Re: [Gimp-developer] New Image dialog usability bug
On Sat, 11 Sep 2004 07:47:39 -0700, William Skaggs <[EMAIL PROTECTED]> wrote: > > Remember, even moving a menu entry to a more logical place is > annoying to many people. We don't want to offend our most > loyal customers! Of course, since this dialog is already radically different from how it looked in 2.0, making a minor redesign to it now isn't going to change how different it will appear to users switching from 2.0 in the slightest. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi Bill, William Skaggs wrote: > On this issue I think I agree with Sven that the gain of reducing > annoyance for new users does not offset the costs of (a) reducing > the consistency of size-entry areas and (b) annoying the mass of > existing users who know how it works and don't expect it to change. I'm happy to leave any decision in the hands of the people who designed the dialog. I just wanted to point out that since this is a dialog modified in 2.1, there is no mass of existing users to worry about. I was under the impression that there was one size entry widget which was included everywhere, from what Sven says this isn't the case, so perhaps the status quo is for the best. I would like to see consistency for size entries. I'd prefer them all to change, I think, but if they all stay the same that's second best. Anything else is a long way behind. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On this issue I think I agree with Sven that the gain of reducing annoyance for new users does not offset the costs of (a) reducing the consistency of size-entry areas and (b) annoying the mass of existing users who know how it works and don't expect it to change. It's especially bad to change things where people do them often and have developed habits of doing them in a certain order. Remember, even moving a menu entry to a more logical place is annoying to many people. We don't want to offend our most loyal customers! Best, -- 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] fonts
Sven Neumann writes: > The information given above may be appropriate for adding fonts to > your win32 system but it is irrelevant for GIMP on Win32. On Win32, fontconfig by default uses the Windows fonts directory, i.e. the same fonts that Windows uses itself. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
On Friday 10 September 2004 19:41, Kevin Cozens wrote: > 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. I had tought about it as well. When I said about increasing the funcionality of tens of dialogs without changing any code besides adding this chain icon to activate/deactivate unit conversion. It could be even be done in a way that, when someone would select a template, it would become locked - as it's default state on the New Image Dialog should be open. There is nothing about "impossibility" of working with templates here. There is an issue about Left to right - top down reading and inputing values into a form, or keeping a form that has one entry behaving right to left, upside down. JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Hi Tor, I've played around with the g_set_print_handler and the g_log_set_handler functions and they certainly stop the console window from coming up when I use my custom handler to redirect the message to somewhere else. So it may well be a good way to give the user an option of redirecting these stdout and/or stderr messages to somewhere totally invisible. Regards, Alif. On Sat, 11 Sep 2004 06:48:28 +, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > 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 > > -- "Heaven is the peaceful place on earth...New Zealand." -- Alif Wahid. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi jimmac, Jakub Steiner wrote: > 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. Good point - speaking for myself, what I understood was on the table was the following: Template: [A4 (300dpi)] Units: [mm] Width: [210] Height: [297] Now if I change the unit to px, the width and height will change, as you expect. However, if I am starting from the defaults: Template: [(None)] Units: [px] Width: [377] Height: [233] Now, if I want an image 130x100 mm in size, I set unit mm (changes width and height), then set the width and height I want. (forget for a moment that I could pick the template). The point is, if I want to change all 3 boxes, the one which changes the other two should be first. Otherwise I end up doing Width: [130] Height: [100] [px] (change unit to mm) Width: [45.86] Height: [35.28] [mm] and I have to change width & height again. Cheers, Dave. PS. Just for the record, I think this is a pretty superficial thing, I'm not passionnate about it either way. I can see the point of Nathan and the original bug reporter, because this has happened to me a few times too. But if the decision is "no change", well, I guess that's OK. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Hi, > 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. It's often a habitual thing for windows users, minimizing a console window that displays constant warning messages often isn't enough satisfaction for some. May be GIMP could have a preference option where the user can choose to have these g_print based messages redirected to a file using a custom print handler that gets set via g_set_print_handler(..). Regards, Alif. -- "Heaven is the peaceful place on earth...New Zealand." -- Alif Wahid. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fonts
On 11 Sep 2004 09:28:54 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > The information given above may be appropriate for adding fonts to > your win32 system but it is irrelevant for GIMP on Win32. Please read > my other mail in this very thread. That's funny. Works for me. I'd call the method I use to install fonts that I use in GIMP on Win32 very relevant. I don't do anything that is gimp-specific. Please see my other mail in this very thread. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fonts
Hi, Nathan Summers <[EMAIL PROTECTED]> writes: > > 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. The information given above may be appropriate for adding fonts to your win32 system but it is irrelevant for GIMP on Win32. Please read my other mail in this very thread. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Nathan, please try to be more concise. I am not going to read this huge amount of text which, I am afraid, will in large parts be unrelated. I think Jimmac has so far given the best argument for not changing the dialog behaviour. If we would change it, we would make it impossible to work with templates which is the key feature of this dialog. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
