Re: [Gimp-developer] Current work
At 07:12 PM 12/5/2001 -0500, Robert L Krawitz wrote: Gimp-print generates the HTML (and .pdf, and .ps) manuals at packaging time. Do keep in mind that using Gnome-Print to generate the PDF files will give you flat documents (ie. no hyperlinks, bookmarks, etc.) which are VERY USEFUL for documentation... Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
On Wed, Dec 05, 2001 at 11:44:02AM +0100, Michael Natterer [EMAIL PROTECTED] wrote: This could be achieved by filtering xml = html (which is trivial) on install time. That's IMHO a very good idea. Simply XSLT the thing on install and never fiddle with HTML before... If help with XSLT is wanted, btw, I'd be happy to write some stylesheets (that would be part of my personal starting to work in gimp again campaign ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
GNOME has been working on a new help browser that works with XML and scrollkeeper directly. It is worth checking. Also worth a look is the project David Merril is working on that will make it possible to use the XML files and Scrollkeeper stuff with any browser. It is called Scrollserver I think. If necessary, I can try to track down more specifics. Both projects sound good and they are worth looking at rather than continuing to maintain our own help browser. It should provide the functionality we require along with lightening the burden on the GIMP hackers. We could still ship an HTML version with the Windows and Mac and whatever releases and provide a tar of the HTML for download on www.gimp.org. I think it would be nice to work directly with the XML for the user, especially considering some of the added features things like Scrollkeeper offer. Scrollkeeper is allegedly being coordinated with KDE people and such so offering our help in that format should make it easier to integrate with preferred systems. The Scrollserver thingie is supposed to be pretty fast and convert the things on the fly. David Merril (sorry if I am spelling it wrong) is doing it so help can also be used with lynx or any browser. bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
On Wed, Dec 05, 2001 at 05:51:12PM +0100, Rebecca J. Walter wrote: GNOME has been working on a new help browser that works with XML and scrollkeeper directly. It is worth checking. Also worth a look is the project David Merril is working on that will make it possible to use the XML files and Scrollkeeper stuff with any browser. It is called Scrollserver I think. I can probably give a little bit more info about these, since I'm helping to complete the gnome help browser and I've done a small bit of hacking on ScrollServer. Firstly, the help browser (yelp) that's intended for GNOME 2 is probably not appropriate as the lowest denominator. It depends (at least) on the libxml2, libxslt and the gnome-vfs module, which means libbonobo as well (bonobo isn't used in yelp, but it's a requirement for gnome-vfs). So while it will serve any document that is available in scrollkeeper or info or man pages, gimp still needs something simpler for its own use. Yelp will also work with a file passed as a parameter to use for the help file (resolved into an absolute URI by some fairly well-defined rules). Secondly, activity on ScrollServer has slackened a bit lately, since both David Merrill and I have been doing other things. It just presents a front-end to scrollkeeper so that requests can be made of it as if to a webserver and pages are returned in HTML format. All the conversion of XML - HTML is done on the fly (well, cached) by scrollserver. The dependencies there would be python 2.0 or greater, libxml2 and libxslt. ScrollServer seems like a nice idea to me, but nothing uses it, so I have no idea whether it's actually useful or not. My gut feeling is that serving help pages for a single application from something like ScrollServer is overkill and tricky to manage. Now it's possible that yelp could be slightly adjusted to build and perform at some level of functionality without gnome-vfs. After all, it only uses the gnome-vfs-help library to resolve the uri to look up and to convert it to html (which is really just a call to an external process). The name resolving is much simpler in the gimp and the conversion stuff could either use the same external program or just make direct C calls to libxslt. Right now, this modification isn't going to happen, since we're under the hammer to get something ready asap for GNOME 2. But the design would allow an add-on like this pretty easily, I think. But really, I don't know what the answers are. I just thought I'd through out some opinions and maybe if people want to think this way it will be useful. Cheers, Malcolm -- A clear conscience is usually the sign of a bad memory. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
On 5 Dec, Sven Neumann wrote: what would be the additional features you have in mind here? Options would be reformatting of the layout to fit the screen layout better or making it easier to read for vision impaired by applying additional rules. Also the level of detail could be easily changed say like removing warnings and or screenshots to just get a reference. Possible would be also the search for special attributes or tags like dynamically generating an index of all documented menu entries. This is only possible with the markup in the DocBook source. I agree however that shipping the HTML with the sources is not a perfect solution. Converting at installation time is an option, but then it adds a new requirement to the build environment and I doubt that a lot of people have a working featureful XSLT processor installed. Especially since good ones are still rare/buggy/dog slow/insert your favourite hatephrase here. It is probably a good idea to continue to do the conversion when packaging the help tarball (on 'make dist'). This wouldn't make a big difference for us, except we find some way to adapt the HTML output to the C-Source by referencing the XML links in the C-Source and having an intelligent script which sorts out the problems. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
From: Sven Neumann [EMAIL PROTECTED] Date: 05 Dec 2001 14:15:42 +0100 what would be the additional features you have in mind here? I don't see any advantange in relying on advanced capabilities in the help browser. I agree however that shipping the HTML with the sources is not a perfect solution. Converting at installation time is an option, but then it adds a new requirement to the build environment and I doubt that a lot of people have a working featureful XSLT processor installed. It is probably a good idea to continue to do the conversion when packaging the help tarball (on 'make dist'). Gimp-print generates the HTML (and .pdf, and .ps) manuals at packaging time. The docbook toolchain seems to be incredibly fragile; different versions of tools emit different warnings and/or fail in different ways. I would not recommend requiring the docbook toolchain at compile time. -- 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] Current work
If help with XSLT is wanted, btw, I'd be happy to write some stylesheets (that would be part of my personal starting to work in gimp again campaign ;) IMHO XML could be appreciated in both data/log features as well.Btw, I released a small perl library : http://fabian.unixtech.be/perlgimp/ Regards, Fabian -- Sent through GMX FreeMail - http://www.gmx.net ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
Continuing Bolsh's thread... My current project is to proofread all the strings in the program. I am trying to standardize things like proper use of plug-in so the user is presented with a consistent use of language in the interface. I am also trying to improve standardization of strings as much as possible and make sure that error messages to the user can actually make sense to the user. In the course of this, I am also helping to standardize the use of g_warning and g_message and what things are used for %s is bug messages. I am currently working in app/gui. I intend to also do all the existing plug-ins when I eventually have time. If any plug-in maintainers want me to send them patches before committing, I would be happy to do so. Just let me know off list at some point and I will make myself a list for when I get around to them. After I get through everything, I will try to actually look at the interface and help to standardize capitalization and such to make things consistent. I am not a UI designer though so won't be moving things around or anything. I just want the user to be handed something consistent. Marco Wessel (CyBeR) is helping me a lot so I have to bug Mitch and Sven less. thanks. bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
Dave Neary ([EMAIL PROTECTED]) wrote about his current project. I think I should do the same too, despite the fact that there is no real code yet. I am currently thinking about a new infrastructure in Gimp for vector image data. Originated from frustration about the current path tool (both - useability and things that are possible with it) I implemented ages ago a new path tool which had some cool features - except one thing: It is not useable to create image content with it. It is still in CVS (some things are missing though) but I think it has to be rewritten for the following reasons: 1) it is constructed arount path and path-like things, and thats a limitation 2) it is not nicely integrated in the imagedata, 3) since we now have the idea of tool objects it probably should evolve in a bunch of tools (no clear ideas on this front). As I said, this stuff is vapourware since ages. I am sorry about this, but currently I am trying to finish my studies and this is a task that is sometimes kind of blocking me from other things :-) Another blocking issue for me is, that this can be deeply involved with all gimp core stuff. I am kind of scared about that. So here are some rough ideas about this stuff: We need a Object-structure to be able to store and handle vector imagedata. I am not sure about how far we should go in this way, or where is the point to leave this stuff to other programs like sketch or sodipodi. We have to be able to handle at least bezier paths, grids, basic geometric objects. These should be derived from a GimpVectors Object, that has some ideas about anchors and controlpoints and lines connecting them. The path tool (or vector tool) just asks for the control points and anchors, can render them on the image window and draw lines according to information from the GimpVector object. It could also provide information about restrictions in the freedom of the control points. So the vector tool does not have to know too much about the specifics of the vector data itself. It could even work on Text. The next logical step is, to make these vector objects full featured elements of the image (assign a color to them, fill them with some other color). But at that point it makes no real sense to have these Objects in a separate list (the path tab or so), they should be integrated in the Layers Dialog then. Maybe as a kind of pixel provider. Ideas and comments are highly appreciated. As I said above this is (unfortunately) vapour ware yet and it does not look as if it would become non-vapour in the next time. Bye, 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] Current work
I'm currently in end-of-semester crunch time, so I won't be working on Gimp until after all of my semester projects are done. The IRC addicts are probably already aware that my plans for after that are: * implement tool plug-ins with as little disturbance to the rest of Gimp as is reasonable. * write PDB functions for the few remaining palette functions that are not yet exposed. There are several possible ways to implement tool plug-ins. While I have pretty much come to a conclusion about which way is best, I still would like some input on alternatives. I will post an RFC when I have time. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
On Wed, Dec 05, 2001 at 12:07:56AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Why not directly read XML in a plugin and apply some inline defined styles to it? Just an idea... it might be a good idea to keep the help pages in a format that can be read with standard browsers ?! This could be achieved by filtering xml = html (which is trivial) on install time. The installed help pages would not require special rutime support and would be standard (x)html. this leaves all options open for later. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
