Re: 1.1.19-installation fails

2000-04-10 Thread Daniel . Egger

On 10 Apr, Marc Lehmann wrote:

 Maybe you are not aware that glibc2 is installed only on a minority of
 operating systems.

 Where's the point? gettext is also available outside of glibc2.
 
 That means that we won't be able to use the native gettext
 implementation, but always build our own libintl.

 On these systems: yes. Or you forget about internationalisation
 quickly.

 There is just one problem with this approach: gimp does not yte know
 that this is the case, i.e. it will try to use the native gettex
 implementation.

 Hm, I know you really LIKE auto*, what about extending the configure
 script? :)

  Just curious: which one? It's very hard to believe, sort of
  braindamage...
 
 Do you read gimp-developers?

 How could I? I'd never ever do this come on Marc, please get
 serious again. 
 Really, I'll traverse through all the mails concerning this topic again
 to find some information I may have missed, but there shouldn't be very
 much to find. What reports sometimes are really lacking are DETAILS.

  Sorry if I told you something that ain't right. Would you please
  tell me WHAT of the information I gave you has been wrong to give me
  a change to correct my mind (maybe even other sosurces)?
 
 Do you read your mail?

 Of course do I read this mail. I should put this sentence on a shortcut
 for easy answering of your mails. Questions asked by me are serious as long
 as they are not wrapped by smileys.

 No more to say here :(

-- 

Servus,
   Daniel




Re: 1.1.19-installation fails

2000-04-09 Thread Daniel . Egger

On  8 Apr, Marc Lehmann wrote:
 
 Yes, I got the impression from all what I was told:
 
 a) msgmerge is not checked for by gettext itself
 b) binary .mo files are being distributed with the gimp
 
 Since I was no gettext expert, I just ate it. But now we know better:
 a) is wrong, since msgmerge is a gno-only thing and b) is bad, since
 mo files definitely are not portable.

 Not distributing the .mo files with the GIMP would mean that every
 one who wants to compile it her/himself has to have a working
 set of gettext tools. Would be no problem for me, BTW...
 
  It's a part of the gettext tools. On Linux you either get both or
  none.
 
 As some people already have said, this is wrong.

 I'm afraid I didn't get your point here; If you have the GNU gettext
 tools installed you'll have all of them, if not you'll have none.
 There is no inbetween.
 Please note that I spoke of Linux not of any OS in the world. 
 Do the GNU gettext utils work for let's say Solaris, too?
 If yes, why not rely on them, if we do so on Linux, too?
 
 I think it would not be the worst thing if we had somebody with
 working knowledge of i18n. As it seems, we do not not have such a
 person :(

 You are so nice to me... :)

-- 

Servus,
   Daniel




Re: 1.1.19-installation fails

2000-04-07 Thread Daniel . Egger

On  3 Apr, Raphael Quinet wrote:

 Unfortunately, many systems have msgfmt but do not have msgmerge.
 This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and
 Solaris 7) and under SuSE Linux (unless you install the dev rpm that 
 contains msgmerge).

 I'll check this; if it's true it's definitely a bug. If the gettext
 tools are installed so is msgmerge or better: has to :)

 I think that msgfmt is more or less standard, but msgmerge is not.

 It's a part of the gettext tools. On Linux you either get both or none.

-- 

Servus,
   Daniel




Re: Gimp Wishes (efficient trivial wishes)

2000-04-03 Thread Daniel . Egger

On  1 Apr, Marc Lehmann wrote:

 I think using optional(!) tags (which will be more verbose) will be
 even more useful: Not much added strain on the programmer, not much
 strain on translators (we need one more translator for the en
 mapping).

 Please note that adding "tags" to the messages will mean that GIMP
 isn't usable any more without catalogs which is not very sensible 
 IMHO. I'd rather refine the messages to have more variance in the
 texts... 

-- 

Servus,
   Daniel




Re: Gimp Wishes (efficient trivial wishes)

2000-03-31 Thread Daniel . Egger

On 30 Mar, Stanislav Brabec wrote:

 I18n wishes:
 
 -- Please do anything with the fact, that main panel menu with default
GTK theme can contain exactly 15 letters. Too few for three items
 inmost languages.

 What exactly would you suggest? That's actually a matter for the
 translators, not for the developers, as we don't know all the
 languages around the world. :)

 Ad translation problem:
 
 |   2. Gettext problem.
 |  Sometimes you absolutelly need to translate same message
 differently.
 
 Tell it the programmers; they will have to add "prifixes" to make the
 strings different; e.g.:

 That's not meant to be serious, is it? It would be really a
 pain-in-the-ass to maintain this, even in the most simple case.
 Please consider that every language has other problems with those
 messages and trying to fix everthing with this idea would probably
 mean that EVERY message is used ONCE, which would be a kind of overkill.

-- 

Servus,
   Daniel




Re: Gimp User Installation Dialog.

2000-03-30 Thread Daniel . Egger

On 25 Mar, Blue Lang wrote:

 A lot of laptops, especially running linux @ 1024x768, will only
 support 8 bit depth. Dunno if it matters to ya or not. :P Gimping on
 the plane, ahh.

 Really? But that's not a limitation of the notebook I hope...
 The techniques used in notebook LCD's allow normal notebooks to
 run at full 15/16 bit or even in simulated 24/32bit (the circuts
 convert the real 20bit to 24 or 32bit)

-- 

Servus,
   Daniel




Re: Gimp version number in $prefix/lib/gimp/* path names?

2000-03-11 Thread Daniel . Egger

On 10 Mar, Raphael Quinet wrote:

 P.S.: I identified this problem when I tried to start an old version
   of the Gimp in order to check why the "Frosty" script was not
   giving the same results as in 1.0.  If anybody knows why this
   logo script does not produce the same effects as it used to
   create, please tell me...

 I guess the problem you're describing comes from a change in the
 sparkle plugin. The are some other scripts, too, which don't produce
 the same quality output as earlier GIMP versions.

-- 

Servus,
   Daniel



Re: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)

2000-02-29 Thread Daniel . Egger

On 26 Feb, Kelly Lynn Martin wrote:

 It will also force us to develop tools for the separate compilation of
  plugins and develop a plugin interface that is versionable

 The first one is definitely a need but "a plugin interface that is
 versionable"? We do have versioned libraries ensuring that plugins
 always use the right libgimp version and a wireprotocol which checks
 whether a plugin is using the same protocol version as the GIMP. 

-- 

Servus,
   Daniel



Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Daniel . Egger

On 25 Feb, Sven Neumann wrote:

 Which is exactly what I proposed at the end of my last mail. Despite
 that I proposed to build up the menu-structure (actually only the
 strings) in a hash-table before actually creating it.

 For a new translation function I guess?

 Would be much
 faster then going through gtk+ for each and every menu just to know
 if there's already a matching menu.

 It shouldn't be that complicated, but that depends on the internal
 representation of menus which I didn't look at.

 We'd end up with a hash containing
 all possible menu-strings with their translations as key-value pairs
 and would use that table later instead of calling gettext again.

 Uhm, no, that's not what I had in mind.

 This could be hacked in about 20 lines of code using a GHashTable, but
 I still consider this unnecessary bloat...

 Look at the code we already have to add the tearoff menus. A similar
 thing could be used to create the branches itself. 

 I'm leaving home in a few minutes and after spending a whole night 
 on other problems I'm very glad to have a look such an improvement.

 Don't expect a solution before 17:00 CET...

-- 

Servus,
   Daniel



Re: Testing and integration of The i18n solution(TM)

2000-02-25 Thread Daniel . Egger

On 25 Feb, Sven Neumann wrote:

 Don't waste your time at that. I already did that and I tried to
 explain you why there is no way to hook into that place since GTK+
 creates the submenu on the fly. At the time we create the tearoff
 menu, the submenu is already created. But when the submenu is created,
 the menu_translate function does not know the complete path and
 therefore can't lookup a matching translation.

 Hm, but I think I nearly got it.

 Unless I have overseen something obvious, the only way to go is to
 analyze the menu strings on our own before we actually build the
 menus using gtk+. The more I think about it, the more I feel it might
 be worth to try the implementation I've proposed. Eventually this
 weekend...

 Please wait a moment. Otherwise we'll work again in different
 direction.

 BTW, is there a function to unbind from a textdomain?

 No.

 There's actually
 no need to hold the plugins translation tables in memory after the
 menus are created and we only need such a small portion of it. Or are
 the message catalogs properly shared if multiple apps use the same
 catalog?

 With gettext? You must be joking. I've never seen such a bad
 implementation of anything.

-- 

Servus,
   Daniel



Re: Crash in Gimp 1.1.7 on Solaris 8.

2000-02-24 Thread Daniel . Egger

On 23 Feb, Ludovic Poitou wrote:

 SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
 UltraSPARC-IIi
 
 But I haven't compiled with the 64 bit flag on !
 
 A simple program like this :
 main(){
 printf("%d\n", sizeof(unsigned char *));
 }

 Do the plugins work for you? We've got dozens of problems with
 GIMP on 64bit architectures not using gcc for compilation.

-- 

Servus,
   Daniel



Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger

On 24 Feb, Sven Neumann wrote:

 On the first thought the idea looks promising, but I fear it is
 not that easy. GTK+ wants to create the menu using the orginal 
 strings.

 Yes. That's why I thought of ripping off a slice from both the
 translation AND the original.

 Consider this:
 Plugin wants to create a menu Image/Filters/verynew/stupidtool.
 Now we first check:
 - Is there a menu Image/Filters/verynew
   - if not continue ripping off until we found a menu which is
  already there.
 Let's assume we do have the menu Image/Filters already which
 translates into the German Image/Filter. We detected that
 the next instance we have to create is Image/Filters/verynew.
 Unfortuntely we don't have a translation handy but we can get 
 this one by taking the translation from
 Image/Filters/verynew/stupidtool and strip off the same number of
 instances. The full translation would be 
 Image/Filters/ganzneu/dummesteil Image/Filters/ganzneu and this
 is the menu to create. 

 The really trick is to sell this to Gtk+. The only think we can supply
 to Gtk+ is the menuname (the shortened one in this case) and a function
 which translates it. Thus we'd have to create a function which is able
 to do a translation although we can not directly pass the original.
 
 The translation is only used when the label is to be displayed. 

 Right.

 Therefore it then calls our menu_translate functions which takes
 care of appending the factory name (Image, Toolbox, ...) to 
 the string, passing this string to gettext and removing the factory 
 name from the translated result. GTK+ takes the returned string 
 and strips away everything up to the last '/' and puts that into 
 the menu_label. At least that is my impression of how it works. 

 Right, too.
 
 Submenus are created on the fly when they are needed. Unfortunately
 they have to be created before the actual menu_entry can be added. 
 That means if
   Image/Filters/Render/Nature/Flame...
 is to be created, the submenu 
   Image/Filters/Render/Nature
 is created automatically. Unfortunately there is no such string 
 in the textdomain of the plugin and the lookup fails. If the lookup 
 order would be different, it would be easy to store the result of the 
 latest lookup and strip the last part. But that's fiction :-(

 Right again.

 I'll think about this issue and since we got that far I'm nearly
 certain that we get a solution for this one also

-- 

Servus,
   Daniel



Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger

On 24 Feb, Sven Neumann wrote:

 the new i18n implementation supports localisation of 
 plugins outside the gimp distribution. I'm pretty sure
 that it works. I have however not yet tested if it 
 really does what we expect and if it solves the problems
 it targets. Is there anyone out there maintaining a 
 seperate plugin who is interested in internationalising 
 it? It would be very nice to get some feedback if the 
 current solution works under realistic circumstances. 

 I'll test a few plugins soon.

 Would be nice if someone else could take care of changing 
 gimptool and doing a little testing... 

 I'll look into that, too.

 If you need more explanations how the new system is 
 supposed to work, let me know. Anyway I'll try to add a 
 few lines to README.i18n in the next days.

 But don't correct my typoes... :)

 "The i18n solution"(TM) is a registered trademark owned by Daniel
 Egger

 Hey Sven, come on...

-- 

Servus,
   Daniel



Re: Testing and integration of The i18n solution(TM)

2000-02-24 Thread Daniel . Egger

On 24 Feb, Sven Neumann wrote:

 Eek, yes of course, that does not work any more. There are
 two ways to solve this: Either we search in the gimp domain
 if the lookup of the menupath failed (like we used to do (*)) 
 or we move the dummies into the plugins. I prefer the latter, 
 since it is the cleaner solution.

 I'd suggest testing for existance of the parent menu first and
 if it's not there extracting the correct translation for it from
 the full path and initialize it together with the tearoff menu.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 Huh? Daniel, stop spreading FUD and read the code. The parser in
 gimprc is actually pretty flexible.

 No, it isn't. It supposes a fixed order and fixer number of arguments
 (except the pdbargs of course), that anything but flexible.
 A tag based system on let's say XML would be a lot more flexible 
 and allow us to save some bytes in the pluginrc.

 Well, I have no problem to discuss the arguments, I just had the
 impression that you simply ignored them...

 No, I wouldn't ever do that.

 A PDB call is actually no harm. IMO libgimp should not fiddle with
 configuration files at all. Since the localisation of the menuentries
 is a problem in the core and not one of each and every plugin, putting
 the functionality into libgimp is actually bad style.

 But simple. I have no problem with a more complex solution as long as
 is seems reasonable and maintainable in a "frozen" tree. 

 I am proposing exactly the same solution, with a little difference: 
 Instead of doing the work in libgimp which is not suited to work 
 with configuration files, make the libgimp call be a PDB wrapper 
 and let the application handle the dirty work. 

 Okay.
 
 The advantage I see is that we will not need another configuration
 file and we have the information about a plugins gettext-domain
 in the plugin structure where it belongs and where it is automatically
 kept in sync with the list of installed plug-ins.

 Let's sync our ideas. We add two optional entries after the PDB args
 in pluginrc which get's parsed by the normal parser and inserted in a
 list and then my code does the rest.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 Ok, one shouldn't just bitch about other people's code, so here is my
 patch that adds an optional locale_domain and locale_path to the
 plugin structure and extends the pluginrc code to read and write that
 information from/into the pluginrc. This code is obviously a few
 lines longer than what Daniel proposes, but it seems to work very
 well here.

 Great! I'll have a look.

 The locale information is optional and if the locale_domain is given,
 there _can_ be an additional locale_path entry. The code handles the
 case that pluginrc registers the locale_domain twice (by using the
 last given entry), but that should never happen unless the user edits
 the pluginrc by hand.

 Hm, I don't really now whether this assumption is safe, but anyway it's
 a thing we don't have to fiddle with right now.
 
 You will find the patch at
 http://sven.gimp.org/files/locale_parse.patch.
 
 It only contains the code to read, store and write the locale info for
 the plug-ins. This will have to be extended to do build a list out of
 this entries (eventually checking for the existence of the given
 paths). Other necessary parts can be taken from Daniels patch.

 The code for building the list is also there.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 You will find the patch at
 http://sven.gimp.org/files/locale_parse.patch.

 OK, looks fine to me. I changed my files accordingly.
 libgimp/gimpdomain.* is now futile. And the gimpgettext.* file
 were changed to support that scheme. I added a few lines to
 your modified gimprc.c to support that. The only thing
 missing now is the pluginrc write code.

 I added the libgimp and gimp-std-plugins to the default domains,
 so no need to specify them elsewhere. Also everything works fine
 like before.

 Patch against CVS gimp and Sven's patch appended.

-- 

Servus,
   Daniel

 diff31.gz


Re: print plugin

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 I hate to note that, but hopefully this will teach the one who applied
 that patch in request of someone else, to check patches more
 carefully before applying them. If you want to know who is ment here,
 read the ChangeLog. But I think you already guessed it...

 I think you shot yourself into the foot. I guess you meant me and Marc
 but in fact I never touched the print plugin but ChangeLog says:

 Mon Jan 31 22:43:48 CET 2000  Sven Neumann [EMAIL PROTECTED]

* libgimp/gimpcolorspace.c
* libgimp/gimpcolorspace.h: added INTENSITY() macro

 [ ripped off a few entries ]

* plug-ins/print/print-util.c
* plug-ins/rcm/rcm_misc.h: use INTENSITY() and other 
color_conversion_routines from libgimp. I'm not sure if I have 
tested all this properly (I tried to do), so if you are bored, 
please play around with the changed plug-ins.

 I guess this one introduced it. However it could also have been this
 one:

Mon Feb  7 12:57:16 CET 2000  Stanislav Brabec  [EMAIL PROTECTED]

* plug-ins/common/sparkle.c, plug-ins/common/bumpmap.c,
* plug-ins/common/gz.c, plug-ins/common/tileit.c,
* plug-ins/common/oilify.c, plug-ins/maze/handy.c,
* plug-ins/print/print-util.c, plug-ins/sinus/sinus.c,
* app/channels_dialog.c, app/fileops_cmds.c,
* app/nav_window.c, app/path_tool.c, app/scan_convert.c,
* app/xinput_airbrush.c, app/airbrush_blob.c:
On request of Martin Weber [EMAIL PROTECTED].
Remove obsoletted rgb-hsv routines, purifications.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 gimp_plugin_add_locale_domain (gchar *domain_name,
  gchar *domain_path)
 
 and can only be called in the query function of a plug-in. The
 domain_path may optionally be NULL. Proposals for a better name are
 welcome.

 I'd recommend gimp_plugin_domain_add (gchar *domain_name)
 and gimp_plugin_domain_add_with_path (gchar *domain_name,
   gchar *domain_path)

 because it IMHO fits better into the namespace and is more obvious
 than to have just 1 function with two meanings.
 
 Daniel, if we can agree on this solution, I would like to check this
 code in, so that you can work on adapting your code to the framework.

 I sent a newer patch in my last mail. It should do everything we need
 for now.

 I totally agree with this solution, so let's finalize it and get it
 into the tree.

 While working on the code I came across a new idea which would
 simplify things quite a bit eventually: The plugins create their
 menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why
 not use the knowledge about the domain_name the translated string is
 to be found in and only look it up in that domain by passing it to
 menus_create_item_() ? You'd only have to change the code to iterate
 through the plug_in_defs instead of proc_defs since the domain is
 stored with the plug_in definition.

 I'm afraid I don't understand that. Could you please explain it again?

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 No, that won't work. Of course you need to hook somewhere into
 plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins
 won't be able to register their domain on the first call.

 Of course you are right, just a braino.

 The only thing missing now is the pluginrc write code.
 
 Huh? The info is already written into the pluginrc!

 I didn't say what I mean (TM), I meant the PDB code.

 New patch appended.

-- 

Servus,
   Daniel

 diff32.gz


Re: PROPOSAL: New i18n solution

2000-02-23 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 One of us defintely works too much and too fast.

 Uhm, but who? I think its you... :))
 Sven, you are doing great work

 I have just checked
 in a working solution which gets rid of the annoying
 iterate-through-all-domains problem.

 Great

 Sorry, but when I had the idea how it could work (actually Mitch
 helped a little) I just had to try it. Since the changes are so small
 and no new files are necessary at all, I just had to check them in.
 The overall idea is of course still yours and we owe you much for
 solving the i18n problem.

 grin

-- 

Servus,
   Daniel



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 22 Feb, Raphael Quinet wrote:

 I did not like the GNU style at first (especially the space before the
 opening parenthesis) but now I understand that it is very important
 to keep a consistent coding style in each project, because it keeps
 the code manageable and maintainable.  So I always use whatever coding 
 style is recommended for the each project, even if this means that I 
 have to format my patches differently for the Gimp and for a Linux 
 driver, for instance.  Since the Gimp uses the GNU style, I think that 
 it is important to follow the GNU coding guidelines faithfully.

 Okay, will turn from the Standard vi indention into GNU coding style.

 BTW: While browsing the code I saw some file not matching ANY standard
 like xcf.h. It has neither a GNU header nor any guardings

  It's not that much code, and does fix a gaping hole in the i18n
  framework for plugins not distributed with gimp. Especially if we
  want 1.2 to last a while..
 
  That's absolutely right.
 
 Yup!  Me too (tm).

 Glad to hear that.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-22 Thread Daniel . Egger

On 22 Feb, Sven Neumann wrote:

 With the usage of static array and buffer lengths you demonstrated in 
 your patch it will most likely introduce one or two new bugs, but
 that could easily be hacked up a little cleaner

 Of course I could have used a linked list, but I'm not sure if
 it's worth using it.

 I also don't like the format of the localerc you proposed since it
 doesn't look like the other files in ~/.gimp-1.1. Why not use the
 scheme-like syntax people are used to use and that the gimp can parse
 anyway?

 I'd like to avoid having to extend the parser from GIMP because
 I don't need much functionality and this would surely introduce
 more bugs. But if this is a real concern, then I'll do it together
 with point 1.

 I'm not yet convinced that this goal is worth all the hassle. What do
 other people on this list think about this?

 If we don't change it know we'll be shipping 1.2 with crippled
 localisation support, since the number of plugins is increasing
 constantly and we're trying to get rid of some in the main distribution
 I really thing that something like this is a really must-have.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-22 Thread Daniel . Egger

On 22 Feb, Manish Singh wrote:

 True, although we have a couple other inconsistencies already. The
 coding style needs to be the same as the rest of gimp though.

 I tried to bring it as near as possible. Of course a lot things could
 be better

 It's not that much code, and does fix a gaping hole in the i18n
 framework for plugins not distributed with gimp. Especially if we want
 1.2 to last a while..

 That's absolutely right.

-- 

Servus,
   Daniel



PROPOSAL: New i18n solution (2nd try)

2000-02-22 Thread Daniel . Egger

On 22 Feb, Sven Neumann wrote:

 With the usage of static array and buffer lengths you demonstrated in 
 your patch it will most likely introduce one or two new bugs, but
 that could easily be hacked up a little cleaner

 Okay, I took some of the comments and updated the files.
 I'm now using a single linked list to store the domains and
 I reindented the source to match the other files.

 Patch attached...

-- 

Servus,
   Daniel

 diff30.gz


Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 22 Feb, Federico Mena Quintero wrote:

 I don't know if this will be useful at all, but the GNOME Programming
 Guidelines has a snippet for .vimrc to set the Linux kernel
 indentation style. 

 This is the standard vim style.

 If you tweak it a bit it may work for GNU indentation style.

 No, unfortunately I couldn't get vim used to GNU indention style.

 Please tell me if this works or if you had to change something; I'd
 like to keep that part of the programming guidelines as accurate as
 possible.

 It'd work, but not for GIMPs code. :/

-- 

Servus,
   Daniel



Re: Coding style (was: PROPOSAL: New i18n solution)

2000-02-22 Thread Daniel . Egger

On 23 Feb, Marc Lehmann wrote:
 Then, most probably, you have a very very old or broken version of vim
 (or maybe you use another editor, or vim in vi-emulation mode).

 Actually it's the latest stable version of vim.

 The whole point of these options is to make indentation automatic and
 more-or-less gnu-style.

 I was told that the style I used before is not acceptable as GNU style
 so I guess it's the less in "more-or-less".

 In any case, giving "my editor does indent differently" is a very poor
 reply to a request to follow a specific coding style.

 Well, Marc, if you followed this list then you'd know that I already
 posted an well indented and improved version of my patch. It was just
 a kind of a BTW note that I can't bring my editor to automatically 
 create this indention style.

 You can write 
 gnu-style using any non-broken editor! So if your editor does indent 
 differently, use the keys of your keyboard to correct your editor, or
 read the docs on how to persuade your editor to do it for you.

 This seems impossible, but fortunately indent is working quite nice for
 me so this is now just an annoyance no "problem" anymore.

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-22 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 The current solution for the plugins
 distributed with The GIMP works reasonably good.

 Really? I wouldn't call "we have to pre-add the menuentries to GIMPs
 core source otherwise it wouldn't work" working good. Actually my
 patch doesn't really address those problems, but the current code
 for plugin localisaing is more or lass an evil hack. 

 I don't see why we 
 should ditch the hardcoded path in favor of a config file the user 
 will be able to mess with. I thought your proposal would only be a 
 hook for additional plugins?!

 It was meant such, but from your description it seemed to me that 
 you'd like to add those entries to ALL plugins. From your answer
 I can see that this was just a misunderstanding. Sorry, Sven.

 But this make it even harder to modify the parser like you'd like
 since it's only usable for a fixed number of arguments. It would work
 to insert those parameters before the pdb-args but that would 
 a) be incompatible and b) mean that every plugin must have such an entry.

 I was speaking about the fact that whatever solution we come up
 with will not be backward compatible.

 Of course it will or at least should try to be. My current solution for
 example is. And your suggested solution will also as long as you don't
 touch the wire protocol.

 I will have to look through the code in app/plug_in.c a little more,
 but I think I was wrong in my last mail and there's no need to change
 the wire protocol at all. 

 It would be really bad to do so. And even worse: This code is very
 simple to break, just look at it and it won't compile on DEC Alpha
 anymore; another look and it will cause every plugin under Solaris to
 fail. :( 

 The amount of code-changes is IMHO more or less equal. The small 
 feature you want to add should be well-thought and I don't see 
 why you simply wipe away the arguments have I put up against your 
 solution.

 Of course I try to wipe them away if they seem not reasonable or
 correct to me, that's how argumentation works. HOWEVER this
 doesn't mean that I don't care about your thoughts, they are
 really helpful and result in new ideas in my head.

 Just to clarify what I do think of:
 I'd like to have this done as simple as possible that means:
  - No PDB calls
  - No wire protocol changes
 There should be a simple libgimp call which allows plugins to
 register themselves in a new domain. If the domain is already
 available, check whether the path matches (not done in my patch
 yet!), if not simply add it.
 The GIMP on the other side should simply be able to get all the
 registered domains and to do the right things when gimpgettext()
 is called.

 Sven, your ideas are very nice but they are neither simple nor
 so easy to implement like mine. Please consider that we have 
 already feature freeze, are trying to get a stable version out
 and just don't have the time for a fullfeatured platinum
 solution.

 Don't tell me that you have spent days to create your patch 
 and don't want your hard work to be discarded.

Sarkasm on

 GOD, I spend days without anything to eat and drink in my room just
 to get this idea into a working patch. PLEASE don't blow it away!

Sarkasm off

 Sven, if you have good ideas, tell them to me and the world, any ideas
 are really appreciated. My only goal is to do my very best to get a new
 stable release of this great project done ASAP. I don't care about anything
 else at the moment and would rather like to concentrate on the GIMP
 instead of wasting time with flaming. 

-- 

Servus,
   Daniel



Re: PROPOSAL: New i18n solution

2000-02-22 Thread Daniel . Egger

On 23 Feb, Sven Neumann wrote:

 The core would then have to try to bindtextdomain() to all
 possible paths until success (or total failure if no message
 catalog was found).

 You can't find out whether bindtextdomain failed or not. The only
 way to get the information whether a catalog is available in a path
 or not is to find the files yourself and then register them with the
 right path. :(
 Welcome to the nice world of gettext.

 Anyway, I'd really like to leave the decision where to install a
 catalog to the plugin. Considering that most of the external plugins 
 will get their own configure script it would be simple to find a 
 convinient place for the catalog, assign it to a #define and use this
 define in the sourcecode of the plugin.

-- 

Servus,
   Daniel



Re: the .po filename domain

2000-02-21 Thread Daniel . Egger

On 21 Feb, Marc Lehmann wrote:

 I have a question: what standard do the po-filenames follow? In the
 current gimp, we have a en_GB translation, however, GB is not a
 toplevel domain, but the iso-3166 code for the UK.
 
 On the other hand, we also have uk (which is a toplevel domain, but
 not for ukraine), however, the iso-3166 code for ukraine is ua.

 So something seems wrong here. I *think* the easiest thing would be to
 standardize on iso-3166 and rename uk.po to ua.po.

 This is the right solution. AFAIR do all the other packages the same.

-- 

Servus,
   Daniel



Re: pathsP.h

2000-02-21 Thread Daniel . Egger

On 21 Feb, Blue Lang wrote:

 did that. :) 
 
 if you have time, would it be possible to get someone with better
 bandwidth than i to download a clean copy of CVS gimp and see if it
 builds?

 Yes, it builds it's in our SuSE internal database

 i've done distclean and autogen, etc, etc - apps/pathsP.h is
 still not in CVS (and there still seem to be dependancies on it,) and
 the intl/ dir stuff still stops the build cold.

 Should 1.1.17 build w/out gnu gettext if I configure with
 --disable-nls?

 It should, this isn't tested thoroughly though, because we
 expect people being tough enough to test the CVS version to
 have all the necessary utils including gettext-0.10.35.

-- 

Servus,
   Daniel



PROPOSAL: New i18n solution

2000-02-21 Thread Daniel . Egger

Hi developers,

 as you might know that gettext solution works quite nice for
 GIMP itself but may cause trouble with plugins. To circumvent
 the problem that every plugin must have it's domain registered
 within the GIMP source, I'll offer you a new idea here:

 0. Foreword
 Basically we can't get away from gettext and switch to a better 
 system (which would have to be written first, too) that short before a 
 release like at the moment. Thus my goal was to change as little as
 possible. Like you'll see, we'll just have to add a line to every
 plugin outside the GIMP distribution to make this work; everything
 else stays the same like it is now, even the catalogs remain untouched.

 1. Ideas

 1.1 The config file
 The current system is a very static one i.e. nothing can be changed 
 neither without the sourcecode nor after compilation. What we need
 is a dynamic system to remove that deficiencies. A good way to bring
 some dynamic into a system is to make it configurable for example by
 having a config file.
 This configfile of course shouldn't have to be modified by an editor
 but automatically by the GIMP resp. libgimp.

 1.2 Plugins with libgimp
 To get this information in there we'll provide a funtion call in 
 libgimp which registers the domain from the name and path the plugin
 CAN provide. If the domain hasn't been registered yet it'll its way
 into the configfile
 
 1.3 The GIMP core
 The GIMP uses the information from this file to bind the necessary
 catalogs to itself. To actually use this bound domains we'll have to
 provide a function which won't look up a message in one catalog but
 recurse through all of them. This function will replace the gettext
 call just in places where the GIMP would lookup a menuentry which
 is sometimes not in its own catalog.

 2. Implementation

 2.1 The configfile
 Like all other configfiles this one will stay in ~/.gimp-Version.
 The first line contains ":gimp" to ensure that no one messed up this file.
 The next lines contain the name of the domain, a withespace and the
 location of the catalog. One catalog per line.

 2.2 Plugins with libgimp
 For the plugins we'll have two new functions in libgimp/gimpdomain.c
 which have the selfexplaining prototypes.

 gimp_domain_add (gchar *)
 and
 gimp_domain_add_with_path (gchar *, gchar *)

 Every plugin may register a domain but don't has to necessarily.
 The functions call another static one which checks whether the files
 already exists and whether the domain is already registerd. If so it
 won't be registered again else it will.

 2.3 The GIMP core
 GIMP will call initgettext() at startup which will initialise i18n
 if compiled with it and setup a default (and fallback) domain "gimp"
 and every domain that it'll read from localerc.
 Every occurence of gettext which had been used to translate menunames
 will be changed to gimpgettext which consists of a loop which checks 
 for a possible translation in all domains which were read from
 localerc.
 At the end GIMP'll call freegettext() to clean up everything.

 3. Conclusion
 This idea will cirumvent most of the problems which gettext alone
 just can't deal with. It's little and as such not very likely to 
 introduce many new bugs. It would allow us to ship GIMP 1.2 with
 the possibility to add plugins which will also benefit from
 localisation without any hassle.

 Patch against current CVS is appended. Please feel free to contribute
 further ideas and to comment this stuff.

-- 

Servus,
   Daniel


diff -P -r -u gimp/app/Makefile.am gimpnew/app/Makefile.am
--- gimp/app/Makefile.amMon Feb 21 23:26:00 2000
+++ gimpnew/app/Makefile.am Tue Feb 22 00:11:35 2000
@@ -198,6 +198,8 @@
gimpcontextpreview.h\
gimpdnd.c   \
gimpdnd.h   \
+   gimpgettext.c   \
+   gimpgettext.h   \
gimphelp.c  \
gimphelp.h  \
gimphelp_cmds.c \
diff -P -r -u gimp/app/gimpgettext.c gimpnew/app/gimpgettext.c
--- gimp/app/gimpgettext.c  Thu Jan  1 01:00:00 1970
+++ gimpnew/app/gimpgettext.c   Tue Feb 22 01:02:10 2000
@@ -0,0 +1,188 @@
+/* The GIMP -- an image manipulation program
+ * Copyright (C) 1995 Spencer Kimball and Peter Mattis
+ *
+ * gimpgettext.c
+ * Copyright (C) 2000 Daniel Egger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write 

Re: An experiment (was Re: Move help menu item...)

2000-02-14 Thread Daniel . Egger

On 13 Feb, Kelly Lynn Martin wrote:

 This can be dangerous; you can get a resizing loop if your code isn't
 carefully written.  Window managers can refuse to accept a client
 resize request or can modify it, which could result in a duel between
 GIMP and the window manager as the two fight over who gets to decide
 what size the window will be.

 Hm, but how does it work to create the initial window then? Doesn't
 gtk/gdk tell the window manager how big the window should be? Maybe
 it would be even possible to hide/destroy the window and then show/create
 it again when we'll now the final size. This things are really mystic to 
 me, do you have experience in that area?

-- 

Servus,
   Daniel



Re: An experiment (was Re: Move help menu item...)

2000-02-10 Thread Daniel . Egger

On 10 Feb, Raphael Quinet wrote:

 Flexibility is ok.. but some time create problems.
 Why don't set fixed sizes x*y to cover all the dimension of toolbar?
 This could be usefull to have right dimension and good
 rappresentation.

 Unfortunately, this is not so simple.  Constraining the dimensions of
 a window requires some cooperation between the application and the
 window manager.  Under X, you cannot simply tell the WM that some
 fixed sizes should be allowed for your window but not some others.

 Hm, couldn't we use the event handling system to automatically resize
 the toolbox to a new good value on every resize event:
 If you enlarge the toolbox the window size automatically snaps on the
 next convenient size and vice versa...

-- 

Servus,
   Daniel



Re: gimp i18n == segfault

2000-02-09 Thread Daniel . Egger

On  9 Feb, Marc Lehmann wrote:

 Since about two weeks, setting LANG to any value results on a
 segmentation fault on startup.

 Since I cannot reproduce this (i.e. GIMP works just fine)
 I'd need more input on this.
 
 Your stacktrace seems like it crashes when initialising the
 help_pages but I can guess that only from the arguments to
 the g_str function. Could you please compile libgimp with
 debugging information and report again? 

-- 

Servus,
   Daniel



Let's squeeze that i18n bug!

2000-02-09 Thread Daniel . Egger

Okay people,

 since there seems to be some i18n which I can't reproduce but
 a lot of people seem to experience it's time to take the next step.

 According to the bug report #6052 and the inline stacktrace it seems
 that menus_create_item in menus.c calles gtk_item_factory_create_item
 which then calles gtk_item_factory_parse_path which seems to cause the
 segfault. This leads to my assumption that an invalid path is being
 used OR a GtkItemEntry has a pointer to a not valid memory region.

 To aid debugging please send me your output from GIMP compiled with the
 little patch attached. Compile it, and run GIMP with gimp 2log and
 send an mail with log attached to [EMAIL PROTECTED]

 I assume this bug is introduced by a broken gettext behaviour which
 my system doesn't suffer from. I tried all the hints given to reproduce
 this but my system stays stable (bastard :)) and GIMP runs like
 expected in the set language.  

-- 

Servus,
   Daniel



--- app/menus.c.origWed Feb  9 15:39:07 2000
+++ app/menus.c Wed Feb  9 15:46:40 2000
@@ -1555,6 +1555,8 @@
   menu_item = gtk_item_factory_get_item (item_factory,
 ((GtkItemFactoryEntry *) entry)-path);
 
+  fprintf(stderr,"Created: %s\n",((GtkItemFactoryEntry *) entry)-path);
+  
   if (menu_item)
 {
   gtk_signal_connect_after (GTK_OBJECT (menu_item), "realize",



Re: Let's squeeze this i18n bug (quoting by heart) - bug report #6052

2000-02-09 Thread Daniel . Egger

On  9 Feb, Mike wrote:

 Here is the file log you requested in order to have an easier
 debugging. Hopefully it can be useful, so that you fix this bug! BTW:
 On my box, not all locales (as Mark said in his report) are broken. I 
 tested out them all, and I found that only it and de crash gimp.- Any
 particular reason for that??

 Now I do know the reason for YOUR crash:
 The output shows that your GIMP crashes just before initialising
 the menu "/Layer Boundary Size" which is obviously not correct translated
 in the Italian catalog. There seem to be a few more maybe also in the
 German catalog. 

 This, however, is no answer to the question: Why the hell does my
 system not crash although using the same catalogs?

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-08 Thread Daniel . Egger

On  7 Feb, Tuomas Kuosmanen wrote:

 I'm expecting a lot from this tool though, I really wish Simon and the
 dudes have time to finish it.

 Maybe some people will find time to lend him a helping hand... :)
 ... for 1.3.
 
-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-07 Thread Daniel . Egger

On  6 Feb, Marc Lehmann wrote:

 This has been mentioned at least three times on this list: one of them
 works, the other doesn't.

 Both don't work correctly, as I stated before. Do you read my mails?
 The Bezier Select Tool behaves very strange: Points appear automatically
 here and there and sometimes I can't change a curve. I don't know how
 this can be reproduced as I can't trigger this bugs always... :/

 Even a gimp-beginner can find this out in minute or so.

 A beginner will most probably not use this tool for making
 selection because it'll give strange results if you don't know how it
 works... No, this aren't just my thoughts. I demonstrated the GIMP
 to quite a lot of people who are using it now and tell me those things.
 
 Serious question: are you reading this list, or are you ignoring what
 others write? I am not so sure anymore...

 I do read this list but I can't read any messages that didn't go
 through my mail system first, if you know a fix for this, I'd really
 appreciate it... :)

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-06 Thread Daniel . Egger

On  5 Feb, Nick Lamb wrote:

 Please do not step forward and say "I'll do it", the time for that was
 in November or at the latest December, and there was conspicuous
 silence during my last Triage thread from those named to defend their
 code.

 You are right, it's time to cleanup. Unfortunately I don't know which
 code is in a better state to stay and which one has to go.

 Now is a good time to check-in fixes to code that you left in an
 untidy state (expect some File plug-in code in that vein) and to
 file bug reports for mysterious occurences that you've been putting
 up with during the development cycle.

 Me or Sven? And what "mysterious occurences"? Tell me, I'd like to fix
 them all... :)

-- 

Servus,
   Daniel



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-06 Thread Daniel . Egger

On  5 Feb, Marc Lehmann wrote:

 Thats not the point. The point is effective user feedback.
 Now, where are the users? :)

 Here is one. If you are not a user you should not decide whats best
 for them. Especially not if you limit your horizon to a single person
 (yourself).

 I'm running tests with more or less experienced people to get some
 feedback. One of the common thoughts: The icons are very bad. 

 Tigert? hint, hint

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-06 Thread Daniel . Egger

On  5 Feb, Tuomas Kuosmanen wrote:

 Argh.. I am used to toggle between paintbrush and pencil. Like I
 pointed out in my previous mail on this thread, I use the paintbrush
 as a "fine tuning" tool together with the "real" tool I am drawing
 with. And if it is the paintbrush, then there is no way to toggle fast
 between those.. clicking a checkbox every time instead of pressing a
 shortcut key sounds clumsy.

 We could add a plugin with toggles this per shortcut. Would that be
 sufficient? 

-- 

Servus,
   Daniel



Re: Performance

2000-02-05 Thread Daniel . Egger

On  4 Feb, Raphael Quinet wrote:

 I wouldn't be too sure about that.  On a system that I was previously
 administering (students' network at the university), I have seen some
 users that were using /var/tmp or /tmp to store their applications
 while they were logged in, and deleted the stuff afterwards.

 In our university you just have a chance to compile anything if you 
 are using /tmp. It is also a very convenient place because everything 
 else will go over NFS and thus is dog slow. You can even leave your
 programms there if you make sure that you get the same machine back if
 you need them or the /tmp-machine is at least running Linux... :)
 It makes also sense to crosscompile projects like GIMP on an Alpha
 maschine with plenty of memory and very fast RAID clusters. 

 progress?  On third thought...  If your disk quota is exceeded, you 
 will not even get the core dump.  On fourth thought... :-)  Who in 
 their right mind would use the Gimp on a systems that has such strict 
 constraints?

 I do sometimes, but you are right: In general it's better to convince
 the sysadmin to install a programm in a place where everyone might use
 it than forcing eveyone to do it for himself. Unfortunately you won't
 have a big chance to get your favourite latest snapshot of some
 software installed :( 

-- 

Servus,
   Daniel



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-05 Thread Daniel . Egger

On  4 Feb, Steinar H. Gunderson wrote:

 I'm constantly finding myself looking for tools. I know that they are
 there, but I have to stop and look closer at almost every single tool.
 There are simply too many tools (some of them could well be combined),
 and the icons look very much the same (believe it or not). I don't
 know if colour would solve this (or just add clutter), but we should
 really get to reduce the number of tools, as a previous poster
 suggested.

 Yes, at least the Pencil now is rather useless

 Now, where are the users? :)
 
 They're buried in the pile of messages from gimp-developer (I was told
 "2 or 3 messages per day" when I joined) ;-)

 Bad luck... Believe me, it'll go better at least in summer :)

-- 

Servus,
   Daniel



Removing pencil?

2000-02-05 Thread Daniel . Egger

Hiho!

 I think it's time to remove that useless pencil before the release
 of the magic version 1.2. Did anyone use it in the last time?
 It contains no functionality that paintbrush doesn't have except of
 hard edges (anyone needing that "feature"?)...

 Anyway: This is up for discussion on this list. Quite a lot people
 I know think it's useless but maybe you don't think so. :)

 Patch is appended

-- 

Servus,
   Daniel

 diff23.gz


Pathtool?

2000-02-05 Thread Daniel . Egger

Hi developers,

 At the moment we have got 2 Pathtools in GIMP. One which is called
 Bezierselect in the Toolbox but has a Path dialog
 (in the Layers/Channels dialog???) and another one called Path tool.

 The latter works a lot nicer IMHO but I haven't managed yet to
 transform a path into a selection and the former has better support
 in form of a dialog. Which one should we keep? Or better: should we
 merge it into one Tool which works nicely AND has a support dialog?

-- 

Servus,
   Daniel



Re: Edit Fille behaviour change?

2000-02-05 Thread Daniel . Egger

On  4 Feb, Kelly Lynn Martin wrote:

What does Photoshop do?
 
 What does that matter?  

 Photoshop is the most used graphicstool out there and it makes sense
 to have a closer look on their behaviour especially in the UI sector.

 Anyway, even if books do now say that Fill fills with the background
 color, the obvious way would be using the foreground color. I'd prefer
 that, too, but we then also have to correct all plugins/scripts! 

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, FUJITA Yuji wrote:

 Which one should we keep? Or better: should we
  merge it into one Tool which works nicely AND has a support dialog?
 
 I hope them to be merged into one tool with support dialog.
 
 Anyway, the dialog window title should be something like
 "Layers, Channels and Path" or so.

 Yes, forgot to mention that :)

-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 OK, I'll repeat it once again: The new tool was an approach to design
 better path tool taken by Simon Budig.

 Well, I talked with Simon about it.

 The goal was to exchange the
 user interface of the BezierSelect tool when it becomes useable. Simon
 didn't find the time to complete it and noone else did.

 But it seems that work on the Bezierselect was done...

 There's no
 need to discuss which path tool should make it into 1.2, since there
 is only one that is working.

 It works, it may not have all the features that Simon desired but it's
 nice nevertheless...

 You are too late if you want to change
 this now!

 Why? Fixing tools which are in there and removing redundant code is
 our work at the moment.
 
 The Path tool will not be in Gimp-1.2.

 I'd like to hear the thoughts of developers, too

 Same applies to the Xinput
 Airbrush unless someone fixes it really quick now (I see a small
 chance for the Xinput Airbrush to be fixed in time since its a
 standalone tool).

 OK... 

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 It is a very important feature, believe me!

 It's your right to consider it useful, I don't and won't believe you...

 But the pencil can easily
 be merged with the Paintbrush by adding a "Hard Edges" option.

 Yes, if you appreciate. But the makes the eraser rather useless...
 We could add the eraser features, too and use the same codebase for
 these 2 tools.

-- 

Servus,
   Daniel



Re: The toolbox...

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 It works much better now (/me thanks Kelly).

 "much" is a bit too much... :)
 It definitely works better but the current behaviour isn't acceptable
 for the release anyway 

 Well, if you don't see the advantages of a more configurable toolbox
 layout, I can't help you...

 Configurable? If it WOULD work then I'd have nothing against this
 feature but it doesn't i.e. won't allow to change the orientation of
 any of the widgets in it and thus is a decent bug and nothing more.

 We will have much better approaches in 1.3 (I have plans for a fully
 configurable toolbox including menus etc.) and since we can't change
 anything in the toolbar without modifying the code which isn't an
 option for a user I'd really recommend to remove that "feature" or
 at least fix it (I don't get the logic behind it so I won't touch it,
 will you?)...

 Of course this needs to get better before 1.2, but I don't
 hink that lamenting about it will help.

 The only thing I want is a stable featurerich release of GIMP and that
 really soon now. Everything else doesn't matter. Instead of bashing me
 you should rather keep our goal in mind. 

-- 

Servus,
   Daniel



Re: Removing pencil?

2000-02-05 Thread Daniel . Egger

On  5 Feb, SHIRASAKI Yasuhiro wrote:

 I'm all for removing the Path Tool, the Xinput Airbrush and and
 merging Pencil and Paintbrush. If I counted correctly this would
 reduce the number of tools to 24. This is a perfect number of tools
 since 24 % [2|3|4] == 0 which means we always get a nicely layed out
 toolbox. 

 core and plug-ins feature isn't frozen yet? 

 This would be a proper cleanup. Do you want to leave old cruft in for
 release rather than removing it?
  
-- 

Servus,
   Daniel



Re: Pathtool?

2000-02-05 Thread Daniel . Egger

On  5 Feb, Sven Neumann wrote:

 Do you have any idea how much work is needed to integrate it with the 
 Paths dialog?

 No, not yet, but I'll have a closer look on this.

 A number of new bugs would certainly be introduced by
 doing so. That's why I say: It's too late!

 Every line of code introduces new bugs...

  I'd like to hear the thoughts of developers, too
 
 You hereby finally managed to make your way onto my kill-list. Expect
 me to ignore your mails in the future.

 Nice way of discussing problems, congratulations

-- 

Servus,
   Daniel



Re: Performance

2000-02-03 Thread Daniel . Egger

On  3 Feb, Arcterex wrote:

 I think that this was discussed some time back and the conclusion was
 that if you have 5 users on your system all using gimp and each using
 50%... well, you see where that could be a problem.

 In that case you could adjust the value manually. But bear in mind:
 If you have 5 users manipulating big pictures via remote X you will 
 have other perfomance problems than too little memory...
 
-- 

Servus,
   Daniel



Re: Performance

2000-02-03 Thread Daniel . Egger

On  3 Feb, Raphael Quinet wrote:

 I think that asking the user is the best solution in any case, because
 you can hope that the user has some vague idea of how much memory is 
 or will be available on the system he is using (shared or personal 
 computer).  This will not work in all cases (e.g. dumb users, or users 
 who have a home directory mounted on a network of heterogenous 
 machines) but it will probably be better than any attempt at guessing 
 what is best.

 If you have a shared maschine the best would be to let the
 administrator choose how much memory each user will get because
 users'll ALWAYS try to get what they can even if it makes no
 sense 

-- 

Servus,
   Daniel



Re: installing .po files in addition to .gmo files?

2000-02-03 Thread Daniel . Egger

On  3 Feb, Marc Lehmann wrote:

 Hmm... I removed gimp-perl.pot now. However, all the other .pot files
 _are_ in cvs.

 Shouldn't be, the files are generated at compile time and ignored by
 CVS...
 
 Whats the logic behind that?

Server:/usr/src/gimp/po # less .cvsignore 
*.gmo
*.mo
Makefile
Makefile.in
Makefile.in.in
POTFILES
cat-id-tbl.c
gimp.pot
stamp-cat-id
messages

-- 

Servus,
   Daniel



Re: installing .po files in addition to .gmo files?

2000-02-03 Thread Daniel . Egger

On  3 Feb, Marc Lehmann wrote:

 You seem to want to move the catalogs to the home directorys, which is
 much worse (one copy for each user is insane).

 But would work

 Do you have any _reasons_ not having a seperate domain (speed?
 usability?) AFAIK it'S only in a few places neede d(probably only
 one).

 Having multiple domain makes things rather complicated. And the whole
 idea would only work as long as the user can write his own files which
 isn't true for multiuser systems - there you've got only your
 homedirectory...

 OR can we bind a domain on more than one .mo-file (probably not).

 Hehe, the name of the domain is directly coupled to the filename,
 however it should be possible to use symlinks... :)

  I think it's the same as yours, but beware: Before merging catalogs
  you have to remove the headers and duplicate entries or msgfmt will
  refuse the compile them
 
 msgmerge? (I hope that'll do it). OTOH, perl is versatile..

 msgmerge won't work. It is "designed" to work just with one template
 and one catalog... I had something in mind like: 
 cat them together, remove the second header and duplicate entires (i.e.
 entries with the same wording)

 All of this is a theory.  I just want to make sure that, in six months
 or a year from now on, people can use the all-new gimp-installer and
 it works with the last stable release.

 :)) using gettext? Marc, I just remembered what you said to me about a
 half year ago: gettext is broken! NOW I believe you, I fear I could
 write buglists which are longer than the source of gettext... growing
 day by day :(

 So it does not matter wether it's slow to merge catalogs, it matters
 wether it is possible at all to cleanly install plug-ins later.

 My idea would work, but would cost space

  I'm no fan of further dependencies you know...
 Neither me... any better solution, though? No...
  No, despite of replacing gettext :)
 
 You would work on that (in the long term)...? (hopefully ;)

 Yes...

  We could also use to remove the barriers in GIMP i18n for know. This
  would only have one big limitation we also suffer from at the
  moment:

 As long as it doesn't introduce new limitations it does not matter.

 Limitations are relative... :)

 You mean a single mega-catalog containing gimp-perl, libgimp,
 gimp-std-plug-ins, gimp?

 Yes.

 Why is that necessary?

 To prevent gettext from not working. Remember the idea I told you
 (allowing several catalogs to be bound to one domain)? That would
 be the only real solution for multi-binary-applications like GIMP.
 This is unfortunately not realisable with gettext but merging all
 catalogs together into one and thus having only one domain would
 have the same effect and thus remove the limitations of the current
 code. 

  e) Head for a proper solution afterwards? :)  
 
 Me, too!

 :)

-- 

Servus,
   Daniel



Re: Updating 1.0.4 plug-ins to work with 1.1.x

2000-02-03 Thread Daniel . Egger

On  3 Feb, Marc Lehmann wrote:

 Now that you mention it, I have the same problem since around 1.1.13
 or so.  However, that was the time I installed XFree-3.9.1x, so I
 thought this is a bug in my X-Server.

 XFree-3.9.1* isn't guilty, at least not general as I cannot reproduce
 this without using a broken gtk theme

-- 

Servus,
   Daniel



Re: Print plug-in

2000-02-02 Thread Daniel . Egger

On  2 Feb, Steinar H.Gunderson wrote:

 In my illusion at least making tags from events and the
 way back should be simpler...
 
 The problem with Perl is the parsing step, not the recording step. We
 already have well-working code for parsing/running Perl.

 That sentence doesn't make a lot of sense to me. I agree that we've got
 well-working code for parsing/running Perl, well, that's Perl :)...
 But where's the problem with the parsing step? And how do you produce
 Perl code?

-- 

Servus,
   Daniel



Re: Some UI inconsistencies and a patch....

2000-02-02 Thread Daniel . Egger

On  1 Feb, Marc Lehmann wrote:

 Your:
 
 "
 Category  New File
 "
 
 Looks IMHO much worse than the existing:
 "
 Category  New File Settings
 "

 Not really, you have the word "Preferences" just a few mm above it.
 Also there was some inconsistency: The category "Monitor Information" was
 a settings dialog anyway but it had no "Settings" in its name

  2. Some tools had a "Tool" in the options dialog and some not. Since
  all toolsare tools and people know what tools are, we don't need
  to call some
 
 Same thing here. Just because all tools are tools there is no reason
 _NOT_ to display this.

 Well, we could have add the word "Tool" to all tools the other way
 round but that's unprofessional; you don't call every Mercedes
 "Mercedes Car", do you? You know that Mercedes produces cars as you
 know that a pencil is a tool and in a toolbox every item is a tool.

 There's no need to tell the user what she/he's seeing if it's
 obviously.

  3. The optiondialog of the tools is obviously a option dialog and

 Same here... Just because all these dialogs are option dialogs there
 is not reason not to display this fact.

 Uhm, I guess like the idea of having window titles that tell you what
 you should see, so why no "Save File Dialog" or "Preferences Dialog".
 That no good UI design, in fact if you look at the comercial competitors
 of GIMP you'll see that they don't do this either and surely this gives
 a more professional impression...

  A patch for fixing that is included
 
 I detest :)

 Like you can see, I'm not the only one who was disturbed by this... :))

-- 

Servus,
   Daniel



Re: installing .po files in addition to .gmo files?

2000-02-02 Thread Daniel . Egger

On  2 Feb, Marc Lehmann wrote:

  Well, yes, but I guess they wouldn't want to translated them
  themselves, so why personal i.e. with catalog in the home directory?
  
 Because it's the only user-writable place on a machine. I only talk
 about installing plug-ins _seperately_ from the gimp.

 Okay, that seems reasonable... 

  GIMP itself uses two and a plugin uses also two.
 So this means there is no problem, no?

 You can create domains with nearly no limit. Where the files 
 reside is completely up to, it may even be the homedirectory... 

 (gmo == mo, I assume, since I have no idea what I am talking about all
 the time ;)

 Yes...

 If that's possible (which commands do I need), then there would be no
 need to deliver the .po files. However, the .mo file format is not
 standardized, so I doubt that it is possible to idsassemble them
 portably.

 I have never heard of any problems, so we may treat it as
 "incompatibilites not known".

 The command you're asking for is msgunfmt...

 I think it's not too unreasonable to requre gettext for installing
 plug-ins.  It's a bit awkward when you only want to install binary
 plug-ins, but since gettext itself is rather inadequate I don'T aim
 for the perfect solution, just something that works.

 I'm no fan of further dependencies you know...

 That would require yet another dependency to a compression
 library/program that might not be available. OTOH, we might just as
 well require gzip, since the plug-in packages are most probably packed
 with it anyway.

 Without gzip you are simply lost in UNIX space...

 Daniel, do you know how to modify the Makefiles to do that,

 Yes

 and where
 a good place to store these files is (probably just besides the .mo
 files)?

 That would be reasonable... You just have to choose sensible filenames
 because the files gettext is searching for is depending on the
 domainname you request a translation for.
 
 There must be a simple way to find them though (a gimptool
 switch, maybe)?

 Would be possible.

-- 

Servus,
   Daniel



Re: Documenting the source?

2000-02-02 Thread Daniel . Egger

On  2 Feb, Sven Neumann wrote:

 /**
  * gimp_size_entry_new:
  * @number_of_fields: the number of entries
  * @unit: the default unit
  * @unit_format: a pointer to a format string describing the unit

 The good thing is that gtk-doc checks that the documentation and the 
 source are in sync and it creates DocBook SGML that can be used to 
 create nicely linked HTML. In the example above all gimp-specific
 types and enums (GUnit, GimpSizeEntryUP, GimpSizeEntry) would be
 linked to their declaration. But I guess you have worked with the glib
 and gtk+ reference manuals before and know how the output looks like.

 Hm, yes, but the gtk+ manual is not quite what I had in mind.
 I thought of really in-source-documentation and looking at your example
 code I think you had the same in mind. 
 But I would like to use a standard not a new solution, therefor your
 examplecode doesn't match my thoughts. Defining the
 documentation of the parameters directly by giving every one unified
 metatag is very restricting. Javadoc like sourcecode has a better
 approach:

 @memo  short documentation
 @doc   long documentation 
 @returndoc of return value of a function  
 @param doc of parameter of a function 
 @exception doc for exepction thrown by a function
 @see   cross reference   
 @authorauthor
 @version   version   

 There are at least a few dozen programms which can extract this and
 export them to at least that number of formats. Have a look at doc++,
 a very cute program to generate documentation...
 
-- 

Servus,
   Daniel



Re: Documenting the source?

2000-02-02 Thread Daniel . Egger

On  2 Feb, Sven Neumann wrote:

 Well, does it support the GTK+ object system like gtk-doc does? I
 guess not and that's why I suggest that we stop discussing what tool
 to use since I doubt we will find something better suited to our
 needs.

 It supports crossreferences, what else do you want?

-- 

Servus,
   Daniel



Re: installing .po files in addition to .gmo files?

2000-02-02 Thread Daniel . Egger

On  2 Feb, Marc Lehmann wrote:

 So that means that we need a new domain, such as "gimp-override",
 that resides in .gimp/locale and is consulted just like gimp-perl and
 gimp-plug-ins.

 No

  The command you're asking for is msgunfmt...
 
 Hmm... sounds like the solution. You pribably made my day (or so ;)
 Thanks!

 Hm, I just got an idea
 I think it's the same as yours, but beware: Before merging catalogs you
 have to remove the headers and duplicate entries or msgfmt will refuse
 the compile them

 That way we can msgunfmt the existing mo file, add messages, and write
 it back again on installation.

 Theoretically, yes...

  I'm no fan of further dependencies you know...
 
 Neither me... any better solution, though? No...

 No, despite of replacing gettext :)

 No longer necessary, as it's possible to regenerate .po from .mo (and
 if that does not work we just loose).

 We could also use to remove the barriers in GIMP i18n for know. This
 would only have one big limitation we also suffer from at the moment:
 No different translations for same wording but different meaning.

 Everyone: Since I stumbled over a severe problem which probably means
 that I can't realise my solution with gettext at the moment, would it
 make sense to you to:
 a) Move the used catalog from its standard location to the homedirectory
of the user?
 b) Merge all translations into this catalog with help from a
script/tool?
 c) Remove the hackery from the sourcecode since it would be unnecessary
then?
 d) Release GIMP 1.2?
 e) Head for a proper solution afterwards? :)  

-- 

Servus,
   Daniel



Re: Some UI inconsistencies and a patch....

2000-02-02 Thread Daniel . Egger

On  2 Feb, Marc Lehmann wrote:

  Not really, you have the word "Preferences" just a few mm above it.

 No, I haven't.

 Sounds like you should send a bugreport to the authors of your
 favourite windowmanager

 I have no problems with these!! Consistency is great, I am just
 against removing non-redundant information.

 I do have a problem with them because they look just silly.

  "Mercedes Car", do you? You know that Mercedes produces cars as you
  know that a pencil is a tool and in a toolbox every item is a tool.
 
 The problem is that I know that every thing in the toolbox is a tool,
 but I do not know that a givne dialog belongs to such a tool unless it
 is marked as such.

 It is marked and will stay that way. You'll always have the name of the
 tool in the dialog...

 The reason nobody calls it a Mercedes car is because you can see
 it.

 And I guess you can't see that a tool from the toolbox IS a tool?
 In this case we should care about the sense of the tools instead 
 of specifying them to be tools

 Windows look the same, so you need other things to differentiate
 between them.

 Who cares about Windows? :
 Serious, no tool looks the same like any other in GIMP and I didn't
 get you point with the Windows.
 
  There's no need to tell the user what she/he's seeing if it's
  obviously.
 
 I don't see it :(

 Hm, you don't wear glasses, do you?

 I would rather like _more_ information displayed in the title than is
 already. For example, if I open a Save As dialog window and answre a
 phone call, it is not obvious which image you wnated to save (as this
 isn't displayed anywhere).

 YES, you finally got it! So let's make it visible what image you are
 about to save instead of underlining the point that this window is a
 dialog (which everyone can see) That is sensible UI desgin.

 Hmm... I wasn't the one who complained that some person with cvs
 access applied a braindamged patch not so long ago ;-

 Hey, he didn't apply the whole patch... ;

-- 

Servus,
   Daniel



Re: [gimp-devel] Re: Some UI inconsistencies and a patch....

2000-02-02 Thread Daniel . Egger

On  2 Feb, Simon Budig wrote:

 Hmm - I dont like the first too, since it is unclear what preferences
 are adjusted inside "New File". "New File Settings" is not much
 better...
 
 What about "New File Defaults" ?

 Sounds good.

 So, what about the "Colors-Curves" Thing ? It is a tool isnt it?
 It is not always clear, if something is a tool or not - especially
 when it does not have a button in the Toolbox.

 Then rename it to Curves Tool. You only have two choices in GIMP:
 Either it's a tool or it's an action, this is normally obvious
 because actions (like Save File) contain a verb, while Tools are
 objects. Anyway: it doesn't really matter as long as the user knows
 what she/he'll get from choosing a menuitem.

 IMHO Redundacy is not that bad. I vote for "Tool" in every
 Option-Dialog.

 Redundancy is not bad if it's improving usability. In this case it
 won't, so why adding it?

 Example? Well, take the pencil: Open the options dialog und choose the
 symbol for the pencil. Now you have an optiondialog for the pencil open;
 you know it's an optiondialog because it contains nothing else but
 widgets to change something, so the words "option" and "dialog" are
 superfluous here. Since you know that a pencil is a thing to write with
 and that you can't for example eat it, it is a tool, so why bother
 mentioning it? Let's concentrate on improving the tool tips to let the
 user know HOW to use it, instead of telling him that he may use it.  

 Now I'll turn off my Palm III Palmtop, leave my keyboard inputdevice
 alone and drive my Ford car a little bit...

-- 

Servus,
   Daniel



Re: Plugins at Sourceforge

2000-02-01 Thread Daniel . Egger

On  1 Feb, Kelly Lynn Martin wrote:

additional plug-ins. Some things, like translations, must be part
of the distribution currently.
  
This needs to be fixed. :)
 
 Do you volunteer?
 
 I don't understand translations at all. :)

 What a pity... I'm currently trying to dissolve all these problems but
 while I coding some source I stumbled over a problem with gettext which
 took me nearly a whole to identify.
 I would really like someone to give me a helping hand on this to reduce 
 the time and of course I would need someone to wake up Ulrich
 Drepper because I really need his answer :)) 

-- 

Servus,
   Daniel



Re: Print plug-in

2000-02-01 Thread Daniel . Egger

On  1 Feb, Federico Di Gregorio wrote:

  Great... so maybe you can tell us what we'd gain from using gnome in
  GIMP. Now tell us: what would we get for linking against another
  bunch of libraries?
 
 1/ economy of coding

 Uhm, more concrete?

 2/ better integration

 Into the GNOME desktop? At best this should be optional...

 3/ total bloat reduction (if the user already uses other programs 
linked with the same libraru)

 I'm sorry to tell you, but although I'm trying to compile gnome from
 time to time I don't use any application that DEPENDS on GNOME and
 I'm really happy about that

 4/ it was a discussion about using *selected* libraries, like
 gnome-print,not the *entire* gnome framework.

 gnome-print depends on gnome-libs, doesn't it? At least I can't
 compile it right now without it. That would mean that we have to
 additionally link at least against gnome-print, gnome-libs,
 libart_lgpl, gnome-xml, gconf, ORBIT...
 Hm, seems well worth the effort...  :)) Maybe there could be a plugin
 that integrates well into GNOME but you wouldn't want to make the whole
 GIMP depend on it, would you? 

 I prefer a print plugin that works without gnome...

-- 

Servus,
   Daniel



Re: Print plug-in

2000-02-01 Thread Daniel . Egger

On  1 Feb, Sven Neumann wrote:

 You don't seem to be very familiar with gnome-libs, especially not
 with the progress that was/is being made towards the next release.
 
 Uhm, not quite except that I'm trying to compile it every three days...

  gnome-print   for printing (preview, native printer drivers, a nice
  print dialog)

 Optionally, OK

  gnome-fontfor font-rendering (don't know if gnome-2.0 will have
  this)

 I doubt that this would be of any real use, we want to have first class
 rendering into GIMP with no eye on speed and such opposing to the
 font-rendering of applications where rerendering happens quite often...

 gnome-canvas  for the UI (he draw routines we use on the gimp
 canvas are very difficult to handle, using objects that can be connected
 to and emit signals would make our live much easier)

 I didn't really get your point here

  libartprovides convenient and optimized functions for all
 sorts of affine transformations

 Okay, I wouldn't even mind to make libart mandantory...

 gdk-pixbuf   
 image-loading and simple (but fast) transformations (we may want
 to use this to implement a proper brush and patterns system
 since it integrates nicely with libart which would give us
 scalable, rotatable brushes/patterns for free)

 Optionally this would be okay, although I prefer Rastermans Imlib2...
 It may be that gdk-pixbuf focuses too much on the needs of a desktop
 or were there any other reasons to go away from Imlib?

  gconf for configuration (have a look into the code for the 
preferences-dialog, it sucks badly ...)

 I think the preferences dialog is very nice, anyway I'd prefer using
 XML as a save format for configureations and even for scripts. This would make
 macro recording possible...
 But having a centric configuration possibility for GIMP doesn't make
 any sense to me anyone out there who would like to configure it via
 GNOMEs control-center or via console? :)) 

  gtkhtml   seems to be a very nice replacement for gtkxmhtml
  ...

 Okay, for the help system... optional

 Now, tell me why we should recode all this on our own. It would not
 only be ridiculous to do so, I can also assure you that it is beyond
 our limits due to limited resources of good developers willing to
 spend their time to do it.

 I don't think we should avoid using new technologies for every price
 but we should avoid linking against megabytes of libraries just for having
 a possibility to print or render a nice UI

 On the other hand, a lot depends on the GNOME people. I hope that
 their goal is to provide a bloat-free set of portable libraries that
 don't depend on too much other stuff we don't want to use.

 We'll see

-- 

Servus,
   Daniel



Re: Plug-In manag(er|ing)

2000-02-01 Thread Daniel . Egger

On 31 Jan, Marc Lehmann wrote:

 BTW: we need to
 consult a ~/.gimp/po/ directory for translations as well at some point
 in the future!

 Bad luck, I don't know why you like to have a personal catalog
 directory but with gettext you have either ... or ... and setting up
 such a system which uses a personal catalog AND a global one would be
 a bit difficult...

-- 

Servus,
   Daniel



Some UI inconsistencies and a patch....

2000-02-01 Thread Daniel . Egger

Hiho developers...

 I discovered some name glitches in GIMP.

 1. The "Settings" in the preferences Dialog wasn't in everything and is
useless nevertheless because a preferences dialog is supposed to
contain settings...
 2. Some tools had a "Tool" in the options dialog and some not. Since all tools
are tools and people know what tools are, we don't need to call some
tools additionally tools :)) 
 3. The optiondialog of the tools is obviously a option dialog and
nothing else so removing the "Option" is sensible and matches the
behaviour of the professional programms

 A patch for fixing that is included

-- 

Servus,
   Daniel

 diff21.gz


Re: Print plug-in

2000-02-01 Thread Daniel . Egger

On  1 Feb, Marc Lehmann wrote:

 Macro recording and XML are two *completely* orthogonal things. Macro
 recording gets possible by programming it, not by using a difefrent
 format to save config files.

 You could use XML for saving macros. Of course you could also use
 scheme BUT: There are libraries e.g. libxml which allow very simple 
 loading and saving of XML files while we would possibly have to write
 one for any other language first. It's a big advantage if you already 
 have a parser/creator handy

-- 

Servus,
   Daniel



Documenting the source?

2000-02-01 Thread Daniel . Egger

Hi developers,

 Having no real documentation of the sourcecode is really a burden
 when searching for bugs. Do you agree that having a documentation
 would be fine? I'd like to introduce a in-source-documentation 
 which an extractor program could use to make a TeX or HTML file of
 it.

 Using javadoc like comments we'd always have a specification of a 
 function handy without having to guess the sense.

-- 

Servus,
   Daniel



Re: Usage of Gnome libs (was: Re: Print plugin)

2000-02-01 Thread Daniel . Egger

On  1 Feb, Sven Neumann wrote:

 This is supposed to be first class font-rendering and if it prooves to
 be useful, I see no reason not to use it, even it has gnome printed
 on it.

 Well, if it really is first class rendering, then I'd like to see it
 in GIMP I haven't yet seen this package, is it in the CVS?

  gnome-canvas  for the UI (he draw routines we use on the gimp
  canvas are very difficult to handle, using objects that can be
  connected to and emit signals would make our live much easier)
 
  I didn't really get your point here
 
 Look into the code that handles the bezier_curves UI. A good part of 
 that code is doing nothing but checking if the mouse is on a
 control-point. Now imagine the control-points were objects that emit 
 signals like enter, leave, clicked etc. Do you start getting my point?

 Now I do but AFAIK gnome-canvas is a fixed part of gnome-libs, or
 am I anybody working on seperating it? 

  Okay, I wouldn't even mind to make libart mandantory...
 
 Why? libart was developed explictely to work w/o gnome-libs. It's an
 extremly useful library that fits perfectly to our needs.

 Uhm, maybe I just can't get no real English sentence out of my
 keyboard, in other words: Okay, go for it, link it to the GIMP :))

  Optionally this would be okay, although I prefer Rastermans
  Imlib2... It may be that gdk-pixbuf focuses too much on the needs of
  a desktop or were there any other reasons to go away from Imlib?
 
 All I know about Imlib2 is that is has a lot of features we will never
 need.

 For example? Everything that is in Imlib2 so far would be also usable
 for the kind of actions you mentioned

 I don't see why gdk-pixbuf looks desktop-centric to you,

 That's my conclusion from the GNOME team wlaking away from Imlib and
 Imlib2... why else should they do that?

 but it certainly has a small memory-footprint, is fast and it
 integrates nicely with GTK+.

 GTK+? You meant gdk I guess and so does Imlib as well

  I think the preferences dialog is very nice, anyway I'd prefer using
  XML as a save format for configureations and even for scripts.
  This would make macro recording possible... But having a centric
  configuration possibility for GIMP doesn't make any sense to me
  anyone out there who would like to configure it via GNOMEs
  control-center or via console? :))

 Did I say control-center?

 gconf is the new replacement for the control-center

 Daniel, this is FUD! You talk about using XML.

 Sven, gconf uses gnome-xml for storing preferences data, and that's
 something I really like about it

 Do you want to write your own parser?

 Why? It's already there... and I really like the idea of getting away
 from our current system...

 I'm not advertising  gnome-conf since I don't know much about it, I
 just mentioned it as an example of stuff that might be of interest.

 Well, gconf is designed as a general purpose configuration system which
 can use several backends for storing it's data and several frontends for
 modifying preferences.

 Let's argue about using GNOME. It does not make sense to turn your
 head only if something has GNOME written on it.

 I don't have anything against GNOME... I like it in fact because the
 whole desktop environment has a small memory footprint and is fast
 compared with KDE. But I really doubt it is good for ANY big project
 which is not really related to GNOME to depend on it

 And remember: this has
 nothing to do with the desktop, the control-center or whatever. All we
 are talking about is if we want to use selected parts of the
 libraries that evolved around gnome. The good thing about these libs
 is that they are maintained and integrate nicely with GTK+ and its
 object system.

 Great, then we're on the same side

 As said before, a lot depends on the will of the GNOME people to
 release those libs in small packages without throwing too much
 gnome-specific stuff into them. I think we would already use the
 canvas now if it would have been released seperately.

  (gnome-xml)- not sure if we will need this one

 I think this could be very useful

 With the execption of the canvas all this is AFAIK already available
 outside of gnome-libs. 

 Sven, I don't really know why you are arguing against me; It really
 seems like we do have the same things in mind so let's spend our time
 on realising them

-- 

Servus,
   Daniel



Re: Documenting the source?

2000-02-01 Thread Daniel . Egger

On  2 Feb, Sven Neumann wrote:

 We have already brought up this issue lately and I think the
 conclusion was that we try to add documentation for libgimp before
 1.2. Most certainly we will use gtk-doc with comments embedded into
 the source. Marc volunteered to write the necessary scripts to
 convert the info out of the PDB.

 What characters does gtk-doc use to introduce a comment?
 I like the idea of having javadoc like comments i.e. /** */
 with some special tags because there are several programms out
 their which make beatyful documentation out of this and it's quite
 a standard solution...

 I volunteer to do some of this documentation... I have to get the
 sense anyway... :))

-- 

Servus,
   Daniel



Re: Print plug-in

2000-02-01 Thread Daniel . Egger

On  1 Feb, Steinar H. Gunderson wrote:

 Well, we _do_ have gimp-perl available...

 Uhm, yes... 

 With XML, we'd have to write _both_ loader and saver

 There are fantastic parsers available, no need to write any of those.

 -- with gimp-perl (or Perl-Fu, whatever name 
 you like best), we'll `just' have to add some saving hooks into the
 PDB

 That's the hitting point, if you want to use perl or script-fu here you
 have to produce code for (possibly :)) highlevel languages which isn't 
 quite simple. In my illusion at least making tags from events and the
 way back should be simpler...

 I don't really see why you'd want to have XML for this -- it just
 doesn't seem logical to me.

 XML is very abstract, you can do nearly everything with it (except
 saving images :))... the macrorecording feature was just a quick idea
 by me; originally my intend for XML in GIMP was using it as a save
 format for user options to get that ugly rc parser out of GIMP

-- 

Servus,
   Daniel



Re: Colormanagement

2000-02-01 Thread Daniel . Egger

On  1 Feb, Martí María wrote:

 So, any volunteers?

 This piece of code is highly interesting but since this won't make
 into GIMP before 1.2 because of the featurefreeze I really hope that 
 all GIMP developers will concentrate on the project until we released
 the next stable version. 

-- 

Servus,
   Daniel



Re: Print plug-in

2000-02-01 Thread Daniel . Egger

On  1 Feb, Shawn T . Amundson wrote:

 But hasn't Mozilla basically given up on this idea and just
 used their own toolkit?  Mozilla certainly looks crappy on the
 Mac at any rate.

 Not yet... at the moment it's possible to use even gtk or qt for the
 UI but they are slowly migrating to their own rubbish. It's possible
 simpler for them than to have an additional layer between the UI and
 the widget toolkit.

 Anyway, GIMP doesn't suffer from such ideas because we already HAVE
 our own toolkit for GIMP... and it even seems to work with windows...
 :) 

-- 

Servus,
   Daniel



Re: Translation inconsistency

2000-01-31 Thread Daniel . Egger

On 31 Jan, Sven Neumann wrote:

 (A) do nothing, ignore the problem
 (B) don't mark the strings for translation, not in the core, neither
 in the plug-ins (C) mark the core PDB strings for possible
 translation too

 Kick them

-- 

Servus,
   Daniel



Re: Plugins at Sourceforge

2000-01-31 Thread Daniel . Egger

On 28 Jan, Michael J. Hammel wrote:

 Do you mean language locales?  I'm not very familiar with working with
 multi-language issues, but I have wondered why this isn't handled by
 the plug-ins directly.

 Because it won't work entirely this way... localisation works for
 everything but the menues which are set up by GIMP at startup time not
 by the plugins...

 GTK supports internationalization, right?

 Errr, let's say: a little bit

 So
 shouldn't the plug-ins be responsible for the language issues? 

 Yes, they SHOULD, but it's not possible, at the moment...

-- 

Servus,
   Daniel



Re: Print plug-in 3.0.5 patch

2000-01-27 Thread Daniel . Egger

On 27 Jan, Robert L Krawitz wrote:

 diff -rc print/README /tmp/print/README

 Please use diff -u for further patches to preserve readability and
 attach them to prevent line wrapping to slash the patch

-- 

Servus,
   Daniel



Re: Remove the Stack Trace...

2000-01-26 Thread Daniel . Egger

On 25 Jan, Marc Lehmann wrote:

 I really do not understand this. The stacktrace simply does not work.
 Attaching a debugger is much better, but still: the core file a segv
 would create would be _far_ more reliable.
 
 I buy the argument that users can do bug reports better with an
 automatic stacktrace, but I don't buy that it makes it easier for
 developers.

 You are absolutely right there so I would suggest disabling it for
 normal use and enable it for distributions

 I know you like those small patchlets... so here is your personal
 one... :))

-- 

Servus,
   Daniel

 diff18.gz


Re: Remove the Stack Trace...

2000-01-24 Thread Daniel . Egger

On 24 Jan, Raphael Quinet wrote:

 Any suggestions for the name of the new option?  It could be something
  like "--disable-stack-trace" or "--disable-crash-query", assuming
 that the default behaviour would be to have it enabled in unstable
 releases. Note that I also support the idea posted some time ago on
 this list that suggested to enable most debugging options in the
 unstable releases, but to disable them by default in the stable
 releases (so that you would have to use the opposite option
 --enable-crash-query if you wanted that feature).  And maybe the
 people building RPMs or other pre-compiled packages should disable
 these options as part of the build rules also for unstable releases if
 they think that it is better.

 I will check the behaviour and if it really blocks when not called from
 a terminal I will remove this "feature" for our next distribution
 otherwise it will stay because it gives a good start for bugreports
 even if compiled without debugging information

-- 

Servus,
   Daniel



Re: menu translation again - how does it work?

2000-01-17 Thread Daniel . Egger

On 14 Jan, Marc Lehmann wrote:

 So, if at all possible, could some translation expert find a fix for
 this problem, and I'll just add Logulator to app/menus.c in the
 meantime. Or did I misunderstand the general plan for translation? I
 thought that would already have been fixed?

 At the moment we don't have any fix just an ugly workaround with a
 bunch of drawbacks. I'll check out whether my idea works and we'll see
 whether we can fix it for 1.2 or not

-- 

Servus,
   Daniel



Nasty problem in new file requester...

2000-01-17 Thread Daniel . Egger

Hiho!

 I recently discovered that using one of the spinbuttons in the filenew
 dialog causes redrawing of the whole upper table and thus flickering.
 This is quite annoying because it prevents users from using the spinbuttons
 to choose their imagesize because it is impossible (on my AMD K6-2 400) to
 accurately select a value; if I click long enough for the autorepeat
 function to work on one of the buttons the value rises up to really big
 number or down to 1. 

 This behaviour is not shown for example in the scale dialog, so I guess
 the redraw signal is thrown by our magic size displaying frame, which
 leads me to the question: Wouldn't it be better to display the image
 size somewhere else IN the frame to curb this problem?

-- 

Servus,
   Daniel



Re: Call for plugin maintainance

2000-01-06 Thread Daniel . Egger

On  4 Jan, Sven Neumann wrote:

 on our way from 1.0 to 1.2 we included a few plug-ins that were 
 considered not to be stable enough to be included with a stable 
 release. This was done in the hope that the inclusion into the 
 1.1 developement tree would encourage people to work on those
 plug-ins so that they would become stable enough to be released
 with 1.2. 

 Hm, there are two thing that are really annoying me:

 -megawidget
 -libgck

 libgtk, libgdk and libgimp should provide all methods which are
 necessary to build plug-ins. If they do (and I think they do) then
 there's no reason for existance of these kludges and they should be
 removed. If they don't we should integrate the necessary functionality
 into libgimp and thus provide a straightforward and common way to build
 plug-ins...

 Yosh: Will these changes have any chance to get into the tree soon
 if I'm providing the necessary patches? 

-- 

Servus,
   Daniel



Re: libgimp(ui), iibintl and (l)gpl problems

1999-12-03 Thread Daniel . Egger

On  2 Dec, Marc Lehmann wrote:

 However, if we solve this problem by *linking* libintl against
 libgimpui we get another problem: linking against libintl
 automatically puts libgimpui under the GPL.

 If you are using glibc2 then you've got not problem with lgpl, because
 its LGPL itself then...

-- 

Servus,
   Daniel

 PGP signature


Re: Tons of useless translations???

1999-11-27 Thread Daniel . Egger

On 23 Nov, Michael Natterer wrote:

 It seems we're doing _many_ useless translations in the menu system.
 For example all calls to menus_set_sensitive() et.al. are using
 strings which are marked with N_().

 Note: A N_ mark is just a mark and as such an pseudo op. 
 It can't cause bigger executables or alike... But of course you are
 right that marking such items is senseless since they are already marked
 somewhere

 However it's totally sufficient to pass the untranslated (english)
 text to _all_ item factory functions because GtkItemFactory uses
 the translate function _only_ when creating the menu labels.

 We DO pass untranslated strings! N_ is a macro which gets replaced by
 nothing
 
 I'm quite sure that I got the semantics of the item factory code
 right. Could anyone verify this please? It could save us lots of
 work and reduce the size of the po files drastically...

 It'll just save a little bit of preprocessing time and a few bytes is
 the .po file which won't influence the .mo file...

-- 

Servus,
   Daniel



Re: Tons of useless translations???

1999-11-27 Thread Daniel . Egger

On 23 Nov, Michael Natterer wrote:

 I did some debugging there and noticed that gettext() returns
 "/Datei/tearoff1" for _any_ string which has the form "*/tearoff1"
 ().
 
 This is either a bug in our po-files, a bug in gettext or a feature of
 gettext which allows to do some magic by adding kinof identifiers
 after a slash?

 I bet it's a bug in menus.c...

 Seems we need a guru here...

 At your service... :)

-- 

Servus,
   Daniel



Re: Tons of useless translations???

1999-11-27 Thread Daniel . Egger

On 27 Nov, Marc Lehmann wrote:

 PS: does gimp now translate by component or still using the whole
 path?

 Componentwise...
 BTW: Is there any special reson I can't unsubscribe from this list and
 subscribe again with another address? Quite annoying

-- 

Servus,
   Daniel



Re: Tons of useless translations???

1999-11-27 Thread Daniel . Egger

On 23 Nov, Marc Lehmann wrote:

 (btw, can anybody tell me why redhat ignores LANG? and what is this
 LINGUAS thing anyway? maybe because other variables like LC_ALL are
 also set and take precedence?)

 LANG will be just used if no other LC_* is set to something... and
 LINGUAS are all possible languages available, although I don't 
 really know who invented this...
 
-- 

Servus,
   Daniel



Re: Tons of useless translations???

1999-11-27 Thread Daniel . Egger

On 25 Nov, Michael Natterer wrote:

 However, I still didn't find out why my installation is unable to
 lookup translations from "gimp-std-plugins".

 In GIMP core? I don't know why it should... you are in the wrong
 doamin

-- 

Servus,
   Daniel



Re: Toolbox bug

1999-11-27 Thread Daniel . Egger

On 23 Nov, Steinar H. Gunderson wrote:

 There seems to be a bug in the toolbox. If you simply make the window
 taller (on my system, the threshold seems to be about 380 pixels
 high), the gradient selector (and half the color selector) seems to go
 under the visible area, and out of sight. Should I look into this
 myself, or is there anybody here who could fix this quickly?

 This bug appeared with the the widget that GIMP uses for its toolbox.
 IMO this one is too broken to stay for release, the old one approach 
 instead is not that flexible but it actually works...

 I hereby offer to revert the code to the old behaviour 

-- 

Servus,
   Daniel



Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?

1999-11-14 Thread Daniel . Egger

On 11 Nov, Tor Lillqvist wrote:

 I don't think gimpenv.c is in any way unique in this sense, probably
 many of the other files in libgimp also contain code snippets that
 have originally been in some file in the GIMP proper.

 Hm, the file I created was done on my own or cutted from gimp-libs
 which is LPGLed... So I think I may add a necessary an LPGL header to
 it
 BTW: Can somebody please replace the COPYING file by an updated version
 to avoid further confusion?

-- 

Servus,
   Daniel



Re: Help System

1999-11-14 Thread Daniel . Egger

On 11 Nov, Marc Lehmann wrote:

 The difference (IMHO) is that a help system is an integral part of the
 gimp, just like menus, a good ui design or the tooltips are.

 IMHO the best solution would be to leave everything out of GIMP that 
 isn't really necessary for running, including help, catalogs and a
 lot of plug-ins. For these we should have extra packages like
 gimp-german.tar.gz, gimp-english.tar.gz gimp-japanese.tar.gz and
 gimp-fancy-plugins.tar.gz, gimp-often_used-plugins.tar.gz and so on
 which gives the user the possibility to get all the features he/she
 wants without the need to download a single 50 MB package and then
 having online help on its system (possibly in some curious language)
 he/she never wanted... 

-- 

Servus,
   Daniel



Re: Solution for the i18n problem?

1999-11-14 Thread Daniel . Egger

On 11 Nov, [EMAIL PROTECTED] wrote:

 I have the same problem, very most menu's contains the german word
 "Datei".

 Which version of GIMP do you use?

 Locale settings:
 LANG=de
 LC_ALL=de_DE

 I now did a complete fresh installation of all packages coming in mind
 and still can't reproduce that one? 

 Is there anyone having a machine on the net using such a bugged version
 of GIMP which I could use to remotely debug this one?

-- 

Servus,
   Daniel



Re: Help System

1999-11-11 Thread Daniel . Egger

On 10 Nov, Kevin Cozens wrote:

 Reading the discussions re: the help system has made me think I
 understand why compiling GIMP always broke at a point where it needed
 a GtkXmhtml header file. I use a RedHat system without Gnome installed
 and I'm beginning to understand that GtkXmhtml is a Gnome thing. I
 recently upgraded to the latest glib and gtk+ as I thought what I was
 missing was something that was added to a version of gtk+ more recent
 than I had. The name of GtkXmhtml now seems to be misleading as it
 appears not to be part of the base gtk+ libraries.

 By the way: you all are aware that GtkXmhtml is something that is due
 to be remvod from gnome-libs, right?

 I would like to offer stripping it down to our needs. Then we could
 bundle it together with an helpmodule for GIMP and the documentation.

 So we don't pollute our mainstream GIMP archive; help is only available
 to people who installed the right package 

 Comments?

-- 

Servus,
   Daniel



Re: Plugins

1999-11-11 Thread Daniel . Egger

On  8 Nov, Marc Lehmann wrote:

  Hint: It's the way menues are handled by Gtk...
 
 And if this leads to segfaults it is surely a bug in gkt+? No, really,
 I am _simply_ interested in how a call to gettext can result in a
 "legal" segfault.

 The most likely way to cause a segfault is to write to an address 
 not owned by the process... In C this is very easily because we sometimes 
 even calculate with pointers...

 Well, if you care that I won´t repeat the same error again it would be
 nice if you explained the bug...

 Got me here, but since I don't exactly know what the bug is I can
 hardly explain it. I just know the symptoms and you do, too...

  I don't think so. Half-translations can be really confusing and
  annoying for a user.

 Ok, then let's vote on this. "I vote that this is less confusing..."

 Do so, but at a public place, please...

  Push me, please... 

 PUSH!

 Not hard enough, but this may change VERY soon

 "ls" is ls(1) and "vz" is the shortcut for "verzeichnis".

 Ouch

  mixed language environments are the rule today, not the exception.

  That doesn't make them any better
 
 I think it's the only way to go. Look at how M$ handles translation
 (by looking at i18n'ed visual basic for example ;)

 ROTFL. Did you have a look how M$ does internationalisation?
 Have you ever seen a catalog for any Microsoft program? 
 No? Maybe it's their special art of doing Cut'n'Paste... :))

 Well, I have an opinion about half-trabslation that is just as good as
 any opinion from an average user. The gimp is not the only i18n'ed
 project, and I didn't speak english all the time in the past...

 Well, for distributors internationalisation is a very big concern
 because they address firms (which don't care about it very much) on
 the one hand but on the other hand also users who want a stable
 OS with many free programs and they DO care about. 

-- 

Servus,
   Daniel



Re: Plugins

1999-11-11 Thread Daniel . Egger

On 10 Nov, Marc Lehmann wrote:

 That all plug-ins that are part of the distribution should have
 corretc translated menu entries is (for me) obvious. The problem is
 new (third-party) plug-ins.

 These problems are solvable by a consistent way to handle the
 translations. Im working on these but I guess I'll have to sleep until
 the release of Gimp 1.2 ... In this area we have too much changes to allow
 me to start coding now for Gimp 1.3...

 A way around would be to increase the version number to something
 like 1.1.95 to show that we are on the right way and get a big bug
 fixing push :))

-- 

Servus,
   Daniel



Re: Help System

1999-11-11 Thread Daniel . Egger

On 10 Nov, Raphael Quinet wrote:

 So please stop complaining about the help system, because that could
 backfire on Gimp-Perl quickly...

 No flamewars, please. Let us concentrate on our work instead of pushing
 our energies in a thread which as useless as Win 3.11 ... :))

-- 

Servus,
   Daniel



  1   2   >