Re: [Gimp-developer] Wanted: pixel warrior drones

[John Beppu]

[  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/;print"J$_\n";#$^%$^X@.^  # 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]

[  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/;print"J$_\n";#$^%$^X@.^  # 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

[vmilitaru]

* 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

[pcg]

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

Re: [Gimp-developer] Wanted: pixel warrior drones

[pcg]

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

[Tom Rathborne]

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

[Carol Spears]

On 2002-03-04 at 1138.18 -0500, vio typed this mail:
> 
> 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".
> 
> 
do you mean something like this:
http://www.goof.com/pcg/marc/gimp.html

i read about the images on this page quite a long time ago.
unfortunately, i am not able to find the info again to check my memory.
but i think the on demand images on this page were not rendered with
gimp.  the page is very very informative, yet i was not able to access
it with lynx.

with a graphical browser, the images are very cool though.

it is prolly off topic by now, but i wonder about the differences
between these images and the usual ones found on web pages.  what would
be the advantage of this sort of rendering?

carol

___
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]

On Mon, 4 Mar 2002, vio wrote:

> * 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?

(Not that I'm particularly advocating this as a thing to do - but...)

I meant: Sending the plugin source code to the browser from the server
along with whatever it takes to invoke it with the right options.  Of
course this means scripting in a 'safe/portable' language that can't be
used to create terrible havoc on the client side - so this is probably
a non-starter.

> And a browser plugin: which browser? Exactly.

Indeed.

OK - forget it - I was just thinking that it would be better to transmit
a couple of dozen lines of ASCII script than a megabyte of image generated
by that script...but it's not really going to work for lots of reasons.


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

[Carol Spears]

On 2002-03-04 at 1138.18 -0500, vio typed this mail:
> 
> 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).
> 
hi, there is something new lately, i found this at freshmeat:
http://freshmeat.net/projects/fu-gen/ 

the net stuff comes with the stable gimp perl modules.

also, i saw someone working on porting the unstable gtk to perl the
other day. prolly it is too soon to mention names though.

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Wanted: pixel warrior drones

[vio]

* 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

[Stephen J Baker]

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

[Branko Collin]

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 . 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

[Sven Neumann]

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: 
> "">".
> 
> "" is a html tag, and "" 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

[Gimp-developer] Wanted: pixel warrior drones

[vio]

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: 
"">".

"" is a html tag, and "" 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

[Gimp-developer] Wanted: pixel warrior drones

[vio]

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: "">".

"" is a html tag, and "" 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