Re: [Gimp-developer] Console window on Win32
Sven Neumann writes: > Almost all of the messages that cause this problem don't come from the > GIMP application. They are created by libraries that we are using and > these libaries aren't necessarily using g_print() and g_printerr(). Nope, you have it backwards. 3rd-party libraries who write to stdout directly don't cause them. > Also I don't see why we should be redirecting stdout and stderr. > Everything that shows up there is strictly just for the eyes of > developers. Some clarification here: The GIMP executable is linked as a "GUI" application. This means that it doesn't have any console window when it starts. stdout and stderr are not connected to anything. Writing to them doesn't go anywhere, and certainly doesn't open a console window for the application. It's the g_print() etc functions that explicitly open a new console window if stdout (or stderr) isn't connected to a valid file handle. It would be possible to make it impossible to close the console window that GLib opens, by removing the close button from it. Then users would know just to minimize it if they aren't interested in the messages. See my last comment in bug #141102. > We use g_message() for all messages that are meant to be > seen by users. Such messages then are processed by the following logic: > > If GIMP was started with the --console-messages command-line > option, the messages go the console (stdout iirc). Hmm, if most GIMP users on X11 start GIMP through some window manager whose stdout isn't visible, is that option then really supposed to mean "don't show messages"? I guess there is a mismatch in the ways of thinking here: GIMP thinks that writing to stdout means the output will mostly go somewhere where the user doens't see it, unless he explicitly does something unusual (starts GIMP from the command line). The Win32 code in GLib again thinks that g_print() etc messages are *important*, and supposed to be shown to the user in some way, even opening a new console window if there isn't one already. If the user wants to redirect stdout and stderr (to NUL: or a file), he can do it from the command line. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fonts
Nathan Summers schrieb: On Fri, 10 Sep 2004 10:47:52 -0700, William Skaggs <[EMAIL PROTECTED]> wrote: 3) How do you add fonts in Windows, and what types of fonts can GIMP use there? The easiest way is to drag the file onto the Fonts directory and let the shell do its magic. Unless you've done something creative, it's probably in its default location of C:\windows\fonts or C:\winnt\fonts. Sometimes double-clicking on a font will install it as well as display it; sometimes it only displays it. I don't know what the pattern is. Fonts files that can be installed have an "Install" entry in their context menu, too. Additionally, copy&paste of fonts files works as well. I would imagine that GIMP can use any type of font on Windows that FreeType can handle, although figuring out how to install fonts that Windows can't handle natively is left as an exercise for the reader. I hope that the docs will describe that arbitrary other font directories can be added in GIMP's preferences. HTH, Michael -- The GIMP > http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Sodipodi > http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fonts
On Fri, 10 Sep 2004 10:47:52 -0700, William Skaggs <[EMAIL PROTECTED]> wrote: > 3) How do you add fonts in Windows, and what types of fonts can GIMP use > there? The easiest way is to drag the file onto the Fonts directory and let the shell do its magic. Unless you've done something creative, it's probably in its default location of C:\windows\fonts or C:\winnt\fonts. Sometimes double-clicking on a font will install it as well as display it; sometimes it only displays it. I don't know what the pattern is. I would imagine that GIMP can use any type of font on Windows that FreeType can handle, although figuring out how to install fonts that Windows can't handle natively is left as an exercise for the reader. The support Windows has varies by version; all that GIMP runs on support at least TrueType, Windows FON, and Windows FNT. 2000 and later support Type 1 and OpenType. ME supports OpenType. I don't know about Type 1. To install a Type 1 file, you need both the .pfb and .pfm. Drag the one that gets an icon into the fonts folder. The other one doesn't strictly need to be in the same directory when you drag the file, since it uses some kind of search algorithm to find it if it's not, but I'm not sure what the algorithm is, and only know that it does this because I've accidentally put the other file in the wrong directory. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On 11 Sep 2004 01:47:03 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Kevin Cozens <[EMAIL PROTECTED]> writes: > > > Just another thought. What about adding some sort of "lock" icon > > beside the X&Y values that, when set, would prevent changes in the > > units from affecting the X&Y values. > > I think that such a lock would add unnecessary complexity to the > dialog. It will be easier for our users to understand how the UI > works if we don't add another button. True, but then again, it would be easier still to understand how the dialog works if it did nothing at all! Engineering always involves trade-offs between competing goals. I find a slight increase in learning how a dialog works to be an acceptable trade-off for being able toenter the size you want without facing frustratingly broken behavior. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On Fri, 10 Sep 2004 18:41:07 -0400, Kevin Cozens <[EMAIL PROTECTED]> wrote: > Joao S. O. Bueno Calligaris wrote: > > Just another thought. What about adding some sort of "lock" icon beside > the X&Y values that, when set, would prevent changes in the units from > affecting the X&Y values. This would be similar to how we have the link > icon that locks the X&Y together to maintain the aspect ratio when > changing one of the values. > > An alternative would be to have a link icon between the unit box and the > X&Y values. When the chain is complete, it will affect the X&Y value. > When the chain is broken, you can change the units without affecting X&Y. This seems to me like the best idea so far. Let's develop it some more. Rockwalrus > Packet:[EMAIL PROTECTED] Hmm, I can't say that I can make head or tail of this. Do I need to rot13 it? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On 10 Sep 2004 13:53:38 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Dave Neary <[EMAIL PROTECTED]> writes: > > > You forgot a third solution, proposed in bugzilla, which you said yourself > > wouldn't be too bad [...] > > That provides the affordance for people who want to create images by unit, and > > also allows us to keep the current behaviour for unit changing without > > confusing people too much. > > Apart from the fact that it looks like crap, I'd rather use a dialog that's somewhat less enjoyable asthetically than enjoy a dialog that's somewhat less usable by humans. I don't think I'm unique in that opinion, although I can point you to some apps whose developers obviously disagree. Trying to get anything accomplished with them is almost physically painful, but look! Pretty buttons! > it also looks different > than in all other places where lengths are being entered. If the size > entry looks different than other size entries, how is the user > supposed to understand that it behaves like the others? Perhaps they won't. Perhaps they won't need to. You can't say that it would be particularly surprising to discover it does, or unreasonable to try it out if you need that feature. At any rate, once they learn the first time that it works that way, they will remember it and be able to use it, since unlike the way that the dialog currently works, being able to consistantly use that behavior doesn't require working against the fundamentals of the way our brain is designed. At a more technical level, what I mean by that is that cerebellum is quite capable of finding the nice affordable button with the current unit on it with rather minimal input from the cerebrium; at any rate, no more input than it takes to find the units box normally. It's true that it has to look around a bit longer to find it, but it's even capable of optimizing that to a surprising degree. The reason for the difference is that "convert these numbers to a different unit" is not a task that has years of convention to unlearn, while "fill in the desired information" is. > And why do the other entries look different then? Ony the terminally nitpicky would even notice. The terminally nitpicky probably have bigger fish to fry. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On 10 Sep 2004 11:53:17 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Nathan Summers <[EMAIL PROTECTED]> writes: > > > Consistancy is a good thing, of course, and in all the other places > > where units are used, this is a very nice behavior to have. But the > > new image dialog is different in that there really are no > > pre-existing sizes or units, really. You are entering new ones from > > scratch. > > I am sorry but I have to disagree with you here. You are seldomly > entering new dimensions from scratch in this dialog. What you do is > you start with the last values or the ones from the image you opened > the dialog from. Or you are using a template. So what you usually do > is to accept or modify the values that are present already. I don't > think that entering new dimensions completely from scratch is a common > use case. It's true that you can get sizes from the last image or templates, but obviously you don't use the GIMP for the same tasks that I do. :) I frequently enter a new size from scratch. Apparently the reporter does as well. It's certainly not an unusual thing to do. > > It's not absurd to think of a case where having unit conversion in > > the dialog box is useful, but most of the time it's not a desirable > > behavior. Actually, that's being polite. In reality, it's the kind > > of frustrating, annoying thing that I make fun of the stupidity of > > the developers when I run across in propriatary code. > > Since you admit that it is useful, I don't understand why you don't > want to learn that you need to select the unit first. Seems like you > behave like the kind of frustrating, annoying users who aren't willing > to learn. The current behavior is wrong for the exact same reason that it is wrong to put a handle on a a door that is opened by pushing. Even if you mark PUSH on the door in big letters, and it's a door you use frequently, you will still ocassionally find yourself straining to pull the door open, simply because even though the door is documented properly, it's afforded incorrectly. It's not a matter of learning! It's a matter of the person who put the handle on in the first place being ignorant of human nature. The brain just is not very good at internalizing the rule "You pull doors which have handles except for this ONE SPECIAL DOOR which in defiance to both convention and practical physical considerations has a pull handle even though it can only be opened by pushing." It tends to spontaneously forget it, especially when you are paying attention to higher-level tasks, instead of focusing on the menial, uninteresting, and usually trivial task of door-opening. In terms of hardware, routine low-level physical tasks are generally handled by the cerebellum and brain stem. These devices are capable of rather amazing feats of systems control, but are limited to relatively simple programming. They are quite simply incapable of learning rules with ONE SPECIAL DOOR exceptions. This is a hardware limitation. This restriction cannot be eliminated through practice, training, or having a good attitude. On top of this basic, almost fixed-function hardware, we have the cerebrium and neocortex, which is capible of learning more numerous and more complicated rules such as "for this ONE SPECIAL DOOR, you need to push instead of pull." When you think of the amount of signal processing and storage this involves, this is really quite extraordinary, and yet we take it for granted. In this case, humans are able to open a misafforded door because the cerebrium overrides the cerebellum's natural behavior. When the intentionality of the individual is such that a door opening is necessary (the cerebellum is smart enough to deduce this without input from the cerebrium) and it perceives that the door affords pulling, the cerebellum decides to run the door-pulling program. However, in this case, it is overridden and given instead the instruction to run the push program. It should be noted that the cerebrium is incapable of meaningful systems control without the use of the cerebellum. While it is true that it can do systems control directly, it is not nearly at the same rate of speed that the more specialized hardware is capable of doing. Without the cerebellum, the cerebrium is incapible of processing incoming signals and sending outgoing ones fast enough for even the most basic physical tasks such as walking. The inherent problem with the misafforded door is that in order for someone to be able to go through it, that individual's cerebrium must override the cerebellum every time. If, for some reason, it does not, such as if the person has the audacity to be thinking of something other than door-traversal, the cerebellum will run the program it thinks is most appropriate, and the individual attempts to pull the push door. When the cerebellum notes that it is unsuccessful at its attempts to open the door, it triggers an interrupt, notifying the cerebrium t
Re: [Gimp-developer] New Image dialog usability bug
Hi, Kevin Cozens <[EMAIL PROTECTED]> writes: > Just another thought. What about adding some sort of "lock" icon > beside the X&Y values that, when set, would prevent changes in the > units from affecting the X&Y values. This would be similar to how we > have the link icon that locks the X&Y together to maintain the aspect > ratio when changing one of the values. > > An alternative would be to have a link icon between the unit box and > the X&Y values. When the chain is complete, it will affect the X&Y > value. When the chain is broken, you can change the units without > affecting X&Y. I think that such a lock would add unnecessary complexity to the dialog. It will be easier for our users to understand how the UI works if we don't add another button. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Joao S. O. Bueno Calligaris wrote: Ok, just to drop my 2 cents in here: I think that changing the units on the new image dialog should not convert the numbers typed in, unless if explicitly desired. Just another thought. What about adding some sort of "lock" icon beside the X&Y values that, when set, would prevent changes in the units from affecting the X&Y values. This would be similar to how we have the link icon that locks the X&Y together to maintain the aspect ratio when changing one of the values. An alternative would be to have a link icon between the unit box and the X&Y values. When the chain is complete, it will affect the X&Y value. When the chain is broken, you can change the units without affecting X&Y. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On Thu, 2004-09-09 at 20:09 -0400, Nathan Summers wrote: > Sven suggested that I direct the mailing list's attention to > http://bugzilla.gnome.org/show_bug.cgi?id=152224 to see if there were > any ideas about the best way to go about fixing it. Basically, if you > enter in that you want a 200 mm x 100 mm image using the order that > makes sense (top to bottom, left to right), you enter 200 in width, > 100 in height, and then mm for the units. Unfortunately, if you were > to do that, you would end up with a 17 x 8.5 mm image, since changing > the units causes the width and height to change as well. > > Consistancy is a good thing, of course, and in all the other places > where units are used, this is a very nice behavior to have. But the > new image dialog is different in that there really are no > pre-existing sizes or units, really. You are entering new ones from > scratch. > > It's not absurd to think of a case where having unit conversion in the > dialog box is useful, but most of the time it's not a desirable > behavior. Actually, that's being polite. In reality, it's the kind > of frustrating, annoying thing that I make fun of the stupidity of the > developers when I run across in propriatary code. > It's an interesting task that indeed exposes a problem of the current UI. I have one usage pattern that would suffer if we implement the behavior you propose though: 1) Select A4 from templates. Millimeters is selected as a unit (makes sense). 2) Change to pixels as units to see how much that is really (me no maths please) 3) Oops, 210x297 pixels? The change you propose does make sense in the workflow you propose. The above + consistency with how units behave elsewhere in the interface speak against the change. -- Jakub Steiner <[EMAIL PROTECTED]> Novell, Inc. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fonts
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > I would like to add some information about fonts to gimp-help-2, You have read http://gimp.org/unix/fonts.html, haven't you? I would also suggest not to duplicate that information in gimp-help-2 but simply to link to this page. If there's info missing, it should probably be added there. > Here is what I know: In Linux, you can add a Truetype or Freetype > font by putting it in your ~/.fonts directory or your > .gimp-2.0/fonts directory. I am sorry, but what is a FreeType font? You probably mean OpenType?! > Here is what I would like to know: > > 1) Can you use other types of fonts in GIMP? Are there any types > for which special things need to be done? You can use any font that FreeType2 can handle. By default, FreeType2 supports the following font formats: * TrueType fonts (and collections) * Type 1 fonts * CID-keyed Type 1 fonts * CFF fonts * OpenType fonts (both TrueType and CFF variants) * SFNT-based bitmap fonts * X11 PCF fonts * Windows FNT fonts * BDF fonts (including anti-aliased ones) * PFR fonts * Type42 fonts (limited support) (see http://www.freetype.org/freetype2/index.html#features). > 3) How do you add fonts in Windows, and what types of fonts can GIMP > use there? The same code is used to render fonts on Windows so the same information applies here. Actually we should move http://gimp.org/unix/fonts.html out of the unix directory. > 4) If you want to create special characters (i.e., non-ascii) with > the Text tool, what is the right (and/or easiest) way to do it? Use a character picker tool like gucharmap. gucharmap can also install a GTK+ input module so it is directly available from the right-click menu in the GIMP text editor. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] fonts
Hi, I would like to add some information about fonts to gimp-help-2, but I'm hampered by lack of knowledge. Here is what I know: In Linux, you can add a Truetype or Freetype font by putting it in your ~/.fonts directory or your .gimp-2.0/fonts directory. Here is what I would like to know: 1) Can you use other types of fonts in GIMP? Are there any types for which special things need to be done? 2) Are there any Linux setups on which GIMP 2.0 or GIMP 2.1 runs but where you need to do things differently? 3) How do you add fonts in Windows, and what types of fonts can GIMP use there? I know enough about the problems people have had with malformed fonts to be able to give some useful advice, I think (i.e., don't close the console window that pops up!). One more question, though: 4) If you want to create special characters (i.e., non-ascii) with the Text tool, what is the right (and/or easiest) way to do it? Thanks for any informatin, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Hi, Alif Wahid <[EMAIL PROTECTED]> writes: > > > I noticed that GIMP uses message output and debugging functions > > > provided by GLIB. So isn't it possible to fix this by just setting a > > > custom print handler using g_set_print_handler and so on? That would > > > make it portable as well. Just a suggestion anyway. Cheers. > > > > No, it is not possible to fix it this way. Messages sent via GLib are > > of course not sent to stdout/stderr. At least not by default. > > But the GLIB docs for g_set_print_handler say that "Any messages > passed to g_print() will be output via the new handler. The default > handler simply outputs the message to stdout. By providing your own > handler you can redirect the output, to a GTK+ widget or a log file > for example". It says the same for g_log functions as well. Almost all of the messages that cause this problem don't come from the GIMP application. They are created by libraries that we are using and these libaries aren't necessarily using g_print() and g_printerr(). Also I don't see why we should be redirecting stdout and stderr. Everything that shows up there is strictly just for the eyes of developers. We use g_message() for all messages that are meant to be seen by users. Such messages then are processed by the following logic: If GIMP was started with the --console-messages command-line option, the messages go the console (stdout iirc). Otherwise they are shown in the Error Console dockable. If that dockable doesn't exist, an error dialog pops up. If for whatever this isn't being successful (I can't think of reason), the message ends up on the console. So since stdout/stderr are not for the user's eyes, why are the poor GIMP users on the Win32 platform faced with it? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes: > Like we say around here, "you are doing a storm in a glass of water". > A simple and elegant solution would be to add an "auto-convert" bool > property to the widget, that is on by default. The new image dialog > would just set this "auto-convert" to false. The widget can already do that, there's no need for a new API. I was refering to Bolsh's suggestion to change the layout of the GimpSizeEntry widget. Please try to read the mails more carefully before you reply. The point here is that the unit conversion feature is very useful in the New Image dialog. I am using it almost everytime I create a new image and I would definitely be missing it a lot. So far I haven't heard any good argument for removing it except that users might be surprised the very first time they discover that it works this way. That's IMO not a valid argument to remove a very useful feature. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Ok, just to drop my 2 cents in here: I think that changing the units on the new image dialog should not convert the numbers typed in, unless if explicitly desired. On Friday 10 September 2004 09:11, Sven Neumann wrote: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > > Apart from the fact that it looks like crap, > > > > That's subjective, I don't think it does. But perhaps a mock-up > > would resolve that issue... > > I already said that the dialog design is owned by Tigert and > Jimmac. Without their approval (and mockup) there isn't going to be > any changes anyway. > > > I presumed that we would change it everywhere. There is no change > > in behaviour, merely a change in the position of the units. > > We can't do that since it would break lots of existing code. Code > that is not under our control since it lives in external plug-ins. > The only thing we could do is to write a new widget and change > hundreds of places in the GIMP source tree. Like we say around here, "you are doing a storm in a glass of water". A simple and elegant solution would be to add an "auto-convert" bool property to the widget, that is on by default. The new image dialog would just set this "auto-convert" to false. No compatibility issues. And this behavior could even be changeable as part of the preferences. (Or, in this particular instance of the widget, tehre could be put a chain link GIMP widget to the right of the entries. Maybe, the chain indicating auto-conversion could be added by default to the widget as a whole increasing the flexibility of The GIMP in tenths of dialogs. > > > Sven JS ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > > Apart from the fact that it looks like crap, > > That's subjective, I don't think it does. But perhaps a mock-up > would resolve that issue... I already said that the dialog design is owned by Tigert and Jimmac. Without their approval (and mockup) there isn't going to be any changes anyway. > I presumed that we would change it everywhere. There is no change in > behaviour, merely a change in the position of the units. We can't do that since it would break lots of existing code. Code that is not under our control since it lives in external plug-ins. The only thing we could do is to write a new widget and change hundreds of places in the GIMP source tree. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Quoting Sven Neumann <[EMAIL PROTECTED]>: > Dave Neary <[EMAIL PROTECTED]> writes: > > You forgot a third solution, proposed in bugzilla, which you said yourself > > wouldn't be too bad, and that is rearranging the frame with the units in it > to > > look like this: > > > > Units: [mm] > > Width: 210 > > Height: 297 > > Apart from the fact that it looks like crap, That's subjective, I don't think it does. But perhaps a mock-up would resolve that issue... > it also looks different > than in all other places where lengths are being entered. If the size > entry looks different than other size entries, how is the user > supposed to understand that it behaves like the others? And why do > the other entries look different then? I presumed that we would change it everywhere. There is no change in behaviour, merely a change in the position of the units. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > You forgot a third solution, proposed in bugzilla, which you said yourself > wouldn't be too bad, and that is rearranging the frame with the units in it to > look like this: > > Units: [mm] > Width: 210 > Height: 297 > > That provides the affordance for people who want to create images by unit, and > also allows us to keep the current behaviour for unit changing without > confusing people too much. > > I think that this is a reasonable way to organise things. Apart from the fact that it looks like crap, it also looks different than in all other places where lengths are being entered. If the size entry looks different than other size entries, how is the user supposed to understand that it behaves like the others? And why do the other entries look different then? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Quoting Sven Neumann <[EMAIL PROTECTED]>: > Since you admit that it is useful, I don't understand why you don't > want to learn that you need to select the unit first. Because this isn't the afforded way of doing it. We should aim for affordance where possible. If people use the width, height and unit to create 5"x3" postcards, then the way to enter "5 inches by 3 inches" should be natural. This isn't something I do a lot myself, but I accept that this might be something people want to do. > IMO there are two solutions, none of them involve any change in the > dialog layout: > > (a) Don't set a resolution on the size entry. > > (b) Explain the behaviour in the documentation, close as WONTFIX. You forgot a third solution, proposed in bugzilla, which you said yourself wouldn't be too bad, and that is rearranging the frame with the units in it to look like this: Units: [mm] Width: 210 Height: 297 That provides the affordance for people who want to create images by unit, and also allows us to keep the current behaviour for unit changing without confusing people too much. I think that this is a reasonable way to organise things. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Console window on Win32
Hi, whenever one reads some of the public forums about GIMP there's one problem on the Win32 platform that shows up over and over again: Whenever GIMP or any library that GIMP is using writes something to stdout/stderr, on Win32 a console window is opened. There is really no reason a user should ever be presented with whatever GIMP or any of it's libraries are sending to stdout/stderr. The console window alone would be annoying and useless enough but the real problem is that closing this window closes GIMP. So what the user sees is an error window with a cryptic message and if you close that window, the application is quit. It is not surprising that the casual user thinks that GIMP has just crashed. This little stupidity makes GIMP on Win32 look a lot less stable than it actually is. The problem is known for years and gets reported over and over again. Yet noone has ever done anything about it. Why is that? I don't know enough about the Win32 platform but I simply cannot imagine that there isn't a simple solution for this. Why doesn't the Win32 installer setup GIMP in a way that if it is not started from a terminal window, stdout and stderr are redirected to the digital dustbin? There got to be an equivalent to /dev/null on Win32. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Nathan Summers <[EMAIL PROTECTED]> writes: > Consistancy is a good thing, of course, and in all the other places > where units are used, this is a very nice behavior to have. But the > new image dialog is different in that there really are no > pre-existing sizes or units, really. You are entering new ones from > scratch. I am sorry but I have to disagree with you here. You are seldomly entering new dimensions from scratch in this dialog. What you do is you start with the last values or the ones from the image you opened the dialog from. Or you are using a template. So what you usually do is to accept or modify the values that are present already. I don't think that entering new dimensions completely from scratch is a common use case. > It's not absurd to think of a case where having unit conversion in > the dialog box is useful, but most of the time it's not a desirable > behavior. Actually, that's being polite. In reality, it's the kind > of frustrating, annoying thing that I make fun of the stupidity of > the developers when I run across in propriatary code. Since you admit that it is useful, I don't understand why you don't want to learn that you need to select the unit first. Seems like you behave like the kind of frustrating, annoying users who aren't willing to learn. It is certainly a desirable goal to make things intuitive but I don't think that useful features should be removed for the sake of intuitivity. I also very much doubt that users will find it intuitive if the size entry in the New Image dialog doesn't behave like other size entries. > There are a couple of ways to fix it that we've discussed on the > bugzilla. None of them are completely satisfactory. Does anyone > here have a better idea, or, if not, which of the existing solutions > do you think is best? IMO there are two solutions, none of them involve any change in the dialog layout: (a) Don't set a resolution on the size entry. Changing the unit won't affect the size then. That would IMHO be a major regression since you wouldn't any longer be able to find out how many pixels a DIN A4 paper has in 300 dpi or how large your 1600x1200 image will turn out when being printed at 100 dpi. I don't know about you but I use this feature very often and would miss it a lot. (b) Explain the behaviour in the documentation, close as WONTFIX. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
