Re: [Gimp-developer] (no subject) plus dockables
On 08/28/10 07:16, Martin Nordholts wrote: Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense But won't that be a problem? Instead of having all dockable dialogs in a single place, a user would have to go hunt for the one he wants. Regards, Martin I think this is the logical error here from usage point of view. It is not the fact that they are dockable which means they should be grouped together. They should be grouped according to function. If I want to hide a layer I should not need to think : last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden? If I want to hide a layer , I go to the layers menu. I find it strange anyone would argue against that. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
Just the simple point of a basic user: 2010/8/28 g...@catking.net I think this is the logical error here from usage point of view. It is not the fact that they are dockable which means they should be grouped together. They should be grouped according to function. If I want to hide a layer I should not need to think : last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden? If I want to hide a layer , I go to the layers menu. I find it strange anyone would argue against that. The layers (dockable) dialog should never be hidden, every GIMP user guide says that. Thus for anybody following this idea, the real question is If I want to hide a layer, I go to the layers dialog. Otherwise, it would be necessary to copy in the layers menu all the functionalities of the layers dialog, which means a lot. Is this argument so strange? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dummy Layer with particular dynamic
Sorry but i don't understand if this possible new feature (adjustment layer) is interesting or not? I would try to do an implementation, but if is useless or not interesting i will do other. What do you think? This is original message: --- Message: 1 Date: Sat, 28 Aug 2010 02:05:47 +0200 From: Jacopo Corzanicorz...@gmail.com Subject: [Gimp-developer] Dummy Layer with particular dynamic effect To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:4c7852db.4040...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, i think that would be very useful a dummy layer that can contains a particular effect/operation like curves in order to change parameters in future without any problems and eventually using a particular mask for handle particular zone where i don't want this. In this case is possible to activate or deactivate effects and change that parameters dynamically without any duplicate image layers with static effects. The problem may be in a user-defined plugins but for standard operation like levels or curves there isn't or i'm missing somethings? If i write an effect plugin would be perfect to associate that with this kind of dummy layer in order to change parameters/enable/disable/masking/unmasking that whenever i want. Sorry for my english :),i'm not a mother language... Jack ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dummy Layer with particular dynamic
On 8/28/10, Jacopo Corzani wrote: Sorry but i don't understand if this possible new feature (adjustment layer) is interesting or not? Well, adjustment layers is what GIMP developers seem to refer to as layer abuse :) There are different ways to implement non-destructive editing. Would you be interested to find out more? Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting new layer modes fit for inclusion
On 24-08-10 11:51, Øyvind Kolås wrote: On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weberg...@leguanease.org wrote: On 08/24/2010 04:20 AM, David Gowers wrote: I hope you're not associating the quite suboptimal way in which GIMP currently uses GEGL, with BABL's speed or lack of speed. BABL just processes raw pixel buffers. A converter function just accepts a source and a destination pointer, along with a pixel count, and should convert that number of pixels. It doesn't have any heavy architecture or processing, aside from what may be in each individual converter function looking at your code in gimpcolorspace.c, making that code work with BABL looks like it's pretty much a case of cut+paste, modify the way the input is referred to, add some registration code. (getting your layer mode code to USE that, is a different issue, and I agree that would be non-trivial, although you might get significant speed gains from it because of greatly reduced function call overhead -- probably about as much as you describe for inlining below.) As I indicated, I'll be happy to make the babl integration of those conversions my next little project, but I also expect a bunch of questions to come up in the process (color management comes to mind). Color management does not have much to do with this, since the pixels are already assumed to be in a well defined pixel format and color space. Babl is nothing more than a collection of conversion functions, meta data about the color spaces and data types used and the ability to assess the conversion speed and quality of these conversions at runtime. Thus as long as the claim as to what pixel format a buffer is in is correct, use of babl is correctly color managed. /Øyvind K. Well how well defined is the format that babl receives and sends back. According to the web page at : http://www.gimp.org/release-notes/gimp-2.4-cm.html. The intent is to work in Gimp using the sRGB color space, however one can ignore this. On the other side there babl is supposed to work in scRGB (http://www.gegl.org/babl). Maybe I didn't look hard enough but I didn't find a real conversion from sRGB(8bit) to scRGB(16bit), neigther in GIMP nor in babl as described in *http://www.colour.org/tc8-05/Docs/colorspace/61966-2-2NPa.pdf.* In the babl extensions a CIE model is present, it takes as e reference white D65 while more common would be the reference white E (http://www.brucelindbloom.com). I assume that the sRGB/scRGB have reference white D50. Has anyone an idea what is the reference white for the RGB color model in BABL or GIMP? Are the reference white and the chromaticity coordinates not missing in the BABL model? Geert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Newbie startup problems
On Fri, 2010-08-27 at 14:55 +0200, oli...@first.in-berlin.de wrote: Hi, On Thu, Aug 26, 2010 at 01:55:22PM +0530, Phani Bhushan Tholeti wrote: Hi, I am new to GIMP (its source, usage and features). I had joined this list with a view to contribute to GIMP. I did manage to get it to compile and run (though my code is old - about a month or two). Currently I am giving the manual a try (to get used to GIMP), but its HUGE and a lot of features for me to learn. :( or :) ? The wiki took me here: http://gimp-wiki.who.ee/index.php/Hacking:Source_Tree [...] Oh, an overview on the organization of the source tree! More complete and up-to-date documentation can be found in the devel-docs folder of the source tree. Here is also the place where any new developer documentation should be added. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote: If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu. Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have Layers dialog in the Image/Layers menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch... I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now? Having just one place to do things avoids such ambiguity and mental friction. We do that for a few menu items already and I don't think it has ever caused any problems. Some examples are (and there are many more): Edit-Undo History View-Navigation Window Select-Selection Editor Colors-Info-Histogram Actually I think it's just an oversight that the Layers dialog is missing from the Layers menu. IMO all dialogs should be accessible from the menus where they belong to functionally. The Dockables menu is just a place to list all the available dialogs. It should be secondary. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
On Fri, 2010-08-27 at 12:39 +0200, yahvuu wrote: On 27.08.2010 07:32, Martin Nordholts wrote: If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu. What about naming it the 'Dialogs' menu? -- 'Dockables' sounds like implementation slang to me. And the 'Windows' menu becomes confusing in single-window-mode. Dialogs is even more special than Windows and in single-window-mode it is at least as wrong as using the term Windows. The Windows menu name on the other hand is pretty much default and used in many applications as a place to list all currently open windows. And that's the main use of it in GIMP as well. With the exception that we also list the dockables since we consider them something like sub-windows. Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's the job of a 3.0 redesign -- there is a whole lot more to do than just releasing the dockables from their current hiding place and distributing them over the menu structure. As I pointed out in another mail, most dialogs are already available in their respective menus. Completing this is not a major overhaul, it's a bug-fix. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dummy Layer with particular dynamic effect
Well, adjustment layers is what GIMP developers seem to refer to as layer abuse :) There are different ways to implement non-destructive editing. Would you be interested to find out more? Alexandre Prokoudine http://libregraphicsworld.org Hi Alexandre, i could agree with your consideration of layer abuse but adjustment layer is a quick and robust solution to manage effects whenever i want. Changing a curve (or any other effect) dynamically without duplicate layers would be a great. Sure,i'm interested to find another quick way to handle effects during time without do an layer abuse, but i don't have any ideas that speed up work like adj layers... :) Thanks for your response. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dummy Layer with particular dynamic
On Sat, 28 Aug 2010 18:24:26 +0400 Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: There are different ways to implement non-destructive editing. Would you be interested to find out more? I would be very interested in a non-destructive way of applying a curve to an image. A method that would allow later modification of the curve without having to rebuild everything that had been worked on since. Is there a proposed mechanism to support this? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
