Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
Quoting Sven Neumann s...@gimp.org: just forwarding a few aspects of the GTK+ 2.20 release notes that are of interest for GIMP: GTK+ 2.20.0 is now available for download at: : : : Congratulations and a lot of thanks to the GTK+ team for this release. Though perhaps minor, the improvements made to the keyboard mnemonics (the underlined letters in menus and dialogs) seem very elegant and intuitive. From the description on http://blogs.fedoraproject.org/wp/mclasen/2010/03/24/mnemonics/ : * no mnemonics are shown when menus are opened with the mouse * interacting with the menus via the keyboard (opening a menu with keyboard shortcut, or navigating with arrow keys or similar) will make mnemonics visible * mnemonics which cannot be activated are not shown; this includes insensitive controls * moving the mouse over a non-activatable menu item does not change which mnemonics can be activated Thank you, GTK+ team. ___ 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/24/2010 10:00 AM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Sven Neumann s...@gimp.org: just forwarding a few aspects of the GTK+ 2.20 release notes that are of interest for GIMP: GTK+ 2.20.0 is now available for download at: : : : Congratulations and a lot of thanks to the GTK+ team for this release. Though perhaps minor, the improvements made to the keyboard mnemonics (the underlined letters in menus and dialogs) seem very elegant and intuitive. From the description on http://blogs.fedoraproject.org/wp/mclasen/2010/03/24/mnemonics/ : * no mnemonics are shown when menus are opened with the mouse * interacting with the menus via the keyboard (opening a menu with keyboard shortcut, or navigating with arrow keys or similar) will make mnemonics visible * mnemonics which cannot be activated are not shown; this includes insensitive controls * moving the mouse over a non-activatable menu item does not change which mnemonics can be activated Thank you, GTK+ team. This feature: * no mnemonics are shown when menus are opened with the mouse is quite UNfortunate and to my way of thinking, inappropriate. IMHO the way people learn the mnemonics is by seeing them. It is the mouse-users that most need (should) learn them to increase their productivity and reduce visits to the doctor for mouse shoulder. Just my 2 øre worth Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Doubt in Google Summer Of Code Idea
Sven Neumann wrote: On Tue, 2010-03-23 at 21:30 +0100, Martin Nordholts wrote: The GIMP menu structure is a beast. But each item is well documented, in particular there are tooltips for most of them. The idea is to make the menu item labels and the descriptions of them searchable. It could be a text entry in the menu bar for example. It could be a text entry that replaces the menu-bar triggered by a keyboard shortcut, similar to how you can switch from the path-bar to a location entry in the file-chooser. Or it could be a UI that overlays itself on the image. The current work on the text tool UI shows what's possible in this respect with newer versions of GTK+. Would be nice to get some input from Peter on this subject. With a little help from the guiguru, this could turn out to become a very useful change to the GIMP UI. well, I have still mixed feelings about the whole plan. if there is a need for search in a menu structure, then how well is that menu structured? it really sounds to me like signalling UI design defeat, and sticking a band-aid (search) on it. however, going much further makes it useful. searching tooltips is one thing, digging into the manual is next. going further is needed before thinking about the UI. --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] wiki down...
Sven Neumann wrote: On Mon, 2010-03-22 at 23:11 +0300, Alexandre Prokoudine wrote: On 3/22/10, Sven Neumann wrote: Yes, it's down for a while already. I can't host this service any longer and already offered a backup on IRC for anyone who wants to take over. So far no one approached me asking for the data. I have over a gig of free space on my virtual server. What versions of PHP/MySQL are required? The current setup uses PostgreSQL 8.1.8 and MediaWiki 1.9.3. The PHP version on this server was recently upgraded from 5.2.11 to 5.3.1. Since this update the gui.gimp.org wiki is down, because the MediaWiki installation appears to be incompatible with this newer version of PHP. so that is what happened... If you are still interested in taking over, and if Peter agrees, I can make the database dump and a backup of the mediawiki installation with all uploaded images etc. available. yes, I do agree to getting gui.gimp.org (as-is, and under that address) running again a.s.a.p. --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] [Fwd: GTK+ 2.20.0 released]
On Wednesday 24 March 2010, saulgo...@flashingtwelve.brickfilms.com wrote: * no mnemonics are shown when menus are opened with the mouse * interacting with the menus via the keyboard (opening a menu with keyboard shortcut, or navigating with arrow keys or similar) will make mnemonics visible * mnemonics which cannot be activated are not shown; this includes insensitive controls * moving the mouse over a non-activatable menu item does not change which mnemonics can be activated This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? By seeing them when using the menu with the mouse - this is a sub conscious learning process going on, you see it the first time, the second time, the third you don't use the mouse but the keyboard because you remembered that this function is available via a shortcut without having to resort to the mouse. With this enabled you'll never find out and thus you have to replace an automatic sub conscious process with a conscious effort - something most people will not endeavor to do and is for the most part less effective. Thank you, GTK+ team. Yes, thank you for getting rid of a valuable function in a very unelegant way and making life harder for people to understand how to interact with complicated software! I just hope this can be deactivated even in a few years time, for the time being the setting gtk-auto-mnemonics = 0 will be added permanently to my ~/.gtkrc-2.0 - if that should ever disappear I'll phase out any application that uses GTK - even if that means switching to windows for my photo editing needs. But digikam is reaching maturity, maybe it's there when this bonkers development becomes standard, I'm already on the verge of giving up on the GIMP as it can't remember the last settings in many dialogs after a restart or even from one dialog invocation to the next - I'm getting fed up to reenter for example my copyright comment over and over even if I don't leave the GIMP when saving the edited image for publication. Little things like this menu change may push me over the edge and make me - and many of my friends, which I have supported over the years when editing images with the GIMP - dump it for good... regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Doubt in Google Summer Of Code Idea
On Wed, 2010-03-24 at 17:55 +0100, peter sikking wrote: well, I have still mixed feelings about the whole plan. if there is a need for search in a menu structure, then how well is that menu structured? We have tons of plug-ins and the user may install even more. It is almost impossible to structure them perfectly in a menu hierarchy. however, going much further makes it useful. searching tooltips is one thing, digging into the manual is next. That was mentioned from the very beginning. Of course searching in just the menu labels is not of much use. The search would include the tool-tips text of course. Combining this with a search in the manual is however taking this way too far. Then it can't be a GSoC project any longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Tue, 2010-03-23 at 23:03 +0100, Merkelvin Glasmer wrote: I just have two questions about the future of the implementation of GEGL into The GIMP: 1. I read on different websites, that in future it will be possible to open RAW image formats of different camera manufacturers natively in GIMP without the requirement of additional software. Is this true? If you don't consider a plug-in additional software, then you can already do that today. The difference with a GEGL-enabled GIMP is that you can then work in the higher color-depths that the RAW format offers. Today the RAW image is converted to 8bit per color channel on import into GIMP. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Wednesday 24 March 2010, Sven Neumann wrote: If you don't consider a plug-in additional software, then you can already do that today. Sorry but I would consider this solution quite inadequate as higher color depths account for much of the leeway expected from using RAW image formats in digital cameras... The difference with a GEGL-enabled GIMP is that you can then work in the higher color-depths that the RAW format offers. Which only means that a GEGL enabled GIMP with appropriate input filters is the only way forward in this respect. regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On 3/24/10, Karl Günter Wünsch wrote: The difference with a GEGL-enabled GIMP is that you can then work in the higher color-depths that the RAW format offers. Which only means that a GEGL enabled GIMP with appropriate input filters is the only way forward in this respect. Fortunately ACR, smart objects et al. are not the only acceptable way of dealing with Raw files :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Wed, 2010-03-24 at 20:11 +0100, Karl Günter Wünsch wrote: On Wednesday 24 March 2010, Sven Neumann wrote: If you don't consider a plug-in additional software, then you can already do that today. Sorry but I would consider this solution quite inadequate as higher color depths account for much of the leeway expected from using RAW image formats in digital cameras... Well, if you ever looked at the UFRaw Import Plug-in, you'd know that it gives you a lot of control over how the conversion to 8 bit is done. So you already get most of the benefits of the RAW format. It's just somewhat uncomfortable that you have to do all the color and exposure correction at the import step. The difference with a GEGL-enabled GIMP is that you can then work in the higher color-depths that the RAW format offers. Which only means that a GEGL enabled GIMP with appropriate input filters is the only way forward in this respect. Sure. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC proposal: cage-based transform tool
Hello, I'm Michael Muré, a French student in computer science. I'd like to propose a GSOC about a new cage-based deformation tool. This tool wil be based on this paper: http://www.math.tau.ac.il/~lipmanya/GC/gc_techrep.pdfhttp://www.math.tau.ac.il/%7Elipmanya/GC/gc_techrep.pdf(Siggraph 2008) 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. Unlike the other classical method (mean value coordinates, harmonic coordinates, ..), the Green Coordinates allow high quality deformation by preserving the shape. That mean that you don't have side effect like shear. Example can be found in the paper. However, a restriction, the figure 14 show a deformation of the outside of the cage, that require a cutting of the outside. I think that's not relevant for a software like the Gimp. That was for the presentation. I would really like some advise or opinion of the community, to improve my proposal. For instance, I've some question: - Since the GC is affine-invariant, it can do rotation and translation as well. However, it is less efficient than this simple tools. Should this tools be merged in the same tool ? - Generally speaking, I'm not sure about the best UI solution - Concerning the code, I'm a bit rookie with the code base of the Gimp. I usually follow more the Blender's development. Any hint or advise or thing to know would be appreciated. Regards Michael Muré ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Wednesday 24 March 2010, Sven Neumann wrote: Well, if you ever looked at the UFRaw Import Plug-in, you'd know that it gives you a lot of control over how the conversion to 8 bit is done. So you already get most of the benefits of the RAW format. It's just somewhat uncomfortable that you have to do all the color and exposure correction at the import step. The problem is that I recently read about the scaling problems in any non- linear colour space and as a result have tried scaling some of my images in a 16 bit linear colour space - with stunning results. So UFRaw helps with the first problem of doing the conversion but 8 bit GIMP is messing up things later in the editing process... For the moment I am living with the results but now knowing how much better they can look without having to compensate late in the editing process having a workflow which would start with the 14 bit depth my camera provides per colour channel and never drops to a non linear colour space before the final save to JPEG would be preferred and I hope that a GEGL enabled GIMP will do so in the forseable future... regards Karl Günter Wünsch ___ 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/24/10, Karl Günter Wünsch wrote: This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? This is default behaviour on Windows. The majority of GIMP users (up to ~90% in my country) are on Windows. What was your question again? :) Alexandre ___ 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
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... -- --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 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? This is default behaviour on Windows. Which is the first thing I disable on any Windows installation I do and the users are happy about that. regards Karl Günter Wünsch ___ 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/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? This is default behaviour on Windows. Which is the first thing I disable on any Windows installation I do and the users are happy about that. 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? What percentage of users navigate the menus via keyboard? To me beginners use the mouse to navigate the menus. Experts use keyboard shortcuts. People that are unable to use the mouse use the keyboard to navigate the menus until they learn the shortcuts. It is very awkward for me to learn the keyboard shortcuts if they aren't visible during mouse navigation. I never use the keyboard to navigate the menus. Just my two cents. -Jason Simanek ___ 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/10 05:02, Jason Simanek wrote: 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? This is default behaviour on Windows. LOL It must be the right thing to do then ! Which is the first thing I disable on any Windows installation I do and the users are happy about that. 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? What percentage of users navigate the menus via keyboard? To me beginners use the mouse to navigate the menus. Experts use keyboard shortcuts. People that are unable to use the mouse use the keyboard to navigate the menus until they learn the shortcuts. It is very awkward for me to learn the keyboard shortcuts if they aren't visible during mouse navigation. I never use the keyboard to navigate the menus. Just my two cents. -Jason Simanek I think your points are entirly valid, this is a bad direction to go in. I strongly suggest you open a bug on GTK+ about this. They are pretty intractable and refractory to any outside suggestions that they may not have made the best choice BUT if no one flags this sort of stupidity it certainly will not get fixed. While there is some overlap of gimp and gtk+ developers since it was originally gimp tool kit, the two are basically separate now, so please bug gtk+. ;) Post a link to the bug here if you like and I'll give it a comment if I can add anything. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
