Re: [Gimp-developer] Icons for layer modes
Akira wrote: > 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. well, another way of saying that is that these specialised paint programs need improvements for you paint-from-scratch guys, their core audience. in the discussion where the GIMP team formulated what they are, it was explicitly mentioned that GIMP is not an app like Painter. > 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. let's put it this way, that GIMP still works out for you paint-from- scratch guys is a side effect of what the GIMP team decided what they want to achieve. GIMP needs a better general-purpose paint system, Alexia is on the job (I also help out there) and you will also win at the end. the stress in "no additions solely for digital-artists" is on _solely_. if an addition that you are craving for can be proven to be a paint improvement in general, or can be morphed into something that is a paint improvement in general (as seen through the eyes of our core users) then I say let's do it. part of that is also that I can imagine adding it without adding bloat (like adding another tool in the toolbox), integration is crucial. I think the GPS brushes are an example of that. As far as I know we are including them. All I have to say about it is: please take only the sub-set of brushes that are truly general-purpose, in the sense that the person who reviews them can see each of these used in a thousand different ways, depending on the paint settings they are used with. --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] 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
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] 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] 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] 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
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] 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] 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
[Gimp-developer] Invoking custom Gimp module from Web (Apache)
Hello, I've been trying to debug invoking my gimp plug-in from an apache module for past 3 days without much success. I'm sure others tried the same, but Google didn't help much in finding these gems, so far. So maybe a fresh pair of eyeballs may have other ideas ... Ok, basically, I have a python-based GIMP plug-in which runs Ok when invoked from command-line. But when called from apache (from a python-based apache plugin/module), for some reason the command: 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 !! For testing, I've set the permissions of the OUTPUT directory to 'www-data' (apache user) and '777' (open to universe) but still got no output from the GIMP plug-in in this directory. ... though I got debugging files written by the apache module, so I know apache can write can write files in this directory at run-time. But nothing from the Gimp module ... Actually I don't get ANY error message from GIMP in any of my /var/log files But once again, if I run that Gimp command from the command line (bash), it runs Ok !! 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. So after 3 days of trying different options and digging the Web, I'm a little out of 'debug tricks' right now. If anyone knows why Gimp keeps silent or knows of a mailing list thread which discusses this topic (i.e. Gimp web invocation), I would very much appreciate it. Cheers, 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: > 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] 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] 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] 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
