Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 12:53:40AM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > Oh sure, out of all the bindings, perl comes closest by far to full coverage. > But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, > and libgimpthumb. Ah yes, I haven't looked into the new stuff... [hints for implementors, after looking into a slightly older 2.0 snapshot that I have on my disk:] Most of libgimpcolor and libgimpmath is available in other perl modules (using them directly would be rather slow in perl, using pdl is faster, although the results might be subtly dfferent, of course. Wrapping these into PDL interfaces would be best). The way to wrap the remaining libgimpwidgets is to make them into real gtk2 widgets with properties and signals. The way it is now, every language interface has to reimplement the api, if they were written in the same way as other libgtk2 widgets it would be as simple as calling the register function and have everything available without extra C code. (as I understand, at least the python gtk2 interface is working very similar and would benefit automatically from this). libgimpthumb would probably just need a few init calls to be called on module init, although the design of combining an initialisation function with setting parameters (gimp_thumb_init) might not have been the wisest choice, but this could be handled in perl using "use Gimp:Thumb (MyApp /basedir)", athough it's not clear how to handle multiple users of Gimp::Thumb. Everything else is nicely wrapped into gtk enums and properties there. (Gimp::Thumb might become an extra module on CPAN, even, I see possible uses in non-gimp-apps. Same is true for the other libgimp interfaces that are not tied into the gimp protocol themselves). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 11:58:15AM +0100, Sven Neumann wrote: > Hi, > > Manish Singh <[EMAIL PROTECTED]> writes: > > > Oh sure, out of all the bindings, perl comes closest by far to full > > coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some > > of libgimpwidgets, and libgimpthumb. > > We will have to make the libgimp APIs more language binding friendly > then. If we made more use of GObject properties, that would probably > help. Yeah, there's a bit of work to be done on the libgimp* side too. Not a whole lot though, and certainly doable for 2.2. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Manish Singh <[EMAIL PROTECTED]> writes: > Oh sure, out of all the bindings, perl comes closest by far to full > coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some > of libgimpwidgets, and libgimpthumb. We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 08:35:04AM +0100, Marc A. Lehmann wrote: > On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > > currently, and go beyond that with a full gtk and gimp binding. The > > same should be done for python (I have plans to do this) and perl, the > > idea being having languages besides C that can use the entire gimp API. > > Hmm, at least during the 1.2 era, perl did have access to the full API > (i.e. low-level pixel access, full UI transparency etc.), and right now I > don't think something important has been added that is not accessible (as > opposed to parts that haven't been converted to the new API). > > I mean, in the sense of "you can write plug-ins indistinguishable from > plug-ins wirtten in C", this was possible in perl for a long time already. > > However, very few authors have used these features, and only two perl > plug-ins, both written by me, use their own Gtk-UI instead of relying on > Gimp::Fu, so I guess the demand for the latter power in perl is pretty > low. > > (I might err and there are lots out there, perl developers have this > tendency of doing stuff for themselves without polishing & publishing > them...) Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. I'd like to see more bindings that let you do everything a C plugin does, so people have language choice when it comes to writing things, which could mean a larger pool of plugin coders. It's also nice to have a quick way of trying out new algorithms. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > currently, and go beyond that with a full gtk and gimp binding. The > same should be done for python (I have plans to do this) and perl, the > idea being having languages besides C that can use the entire gimp API. Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API). I mean, in the sense of "you can write plug-ins indistinguishable from plug-ins wirtten in C", this was possible in perl for a long time already. However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low. (I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing & publishing them...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Thu, Feb 05, 2004 at 04:14:10PM +0100, Marc A. Lehmann wrote: > Simons agruments, however, smell a lot of "standard gimp extension > language", because his goal is to have one language that is always pat > of gimp, which would effectively be a standard. I don't think that's a > bad idea at all, especially when we later think of macro recording and > other tasks, where we _will_ need some standardized macro language that > should be easy to translate into real scripts. Exactly. And scheme is pretty good for that, since it's easy to parse, which makes writing a macro->real program script easy. Running a macro shouldn't need any extra dependencies either. So SIOD is fine for this, unless there is a smaller scheme implementation out there. Use of it for anything beyond simple macro logic should be discouraged. So there is room for a Guile binding which could run stuff that is .scm currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: I'd guess that the majority of our power users are on Win32. Are there any numbers you can base this statement on? No, it's a guess. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. It's possible. I'd also like to get an idea of the number of MacOS X GIMP users. I'd say not many. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > Actually, most GIMP users probably get their GIMP from Jernej - OK - > the GNU/Linux side of things gives us a nice big install base on > Linux, but proportionately very few Linux people actually *use* the > GIMP. I'd guess that the majority of our power users are on Win32. Are there any numbers you can base this statement on? I don't think this assumption is correct. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. I'd also like to get an idea of the number of MacOS X GIMP users. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Thu, 2004-02-05 at 16:14, [EMAIL PROTECTED] wrote: > Simons agruments, however, smell a lot of "standard gimp extension > language", because his goal is to have one language that is always pat > of gimp, which would effectively be a standard. I don't think that's a > bad idea at all, especially when we later think of macro recording and > other tasks, where we _will_ need some standardized macro language that > should be easy to translate into real scripts. I agree that we should have a "standard gimp scripting language" but nothing prevents us from having it in a separate package on which The GIMP depends on being installed - just as we depend on GTK+ being installed (and just as we will depend on GEGL being installed in a not too distant future). I believe the project would benefit from splitting stuff like script-fu, python-fu etc. out from the main source module into their own. Why? To make the GIMP source code more modular. IMO, modularity means easier to maintain, easier to grok for new developers - and the beauty of it all: a much better separation between the different modules. ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > Including guile doesn't mean supporting it. As it is, there are a > bunch of things we include that don't get much support because the > original authors have gone their own way. This time we're not even > talking about *pretending* that this is a GIMP thing - we set up a > configure script that checks if there's a local guile installed, if > there is it uses it, otherwise it calls configure && make on its copy, > and uses it in the GIMP. It is the same thing as we currently have, > except that instead of George Carrette's SIOD, we'll be using > GUILE. And this time, we will be using an official release of a scheme > interpreter, not a GIMP modified copy. I don't see a downside. We don't include libpng or libjpeg or glib or gtk+. Why should we include guile? If we need guile for script-fu and you argue that script-fu needs to be part of the standard gimp tarball, then gimp needs to depend on guile. Where's the downside? > > In the long run we should move as much as possible out of the GIMP > > package. This will assure that we provide a stable and powerful API > > and will enable more extensions and plug-ins to be written. IMO moving > > script-fu out of the tree and putting it on the same level as > > gimp-perl and other language bindings is a very important thing to do. > > There is a certain point at which this is unreasonable. If we move all > the C plug-ins out into another module, and all the brushes, patterns > and other data to another module, and all the script-fu and python-fu > to separate modules, we'd have a small, stripped down core, but a > usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to > download, and 6 or 7 packages to maintain. This sounds like the right thing to do. I'd go even further and move the GIMP libraries into a seperate package as well. The casual user will not even notice the difference. Users can install a meta package, all packaging systems I am aware of support such a thing. But if we had all these separate modules and would even distribute libgimp separately, we would finally allow other apps to use our widgets and the image processing libary we are developing. Other apps like for example a video manipulation program could be developed around the gimp core. > I'm afraid that moving all of the langauge bindings out of the core > would only result in the bindings not being maintained as well. As it > is, the Python bindings are in need of a bit of a work-over before > 2.0, if I remember correctly, and script-fu itself is only getting the > minimum of maintenance for it not to be broken. If it turns out the languages are not maintained outside the GIMP it is probably about time to get rid of them. Actually I believe that it is a lot easier for people to maintain and contribute to a smaller package like gimp-script-fu as it is for the GIMP maintainers to keep Script-Fu alive and decide what to do about contributions from others. > Anyway - working towards a minimalist GIMP is kind of going away > from what I'd like to see. This would a major shift in our goals and policies and it definitely needs more discussion. > I'd be more interested in being pretty liberal about the patches and > plug-ins we accept in the core, and get more plug-in authors > involved in maintenance work and development. For that we need to > define guidelines for getting a plug-in into the core, and get the > word out that we're interested in more or less anything and > everything to do with image processing. Hand in hand with that we > would also need guidelines for when a plug-in would get dropped > (temporarily?) from the distribution if it is unmaintained. If we > have decent guidelines, this would add very little work for > maintainers, who could just let plug-in authors take care of their > own code. This is IMHO not a reasonable goal. At the moment we are doing it like this because we are afraid of finally cleaning up our codebase to a point where it becomes maintainable again. At the moment the GIMP tree is way too large. Not only from a maintainance point of view. I also believe that the casual user is struggling with the shear amount of plug-ins and modules we ship by default. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32. (and the rest should easily be prepared to deal with installing things from source). This is the big developer fallacy... installing from source is not easy, particularly if you have a desktop set-up and not a developer's set-up. If you have to install a C compiler, you probably won't bother. To me it's all a matter of the installer. Agreed. The installer should, IMHO, install almost everything (within reason). It makes more sense to have separate packages for stuff on Linux (that's the Linux way) but on Windows, people expect to be able to install 1 thing. Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. Agreed. So - who's been thinking about the macro recorder? :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I don't think we should do that simply because I don't see what is so > important about having a self-contained scripting language. I'd rather > like to see three or four well-maintained and working scripting > languages that can be installed separately. If we can make sure that > the language extensions work and can be easily installed that should > be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. (and the rest should easily be prepared to deal with installing things from source). To me it's all a matter of the installer. Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
Ooops, that should have been gone to the ML as well... Sven Neumann ([EMAIL PROTECTED]) wrote: > Simon Budig <[EMAIL PROTECTED]> > > Include a GUILE in the Gimp sourcecode, make sure that it doesn't > > conflict with other GUILEs on the target system and use it as the GIMPs > > default language. Perfectly fine with me as long as I have a language > > that is guaranteed to be available for 99% of the GIMP installations. > > I don't think we should do that simply because I don't see what is so > important about having a self-contained scripting language. I'd rather > like to see three or four well-maintained and working scripting > languages that can be installed separately. It is pretty easy to see why a default scripting language is important, and I guess it is your grumpiness against script-fu that prevents you from seeing it. When somebody on IRC has a problem that is cumbersome in the UI, but can be solved with three or four PDB calls (e.g. "Flip Layer menu entry") I'd hate to tell him that he has to install a monster like Perl/Python or whatever, to be able to use my quickly hacked three line solution. And even if he has Perl installed, I could not provide a script for him, because I only know about Python and Script-Fu. I don't want to be a master in all bindings available for gimp, just to be able to provide such a thing. I want to focus on one or two languages. This has happened in the past and Script Fu was a nice solution for stuff like that. And that is the reason why it is important to have a simple language available always. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hello, Sven Neumann wrote: It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it. Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure && make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside. In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all. I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken. Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Dave Neary ([EMAIL PROTECTED]) wrote: > We might assume that perl or python are more or less universally > available, [...] Please note that this definitely is wrong. We have a Windows user base and they most probably don't have Perl or Python installed. Otherwise I wouldn't bring this topic up. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I'm with Simon - at least one scripting language installation's a good > idea. We might assume that perl or python are more or less universally > available, but we can certainly not assume that guile is always > installed. Given the fact that script-fu has historically been the > reference language binding (and it continues to be), we should go out > of our way to make sure it's available, IMHO. It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it. In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Simon Budig <[EMAIL PROTECTED]> Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Simon Budig <[EMAIL PROTECTED]> > Include a GUILE in the Gimp sourcecode, make sure that it doesn't > conflict with other GUILEs on the target system and use it as the GIMPs > default language. Perfectly fine with me as long as I have a language > that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Daniel Rogers ([EMAIL PROTECTED]) wrote: > Simon Budig wrote: > >IMHO we should have at least one language where we can rely on the > >availability on *every* gimp installation. Basically this is impossible > >to guarantee for all languages that are packaged separately (like Perl, > >Python and Guile as well). > > > >I don't want to tell a newbie on Windows to install Python, because he > >needs it to e.g. run a simple script that applies a curve that depends > >on the current foreground color... (just a silly example). It'd be > >better to tell him "drop this file in that directory and invoke it" > >and I don't have to care whats his platform and what interpreters > >are installed. > > This is, I think, really shooting ourselves in the foot. By making this > choice, we are choosing to use a broken, out-of-date, scheme interpreter > when _much_ superior alternatives exist, because we don't want to force > installers in have to install another library. I think you missed my point. I am not advocating for script-fu over guile (or that is not my main point), I am advocating for a simple self-contained language, that is included with the GIMP sources. Lets call it Gimp-Basic. > Isn't that what > installers do!? Guile is specifically designed to be an extension > language for applications. It is a shared library. It is a perfect > replacement for the gimp's soid bundle. > > The problem I see with this argument is: > > You are turning a packaging problem into a design choice. Suppose, for > example, we choose to make siod a seperate dynamically linked library > (included in the gimp sources, even). What is the difference between > forcing you to install soid, and forcing you to install guile? The difference of course is, that Gimp is most likely the only application using SIOD and we would have full control over the version we deliver. I have no idea how GUILE usually is distributed, I was assuming that GUILE gets distributed similiar to Perl or Python. [Assuming this is true, I might be wrong here:] When we'd use GUILE (as the "Gimp-Basic") and the user uses Guile for different tasks he obviously would expect that GIMPs Guile is the same as his GUILE. Having our own Guile in the Installer would be a bad idea then, either because of e.g. Windows DLL hell or because of two different versions. > The "not-creating-another-depency" argument is an illusion. soid is > already a dependency. It is just a dependency we choose to include in > the sources. Why did we do this? Is jpeglib included in the gimp > source tarball? What about libppm? libpng? These are all > dependencies. Should we include those in the tarball as well? Well, supposing SIOD were a library, it is perfectly natural to include SIOD, because it is not as universally available as the other libraries. Having libraries in the GIMPs tarball already has happened... > It is true enough that you can argue that jpeglib is not as important as > siod because you can disable the jpeg plugin on the configure command > line. But this can be true for soid as well. While I don't immediatly > see a ./configure option to disable script-fu, there is no technical > reason why we can't have a configure option that disables script-fu. > In fact, because you can disable script-fu, you cannot gaurentee that > there exists a script system at all, let alone script-fu. [there used to be a dependency on the SIOD interpreter for parsing batch commandlines, but IIRC this is gone now] All true and well, but my point is: I *want* to have a scripting system that is available almost universally. And this is the reason why siod is much more important than libjpeg right now. The scripting system not necessarily has to be Script-Fu, but it did the trick for at least six or seven years now... > Basically, the only real way to ensure that every single instance of the > gimp has a scripting language installed is to package the gimp for every > platform ourself. Not moving to something besides siod is *crippling* > to our supported, which should be the best, extension language. > > >So we should have at least one self contained language that comes with > >the GIMP. I am not exactly tied to Script-Fu, but I don't see any other > >obvious candidates. > > Guile is in all ways superior to siod, and is even self contained. We > could even include a version of Guile in the tarball, which is what we > do now with soid anyway. I indeed would be very happy if I could write all my scripts in Python, but this is not an option, since I cannot assume that Python is available on all gimp installations. Thats why I write most of my scripting stuff in Script-Fu, and it works. Ok, sometimes it is a pain to debug (I think most of the debugging problems could be solved by evaluating errobj instead of displaying a silly "see errobj" message), but when the script is completed it is plug'n'play. Include a GUILE in the Gimp sourcecode, make sure that it doe
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Tue, 2004-02-03 at 18:18, Daniel Rogers wrote: > Sven Neumann wrote: > > All of this would probably be best solved by redoing Script-Fu using a > > full-featured and actively maintained Scheme implementation. > > Might I suggest Guile? > http://www.gnu.org/software/guile/guile.html > > It seems almost ready made to be stuck into the gimp. I have done some preliminary looking around the net related to Scheme interpreters. The use of Guile was proposed in messages I saw dated 1998. Back then it was felt the start up time for Guile was a little too long. I would hope that issue has been resolved in the intervening years. I have also seen references to guile-gtk as an extension for Guile, and a reference to a GIMP plug-in called 'gimple'. I haven't found copies of either of these two projects on the 'net yet. So far, I have grabbed copies of libscheme and the latest version of SIOD (v3.2) to take a look at them. A first step might be to replace the existing SIOD stuff with the 3.2 version but even that version of SIOD is very old and libscheme is even older. Based on comments in messages from years ago and recent comments, I will take a closer look at Guile. Developing a separate replacement for Script-Fu is the way to go. IIRC, this is how Script-Fu came about. Other items such as Xscanimage are able to be dropped in to GIMP at any time so the new interpreter could be done the same way. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Michael Natterer <[EMAIL PROTECTED]> writes: > I agree 100% with everything Daniel said. SIOD is unmaintained crap > from the stone age. We should ditch it and use guile instead. I think the best approach will be to develop a Script-Fu replacement based on Guile (or another interpreter) separately from Script-Fu. When this implementation is mature enough to provide a way to run the existing scripts, we can drop Script-Fu. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Daniel Rogers <[EMAIL PROTECTED]> writes: >>>As far as I remember, it was because it adds a rather big dependency, and >>>people thought that gimp should come with at least one script interpreter >>>on it's own. >>> >>>(These are not my arguments, I just repeat what I think was one of the >>>bigger points back then). >> It was a point that I indeed support very strongly :) >> IMHO we should have at least one language where we can rely on the >> availability on *every* gimp installation. Basically this is impossible >> to guarantee for all languages that are packaged separately (like Perl, >> Python and Guile as well). >> I don't want to tell a newbie on Windows to install Python, because >> he >> needs it to e.g. run a simple script that applies a curve that depends >> on the current foreground color... (just a silly example). It'd be >> better to tell him "drop this file in that directory and invoke it" >> and I don't have to care whats his platform and what interpreters >> are installed. > > This is, I think, really shooting ourselves in the foot. By making > this choice, we are choosing to use a broken, out-of-date, scheme > interpreter when _much_ superior alternatives exist, because we don't > want to force installers in have to install another library. Isn't > that what installers do!? Guile is specifically designed to be an > extension language for applications. It is a shared library. It is a > perfect replacement for the gimp's soid bundle. > > (...) I agree 100% with everything Daniel said. SIOD is unmaintained crap from the stone age. We should ditch it and use guile instead. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Simon Budig wrote: Marc Lehmann ([EMAIL PROTECTED]) wrote: On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney <[EMAIL PROTECTED]> wrote: Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD? As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own. (These are not my arguments, I just repeat what I think was one of the bigger points back then). It was a point that I indeed support very strongly :) IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well). I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed. This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle. The problem I see with this argument is: You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile? The "not-creating-another-depency" argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well? It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu. In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu. Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language. So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates. Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney <[EMAIL PROTECTED]> wrote: > > Does anyone know any good reasons why Guile would be an inappropriate > > choice for replacing SIOD? > > As far as I remember, it was because it adds a rather big dependency, and > people thought that gimp should come with at least one script interpreter > on it's own. > > (These are not my arguments, I just repeat what I think was one of the > bigger points back then). It was a point that I indeed support very strongly :) IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well). I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed. So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney <[EMAIL PROTECTED]> wrote: > Does anyone know any good reasons why Guile would be an inappropriate > choice for replacing SIOD? As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own. (These are not my arguments, I just repeat what I think was one of the bigger points back then). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Tue, Feb 03, 2004 at 11:52:29PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Another thing that could be considered is to use a dedicated > interpreter instance for each script. Currently you cannot run two or > more scripts simultanously. Another problem that could be solved with this measure is that script-fu no longer needs to be in memory all the time and would get rid of the delay caused on startup. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
In regard to: Re: [Gimp-developer] Misnamed structure element in SFScript...: >All of this would probably be best solved by redoing Script-Fu using a >full-featured and actively maintained Scheme implementation. Years ago, there was talk of switching to Guile, since that's what the GNU people were (are?) pushing as the language for scripting applications. I don't recall ever seeing why that was rejected, but talk of replacing SIOD with Guile just kind of died. Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Sven Neumann wrote: All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation. Might I suggest Guile? http://www.gnu.org/software/guile/guile.html It seems almost ready made to be stuck into the gimp. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Kevin Cozens <[EMAIL PROTECTED]> writes: > On Tue, 2004-02-03 at 04:48, Sven Neumann wrote: > > Well, it is not only used as a menu-path but also as a (short) > > description. Basically, Script-Fu is a mess. Wouldn't you want to > > rewrite it? We keep looking for someone who wants to redo Script-Fu > > for quite a while already. > > Looking at that again, you are right (of course). The menu path shows up > in the second line titled 'Blurb:' in DB Browser. This is good. I > remember a long time ago when this wasn't there. I would find something > in the browser I wanted to use but had trouble tracking down where it > was in the menus. > > I do seem to have painted a target (or at least a sign) on my back as > Script-Fu maintainer over the last number of days. :-) > > AFAIK, the Script-Fu stuff seems to be working. When you say you want > someone to redo it, can you be more specific as to what you feel needs > to be done to it? Probably the worst thing with the current Script-Fu interpreter is that its error reporting sucks. This makes it very hard to debug scripts. Then, the interpreter doesn't provide a full implementation of SIOD. There are a few things missing that would be extremely useful. For example functions to deal with the file-system so that one could write scripts that operate on directories or files that match a regular expression. All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation. Perhaps things would also already improve if the SIOD implementation in Script-Fu would be updated to the latest release which is, iirc, albeit being 8 years old, still two years newer than what we use currently. Another thing that could be considered is to use a dedicated interpreter instance for each script. Currently you cannot run two or more scripts simultanously. > the moment I hit a call to write_channel and the GTK+ documentation > I have often found lacking. I'll try and track down some good GTK+ > tutorials since I want to be able to do more GUI related programming > in Linux. I suggest you also make yourself comfortable with GObject and would like to point you to this very nice tutorial: http://le-hacker.org/papers/gobject/ Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Tue, 2004-02-03 at 04:48, Sven Neumann wrote: > Well, it is not only used as a menu-path but also as a (short) > description. Basically, Script-Fu is a mess. Wouldn't you want to > rewrite it? We keep looking for someone who wants to redo Script-Fu > for quite a while already. Looking at that again, you are right (of course). The menu path shows up in the second line titled 'Blurb:' in DB Browser. This is good. I remember a long time ago when this wasn't there. I would find something in the browser I wanted to use but had trouble tracking down where it was in the menus. I do seem to have painted a target (or at least a sign) on my back as Script-Fu maintainer over the last number of days. :-) AFAIK, the Script-Fu stuff seems to be working. When you say you want someone to redo it, can you be more specific as to what you feel needs to be done to it? I might be able to start with small changes or patches to Script-Fu at first. However, GIMP itself and GTK+ have gotten a lot bigger and more complex over the years. I usually get lost following things in the GIMP the moment I hit a call to write_channel and the GTK+ documentation I have often found lacking. I'll try and track down some good GTK+ tutorials since I want to be able to do more GUI related programming in Linux. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Kevin Cozens <[EMAIL PROTECTED]> writes: > In the file plug-ins/script-fu/script-fu-scripts.c is a typedef for > SFScript. The third member is 'description'. The contents of the > structure is filled in by the routine script_fu_add_script() further > down the file. This routine is processing the arguments of the > script-fu-register call located at the end of a Script-Fu based script. > It uses the second argument of script-fu-register to set the value of > 'description' in the SFScript structure. > > I see this as misleading. It is not a description of the script but more > of a menu path. The following item (referred to as 'help') contains more > in the way of an actual description of a script. > > I think it would make more sense to change 'description' to something > like 'menupath'. It would be more indicative of its actual use. Well, it is not only used as a menu-path but also as a (short) description. Basically, Script-Fu is a mess. Wouldn't you want to rewrite it? We keep looking for someone who wants to redo Script-Fu for quite a while already. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Misnamed structure element in SFScript structure?
Greetings. In the file plug-ins/script-fu/script-fu-scripts.c is a typedef for SFScript. The third member is 'description'. The contents of the structure is filled in by the routine script_fu_add_script() further down the file. This routine is processing the arguments of the script-fu-register call located at the end of a Script-Fu based script. It uses the second argument of script-fu-register to set the value of 'description' in the SFScript structure. I see this as misleading. It is not a description of the script but more of a menu path. The following item (referred to as 'help') contains more in the way of an actual description of a script. I think it would make more sense to change 'description' to something like 'menupath'. It would be more indicative of its actual use. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
