Re: Announcing the 'Sheets and Objects' dialog

[Lars Clausen <lrclause cs uiuc edu>]

On Tue, 9 Apr 2002, M. C. Nelson wrote:
> On Mon, 8 Apr 2002 18:21:11 +0000 (UTC), Lars Clausen wrote:
>>
>> On Mon, 8 Apr 2002, Steffen Macke wrote:
>> > 
>> >> Coming soon to a cvs server near you.
>> > 
>> > Right, but before I would like some more people to test Michael's
>> > awesome patch:
> 
> Attached is a *new patch* against the cvs addressing some of the issues
> Lars brought up.
> 
> 567c5bf1de60c3f8829dba222f4b4c88  dia-patch-020409.diff.gz

Woo-hoo!  I feel so... listened to:)  Thanks for responding so quickly and
so well (fixed... done... fixed...).

> NOTE NOTE NOTE
> 
> This patch will only compile with '--enable-gnome' since glade is too
> stupid to make gnome support optional.  When the other elements of 
> the interface have stabilized, code will be modified by hand to support
> either gnome or non-gnome for the cvs (as before).

Stupid glade.  Hopefully we can get this fixed soon.  From the rest of the
mail, it sounds like we're ready to put it into CVS.

>> Now for the nitpicking:)
>> 
>> Bigger things:
>>   
>> Could the dialogs *please* be made non-modal?  I know it's a bit of a
>> bother to make the callbacks, but I really, really dislike modality.  It
>> breaks the illusion of multitasking.
> 
> All the dialogs are now non-modal but the backend is still in progress
> until I figure out how to gracefully handle multiple instances of the
> same window.

I don't mind if there can only be one instance of the editor window.  I
noticed it doesn't block the diagrams.

> Done, for (N)ew, (E)dit, (R)emove, (C)opy, (M)ove.  All <ctrl+key>.
> I don't think Apply, Revert, or Close should be accelerated.  Note that
> glade doesn't support the accellerator highlight but this can be coded
> by hand after we're sure we won't be regenerating the glade output.
> (N)ew is highlighted to see what it looks like.

Let's do this for now.  Perhaps Apply should be Enter and Close escape or
something.  Not of high importance.

>> Smaller things:
>> 
>> The scrollbar on the sheet display comes in too early -- try selecting
>> UML and resize till all objects is show, the scrollbar is still there.
>> It seems to not understand the wrapping of shapes either -- make the
>> editor really wide, and the scrollbar will appear at up to 8 times the
>> required height.  It should depend on the number of lines, not the
>> number of items.
> 
> The idea behind this was to provide a buffer-zone for sheets to grow
> in the number of _lines_, say when someone adds a whole rack of line 
> breaks, so gtk doesn't compress the sheet object buttons (looks ugly).
> (Hmmm, i just realized this could be adjusted dynamically.  Let me get
> back to you).

Yes, that was what I hoped.  No compression necessary.

>> The dialog when removing objects is irritating, since the only
>> alternative in it is very rarely used.  This is a somewhat radical
>> design change: Make it so that if you click in the sheet area outside
>> the icons, or on the sheet selector, no icon is selected, but the sheet
>> name is highlighted.  Then operations should apply to sheets (Remove
>> ghosted for built-in sheets, Up and Down would reorder the sheet list
>> (if that is possible)).  It has to be clear that it's the sheet that's
>> being worked on.
> 
> Hmmm.  I don't expect that the Remove button will be used much in
> general.  I'm not keen on having the Edit dialog offer both sheets and
> objects, but the Remove dialog being contextual.  Either one or the
> other.  As for the order of sheets, at the moment they are sorted by
> Sheet 'name' since there is no other structure to tell dia how to order
> sheets in an arbitrary manner.

I would prefer both Edit and Remove being contextual, *if* we can clearly
visualize when the sheet is selected rather than a shape.
I see why the up-down buttons won't work, then.  Fixing that may be a
way-later thing, and would involve fixing main Dia too.

>> The minimum size for the two sheet displays should be smaller, I thing
>> down to one (maybe two) icons wide and one (maybe two) icons high.
> 
> The issue here is that the text on the buttons at the bottom will be
> cramped if the default size of the dialog is reduced.  We could stack
> the buttons in two rows if you really want to reduce the overall size of
> the dialog.  Personally, I find the larger size easier to work with, but
> that's just me.

Didn't think about the button size.  It's fine, then.

>> If you move line end markers together using up and down, they coalesce.
>> I'm not sure whether that's a bug or a feature.
> 
> Its a feature. :) No really! :)  The sheet datastructure will not allow
> for two line breaks next to each other, so the interface doesn't either.

If we want to fix that in the sheet, it will have to be later.

>> Suggested improvements, not to be done before the basics are OK:
>> 
>> Would it be possible to drag items around in addition to using the
>>   copy/move/up/down buttons?
> 
> Its an idea I played around with in the beginning, but in the interest
> of time, I put it on the back burner.

Good plan.  Let's do that after it's in CVS.

>> How about creating shapes without a (visible) intervening step of saving
>>   to disk?  Basically ask for a name and description, and it will save
>>   the current shape with that name and load it with that description?
> 
> I'm not sure what you mean?  Are you meaning to create a new SVG Shape
> in the main dia window, then add it to a sheet?  If so it could be done
> painlessly by adding an "Import from main window" (or something) radio
> button to the New dialog.

Yes, exactly.  That would be wonderful.

>> How about shift-click to select multiple shapes?
> 
> Selecting multiple shapes would really only be useful for Remove I think.
> It would also be a substantial design change that I think we should
> consider carefully (ie. alot of work).

Also quite useful for copy and move, but with hotkeys not as critical.
Let's put on back burner.

>> Could the line break arrows have no box around them, so they don't look
>>   like actual shapes?
> 
> They still need to be /buttons/ so they can be selected.  But I will 
> play around with the button relief and see if that makes it clearer.

GTK_RELIEF_NONE, perhaps?

I haven't tried the new patch yet, I shall tomorrow (hopefully).  If I
don't find anything critical, let's get the glade stuff fixed and push the
thing into CVS.  

-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   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?