Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 03/24/2010 03:21 PM, Karl Günter Wünsch wrote: On Wednesday 24 March 2010, Alexandre Prokoudine wrote: On 3/24/10, Karl Günter Wünsch wrote: This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? I would imagine by holding down the ALT key -- a necessary precursor to actually using the mnemonic keystroke and thus a logical, intuitive, and discoverable action. If it is OK to presume that a user already knows that the ALT key is associated with accessing menu items (this association had to be learned somehow, it is not intuitively obvious), what is wrong with presuming that they will likewise learn that holding down the ALT key will reveal the underlined letters? Quoting Jason Simanek jsima...@gmail.com: The shortcuts should definitely be shown while using the mouse. Who came up with this idea? I know this isn't the GTK+ mailing list, but seriously, how is this an improvement? Were the drop down menus getting too wide with the included shortcuts? Were they interfering with legibility? Why are they trying to fix problems that don't exist? The mnemonics are unrelated to GIMP's keyboard shortcuts (which will still be visible in the menus, unless the user has specified otherwise in his gtkrc). Personally, I never use the menu mnemonics in GIMP because keyboard shortcuts are much more efficient and are also dynamically configurable (surely hitting the + key is simpler than ALT+V, ALT+Z, and ALT+O). To me, having random letters underlined in menus and dialogs is just visual noise cluttering up the interface. As a final note, the attention given to discoverability for facilitated access to commands or advanced features need not be so strict as that for normal workflows. If there is an easily discoverable way to accomplish a task (e.g., through the menus) then there is nothing wrong with a more convenient method also being provided which might not be readily apparent (perhaps only learnable by reading the manual or tutorial). Advanced users will learn to avail themselves of such optional conveniences without requiring prompting from talking paperclips or animated walkthroughs, and the neophytes are better off not being confronted with the additional complications. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC (Student Suggestion) - Visual Scheme Editor
Hi, I would like to create a Visual Scheme Editor for the GIMP to allow users with little or no programming knowledge to quickly and easily create a script. The simplicity of Scheme makes it (in my opinion) the ideal import/export language for Visual Programming. The editor (ideally) would allow users to drag-and-drop procedures from a procedure list into the editor. I envision the editor as representing each procedure as a box. Boxes can be nested inside of other boxes to be passed as arguments. Common procedures would be given icons and a help bubble. To reduce boiler-plate, the user would be presented with a table to fill in the additional information needed for a script (author, date, copyright, etc.) Obviously this is quite an ambitious project, and thus I would try to focus on just the essentials. Also, I have never programmed with GTK+, glib of gobject before. ~ Andrew Simmons ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 03/25/2010 01:00 AM, saulgo...@flashingtwelve.brickfilms.com wrote: The mnemonics are unrelated to GIMP's keyboard shortcuts (which will still be visible in the menus, unless the user has specified otherwise in his gtkrc). Wait. I thought they were using the word 'mnemonics' to mean what is commonly called 'shortcuts'. I see now that what was meant by 'mnemonics' was the underlined letters in menu items. As I understand it, these underlined letters are only useful if you are navigating the menus via keyboard. Well, making those visible only when navigating the menus by keyboard makes sense. Pardon my confusion. The UI-world use of the words 'mnemonic' and 'shortcut' seem confusing to me, since the functionality of the two in this case is very similar. I would call that a misuse of the word 'mnemonic'. But this isn't a debate about language use. Advanced users will learn to avail themselves of such optional conveniences without requiring prompting from talking paperclips or animated walkthroughs, and the neophytes are better off not being confronted with the additional complications. I don't think that philosophy applies to the presence of keyboard shortcuts next to the names of menu items. These subtle bits of additional information are a different species than talking paperclips. One is helpful but not intrusive. The other is condescending and intrusive when on by default. In my experience 'neophytes' or non-expert users don't even notice that the shortcuts are there. I have people at work that supposedly work on computers every day that don't know the keyboard shortcuts for copy/paste. For some it seems the GUI is filled with lots of small details that they don't comprehend, so they just ignore those details and continue working to the highest level of efficiency that they are capable. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Hi:) The basic behavior of this tool would be: - you put a closed polygon on the image (not limited to 4 handles) - you deform the cage, the image is deformed accordingly - user can choice if the pixels can go outside of the cage or not. In the normal behavior of the Green Coordinates, the pixels can overflow the cage, due to the shape preservation. I looked through the paper and examples there were very impressive. This tool can be the tool of choice for many use-cases currently handled by iwarp plugin and perspective transform in a much more convenient and usable way. As a project it has great potential. Im thinking, it might make sense to implement it as a gegl op with UI in gimp. however, we dont have an example of such tool yet... Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? js -- -- --Alexia ___ 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] GSOC proposal: cage-based transform tool
On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? Could you point me to the plug-in? I don't think Ive seen it before -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
http://liquidrescale.wikidot.com/en:tutorial But the behavior and the goal of this tool is rather different from mine. 2010/3/25 Alexia Death alexiade...@gmail.com On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? Could you point me to the plug-in? I don't think Ive seen it before -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
On Thu, Mar 25, 2010 at 1:23 PM, Alexia Death alexiade...@gmail.com wrote: On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? Could you point me to the plug-in? I don't think Ive seen it before http://liquidrescale.wikidot.com/ It does the trick thatadobe sohowed off in the new photoshop yesterday -- it is quite well maintained - I keep the .pt_BR translation for it. Give it a try, it is worth it. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
http://liquidrescale.wikidot.com/ It does the trick thatadobe sohowed off in the new photoshop yesterday -- it is quite well maintained - I keep the .pt_BR translation for it. Give it a try, it is worth it. Will do, but it only seems to do the rescale part of it, not the cleanup part it seems. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 3/25/10, gg wrote: This is default behaviour on Windows. LOL It must be the right thing to do then ! If you made an effort of reading things in context, you wouldn't LOL, because there is nothing to LOL about. I strongly suggest you open a bug on GTK+ about this. +1 Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer