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] Re: your so called optimizations and why we don't like them
Hi, [EMAIL PROTECTED] writes: but you continue to state that it makes the code cleaner which it clearly doesn't. I say using a type that represents the actual type of the value closely is a feature and not a bug. What wrong about seing: Hey, this value is supposed to be unsigned? This is a cleanup like using enums instead of magic values. if we'd use a programming language that would properly support ranged types, it'd be a cleanup. C however doesn't assure that. If the program would throw a signed exception if a negative value is ever assigned to an unsigned variable, we'd indeed be able to catch bugs and declaring variables as unsigned would make sense. Since this is not the case, the use of unsigned variables is dangerous without giving any real advantages. it gives a small improvement and is probably a valid optimization in this place. That's also not the point. You doubted that using unsigneds/signeds doesn't make a difference and I told you that it might not make a difference on all platforms and compilers but definitely does in not so few cases. your example involved a modulo operation. Modulo is only properly defined on positive values so it definitely makes sense to use an unsigned variable here. But then modulo operations are rare, subtractions are much more frequent and they will give unexpected results if unsigned variables are involved. The difference to the changes I reverted is that this is a very local change. The function is small and the variable is local. It is easy to decide that using an unsigned integer here does not have any unwanted side effects. Sure, but since you're breaking GIMP anyways what's the problem with doing it correctly here? BTW: I tested the afffected functions (including the brushes that you stated would break) and at least there is no obvious breakage but if someone is careing about the code it can only get better not worse. you can't have tested all possible usage patterns since there are way too many. Your changes however did affect mostly headers. This means the values are used in a lot of places and it is almost impossible to check them all. Even if you would check them all, a future change to the code might introduce a bug because the one who did the change didn't think about the unsignedness of the variable (which is defined somewhere else). It will introduce bugs but it will also make a few older bugs obvious and correctable. the point is: how are we supposed to catch them? If the compiler would give us hints like it does for wrong usage of consts and enums, great. However, this is not the case unfortunately. Since the code is very much in flux right now, a lot of these changes are going to happen in the future. I don't get it. distances are for instance per definition always positive if we have a concrete list of types that are always signed or unsigned and we stick to it then we'd have more then now: A documentation and guide for datatypes. distances are a good example since they can very well be negative: dist = a - b; this perfectly valid code will awfully break if b is larger than a and dist is defined unsigned. For the CPU and the compiler it wouldn't make any difference, only the outcome would be wrong. In the worst case the problem only becomes apparent under rare circumstances and is not even caught during the development process. Yes, this might happen though I consider that unlikely. then have a look at some of the bugs reported in plug-ins lately. They have been reported years after the first release and didn't get caught because they only showed up when the plug-in was used on small images (width 64 || height 64). Such a bug could very well be caused by the use of an unsigned variable. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: your so called optimizations and why we don't like them
On Wed, Dec 05, 2001 at 01:11:56AM +0100, [EMAIL PROTECTED] wrote: I say using a type that represents the actual type of the value closely is a feature and not a bug. What wrong about seing: Hey, this value is supposed to be unsigned? Because that's not what unsigned does in C. Unsigned is a promise to the compiler by the programmer; don't make the promise if you're not certain you can. The compiler doesn't enforce type safety with respect to unsigned (except very trivially). -- I love catnip mice. It's why I chew their heads off. They're good for breakfast. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: backtrace of the 1.2.x cannot save and all save-menu entries are gray -bug
Hi, Tuomas Kuosmanen [EMAIL PROTECTED] writes: I am getting these things a LOT on debian/ppc machine running Xfree 4.1 and the debian gimp packages. The symptoms are as follows: at some point, seems to be related to undo, Save, Save As etc get grayed out from the menus. I also get the following on the terminal. This time it also segfaulted, so I caught a backtrace, it is at the very end. Sorry about the messy mail, though I have not seen anyone else complain about this kind of issue with the gimp. It does not happen on the intel machine (redhat), but it happens if I run gimp from it on my powerbook display. Seems like something with X or such is wrong here, but I have no clue what. Everything else works fine. Anyone else have any ideas what this could be? this looks strange indeed. I have no idea how this can happen and the stack-trace is only moderately helpful. Could you give us more information about the versions and origins of glib, gtk+ and gimp that are involved? Salut, Sven ___ 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
[Gimp-developer] Re: backtrace of the 1.2.x cannot save and all save-menu entries are gray -bug
Raphael, oops. Sorry. http://bugzilla.gnome.org/show_bug.cgi?id=65117 This is a bug reported recently by Carol that I haven't been able to reproduce. According to her, trying to save a file in a directory in which the Gimp has no write permission causes the Gimp to permanently disable the Save options. I had another open save window. I should not have filed the bug report and I have changed the report at bugzilla to reflect this. It did make me think that maybe something is confusing tigerts gimp session. That gimp thinks there is an open save window, even if there is not one. sorry, i will relurk carol ___ 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
