Re: [Gimp-developer] Yes, you can help even if you can't code.
Hi, Malcolm Tredinnick <[EMAIL PROTECTED]> writes: > Well, Anders and Mikael are both claiming that they don't have time to > maintain it at the moment. I'm not sure if Code Factory have an official > position. > > I, too, would prefer to see GtkHtml2 live long and prosper, since it is > much nicer code to read. I don't know what the solution is here. the code is in CVS and people use it (the gimp help browser does so since yesterday). I don't see why it should die. 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.
On Sun, May 05, 2002 at 03:10:47PM +0200, Sven Neumann wrote: [..] > Personally I like the GtkHtml2 approach much better than GtkHtml1 > which is IMHO pure bloat. I think GtkHtml2 can be considered useable > and thus shouldn't need too much maintainance. We are using it in the > company for quite some time now and I have never had problems to get > patches in. Are you saying that codefactory is not supporting the > development any longer? Well, Anders and Mikael are both claiming that they don't have time to maintain it at the moment. I'm not sure if Code Factory have an official position. I, too, would prefer to see GtkHtml2 live long and prosper, since it is much nicer code to read. I don't know what the solution is here. 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 16.52 schrieb Ayose: > sablotron is very fast, look this: > real0m0.542s > user0m0.540s > sys 0m0.000s Cool. > Well, this is a problem if you want all text in a few files, but slice > the content in a lot of files makes easier transforming to HTML, or > other format. Moreover, it will be easier to keep and write :) At the moment we have lots of files which are referenced from the main document for cross referencing purposes but written again to lots of small files. We have a few chapter files as well to glue the topics together for the PDF and HTML reference. We have English content and some Japanese content, which together make it for a whopping 1,9 MB of text resp. 55k lines, so it's not really a small project and thus needs some intelligent management and clever splitting. If you have some ideas how to organize that best feel free to come up with your ideas. -- 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 10:20:25PM +0200, Daniel Egger wrote: > > 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? sablotron is very fast, look this: $ wc -l enlaces.xml gimp.xsl 544 enlaces.xml 400 gimp.xsl 944 total $ time sabcmd gimp.xsl enlaces.xml > /dev/null real 0m0.542s user 0m0.540s sys 0m0.000s And with jade: $ wc -l gimp1.sgml 460 gimp1.sgml $ time db2html gimp1.sgml > /dev/null real 0m5.465s user 0m4.810s sys 0m0.290s In gimp.es.gnome.org, we have a lot of XMLs files which are transformed to HTML or PHP using sablotron, and it takes a few time to complete the process. > > > 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, this is a problem if you want all text in a few files, but slice the content in a lot of files makes easier transforming to HTML, or other format. Moreover, it will be easier to keep and write :) BTW, another solution could be use the XSLT to make intermediates files and, with a script (perl, python...), create the definitives files. That is: we have one XML, using XSLT we transform it in a pre-HTML (without headers), and with the script we split it in severals files and add to it the headers (both HTML and content headers). -- 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, Malcolm Tredinnick <[EMAIL PROTECTED]> writes: > 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. Personally I like the GtkHtml2 approach much better than GtkHtml1 which is IMHO pure bloat. I think GtkHtml2 can be considered useable and thus shouldn't need too much maintainance. We are using it in the company for quite some time now and I have never had problems to get patches in. Are you saying that codefactory is not supporting the development any longer? 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
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
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] 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
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
[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
