Re: modules cleanup
On Mon, 8 Nov 1999 17:13:08 + (GMT), Austin Donnelly wrote:
On Monday, 8 Nov 1999, Asbjoern Pettersen wrote:
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
The same problem was occurring on Solaris2. Yosh has now tweaked some
of the libtool options so that it should now work. Do these fixes for
Solaris2 also fix the problem under OS/2?
I'm not useing libtool. Is it a script ?
I just wanna solve the problem in the source code and
compile/link with gcc. For OS/2 there is one simple bug but i don't want
to patch this on all 4 modules. The OS/2 code with #ifdef ins't nice to
look at.
Here is some ugly example from colorsel_gtk.c:
G_MODULE_EXPORT GimpModuleStatus
module_init (GimpModuleInfo **inforet)
{
GimpColorSelectorID id;
#ifndef __EMX__
id = gimp_color_selector_register ("GTK", "gtk.html", methods);
if (id)
#else
color_reg_func reg_func;
reg_func = (color_reg_func) get_main_func("gimp_color_selector_register");
if (reg_func (id = (*reg_func) ("GTK", methods)))
#endif
{
info.shutdown_data = id;
*inforet = info;
return GIMP_MODULE_OK;
}
else
{
return GIMP_MODULE_UNLOAD;
}
}
-
Here is mine suggestion for module_init() colorsel_gtk.c (and all the other mods):
G_MODULE_EXPORT GimpModuleStatus
module_init (GimpModuleInfo **inforet)
{
GimpModuleStatus status = mod_color_register ("GTK", "gtk.html",inforet);
return (status);
}
The "mod_color_register()" is the "old" module_init() .
Simple , cleaner and doing the same.
I suggest to create a new file called modregister.c and put
all the "register" things there. Modules have to link the new file.
The will be no new features only a cleaner design.
I'm all for a cleaner design. Ideally we should be doing the same
thing for all architectures, rather than using nasty #ifdefs
everywhere.
Also, still to be fixed with the module code is a version check as
suggested by Tim Janik a long time ago, and unloading modules from the
idle loop (which should make the perl module self-unloadable).
I'm not particularly happy with the OS/2 solution, it seems a little
ugly, but I'm not sure why exactly I don't like it.
Asbjoern
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
Re: Clean up and Re: Help System
On Friday, 12 Nov 1999, Sven Neumann wrote: Here is my list of minor things to clean up and make better (Without breaking the freeze). First the list and then the discussion below it. YES!! I also like the new layout. It seems more consistent. I'm not sure about leaving out all the script-fu's. I'm worried about people complaining that stuff that always used to be there isn't there anymore. Also, is there really a need to group scripts by the interpreter they run under? I don't think so. You wouldn't put shell scripts in /usr/bin/sh-scripts/, but perl scripts in /usr/bin/perl-scripts/, would you, so why make the distinction in gimp? If the script works, a user shouldn't need to know which language it's written in. Austin
Re: [gimp-devel] Re: Clean up and Re: Help System
Sven Neumann ([EMAIL PROTECTED]) wrote: Magnify: Shift zoom out --- Ctrl zoom in Isn't it just always Zoom In (I mean unless Shift is pressed of course)? Just an idea: middle mouse-button is panning, why not Shift-middle button = Zoom Out and ctrl middle-button = zoom in. (Personally I'd prefer it the opposite: Shift: Zoom In, CTRL: Zoom out, but I cannot tell you why, it seems more logical for me...) Maybe using alt for allowing window resizing is a good idea. In a post 1.2 step we can make the Magnify tool behave the same and simply bind the middle mouse-button per default to the magnify-tool. Then you could assign arbitrary tools to the middle mb - for example to easily switch between the eraser and the paint tool. BTW: Shift middle-button + some dragging easily leads to artefacts when the paint tool is active! Apropos cleanup: What about removing the pencil and substitute it with a "hard edge" toggle in the Painbrush? Sometimes it is quite hard to convince the people to use the paintbrush instead of the pencil... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: the ultimate solution to the i18n problem...
On Thu, Nov 11, 1999 at 10:00:57PM -0800, "Jon A. Cruz" [EMAIL PROTECTED] wrote: gettext was a good compromise at the time, but leaves a lot to be desired. Especially when one source english term ( "its" for example ) might be make it (eg) "its1", "its2" etc... and use an english catalog. We probably need an en_UK catalog anyway, to correct all these wrong spellings for colour ;- -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?
On Fri, 12 Nov 1999 [EMAIL PROTECTED] wrote: On 11 Nov, Andrew Kieschnick wrote: Hmm, that sure as hell looks like an LGPL to me. I seriously doubt your copy of gimp is different than mine... LGPL stands for "Lesser GNU Public Licence". Now do me a favour and count the word lesser in this COPYING file... Then do this again for the COPYING file in your Gtk distribution in the subdir gtk... LGPL previously stood for "GNU Library General Public License". It was changed to be the "Lesser GNU Public License" at some point not all that long ago. Read http://www.gnu.org/philosophy/why-not-lgpl.html if you'd like to know why its name was changed. LGPL version 2 is the GNU Library General Public License. LGPL version 2.1 is the Lesser GNU Public License. The COPYING file in libgimp is the LGPL, version 2. The COPYING file in gtk+-1.2.6 is also the LGPL, version 2. Its becoming obvious to me that you just don't know what you're talking about. later, Andrew
Re: Review and better -- Clean up and Re: Help System (fwd)
On Fri, Nov 12, 1999 at 08:11:15PM +0100, Olof S Kylander [EMAIL PROTECTED] wrote: However I'm not after a "on the fly loader". I just want a simple (i.e not load Gimp with bugs) way of handling/install all the scripts. Furthermore most users don't want all scripts. Most of the time you only want a subset. I still fail to see the difference between what you call a script and a in normal plug-(in the python or perl case). Script-Fu scripts, OTOH, are not normal plug-ins. I also do not understand why the user might, say, not want to install some script-fu script but ALWAYS wants to install ALL plug.ins written in C. So are plug-ins written in C more useful by definition than scripts in script-fu? This is what you imply! The "Script Pack" script will simply enable you to choose scripts which will be installed under your .gimp directory if they are supported by your Gimp configuration. Again, since there is no difference between a plug-in written in C or in perl, why not just use a "plug-in-pack" and manage your plug-ins with these? I think the overhead of finding out wether a given executable is a perl/python-plug-in or c is not worth the trouble. This will solve the Perl thing once and for all and What's the perl thing, btw? ever body will be happy ;-). The script can even tell you that you don't have e.g Perl-XFY installed and there for you will not be able to install XXX script. Just a note: this is how it's done (for perl) since more than half a year, with the exception of the tex and povray plug-ins. All others won't clutter the menu unless the necessary modules are found. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: the ultimate solution to the i18n problem...
Sven Neumann wrote: Almost, but not quite. gettext was a good compromise at the time, but leaves a lot to be desired. Especially when one source english term ( "its" for example ) might be translated differently depending on context. When working carefully with gettext, you can translate all appearances of the same word differently. Since the location of the string in the source code is contained in the po files, it is easy (even without knowing the entire source) to detect in what context/dialog the word is used. Yes, that's true. But it still is problematic. Mainly it makes it more transparent for the programmer in the first place, but it creates a more complex and fragile binding. Personally I think that it's no longer necessary to trick programmers into supporting internationalization like it was back in the early '90s. Especially with the current scope of the Internet and it's community. If some simple web site kept this information in some XML format (perhaps one of those being hammered out by the translation software companies) then it could always be easily converted down at distribution time into stuff proper for gettext. Then later if we found a good replacement for gettext (ICU?), we could have all the needed information in place. -- "My new computer's got the clocks, it rocks But it was obsolete before I opened the box" - W.A.Y.
Re: Tile Cache Size
On Fri, Nov 12, 1999 at 05:32:10PM +0100, Marc Lehmann wrote: You saying that the tile system in Gimp is faster is not useful. ^^^ I didn't. Please don't leap into every discussion just to bait me Marc, it's very annoying and I somehow doubt that others are reading this list just to see whether you can bait me enough for me to really bite. Nick.
