Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Hi, On Sun, 2007-12-09 at 03:32 +, William Skaggs wrote: Okay, I can see that a preview would go a long way toward making the dialog more usable. I looked over the relevant code, though, and I'm not sure it would be very easy to set one up. Previewing libart stroking wouldn't be very hard, because basically all you need is a set of tiles to do the stroking on. Previewing paint tool stroking would be more problematic: it requires either an attached drawable, or massive code changes. So, as far as I can see, the only way to do it without massive rewriting would be to create a new temporary layer, attach it to the image, render the preview onto it, transfer the preview to the dialog, then remove the temporary layer. That wouldn't be hard to do, but it seems a bit, um, baroque. It's not only baroque, it is definitely not a reasonable way to implement this. The Stroke dialog must not alter the image structure. Simply because there is no guarantee that the user (or some plug-in) doesn't do anything else with the image while the dialog is opened. I don't see though why it requires massive changes to implement a preview of paint strokes. It should be possible to do this after some refactoring of the code. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP lecture, berlin...
GIMPsters, This Wednesday (12‑12‑7) I will be presenting at the newthinking store in berlin. It’s berlin‐usability‐stammtisch‐Wednesday and I will do a lecture on GIMP, open source and interaction architecture. Apart from the announced focus on the run of the GIMP redesign project thus far and our professional approach to the top‑10 most requested features, I will also elaborate on the—partially novel— methods developed during the project. If you are in or around berlin this Wednesday, I hope to see you there. Tucholskystraße 48 10117 Berlin, it starts around 19:30. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Sven wrote: I don't see though why it requires massive changes to implement a preview of paint strokes. It should be possible to do this after some refactoring of the code. Stroking with a paint tool is implemented in gimppaintcore-stroke.c, by gimp_paint_core_stroke() or gimp_paint_core_stroke_boundary(), which are very similar. Each of these functions calls: gimp_paint_core_start() gimp_paint_core_paint() gimp_paint_core_interpolate() gimp_paint_core_finish() gimp_paint_core_cleanup() And each of those requires an attached drawable. Furthermore, each of them is actually a virtual function (mostly), implemented differently by each paint tool. And at least some of those object methods will break if you don't have an attached drawable. So I don't see how to make this work on anything other than an attached drawable by any sort of simple refactoring. It would require a major rewrite of the paint core code, and that's some of the worst code in all of GIMP to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
From: William Skaggs [EMAIL PROTECTED] I think I need to follow up on my last message, because it was read incorrectly by some people. I should say that the English skills of most of the people who contribute to GIMP are so strong that I normally don't worry about how I say things, but in this case I assumed too much. The phrase in question is, that's some of the worst code in all of GIMP to mess around with, which was taken by some readers to mean that's some of the worst code in GIMP. To a native English speaker, it certainly does not mean that. It means, approximately, it is dangerous to make changes to that code. The word worst applies to mess around with, not to code. This sort of construction is actually pretty common. If I say, he's a bad man to annoy, it doesn't mean that he is a bad man---bad applies to annoy, not to man. I hope this makes my meaning more clear. Whether it is, in fact, dangerous to make changes to the paint core code is, of course, a different question, but I don't think it is insulting to suggest this. Some of the best code in GIMP is very carefully written to deal with complicated situations, and very dangerous to change, in other words, bad to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
