[Evolution-hackers] Evolution community meeting at #evolution-meet channel - April 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution's GTK+ requirement
Given all the scrolling and selection bug reports I'm seeing from GTK-3.4 users, none of which are present when building against GTK-3.2, I suggest we keep our minimum requirement at GTK-3.2 until these issues get sorted out, either by us or by Xorg/GTK+ developers. The problems seem to have started when GTK+ 3.3.x switched to XInput2. I don't know the details, but my guess is there's some behavior changes and GDK's X11 backend was written to the old XInput behaviors. Being able to build Evolution 3.5 against GTK-3.2 to prove these are not our regressions is useful. I don't see any particularly compelling new APIs in GTK-3.4 anyway. Sound okay? Any objections? Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] moving messages is visually slow
Hi, I've noticed that moving messages takes considerably more time than deleting them. Visually when I delete a message I see the item disappear almost instantly, I'd like to achieve the same thing when I move a message. Is there any way to achieve this? Maybe hiding the selected items and then move them? I couldn't find anything related to hiding messages (except a boolean for hiding the deleted ones) Cheers! -- David ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] moving messages is visually slow
On Tue, 2012-04-17 at 11:10 -0300, David Roguin wrote: > I've noticed that moving messages takes considerably more time than > deleting them. Visually when I delete a message I see the item > disappear almost instantly, I'd like to achieve the same thing when I > move a message. > > Is there any way to achieve this? Maybe hiding the selected items and > then move them? I couldn't find anything related to hiding messages > (except a boolean for hiding the deleted ones) "Deleting" a message really just tags the message to be deleted when the mail folder is expunged at some later date. It's a fast local operation which you don't even have to be online for, since tags are synchronized with remote mail servers in batches. You can do "View -> Show Deleted Messages" and see the messages tagged for later deletion. Your Trash folder, by the way, is just a live query for these tagged messages across your entire account. "Moving" a message involves appending a copy to the destination folder and then marking the original for later deletion. This naturally takes much longer, and we don't want to mark the original message for deletion until we're sure the copy was successfully appended to the destination. Otherwise we risk data loss if the append fails for some reason. I suppose we could play more tricks with the message list to give the appearance that messages are removed instantly, but the message list is already rife with such tricks, and each new one makes it harder to keep the logic clear and thus harder to maintain. I'm happy to review a patch, though, if you still want to attempt it. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution's GTK+ requirement
On Tue, 2012-04-17 at 09:35 -0400, Matthew Barnes wrote: > Sound okay? Any objections? Sounds fine to me; the only problem I have is that you feel you have to ask in the first place :) Allowing users to build with the old version (of *anything* until there's a *compelling* reason to break the build ought to be our default behaviour anyway. It's a constant PITA that you have to have the latest versions of *everything*, when in practice most of those dependencies aren't really true at all. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution's GTK+ requirement
On Tue, 2012-04-17 at 22:25 +0100, David Woodhouse wrote: > It's a constant PITA that you have to have the latest versions of > *everything*, when in practice most of those dependencies aren't really > true at all. That's not true for Evolution. We don't require unstable releases of base libraries, but anything in the most recent stable release is fair game. That way we can utilize new features at a reasonable pace without forcing contributors to run a whole bleeding-edge desktop just to hack on a bleeding-edge app. GTK+ 3.4 was included in the module set for GNOME 3.4, so it's fair game for Evolution 3.5.1. But I'm asking that we hold off for a little while longer for the aforementioned reasons. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] moving messages is visually slow
On Tue, 2012-04-17 at 10:44 -0400, Matthew Barnes wrote: > On Tue, 2012-04-17 at 11:10 -0300, David Roguin wrote: > > I've noticed that moving messages takes considerably more time than > > deleting them. Visually when I delete a message I see the item > > disappear almost instantly, I'd like to achieve the same thing when I > > move a message. [snip] > I suppose we could play more tricks with the message list to give the > appearance that messages are removed instantly, but the message list is > already rife with such tricks, and each new one makes it harder to keep > the logic clear and thus harder to maintain. I'm happy to review a > patch, though, if you still want to attempt it. Please make sure that you have a good way to inform the user so that he knows Evolution is busy. He needs to know when it is okay to suspend the laptop or pull the networking cable out. -- Knowledge Is Power Power Corrupts Study Hard Be Evil signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] moving messages is visually slow
On Tue, 2012-04-17 at 17:03 -0600, Zan Lynx wrote: > Please make sure that you have a good way to inform the user so that he > knows Evolution is busy. He needs to know when it is okay to suspend the > laptop or pull the networking cable out. That's what the task bar at the bottom is for. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution's GTK+ requirement
On Tue, 2012-04-17 at 09:35 -0400, Matthew Barnes wrote: > Given all the scrolling and selection bug reports I'm seeing from > GTK-3.4 users, none of which are present when building against GTK-3.2, > I suggest we keep our minimum requirement at GTK-3.2 until these issues > get sorted out, either by us or by Xorg/GTK+ developers. > > The problems seem to have started when GTK+ 3.3.x switched to XInput2. > I don't know the details, but my guess is there's some behavior changes > and GDK's X11 backend was written to the old XInput behaviors. Being > able to build Evolution 3.5 against GTK-3.2 to prove these are not our > regressions is useful. Hi, it's scrolling and clicking (preview panel selects text instead of clicking the URL, as indicated in [1], and downgrading to gtk 3.3.14, which is basically the place just before the XInput2, fixes the issue). In other words, there are few regressions with their move to XInput2. > I don't see any particularly compelling new APIs in GTK-3.4 anyway. > > Sound okay? Any objections? Sure thing, they do not provide anything special and new for us. :) Bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=809852 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
