On Thu, 2005-01-13 at 15:34 +0100, Lars Clausen wrote: > Philip Van Hoof sagde:
> > o. I'd prefer a better menu-structure and a distinction between > > "Selected objects" and "Currently selected object". Right now the menu > > says "Objects". Whereas the properties dialog-box is using " Currently > > selected object". I'd be better if there would be two menu's. One for > > "Currently selected object" and one for "All selected objects". > I don't know that there's much use for a "Currently selected object" as > such, except perhaps for the middle-mouse-button menu. > > o. A group-object inherits from object. Therefor it's possible to > > overwrite the get_properties and apply_properties functions (they are > > luckily functionpointers. I just hope that the function pointers are > > using consistently in stead of the implementations for them. In which > > case overwriting by just letting the functionpointer point to another > > function for group-objects, is possible). I have plans to do so and to > > implement a get_properties and a apply_properties for group-objects. > Once we have properties setting on selected objects working, we can remove > that crap from the group object. Never was a good model. Groups should > indeed inherit from object, and might (at some point) be changed to look > like parenting. This is not something that should hold up the > selected-objects properties code, though. Should it be possible to set all the properties of individual objects in a group? In which case I think only a treeview of properties is going to give it a usable userinterface (so rewriting the entire properties-gui). Or does setting the properties of a group-object basically means setting the changed values (in the dialogbox) of as much individual objects of that group-object to the new value. So in that case the dialogbox needs an union of properties of all individual objects. > > o. The undo/redo stuff will right now undo/redo the actions per object > > that had been selected when we applied the properties. It won't undo the > > whole set of actions in one time whereas the apply-button of the dialog > > box does apply all properties in one time (for the end-user point of > > view, that is). I'm not sure how to solve this. It might involve > > altering the undo/redo code (making it possible to pack a set of > > historical actions together or flagging actions to belong in a group > > that is atomic and thus needs to be undone in group rather than > > individually). > > Check out the transaction points, sounds like what you're talking about. Perhaps. I haven't yet checked it out. Will do. > > o. Comments and suggestions about this feature from users who have > > actually tested it. > I applied and it compiled nicely. I saw two bugs (trying to use it with > boxes, ellipses and polygons): > 1) The properties were duplicated, i.e. twice as many properties were > shown in the dialog box that there should have been. First set seemed to > apply to all objects, though. Yes. I've quickly walked through the code that detects intersections. It looks like it's checking whether or not the function-pointer of the apply-handler is already used in one of the other already stored properties. Or something like that. If thats correct, I'm guessing the problem is that for the user it's the same properties, but they have different apply-handlers (so in reality they're different). But I can be wrong here, I haven't really investigated that intersection-function very deeply. So far I Just assumed it's functionality is what I need (but perhaps thats untrue). > 2) Pressing Apply applied all properties to all objects, not just the > changed properties to all objects (FYI, that was the stage I got to in my > attempt for groups a while ago:) To get the working correctly, we first need to show the user that he has changed a property. For example by doing something with the color. Then we will need to alter the functionality for applying properties to an object. Perhaps a flag in the struct of a property (gboolean changed) and letting the GUI set that flag. And letting the apply-handler check for it. Something like that . . . I perhaps misunderstood the 'checkboxes' story of Hans. If this is what he ment, it's indeed necessary to have something like it. I don't feel, however, a checkbox next to each property is going to make the user understand what happened and/or what is going to happen. Delphi, I remember, and Visual Studio .NET, will bold/unbold the value-label of changed properties. For example: Unchanged: Font: Luxi whatever Color: Blue [ABLUECOLOR] Changed: Font: <b>Luxi whatever</b> Color: <b>Blue</a> [ABLUECOLOR] > > Short: It's all possible. However. So far I haven't received many > > feedback from the core developers of Dia. Currently I am waiting for > > that interrupt to be set, by them, with perhaps instructions and > > thoughts, from them, on the mailinglist of Dia :-). > Here you go! Ah, oeps :-). I wasn't aware that you're the Lars from the authors.h file! In that case I've indeed just received that interrupt. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org _______________________________________________ Dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
