On Sat, Oct 06, 2001 at 11:23:11AM +0200, Sven Neumann wrote:

> > It's a lot more versatile then the header approach with my lovely
> > friend gettext since the information is not spread over several
> > files which need to be generated, compiled and installed. If we had
> > more tips we could even categorize them.

> I don't think we want all translations in one file. 

That wasn't my point. I meant that it might be sensible for tips
(instead of introducing the header kludge) and for plugin descriptions 
because it makes them more versatile and not bound to the distribution.

> The file will get large and akward to edit. 

In the mentioned case this is not an issue. The tips are pretty small
anyways (just compare it to a uncompiled catalogfile) and for plugins
this isn't an issue at all. 

> > Actually using XML would also solve a part of the "how do we localise
> > plugins that are not part of the distribution" problem and might lead
> > to a leaner core distribution and an intelligent repository which is
> > a really cool thing. Back when we implemented the first round of the
> > now active stuff this techniques were not available for consideration
> > and thus we ended with the kludgy solution. 

> hmm, how would XML help here and what are the kludgy solutions you speak
> about?

Remember how we solved the localised-menuentries-for-plugins problem?
I'd call it kludgy and it causes trouble for external ones.

So how could it look like? Think glade, it uses XML files to describe
userinterfaces; if we go this way we'll have two choices: 
- Create the complete userinterface from XML (including translations).
  I'd love to see that because it would ease pluginwriting quite a bit
  if we also had good interfaces to access the layerdata directly by 
  rectangular coordinates also.
- Use the file just for the labels and their translation as well
  as for the menuentries; by using a fast library this might also
  obsolete pluginrc - simply drop the description in a special 
  directory and you're all set also for scripts.

> Actually I do have some ideas in this area and I think Ingo wanted 
> to outline a plug-in description draft that uses XML. 

Cool. I'd like to see it when ready.

> But the use of XML alone will not solve any our problems.

Of course not.

> After all it's only a markup 
> language and there's nothing really new to it that you couldn't have done
> years ago.

I tend to disagree; although being available for quite some years now the
tools to use it are still being heavily develloped and were nearly non-
existant back when we last implemented the latest featureset wrt. plugins.

Yes, it's only a markup language but the big advantage is that it's a 
standard and well developped and we should make use of that.

Gimp-developer mailing list

Reply via email to