On 25 Apr 2002, Michael Natterer wrote: > Nathan C Summers <rockwlrs@xxxxxxxxxx> writes: > > On 23 Apr 2002, Michael Natterer wrote: > > After a few weeks of silence, I figured that you didn't have anything > > more to say, so I started commiting again. I have my own schedule, too. > > Sorry again, I know this is not the way communication should happen. > My apologies for my lazyness. Apology accepted. > Same here :) After reading you mail, I understand the way libgimpproxy > is meant to work lots better than before and some of my concerns don't > apply any more... I hoped that that was the case. :) > > Why do you think that your time is orders of magnitude more important than > > mine? > > Why do you think I consider my time more important than yours? The > mail I sent came ages too late, that's my fault. Consider the ratio between how much time it takes to look over the architecture and how much time it takes to implement it. I know that you don't really think your time is more important than mine, but you have to admit that's how it looks. > One reason it took so long is that I just didn't know how to write it > without pissing you off, which is definitely *not* what I want. Hey, I understand that that is a hard skill to learn. :) > 1.3 development would not be where it is now and we cartainly don't want > to prevent valuable work to be done! I hoped that was the case as well. > As mentioned earlier on #gimp I find all this possibilities utterly > cool and I don't object at all to having this feature. I'm just *very* > concerned about exposing these nasty object system deatils to a > library. You're right that the performance thing is a non-issue, given > that the user can choose to module-load the plug-in and that all > GdkEvent related uglyness should and will be handled by the display > shell callbacks. Sounds good. I don't want ugly implementation details exposed any more than you do. > > > We should not add further tools, but drastically reduce their number > > > by separating their ui from the core. > > > > I agree that better ui/logic separation is needed with the tools. That > > gives me an idea...but that is for a different email. > > > > > Then we make the factored out core code (their actual functionality) > > > accessible via both the PDB and a module API. This is close to be > > > finished for the paint tools. In the end, there will be *one* paint tool > > > with a variety of paint_core implementations, each of them optionally > > > featuring it's own tool options. > > > > > > The same holds true for the ImageMap tools, they will probably all > > > collapse into one single tool which simply uses the image_map modules > > > which are compiled in or loaded. > > > > Well the factoring out of core functionality is the main goal of 1.4, > so of course one of the goals is to make all tools (read: their > functionality) usable without even initializing GTK+, so without any > tool involved. The lack of detailed communication is a problem I > admit, but the overall direction was quite clearly outlined IMHO. > > > > The tool itself is an ugly piece of code which is particularly hard to > > > maintain in in't current state, so I really want to keep it an > > > internal detail. Nobody should be forced to subclass GimpFooTool just > > > to get new functionality in. The way to go IMHO is subclassing > > > GimpFooCore (e.g. GimpPaintCore) to get new functionality and simply > > > let it handle by the single GimpPaintTool. > > > > This is all fine and good when you are writing something that falls under > > a handful of specialized categories, but even a lot of the existing tools > > don't fall under nice categories. For example, the move tool is pretty > > much unlike all the other tools and should probably stay that way. As > > another example, I'd like to write a tool that allows the user to > > interactively resize a layer. It makes a good DrawTool, but other than > > that it is not really like any other tool. > > > > What I'm trying to say is that while separating logic and ui is a good > > thing, both logic and gui need to be pluggable. > > Agreed. I said in the last email that I had an idea. How about we rename the current GimpTool class GimpInternalTool. We then create a GimpToolUI class that can be inherited from and which works just like the GimpPaintCore system does now. GimpPaintCore and friends would inherit from GimpToolCore. Since the cores might not be in the core, it would be nice if we could come up with a different name, but nothing comes to mind. Perhaps someone with a thesaurus could help. :) The GimpInternalTool class would know how to talk nicely to the GimpToolUI and GimpToolCore classes. When a ToolCore registers itself, it informs the core which GimpToolUI subclass it's associated with, so we could have, for instance, one GimpPaintUI class that serves as the interface to all the GimpPaintCores. > > The whole point of my work is that core tools and plugin tools are > > implemented practically identically. > > Which is a good thing to do, given the core/ui separation is kept > intact. It should be possible to load e.g. a paint core module into > a GIMP binary which does not even link against GTK+. I agree. > I would strongly prefer to initialize the GimpToolControl struct with > default values in it's constructor and override them explicitly when > needed. This way we can add or remove some of the hacks (or non-hacks) > without the need to change every place where gimp_tool_control_new() > is called. Sounds good to me. > > > and the whole tool system needs much more attention before it actually > > > works nicely. > > > > This is the kind of vague statement you often make that helps no one. > > What exactly needs to be done? When you see room for improvement, instead > > of saying, "no one touch this area of code because it could be made > > better," make public what needs to be done. Itemize it. Then anyone can > > work on making it better. We can not make the Gimp better if we don't know > > what needs to be done. When someone independantly commits something that > > in their opinion makes it better, you just revert it. It really does seem > > like you don't want any contributions. > > Huh? Sorry if that is your impression. I was just overly concerned > that adding more complexity to the tool system in it's current state > doesn't ease the task of cleaning it up. I have no prepared list of > items what needs to be done for the tools. They used to work just by > chance for a long time and often they don't work correctly at all > (like cursor updating). Perhaps in the future it would be good to create detailed lists of what needs to be done. > There currently is no paintcore module API/ABI, but creating a restricted > API for paint cores is much easier than for tools because there is only > the core involved, not core + tools + GTK. As I said above, my concerns > do not apply the way they did before, see below... Good point. That does restrict it a bunch. > > > For instance, you moved GimpObject (including overly ugly crap like > > > it's "disconnect" signal) to libgimpproxy. > > > > I did not move GimpObject. It's still in app/core where it belongs. > > I talked about moving GimpObject, and in fact the Feb 24 patch moved > > GimpObject, but it has never been moved in cvs and was only moved in my > > personal copy for a few days. It was there before I wrote gimp-mkproxy, > > which was a much better solution. > > > > It's true that gimp-mkproxy does copy the structure definition over to > > libgimpproxy. Short of making all tool-related objects not inherit from > > GimpObject, there's not much that can be done to get around that. > > This is exactly the point that hurted me most. From my impression > you were about to proxy all our internal object and object class > *structures* in libgimpproxy... > ...but obviously you exactly do *not* want to do this. Great :) That would hardly be proxying. I'd have to call it libgimpcopy. :) > > We could remove the dependance on GimpObject as well, but it's probably > > not worth the effort. > > > > Looking at app/paint/gimperaser.c for an arbitrary example, I see that it > > depends on GimpDrawable as well. How are you going to magically make this > > dependancy go away for your "clean module ABI" any way other than how I > > have? > > I would do it the same way probably, whithout exporting any structs. > (the nasty GimpObject issue ignored). We might be able to get around the GimpObject issue by making sure that none of the classes whose structs are exported use GimpObject. > The point was not temporary breaking stuff or forcing people to > develop huge portions of code off-tree. We were really afraid you were > about to do things we considered plain wrong. As this is not the case, > please just forget about the reverting idea. Already forgotten. :) > > Ok, then please let us restore the separation of app/core/ from > anything tool related. Currently, many core/ files include > libgimptool/ stuff because GimpToolInfo is defined there. Actually, > GimpToolInfo is a core object, so no part of core/ should need to > include it from libgimptool/, it should be proxied in libgimpproxy/ I'm trying to remember why I moved GimpToolInfo in the first place. It made sense at the time, but now I don't see any reason for it to be in libgimptool at all. It's had a nice vacation in libgimptool, but I think it needs to go back home now. > (actually, GimpToolOptions needs to be objectified as GimpContext > subclass and be the parameter struct for tool core implementations. > Tools then create a view on this model containing all the widgets). OK, but let's do what we currently do with the GimpFooCore classes so that we don't have to include the structure definitions for GimpContext and everything it inherits from in libgimpproxy. > Also, the GimpChannel and GimpChannelClass structs are in libgimpproxy/, > involving stuff like BoundSeg being exported. No need for those structs to be exported. Just didn't tell mkproxy not to export them. > But these are details not related to the real reason for this > thread :) I just have to mention what hit my eyes apart from the > original misassumption... Understand. It's quite productive, though. This last bit is exactly the kind of stuff that should be discussed on gimp-developer more often. > Keep on hacking! Will do. You too. Rockwalrus
