Hi Not, > > 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. That makes sense Not. I see what you mean. > 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. That also makes sense Not. I guess in the final analysis, given that Evolution is open source, that people could take the code, spend a few weeks studying it, and then make changes to it themselves. Something I do hope to do. > > 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. > 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. Hmmm...I hadn't thought of just closing that window. I will try that. Hopefully the mail will continue to download on it's own. I did not realize that this was more a factor of the Gnome window manager forcing this behaviour on users and not so much an Evolution thing. Sorry about that. > 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. Hmm...I'll look into that Not. Bonobo eh? I'll have to study up on that. > > 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. That's a shame that this was removed. Perhaps years ago it was a rather new feature. One that has now become incorporated in every other MLA that I have used (Eudora, KMail, Outlook Express (I think)). It's quite handy. > > 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. > 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. I don't think it's that plain and clear cut Not. Even today I found myself occasionally hitting the down arrow key hoping to go to the next unread message only to find myself going to the next folder instead. Very frustrating. I've been using Evolution for going on a week lots by now and I still don't have it straight. Thing is Evolution itself isn't consistent in this. The blue highlight might be over a folder. I press "." to go to the first unread message in the folder and it takes me there. Then I use arrow keys to go to the next message. While the blue highlight is still back in the folder pane. This is just downright confusing. I did discover that the expired highlight bar which is a drab color brownish thing IS a gnome specific thing and not an Evolution thing. It's just that I first noticed this in Evolution but it's a gnome thing. So I guess I am stuck with that silly expired highlight bar unless I want to hack into Gnome (no thanks). > > 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. > 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. Yeah I found out that's also a gnome thing. Very silly looking mini checkboxes if you ask me. I mean they're cute little things and all but quite disfunctional in not being like any more normal check box. > 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, That's not good. > 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. Ain't that the way it usually is? :) That's the kind of issue that I don't particularly want to mess with so it seems best for me to just make the changes on my own for me and my clients, submit those changes and make them available to all, but don't fight for any particular change to be incorporated. It sounds like doing so would just be an exercise in frustration. The only thing I have to figure out is how to make my changes applicable to my own situation after every update of evolution. That might get tricky. Maybe my whole desire to change a few things is nutty :). I don't. I'll think about this some more before I go changing anything. > 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. Hmm...I see. > > 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. Well it's not that I want to make changes without considering the long term plans Not. It's that I don't want to take the time to fight for changes if the Evolution ui people are, as you say, not around much for feedback and the developers don't have a choice, why bother? It'd be easier for me to just work my own ui and coding changes on the side for just me and my clients. I wouldn't mind at all getting involved more in helping out if I had more of a hope that my efforts might lead to something constructive as opposed to being swallowed up in a sea of management issues or the like. I hope that makes sense. Incidentally just so you know I think the work that has been done so far to make Evolution what it is, is absolutely mindboggling! In a good sense. I mean it boggles my mind that open source software can be as good if not better than commercially produced software in the spheres where it is found. Carlos _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
