On Tue, 28 Mar 2000, [EMAIL PROTECTED] wrote:
> On 27 Mar 2000, Lars Clausen wrote:
>
> It is also due to me being busy with other stuff, and not catching up
> with the old patches (sorry about that).
That's what I thought:)
>> Just now I added two new menus on the right-mouse menu, Tools and
>> Select. The Tools menu may seem superfluous, but it's there to allow
>> keyboard shortcuts (and less mouse-movement). The Select menu has
>> several different select methods. Let me know if they're too
>> confusing/unusable. This includes the start of a transitive selection,
>> namely Select Connected, which selects object immediately connected to
>> the currently selected objects. I'll make a Transitive Connect soon.
>
> Those sound like useful things. Speaking of menu enhancements: the
> middle click menu is quite sparse at the moment. Does anyone think it
> would be a good idea to add a few standard object actions to this menu
> (such as delete, properties, and a few others I can't think of at the
> moment).
I'm kinda thinking that the middle menu should really be a submenu of the
right menu. Only that's a bit more involved. People are having enough
trouble finding the right menu (should we start having a Tip of the Day
thing like Gimp?), the middle menu is definitely a problem.
>> I'll be adding persistent menu shortcuts soon, unfortunately they'll
>> have to live in a bunch of different files because of the number of
>> menus that are created dynamically. Interestingly, the menu on the
>> sheet tabs isn't a 'real' menu, in that you can't add shortcuts, but
>> that's a GTK problem.
>
> You should be able to get gtk to dump the right click menu and toolbox
> menu to a file and load it without trouble. That would cover most things
> people would want to add shortcuts for.
I tried that. Problem is, the right menu is not created until a diagram is
created. So if you start dia and then quit without opening a diagram, you
lose all the shortcuts on the right menu. Plus, I'd really like to have
shortcuts on the object menu.
>> James, about the filled bezier/polygon: Should we add two new tools,
>> Filled Polygon and Filled Bezier? They're almost the same as the
>> Polyline and Bezierline. I think having 'connect' and 'fill' options on
>> Polyline and Bezierline would be a nicer solution. Hmmm... the
>> properties will need some way to disable properties, like menus have.
>
> It is probably better to have them as separate shapes, as you want them
> to act differently (eg. have connection points rather than connectable
> handles, etc). We should probably add some more distance functions (such
> as distance from filled polygon, bezier curve, filled bezier, ellipse,
> etc). This could also be used in the custom shape code to get correct
> selection behaviour for them (at the moment it uses a rectangular
> bounding box).
Good point about connection points. I'll go ahead and make the Filled
versions.
>> Units. I have the Properties code for this, but need to deal better
>> with default values for line widths etc for various units, and the
>> modularity problem that Properties are in app while the use is in lib.
>
> How does this sound: add a property type (maybe called length), which is
> the same as the current PROP_TYPE_REAL, except that it uses the
> DiaUnitSpinner widget (which would have to be moved to lib/). This gives
> some unit support to the spin button (eg. you can type in 12pt or 12in or
> 0.5ft and it should do the right thing).
I already added two properties (PROP_TYPE_LENGTH and PROP_TYPE_FONTSIZE) to
do exactly that (though it's not in CVS yet). Didn't see the
DiaUnitSpinner widget yet. And what about the modularity? Preferences are
a thing of app/, the properties that use them one of lib/.
>> The direction of the initial endpoints of a zig-zag line should be
>> settable.
>
> Here is one way to do this: maybe we can look at the direction the handle
> is being pulled with the HANDLE_MOVE_CREATE reason. Then we can set the
> direction acoording to the drag direction.
>
> Of course, this is a bit difficult to implement.
I'll look at that.
>> Grid, zoom, margins, are not saved.
>
> The paper margins should be getting saved. Grid and zoom are currently
> view attributes rather than diagram attributes. I don't know how is best
> to handle this if you have more than one view for the diagram open.
How about saving every view?
>> Add connection point for boxes etc.
>
> I haven't looked too closely at how easy this is to do without breaking
> old diagram files (as it may cause a renumbering of connection points).
I'll keep that in mind.
>> Find better way to specify poly/bezier points at creation.
>
> The drag idea I mentioned for orthconn's could be used for this. It is a
> little difficult though.
Let me go back and find that... you mean dragging the line free-hand and
then fitting the line?
-Lars
--
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | H�rdgrim of Numenor
"I do not agree with a word that you say, but I | Retainer of Sir Kegg
will defend to the death your right to say it." | of Westfield
--Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
