[Gimp-developer] Wanted: pixel warrior drones
Hi all, After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towards Gimp as a web graphics server. Analogy: as we now have static web pages and dynamic web pages (php, zope, etc), similarily I ould like to see not only static graphic representations (implementations: bitmap, vector, mpegs), also dynamic graphic representations. What are dynamic graphic representations? Nice images we can only see at runtime (just as dynamic web pages can only be seen at runtime). Well Gimp's scripts are a good example of dynamic pictures (granted, scripts are not pictures per se, but follow my idea). So from a web designer's point of view, what would really make a lot of sense would be the ability to call such dynamic graphical representations from, let's say, a 'php' or 'dtml' page. For those who don't know, 'dtml' are simple tags inserted in a html page, which the Zope server replaces with the appropriate value before sending it to the client. Example of a dtml tag inside a html page: img src=dtml-var expr=My_time_alienGlow. img ... is a html tag, and dtml-var expr=My_time_alienGlow is a dtml tag. What does the latter do ? Well, it is a call to my method - Zope server with call it at run time. This method, using Gimp's python bindings, will hopefully call Gimp's AlienGlow script and pass it a string (in this case, the local time on my hardware), and some other parameters required by the AlienGlow script (I guess colour parameners, font size, etc.). Does this sound far-fetched? Ok, this may be still fantasy on ice, as I only installed Gimp 1.2.3 couple of days ago, and haven't yet touched gimp-python or scripting-gimp docs (fun starts in a few minutes). But I am totally impressed with Gimp 1.2.3, and I read it can in fact be made to act like a server, started without the GUI, passing it commands with the 'gimp-remote' program (which incidentally seems absent from my installation). So there's the idea: use Gimp as a general purpose image manipulation server (and beef it up with some charting and other vector-based image manipulation plug-ins, for those lazy designers who like me don't really want to learn more than one toolkit to do their job). Push Gimp towards the industry standard's pixel warrior drone. (as opposed to breathing pixel warriors). In a server configuration, the web browser is the all-encompassing GUI. Granted, not all of Gimp's functionality can be accessed through Netscape or IE's limited GUI, but a lot still (like all the image transformation scripts !!!). And for those who want the rest of it, they'll just need to install the GimpGUI, which from here on is a specialized client for the Gimp server, alongside Zope, Php server, eventually some possible Apache perl module, etc. Well, I'm an old Photoshop - new Gimp convert and don't yet know all there is to know about this impressive piece of code. But I hope this may give some ideas to other participants, or more encouragement if discussions/efforts in this direction are already under way. Cheers, Vio ¢^½éh¥êæj)b b²Ñ¢^½éh¥êåËlÅÇÛz¹ ìvèm¶ÿ+-³ mêäzW²yÛ¿¨¥©ÿ+-wèþ¦¥×¯zZ)z
[Gimp-developer] Wanted: pixel warrior drones
Hi all, After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Analogy: as we now have static web pages and dynamic web pages (php, zope, etc), similarily I ould like to see not only static graphic representations (implementations: bitmap, vector, mpegs), also dynamic graphic representations. What are dynamic graphic representations? Nice images we can only see at runtime (just as dynamic web pages can only be seen at runtime). Well Gimp's scripts are a good example of dynamic pictures (granted, scripts are not pictures per se, but follow my idea). So from a web designer's point of view, what would really make a lot of sense would be the ability to call such dynamic graphical representations from, let's say, a 'php' or 'dtml' page. For those who don't know, 'dtml' are simple tags inserted in a html page, which the Zope server replaces with the appropriate value before sending it to the client. Example of a dtml tag inside a html page: img src=dtml-var expr=My_time_alienGlow. img ... is a html tag, and dtml-var expr=My_time_alienGlow is a dtml tag. What does the latter do ? Well, it is a call to my method - Zope server with call it at run time. This method, using Gimp's python bindings, will hopefully call Gimp's AlienGlow script and pass it a string (in this case, the local time on my hardware), and some other parameters required by the AlienGlow script (I guess colour parameners, font size, etc.). Does this sound far-fetched? Ok, this may be still fantasy on ice, as I only installed Gimp 1.2.3 couple of days ago, and haven't yet touched gimp-python or scripting-gimp docs (fun starts in a few minutes). But I am totally impressed with Gimp 1.2.3, and I read it can in fact be made to act like a server, startedwithout the GUI, passing it commands with the 'gimp-remote' program (which incidentally seems absent from my installation). So there's the idea: use Gimp as a general purpose image manipulation server (and beef it up with some charting and other vector-based image manipulation plug-ins, for those lazy designers who like me don't really want to learn more than one toolkit to do their job). Push Gimp towards the industry standard's pixel warrior drone. (as opposed to breathing pixel warriors). In a server configuration, the web browser is the all-encompassing GUI. Granted, not all of Gimp's functionality can be accessed through Netscape or IE's limited GUI, but a lot still (like all the image transformation scripts !!!). And for those who want the rest of it, they'll just need to install the GimpGUI, which from here on is a specialized client for the Gimp server, alongside Zope, Php server, eventually some possible Apache perl module, etc. Well, I'm an old Photoshop - new Gimp convert and don't yet know all there is toknow about this impressive piece of code. But I hope this may give some ideas toother participants, or more encouragement if discussions/efforts in this direction are already under way. Cheers, Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Access to tools via PDB?
Thus spoke Robert Medina Will new Gimp versions include PDB access to the various editing tools? Or is access currently available? The reason I ask is that I'm writting a plug-in to help me automate manual postprocessing of freshly scanned images (manual processing is required). To simplify the task, I need to automatically bring up the cropping tool with predetermined x-y offsets and predetermined length and width set in the dialog box. But I don't see a way to start the cropping tool from the PDB. What about gimp-crop? Do a Search by Name for crop in the DB Browser to see its arguments. If you actually need the dialog itself, then you'll have to create one of your own (its not that complex a dialog box - you could do it with glade probably, or even by hand) and then pass the values to gimp-crop. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- I don't like tests. The measure of a man's value is in his own heart. -- Michael J. Hammel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
Hi, vio [EMAIL PROTECTED] writes: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Analogy: as we now have static web pages and dynamic web pages (php, zope, etc), similarily I ould like to see not only static graphic representations (implementations: bitmap, vector, mpegs), also dynamic graphic representations. What are dynamic graphic representations? Nice images we can only see at runtime (just as dynamic web pages can only be seen at runtime). Well Gimp's scripts are a good example of dynamic pictures (granted, scripts are not pictures per se, but follow my idea). So from a web designer's point of view, what would really make a lot of sense would be the ability to call such dynamic graphical representations from, let's say, a 'php' or 'dtml' page. For those who don't know, 'dtml' are simple tags inserted in a html page, which the Zope server replaces with the appropriate value before sending it to the client. Example of a dtml tag inside a html page: img src=dtml-var expr=My_time_alienGlow. img ... is a html tag, and dtml-var expr=My_time_alienGlow is a dtml tag. What does the latter do ? Well, it is a call to my method - Zope server with call it at run time. This method, using Gimp's python bindings, will hopefully call Gimp's AlienGlow script and pass it a string (in this case, the local time on my hardware), and some other parameters required by the AlienGlow script (I guess colour parameners, font size, etc.). Does this sound far-fetched? Ok, this may be still fantasy on ice, as I only installed Gimp 1.2.3 couple of days ago, and haven't yet touched gimp-python or scripting-gimp docs (fun starts in a few minutes). But I am totally impressed with Gimp 1.2.3, and I read it can in fact be made to act like a server, startedwithout the GUI, passing it commands with the 'gimp-remote' program (which incidentally seems absent from my installation). The only thing gimp-remote can do is to tell a running gimp to open a specific file. It's there for file-managers etc. that want to be able to open image files in a running GIMP session. The ideas you outlined boil down to: 1. make GIMP work w/o a GUI 2. allow everything to be scriptable To some extent this already holds true for The GIMP. Some areas need improvement but we are working on it. The rest is not GIMPs business. As long as we provide a good scripting API and don't make any functionality rely on the GUI, GIMP can be used in whatever client-server environment you can imagine. We won't build any dynamic web-publishing functionality into the core GIMP however. BTW, have you looked at Net-Fu yet? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On 4 Mar 2002, at 4:10, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. [long explanation snipped] Take a look at http://www.flamingtext.com. Is that an application of what you mean? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On 4 Mar 2002, at 4:10, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Wouldn't it make more sense to push Gimp's scripted rendering features into the browser (as a plugin) and send just the script to the user's machine for interpreting? It would presumably be a LOT less bandwidth than sending out an image...particularly if you are doing animations. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
* Stephen J Baker [EMAIL PROTECTED] [020304 10:27]: On 4 Mar 2002, at 4:10, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Wouldn't it make more sense to push Gimp's scripted rendering features into the browser (as a plugin) and send just the script to the user's machine for interpreting? It would presumably be a LOT less bandwidth than sending out an image...particularly if you are doing animations. I don't understand what you mean by Gimp's scripted rendering features? That the Gimp plugin/script source code is stored on the browser side? And a browser plugin: which browser? Exactly. The client (the web browser) has no idea (nor interest to know!) who or how the pictures it receives from the web server are generated. The only difference in this situation is that those images are generated after the web server received the request from the client for that image. A good analogy would be with Dell's 'direct' distribution model: a Dell computer is assembled only after a customer has placed the order for it. Same here: Gimp assembles the pixels for the image only after the server has received an order for it (a request). Let's call this Image On Demand. Obviously, most images on a web page will continue to be served pre-assembled (pre-cooked) images. But there is a market out there for images generated on the spot, bleeding fresh, photons still smoking. Examples could be any images who age very fast (stock graphs come to mind, though it's not the best example) or images who are dependent on the client's request (so they couldn't have been generated beforehand since the server had no idea what the client's parameters for that image was before it made the request). Yes, this is a very resource-intensive proposition, as opposed to static images, but CPU speeds are getting faster, RAM is getting cheaper. And hopefully bandwidth providers will follow suit. I managed to put my hand on a Net-Fu package. Yes, that is what I was talking about. I wonder if this code is still maintained by anyone, because what I got had a 1997 timestamp. I hope the authors won't mind, but if I can manage to get rid of the Java code (for their client), and re-write the server in python, we're in business (not that I have personally anything against Java or C). Regards, Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Compiling 1.2.3 with X 4.0.2
To whom it may concern: If this email should be sent instead to the gimp-user list, please let me know and I can send it there. I attempted to compile the Gimp, version 1.2.3, (on a linux 2.4.14 machine) under X 4.0.2, and got the following error: output gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I/opt/gnome/include/gtk-1.2 -I/opt/gnome/include/glib-1.2 -I/opt/gnome/lib/glib/include -I/usr/X11R6/include-I/usr/local/include -DLIBDIR=\/usr/local/lib/gimp/1.2\ -DLOCALEDIR=\/usr/local/share/locale\ -DREGEX_MALLOC -DG_LOG_DOMAIN=\Gimp\ -DGTK_DISABLE_COMPAT_H -g -O2 -Wall -c text_tool.c In file included from /opt/gnome/include/gtk-1.2/gdk/gdkx.h:30, from text_tool.c:28: /opt/gnome/include/gtk-1.2/gdk/gdkprivate.h:31: X11/Xlib.h: No such file or directory /opt/gnome/include/gtk-1.2/gdk/gdkprivate.h:32: X11/Xutil.h: No such file or directory make[2]: *** [text_tool.o] Error 1 make[2]: Leaving directory `/home/john/download/gimp-1.2.3/app' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/john/download/gimp-1.2.3' make: *** [all-recursive-am] Error 2 /output I was unable to find the two header files that the compilation choked on, and so my best guess is that X 4 rearranged the location (and possibly API) of their header files. Or it could be some other thing entirely which I'm doing wrong. If you need any further information, please let me know. I'm not (yet?) on the mailing list, so I would appreciate a cc:, if at all possible. Thanks (for this and for a great product), John L. Clark ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling 1.2.3 with X 4.0.2
Hi, John L. Clark [EMAIL PROTECTED] writes: I attempted to compile the Gimp, version 1.2.3, (on a linux 2.4.14 machine) under X 4.0.2, and got the following error: output gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I/opt/gnome/include/gtk-1.2 -I/opt/gnome/include/glib-1.2 -I/opt/gnome/lib/glib/include -I/usr/X11R6/include-I/usr/local/include -DLIBDIR=\/usr/local/lib/gimp/1.2\ -DLOCALEDIR=\/usr/local/share/locale\ -DREGEX_MALLOC -DG_LOG_DOMAIN=\Gimp\ -DGTK_DISABLE_COMPAT_H -g -O2 -Wall -c text_tool.c In file included from /opt/gnome/include/gtk-1.2/gdk/gdkx.h:30, from text_tool.c:28: /opt/gnome/include/gtk-1.2/gdk/gdkprivate.h:31: X11/Xlib.h: No such file or directory /opt/gnome/include/gtk-1.2/gdk/gdkprivate.h:32: X11/Xutil.h: No such file or directory make[2]: *** [text_tool.o] Error 1 make[2]: Leaving directory `/home/john/download/gimp-1.2.3/app' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/john/download/gimp-1.2.3' make: *** [all-recursive-am] Error 2 /output I was unable to find the two header files that the compilation choked on, and so my best guess is that X 4 rearranged the location (and possibly API) of their header files. Or it could be some other thing entirely which I'm doing wrong. I guess the whole problem is that you don't have X11 headers installed. This is not unusual for most distributions but it should be easy to install the X11 header files by means of your distribution. Look for a package called xlibs-dev or somehing similar. If you have the X11 headers installed then gtk-config --cflags is most probably pointing to the wrong location. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On Mon, Mar 04, 2002 at 04:10:39AM -0500, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towards Gimp as a web graphics server. This already exists if you are willing to jump through a few hoops, but you may have to wait for Gimp-2.0 to lose the dependence on X and Gtk+. Hopefully Gimp-1.3 will make more functions available via the PDB, but it's already pretty complete. If you use the Gimp-Perl extension with Apache's mod_perl, you get a persistent connection to a running GIMP (currently in an Xvfb, which is no big deal IMHO). Here's what I wrote and presented in Manchester last summer: http://www.aceldama.com/~tomr/papers/2001/web-gimp/ It's currently running at: http://gimp.aceldama.com/ (only the titles are made by The GIMP, but they're cached fairly effectively) (ooh, and the navigation thingy is automagically generated) The above is on a headless Apple Network Server running LinuxPPC 1999 Q3, and I got it working on Wilber (a Debian x86 box), so it's *reasonably* portable; I don't think I did anything too Linux-specific. There's no reason that such Gimp-Perl calls couldn't be used with the various mod_perl-based template systems already. (Perhaps with a bit of futzing). That's my 2 cents on all this. Cheers, Tom -- -- Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ Most people can't understand how others can blow their noses differently than they do. -- Turgenev ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling 1.2.3 with X 4.0.2
On Mon, Mar 04, 2002 at 07:41:09PM +0100, Sven Neumann wrote: I guess the whole problem is that you don't have X11 headers installed. This is not unusual for most distributions but it should be easy to install the X11 header files by means of your distribution. Look for a package called xlibs-dev or somehing similar. If you have the X11 headers installed then gtk-config --cflags is most probably pointing to the wrong location. Whoops. You're exactly right - I had the devel package installed, but it appears that it had only installed partially, and I hadn't checked that. Sorry for the unnecessary question, and thanks for your prompt reply. Take care, John L. Clark ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On Mon, Mar 04, 2002 at 01:11:02PM -0500, Carol Spears [EMAIL PROTECTED] wrote: do you mean something like this: http://www.goof.com/pcg/marc/gimp.html but i think the on demand images on this page were not rendered with there are no on-demand images on that page in the dynamic-html sense. I create the buttons at make dist time, e.g. when my local html pages get published to goof.com gimp. the page is very very informative, yet i was not able to access it with lynx. hey, lynx should work great with my pages ;) at least, as much as lynx can be called great. with a graphical browser, the images are very cool though. all my friends say: well, the idea is nice, but the images are butt-ugly ;) between these images and the usual ones found on web pages. what would be the advantage of this sort of rendering? in other projects of mine I *do* plan to dynamically create buttons (of course heavily cached). If you look at why traditional web design is so expensive the reason (partly!) seems to be the major time effort: redrawing buttons (and other elements) again and again. actions don't help that much (many artists don't know how to use it). Of course, writing perl scripts won't help in that case, too ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
On Mon, Mar 04, 2002 at 01:55:37PM -0500, Tom Rathborne [EMAIL PROTECTED] wrote: but you may have to wait for Gimp-2.0 to lose the dependence on X and Gtk+. Hopefully Gimp-1.3 will make more functions available via the PDB, but it's already pretty complete. the big problem is indeed fonts (and that's taken care of). the only other problem is long-term-stability, but for real daemonized usage some restarting is inevitable (after all, what's the DBI-ping method for). As Net-Fu shows/solves, the biggest problem is practical availability (caring for gimp restarts, resync, locking), not so much lack of features, as everything is already there in gimp-1.2. So... who wants to invest some time into her existing framework to make it usable for other people (I am quite sure many people have solved these problems for themselves already...) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
