Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.
... after the weekend Am 21.11.03, 07:44 -0800 schrieb Daniel Rogers: | This would be fine for unix based systems too. Are there any plans to | create an system interface for X to plug-in an CMM? | Do You know someone allready working on this? yeah, I am working on this. Hopefully, I will be going to talk to the X.org and freedesktop people in December. Staying interessted. | Can You provide more informations about the current state of CMS in GEGL? Ok, so I avoided the question. Do you want me to discuss technical details of how I think colormanagement will work in gegl? Yes, I am interessted in how gegl handles color space conversions for instance. The more interessting question is how it is planed to get an interface for tools and plug-ins to handle the same command to all color spaces. For instance brighten an image affects all channels in RGB in Lab only the L (Lightness) channel. By the way is gegl C++ and can it use templates to have only one function for all color depths in common? Sorry if I mix here something. Maybe You like to continue the discussion in the gegl list, so I will need to subscribe. regards Kai-Uwe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] What makes the GIMP toolbox special?
Following the discussion in bug #115092 and according to Sven's suggestion, I am moving a part of the discussion here: what is special about the GIMP toolbox, from a user's point of view? What makes it different from the other docks? There are some subtle differences that are internal and IMHO not important from the user's point of view: the code currently keeps some references to that window because it contains the brush, pattern, gradient and color indicators but these will probably change or go away soon. Also, its title is handled differently from the other dock windows and there are other internal differences due to the fact that the code of the GIMP must have at least one window to start with. But if we look at the remaining differences (again, from the user's point of view, not from the code point of view), what is left? - The toolbox has a menu bar. - The toolbox contains the buttons for switching tools. Apart from these differences, I consider the toolbox to be just another dock: - one can drag tabs to and from it, - one can move and resize it - its state is saved accross sessions, - it is a controller window that allows the user to perform some actions on the current (active) image. As I wrote in bug #115092, I don't think that any user would be surprised if we allowed the menu and the tool buttons to be dragged from the toolbox to any other dock. In fact, it would be nice to add this feature to a future release. Is there anything else that makes the toolbox special in the GIMP user interface? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Raphaël Quinet wrote: There are some subtle differences that are internal and IMHO not important from the user's point of view: if we look at the remaining differences (again, from the user's point of view, not from the code point of view), what is left? - The toolbox has a menu bar. - The toolbox contains the buttons for switching tools. - Drag drop of URLs, image icons, etc. opens up the image. That's the only one I can think of off the top of my head. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Hi, Raphal Quinet [EMAIL PROTECTED] writes: Following the discussion in bug #115092 and according to Sven's suggestion, I am moving a part of the discussion here: what is special about the GIMP toolbox, from a user's point of view? What makes it different from the other docks? The toolbox is the first window that opens and the last that closes. It is even raised when the last image window is closed. It is treated special when you hit Tab. All this makes it the leader window of the GIMP application. It is a very special window and IMO there's no reason for this to change. As I wrote in bug #115092, I don't think that any user would be surprised if we allowed the menu and the tool buttons to be dragged from the toolbox to any other dock. In fact, it would be nice to add this feature to a future release. You can already add a tools list/grid to whatever dock you like. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
On Mon, 24 Nov 2003 16:52:34 +0100, David Neary [EMAIL PROTECTED] wrote: Raphaël Quinet wrote: There are some subtle differences that are internal and IMHO not important from the user's point of view: if we look at the remaining differences (again, from the user's point of view, not from the code point of view), what is left? - The toolbox has a menu bar. - The toolbox contains the buttons for switching tools. - Drag drop of URLs, image icons, etc. opens up the image. Yes, but this is already a bit confusing for the user: you can drop something on the menu, on the icons of the tools or on the area around the color, brush, pattern and gradient selectors. But you cannot drop it on the selector themselves or on any other part of the toolbox window (e.g., the tabs attached to it, such as tool options, etc.) We should probably take care of the drag drop issues in a separate thread (maybe I should file a bug report) because I don't think that our user interface is very consistent there. How do we explain to a user _why_ she should drop an image on the menu or on the icons of the tools, but not on the other parts of the GIMP windows? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
On 24 Nov 2003 17:04:37 +0100, Sven Neumann [EMAIL PROTECTED] wrote: The toolbox is the first window that opens and the last that closes. Yes, I mentioned this in my message (the code of the GIMP must have at least one window to start with). But this is not something that most users should care about, IMHO. It is even raised when the last image window is closed. It is treated special when you hit Tab. All this makes it the leader window of the GIMP application. But could you explain to a newbie _why_ this is like that? Is there a reason why only that window (which includes a dock) is raised when the last image window is closed and why this one is treated differently when you press Tab? Why don't we do the same thing for all docks? The only reasons that I can think of are historical, so this is not very good from a (new) user's point of view. It is a very special window and IMO there's no reason for this to change. The consistency of the user interface would be a good reason, IMHO. As I wrote in bug #115092, I don't think that any user would be surprised if we allowed the menu and the tool buttons to be dragged from the toolbox to any other dock. In fact, it would be nice to add this feature to a future release. You can already add a tools list/grid to whatever dock you like. But this list or grid of tools does not behave like the one in the toolbox, unfortunately. The grid view does not behave as set of buttons (different background color, no highlighting on mouse-over) and it is not possible to drag drop images (as mentioned in Dave's message). It would be nice to replace the main tools area in the toolbox by a grid view of the tools if these differences could be fixed. But then there would be even less reasons to treat the toolbox differently from all other docks. If the menu could also be removed or dragged to another dock, then the last difference between the toolbox and the other docks would go away. Or did I miss something important? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Porting plug-ins to GIMP-1.3.23
Hi,
if you have plug-ins that used to work with GIMP-1.3, you will most
probably notice that they don't work with 1.3.23 any longer. If you
try to recompile them, you will notice that there are some
incompatible changes in libgimpwidgets. The changes were absolutely
needed and are quite small. Let me point you at the culprits
nevertheless...
(1) GimpDialog API changes
http://developer.gimp.org/api/1.3/libgimpwidgets/GimpDialog.html
GimpDialog is actually a GtkDialog. It has always been but the new API
is much closer to the GtkDialog API. Here's a simple code snippet
using the new API:
dialog = gimp_dialog_new (_(Foo Filter), foo,
NULL, 0,
gimp_standard_help_func, gimp-plug-in-foo,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OK, GTK_RESPONSE_OK,
NULL);
As you can see the new way of creating a GimpDialog is a lot
simpler. For each button you simply pass a label text (or a stock-id)
and an integer that will serve as an identifier for the button. You
can then connect to the response signal which is emitted if a button
is pressed or the user attempts to close the dialog by other means.
The registered response ID is passed to the signal handler.
Alternatively, you can use gimp_dialog_run(), a convenience function
that behaves very much like gtk_dialog_run(). Most GIMP plug-ins
simply create a dialog, run a main loop which is quit when the dialog
is closed and then check if the OK button was pressed. This used to be
done by connecting a signal handler to the OK button and setting some
boolean variable from there. With the new dialog API, this boils down
to:
static gboolean
foo_dialog (void)
{
GtkWidget *dialog;
gboolean run;
dialog = gimp_dialog_new (_(Foo Filter), foo,
NULL, 0,
gimp_standard_help_func, gimp-plug-in-foo,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OK, GTK_RESPONSE_OK,
NULL);
/* add widgets to the dialog here */
run = (gimp_dialog_run (GIMP_DIALOG (dialog)) == GTK_RESPONSE_OK);
gtk_widget_destroy (dialog);
return run;
}
(2) GimpFileSelection was renamed to GimpFileEntry.
http://developer.gimp.org/api/1.3/libgimpwidgets/GimpFileEntry.html
This is a trivial change and not many plug-in are using a file entry
anyway. If your's does, just change all occurances of
gimp_file_selection to gimp_file_entry.
(3) New option menu and radio group APIs
http://developer.gimp.org/api/1.3/libgimpwidgets/libgimpwidgets-GimpWidgets.html
The old API for option menus and groups of radio buttons associated a
data pointer with each menu item or button. In almost all cases this
pointer was used to attach an integer (often an enum value). Unless
you used the GINT_TO_POINTER() and GPOINTER_TO_INT() macros, this
common usage case doesn't work for all platforms. That's why we
introduced new functions that take integer values directly. We ask you
to check your code and convert to the new functions if you are using
integers with gimp_option_menu_new() or gimp_radio_group_new().
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Hi, Raphal Quinet [EMAIL PROTECTED] writes: You can already add a tools list/grid to whatever dock you like. But this list or grid of tools does not behave like the one in the toolbox, unfortunately. The grid view does not behave as set of buttons (different background color, no highlighting on mouse-over) and it is not possible to drag drop images (as mentioned in Dave's message). It would be nice to replace the main tools area in the toolbox by a grid view of the tools if these differences could be fixed. But then there would be even less reasons to treat the toolbox differently from all other docks. Exactly and that's why the toolbox is special. It holds the tool buttons, it decides what tool is active, it has the most important menu and for that reason it also creates images when things are dropped there. If the menu could also be removed or dragged to another dock, then the last difference between the toolbox and the other docks would go away. Or did I miss something important? You missed the important fact that the menu cannot be removed and that we don't intent to change this. Face it, as it stands, the toolbox is special. I really don't understand why you are questioning this. It's a fact. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2 status and suggestions
On Nov 24, 2003, at 12:02 am, Roman Joost wrote: I tried it with some docs and it rocks. Unfortunately, i'm running into trouble with the german umlauts. Do you've a solution for keeping the umlauts ? We'll switch to UTF-8 which should solve this problem, unless I'm misunderstanding the issue, of course. :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
On 24 Nov 2003 18:42:21 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] writes: If the menu could also be removed or dragged to another dock, then the last difference between the toolbox and the other docks would go away. Or did I miss something important? You missed the important fact that the menu cannot be removed and that we don't intent to change this. Face it, as it stands, the toolbox is special. I really don't understand why you are questioning this. It's a fact. I am questioning this because I think that the fact that the toolbox is special is an artificial limitation that should go away in a future release in order to make the user interface more consistent and easier to use. Let's imagine for a moment that the menu can be moved to any dock, and the tools area is just a grid view that can also be moved around. We may have to ensure that at least one menu is present in some dock, but this may not even be necessary if the functions can be accessed in some other way. If we achieve this, then the mental model of how the GIMP behaves becomes much simpler: - There is one, two or any number of windows (docks) that can include various controls acting on the image windows. - All docks are session-managed top-level windows. Their size and position are kept accross sessions. - All docks are equal and can host any number of tabs, including the one containing the tools. - The main menu is just another thing that can be included (or not) in a dock. If present, it would appear at the top of the dock. Wouldn't this be easier to understand and work with? The user simply has a number of control windows in which several dockable items can be organized in any way they want. And none of them is more special than the others. If there is no good answer to the question why do we need the toolbox to be special (from a user interface point of view)? then the differences between the toolbox and the other docks should go away. Not now, but in a future release. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Hi, Raphal Quinet [EMAIL PROTECTED] writes: I am questioning this because I think that the fact that the toolbox is special is an artificial limitation that should go away in a future release in order to make the user interface more consistent and easier to use. This discussion is about proper defaults for GIMP-2.0, not some future plans. Let's imagine for a moment that the menu can be moved to any dock, and the tools area is just a grid view that can also be moved around. We may have to ensure that at least one menu is present in some dock, but this may not even be necessary if the functions can be accessed in some other way. If we achieve this, then the mental model of how the GIMP behaves becomes much simpler: - There is one, two or any number of windows (docks) that can include various controls acting on the image windows. - All docks are session-managed top-level windows. Their size and position are kept accross sessions. - All docks are equal and can host any number of tabs, including the one containing the tools. - The main menu is just another thing that can be included (or not) in a dock. If present, it would appear at the top of the dock. Wouldn't this be easier to understand and work with? The user simply has a number of control windows in which several dockable items can be organized in any way they want. And none of them is more special than the others. I seriously doubt that this would make it easier for the user. In my opinion it only adds an completely unneeded level of configurability and thus complexity. The GIMP should have a common window that everyone (and the docs) can refer to as the toolbox. I don't see any good reason of changing this. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Raphaël Quinet ([EMAIL PROTECTED]) wrote: On 24 Nov 2003 17:04:37 +0100, Sven Neumann [EMAIL PROTECTED] wrote: It is even raised when the last image window is closed. It is treated special when you hit Tab. All this makes it the leader window of the GIMP application. But could you explain to a newbie _why_ this is like that? Is there a reason why only that window (which includes a dock) is raised when the last image window is closed and why this one is treated differently when you press Tab? Why don't we do the same thing for all docks? Actually the raising action that Sven mentioned is a side-effect of the Tab-Feature. I'm pretty sure that you know about it, but it appears garbled in your description. * The first Tab in an image window hides the toolbox and the docks * The second Tab lets the toolbox reappear * The third Tab also lets the docks reappear. Basically the Tab key cycles between Full blown GUI, Toolbox only, just image windows. And IMHO the possibility to have a reduced GUI (Toolbox only) seems useful to me. Of course we have to make sure that a window of the Gimp is visible when the last image window gets closed. So we make sure that the toolbox gets _present()ed again [1], when the last open image gets closed. So the Toolbox Window is different, because it is by definition the minimal GIMP GUI. Hope this clears things up. Bye, Simon [1] There lurks an annoyance here: this step actually should be omitted when actually closing the GIMP. I sometimes have the effect that I shut down the Gimp (living in its own Viewport), switch to a different Viewport and want to do something different and *oops* Sawfish switches back (because the toolbox got _present()ed) and I have to watch the Shutdown process of the GIMP. -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: The GIMP 1.3.23
Hi all, The next release in the development series of the GIMP, version 1.3.23, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.23/ or from one of the mirrors listed at http://gimp.org/download.html This is expected to be the final release before we enter a pre-release cycle. A great deal of work has gone into stabilising the plug-in API, and fixing a large number of outstanding issues before the 2.0 release, so we think that this release of the GIMP is the best yet. More than ever, we would like people to download and build this release, and try to break it in new and interesting ways. Happy GIMPing, Dave. Overview of Changes in GIMP 1.3.23 == - Color proof display filter using ICC profiles written by Banlu Kemiyatorn - New gimprc options to work around window management problems [Sven, Brix] - Fixes for using GIMP on Xinerama setups [Sven] - Numerous libgimp* API cleanups [Mitch, Sven] - Theme switching in the preferences dialog [Mitch] - Added a small theme [Mitch] - Cleanup and unification of message strings [Mitch] - 64bit clean libgimp API [Yosh] - New plug-in color selector using color-selector modules [Mitch] - GimpCanvas drawing abstraction [Sven] - Added DICOM file plug-in by Dov Grobgeld - Imported new WMF plug-in from libwmf2 [Sven, Mitch] - A session name can be given on the command-line [Sven] - Allow to move image windows and docks between screens [Mitch, Sven] - Fixed multi-head issues [Mitch] - Allow to merge visible paths [Simon] - Redone GimpDialog API [Mitch] - Load GIMP brush format version 3 [Sven] - Allow to use GIMP without any fonts [Sven] - Lots of bug fixes Other contributors: Ville Pätsi, Eric Pierce, Tor Lillqvist, Henrik Brix Andersen, Manish Singh, Dom Lachowicz, Francis James Franklin, Dave Neary, Maurits Rijk, Joao S. O. Bueno, Michael Schumacher, Daniel Rogers, Hans Breuer, Jakub Steiner -- David Neary, Lyon, France. E-Mail: [EMAIL PROTECTED] -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Re: Fwd: [GUG] CMYK under Gimp.
Am 21.11.03, 09:37 -0800 schrieb Daniel Rogers: Ah, well I interpreted this slightly differently. While X11 does have color management support, it is not as good as lcms, and doesn't support the concept of CMM, which is what I really thought he was asking about. Pro people like to be able to buy Color Management Modules and plug them into the exsisting system apis. I heard lcms is plugable as an CMM module too (mac/win) and is sold for zero ;-) -- Kai-Uwe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.
Am 21.11.03, 16:04 +0100 schrieb Sven Neumann: would help plug-ins to easily link against liblcms? I don't see how a configure check in GIMP would help plug-ins so the answer to the question doesn't really matter. I'll give it anway: I've added such a check a few minutes ago when the color proof display filter was added to CVS. Great. Thanks for this hint. I will see what I can do with it. -- Kai-Uwe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.
Hi, Kai-Uwe Behrmann [EMAIL PROTECTED] writes: would help plug-ins to easily link against liblcms? I don't see how a configure check in GIMP would help plug-ins so the answer to the question doesn't really matter. I'll give it anway: I've added such a check a few minutes ago when the color proof display filter was added to CVS. Great. Thanks for this hint. I will see what I can do with it. Hmm? As I already outlined, the configure check in GIMP doesn't help external plug-ins and modules. Also, GIMP does not depend on lcms now, so I wonder what exactly you are trying to do with it ...? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp. (fwd)
I resend this email, as it was lost by the lists.xcf.berkeley.edu mailserver. -- Forwarded message -- Date: Mon, 24 Nov 2003 11:03:41 +0100 (CET) From: Kai-Uwe Behrmann [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp. Hi, Am 21.11.03, 16:48 +0100 schrieb Sven Neumann: X11 has support for color management for a lng time already. What exactly is missing in your opinion? That was my surprise and hope some time ago too. I looked in the man pages and found only some rudimentary entries describing how to convert single colour for the colour selction. I am not aware of any mechanism on how to send Lab or Yuv or something else directly to X for displaying. And I did not found any mechanism on telling X which is the correct monitor profile. This I would call colour management. regards Kai-Uwe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
