Re: [Gimp-developer] Wanted: pixel warrior drones
[ date ] 2002/03/09 | Saturday | 11:58 AM [ author ] Vio [EMAIL PROTECTED] Because it is a HUGE security hole into the system hosting the Gimp: a skilled python programmer can run any python script he/she wants remotely and anonymously, so potentially do a lot of damage on the host. It's a dirty little hack. Still, it does execute Gimp commands (python-only) as I wanted, and I guess I like to live dangerously. Perhaps these modules will help you: http://www.python.org/doc/current/lib/module-rexec.html http://www.python.org/doc/current/lib/module-Bastion.html They're kind of like the Safe module for Perl from what I've been told. They can restrict code from performing certain 'insecure' operations. -- package wuv'apqvjgt;($_=join('',(*PgtnHcemgt))) # print map beppu\@$_\n, qw( =~ s/([HaP])(?!e)/ \U$1/g;s/^.|:| (?=A)|//g;y # cpan.org lbox.org binq.org /c-z/a-u/;printJ$_\n;#$^%$^X@.^ !-- japh -- # oss.lineo.com codepoet.org); ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
* John Beppu [EMAIL PROTECTED] [020309 11:20]: [ date ] 2002/03/04 | Monday | 01:07 PM [ author ] Sven Neumann [EMAIL PROTECTED] __vio__: 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). __sven__: The only thing gimp-remote can do is to tell a running gimp to open a specific file. I wrote a script called gimp-request which does what you (vio) thought gimp-remote would do. An interesting twist is that it lets you preprocess the Scheme code with Perl. I noticed you were a Python guy, but you might find the implementation to be interesting anyway. http://perlmonks.org/index.pl?node_id=146539 Hi John, Thanks for your message. You can be sure that I will have a look, and your preprocessor sound intriguing. Instead of trying to bring the GIMP to the Web like you're proposing, I'm trying to make the GIMP and the Unix command line work together the way a Unix programmer expects to be able to. On my front, after some intense work this week, I managed to embed a python web server inside a Gimp module. In fact, I call it a Proxy server, because all it does is listen to a port, then execute all data POSTed to it by some web client, and return the result back to the client. That data this proxy server receives from the client is hopefully 'only' Gimp scripts (python-based). Because it is a HUGE security hole into the system hosting the Gimp: a skilled python programmer can run any python script he/she wants remotely and anonymously, so potentially do a lot of damage on the host. It's a dirty little hack. Still, it does execute Gimp commands (python-only) as I wanted, and I guess I like to live dangerously. Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
[ date ] 2002/03/04 | Monday | 01:07 PM [ author ] Sven Neumann [EMAIL PROTECTED] __vio__: 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). __sven__: The only thing gimp-remote can do is to tell a running gimp to open a specific file. I wrote a script called gimp-request which does what you (vio) thought gimp-remote would do. An interesting twist is that it lets you preprocess the Scheme code with Perl. I noticed you were a Python guy, but you might find the implementation to be interesting anyway. http://perlmonks.org/index.pl?node_id=146539 Instead of trying to bring the GIMP to the Web like you're proposing, I'm trying to make the GIMP and the Unix command line work together the way a Unix programmer expects to be able to. PS: Don't let the long write-up fool you -- the actual script is really short. -- package wuv'apqvjgt;($_=join('',(*PgtnHcemgt))) # print map beppu\@$_\n, qw( =~ s/([HaP])(?!e)/ \U$1/g;s/^.|:| (?=A)|//g;y # cpan.org lbox.org binq.org /c-z/a-u/;printJ$_\n;#$^%$^X@.^ !-- japh -- # oss.lineo.com codepoet.org); ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[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] 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
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] 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