On Fri, 2005-04-29 at 18:51 +0530, Not Zed wrote: > > > Hmm, this seems to be a pretty big patch. It would probably be easier > if you just stuck to the ui parts in the patch, and not a major > re-factor of bits of code (admitedly needed refactoring). > > Which parts were crashing? Calling em_folder_selector_get_selected_path () before making a call to em_folder_selector_get_selected_uri () on the same widget, seems to cause memory corruption, and a subsequent crash.
should've got jeff to look at it.
> Issues: > - Folder->Mark Messages As Read does nothing, i presume this was the > old 'mark all messages as read' one, and it doesn't read the same > anymore Hrmm. I must have overlooked that. I thought it worked, given that we already have something that does this. I'll look into that.
So what happened to the different forwarding message types?
And what happened to the 'hide read messages' and related stuff?
These are pretty major functional changes, not just a re-arranging of menus.
> - folder->subscriptions makes no sense, it isn't a folder operation. > if everything else that was in tools is now in edit, why not move it > there? Everything else that was in tools, for the most part, seem to all be things that should be in preferences anyway. This is why they were moved to Edit, next to the Preferences item.
Subscriptions are a preference too, by that logic.
> - message->mark as ... doesn't make sense much either. 1. it is hard > ot get to, and 2. they alter the message state, i.e. edit it, they > don't alter the messages themselves, which are immutable. They don't alter the messages themselves. They alter metadata related to the messages. They are directly related to the message, and we think this will make them easier to find. Nobody ever knew that these items even existed in the Edit menu before. They were not discoverable. If the Message menu is not the place for them, then user testing we do on them, should show us that, and we can change it.
It is still very hard to get to, and one of the most commonly used functions in a mailer.
The whole message menu's layout is strange, the groupings and order are strange.
> - similalry message->goto doesn't make much sense, since you're > altering the view. These two ops are pretty likely some of the most > often accessed ones, it seems odd to change them, they were quite fine > where they were I thought. You're going to a different message. You aren't altering the overall view of the application. You're just loading a different page or document. And if this proves ineffecient, we can move them. This is why we are doing user testing on these changes, once they get into CVS.
It's still changing the view state, not the message. Certainly as much as changing 'threaded' mode changes the view. Maybe 'threaded' should be in folder? And 'hide deleted messages' as well? And most of the rest of the view folder must live in message, by this logic?
Shouldn't you have done this testing before affecting every user of the application? It seems a little strange to do this, and then if changes are required, go and mess up everyone who is testing the 2.3 codebase.
It applied cleanly, and i did a make && make install. Unless the patch is out of date. Maybe it didn't build properly.> - a bunch of plugins mess up the menu, there is now a blank menu past > help for a few items that used to be in actions (save attachments and > mailing list actions plugins). The Mailing List actions show up under the Message menu for me. Are you sure all of the patch is applied/installed properly for you?
> - the actions menu in the other components now shows up after help > (maybe this only happens if you start in the mailer). This is a slightly annoying side effect that will be remedied as soon as possible. The problem is that everything is a single app, so the base menu structure all comes from the same place, so changing the menus in one component is very difficult to do, without possibly slightly affecting other components. There were similar issues during the 2.2 cycle, with the plug-in menus breaking the menu structure, even just in the mailer. We want to get the mailer stuff in as soon as possible though, so that it can get testing, while we also work on getting the other components migrated to the new structure. > - its a vfolder not a search folder VFolder is a horribly confusing term for a user to see. It doesn't describe at all what the folder does. It's a branding term that we need to get rid of.
Can't you think of a better name than search folder then? Its naff.
> - 'tools' seems to be a bit redundant, everything that was in it is > now in tools, except for some arbitrary choices which aren't. I presume the second "tools" here should be "edit". If we could just hide the hole idea of switching components within evolution itself, and just get rid of "Tools", the buttons, and the preference for their appearance, I would be more than glad. The "Tools" menu is still around for lack of a better place to shove the components.
What was wrong with "view"?
> - what happened to cut and paste?!? Cut and Paste are editing actions. You can not cut text from, or paste text into, a read-only document. "Move to Folder" does the same thing. Select mails, hit C-S-v, and it moves the items to the folder.
Uh. Yeah, like dnd does the same thing. We could just force everyone to only use dnd then right? Or remove dnd - wouldn't want to confuse users with a choice, and dnd needs that nasty mouse thing.
There is quite a lot of code to support cut and paste of messages, is that just going to hang around?
> - folder->expunge seems to be in a weird spot. there are other menu > items which appear to be in strange locations (add sender to > addressbook, 'go to', mark as, Weird how? It's an action on the folder. It seems like it belongs in the Folder menu. Although, I would much prefer to get rid of "Expunge" all together, and just have "Empty Trash". I think a lot of users get confused by the term "Expunge".
It is directly beneath the non-functioning and confusingly named "mark messages as read".
That seems to be a weird spot to me.
"subscriptions", if it must live in that menu, is similarly in an odd spot, at the top, near "new". Rather than at the bottom, under "properties".
> - edit select all text/deselect all text aren't hooked up. what does > deselect all text do, sounds uncommon. We can probably drop Deselect all. It is mentioned in the HIG. If it were hooked up, it would clear the selection of text made in the message display. I must have overlooked these. Will try to get them hooked up as soon as I can.
What an odd thing to have in a mailer. Deselect all text? Who ever does that in a mailer? The hig does seem to have some problems with real applications ... I've never heard or noticed such an option in 20 years of using computers.
> Anyway, take most of those comments with a grain of salt (like i'm > sure you will), although i find no paste a bit of a killer (this is > how i normally move mails around for example, and i'm sure i'm not > alone). Tools looks like it has to die though. Yeah. I am not sure what to do with Tools though. As I said, it's there because there is no better place to put the component menu items. If we
view. You're changing the whole view of the application aren't you? how can it not belong in view?
Why would that be awsome?can fix up Evolution in the 2.3 cycle to hide the other component things, and just drop the internal switching stuff, that would be awesome. I'm not sure if we can do that though.
Not really, it pops up an annoying window that you have to navigate to with the mouse anyway (if you have focus follows mouse).As for paste, I think actually using Move/Copy to Folder would be much faster from the keyboard, and in general, as you don't have to switch folders, so there is a lot less work you have to do as a user. Also, they were confusing at best, especially given that they were context sensitive items.
ctrl-c and ctrl-v are easily remembered shortcuts in an easy to reach place.
shift-ctrl-y is neither.
But, the sooner we can get this in, the sooner we can get proper user testing on it, and the sooner the rest of the components can get fixed as well. And, there will be user testing.
I'm sure microsoft don't wait till a public beta release is patched with radical changes before doing their user testing. Shouldn't you have been doing this user testing in the last 3 months while were in ui freeze? It isn't hard to build a patched package for installing on a user testing lab. Surely.
The patch at least has to work anyway, so awaiting another one.
