Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why?

[Not Zed <notzed ximian com>]

On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote:
> Hi Jon, 
>
>
> On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote:
> > Hello,
> > 
> > You are attempting to draw conclusions from the number of open bugs 
> > without considering all bugs.  Please see:
> > http://en.wikipedia.org/wiki/Selection_bias
>
> I thought it might be something of the sort Jon.  Appreciate the heads
> up on the possibility of my impression being way off based on skewed
> analysis based on the bugs that are still in existence without taking
> into account all the countless bugs and feature requests that have
> probably been dealt with already.  
>
> I meant no offense by the way in case anyone found my impression
> offensive.  I was mostly asking so that others could help me see
> differently.  
>
> And from the standpoint of wondering how to approach making changes to
> the code for my own use and that of potential business clients of mine.
> Whether to participate in helping out or not based on my perception of
> whether any changes would be well received or considered or not.  
>
> > If you have a sincere desire to help, produce good quality code to fix a 
> > problem.  We can never have enough people volunteering to be part of the 
> > solution.
>
> For sure Jon.  But on my end I am not so much interested in squashing
> bugs as much as I am in changing the way Evolution works in some of it's
Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests.  It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either.  I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches.
> more quirky ways.  For I have settled on Evolution as my email client of
> choice and will be with it for years to come. So it's worth it for me to
> work on some changes.  
>
> For example....
>
> 1. Get rid of the way the Send/Receive box takes over the screen and
> does not allow one to do much of anything in Evolution until AFTER it
> has finished.  Only way that I have found around this is to set
> Evolution into automatic retrieval mode and then go off to do something
> else on my computer.  But it would be better to get rid of the box
> altogether and replace it with some kind of indicator on the status bar
> unless user wishes otherwise.  
I never knew this was a problem.  Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows.  You should still be able to just close the window using the close button, and it will keep downloading in the background.

Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it.  Its easy, write a patch, and then see if anybody wants it.
> 2.  Provide the means to be able to run a filter on a folder of emails
> manually. Without having said filter execute on incoming emails or
> outgoing emails only.  Right now there is no such mechanism and this is
> quite handy, almost needful,  to have to accomodate those who don't want
> all their email filtered until AFTER they have read it all out of their
> inbox. 
We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list).  This was removed years ago.  I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something.
> 3.  Revamp the way Evolution responds to key presses and otherwise on
> the screen such that a user has a hard time telling what area of the
> screen is in focus and what their key presses will affect.  For example
> the blue highlight bar (under Gnome) is in the folder pane over a
> folder.  The emails in that folder are being displayed in the message
> pane (not the preview pane).  One presses "." to go to the first unread
> message in the folder followed by the down arrow key to get to the next
> one (which is intuitive).  What happens?  The highlight bar moves to the
> next folder not the next message.  This is confusing and quirky.  It's
> difficult to tell what pane will be affected by my keypresses.  
Well the focus is on the folder tree in that case (as clearly indicated by the blue selection).  So all normal key presses should be going there.  Menu accelerators are global however.

Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to.  Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything.  And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone.
> 4. Change the little, itty bitty check boxes Enabling the checking of
> email from the various accounts one has, to more standard check boxes
> that are more seen to be that.  The one's that are there look like some
> kind of decorative icon and are thus confusing.  I mean they look pretty
> and all but for a regular user they are confusing since they don't look
> like any checkboxes one normally sees in programs of any kind.  I mean
> the check inside the box I should say.  Not the fact that there is a box
> accepting a check.  
As far as I'm aware, we're just using standard gtktreeview checkboxes here.  That would be a gtk+ issue quite beyond our control.  The same checkboxes are used for enabling calendars.
> I could go on.....
>
> Suffice it to say that each of these changes, while perhaps good overall
> and not just beneficial to me personally, would require a lot of effort
> not only to implement for myself alone but perhaps for everyone through
> a more formal inclusion into the main code branch.  
Well, we have quality standards that must be met.  But that isn't the problem usually.  Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input.  The developers are not always able to have the last word, so the process falters because of management issues.
> I'm not sure I want to fight for these changes and take the time to so
> fight for them if in the end such changes are going to be considered
> invalid, of no use, or even frowned upon.  That is why I was asking
> about the apparent lack of closure to some very old bugs and very old
> feature requests.  Either in implementing such or definitively putting
> them to rest by stating that they will not be worked on for this or that
> logical reason.  All I see with most of the old one's left is that they
> keep getting knocked to later or in the future.  They are never closed
> if that makes sense.  
There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that.
> Again my apologies if my impressions are way off but please take into
> account that I am feeling my way around all this for the first time with
> Evolution.  

It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans.


> > 
> > Jon
> > 
> > Carlos Gonzalez wrote:
> > > I was reading through a bunch of the bug and feature requests entered
> > > into the Ximian bug database and was struck by how so many of them have
> > > not had any resolution for years while being requested over and over
> > > again.  
> > > 
> > > Is this because there are not enough people volunteering to fix bugs
> > > and/or add features?  
> > > 
> > > Is this because of a philosophical lack of willingness to include some
> > > of the feature requests (many of whom seem quite reasonable)?  
> > > 
> > > A little of both or maybe something else?  
> > > 
> > > I am just curious given that I am looking at starting to make some
> > > changes in Evolution for my own use and that of my business clients and
> > > want to work as much as possible with Evolution developers as opposed to
> > > independent of them.  But I don't want to even bother helping out if
> > > there is some sort of philosophical mind set against adding new features
> > > or some such.  In the end I may just have to incorporate the features
> > > that I and perhaps some of my clients might want in my own little "fork"
> > > rather than waiting for something to make it into the main tree, so this
> > > issue may be mute but I am mainly just curious as to why it seems to
> > > take so long to act on a bug or a feature request.  
> > > 
> > > I suppose I should also take into account that I was only viewing those
> > > things that were not resolved and that the context of seeing this
> > > against the great numbers that may have been resolved already is
> > > missing.  
> > > 
> > > Any insight on this would be appreciated.  
> > > 
> > > Thanks. 
> > > 
> > > Carlos 
> > 
> > _______________________________________________
> > evolution-hackers maillist  -  evolution-hackers lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-hackers
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers