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
Some update to gimp sources
Hello all,
I just installed GIMP on my station, and I tried to make it save JPEGs
exactly as saved by IJG's software cjpeg. For that, I needed to strip the
comment field, because it was stored, even if it was the empty string. I
have fixed that problem with a small change.
I also tried to compile plug-ins/common/jpeg.c having GIMP_HAVE_PARASITES
#undefined. I could't because there was a section in source that was not
guarded by #ifdef GIMP_HAVE_PARASITES / #endif. I fixed that too.
It is the very first time when I try to send a patch to some GNU software,
so I don't know exactly how to do it. I sent this message to this List
now; if there is another, better way to contribute to contribute to GIMP,
I would like to know about it :-)
Please reply with Cc: [EMAIL PROTECTED], as I am not subscribed to the
GIMP Developer List. Thank you.
Cosmin
Here is my patch:
*** plug-ins/common/jpeg.c~ Tue Feb 8 12:37:36 2000
--- plug-ins/common/jpeg.c Fri Feb 11 01:46:22 2000
***
*** 1043,1049
/* pw - Last of all, attach the parasites (couldn't do it earlier -
there was no image. */
!
if (!preview)
{
if (comment_parasite)
--- 1043,1050
/* pw - Last of all, attach the parasites (couldn't do it earlier -
there was no image. */
!
! #ifdef GIMP_HAVE_PARASITES
if (!preview)
{
if (comment_parasite)
***
*** 1057,1062
--- 1058,1064
parasite_free (vals_parasite);
}
}
+ #endif /* GIMP_HAVE_PARASITES */
return image_ID;
}
***
*** 1382,1388
jpeg_start_compress (&cinfo, TRUE);
/* Step 4.1: Write the comment out - pw */
! if (image_comment)
{
jpeg_write_marker (&cinfo,
JPEG_COM,
--- 1384,1390
jpeg_start_compress (&cinfo, TRUE);
/* Step 4.1: Write the comment out - pw */
! if (image_comment && *image_comment)
{
jpeg_write_marker (&cinfo,
JPEG_COM,
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: gimp && i18n == segfault
On Wed, Feb 09, 2000 at 08:59:43PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I haven't beeen able to reproduce the problem, so I depend on more You recent patch completely fixes the problem for me. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
loading EPS files
Hi,
One problem that people mention on comp.graphics.app.gimp quite
regularly is that gimp says "load failed" on some EPS files.
This happens when the EPS file doesn't have a "showpage" command on
the end of it.
Actually, EPS files probably shouldn't use an explicit showpage, since
they're supposed to be embedded. But users like to be able to just
"lpr foo.eps" and have some output generated, and Adobe's Encapsulated
PostScript File Format Specification (version 3.0, 1 May 1992) says
that showpage is allowed (see page 10, section "Redefining showpage").
So in a bid to reduce the number of confused users, I think gimp
should continue to produce EPS files with a showpage at the end (and
rely on the embedding application to correctly define away showpage).
However, this still leaves the question of how to correctly load an
EPS file. Currently, we just present the file to gs pretty much
verbatim (ie, with no embedding). This works only for EPS files that
have an explicit showpage in them. Some don't, eg those produced by
Aldus Freehand 8 on Mac.
The correct way to get gs to render the EPS file is to provide it with
a prologue, the file itself, then finally an epilogue.
The reccommended code (again from Adobe's EPS standard, pg 17), is:
1 /b4_inc_state save def
2 /dict_count countdictstact def
3 /op_count count 1 sub def
4 userdict begin
5 /showpage { } def
6 0 setgray 0 setlinecap
7 1 setlinewidth 0 setlinejoin
8 10 setmiterlimit [ ] 0 setdash newpath
9 /languagelevel where
10 {pop languagelevel
11 1 ne
12 {false setstrokeadjust false setoverprint
13 } if
14 } if
15
16 count op_count sub {pop} repeat
17 countdictstack dict_count sub {end} repeat
18 b4_Inc_state restore
Line 1 saves the memory arena, so it can be later restored by line
18. We don't need this, since we don't need to do further processing
after the EPS file.
Lines 2, 3 save the stack sizes for operand and dictionary stacks, and
lines 16 and 17 then pop any extra crap the EPS left lying around on
those stacks. Again, we don't need that, but could be vulnerable to
malicious EPS files that deliberately popped more than they push. Not
much we can do about that, short of starting with an empty stack.
Line 4 makes sure the EPS file puts any temporary defs into the user
dictionary, rather than any application one in use. We should
probably do this, not so much to protect our dictionary (we don't
care if it gets trashed) but more so that the topmost dictionary is
large enough for the EPS file's use.
Line 5 redefines showpage to be harmless, so the EPS cannot output
stuff at inopportune moments.
Lines 6 to 8 restore the graphics state to the default. gs should
initialise to this anyway, so we don't need this. Lines 9 to 14 to
the same for portions of the graphics state only present in PostScript
level 2 interpreters. Note that "languagelevel" is itself a level 2
feature, hence the rather convoluted way of using it.
In addition to this, we need to add:
4.5 /saved-showpage /showpage where pop /showpage get def
to squirrel away a safe version of showpage before blowing it way,
and:
19 saved-showpage
to actually print the EPS out. This last solves the problem with EPS
files not loading correctly. (Hmm, actually, might need to put the
saved-showpage in a fresh dictionary to make sure that malicious EPS
code can't redefine saved-showpage).
Now, the only question remains how to add this harness code around the
EPS we want to load. The simplest is just to copy the EPS to a
temporary location, sticking the prologue and epilogue on as we go.
This is tedious, since people often want to load large bits of
PostScript, and we don't want the overhead (in terms of both time and
space) of copying the thing.
Luckily, gs allows multiple files to be listed on the command line.
So, where's a good place to put a couple of plugin-specific data
files, namely: eps-loader-prologue.ps and eps-loader-epilogue.ps ?
Austin
(phew)
Re: Toolbox layout and Help menu
What about how the netscape tool thingie works when it is detached from the browser window? Right mouse clicking on it gets a small menu: Vertical, Horizontal, etc. -- Jon Winters http://www.obscurasite.com/ OpenVerse http://www.openverse.org/
Re: loading EPS files
On Thu, Feb 10, 2000 at 09:55:19PM +0100, Peter Kirchgessner wrote: > How about hard-coding it into the plug-in and creating temporary files > on runtime that are passed to gs ? Even given that we have a secure place to write temporary files (in the user's private .gimp directory probably .gimp/tmp/ by default) this sounds like an unnecessary and dangerous mechanism for something we could just stick in .../share/gimp/somewhere and forget forever. Also, if (for some crazy reason) there is a local benefit in using a different prelude and conclusion then it's easy to fix them, no? Nick.
Re: loading EPS files
Austin Donnelly wrote: > The correct way to get gs to render the EPS file is to provide it with > a prologue, the file itself, then finally an epilogue. How about hard-coding it into the plug-in and creating temporary files on runtime that are passed to gs ? --Peter -- Peter Kirchgessner WWW:http://www.kirchgessner.net e-mail: [EMAIL PROTECTED]
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: Toolbox layout and Help menu
On Thu, Feb 10, 2000 at 12:51:20PM -0600, Jon Winters wrote: > What about how the netscape tool thingie works when it is detached > from the browser window? > > Right mouse clicking on it gets a small menu: Vertical, Horizontal, > etc. Yes! When you resize the netscape toolbar window, it is just cropped. Since I only use navigator, I stick the cropped toolbar in the top left, like this: http://www.aceldama.com/~tomr/wx/desktop.png (ok, so you can't tell it's been resized because it's obscured by the GNOME panel ... but you get the picture.) Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
anyone else submitting for LinuxWorld San Jose?
I wasn't sure if I was going to go to LinuxWorld in San Jose, but thought I'd check if anyone else is submitting a paper for a talk or class there. If so, I won't bother. If not, I can try to give another talk there. Doesn't hurt to keep spreading the word, I guess. I'm only asking now because apparently the deadline for paper submission is the end of the month (man, thats a long lead time!). Not that I have any idea what I'd talk about yet. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Success is never hard won. It is hard achieved. -- Michael J. Hammel
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: CMYK when?
On 2/9/2000 16:47, Robert L Krawitz at [EMAIL PROTECTED] wrote: > CMYK is a bit of an oddball subject. Partly this is because there are > so many variants (CMY, CMYK, CcMmYK, CcMmYy, CcMmYyK), and partly > because (to the best of my knowledge) this color space is really only > useful in the context of specific output devices, which is what the > print plugin deals with. > > What specifically would your friend like? Ok, I asked my friend for more details, and here is what he said: "My main concern is support for TIFF images saved in CMYK format Our advertising agency works in this format, and currently I have to ; get the image, convert using a corel product from CMYK to RGB, play with an image in the Gimp, convert back through the corel program and send it back, with image quality loss every step Of course this is probably going to necessitate a major change in the core, because Gimp currently works only with RGB colour palettes..." I'm sure others have similar concerns/wishes so it's good to pass all this on. Hope we can see something soon...1.3 maybe? -- __ _ Carl B. Constantine / / (_)__ __ __ [EMAIL PROTECTED] / /__/ / _ \/ // /\ \/ / (2.2.14)http://www.pobox.com/~macman //_/_//_/\_ _/ /_/\_\ Stormix 2000 PGP key available on request VLUG - Victoria Linux Users GroupICQ: 26351441
Re: Toolbox layout and Help menu (again)
Just to clarify, in my prev msg when refering to the selectors I was refering to the pattern/gradient/brush one, not the [fore|back]ground color one :) Regards, alan -- Arcterex -=|=- [EMAIL PROTECTED] -=|=- http://arcterex.ufies.org '... I was worried they were going to say "you don't have enough LSD in your system to do UNIX programming."' -- Paul Tomblin in a.s.r
Re: Toolbox layout and Help menu
> On a related subject, I want to express that I'm not very content with the > latest changes to the toolbox since it is now impossible to have a > horizontal toolbox with the colorselectors at the right side. > The default setup we shipped with until now was never intended to be a > solution, since having 3 columns of icons with the selectors packed to the > right wastes a lot of space. So this setup was more or less an accident. > > IMHO there are only two useful setups: One is to have the toolbox vertically > layed out with the tools in 3 columns and the selectors below. Alteratively > you could (can't anymore) lay it out horizontally with 2 rows of tools and > the selectors placed to the right. I know the old setup was broken from the > beginning, but the recent changes IMHO render the whole idea of having a > configurable toolbar useless. > > I'd vote for the following solution: Completely get rid of the interactive > resizing (since it obviously can't be fixed to work correctly) and offer > two alternative layouts (as described above) which are switchable from the > preferences dialog. The horizontal layout would have a Help menu and probably > even a Dialogs menu, while the vertical layout would add these as entries to > the File menu (or probably Xtns for the Help menu). I wouldn't mind seeing an option to use or not use the selectors. When I'm using the gimp (and I am not sure if I'm alone here or not) I have the brushes/gradients/patterns dialoge open if I am using them a lot, and having the selectors shown at all sometimes is a waste. From what I can see, they do is provide a) a visual cue as to the current selections and b) a quick way to open up the dialogs correct? Well those things I can see from the open dialoge windows anyway. What would be more useful for me would be a mini-popup window (similar to the nav window in the btm right of the image window) that pops up, lets you select, and when you've selected it dissapears. This would, IMHO, save desktop space with the toolbar, and make the selectors a lot more useful. Giving people the option to use the selectors at all might be another thing worth considering. I must agree though (back on the toolbar resize thing) that once you find something you like, you don't change it around a lot. My $0.02, take it for what it's worth :) alan -- Arcterex -=|=- [EMAIL PROTECTED] -=|=- http://arcterex.ufies.org '... I was worried they were going to say "you don't have enough LSD in your system to do UNIX programming."' -- Paul Tomblin in a.s.r
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: loading EPS files
Austin Donnelly wrote: > > [ snip lines which show that you definitely know much more about eps > than I do ;-) ] > > So, where's a good place to put a couple of plugin-specific data > files, namely: eps-loader-prologue.ps and eps-loader-epilogue.ps ? All other plugins with need auxilliary files have their own directories. bye, --Mitch
Toolbox layout and Help menu
Hi, Marc wrote: > 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. Since all GNOME apps have the help menu rightmost but not seperated from the other menus, we wouldn't be the only app that does it this way... On a related subject, I want to express that I'm not very content with the latest changes to the toolbox since it is now impossible to have a horizontal toolbox with the colorselectors at the right side. The default setup we shipped with until now was never intended to be a solution, since having 3 columns of icons with the selectors packed to the right wastes a lot of space. So this setup was more or less an accident. IMHO there are only two useful setups: One is to have the toolbox vertically layed out with the tools in 3 columns and the selectors below. Alteratively you could (can't anymore) lay it out horizontally with 2 rows of tools and the selectors placed to the right. I know the old setup was broken from the beginning, but the recent changes IMHO render the whole idea of having a configurable toolbar useless. I'd vote for the following solution: Completely get rid of the interactive resizing (since it obviously can't be fixed to work correctly) and offer two alternative layouts (as described above) which are switchable from the preferences dialog. The horizontal layout would have a Help menu and probably even a Dialogs menu, while the vertical layout would add these as entries to the File menu (or probably Xtns for the Help menu). I think it should be possible to switch the layout on the fly by providing the necessary containers and reparent the contents between them, but if it turns out to be undoable, I guess users could even live with the need to restart The GIMP for the change to take place. From my experience you don't change the layout too often once you've found your favorite. Salut, Sven
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.
