speps | 1 Aug 2011 23:15
Picon
Favicon

[sylpheed:34698] Quick search style patch, gtkrc and ml

Hi Hiro,

first of all, thanks for this great mail client.
I'm just sad in realizing there is no bug tracker system.
I found some older posts about this topic, and seems like
there is no intention to switch to any bug tracking platform.

Mailing list is surely a good tool too, btw at least would be
better if we had more than a single ml to handle all topics.

It could be more complex, ex
sylpheed-users    -> for any end user question
sylpheed-bugs     -> a place to signal bugs and send patches
sylpheed-requests -> for any feature request

or simpler
sylpheed       -> any end user topic (help, info, functionalities)
sylpheed-devel -> any development related topic (bugs, requests, patches)

This could be a middle solution, but this is just my opinion.

=========================================================================

About the subject of this mail.
I'm a dark themes addicted (my eyes are grateful), and I often have to
face with noisy readability issues through applications.

Also sylpheed is affected by this with the quick search entry.
The widget displays a message when there is no text and coloured with a
default gray by modifying the GTK_STATE_NORMAL state for the entry.
(Continue reading)

Hiroyuki Yamamoto | 2 Aug 2011 09:29
Picon

[sylpheed:34699] ANNOUNCE: Server maintenance completed

Hello,

Server upgrade of sylpheed.sraoss.jp has been completed.
All services are available again now.

Thanks for your cooperation.

# The server is quad-core Xeon now :)

--

-- 
Hiroyuki Yamamoto <hiro-y <at> kcn.ne.jp>

Hiroyuki Yamamoto | 3 Aug 2011 11:26
Picon

[sylpheed:34700] Re: Quick search style patch, gtkrc and ml

Hello,

On Mon, 1 Aug 2011 23:15:12 +0200
speps <speps <at> gmx.com> wrote:

> first of all, thanks for this great mail client.
> I'm just sad in realizing there is no bug tracker system.
> I found some older posts about this topic, and seems like
> there is no intention to switch to any bug tracking platform.

Actually I want to have a new BTS, but I cannot determine what system
is the best yet.

> Mailing list is surely a good tool too, btw at least would be
> better if we had more than a single ml to handle all topics.
> 
> It could be more complex, ex
> sylpheed-users    -> for any end user question
> sylpheed-bugs     -> a place to signal bugs and send patches
> sylpheed-requests -> for any feature request
> 
> or simpler
> sylpheed       -> any end user topic (help, info, functionalities)
> sylpheed-devel -> any development related topic (bugs, requests, patches)
> 
> This could be a middle solution, but this is just my opinion.

When I started the development of Sylpheed, I intentionally provided
only one mailing list, because I didn't want to divide users and
developers into two groups.
(Continue reading)

Hiroyuki Yamamoto | 4 Aug 2011 06:28
Picon

[sylpheed:34701] Re: Quick search style patch, gtkrc and ml

Hello,

On Wed, 3 Aug 2011 18:26:36 +0900
Hiroyuki Yamamoto <hiro-y <at> kcn.ne.jp> wrote:

> Hello,
> 
> On Mon, 1 Aug 2011 23:15:12 +0200
> speps <speps <at> gmx.com> wrote:
> 
> > first of all, thanks for this great mail client.
> > I'm just sad in realizing there is no bug tracker system.
> > I found some older posts about this topic, and seems like
> > there is no intention to switch to any bug tracking platform.
> 
> Actually I want to have a new BTS, but I cannot determine what system
> is the best yet.
> 
> > Mailing list is surely a good tool too, btw at least would be
> > better if we had more than a single ml to handle all topics.
> > 
> > It could be more complex, ex
> > sylpheed-users    -> for any end user question
> > sylpheed-bugs     -> a place to signal bugs and send patches
> > sylpheed-requests -> for any feature request
> > 
> > or simpler
> > sylpheed       -> any end user topic (help, info, functionalities)
> > sylpheed-devel -> any development related topic (bugs, requests, patches)
> > 
(Continue reading)

[sylpheed:34702] manipulating email outside of sylpheed

i'd like to have my inbox automatically managed such that just
prior to the first download of email each month i move all the
email in the inbox into another directory named YYYY-MM (eg.
2011-08 just before the email for september 2011 is downloaded).

i know how to accomplish this via scripting.

what i'd like some insight into is what if any deleterious
repercussions would result if:

 - i scripted this action to occur while sylpheed was running
 - i scripted this action to occur while sylpheed was *not* running

the main problem i can imagine is that i might lose the
information in the .sylpheed_mark file.

i also imagine that sylpheed might not like it if email files
were moved while it was running, but this may not be true
(assuming the email files being moved were not open), and since i
haven't tested it i figured i'd ask.

if email files were moved when sylpheed was not running, and if
all the email was moved without changing the email numbers
(filenames), shouldn't i be able to also move the .sylpheed_mark
file to a new directory, thereby preserving the various per
message flags that were set?  and would i want to delete or move
the .sylpheed_cache file--maybe the references in the cache file
are path dependent?

thanks,
(Continue reading)

Ricardo Mones | 5 Aug 2011 10:24
X-Face
Picon
Favicon

[sylpheed:34703] Choosing BTS (was: Re: Re: Quick search style patch, gtkrc and ml)

  Hi Hiroyuki,

On Wed, Aug 03, 2011 at 06:26:36PM +0900, Hiroyuki Yamamoto wrote:
> Hello,
> 
> On Mon, 1 Aug 2011 23:15:12 +0200
> speps <speps <at> gmx.com> wrote:
> 
> > first of all, thanks for this great mail client.
> > I'm just sad in realizing there is no bug tracker system.
> > I found some older posts about this topic, and seems like
> > there is no intention to switch to any bug tracking platform.
> 
> Actually I want to have a new BTS, but I cannot determine what system
> is the best yet.

  Umm, choose one you like and feel comfortable using it, waiting for the
best can take forever ;-)

  My suggestion is Trac [0] if the BTS is just for Sylpheed: it's very simple
to install, integrates directly with svn and only needs an Apache and Python.
  Bugzilla would be also a classic choice. There's more [1] of course.

  regards,

[0] http://trac.edgewall.org/
[1] http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
--

-- 
  Ricardo Mones 
  ~
(Continue reading)

nomnex | 8 Aug 2011 01:52
Picon
Gravatar

[sylpheed:34704] Help with search condition for launchpad bug report msg.

I don't know how to define a search condition to filter messages of
this type (launchpad bug reports).

Can you help? Thanks.

Delivered-To: nomnex <at> gmail.com
Received: by 10.231.33.193 with SMTP id i1cs6434ibd;
        Mon, 1 Aug 2011 16:30:55 -0700 (PDT)
Received: by 10.227.28.129 with SMTP id m1mr292267wbc.80.1312241454746;
        Mon, 01 Aug 2011 16:30:54 -0700 (PDT)
Return-Path: <bounces <at> canonical.com>
Received: from adelie.canonical.com (adelie.canonical.com
[91.189.90.139]) by mx.google.com with ESMTP id
fe3si10163208wbb.101.2011.08.01.16.30.54; Mon, 01 Aug 2011 16:30:54
-0700 (PDT) Received-SPF: pass (google.com: best guess record for
domain of bounces <at> canonical.com designates 91.189.90.139 as permitted
sender) client-ip=91.189.90.139; Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of
bounces <at> canonical.com designates 91.189.90.139 as permitted sender)
smtp.mail=bounces <at> canonical.com Received: from loganberry.canonical.com
([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.71 #1
(Debian)) id 1Qo1wk-0005pW-2I for <nomnex <at> gmail.com>; Mon, 01 Aug 2011
23:30:54 +0000 Received: from loganberry.canonical.com (localhost
[127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id
DA7A52E895A for <nomnex <at> gmail.com>; Mon,  1 Aug 2011 23:30:53 +0000
(UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable Date: Mon, 01 Aug 2011
23:24:51 -0000 From: nomnex <nomnex <at> gmail.com>
To: nomnex <at> gmail.com
Reply-To: Bug 819554 <819554 <at> bugs.launchpad.net>
(Continue reading)

speps | 8 Aug 2011 18:32
Picon
Favicon

[sylpheed:34705] Re: Quick search style patch, gtkrc and ml

On Thu, 4 Aug 2011 13:28:27 +0900
Hiroyuki Yamamoto <hiro-y <at> kcn.ne.jp> wrote:

> Hello,

Hi, again :)

> > Actually I want to have a new BTS, but I cannot determine what system
> > is the best yet.

That's a great news, and I bet switching to a BTS would improve
significantly sylpheed development.

Choosing the best one, is pretty hard, since many BTS are stable enough
and comparable.
A good one would fit better to your needs ;)

I also prefer Trac, as it is simple and powerful enough.

Bugzilla, Mantis, Fossil, Flyspray, etc are also good choices, just try them.

> > When I started the development of Sylpheed, I intentionally provided
> > only one mailing list, because I didn't want to divide users and
> > developers into two groups.

I see, this could cause a user splitting, so some devels could ignore
the end users list.
That's why a BTS is often a better choice.

> > But maybe it is better to have several purpose-based MLs at this time.
(Continue reading)

speps | 8 Aug 2011 18:52
Picon
Favicon

[sylpheed:34706] Re: Quick search style patch, gtkrc and ml

> The patch attached solves the issue, removing that code.

Sorry i forgot to attach it, here it is ;)

- speps -
Attachment (gtkrc.patch): application/octet-stream, 1561 bytes
speps | 9 Aug 2011 12:42
Picon
Favicon

[sylpheed:34707] was Fw: Bug#585483: sylpheed: folder tree draws icons in an incorrect way

Hi, I need to reopen this one year old bug, cause it was never solved.

I'm affected by the same noisy issue reported by Ricardo Mones [1],
the gtktreeview rows are wrongly height fixed, so

#if GTK_CHECK_VERSION(2, 12, 0)
      g_object_set(treeview, "fixed-height-mode", TRUE, NULL);
#endif

cause a weird behaviour.

The "fixed-height-mode" property speeds up the treeview drawing by applying
the same height calculated in the first row to the others.
This way, all rows elements needs to be the same in height, to let this
work properly.

What happens here, depends on the different folder-*.{h,png} height compared
to the other stock icons.
While all icons are 16 in height, folders are 12.
Since the first row always contains a folder icon, "fixed-height-mode"
forces every row height to the first one, even if the first row is shorter
than 16 pixels, causing cuttings in the other rows.

So, if text size in pixels is higher or equal than 16 pixels, you'll not
notice any glitches, otherwise every non folder row will be cut in height.

This is my case, since I use very little font, and it also cause slowness.

The first solution is to completely remove those 3 lines, in the way
"fixed-height-mode" is not used any more, since it seems this was
(Continue reading)


Gmane