Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts enselic at gmail.com writes: On the developer meeting I got an action to create a draft of a roadmap. It can be found here: http://gimp-wiki.who.ee/index.php/GIMP_Roadmap It has has a list of features we prioritize, as well as a list of at what GIMP release we expect features to be available. It is quite influenced by my personal opinions of what we should prioritize, please take a look and add things you miss. If you disagree on priorities, please bring it up here so we can discuss it and reach consensus. / Martin Congrats! this is a much-needed step. Can I ask what non-destructive editing is? According to Adobe, this includes: * Color adjustment layers (such as levels, hue/saturation, threshold, etc) * filter layers (such as blur, sharpen, emboss, etc) * smart objects (i.e., ability to scale / rotate a layer as a single object, without changing its pixel data) Maybe this could be expanded upon and prioritized. I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. * Automate layer boundary management so that the user can draw on any point at any time and not worry about increasing the boundary * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) So, what do people here think? I believe all three are essential in making GIMP a faster and more hassle free tool. I can expand on these subjects if needed. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 3/1/11, Michael Grosberg wrote: I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. Wasn't it supposed to be done in 2.8 actually? Floating selections got some attention last year -- that's for sure. * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) http://gui.gimp.org/index.php/Transformation_tool_specification You will probably be nicely surprised :) 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] GIMP Roadmap - wiki page
On Tue, Mar 1, 2011 at 16:16, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/1/11, Michael Grosberg wrote: I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. Wasn't it supposed to be done in 2.8 actually? Floating selections got some attention last year -- that's for sure. * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) http://gui.gimp.org/index.php/Transformation_tool_specification You will probably be nicely surprised :) Wow! That's a great idea of one tool for many actions! +1 for me :) Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
On 1 March 2011 05:00, Roger Penn roger.p...@gmail.com wrote: work out all the how's and so-forth, but for now if anyone knows the inner workings of gimp-quit or why calling gimp.exe from the command line forks two gimp processes I'd sure be grateful for some insight. Thanks. I might be able to help a little on the forks-two-processes thing. My app does this as well, because Windows distinguishes between command-line and GUI .exes. When Windows launches a program from the shell, it checks a flag in the .exe to see if this is a command-line or a GUI program. If it's been tagged as a GUI program, it just gets started, but if it's been tagged as command-line, Windows will pop up a console and use that to display stdin and accept stdout for the program. Conversely, if you start a command-line program from the command-line, command.com will display stdout, pipe stdin, and wait until the program terminates before showing the prompt again. If you run a GUI program from the command-line, stdin/stdout for the program go nowhere and command.com will offer the prompt again immediately without waiting for the program to finish. As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop. The usual solution people recommend is to have a tiny wrapper .exe for command-line work. This is a program which is tagged as CLI and which when run starts the GUI .exe, linking that program's stdin/stdout back to the calling command.com, and then waiting for the GUI .exe to exit. So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh. John ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
On 1 March 2011 16:42, jcup...@gmail.com wrote: So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh. Just in case it is the wrapper that's broken, here's the wrapper program I use, written for me by a Windows expert friend: https://github.com/jcupitt/nip2/blob/master/src/nip2-cli.c Perhaps it might be useful. John ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/01/2011 03:23 PM, Michael Grosberg wrote: Congrats! this is a much-needed step. Can I ask what non-destructive editing is? According to Adobe, this includes: * Color adjustment layers (such as levels, hue/saturation, threshold, etc) * filter layers (such as blur, sharpen, emboss, etc) * smart objects (i.e., ability to scale / rotate a layer as a single object, without changing its pixel data) Maybe this could be expanded upon and prioritized. I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. * Automate layer boundary management so that the user can draw on any point at any time and not worry about increasing the boundary * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) So, what do people here think? I believe all three are essential in making GIMP a faster and more hassle free tool. I can expand on these subjects if needed. Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
* unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) http://gui.gimp.org/index.php/Transformation_tool_specification You will probably be nicely surprised :) Definitely surprised. It looks interesting. A different icon than the small circle for the rotation thing could help clarify its purpose (eg. a circle made out of two curved, opposite pointing, arrows?). I will have to read over the rest of the page more thouroughly. I'm a little uneasy at the moment about the ban working with numbers for transformations comment. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Hello, The nearly finalised project list for GSoC 2011 is available at the wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. GIMP on! ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
LightningIsMyName wrote: Users who have a comment on the list should raise it now. I did mention one possible GSoC idea was a rewrite of gimp-perl. The binding seems to be a bit of a mess and could stand some clean up. I may squeeze in a bit more time to make sure it at least works with 2.6 and git master but I won't attempt a rewrite until after I do some of the planned work for TinyFu version 2. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens ke...@ve3syb.ca wrote: I'm a little uneasy at the moment about the ban working with numbers for transformations comment. It would be nice (IMO) to have a dockable that displays the numbers of the transform tool's current selection and transform, and also applies numerical input to the transform tool. Photographers could ignore/hide the dockable entirely and still use the transform tool by feeling, and designers would have a method for performing precise transforms (for example a radial design needing several exact rotations). The spec for the tool looks pretty amazing though ;) Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
jcup...@gmail.com wrote: I might be able to help a little on the forks-two-processes thing. My app does this as well, because Windows distinguishes between command-line and GUI .exes. Could you have Windows start GIMP as a GUI program but pass -i to GIMP to stop it from opening up its windows? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
I'm a little uneasy at the moment about the ban working with numbers for transformations comment. It would be nice (IMO) to have a dockable that displays the numbers of the transform tool's current selection and transform, and also applies numerical input to the transform tool. Photographers could ignore/hide the dockable entirely and still use the transform tool by feeling, and designers would have a method for performing precise transforms (for example a radial design needing several exact rotations). How about having (hideable of course :)) on-canvas infos? IMHO that would be even fancier. Infos could be aligned with control that modifies them. Numerical input could be done similarly on-canvas. I think hovering pointer above e.g. rotation control and clicking middle button (?) could activate input (displayed on the place). That way we'd save considerable ammount of mouse movement between canvas and dock. To make things even more unobtrusive input could “slide” after activation to some place on the screen (bottom of the screen) util value would be entered and whole control could be hidden. Well… there's the thing about this being fast, but I think that's what new, fancy compositioning infrastructures are for ;. It seems to me like a reasonable application of new capabilities. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. Great to have such list! :) I've got a word about slicing tools. I think it would be even nicer if slices as that: --- | - | | | | | | - | --- didn't have to be considered as nested. If they'd be treated as independent entities it would be easy to have e.g.: - | | --+---+-- | | | | | - | | | - Each slice could have, as one of properties, list of layers brought into account when generating final slice image. That way one would be able to easily “cut” some slice for background, even if the background is overlayed with some content. Furthermore, slices could have been able to create “stacks” of graphics exported as one image. I mean a situation when “idle” for of menu is on one layer, “hover” on another and finally “clicked” on third. So: one slice is created, “stack” for that slice is defined in such a way that first layer is topmost part of exported graphics, second layer is the middle and so on. It would give from single slice final image of: --- |idle | +-+ |hover| +-+ | clicked | --- Vertical alignment is choosen purely for the example's sake. Heck! One could even make some tool to visually place such images from different slices. Details remain to be discussed :). I think that gain from such solution is great. This way one could easily create not only menus but also sets of icons cropped from source image with css. And to do it without creating another image or layer on page layout project with icons packed accordingly, but “cut” them directly from layout. Elements could be then placed only once, so possibility of making a mistake while exporting them would lower considerably. That's just a couple of simple things that “traditional” slices make somewhat horrid to achieve :). I'd love to see something like that in GIMP! :D Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
Your mention of a wrapper made me wonder, what? where? I don't believe there was any such thing in the GIMP 2.0. So I looked in the bin directory and lo and behold! gimp-console-2.6.exe. Apparently now there are separate executables for GUI and console use. Either there weren't before, or the pre-compiled binary distro I used didn't include the console version. I called this from the web page instead of gimp-2.6.exe and problem solved! I think the official GIMP documentation needs to be updated to reflect this. All the same, thanks for sharing your friend's wrapper. I will check it out just in case there are further issues, and it may come in handy for someone else as well! Thanks everyone for taking the time to be so helpful and for the really useful advice. On Tue, Mar 1, 2011 at 8:47 AM, jcup...@gmail.com wrote: On 1 March 2011 16:42, jcup...@gmail.com wrote: So it sounds to me, though I've not checked and this is just a guess, that the Windows wrapper .exe is not terminating correctly in the new gimp. Also, this is from memory of looking into this a few years ago, I've probably messed up the details, argh. Just in case it is the wrapper that's broken, here's the wrapper program I use, written for me by a Windows expert friend: https://github.com/jcupitt/nip2/blob/master/src/nip2-cli.c Perhaps it might be useful. John ___ 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] GIMP Roadmap - wiki page
Hi, ense...@gmail.com (2011-03-01 at 2214.48 +0100): Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap Please pick a different name that trully combines both things then, assuming they are combinable. Adjustment layers is already a standard term (de facto from another app, yeah, impossible to change that now) for a layer that only has a mask and applies per pixels changes like hue or level changes. Not only confusing, but hard to see the relation between adjusment and render grid, for example, which is probably what you mean with filter. Thanks. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/02/2011 04:33 AM, GSR - FR wrote: Hi, ense...@gmail.com (2011-03-01 at 2214.48 +0100): Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap Please pick a different name that trully combines both things then, assuming they are combinable. Adjustment layers is already a standard term (de facto from another app, yeah, impossible to change that now) for a layer that only has a mask and applies per pixels changes like hue or level changes. Not only confusing, but hard to see the relation between adjusment and render grid, for example, which is probably what you mean with filter. Thanks. I've changed Adjustment layers to 'Layer filters' for now, and added Layer effects. Ideas for better names are welcomed. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I can remember there was an intention to rewrite iwarp plug-in as a tool... Kevin Cozens wrote: LightningIsMyName wrote: Users who have a comment on the list should raise it now. I did mention one possible GSoC idea was a rewrite of gimp-perl. The binding seems to be a bit of a mess and could stand some clean up. I may squeeze in a bit more time to make sure it at least works with 2.6 and git master but I won't attempt a rewrite until after I do some of the planned work for TinyFu version 2. With respect, Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Chris Mohler cr33dog at gmail.com writes: On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens kevin at ve3syb.ca wrote: I'm a little uneasy at the moment about the ban working with numbers for transformations comment. It would be nice (IMO) to have a dockable that displays the numbers of the transform tool's current selection and transform, and also applies numerical input to the transform tool. I have a somewhat different solution for this. When you start messing around with perspective transform and you drag corner points every which way, scale and rotate numbers become meaningless. So, Precise numbers are not that useful for a free transform tool anyway. GIMP could simply keep the existing separate transform tools, but instead of displaying them as icons in the toolbox, keep them in their own sub-menu under edit--transform or something. The only difference would be to make them behave like one-off dialogs, so once you're done with transforming whatever it is, the UI reverts to the last selected toolbox tool. That way you could still have access to precise transformations for those who need them while not encumbering the more casual users with the numerical info. You've got a similar solution in Inkscape, Where the select tool also does Transformations by default with no numerical input, but there is also a dock for transforming objects numerically (there are tabs for separate actions, so each transform command is separate). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 1, 2011 at 22:52, LightningIsMyName lightningismyn...@gmail.com wrote: Users who have a comment on the list should raise it now. Sven had some time ago the idea of a PDB to D-Bus bridge. Wouldn't that a nice GSoC project? Regards, Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
