Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
On 08/09/2010 10:51 PM, LightningIsMyName wrote: > Hello, > > I recently re-read all the GSoC suggestions for 2010, and I found this > interesting one about making the menus searchable: > https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility > > 0. How do we want the search to work? A user can bring a search dialog > up? Will the search be based on a string? A tree? No dialogs please. What about a search field to the right in the menubar, accesible through a keyboard shortcut, like Firefox' Ctrl+K? I imagine it to work like this: The user can type a string, and it will be matched against all texts associated with a filter/operation/whatever. The title, the description, the short summary etc. Typing "Dogde" should match with "Dodge". As you type, you get a list (not tree) of hits. Each hit has a preview with the effect on the image if applied. 'down, down, return' activates the second matched item, like it works in all similar UIs. > 2. We need to define a "usable" plugin browser. One of the features I'm > missing the most, is a preview image. Plugins should have an option to > register a preview image of their effect (probably by having the image's > binary data embedded in them). This also relates to the feature request > of having a logo script browser... I don't think registering a fixed preview image is good enough, it should be a preview of the effect if applied to the current image. > 3. Will plugins also have a category (in addition to a menu location)? > How should we organize the plugins? With a good search mechanism, organizing plug-ins becomes less important, right? It should be possible to have descriptions good enough to avoid us from having additional tags. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ 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 08/09/2010 10:32 PM, Rupert Weber wrote: > On 08/09/2010 07:42 PM, Martin Nordholts wrote: > >> As long as you are available to respond to feedback about the patch, it >> will be included into 2.8, don't worry. It's just that it might take a >> while before anyone gets around to review and test it properly. > > Oh, cool. > Just, before anyone actually dives in that code, please ask me for the > most recent version, as I don't want to spam the bugzilla page with > daily updates. I suggest you update the patch on, say, a weekly basis. No open source project minds being spammed with patches :) > >>> (a) decide, which modes. Be conservative, don't clutter the menu >> >> CIE LCH based Hue, Saturation, Color and Lightness, right? > > Well, yes. But what about e.g. Dodge, Burn, or Soft Light? D/B are easy > to do and make sense. SL is not so easy, don't know if it even makes sense. > But I'm also ok with sticking to those 4 obvious ones. And D/B ;=) I don't get, we already have working Dodge, Burn and Soft Light, don't we? / Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName wrote: > Hello, > > I recently re-read all the GSoC suggestions for 2010, and I found this > interesting one about making the menus searchable: > https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility > > As far as I know, menus are searchable and the best example is the keyboard > shortcuts dialog which has a searchbox to find the GIMP action you'd like to > use. However, that action is not immediately activateable. What I personally envision is something like the completion dialog that you can find in GTKTreeViews (for example, typing something in when the file list in a file selection dialog is focused, offers you a choice of the possible items. And upon selection from that sub-list, the file is immediately chosen.) So I asked on #gimp and I was told there was a discussion on IRC about > finding a more usable replacement to the plugin browser. The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations). > > So, to get a formal record of this discussion, I'm starting it on the > mailing list again. > > Here are points which should be considered: > > 0. How do we want the search to work? A user can bring a search dialog up? > Will the search be based on a string? A tree? one or more strings, per your Tags suggestion. > > 1. GEGL ops should really be integrated in the GIPM menus. As What's a GIPM ? :D > someone said, > it's like the old script-fu menu - it was wrong. We don't have to force the > user to remember what's a GEGL op (which will be accessed using the GEGL > tool) and what's a regular plugin/script. > It's a bit offtopic, but we should find a way to implement gegl plugins with > a custom GUI, and register them like regular plugins in the menus. Having a > search that will once point to a plugin and once activate the gegl tool, is > a very bad idea... Though we need to consider, that a GEGL op can do much more than simply be applied to the image once, destructively. If we make GEGL ops available in the menus, we should aim to do so in a way which does not trap us in a corner if, for example, we want to in the future be able to add that op into the image as a non-destructive effect on the current layer/layer group. > > 2. We need to define a "usable" plugin browser. One of the features I'm > missing the most, is a preview image. Plugins should have an option to > register a preview image of their effect (probably by having the image's > binary data embedded in them). This also relates to the feature I agree with you, but believe that we need to be more definite than that: previews should show clearly the before and after. I favor GMIC's horizontally split preview style for this -- it avoids wasting space, and instead of tiling two complete images next to each other, you get to see half of the image as it would be if it were filtered. In some cases, the vertically split style may be more appropriate. request of > having a logo script browser... Well, if we did what you outline here, how would Script-Fu scripts handle the necessary embedding of binary data (I don't mean to imply that they couldn't, just that I do not know exactly how well they can handle this kind of binary string literal). > 4. Another option, instead of categories and sub-categories, is tagging - > like the brushes work in 2.7 (unlike categories - there are no sub-levels, > and each plugin can be in many places) The current api allows this, minus the 'no sublevels' criteria, since a procedure can register in multiple menu paths. I like the tagging concept, especially if it turns out to be a cheap solution to menu editing (If I could make my own tag, tag all the stuff I use most with it, and assign a shortcut to bring up that menu, that would really help my efficiency... Or, if I could remove the 'FILE' tag from the 'Print' menu item, I would no longer have to contend with a menu item that I never ever use. Note that if we could untag, we need a virtual 'tag' that items without a tag could belong to.. '-' or '!' possibly.) I think we should tag, and predefine a tag set that should be adequate for most existing plugins. User tagging is important because plugin authors may not always be available or be willing to add this information. [this sort of ties into the 'Get Hot New Stuff' proposition -- it would be nice to be able to distribute the task of correct plugin tagging across users via a web interface) Hope I've given you something to think about :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
On 9 August 2010 23:42, yahvuu wrote: > Hi all, > > On 09.08.2010 22:51, LightningIsMyName wrote: >> 0. How do we want the search to work? A user can bring a search dialog >> up? Will the search be based on a string? A tree? > > Just a quick and cheap thought: > if you're talking about search, that means i'm already using the keyboard to > type in > what i want to do, and then we're only one step away from a command line > within GIMP. What do you call the existing scheme and python interpreters in GIMP? I'd say that we already have this, and have had it for years. -- Regards Jon Nordby - www.jonnor.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
G'Day,
I've been thinking a bit about this recently as I can never
remember where anything is, and
writing script-fu's generally means I have a linear understanding of
what is available.
How to access it:
From some menus, I don't feel strongly about these. Help -> Menu
Browser .. blah.
Anyway, the way I would use it is a shortcut. Ctrl-F would be the most
logical choice.
Once a "tool wheel" is introduced (like in games), there would be a case
to have it included there.
How does it look:
text box at the top, results underneath. It's a popup that appears near
where the cursor was when it was created. (be nice if it was a "light"
popup, but anyway).
The results should just search the name of the menu. See options. It
should do a case insensitive search like pdb (as the user types),
including the regex.
The first item should be selected ready to go. Hit enter to select the item
So an example use for me recently would be, I'm looking for the sparkle
plugin.
Ctrl-F spark . Hitting enter would close the window and call
the menu.
By default each line would just contain the name of the menu: ie
"Sparkle". But I think it reasonable to add an option to show where the
item is: eg Sparkle (Filters -> Light and Shadow). By default the
actual PDB names would not be searchable (eg plugin-sparkle), but no
doubt that would be a good option, but only if the item appears in a menu.
There is no need to get complicated with tagging, and trees, and sub
categories. I believe a basic implementation will show that it's power
will be in the simplicity.
So what about gegl ops. My feeling is that it's a menu search, so it
wouldn't be included by default. However a simple option to add this
into the search would be reasonable.
Options:
X Show Menu location
X Dev: Include GEGL operations
X Dev: Include PDB (internal) names
thanks for bringing this up, it's been playing on my mind recently...
Cameron
On 08/10/2010 06:51 AM, LightningIsMyName wrote:
Hello,
I recently re-read all the GSoC suggestions for 2010, and I found this
interesting one about making the menus searchable:
https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility
As far as I know, menus are searchable and the best example is the
keyboard shortcuts dialog which has a searchbox to find the GIMP
action you'd like to use. So I asked on #gimp and I was told there was
a discussion on IRC about finding a more usable replacement to the
plugin browser.
So, to get a formal record of this discussion, I'm starting it on the
mailing list again.
Here are points which should be considered:
0. How do we want the search to work? A user can bring a search dialog
up? Will the search be based on a string? A tree?
1. GEGL ops should really be integrated in the GIPM menus. As someone
said, it's like the old script-fu menu - it was wrong. We don't have
to force the user to remember what's a GEGL op (which will be accessed
using the GEGL tool) and what's a regular plugin/script.
It's a bit offtopic, but we should find a way to implement gegl
plugins with a custom GUI, and register them like regular plugins in
the menus. Having a search that will once point to a plugin and once
activate the gegl tool, is a very bad idea...
2. We need to define a "usable" plugin browser. One of the features
I'm missing the most, is a preview image. Plugins should have an
option to register a preview image of their effect (probably by having
the image's binary data embedded in them). This also relates to the
feature request of having a logo script browser...
3. Will plugins also have a category (in addition to a menu location)?
How should we organize the plugins? On one hand, it's probably a bad
idea to continue having plugin authors choose their own category (or
as it is now - a menu location). Since then you might find yourself
with dozens of categories (like "my-site" "his-site") and typos
("artisti" and "artistic") or redefinitions ("art" vs. "artistic") may
create more categories.
It's a fact - a bloated category list is good for nothing... So,
should we limit the categories for plugins?
4. Another option, instead of categories and sub-categories, is
tagging - like the brushes work in 2.7 (unlike categories - there are
no sub-levels, and each plugin can be in many places)
Menus in GIMP should become more useful and things should become
easier to find. But how? Please share your thoughts
~LightningIsMyName
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
Hi all, On 09.08.2010 22:51, LightningIsMyName wrote: > 0. How do we want the search to work? A user can bring a search dialog > up? Will the search be based on a string? A tree? Just a quick and cheap thought: if you're talking about search, that means i'm already using the keyboard to type in what i want to do, and then we're only one step away from a command line within GIMP. Ubiquity is probably the best-designed example of such a command line, for firefox: http://mozillalabs.com/ubiquity/ http://jonoscript.wordpress.com/2010/01/20/retrospective-what-we-learned-from-ubiquity/ regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Usability of menus (search, gegl ops, ...)
Hello,
I recently re-read all the GSoC suggestions for 2010, and I found this
interesting one about making the menus searchable:
https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility
As far as I know, menus are searchable and the best example is the keyboard
shortcuts dialog which has a searchbox to find the GIMP action you'd like to
use. So I asked on #gimp and I was told there was a discussion on IRC about
finding a more usable replacement to the plugin browser.
So, to get a formal record of this discussion, I'm starting it on the
mailing list again.
Here are points which should be considered:
0. How do we want the search to work? A user can bring a search dialog up?
Will the search be based on a string? A tree?
1. GEGL ops should really be integrated in the GIPM menus. As someone said,
it's like the old script-fu menu - it was wrong. We don't have to force the
user to remember what's a GEGL op (which will be accessed using the GEGL
tool) and what's a regular plugin/script.
It's a bit offtopic, but we should find a way to implement gegl plugins with
a custom GUI, and register them like regular plugins in the menus. Having a
search that will once point to a plugin and once activate the gegl tool, is
a very bad idea...
2. We need to define a "usable" plugin browser. One of the features I'm
missing the most, is a preview image. Plugins should have an option to
register a preview image of their effect (probably by having the image's
binary data embedded in them). This also relates to the feature request of
having a logo script browser...
3. Will plugins also have a category (in addition to a menu location)? How
should we organize the plugins? On one hand, it's probably a bad idea to
continue having plugin authors choose their own category (or as it is now -
a menu location). Since then you might find yourself with dozens of
categories (like "my-site" "his-site") and typos ("artisti" and "artistic")
or redefinitions ("art" vs. "artistic") may create more categories.
It's a fact - a bloated category list is good for nothing... So, should we
limit the categories for plugins?
4. Another option, instead of categories and sub-categories, is tagging -
like the brushes work in 2.7 (unlike categories - there are no sub-levels,
and each plugin can be in many places)
Menus in GIMP should become more useful and things should become easier to
find. But how? Please share your thoughts
~LightningIsMyName
___
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 08/09/2010 07:42 PM, Martin Nordholts wrote: > As long as you are available to respond to feedback about the patch, it > will be included into 2.8, don't worry. It's just that it might take a > while before anyone gets around to review and test it properly. Oh, cool. Just, before anyone actually dives in that code, please ask me for the most recent version, as I don't want to spam the bugzilla page with daily updates. >>(a) decide, which modes. Be conservative, don't clutter the menu > > CIE LCH based Hue, Saturation, Color and Lightness, right? Well, yes. But what about e.g. Dodge, Burn, or Soft Light? D/B are easy to do and make sense. SL is not so easy, don't know if it even makes sense. But I'm also ok with sticking to those 4 obvious ones. And D/B ;=) >>(c) decide how to deal with storing them (XCF version++) > > Didn't we already say that the XCF version should be bumped? yes, I just wasn't sure how final that was. Good. Rupert ___ 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
>From Martin: > I think the names needs to suggest that new files should avoid using > those layer modes. > > Other alternatives: > > "(compat.)" > "(legacy)" > "(obsolete)" > "(broken") > "(old)" Good point! Then "(obsolete)" is best. The abbreviation of "compat." to be avoided; "legacy" is too figurative, has slightly wrong connotations; "broken", though technically correct, is too negative to be in the interface; "old" doesn't suggest enough that the old modes are obsolete. Since these names will only appear when old files are loaded, the more technical nature of "obsolete" is better. Can we all agree on "(Obsolete)"? Charlie ___ 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 08/09/2010 09:08 PM, Charlie De wrote: >> From Martin: >> >> I think the displayed names should be like above, and the API names >> should have a LCH prefix or suffix. I think the old ones should have >> display names with "(compatibility)" appended, and only be shown when an >> XCF that uses these modes have been loaded. The API names should remain >> as is. > > "(compatibiity)" makes sense but might be a bit too long. Wouldn't "(Old)" or > "(HSB)" be better? I think the names needs to suggest that new files should avoid using those layer modes. Other alternatives: "(compat.)" "(legacy)" "(obsolete)" "(broken") "(old)" / Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ 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
>From Martin: > > I think the displayed names should be like above, and the API names > should have a LCH prefix or suffix. I think the old ones should have > display names with "(compatibility)" appended, and only be shown when an > XCF that uses these modes have been loaded. The API names should remain > as is. "(compatibiity)" makes sense but might be a bit too long. Wouldn't "(Old)" or "(HSB)" be better? Charlie ___ 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 08/09/2010 03:42 PM, Rupert Weber wrote: > Hi, > > while the last patch I posted* to > http://bugzilla.gnome.org/show_bug.cgi?id=325564 > is of course outdated already, I think it's time to think about how to > ever get this included. Hi, As long as you are available to respond to feedback about the patch, it will be included into 2.8, don't worry. It's just that it might take a while before anyone gets around to review and test it properly. > My suggestion: > (1) Completely drop the xcf enum conversions (xcf-util.*) I introduced. > They are not needed anymore and, quite frankly, pointless right now. > This cuts down the patch a bit and means no new files added. Sounds good. > (2) Separate out the actual conversion routines in gimplibcolor as > a standalone patch. > Maybe change the Decompose plug-in to use those, so we at least > have something to make use of the new conversions. > (as far as I can tell, the current Decompose Lab functions are > broken, anyway). Having conversion routines in a separate patch is reasonable. If Decompose is broken, a separate patch to fix it would also be good. > (3) Once gimplibcolor updates are all settled, go about adding new layer > modes which make use of them. > (a) decide, which modes. Be conservative, don't clutter the menu > too much with modes that nobody needs. Once they are out, we > can't take them back. CIE LCH based Hue, Saturation, Color and Lightness, right? > (b) decide how to name them. I think the displayed names should be like above, and the API names should have a LCH prefix or suffix. I think the old ones should have display names with "(compatibility)" appended, and only be shown when an XCF that uses these modes have been loaded. The API names should remain as is. > (c) decide how to deal with storing them (XCF version++) Didn't we already say that the XCF version should be bumped? Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab Decompose
On 08/09/2010 05:50 PM, Charlie De wrote: > Actually, I see it, now that the script is done and the tests can be performed > without bruising my knuckles. It isn't as bad as the Color mode, but it's > there. Decomposing and recomposing an unaltered layer copy of an image > changes > the colours a little. That's rather due to rounding and not a bug. Lab and 8-bit don't play well together. But the Decompose plug-in has no other choice than to squeeze the result into 8-bit. (It *might* be augmented by the unusual assumption of PAL/SECAM input, but that'd be more of a coincidence.) Other than that, decompose and recompose are consistent. ___ 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
Given that decisions made about layer modes will have consequences for years to come, it strikes me that there is an urgent need for a formal specification of what is to be done. A natural place to write one would be the wiki, but since that isn't functioning, maybe it would be possible to create a collaborative Google Docs document and use it to work out a spec? -- Bill ___ 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
Actually, I see it, now that the script is done and the tests can be performed without bruising my knuckles. It isn't as bad as the Color mode, but it's there. Decomposing and recomposing an unaltered layer copy of an image changes the colours a little. Having two layers, top blurred, and bringing into it the L component of the lower layer, accentuates noise somewhat, not as badly as the Color mode. Iterating this procedure a number of times on the blurred layer, however, soon breaks down the image, with severe colour artifacts. Good news: the YCbCr_ITU_R709 decomposition works much better. Iteration tests brought no breakdown. The test on an unaltered layer copy of original also doesn't alter colours. A commenter in the original bug report about the Color mode did say the R709 worked well in his tests. Charlie - Original Message > From: Rupert Weber > To: gimp-developer@lists.XCF.Berkeley.EDU > Sent: Mon, August 9, 2010 4:45:00 PM > Subject: Re: [Gimp-developer] Getting new layer modes fit for inclusion > > On 08/09/2010 04:16 PM, Charlie De wrote: > >> From Rupert: > >> (as far as I can tell, the current Decompose Lab functions are > >> broken, anyway). > > > > What makes you say that? And how severe is the problem? > > > > Right this minute I'm writing a script with LAB Decompose... > > Well, 'different' might have been nicer than 'broken' - > > The conversion doesn't account for gamma: > http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html > > As a result, the L* channel is very light (check the histogram). I have > no clue how that influences a* and b*. > > Also, it uses the conversion matrix for PAL/SECAM RGB. (Maybe PAL/SECAM > has gamma 1.0? Then the missing gamma correction would be correct.) > http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html > > Anyway, unless your image is in PAL/SECAM RGB, the conversion in > Decompose is incorrect. > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ 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 08/09/2010 04:16 PM, Charlie De wrote: >> From Rupert: >> (as far as I can tell, the current Decompose Lab functions are >> broken, anyway). > > What makes you say that? And how severe is the problem? > > Right this minute I'm writing a script with LAB Decompose... Well, 'different' might have been nicer than 'broken' - The conversion doesn't account for gamma: http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html As a result, the L* channel is very light (check the histogram). I have no clue how that influences a* and b*. Also, it uses the conversion matrix for PAL/SECAM RGB. (Maybe PAL/SECAM has gamma 1.0? Then the missing gamma correction would be correct.) http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html Anyway, unless your image is in PAL/SECAM RGB, the conversion in Decompose is incorrect. ___ 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
>From Rupert: > (as far as I can tell, the current Decompose Lab functions are > broken, anyway). What makes you say that? And how severe is the problem? Right this minute I'm writing a script with LAB Decompose... Charlie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Getting new layer modes fit for inclusion
Hi, while the last patch I posted* to http://bugzilla.gnome.org/show_bug.cgi?id=325564 is of course outdated already, I think it's time to think about how to ever get this included. My suggestion: (1) Completely drop the xcf enum conversions (xcf-util.*) I introduced. They are not needed anymore and, quite frankly, pointless right now. This cuts down the patch a bit and means no new files added. (2) Separate out the actual conversion routines in gimplibcolor as a standalone patch. Maybe change the Decompose plug-in to use those, so we at least have something to make use of the new conversions. (as far as I can tell, the current Decompose Lab functions are broken, anyway). (3) Once gimplibcolor updates are all settled, go about adding new layer modes which make use of them. (a) decide, which modes. Be conservative, don't clutter the menu too much with modes that nobody needs. Once they are out, we can't take them back. (b) decide how to name them. (c) decide how to deal with storing them (XCF version++) What do you say? Regards, Rupert * I posted a second version there, but it might not be the right place to clutter with in-development patches. Is there a better way to publish those? Should I setup some webspace and host them there? That way I could publish both, incremental and against-master patches. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
