Re: Changes to ivtools-drawtool

[Scott J. <sc...@ac...>]

Glen Koundry wrote:

> > Two comments about work so far:  1) feel free to do generic work
> > like this in place, in the existing methods and classes (I do understand
> this was
> > just an initial experiment);
>
> The reason I put the code in a new file was that I thought that the
> OverlayUnidraw API was a completely separate project, like Unidraw.  Are
> there any guidelines as to what source can be modified and what can't?
>

Anything can be modified, given a good reason.  We try to preserve idraw as is,

which means leaving the UniIdraw and Unidraw class libraries alone for the
most part. But the classes of OverlayUnidraw are the place to evolve generic
extensions.  The only question is whether it is an evolution to an existing
class
which should happen in place, or the creation of new classes which should be
done in new files.

>
> > 2) I like the double row of toolbar buttons, but it
> > certainly begs for some mechanism to preserve a natural height to the
> entire toolbar
> > panel(to preserve the natural shape of the drawing editor, whatever that
> would be).
>
> I am not sure what you mean by "natural height".  I have been working on
> trying to make the program choose the appropriate number of columns for the
> toolbar based on the window size (ie. as the window's height increases,
> fewer columns are needed for the tool buttons).  If you have any hints on
> how to detect changes in window size that would help.  I've tried using the
> Observer/Observable interface via:
> GetEditor()->GetOverlayViewer()->GetOverlayView()->GetOverlayComp()->attach(
> new MyObserver), but it doesn't seem to detect size changes, just drawing
> events

I believe you can do what you want within the Glyph API, as documented in the
InterViews 3.1 Reference Manual:

http://www.ivtools.org/ivtools/doc/refman3.1/refman.html#PAGE13

My rough understanding is a Glyph asks for a certain amount of space
to draw in with a Requisition, is given a certain amount of space to draw
in with an Allocation and declares how much it will actually use by
returning an Extension.  After a window resize I
believe every glyph will receive a new Allocation passed to the
::allocate method, for which it has to compute a new Extension.

The idea would be to specialize the ::allocate method of one
of the glyphs constructed in OverlayKit::MakeToolbar to
dynamically rearrange the glyph sub-tree as needed.

Scott Johnston
http://www.ivtools.org