Re: [Gimp-developer] Paint core beyond 2.6
On Sunday 08 June 2008 03:07:15 David Gowers wrote: * support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box); A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these? In my vision you could choose arbitrary number of these including the same item twice and then apply different curves to both instances. I'm not 100% how that can be implemented tho. * If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ? They would all have range of 0.0...1.0 just like random, velocity etc now in SVN. I think sin and cos could be implemented as a subcase of 'custom': a custom curve input. All these calculated axis would be a sort of custom. Allowing a free formula type is an option as well but It may be harder to implement. * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? I mean both. The dream is that paincore would only need to worry about painting a stamp at a given event, the where? part is all handled by paint core. The distance in this case is the stamp spacing. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for event mixed influence. Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and unsaved tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent. -- Alexia P.S redirecting back to list, ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
Hi, On Sat, 2008-06-07 at 14:51 +0200, [EMAIL PROTECTED] wrote: The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'. Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
On Sunday 08 June 2008 14:28:17 Sven Neumann wrote: On Sat, 2008-06-07 at 14:51 +0200, [EMAIL PROTECTED] wrote: The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'. Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers. And apparently nobody can really work on things whether interesting or not without a spec... So how about making a spec how this is SUPPOSED to be handled, and then hoping somebody interested enough comes along to actually implement it? With spec I'd say chances of that happening are tenfold, and odds of something usable coming out of it are at least 80%. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint core beyond 2.6
Hi Alexia, On Sun, Jun 8, 2008 at 6:18 PM, Alexia Death [EMAIL PROTECTED] wrote: * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? I mean both. The dream is that paincore would only need to worry about Yes, that's what I meant, sorry. painting a stamp at a given event, the where? part is all handled by paint core. The distance in this case is the stamp spacing. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for What you describe is redundant if you expose those separately... since they currently effect either color or opacity according to distance from start of stroke. That's why I said replicate. I think you could improve this idea a lot by making some mockups, where you can easily spot and eliminate unnecessary redundancies. (I'm certain that there are quite a few neither of us has noticed.) Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made This sounds pretty good! I'd like to suggest the use of bottom-scaling as well as top-scaling here: that is, allow the quick adjustment to either scale down like 0..1 becomes 0..0.5 (scale == 0.5) or scale down like 0..1 becomes 0.5..1.0 (scale - 0.5). I can certainly vouch that I've wanted this a lot of times for Size -- the minimum size ends up far too small sometimes. are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and unsaved tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent. Yes, mockup sounds like it would help. I think what you describe above doesn't yet warrant the description of creating new user-tools. Mainly because it does not support some things that are important at a tool-level: Hard Edge, Clone-like behaviour. Consider talking to peter specifically about this -- he has the 'Dabs of paint' idea, which IMO is more correct than associating settings with either a brush or a tool; In the same way that acrylic paint on a brush has quite different physics than watercolor paint on the same brush. What you are talking about might be called something more like a tool-tip (yes, unfortunate but accurate; how about pen-tip? paint-tip?) IMO a good distinction is like: * tool : what you are doing and how you are doing it * tip : the precise effect that occurs when painting * brush: the area and amount in which it is applied. * paint : all of the actual pixels that end up being applied. HTH, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
proposed spec: File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1] Add File/Import and Export to handle alien formats. File/New and File/Import would be very similar: they both create a new image with various attributes. New gets the the attributes from the dialog, Import gets them from the image file. Currently, File/New, OK, file/Close does not produce a nag. (good.) File/Import, File/Close would not nag. File/New currently does not name the image. That gets asked for on save. The same would apply to File/Import: it would not inherit the name. File/Save would default the name to Import name, but using .xcf instead of ext of Import. File/Export would default to the Imported name.ext and type. (example: File/Import foo.gif, File/Save prompts for name, defaults to foo.xcf. File/Export defaults to foo.gif) command line usage would still work with any format. but that only applies to 'loading' the file, not what it's name is. (i think all save/export cases are covered above) The only nag will be when trying to close a touched image that has not been saved (which by #1 would always be as .xcf) File/Preference option to turn off the you will loose info nag. Possibly some options to tune it, like Only nag if not saved in any format. (I have a feeling that is more confusing than it is worth, but would be easy enough to implement, and would save my ass when I accidentally close the wrong image window.) I am pretty sure there is a usability law that says an app should always warn before discarding data, so I am pretty sure there should always be the Save the changes to 'Untitled' before closing? nag. /proposed spec I think this would remove the need for all nags except save unchanged? It would add steps when using gimp to edit an alien format. current: gimp foo.gif, (or launch gimp, Open foo.gif), edit, Save, Close. proposed: gimp foo.gif, (or launch gimp, Import foo.gif), edit, Export, Hit Save button (filename defaulted to foo.gif)[2], Close, hit Don't_Save in respose to Save Unchanged...? Damm... there is still something that I am not sure how to handle: When Exporting, should it nag when you are overwriting an existing file? I think the answer is 'yes' which will add another step. I can see gimp being intelligent about this and doing the obvious thing (don't nag if using the default) but that might be crossing a line into automagic. maybe another Preferences option. One question: should gimps 'normal' behavior make it easy (minimum nags) to edit A) alien formats, or B) gimps native format? I am kinda liking the idea that gimp makes it easy to edit/save gimp images, and alian formats are derivatives, not the primary storage for images. Did I mis anything? Carl K ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
Carl Karsten wrote: proposed spec: File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1] Add File/Import and Export to handle alien formats. Save_as_Copy and Export are the same (the user should be able to export as .xcf). This approach shifts the problems from saving to opening. Additionally, the 'forced .xcf' behaviour can be quite nagging - consider user experience for a quick Levels adjustment to a photo: 1- Open doesn't work 2- Import 3- adjustments, all jpeg-compatible 4- Save only allows .xcf, which is overkill here 5- Step back to Export 6- remaining image mysteriously nags on closing Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic. To answer your question: please, A and B. Another idea i'm currently tinkering with: Don't all those export troubles disintegrate once we presume a little more confidence in the undo function? What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layersalpha being lost. This is much more intuitive than textual explanations... so long, peter -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
Sven Neumann wrote: Hi, On Sat, 2008-06-07 at 14:51 +0200, [EMAIL PROTECTED] wrote: The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'. Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers. That means it makes sense to work on a temporary solution before the big UI overhaul happens? Sounds like a good place to start hacking the gimp .- peter -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
[EMAIL PROTECTED] writes: Additionally, the 'forced .xcf' behaviour can be quite nagging - consider user experience for a quick Levels adjustment to a photo: [ ... ] Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic. For that workflow, what would be even more useful is to be able to have a command that could do both: save the current .xcf (.gz or .bz2) AND, from the same menu item or keystroke, save a copy to a simpler format. Then you wouldn't have to go back and forth between Save and Save a Copy every time you make a change, and you wouldn't have to confirm the copy's filename every time you saved it. It would be great if it were possible to write a plug-in that would do that, even if gimp didn't include it natively. It would need to get the current filename (that's easy already, gimp-image-get-filename) and also what the last save a copy filename was (not so easy -- I don't think there's an API to get that now, is there?) What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layersalpha being lost. This is much more intuitive than textual explanations... That trains users not to save intermediate results in some cases. Consider the case where you need to add text to a jpeg with the result being another jpeg for a website; yet you still might want to try several different fonts, text strings etc. I know, you're thinking Why not save the intermediates as xcf? But if there are only a couple of layers and fifteen minutes of work, it doesn't always seem worth the extra disk space to save an xcf in addition to the final jpg. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
