[Gimp-developer] Re: another Perl-Server question
On Tue, 24 Jul 2001, Brian Richardson wrote: well, I have things working, but it's a bit of a hack. What I really want to do is launch Perl-Server, running as user nobody, from my init scripts (I use the Perl-Server extensively in my CGI development). So, I put together a setuid wrapper to launch the gimp, but I don't see any way of detaching the gimp process from the controlling terminal so that I can background it without terminating the gimp. Any suggestions, or is this a feature which may be added at a later date? ;) Try VNC: http://www.uk.research.att.com/vnc/ It can keep an entire X-server session running at the background of the computer. You'll need to set the DISPLAY env-var of your CGI scripts in accordance with it, but it should work. Regards, Shlomi Fish right now I have to leave the setuid wrapper as the last item in my rc.local and leave the rc.local script running. Brian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] A more experienced programmer does not make less bugs. He just realizes what went wrong more quickly. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: another Perl-Server question
[EMAIL PROTECTED] (2001-07-25 at 1140.55 +0300): but I don't see any way of detaching the gimp process from the controlling terminal so that I can background it without terminating the gimp. Any suggestions, or is this a feature which may be added at a later date? ;) With control terminal you mean X server or a text console? For text console you can use screen, I guess. Try VNC: http://www.uk.research.att.com/vnc/ The traditional way is to use Xvfb, it comes with X (maybe in a accessory package, it varies with distros). It is a dumb X server for testing or background usage. VNC also comes with some distros, but it usage is more for roaming or serving X to machines that do not have X (aka MS Windows when you do not want to pay more software). In both cases, gimp -i saves the creation of interface for faster load and probably faster work due not doing renderings to monitor (you still need some kind of X so the libs can work). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: after some hours of torturing it with perl and some manual hacking, i got gimp running on current CVS glib/gtk+. ... (applying it means that if you want to hack or simply use gimp 1.3, you will need glib, pango, atk and gtk+ HEAD from CVS too). I few questions: * What are pango and atk, and why do we suddenly require them (if indeed we do)? * Are there compelling advantages to using CVS-GTK which outweigh the cons of forcing developers and users to upgrade? Is GTK 1.3 not backwardly compatible with the GTK 1.2 API? My concern is that with such a casual-user oriented application as GIMP we can easily lose users by the wayside with each additional stipulation. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? Ta, --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But one of the funny things with very pretty girls is that ... men think they won't have a chance with them, so they don't ask them out. I do ask. And... quite often, they come out with me. Probably out of curiosity, or something. -- Sir Clive Sinclair ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Adam D. Moss wrote: Is GTK 1.3 (or GTK 1.9, or 2.0, or whatever the GTK HEAD is!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, 25 Jul 2001 17:57:50 +0100, Adam D. Moss [EMAIL PROTECTED] said: * What are pango and atk, and why do we suddenly require them (if indeed we do)? * Are there compelling advantages to using CVS-GTK which outweigh the cons of forcing developers and users to upgrade? Is GTK 1.3 not backwardly compatible with the GTK 1.2 API? My concern is that with such a casual-user oriented application as GIMP we can easily lose users by the wayside with each additional stipulation. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? I would add: * are there Windows versions of pango and atk? * do we reasonably expect Windows ports of the HEAD versions of all of these libraries before 1.4 is released? Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, answering both mails in one... Kelly Martin [EMAIL PROTECTED] writes: On Wed, 25 Jul 2001 17:57:50 +0100, Adam D. Moss [EMAIL PROTECTED] said: * What are pango and atk, and why do we suddenly require them (if indeed we do)? Pango is the font layout and rendering system used by gtk+. It allows for fancy stuff like bidirectional text and makes an end to the X font mess. ATK is the accessibility toolkit which allows e.g. voice control of programs. Both are required by gtk+ HEAD and everything compiles 100% smoothly most of the time. * Are there compelling advantages to using CVS-GTK which outweigh the cons of forcing developers and users to upgrade? Is GTK 1.3 not backwardly compatible with the GTK 1.2 API? My concern is that with such a casual-user oriented application as GIMP we can easily lose users by the wayside with each additional stipulation. There are lots of advantages with Glib/Gtk 2.0. One of them is the clean core/ui separation they provide because the object system has been moved to GLib. We get sane Xinput support and support for new platforms (because GDK is frontend/backend separated now). We get a much improved object system, better looking widgets, better user preferences for widgets classes. We can strip tons and tons of evil hacks because we also get rid of lots of gtk 1.2 brokenness. And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a stable version (which will be in not too distant future). IMHO the pro's outweigh the con's by far, as it's simply not possible without grand hacks to write an internal object model and a nice generic GUI with Gtk 1.2. The biggest pro of GLib 2.0's object system is it's great degree of dynamism which will bring us e.g. pluggable tools almost for free. Also, it will simply not be possible to include a Gtk+ header from app/core/, which is great for enforcing core/ui separation. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? The changes made for 2.0 migration are much less of a structural change than what happens in two weeks of usual HEAD-reorganizing. Not a single file was moved and almost only the object stuff was touched. Gtk 2.0 is _very_ source compatible compared to Gtk 1.2 except for the object system (which is much more consistent and powerful than before) What's a no-brainer BTW ? I would add: * are there Windows versions of pango and atk? * do we reasonably expect Windows ports of the HEAD versions of all of these libraries before 1.4 is released? This is a misunderstanding: _only_ GLib/Gtk 2.0 exist for windows, the current hack to compile GIMP for windows with a Gtk 1.3 snapshot which is almost a year old is the reason for all those windows bugreports. Pango and ATK of course compile under windows and the folks porting GIMP to windows will love to use a sane version of Gtk. After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's bleeding edge version? This is unstable development. ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Michael Natterer wrote: And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a stable version (which will be in not too distant future). I assumed nothing less. IMHO the pro's outweigh the con's by far, as it's simply not possible without grand hacks to write an internal object model and a nice generic GUI with Gtk 1.2. We had an adequately generic GUI and most users couldn't give a whit about the internal object model, but I can see an attraction to hackers. * For those of us with pieces of the tree's core which diverge somewhat from the trunk, how much of a no-brainer is converting our code to GTK 1.3-isms? The changes made for 2.0 migration are much less of a structural change than what happens in two weeks of usual HEAD-reorganizing. Not a single file was moved and almost only the object stuff was touched. It was an honest and straightforward question, not a rhetorical one; what is involved? Are the changes largely syntactic, or deeper? What's a no-brainer BTW ? Something that does not require brain. =) After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's bleeding edge version? This is unstable development. No, I *really* don't see the logic there at all. That's bleeding for bleeding's sake. GTK took a life of its own millenia ago and their destinies are no longer entwined. But the deed is done. :) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 03:43:51PM -0500, Kelly Martin [EMAIL PROTECTED] wrote: If you have to use a development version at least pick a fixed point in development and use that. Otherwise you're coding to not one, but two moving targets: your own code PLUS the moving code in the library you depend on. Or, in this case, five. If your goal is to make development as chaotic and difficult as possible, you are on the right track. I am sorry, but what you describe is reality for most plug-in authors. Did plug-in developers develop for gtk-1.0 and gimp-1.0 a year ago? It's more of a social problem: do we *trust* the gtk development model to be stable most of the time? I did trust the gimp developers that they want working code as well, and it worked fine. If gtk+ is as chaotic as you think it is, it is evry bad and gimp shouldn't use the HEAD revision. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
Hi, Kelly Martin [EMAIL PROTECTED] writes: Why should we expect the GTK+ developers to keep their HEAD revision compilable at every moment? That is a completely unreasonable expectation in the first place. If I were a GTK+ developer I would be asking that you NOT do what you're proposing because it creates pressure on them to keep their HEAD workable at all times instead of doing what they need to do in order to further their own development. you are obviously not well informed about the current state of GTK+-2.0. The announcement of the latest releases (1.3.6 is the latest, 1.3.7 should be out pretty soon) had the following note: This release is meant for: * Those interested in the development of GTK+. * People planning to port to the upcoming GTK+-2.0 version of GTK+. Note: the API is mostly frozen at this point. Major API changes beyond the remaining open '2.0 API freeze' bugs in bugzilla are unlikely to occur before GTK+-2.0 is released. Now this is about five weeks ago and the API has been frozen in the meantime. The 1.3.7 release should give everyone a working and reasonably stable version to work with. As said, we use it every day for months now and I can only vaguely remember the one or two days when GLib, Pango, ATK and GTK+ from CVS HEAD didn't built out of the box. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Kelly Martin wrote: [snip] If GTK stable release (1.2) is not acceptable for further development in the GIMP (which it probably is not), I would strongly urge picking a relatively stable snapshot of GTK+ current development (possibly, but not necessarily HEAD today) and use that. We might have to adjust later to any changes GTK+ makes to its HEAD after that snapshot, but at least we won't have to adjust to them willy-nilly as they make them. Kelly Sorry for jumping into this discussion in the middle, but I happen to have an opinion on this :). What about all the bugs in the chosen snapshot? I mean they get ironed out during the GTK+ development, but the Gimp developers are stuck with them during development. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On 26 Jul 2001 00:17:03 +0200, Sven Neumann [EMAIL PROTECTED] said: you are obviously not well informed about the current state of GTK+-2.0. No, I don't _care_ about the current state of the development of an unreleased package. We should not be using unreleased code. Why can't we just use 1.3.6? That's a frozen release that should be reasonably close to the eventual 2.0.0 release. Why should we introduce this sort of instability to GIMP development when we don't have a good reason to? When 1.3.7 comes out, we can advance to that. There is simply NO good reason to be dependent on the CVS HEAD, no matter how stable the GTK developers think it might be. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Kelly Martin [EMAIL PROTECTED] writes: Why can't we just use 1.3.6? That's a frozen release that should be reasonably close to the eventual 2.0.0 release. who said, we couldn't do this? I do know that the current CVS HEAD works and has some smaller improvements but that could of course have changed since I last checked (yesterday). You are probably right that we should suggest using a release instead of CVS HEAD. There is simply NO good reason to be dependent on the CVS HEAD, no matter how stable the GTK developers think it might be. I think we do not really depend on it and 1.3.6 should work fine. At the moment our configure script wants 1.3.7 which has not yet been released. We can simply change this but I hope that anyway 1.3.7 will be out soon. There is a reason why we waited until the API freeze and a few weeks longer before we even considered starting the port. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 04:40:41PM -0500, Kelly Martin [EMAIL PROTECTED] wrote: Why should we expect the GTK+ developers to keep their HEAD revision compilable at every moment? because that's what they do, what gimp does, what every other project does. if the head revision isn't compilable nobody can wotk with it. That is a completely unreasonable It's completely reasonable ;) expectation in the first place. If I were a GTK+ developer I would be asking that you NOT do what you're proposing because it creates I am not proposing anything. in the GIMP (which it probably is not), I would strongly urge picking a relatively stable snapshot of GTK+ current development (possibly, but not necessarily HEAD today) and use that. We might have to adjust later to any changes GTK+ makes to its HEAD after that snapshot, but at least we won't have to adjust to them willy-nilly as they make As sven has said, they made an API freeze recently. That means they are already pretty late in the development phase. I think it's totally unreasonable to expect non-compilability on a regular base. How often couldn't you compile gimp-1.1.2x? -- -==- | ==-- _ | ---==---(_)__ __ __ 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
