Re: [Gimp-developer] Usage of mnemonics in GIMP 1.3
lör 2002-05-04 klockan 18.10 skrev Sven Neumann: > > * what will be the impact on the translations when we start using these? > > translations will break and need to be updated. However I don't see > any particular problem here. Of course translators need to put some > thoughts into the mnemonics they use in the translations and should > try not to deviate too much from the original (english) mnemonics. I usually consider the mnemonics to be chosen so that they are easy to remember and access to be of much higher importance than any attempt to make them not deviate too much from their English equivalents. Often, the English characters are not even part of the translated word, so it's usually not particularily useful to use a strategy of not deviating too much, especially as this strategy may cause the mnemonic to clash with much better mnemonics where it's not even possible to use the English equivalent even if you would want to do so. For these reasons, I myself have long since given up any strategy to not deviate too much, and instead try to choose the mnemonics wisely. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code
On Sat, May 04, 2002 at 10:20:25PM +0200, Daniel Egger wrote: > Am Sam, 2002-05-04 um 20.42 schrieb Ayose: > > It should be DockBook/XML :) > > Well, is IS XML, just the DTD is an SGML one. All strict XML like > correct closing and shortened tags as well as case sensitivity are > obeyed, I just haven't checked if anything special changed between > DocBook/SGML and DocBook/XML but it should be trivial to fix that. Assuming you are using the version 4.1.2 DTD, there is no difference. If you are using the older version 3.x DTD, then to move to 4.1.2 XML the only significant change is that whatever the tag was called that gave the article info (title, authors, etc) is now called (but was called something else in 3.x -- sorry, can't remember the old name). > > Yes, I have seen it, but I think that it is better XSLT instead of > > python, because XSLT is more easy and it was designed for this kind of > > jobs :-). > > Well, DSSSL wasn't sufficient layout-wise and python is some magnitudes > faster than Jade. > > > However, XSLT could be insufficient if the LaTeX generated is > > very complex. The loops and conditionals in XSLT are very basics, and > > variables and parameters are limited. > > I wouldn't care too much about the Python output now, HTML is important > and XSLT is THE choice here. > > > I love sablotron. It is fast and very easy to use. Also, it has almost > > every feature of the XSLT standar. > > I see, how long would it take to transform into HTML compared to Jade? The xsltproc that comes with libxslt works out of the box, too and is being used a lot in the GNOME project already. > > When you "XSLT files" you must say "XSLT file". Unlike DocBook, with > > XSLT we only will be able to produce one file, instead of one by > > . > > > Anyway, it will be easy :) > > So we cannot slice the HTML output into several files? That's sort of a > problem, really. It took quite some time to figure out how to get Jade > to do that and still releases are a pain in the neck because there's a > lot which has do be done manually still. This is simpoly not the case. Norm Walsh has produced an XSLT package that allows chunking, as it is called. libxslt supports it and, as I understand, a some other XSLT processors do as well (it requires an extension to the engine, but the mechanism for supplying this is documented in the spec, etc). Saxon, for one, can handle the chunking also, since that is what a lot of the DocBook developers use. Basically, you can specify which level of sectioning gets put on a new page (by default, each is a new page). You can also configure whether the files are named by using id() calls, or by using the id tag of the leading element (the latter is preferable, providing each section tag is written as , etc). Regards, Malcolm -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 06:16:51PM +0200, Sven Neumann wrote: > Hi, > > Daniel Egger <[EMAIL PROTECTED]> writes: > > > So what we need is: > > [...] > > - XSLT files and CSS stylesheets to produce XHTML which looks nice in > > nowadays webbrowsers > > - XSLT files which produce output which is grokkable by the (new?) > > helpbrowser plugin; That means we either need simple HTML files for > > something like the current plugin or some other (new?) simple > > fileformat which allows for additional features which also need to be > > defined. This has to be discussed with the person(s) who will code > > that (and that certainly won't be me). > > I'd say we port the help_browser plug-in to GtkHtml2. It's able to > render quite sophisticated stuff (see http://gtkhtml2.codefactory.se/). > Porting the plug-in should be pretty straightforward. The API is not > compatible but similar. Note that gtkhtml2 is suffering from a lack of maintenance at the moment. The only major project that is currently using it is Mikael Hallendal's Yelp (help browser for GNOME 2). However, Mikael has just recently posted some mail to gnome-doc-list and desktop-devel saying that he is thinking of not using it. GtkHtml(1) is currently being ported to GNOME 2. The main differences are that GtkHtml has editing, but is not accessible and does not support CSS or DOMs, while GtkHtml2 is not editable but is accessible with CSS and DOM support. It's unclear whether anybody will come out of the woodwork and say they will maintain GtkHtml2, so you might want to wait a week or so before making a decision in this regard. Cheers, Malcolm -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code
Am Son, 2002-05-05 um 00.27 schrieb Nathan C Summers: > It would be trivial to add some magic text like "&$^CUT HERE!^$&" where > the files need to be cut and then have a postprocessing script written in > perl that takes the xslt output and cuts it appropriately. I'm not really happy with that approach as it complicates things quite a bit. It's messy enough what we have now and I hoped we could get everything a bit cleaner. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code
On 4 May 2002, Daniel Egger wrote: > Am Sam, 2002-05-04 um 20.42 schrieb Ayose: > > > When you "XSLT files" you must say "XSLT file". Unlike DocBook, with > > XSLT we only will be able to produce one file, instead of one by > > . > > > Anyway, it will be easy :) > > So we cannot slice the HTML output into several files? That's sort of a > problem, really. It took quite some time to figure out how to get Jade > to do that and still releases are a pain in the neck because there's a > lot which has do be done manually still. It would be trivial to add some magic text like "&$^CUT HERE!^$&" where the files need to be cut and then have a postprocessing script written in perl that takes the xslt output and cuts it appropriately. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] LinuxTag 2002 - Contributors?
Hi all. As you can see at http://www.linuxtag.org/2002/english/30.html this years LinuxTag is approaching rapidly. Since I am buried in work I will be unable to do major organisation for a Gimp booth. The current plan is to share a booth with the Gnome team. If you want to come to the biggest Linux'ish event in Europe and help at the Gimp/Gnome booth, please drop me a line. Unfortunately I won't be able to organize travelling or rooms for you. It would be great, if some people were willing to help! Thanks, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code
Am Sam, 2002-05-04 um 20.42 schrieb Ayose: > It should be DockBook/XML :) Well, is IS XML, just the DTD is an SGML one. All strict XML like correct closing and shortened tags as well as case sensitivity are obeyed, I just haven't checked if anything special changed between DocBook/SGML and DocBook/XML but it should be trivial to fix that. > Yes, I have seen it, but I think that it is better XSLT instead of > python, because XSLT is more easy and it was designed for this kind of > jobs :-). Well, DSSSL wasn't sufficient layout-wise and python is some magnitudes faster than Jade. > However, XSLT could be insufficient if the LaTeX generated is > very complex. The loops and conditionals in XSLT are very basics, and > variables and parameters are limited. I wouldn't care too much about the Python output now, HTML is important and XSLT is THE choice here. > I love sablotron. It is fast and very easy to use. Also, it has almost > every feature of the XSLT standar. I see, how long would it take to transform into HTML compared to Jade? > When you "XSLT files" you must say "XSLT file". Unlike DocBook, with > XSLT we only will be able to produce one file, instead of one by > . > Anyway, it will be easy :) So we cannot slice the HTML output into several files? That's sort of a problem, really. It took quite some time to figure out how to get Jade to do that and still releases are a pain in the neck because there's a lot which has do be done manually still. > Well. If you want, look my work in http://gimp.es.gnome.org (spanish). > The tutorials (http://gimp.es.gnome.org/manuales.php) are written in a > new XML vocabulary. For instance, the XML file > >http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/manuales/ilustracion/index.xml?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=GNOME > will generate http://gimp.es.gnome.org/manuales/ilustracion/ using the > XSLT > >http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/gimp.xsl?rev=1.36&content-type=text/x-cvsweb-markup&cvsroot=GNOME I'll have a look, I promise. :) > > This need a lot of planning and someone with your experience can > > possibly bring in some thoughts which would be really appreciated. > Of course :). If I'm useful for GIMP I will work here. What do you need? First of all we need ideas what the help should like and which nifty features we might be able to introduce. Mel wanted redo the complete structure anyway so we have lots of freedom to design... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Am Sam, 2002-05-04 um 18.16 schrieb Sven Neumann: > I'd say we port the help_browser plug-in to GtkHtml2. It's able to > render quite sophisticated stuff (see http://gtkhtml2.codefactory.se/). > Porting the plug-in should be pretty straightforward. The API is not > compatible but similar. Fine with me. Still it might make sense to have a different XSLT file for the HTML files for the helpbrowser because online help makes mostly sense when one can read about and try to apply the just learned instead of having to switch between a big window and the application which is what the documentation for the normal browser would probably be optimised for. Also it might make sense to allow the helpbrowser to fire events for GIMP for demonstration or help purposes which would require use to have special information in the help. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 06:55:56PM +0200, Sven Neumann wrote: > Hi, > > Ayose <[EMAIL PROTECTED]> writes: > > > > we will most likely need at least one XLST that extracts a much > > > simpler format to be used in the About dialog. > > > > How "simpler"? Something like > > > > name, author (email), comments > > all we need are simple list of names. Or do we want email addresses in > the about dialog and the AUTHORS file? I think not. The transformation > wouldn't be a real XSLT since what we need as output format is not > actually XML. I'd like to generate the plain-text file AUTHORS as well > as the header file app/gui/authors.h from the XML file. Wait a moment, please. Who says that XSLT only works with XML? With XSLT you can transform a XML file in everything: a plain-text, HTML, a new XML or even in C source. You only need put in the top-level. http://www.w3.org/TR/xslt.html#section-Text-Output-Method > > Commenting on your proposal, I'd say that it probably makes sense to > organize the XML file by persons because we need more than only > plug-ins. So I was wrong > We also want to list core developers, tool authors, help > writers, web masters, screen designers, just everyone who contributed > to The GIMP. Well, imaging you want to know only his/her name and email, and put a comment about he/she The XML: the name email A little comment For every person will be a entry. And, for instance, if you want to get a list like name1, work1 name2, work2 name3, work3 [...] The XSLT will be http://www.w3.org/1999/XSL/Transform";> , There are a lot of chars, but the code is simple. :) Of course, with the same XML you can get a more detailed list about people. -- Ayose Cazorla León Debian GNU/Linux - setepo ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 06:02:44PM +0200, Daniel Egger wrote: > > gimp-help is written in DocBook/SGML It should be DockBook/XML :) > which is converted to HTML to be > suitable for online-browsing and the help-browser plugin for GIMP. There > are HTML and PS/PDF DSSSL stylesheets which can be used to produce > either the HTML or some (buttugly) PS/PDF file; also we have an > experimental DocBook->LaTeX converter written in python by me which > tends to produce much better PDF output. Yes, I have seen it, but I think that it is better XSLT instead of python, because XSLT is more easy and it was designed for this kind of jobs :-). However, XSLT could be insufficient if the LaTeX generated is very complex. The loops and conditionals in XSLT are very basics, and variables and parameters are limited. > > The DocBook source is written such that the conversion to XML is merely > changing the DTD to an XML one; in short: it is already supposed to be > valid XML. It just hadn't been done so far because the tools were not > mature and fast enough last time I looked but if they were now > > So what we need is: > - A featurerich (and possibly FAST!) XSLT processor I love sablotron. It is fast and very easy to use. Also, it has almost every feature of the XSLT standar. > - XSLT files and CSS stylesheets to produce XHTML which looks nice in > nowadays webbrowsers When you "XSLT files" you must say "XSLT file". Unlike DocBook, with XSLT we only will be able to produce one file, instead of one by . Anyway, it will be easy :) Well. If you want, look my work in http://gimp.es.gnome.org (spanish). The tutorials (http://gimp.es.gnome.org/manuales.php) are written in a new XML vocabulary. For instance, the XML file http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/manuales/ilustracion/index.xml?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=GNOME will generate http://gimp.es.gnome.org/manuales/ilustracion/ using the XSLT http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/gimp.xsl?rev=1.36&content-type=text/x-cvsweb-markup&cvsroot=GNOME > - XSLT files which produce output which is grokkable by the (new?) > helpbrowser plugin; That means we either need simple HTML files for > something like the current plugin or some other (new?) simple > fileformat which allows for additional features which also need to be > defined. This has to be discussed with the person(s) who will code > that (and that certainly won't be me). So we need two XSLT files > > This need a lot of planning and someone with your experience can > possibly bring in some thoughts which would be really appreciated. > Of course :). If I'm useful for GIMP I will work here. What do you need? -- Ayose Cazorla León Debian GNU/Linux - setepo ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Hi, Ayose <[EMAIL PROTECTED]> writes: > > we will most likely need at least one XLST that extracts a much > > simpler format to be used in the About dialog. > > How "simpler"? Something like > > name, author (email), comments all we need are simple list of names. Or do we want email addresses in the about dialog and the AUTHORS file? I think not. The transformation wouldn't be a real XSLT since what we need as output format is not actually XML. I'd like to generate the plain-text file AUTHORS as well as the header file app/gui/authors.h from the XML file. Commenting on your proposal, I'd say that it probably makes sense to organize the XML file by persons because we need more than only plug-ins. We also want to list core developers, tool authors, help writers, web masters, screen designers, just everyone who contributed to The GIMP. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > So what we need is: > [...] > - XSLT files and CSS stylesheets to produce XHTML which looks nice in > nowadays webbrowsers > - XSLT files which produce output which is grokkable by the (new?) > helpbrowser plugin; That means we either need simple HTML files for > something like the current plugin or some other (new?) simple > fileformat which allows for additional features which also need to be > defined. This has to be discussed with the person(s) who will code > that (and that certainly won't be me). I'd say we port the help_browser plug-in to GtkHtml2. It's able to render quite sophisticated stuff (see http://gtkhtml2.codefactory.se/). Porting the plug-in should be pretty straightforward. The API is not compatible but similar. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usage of mnemonics in GIMP 1.3
Hi, Maurits Rijk <[EMAIL PROTECTED]> writes: > GTK 2.0 now has this nice feature of using mnemonics which I think can > greatly improve the navigation inside dialogs. I have 3 questions > about this: > > * should we have some kind of guideline for using these, such that > each plugin will use more or less the same mnemonics? the GNOME style guide could suite our needs. I haven't looked at it in detail. > * what will be the impact on the translations when we start using these? translations will break and need to be updated. However I don't see any particular problem here. Of course translators need to put some thoughts into the mnemonics they use in the translations and should try not to deviate too much from the original (english) mnemonics. > * can I submit a change request in Bugzilla to request for all plugins > to use mnemonics for GIMP 1.4? I'm willing to help out here. sure. I guess the core UI also needs some work in this area. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Am Sam, 2002-05-04 um 18.11 schrieb Ayose: > I know well the XSLT specification, and I have written a lot of lines of > XSLT ;) That's good. > Where is info about gimp-help? In http://www.gimp.org/mailing_list.html > there is no list for it :/, Yes, mostly because there are almost no people behind it. :/ > but I have downloaded the gimp-help module > for CVS. What can I do?, look at bugs.gimp.org? ;) gimp-help is written in DocBook/SGML which is converted to HTML to be suitable for online-browsing and the help-browser plugin for GIMP. There are HTML and PS/PDF DSSSL stylesheets which can be used to produce either the HTML or some (buttugly) PS/PDF file; also we have an experimental DocBook->LaTeX converter written in python by me which tends to produce much better PDF output. The DocBook source is written such that the conversion to XML is merely changing the DTD to an XML one; in short: it is already supposed to be valid XML. It just hadn't been done so far because the tools were not mature and fast enough last time I looked but if they were now So what we need is: - A featurerich (and possibly FAST!) XSLT processor - XSLT files and CSS stylesheets to produce XHTML which looks nice in nowadays webbrowsers - XSLT files which produce output which is grokkable by the (new?) helpbrowser plugin; That means we either need simple HTML files for something like the current plugin or some other (new?) simple fileformat which allows for additional features which also need to be defined. This has to be discussed with the person(s) who will code that (and that certainly won't be me). This need a lot of planning and someone with your experience can possibly bring in some thoughts which would be really appreciated. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 03:51:05PM +0200, Daniel Egger wrote: > Am Sam, 2002-05-04 um 15.41 schrieb Ayose: > > > If you need help with a XSLT I will help you pleased :-) > > Actually if you have experience in that area it would be nice if > you could help out with the gimp-help project. I know well the XSLT specification, and I have written a lot of lines of XSLT ;) Where is info about gimp-help? In http://www.gimp.org/mailing_list.html there is no list for it :/, but I have downloaded the gimp-help module for CVS. What can I do?, look at bugs.gimp.org? ;) -- Ayose Cazorla León Debian GNU/Linux - setepo ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 03:48:20PM +0200, Sven Neumann wrote: > Hi, > > Ayose <[EMAIL PROTECTED]> writes: > > > > > AlienMap > > > >Daniel Cotting > >[EMAIL PROTECTED] > >http://www.mygale.org/~cotting > > > > > > > > > > > >74.0 > >only C files counted > > > > > > > > would it make sense to organize the file by persons instead of > plug-ins? I have no strong feelings either way but I think it should > be considered at least. By persons? No... With that format the plugins are described inside , and every plugin is led by , so the file is organized by plug-ins. Where are you seeing that the organize is by persons? My english is not very good, so if I didn't explain it correctly, please, notice me :) > > > If you need help with a XSLT I will help you pleased :-) > > we will most likely need at least one XLST that extracts a much > simpler format to be used in the About dialog. How "simpler"? Something like name, author (email), comments -- Ayose Cazorla León Debian GNU/Linux - setepo ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Usage of mnemonics in GIMP 1.3
GTK 2.0 now has this nice feature of using mnemonics which I think can greatly improve the navigation inside dialogs. I have 3 questions about this: * should we have some kind of guideline for using these, such that each plugin will use more or less the same mnemonics? * what will be the impact on the translations when we start using these? * can I submit a change request in Bugzilla to request for all plugins to use mnemonics for GIMP 1.4? I'm willing to help out here. Maurits ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Hi, Ayose <[EMAIL PROTECTED]> writes: > > AlienMap > >Daniel Cotting >[EMAIL PROTECTED] >http://www.mygale.org/~cotting > > > > > >74.0 >only C files counted > > > would it make sense to organize the file by persons instead of plug-ins? I have no strong feelings either way but I think it should be considered at least. > If you need help with a XSLT I will help you pleased :-) we will most likely need at least one XLST that extracts a much simpler format to be used in the About dialog. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Am Sam, 2002-05-04 um 13.31 schrieb Sven Neumann: > (4) I suspect the gimp-help crew could also need some help in > converting the existing help files to DocBook-XML (IIRC, that was > the plan) and in updating the help for GIMP-1.3. Please contact > Mel Boyce <[EMAIL PROTECTED]> if you want to help out here. To make gimp-help DocBook/XML all we need to do is flip the switch. Problem are the tools not the format; what would be needed is a working toolchain to convert the XML into HTML or whatever and actually the plan was to wait until you and/or Mitch have decided how to continue with the help-browser plugin. If you want to help out here, with new DocBook source, simple texts, ideas, scripts or just want to say hi simply mail [EMAIL PROTECTED] and don't forget to CC Mel Boyce <[EMAIL PROTECTED]> and Daniel Egger <[EMAIL PROTECTED]>. You'll get all the support you need including CVS write access and a bugzilla account, so if that's what you've ever wanted feel free to contact us. :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
Am Sam, 2002-05-04 um 15.41 schrieb Ayose: > If you need help with a XSLT I will help you pleased :-) Actually if you have experience in that area it would be nice if you could help out with the gimp-help project. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 01:31:27PM +0200, Sven Neumann wrote: > Hi, > > just in case that anyone out there feels bored and useless, here's a > list of things you can do to help us with GIMP-1.3 even if you can't > (or don't want to) code. The items appear in no particular order. > > > (2) There are some files that list contributors and plug-in > maintainers (namely the files PLUGIN_MAINTAINERS and > tools/contributors). I'd like to keep this information in one XML > file that is then used for several purposes: To extract info to > display in the about dialog and to handle maintainance of > plug-ins and bug-reports. The XML approach would have several > advantages. It allows to specify an encoding, so we could use > UTF-8 to be able to show contributor names in the way they are > written natively. We can add all sort of meta information like > email address, bugzilla account, CVS account and what parts of > the code the specific person has contributed to or maintains. > I'd welcome if someone could sit down and come up with a proposal > how such an XML file could be organized. You don't need to write > a DTD, an example would do. The PLUGIN_MAINTAINERS has this --- NAME : AlienMap AUTHOR : Daniel Cotting ([EMAIL PROTECTED], http://www.mygale.org/~cotting) MAINTAINER : SIZE : 74.0 kB in 1 file (only C files counted) COMMENT: --- That could be AlienMap Daniel Cotting [EMAIL PROTECTED] http://www.mygale.org/~cotting 74.0 only C files counted If you need help with a XSLT I will help you pleased :-) -- Ayose Cazorla León Debian GNU/Linux - setepo ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
From: Sven Neumann <[EMAIL PROTECTED]> Date: 04 May 2002 13:54:06 +0200 Robert L Krawitz <[EMAIL PROTECTED]> writes: > Do you want to do anything about the print software for 1.2.4? We've > just released our 4.2.1 release, which is much better than the 4.0.5 > that you're using. actually we wanted to integrate gimp-print-4.2 into gimp-1.3 first. Then, with some experience, do the same change for 1.2. Until now we haven't come around to do so. Perhaps we should indeed consider to update gimp-print in the stable branch. How do you suggest should we proceed? Should we depend on libgimpprint or would it be a good idea to ship gimp-1.2.4 with the whole thing? I'd much rather you link to libgimpprint, and I thought that that's what we had decided. The 4.2.1 version of the plugin, which is presumably what you'd use, had no changes whatsoever over 4.2.0; that code base is rock stable. 4.2.2 will offer a useful quality upgrade (a new dither algorithm) for people printing photos, but that will be a library-only upgrade. 4.2.3 may require a plugin upgrade to get some new functionality that we're discussing, but the 4.2.0 plugin will work with 4.2.3, it just won't have that new functionality. One option might be to distribute Gimp-print as an extra (mirror the distribution of the latest 4.2 release). -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
Hi, Robert L Krawitz <[EMAIL PROTECTED]> writes: > Do you want to do anything about the print software for 1.2.4? We've > just released our 4.2.1 release, which is much better than the 4.0.5 > that you're using. actually we wanted to integrate gimp-print-4.2 into gimp-1.3 first. Then, with some experience, do the same change for 1.2. Until now we haven't come around to do so. Perhaps we should indeed consider to update gimp-print in the stable branch. How do you suggest should we proceed? Should we depend on libgimpprint or would it be a good idea to ship gimp-1.2.4 with the whole thing? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
Do you want to do anything about the print software for 1.2.4? We've just released our 4.2.1 release, which is much better than the 4.0.5 that you're using. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Yes, you can help even if you can't code.
Hi, just in case that anyone out there feels bored and useless, here's a list of things you can do to help us with GIMP-1.3 even if you can't (or don't want to) code. The items appear in no particular order. (1) The CVS tree has two files that list ideas and open tasks for future development: TODO and TODO.xml. We'd like to get rid of these files and store all the good ideas in Bugzilla. Bugzilla has the advantage that people can add comments and that we can assign the bug-reports to milestones. The job that needs to be done here is to look through both files and for each indivual issue check Bugzilla if there is already a bug-report dealing with it. If not a new bug-report should be opened. (2) There are some files that list contributors and plug-in maintainers (namely the files PLUGIN_MAINTAINERS and tools/contributors). I'd like to keep this information in one XML file that is then used for several purposes: To extract info to display in the about dialog and to handle maintainance of plug-ins and bug-reports. The XML approach would have several advantages. It allows to specify an encoding, so we could use UTF-8 to be able to show contributor names in the way they are written natively. We can add all sort of meta information like email address, bugzilla account, CVS account and what parts of the code the specific person has contributed to or maintains. I'd welcome if someone could sit down and come up with a proposal how such an XML file could be organized. You don't need to write a DTD, an example would do. (3) The developers documentation as found in the devel-docs directory needs some work. I have updated the framework lately and I think the Makefile rules for extracting information from the source using gtk-doc are fine now. The SGML files as well as the comments in the code need some work however. Please let me know if you are interested to help out in this area. (4) I suspect the gimp-help crew could also need some help in converting the existing help files to DocBook-XML (IIRC, that was the plan) and in updating the help for GIMP-1.3. Please contact Mel Boyce <[EMAIL PROTECTED]> if you want to help out here. (5) Help with translations is always appreciated. If you are interested please read the file README.i18n in the source tree which should give you all the hints you need. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: > I'd like to comment on bug #79754. Some time ago I built a GIMP 1.2.2 > RPM for SUSE. There was a gimp-fontset.patch included: > > --- app/text_tool.c.origSat Jan 27 16:29:16 2001 > +++ app/text_tool.c Sat Jan 27 16:31:50 2001 > @@ -607,7 +607,7 @@ >gdk_error_warnings = 0; >gdk_error_code = 0; > #ifndef GDK_WINDOWING_WIN32 > - font = gdk_font_load (fontname); > + font = gdk_fontset_load (fontname); >if (!font) > { >g_message (_("Font '%s' not found."), fontname); > @@ -838,7 +838,7 @@ >gdk_error_warnings = 0; >gdk_error_code = 0; > #ifndef GDK_WINDOWING_WIN32 > - font = gdk_font_load (fontname); > + font = gdk_fontset_load (fontname); >if (!font) > return FALSE; > > The problem was: It did not work. If I entered umlauts into the > (dynamic) text tool, the text got truncated there (although they showed > up fine in the preview). (I used the "C" locale, not de_DE or > something). > > I talked a bit with Daniel Egger but we didn't come to a clear solution. > If I find the time, I'll check out CVS today and give check whether the > problem persists. > > I tracked down the problem to gdk_measure_text which called > XmbTextExtens which in turn returned the wrong width (truncated at first > umlaut). > > I'm just telling that story to point out that fontset support might be a > hairy issue and hard to get right. Thanks. Such comments are exactly what I had in mind when I sent the mail. Could you please also attach this comment to the bug-report so it doesn't get lost. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
On Fri, May 03, 2002 at 10:37:37PM +0200, Sven Neumann wrote: > - Look through the list of open bugs for the 1.2.4 milestone (a quick >way to get there is http://bugs.gimp.org/stable-milestone/). Some >of these bugs need comments. Of course patches to fix them are >highly appreciated. I'd like to comment on bug #79754. Some time ago I built a GIMP 1.2.2 RPM for SUSE. There was a gimp-fontset.patch included: --- app/text_tool.c.origSat Jan 27 16:29:16 2001 +++ app/text_tool.c Sat Jan 27 16:31:50 2001 @@ -607,7 +607,7 @@ gdk_error_warnings = 0; gdk_error_code = 0; #ifndef GDK_WINDOWING_WIN32 - font = gdk_font_load (fontname); + font = gdk_fontset_load (fontname); if (!font) { g_message (_("Font '%s' not found."), fontname); @@ -838,7 +838,7 @@ gdk_error_warnings = 0; gdk_error_code = 0; #ifndef GDK_WINDOWING_WIN32 - font = gdk_font_load (fontname); + font = gdk_fontset_load (fontname); if (!font) return FALSE; The problem was: It did not work. If I entered umlauts into the (dynamic) text tool, the text got truncated there (although they showed up fine in the preview). (I used the "C" locale, not de_DE or something). I talked a bit with Daniel Egger but we didn't come to a clear solution. If I find the time, I'll check out CVS today and give check whether the problem persists. I tracked down the problem to gdk_measure_text which called XmbTextExtens which in turn returned the wrong width (truncated at first umlaut). I'm just telling that story to point out that fontset support might be a hairy issue and hard to get right. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer