Re: Move help menu item to last-on-left not first-on-right?
On Thu, Feb 10, 2000 at 10:16:12AM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > It's not a gratuitous change, but I'm not going to defend it to the > death if people object. Well, I see your point now. I would not object to do this in 1.2 (but only then, since it is yet another menu shortcoming of gtk+), since it works around a bug that we cannot fix otherwise (I believe). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Move help menu item to last-on-left not first-on-right?
On Thu, 10 Feb 2000, Nick Lamb <[EMAIL PROTECTED]> wrote: > On Thu, Feb 10, 2000 at 04:47:48AM +0100, Marc Lehmann wrote: > > c) you gave _no_ reason why? > > Ah, that wasn't clear from my diagrams? GTK+ draws space either side of > a menu item, so the Help menu can cover over Xtns, making it useless > and forcing me to have an otherwise unnecessarily wide toolbox. If the > Help menu was in the same SET of menu items as File, Xtns (ie on the > left) it would never overwrite them, and therefore use less space. Also > if we're going to have casualties from manually shortened toolboxes, > Help is much less useful than Xtns, because its key features are > duplicated elsewhere. Hmm... I should have written that before. For a first-time user of the Gimp, there is no problem: the default layout of the toolbox has the colors, brush and gradient to the right of the tools and aspect ratio of the toolbox is close to a square. Since there is enough room for the full menu bar in the default layout, the user will be able to access "File", "Xtns" and "Help" easily. Also, the location of "Help" is consistent with other applications. But things are different once you really start using the Gimp: most of the users that I have seen start by resizing the toolbox to the "traditional" shape which puts the colors, brush and gradient at the bottom of the list of tools. They prefer the thin aspect ratio because it is easier to work with the toolbox when it is on the edge of the screen and not taking too much valuable space near the center. Once you resize the toolbox, its size is saved in your sessionrc so it will always have the same shape (even after you upgrade, so it is easy for us to forget what the default layout looks like). If you have the "thin" layout, then there is not enough room for all items on the menu bar. For example, what I get under Solaris (the font sizes are slightly different under Linux) looks like this: "File X Help" As a frequent user of the Gimp, I use "Xtns" much more often than "Help" and I would certainly prefer the following layout: "File Xtns H" Or even this, if there was a way to persuade Gtk to reduce the reduce the space between the items: "File Xtns Hel" If there is no easy way for the Gimp to detect when the menu bar is too narrow (depending on the font size and other parameters), then I would prefer to have the help menu item changed from first-on-right to last-on-left. If it is possible to detect when the menu bar is too narrow (I haven't checked the Gtk code), then there are several things that could be done: - rename "Help" to "?", as Simon suggests - reduce the space between items, if possible - switch help from first-on-right (which would be the default) to last-on-left, dynamically -Raphael
Re: [gimp-devel] Re: Move help menu item to last-on-left not first-on-right?
Nick Lamb ([EMAIL PROTECTED]) wrote: [Reordering the Toolbox Menubar, because "Help" clobbers "Xtns" with narrow Toolboxes] What about renaming "Help" to "?" ? Maybe we can do this automagically in narrow Toolboxes. Is there a way to detect the clobbering? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Move help menu item to last-on-left not first-on-right?
On Thu, Feb 10, 2000 at 04:47:48AM +0100, Marc Lehmann wrote: > a) what does HCI mean? ;) Someone already answered this. To see bad examples, either look at http://www.iarchitect.com/mshame.htm or look in a good bookstore. > b) I always see programs do it the way gimp does it, so there must be >something about it They give the same reason you do "Uh, everyone else does it", it seems to originate on Windows, but maybe it's the Mac's fault? The only justification I can think of is "Users have good spatial awareness and can always find the top-left of a window". > c) you gave _no_ reason why? Ah, that wasn't clear from my diagrams? GTK+ draws space either side of a menu item, so the Help menu can cover over Xtns, making it useless and forcing me to have an otherwise unnecessarily wide toolbox. If the Help menu was in the same SET of menu items as File, Xtns (ie on the left) it would never overwrite them, and therefore use less space. Also if we're going to have casualties from manually shortened toolboxes, Help is much less useful than Xtns, because its key features are duplicated elsewhere. Hmm... I should have written that before. > > they are there. Comparison with other image editing apps (especially > > on Unix/Linux) is appreciated, > > I think that the type of application should not influence the place where > the help button menu is placed. Oh, I see. Good point. It just seemed "better" to look at similar apps rather than e.g. Hog Racing 2000 or MS Word. > So... I am not against this change, but I also see no reason to do it, > especially since that makes gimp different to other apps, and I think > there should be a very good reason for this. Well, for me it is helpful (see above) and it looks like all the other apps I run, with the exception of XChat. However I'm aware that most of gimp-devel are using a different set of apps from me, and probably making a lot more use of MS Windows, this may even be *more* true of our ordinary users. It's not a gratuitous change, but I'm not going to defend it to the death if people object. Nick.
Re: Move help menu item to last-on-left not first-on-right?
Marc Lehmann said... | |a) what does HCI mean? ;) Human-computer interface |b) I always see programs do it the way gimp does it, so there must be | something about it It gets done both ways - depends on the OS, the window manager, the app, the toolkit... I prefer it all the way to the right, myself. What happens when the window is too narrow is (should be) independent of whether the Help menu button is lft or right justified. -Miles
Re: Move help menu item to last-on-left not first-on-right?
On Wed, Feb 09, 2000 at 03:14:58PM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > > I'd like to change the Toolbox to do this: > > Can people please tell me why (technical or HCI reasons) I shouldn't a) what does HCI mean? ;) b) I always see programs do it the way gimp does it, so there must be something about it c) you gave _no_ reason why? > they are there. Comparison with other image editing apps (especially > on Unix/Linux) is appreciated, I think that the type of application should not influence the place where the help button menu is placed. So... I am not against this change, but I also see no reason to do it, especially since that makes gimp different to other apps, and I think there should be a very good reason for this. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Move help menu item to last-on-left not first-on-right?
I'd like to change the Toolbox to do this: .. or .___. or .. | File Xtns Help || File Xtns Help|| File Xtns H| rather than (as now) this: .. or .___. or .. | File Xtns Help || File Xtn Help || File Help | Can people please tell me why (technical or HCI reasons) I shouldn't do this, given that we don't HAVE to use GTK+ features just because they are there. Comparison with other image editing apps (especially on Unix/Linux) is appreciated, flame wars are not. Ideally, of course, GTK+ would do *something* when menus are not given sufficient width allocation, but that's not fixable for Gimp 1.2.0 release. Right now what I have most resembles the left-most bad case above, and it's impossible to choose Xtns(!) PS This is, AFAIK, a one-liner change in some data, and thus very, very unlikely to break anything. Nick.
