Re: Review Request: Adjust the kde fake mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
On 2010-12-13 16:48:31, Ingo Klöcker wrote: How about using vnd.kde.fontspackage instead of x-kde-fontspackage? Rex Dieter wrote: I only used x-kde-fontspackage at aaron's suggestion in one of the aforementioned bugs, I'm not attached to it. vnd.kde.fontspackage is fine with me too. Christopher Yeleighton wrote: How about submitting a registration of application/vnd.kde.fontspackage to IETF first? vnd.registrations are just let go. I could prepare the registration form, but some KDE VIP would have to sign it. Rex Dieter wrote: OK (?), I'm not familiar with that, so any assistance would be appreciated. 1. Where is a definitive description of the purpose and the content of the media type? 2. All registrations in the KDE domain are submitted by David Fauré; accordingly, his opinion on the matter would be greatly appreciated. - Christopher --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/#review9232 --- On 2010-12-13 17:07:48, Rex Dieter wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/ --- (Updated 2010-12-13 17:07:48) Review request for kdelibs. Summary --- This patch adjusts the kde fake mimetype fonts/package so desktop-file-utils/shared-mime-info doesn't complain (using application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 Diffs - /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop 1206154 /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 Diff: http://svn.reviewboard.kde.org/r/6111/diff Testing --- confirmed no warnings/errors from desktop-file-utils/shared-mime-info Thanks, Rex
Re: Action icons in menus
Am Montag 13 Dezember 2010, 23:42:37 schrieb Dan Meltzer: If common actions were all handled in this way, then it might actually lead to more consistancy, and ease of access. I don't know.. how do I know whether I need to look for a large toolbar button at the top or for a regular menu entry below? Who decides *what is a common action*? (For instance, I usually remove cut/copy/paste from toolbars, since they waste space - come on, who uses the mouse for those actions??) Actions are not particuallarly consistant across applications, It depends, in particular the cut/copy/paste set is typically found in (roughly) the same space, in the Edit menu. That's a matter of UI style guide and I don't think we suffer from this w.r.t. those common actions. (Please give concrete examples if you disagree.) and so it becomes necessary to read the entire list to find the item you are looking for. ..yet I find it easier to read through one long list than to a) first, read the toolbar items at the top, and then b) read the list below, which is in a totally different formatting. I think that's my main problem with M$'s ribbons: I feel it takes me more time to locate actions which I know to be there (somewhere). If cut/copy/paste were always found as icons at the top of the menu in applications that support them, it would probably lead to accessing them quicker. But only if the set of icons does not change from app to app, no? Then, what's the difference compared with a predefined section in the edit menu (possibly requiring the actions to be at the top)? Just my critical 2 cents, Hans
Re: Action icons in menus
On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. Probably half of KMail's shortcuts do not correspond to any menu entries (but of course KMail is a bit special). And in Konqueror I had to lookup the shortcut for Force Reload under Configure Shortcuts. A third argument against is that people using the menu will most likely continue doing so. So for them the shortcut is totally irrelevant. In fact, it's superfluous information that clutters the menu. And for those that are really interested in the shortcut it's also superfluous information as soon as they have learned the shortcut. I agree that it's often nice to see the shortcuts, but given my first two points I don't think it's a serious problem if the shortcuts are missing. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
On Tue, December 14, 2010 2:52 pm, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. I doubt if many inexperienced users will know about Settings-Configure Shortcuts. Personally, I rely on menus to provide me with the information when I want to learn a new shortcut - I wouldn't normally go to the bother of looking in Settings unless I felt very motivated. So yes, I think this is a significant problem, since it raises the barrier to inexperienced users learning shortcuts. Note that this proposal addresses common actions only, so the fact that some shortcuts are not documented in menus isn't really relevant. A third argument against is that people using the menu will most likely continue doing so. So for them the shortcut is totally irrelevant. In fact, it's superfluous information that clutters the menu. And for those that are really interested in the shortcut it's also superfluous information as soon as they have learned the shortcut. As I mention above, I don't think they necessarily will ever learn the shortcut if they first have to discover a Settings page, and then open it up each time they want to find a new shortcut. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Action icons in menus
On 14.12.10 15:52:39, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our Thats not easy thats cumbersome. Especially with bigger plugin-based apps that have a few dozen shortcuts. shortcuts where documented in some menu anyway. Probably half of KMail's shortcuts do not correspond to any menu entries (but of course KMail is a bit special). And in Konqueror I had to lookup the shortcut for Force Reload under Configure Shortcuts. A third argument against is that people using the menu will most likely continue doing so. I disagree. If I approach a new app the menu is what helps me find my way to the things I need. At the same time I'm able to learn the shortcuts easily so at some point I'm using the shortcuts more and more instead of the menu. In particular I can learn the shortcut while doing the work, instead of sitting down and staring at the configure-shortcuts dialog for an hour. You're right though for people not willing/used to use shortcuts, those will always go through the menu no matter how often they read or get told about the shortcut. Andreas -- A day for firm decisions! Or is it?
Re: Review Request: Adjust the kde fake mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
On 2010-12-14 12:59:34, David Faure wrote: The real question is whether this mimetype is used for files, or only for internal fake purposes. If for files, then it should be added to shared-mime-info (Pino or I can help with that). But if I remember correctly in this case it's not about files, which is why a fake mimetype is used. In that case, I'd rather not reuse an existing file mimetype, but rather use a kde-specific fake name. The mime definition in kde.xml seems to imply it's for real *.fonts.zip file globs. svn log kde.xml doesn't seem to include any mention of fonts/package origin though. :( (and I don't see anything in branches/KDE/3.5 either) - Rex --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/#review9248 --- On 2010-12-13 17:07:48, Rex Dieter wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/ --- (Updated 2010-12-13 17:07:48) Review request for kdelibs. Summary --- This patch adjusts the kde fake mimetype fonts/package so desktop-file-utils/shared-mime-info doesn't complain (using application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 Diffs - /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop 1206154 /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 Diff: http://svn.reviewboard.kde.org/r/6111/diff Testing --- confirmed no warnings/errors from desktop-file-utils/shared-mime-info Thanks, Rex
Re: Action icons in menus
Dne torek 14 decembra 2010 ob 16:08:42 je David Jarvie napisal(a): On Tue, December 14, 2010 2:52 pm, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. I doubt if many inexperienced users will know about Settings-Configure Shortcuts. Personally, I rely on menus to provide me with the information when I want to learn a new shortcut - I wouldn't normally go to the bother of looking in Settings unless I felt very motivated. So yes, I think this is a significant problem, since it raises the barrier to inexperienced users learning shortcuts. Perhaps showing the shortcut as a part of the tooltip? I know this is getting off-topic, but it's one idea. This could also be beneficial for actions in normal toolbars, which many people use without knowing the shortcut. I have no solution for DBusMenu, as I don't know how that works. I agree that it is very important that this should works for all menus. Maybe it can be worked around, maybe not. As some of you said before, we really do memorize positions of actions in menus. For example, Firefox 4 reversed the positions of Open in New Window and Open in New Tab, and I remember having many problems with that. However, is this really necessary? Memorizing always takes some iterations, and we do remember pictures easier and faster. Regarding consistency, the actions are consistent with the ones in toolbars. I don't see a good reason why menus should be treated completely different, because they're both just containers of actions. signature.asc Description: This is a digitally signed message part.
