Re: [Gimp-developer] input from the UI team needed
Martin Nordholts wrote: Hello Just wanted to mention this since it appears if you haven't noticed it: You can already now do what you are asking for: 1. Make an arbitrary selection 2. Select - To Path 3. Use the Path Tool to edit the created path 4. Select - From Path I already know it :). Now these sequence is rather long. In order to edit already existing selection as a path, next actions are required: 1. Selection to path 2. Select last selection from selections tab and make it visible. This step is not straightforward and quick. 3. Choose path tool and start editing... I understand there should be the separate selection to path action, and there should be an ability to edit a path not affecting existing selection. But could the 1. and 2. actions be merged into one additional menu item to make the things quicker? The existing selection to path can be renamed into Copy selection to path, and Move selection to path or Convert selection to path can be added. The last should create a path from the selection, clear the selection and make the path ready for editing. Optionally it can switch to the path tool too. The Polygonal Select Tool should IMO only fill the void of a way to quickly make polygonal selections. (If it will even be a separate tool and not just en enhancement to the Free Select Tool.) OK, I understood. -- 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] toward a plan for 2.8
Sven wrote: I think you misunderstood Peter's talk. These are the top 10 user requests, not the top priorities. It is very important to analysize user requests but it would be wrong to use this list as the basis for a discussion about the future roadmap. This should happen based on the product vision. right on. top-10 (as felt by the developers) user requests of the last years. and at the lgm we addressed them as well as we could at that time (printing? what can we say about printing? OK, a couple of things...) --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
Martin Nordholts wrote: Hello Just wanted to mention this since it appears if you haven't noticed it: You can already now do what you are asking for: 1. Make an arbitrary selection 2. Select - To Path 3. Use the Path Tool to edit the created path 4. Select - From Path I already know it :). Now these sequence is rather long. In order to edit already existing selection as a path, next actions are required: 1. Selection to path 2. Select last selection from selections tab and make it visible. This step is not straightforward and quick. 3. Choose path tool and start editing... I understand there should be the separate selection to path action, and there should be an ability to edit a path not affecting existing selection. But could the 1. and 2. actions be merged into one additional menu item to make the things quicker? The existing selection to path can be renamed into Copy selection to path, and Move selection to path or Convert selection to path can be added. The last should create a path from the selection, clear the selection and make the path ready for editing. Optionally it can switch to the path tool too. The Polygonal Select Tool should IMO only fill the void of a way to quickly make polygonal selections. (If it will even be a separate tool and not just en enhancement to the Free Select Tool.) OK, I understood. -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] sponsoring new project
I would like to sponsor(budget ca. 800-900$) a new open source (GPL) linux project - gkiosk. It should be a Gnome photo kiosk program, smth. like this: http://xkiosk2.sourceforge.net/ - this program could/should be used as a start point. things to add: 1) basic image edit functions, like (rotate, zoom, crop, move, redeyes removal, color adjusting,black white, sepia, brightness and contrast etc. - all the standard stuff that can be taken from any open source photo manager like f-spot or any other). 2) adding custom templates/text to an image 3) calculation of the price of an order - for customer(to show before finishing the order) and for kiosk owner(printing expenses for bookkeeping) 4) automatic ftp upload of the order to the ftp server of the printing lab. optional: 5) basic centralized bookkeeping via php/mysql script: once an order is made - it should be recorded in a central MySQL-DB. A simple php script should be created to allow the kiosks owner to see the records. bids: http://www.getacoder.com/projects/gkiosk_68339.html or contact me directly: [EMAIL PROTECTED] thank you ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Size entry widgets could use some simple math (from Bug: 76616)
From: Fredrik Alstromer [EMAIL PROTECTED] As requested, I'm moving this discussion to the mailing list... for the history, see the bugzilla entry 76616. I don't have anything to say about how this should work, but I'd like to make some suggestions about the approach to development. Mostly it should be possible to do this in a modular way -- evaluating expressions doesn't really have anything to do with the details of size entries. So I suggest your effort should go into writing a function that looks like gchar *gimp_math_expr_parse (info, expression) where info is a structure containing any information you need to do the parsing (resolution, image dimensions, whatever), and expression is the string entered by the user. The code could go into new .c/.h files either in libgimpwidgets or perhaps libgimpmath. That way, the size entry code can simply call the function to evaluate the string before using it. It would perhaps be possible to set up the infrastructure for this in the trunk development branch, that is, to create the files and have the size entry code call the evaluation function, but with the function initially just returning expression unchanged. If it were done this way, it would be possible for you to work without worrying much about changes in the size entry code -- which, as Sven has pointed out, needs improvement in several respects. Please don't take the details here too seriously. The function name and form were written on the fly, without any serious thought. The only real point is that the code should be factored. (And if I'm saying things that you had already planned to do, I apologize, but it didn't come through clearly.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
