Re: [Gimp-developer] Console window on Win32
On 09/13/04 11:04:06, Sven Neumann wrote: The messages aren't meant for user's eyes, I think I mentioned that. The messages don't make any sense for the user and should only ever seen by developers or when we ask users to start gimp from a console window and to tell us if there are messages to be seen. Doesn't it make sense to prefix Glib errors with something like: Glib Error: or System Error: or Gimp Error: (localizing just that string) and let the rest appear as-is within the error console? If you think that a certain messages should be seen by the user and not to go stderr, let us know about it. That message should then use g_message() and also needs to be localized. No, that's not exactly the case. But using stderr is a bad idea under Windows for the reasons that motivated this thread. -- Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
On 09/12/04 14:47:14, Sven Neumann wrote: Tor Lillqvist [EMAIL PROTECTED] writes: 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. There got to be a way to change this behaviour of g_print(), no? Regardless on what's done in the glib side, why not using g_set_print_handler and g_log_set_handler, as Alif Wahid suggests, to redirect the messages to the Error Console? I, for one, as a user of the Win32 version expected to find the messages there and when they were shown in a different window I wondered why. Perhaps it's also better under Linux so that the messages aren't lost if the user doesn't open gimp from a console. -- Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bicubic scaling routines in GIMP
On 08/16/04 15:23:08, Michael Thaler wrote: I looked at the GIMP source code but I could not find the relevant parts of the code. Could you please tell me in what files the relevant parts of the code are? It's possible to perform scaling by two means. If invoked from the Scale Image menu entry, the affected code is in app/paint-funcs/paint- funcs.c as Simon already pointed out. If invoked via the Scale tool, then it's the code in app/core/gimpdrawable-transform.c the one in effect. Note, however, that the code in paint-funcs.c does not implement cubic resampling when scaling down. -- Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Extra plug-ins (was: Refocus the 2nd)
On 05/21/04 01:35:49, Sven Neumann wrote: Stephan Menzel [EMAIL PROTECTED] writes: Do you think there's a chance to include refocus in the gimp release at all? snip I don't follow refocus development closely but if is actively maintained and developed outside the GIMP source tree I'd prefer to keep it that way. Simply for the sake of keeping the GIMP source tree somewhat managable. Perhaps a feasible idea is to create a set of extra plug-ins that are in a separate CVS module, similarly to what already happened to GAP, gimp-perl, gimp-help and most notably gimp-data-extras. This can make room for plug-ins that can be considered as very interesting or almost essential and can be included in distributions as a single package. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Donation for GIMP features
On 05/02/2004 02:01:37 AM, Sven Neumann wrote: (3) the windows that are below it are not hidden by the application But that's _the_ major advantage of the current user interface. It allows you to easily use GIMP together with other applications such as web browser and file managers. That's not an advantage for everyone :) Taskbar grouping doesn't help since when you click on the taskbar button what you get is a menu of windows to choose from. It reduces the cluttering of the taskbar but does not allow raising all windows at once. It does so here (using sawfish). IMO it would be a major regression if the individual GIMP windows would not any longer be accessible via the taskbar. That's the nice thing about taskbar grouping. You get a single item in the taskbar that represents the application but you can still easily access a specific GIMP window. I was referring to the behaviour under Windows XP. Taskbar grouping is not useful there since you can't still raise all windows at once. Let alone the fact that noone has yet come up with a proposal on how plug-in dialogs should be handled. Making them transient for the application window would be enough; it's not necessary for them to be inside the app window. Only windows which are permanent need to be: image windows, docks and such. However I don't know if a window in a separate process can be made transient for the application window. Probably not. But then, leaving them free is not so troublesome as long as the permanent windows are not. Eeek, reparenting :( Reparenting should IMHO be avoided. It will break code that relies on gtk_widget_get_toplevel() working properly. If that code is in the GIMP then it would have to be changed of course; reparenting is a prerequisite for WiW. I don't expect the GIMP changes to be problematic at all. With the appropriate help from gtk+ it could even be made transparent with no need to change the code. But I don't expect the gtk+ guys to be adding support for WiW, so a gimp wrapper function controlling which windows are toplevel within their big parent sounds like the reasonable approach. What worries me is the gtk+ code relying on it; that needs testing at least. I don't understand this screenshot; it seems to just add another window. What's the advantage? It has the same effect as what the Deweirdifier plug-in does: adds a background window which hides the windows below (you can, at your option, shrink it vertically if you don't want that); also, on Windows it's the only window showing up in the taskbar during normal work. The screenshot emphasizes that the windows on top of the background window are not inside it, to remark the difference with WiW; however the expected workflow is to have it maximized or otherwise so that all other windows lie inside it. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Donation for GIMP features
On 05/01/2004 07:16:32 PM, Sven Neumann wrote: There are a couple of good arguments against this feature. Basically it is agreed that WiW is a bad concept that is being dropped by all major software companies nowadays. It was only ever introduced to work around the problem that some operating systems, namely Windows, don't handle many windows very well. So we should ask ourselves why people keep asking for it. I remember people mainly giving the following reasons: (1) multiple windows clutter the taskbar (2) the application can't be minimized/maximized as a whole (3) the windows that are below it are not hidden by the application (4) the application can't be shaded (i.e. leave only the window title bar) as a whole For me there's another reason explained below. GIMP addresses these points by setting the same WM_CLASS attribute on all GIMP windows, including plug-in dialogs. This allows the window manager to group the GIMP windows. Personally I find it irritating to have so many windows open at once. In WindowMaker my only choice is to guess which of the icons is the GIMP one because it doesn't provide an icon that WindowMaker likes, so in practice I can't raise all windows at once. I also find confusing that between the image and the toolbox or the layers or the info window there can be windows from different applications. Of course a solution is to dedicate a virtual desktop only for the gimp but that's not practical sometimes. This means that GIMP only shows up as a single item in the taskbar and that all its windows can be minimized/maximized together. Most window managers on Linux support this and I heard that Windows XP does at least support the taskbar grouping. I am not sure where Mac OS X stands here. Taskbar grouping doesn't help since when you click on the taskbar button what you get is a menu of windows to choose from. It reduces the cluttering of the taskbar but does not allow raising all windows at once. There are a couple of technical arguments against the implementation of a WiW user interface. First of all, there's no support from GTK+, I'd say that first of all there's no WiW standard for window managers to comply. As a consequence, the embedded windows must be managed and decorated by the application rather than by the window manager, resulting in ugly hacks like those of kvirc and Scribus. Now this implies your argument about the lack of support from GTK+, which should act as a (sub)window manager for these reasons. Another argument is that we would certainly not want to drop the current user interface since it works well for a lot of people. So I seriously doubt that any user would object against having WiW in the preferences. the WiW feature would have to implemented transparently for the rest of the application and doing this will be very difficult. I don't think it would be so difficult actually, as it's just a matter of reparenting windows. I am making an experiment about transient windows. It is not window-in- window but uses a background window similarly to what Deweirdifier does. If it works well, maybe I can make the patch available as an attachment to bug #7379. Here's the result: http://perso.wanadoo.es/p.gimeno/temp/bgw-screenshot-1024.png (unlike http://perso.wanadoo.es/p.gimeno/temp/mdi-proposal-800.png this one is NOT a mockup but an actual screenshot) Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [META] Subject tags / List Moderation
I've seen a bunch of messages with the title Gimp 2.0 in the list which were absolutely, definitively off-topic. As a reminder, this list is intended for discussion about gimp development-related issues. Many of the discussions are kept on IRC but since not everyone is awake at all times and not everyone is on IRC this is^H^Hshould be a good means for communication between developers and perhaps to receive suggestions, feedback or casual comments by users. So please let's adopt the good habit of sticking an [OT] tag to the messages that are off-topic or go off-topic (where on-topic is more or less defined above but with a bit of relaxation). Comments about the list itself can be marked with the [META] tag as this one, though this is just my suggestion instead of common practice. Also, perhaps there is consensus on that the lists should be moderated. If so, - How many people don't agree about it being moderated? - Is there someone who volunteers to moderate the list? I'd offer myself but I'm afraid that my job won't allow me to cope with that. -- Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
Branko Collin [EMAIL PROTECTED] wrote: I got mine from http://gnuwin32.sourceforge.net/packages/libart.htm. That version is more recent, though, so I had to rename it. I don't know if that has any averse effects, but at least it allowed me to run the GIMP. Thank you very much. Now I've got it running. There are still issues but it works at least. No plug-in is loaded at all: lots of messages like this one are output to the console. C:\gimp-head-20030813\bin\gimp-1.3.exe: Unable to run Plug-In: zealouscrop.exe (C:\gimp-head-20030813\lib\gimp\1.3\plug-ins\zealouscrop.exe) Failed to execute helper program The path is correct and the executables are is there. Any ideas? Finally the mouse wheel works in Windows! Yoo-hoo! Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP HEAD Win32 binaries
Tor Lillqvist [EMAIL PROTECTED] wrote: www.gimp.org/win32/gimp-head-20030813.zip. Thank you so much! I couldn't satisfy the dependency on libart_lgpl_2-2.dll though. Any clue on where to find a working libart binary DLL? Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
