Re: An experiment (was Re: Move help menu item...)
[EMAIL PROTECTED] wrote: > On 13 Feb, Kelly Lynn Martin wrote: > > > This can be dangerous; you can get a resizing loop if your code isn't > > carefully written. Window managers can refuse to accept a client > > resize request or can modify it, which could result in a duel between > > GIMP and the window manager as the two fight over who gets to decide > > what size the window will be. > > Hm, but how does it work to create the initial window then? Doesn't > gtk/gdk tell the window manager how big the window should be? Kelly's right; there is no confusion about it. Window managers own windows. Period. The best that an application can do is HINT about a 'favored size', but said application has to be prepared to deal with the circumstance when that size is not available. This is because window managers are run by users, who express all kinds of preferences to the window manager itself. Indeed, a window manager isn't even obligated to MAP an application. Be good, be well. Garry Osgood
Re: An experiment (was Re: Move help menu item...)
On 13 Feb, Kelly Lynn Martin wrote: > This can be dangerous; you can get a resizing loop if your code isn't > carefully written. Window managers can refuse to accept a client > resize request or can modify it, which could result in a duel between > GIMP and the window manager as the two fight over who gets to decide > what size the window will be. Hm, but how does it work to create the initial window then? Doesn't gtk/gdk tell the window manager how big the window should be? Maybe it would be even possible to hide/destroy the window and then show/create it again when we'll now the final size. This things are really mystic to me, do you have experience in that area? -- Servus, Daniel
Re: An experiment (was Re: Move help menu item...)
On Mon, 14 Feb 2000 14:21:39 -0500 (EST), Glyph Lefkowitz <[EMAIL PROTECTED]> said: >Rather than doing this, wouldn't it be possible to do the same thing >that terminals do, I.E. make the window resizable by char cells >rather than pixels? I like the fact that I can resize the window as >I work, rather than digging through dialogs to choose a setting... The problem is that the buttons in the toolbox are themselves resizable. Kelly
Re: An experiment (was Re: Move help menu item...)
> On Fri, 11 Feb 2000 13:25:04 +0200 (EET), Tor Lillqvist <[EMAIL PROTECTED]> said: > > >One suggestion would be to not have the toolbox user-resizeable via > >the window manager at all, but to have in the Preferences a setting > >where you use a spinbutton to set the number of columns. If you start > >from, say, three columns, and keep increasing the number, at the > >point where the number of rows is less than the number of columns, > >the colour, brush, pattern and gradient selectors could automagically > >jump to be at the right side instead of the bottom. Rather than doing this, wouldn't it be possible to do the same thing that terminals do, I.E. make the window resizable by char cells rather than pixels? I like the fact that I can resize the window as I work, rather than digging through dialogs to choose a setting...
Re: An experiment (was Re: Move help menu item...)
On Fri, 11 Feb 2000 13:25:04 +0200 (EET), Tor Lillqvist <[EMAIL PROTECTED]> said: >One suggestion would be to not have the toolbox user-resizeable via >the window manager at all, but to have in the Preferences a setting >where you use a spinbutton to set the number of columns. If you start >from, say, three columns, and keep increasing the number, at the >point where the number of rows is less than the number of columns, >the colour, brush, pattern and gradient selectors could automagically >jump to be at the right side instead of the bottom. This is as good an idea as any I've seen so far. Kelly
Re: An experiment (was Re: Move help menu item...)
On Thu, 10 Feb 2000 19:50:07 +0100 (CET), [EMAIL PROTECTED] said: > Hm, couldn't we use the event handling system to automatically resize > the toolbox to a new good value on every resize event: > If you enlarge the toolbox the window size automatically snaps on the > next convenient size and vice versa... This can be dangerous; you can get a resizing loop if your code isn't carefully written. Window managers can refuse to accept a client resize request or can modify it, which could result in a duel between GIMP and the window manager as the two fight over who gets to decide what size the window will be. Kelly
Re: An experiment (was Re: Move help menu item...)
Raphael Quinet wrote: > 1. Use WM hints to ensure that the toolbox has a minimum width. This ... > 2. Try to take corrective measures in the Gimp when it detects that ... > 3. Make it possible to split the toolbox in several independent ... > 4. Use some tricks in Gtk to make sure that the full menu bar pops out Why not let the menu items wrap to next line? It might not be possible with Gtk+ now, but it would certainly solve the problem. This is how MS windows behave, though :-) Example: -- |File| |Xtns| |Help| -- Edheldil
Re: An experiment (was Re: Move help menu item...)
One suggestion would be to not have the toolbox user-resizeable via the window manager at all, but to have in the Preferences a setting where you use a spinbutton to set the number of columns. If you start from, say, three columns, and keep increasing the number, at the point where the number of rows is less than the number of columns, the colour, brush, pattern and gradient selectors could automagically jump to be at the right side instead of the bottom. --tml
Re: An experiment (was Re: Move help menu item...)
On Thu, Feb 10, 2000 at 10:29:56AM -0500, Zach Beane - MINT wrote: > On Sat, Feb 12, 2000 at 10:09:42AM -0600, Jon Winters wrote: > > > > I've had problems with the toolbox ever since it became re-sizable. I can > > size it exactly the way I want it, three vertical rows of tools with > > colors, brushes, patterns, and gradients below but the brushes, patterns, > > and gradients are always pushed outside the window, invisible and > > un-usable. > > > > I'm having the same problem on my Linux machines and my windows boxes. > > > > Is there anything that can be done to stop this? > > > > If I haven't explained the problem let me know and I'll post a screengrab > > to illustrate. > > I think everyone has seen this behavior, actually, but I've always just > ignored it, knowing it was a work in progress. > > Yosh: As 1.2 approaches, is this feature going to be fixed so that it works, > or will it be jettisoned in favor of the old-style toolbar? We'll keep on futzing with things for a bit. If it's not satisfactorily fixed and it's the only major showstopper left, it'll be jettisoned. -Yosh
Re: An experiment (was Re: Move help menu item...)
On Thu, Feb 10, 2000 at 07:50:07PM +0100, [EMAIL PROTECTED] wrote: > Hm, couldn't we use the event handling system to automatically resize > the toolbox to a new good value on every resize event: Yes. However, I estimate that it is easier to implement a saner menu display than to implement the code necessary to calculate possible toolbox sizes. -- -==- | ==-- _ | ---==---(_)__ __ __ 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, 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: An experiment (was Re: Move help menu item...)
I've had problems with the toolbox ever since it became re-sizable. I can size it exactly the way I want it, three vertical rows of tools with colors, brushes, patterns, and gradients below but the brushes, patterns, and gradients are always pushed outside the window, invisible and un-usable. I'm having the same problem on my Linux machines and my windows boxes. Is there anything that can be done to stop this? If I haven't explained the problem let me know and I'll post a screengrab to illustrate. -- Jon Winters http://www.obscurasite.com/ OpenVerse http://www.openverse.org/
Re: An experiment (was Re: Move help menu item...)
On 10 Feb, Raphael Quinet wrote: >> Flexibility is ok.. but some time create problems. >> Why don't set fixed sizes x*y to cover all the dimension of toolbar? >> This could be usefull to have right dimension and good >> rappresentation. > Unfortunately, this is not so simple. Constraining the dimensions of > a window requires some cooperation between the application and the > window manager. Under X, you cannot simply tell the WM that some > fixed sizes should be allowed for your window but not some others. Hm, couldn't we use the event handling system to automatically resize the toolbox to a new good value on every resize event: If you enlarge the toolbox the window size automatically snaps on the next convenient size and vice versa... -- Servus, Daniel
Re: [gimp-devel] Re: An experiment (was Re: Move help menu item...)
> > I've had problems with the toolbox ever since it became re-sizable. I can > > size it exactly the way I want it, three vertical rows of tools with > > colors, brushes, patterns, and gradients below but the brushes, patterns, > > and gradients are always pushed outside the window, invisible and > > un-usable. > > Known Bug. Solution: If the Gradients are unuseable make the window > *smaller*. Yes, smaller. The gradients will come up. Please stop discussing last weeks interface. If you have not yet tried it after the recent changes, it's time again to check it out from cvs... Salut, Sven
Re: An experiment (was Re: Move help menu item...)
On Sat, Feb 12, 2000 at 10:09:42AM -0600, Jon Winters wrote: > > I've had problems with the toolbox ever since it became re-sizable. I can > size it exactly the way I want it, three vertical rows of tools with > colors, brushes, patterns, and gradients below but the brushes, patterns, > and gradients are always pushed outside the window, invisible and > un-usable. > > I'm having the same problem on my Linux machines and my windows boxes. > > Is there anything that can be done to stop this? > > If I haven't explained the problem let me know and I'll post a screengrab > to illustrate. I think everyone has seen this behavior, actually, but I've always just ignored it, knowing it was a work in progress. Yosh: As 1.2 approaches, is this feature going to be fixed so that it works, or will it be jettisoned in favor of the old-style toolbar? Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: [gimp-devel] Re: An experiment (was Re: Move help menu item...)
Jon Winters ([EMAIL PROTECTED]) wrote: > I've had problems with the toolbox ever since it became re-sizable. I can > size it exactly the way I want it, three vertical rows of tools with > colors, brushes, patterns, and gradients below but the brushes, patterns, > and gradients are always pushed outside the window, invisible and > un-usable. Known Bug. Solution: If the Gradients are unuseable make the window *smaller*. Yes, smaller. The gradients will come up. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: An experiment (was Re: Move help menu item...)
On Sat, 12 Feb 2000, Jon Winters <[EMAIL PROTECTED]> wrote: ^ You seem to have a problem with the date on your computer. :-) > I've had problems with the toolbox ever since it became re-sizable. I can > size it exactly the way I want it, three vertical rows of tools with > colors, brushes, patterns, and gradients below but the brushes, patterns, > and gradients are always pushed outside the window, invisible and > un-usable. Well, here is how I usually resize the Gimp toolbox so that it becomes usable: 1 - Increase the height of the window to more than 400 pixels. It is important to start with more than enough room at the bottom of the toolbox. 2 - Do not change the height but reduce the width of the window so that exactly 3 columns of icons fit in it. This is easier to do if your window manager allows you to resize a window only in one dimension (e.g. by dragging an edge instead of a corner). For me, the best width is 86 pixels. 3 - Do not change the width but reduce the height of the window so that there is no blank space left between the last row of icons and the fg&bg colors. For me, this means 86 x 376 pixels. Another way to do it is to quit the Gimp, edit ~/.gimp-1.1/sessionrc and change the entry for the toolbox so that it contains "(size 86 376)". Hmmm... Maybe this should go into a FAQ or something... Note that I had some problems with some versions earlier than 1.1.16 (I don't remember which) that were very sensitive to any modification of their size, and I had to leave some blank space between the last row of icons and the fg&bg colors in order to get it to work. -Raphael
Re: An experiment (was Re: Move help menu item...)
I'll try your technique but shouldn't the toolbox be coded so that all parts are visible all the time? End users are going to be frightned if they resize the toolbox using the corner of the window like they would with anything else and parts start dissappearing. To make matters worse, I messed up the toolbox and now it is messed every time GIMP starts. I hope this is corrected before the next stable release. (or the feature is disabled, locking the toolbox down to a size known to work) Ideally the toolbox should be re-sizable but only to sizes that show all components. -- Jon Winters http://www.obscurasite.com/ OpenVerse http://www.openverse.org/
Re: An experiment (was Re: Move help menu item...)
On Thu, 10 Feb 2000, "Daniele Medri" <[EMAIL PROTECTED]> wrote: > about Toolbox resizeble. > > Flexibility is ok.. but some time create problems. > Why don't set fixed sizes x*y to cover all the dimension of toolbar? > This could be usefull to have right dimension and good rappresentation. Unfortunately, this is not so simple. Constraining the dimensions of a window requires some cooperation between the application and the window manager. Under X, you cannot simply tell the WM that some fixed sizes should be allowed for your window but not some others. All non-broken window managers accept the following XSizeHints: - minimum width and height - maximum width and height - size increment for width and height - minimum aspect ratio - maximum aspect ratio That's it. You cannot specify a list of allowed sizes. You could try to get close to that by specifying a size increment that is a multiple of the size of the icons and by setting a minimum value for the width of the window. But that would not help: if you set the minimum width to 30 pixels or so, then the menu is not usable. If you set the minimum width to something larger, then the menu may be usable but you are preventing some users from using their favorite layout (it is very useful to have a tall and narrow toolbox on the edge of the screeen). -Raphael
Re: An experiment (was Re: Move help menu item...)
> Here is an interesting experiment for those who do not understand > what the problem is with the "Help" item in the toolbox: > - start Gimp > - resize the toolbox so that all tools are on a single column > (approx. 30 x 750 pixels) > - try to open a new image, or to do anything useful about Toolbox resizeble. Flexibility is ok.. but some time create problems. Why don't set fixed sizes x*y to cover all the dimension of toolbar? This could be usefull to have right dimension and good rappresentation. Let's me know what do you think about. Daniele Medri Italian Language Mantainer ErLug - http://erlug.linux.it/
An experiment (was Re: Move help menu item...)
Here is an interesting experiment for those who do not understand what the problem is with the "Help" item in the toolbox: - start Gimp - resize the toolbox so that all tools are on a single column (approx. 30 x 750 pixels) - try to open a new image, or to do anything useful The problem is that Gtk draws the "right" menu items on top of evetything else. So in this case the help item occupies all the space available and it is not possible to access "Xtns" or even "File". And if your window manager does not put decorations on the toolbox, then you cannot even quit the Gimp without resizing it first. So the users who prefer the thin and tall toolbox will have some problems with the help menu. I just discussed that with a colleague who suggested that the menu bar should not be part of the resizable toolbox because the two features "being able to use the menu" and "being able to resize to toolbox" are simply incompatible with each other (in some cases). There are several solutions to that: 1. Use WM hints to ensure that the toolbox has a minimum width. This is a bad solution (IMHO) because it would prevent some users from using their favorite layout and it is hard to take font sizes into account. 2. Try to take corrective measures in the Gimp when it detects that the menu bar is too narrow (as I described in my previous mail). Unfortunately, in the extreme case of a single tall column, only the "File" menu would be visible. 3. Make it possible to split the toolbox in several independent windows (menu, tools, colors & stuff), or at least make it possible to detach the menu bar. 4. Use some tricks in Gtk to make sure that the full menu bar pops out as soon as the mouse passes over the visible menu area. The menu would be extended out of the toolbox window and would have the minimum size necessary so that all items are visible. I think that solutions 3 or 4 would be the best long-term solutions, but I doubt that we could have them in the next stable release. In the meantime, maybe solution 2 would be the best choice. -Raphael
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: Move help menu item
On Wed, Feb 09, 2000 at 09:55:26PM -0700, Michael J. Hammel wrote: > He sort of said so, but it wasn't clear to me at first either. The problem > is that with the Toolbox squeezed in tight horizontally, the Help menu's > text button can be squeezed off the right side. His way, that button is > butted up against the other menus, so there's a better chance it will at > least be partially seen (and thus, accessible). Ah, OK, I was even LESS clear than I thought :( The HELP menu is always shown in the current system, which would be great if that didn't mean that you probably can't open Xtns, or in extreme cases even File, which are FEATURES, whereas Help is just that. Help. It literally draws "Help" over the top of File/ Xtns because GTK+ doesn't consider the case where "Right most" conflicts with "Last from left". We cannot effectively fix this in GTK+ now so we have to either say: "Well, sometimes all the user can do is read help, better make the first item in Help Contents 'Hey, where did the menus go?'" That's the current way Gimp works. OR "Well usually everything will fit (*) but when it doesn't Help is the first to go, because there are plenty of other ways to get Help, such as Help buttons and F1 context help". This is what will happen if I move Help to last from the left. (*) Much more will fit in this case, due a GTK+ quirk, as I showed in my diagram, you can often write "File Xtns Hel" where only "File Help" would fit before. For me, that's reason enough to want this changed. Nick.
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
Thus spoke Marc Lehmann > a) what does HCI mean? ;) Human/Computer interfaces, I think. But I've been wrong before. > b) I always see programs do it the way gimp does it, so there must be >something about it Its sort of a defacto standard (there are probably some style guides that say to do it this way - Motif's for example), though I'm not sure if there is anything that says this configuration is optimal for some reason. > c) you gave _no_ reason why? He sort of said so, but it wasn't clear to me at first either. The problem is that with the Toolbox squeezed in tight horizontally, the Help menu's text button can be squeezed off the right side. His way, that button is butted up against the other menus, so there's a better chance it will at least be partially seen (and thus, accessible). I can see the reasoning for the change, but I couldn't decide which way might be better. The current way is standard, but Gimp is a bit unusual in the fact that it's toolbox is so thin *and* has a menu bar. Often, thin main displays don't have those menus. The menus are provided in some other fashion. In any case, this situation isn't covered very well by current style guides. At least not to my knowledge. > > 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. I believe the main reason would be to make sure the Help menu is accessible from the Toolbox even with a very thin configuration. My opinion might be to move the Help menu into the File menu to make sure it's always accessible. But this might not make much more sense than having it squeezed out to the right. Hard to say which way to go with it. I just had a thought - maybe a scroll out menubar (ie to the right or left), like the iconic menus you get with Photoshop, might help. Then you just need the word "Menus" at the top. Not sure how this would be implemented, though. I don't think there is a stock widget for such things in Gtk. And hiding menus within menus might not help either. Anyway, it was just a thought. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- I might be a butterfly, dreaming I'm a man writing down my thoughts. - unknown
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 | |
