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 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...)
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...)
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
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: 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/
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...)
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 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 fgbg 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 fgbg colors in order to get it to work. -Raphael
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 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: 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
