[Gimp-developer] Progressive escalation of help
[Repost after a list resurrection] As far as I understand, one of the principal usability features is a progressive escalation of help. One does not want to drink from a fire hydrant - unless any other option is exhausted. One always wants as little help as possible - as far as it DOES help. In manuals, it appears, e.g., as distinction of user manual and reference manual (2 stages of escalation; if manuals are good, they have stages of escalation inside them as well). In GUI, it is usually 3 stages: Toolbar icon --- Couple-of-words in a tooltip F1 to manual Couple-of-words on a - Short sentence F1 to manual a button or menu entryin a tooltip or a slider label In Emacs, it appears as a requirement that the first line of documentation of a function/variable should be readable by itself. To make a long story short: 3 stages is, of course, not enough - especially with applications which target SIMULTANEOUSLY professionals and first-time-Linux-users. (And many components of GIMP have as little as 1 stage; consider user controls of script-fu-register.) How to create extra stages without making users to learn new paradigms? If you think about it for a second, the solution would jump at you: tooltips should be gradually extensible - when you press F1 with a tooltip shown, the tooltip should expand to the next level; when all the levels are exhausted, it should start the manual viewer. Tooltips which know how to expand should have a visual feedback. (IMO a small square with F1 in UR corner should be enough.) Tooltips which would expand to manual should be also visually distinguishable (with something like Press F1 to view manual, as in GIMP - only in GIMP, this message is completely borken). What is the least intrusive way to introduce this to GIMP? What about: 0) Remove Press F1 to view manual from tooltips unless GIMP knows that a manual is present, and knows to which page to jump. (Most annoying when GIMP already failed to start a manual system, and/or when a tooltip is shown on a Script-Fu UI element which DEFINITELY has no idea how to show a manual.) 1) Allow the UI-strings in script-fu-register to be lists instead of strings. A list entry may be a string (to show as a tooltip), a list of the form (URL http://...;) - for the last element (may be a relative URL w.r.t. user manual, as in (URL manual:gimpedit_paste) 1a) Optionally: allow list entries of the form, e.g., (chrome path_to_icon) to show iconic labels on SF-FOO UI elements, and/or combine icons with text on menu entries. 1b) Lastly, allow one to inspect whether this functionality is present, so one can write (script-fu-register my-foo My Foo (my-escalating-help Do Foo in all the corners Longer help ...) ... Same with SF-BAR labels ) with my-escalating-help() returning the full list, or the first element depending on what script-fu-register understands. 2) When this is implemented (is not it a very minor change?), start to add gradually escalating help to GIMP itself. What do you think? Ilya ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Would single-window fix usability nightmares?
[Repost after a list resurrection] I've read through the discussion of (a possibility of) a single-window GIMP interface. Both on the mailing list, and on http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses. When the windows are merged into one, STILL only one of subwindows has a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)? [Myself, I do not use PhotoShop, but what I saw is people who use both PS and GIMP say that PS allows about 3x times quickier UI interaction - in large respect due to no need to fix mis-focus.] I mean here the [rare?] cases when GIMP caught up with particular features of PS, so one can compare not feature sets, but how convenient is it to perform the operations... And if a solution to this problem is found, why would not it work with multi-window interface too? Or is the improvement ONLY in the fact that utility windows will never obscure the image? === BTW, if one considers single-window interface as just a fix for UI interaction slowness, I see no problem with editing multiple files: just have a single-window interface open for each of them. If this turns out to be important: to make things take less screen space, one could allow utility docks to shrink on unfocussed windows... Yours, Ilya ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
On Fri, Oct 2, 2009 at 10:25 AM, Ilya Zakharevich wrote: a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)? Lemme guess - you are on WIndows? :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
Ilya Zakharevich wrote: However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses. the introduction of a single window mode is in no way related to that. When the windows are merged into one, STILL only one of subwindows has a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)? that is a serious bug. in what version(s) of GIMP does this happen? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
Ilya Zakharevich wrote: To make a long story short: 3 stages is, of course, not enough - especially with applications which target SIMULTANEOUSLY professionals and first-time-Linux-users. I understand first-time-Linux-users as really newby linux desktop users, not beginner-GIMP-users (we have no priority to design for the latter). the help is there to help with GIMP functionality. not to help with the minimal differences of the linux desktop with mac and windows UI. so I am a bit stuck where the point is... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Akira wrote: [1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here: http://sourceforge.jp/projects/gimp-painter/releases/ I remember and checked: we discussed this in july 2008. even our brush mistress Alexia Death chipped in: GIMP is an image manipulation program (including wild brushwork over collages of found images) but not a paint-from-scratch app. so I am sorry. no additions solely for digital-artists. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
peter sikking wrote: so I am sorry. no additions solely for digital-artists. Many people (and really I mean many) use Photoshop or GIMP, the closest open source equivalent program, for paint-for-scratch work even though they're really not suited for this job. This is because almost all specialized programs (included the famous Corel Painter) fail in so many aspects of raster image processing/editing that their advantages in artistic use are quickly overshadowed by them. GIMP may be headed to other directions, but I believe there is a strong demand for such features which cannot be ignored, as demonstrated for example by this mixing brush source code patch I linked in my previous post or Ramon Miranda's Gimp Paint Studio resource collection. Perhaps a more advanced brush engine in the future can overcome the current limitations without expressly introducing digital-artist-only features? Not really a question, just a hope. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
On Friday 02 October 2009 18:47:46 Vio wrote: This would suggest a permissions problem, but I'm not sure. I wonder: does Gimp need to write to the user home directory by any chance? In that case, 'www-data' (the apache user) doesn't have a home directory per se. Gimp needs a place IIRC designated by the $HOME env variable to have its user settings. Ive never tried what happens if is not there even to read, but Im not surprised it does not work. You cant try this out by running the command you have in the rights of www-data using sudo. you should have a clear picture what happens. --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
On 10/02/2009 05:47 PM, Vio wrote: gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE /path/to/image/to/proces.pdf )' --batch='(gimp-quit 1)' doesn't get executed. Or it does but fails silently - which is not very helpful here !! Does it help if you set the GIMP2_DIRECTORY environment variable to /tmp/gimpdir? / Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
On 10/01/2009 07:46 PM, peter sikking wrote: meanwhile, can the overlay thing be repaired file-backward-compatible? If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice but to fix it somehow. Probably by having a legacy compositing mode also when using GEGL. Making GIMP 2.6 XCF files not openable in GIMP 2.8 isn't an alternative. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Martin Renold wrote: [cut] But those brush modes would copy the composited image into the current layer and brighten it there. The result would look on the screen as if you had flattened the image first. If I understood you correctly, this is exactly what you proposed in your footnote? Yes, I meant exactly this! Of course it would be an optional setting. David was somewhat enthusiastic about this, but I'm still wondering whether this would not result in some major annoyances, compared to layer modes? I still think layer modes (or layer operations) have their place, especially if they involve pre-made resources (for example the Overlay layer mode I wrote about in my previous post in my case is used mainly to apply subtle textures to areas painted on lower layers, for example paper/canvas texture). When you make invisible a layer below the one you used to brighten the image, you would see the (faint) image structure from the hidden layer because some of it was copied while brightening. Would this be no big issue? Now that I think about it, you're right, this could be a problem depending on the situation. Would it be important to also be able to manipulate (eg. brighten) the current layer only, in the way that brush modes work right now in GIMP? I think it would be important/useful to be able to affect only a limited set of layers. I think that layer groups/trees, which will be implemented in the 2.8 version of GIMP will add this capability (if a priority system based on layer position within the tree will be implemented. By the way, this is where GEGL is heading, from what I know). I understand if you're more interested in GIMP than in MyPaint, but I am still interested whether this would be compatible with your workflow... It appears it would be. Some issues would have to be sorted out though. By the way, this side-discussion started because on Photoshop CS4 I can use different painting modes even on totally transparent areas (if there is nothing in the background, then the brush behaves as if the painting mode is Normal), while GIMP does not. And, have you already used a software that offers such a feature? I can't try it again right now, because the trial period has expired and for some reasons it doesn't work anymore (it should, but without the file save features), but if I remember well Paint Tool SAI is a very good software for illustration/painting/drawing which handles layers and layer modes better than other programs: http://www.systemax.jp/en/sai/ I think layer modes here work on a hierarchy tree structure. Try it if you can. bye, Martin [1] http://www.davidrevoy.com/temp/mypaint-request/ [2] http://forum.intilinux.com/mypaint-development-and-suggestions/layer-blending-mode/ Thanks, SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Martin Nordholts wrote: On 10/01/2009 07:46 PM, peter sikking wrote: meanwhile, can the overlay thing be repaired file-backward- compatible? If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice but to fix it somehow. Probably by having a legacy compositing mode also when using GEGL. Making GIMP 2.6 XCF files not openable in GIMP 2.8 isn't an alternative. what I mean is that right now (2.6) when overlay is chosen, soft light is executed. I think we should have in 2.8 a working overlay mode (also for legacy compositing). I think the following plan can technically work and is usable: - overlay gets repaired and assigned new mode enumeration number - when any old gimp file is opened and an old overlay mode is encountered, soft light is substituted as the layer mode, also in the UI. this sub does not mark the gimp file as dirty (changed). this means old files display the same as before. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
On Fri, 2009-10-02 at 06:22 +, Ilya Zakharevich wrote: 0) Remove Press F1 to view manual from tooltips unless GIMP knows that a manual is present, and knows to which page to jump. Since GIMP offers to read the manual online, the manual is always present. Or rather, it becomes rather difficult to tell whether it is present or not. Same goes for the decision on whether the manual covers this topic. The core knows nothing about that and the gather that knowledge, it needs to download the manual index. The change you are asking for is definitely not trivial. It might be easier to just fix the manual so that it covers help for all help IDs. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
Thanks for the hints ... Some interesting developments while running under sudo. The first run: - sudo -u www-data gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE /dd/d/app/front/PAK_live/srvr/xformx.com/run/pdf_forms/le-50.0.11.01(2008-10)d8.pdf )' --batch='(gimp-quit 1)' - gives error: error: Cannot create folder '/var/www/.gimp-2.6': Permission denied So I temporarily opened up /var/www with permission 777 and tried previous command again - to see that gimp is going to write in the /var/www directory: -- sudo -u www-data gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE /dd/d/app/front/PAK_live/srvr/xformx.com/run/pdf_forms/le-50.0.11.01(2008-10)d8.pdf )' --batch='(gimp-quit 1)' No protocol specified /var/lib/python-support/python2.6/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) No protocol specified (file-uri:5738): Gtk-WARNING **: cannot open display: :0.0 (gimp:5568): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error No protocol specified /var/lib/python-support/python2.6/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) batch command executed successfully -- This 2nd run interesting things (FINALLY) happened :) The most important is the last line: it says that gimp executed my plugin, and indeed, it did (wrote some debug file to the filesystem, as expected). Also, after examining '/var/www', I see that gimp created 2 new directories: drwx-- 4 www-data www-data 4096 2009-10-02 15:38 .gegl-0.0 drwxr-xr-x 21 www-data www-data 4096 2009-10-02 15:38 .gimp-2.6 I don't know how safe it is to keep these Gimp directories inside my main apache directory - it probably opens up some hole of some kind - but anyway, priority now is to make Gimp happy. I'll deal with holes inside my web server later ... Conclusion: it seems Gimp needed these 2 dirs in that place, as now it seems to work with my preliminary (i.e. debugging) code. The key was to run that gimp command as sudo -u www-data gimp ... to get that error message. Before that, I had no idea what Gimp was complaining about, or if it was even invoked at all ... Thanks for your help, suggestions, and happy Gimping all ! (I'll be 'web-gimping' in my case :) vio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
peter sikking wrote: Akira wrote: [1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here: http://sourceforge.jp/projects/gimp-painter/releases/ I remember and checked: we discussed this in july 2008. even our brush mistress Alexia Death chipped in: GIMP is an image manipulation program (including wild brushwork over collages of found images) but not a paint-from-scratch app. so I am sorry. no additions solely for digital-artists. Hope that gets revisited sometime--art's what I use GIMP for. Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
