Re: GUI design of 0.7

[Bernhard Herzog]

"C. Ecker" <address@hidden> writes:

> I just found that some the links don't work. Try this
> http://de.geocities.com/dendronde/proposal.pdf
> and
> http://de.geocities.com/dendronde/proposal.tgz
> instead.

Thanks for writing all this down.  On the whole this sounds good IMO and
definitely goes in the right direction.  I have some comments now on
things I noticed on a first reading:

Quoting from the proposal:

   The HIG recommends that changes to settings should be applied
   immediately ("auto apply"). And therefore no "Apply" button is
   needed.

In 0.6 the automatic update of the panels can switched off.  In that
case the Apply button is useful to transfer properies from one object to
another.  Other than that, if changes in the panel are applied
immediately there's indeed not much use for the Apply button.

   For complex documents, redrawing the window can take notable time.
   Therefore a automatic "apply" is only possible when the application
   is multithreaded so that the panel is not blocked by the canvas
   redraw. The canvas redraw would need to be in a separate thread (thus
   far it is not I guess).

Skencil is single threaded.  However, you can still solve most of the
blocking while redrawing problem by using an incremental renderer.  We
did that in Thuban.  The same technique would work in Skencil.  The
basic idea is that just as now rendering is only done in idle time, that
is when no events are pending.  However, instead of rendering the
document in one go, only a little bit is rendered and Skencil returns to
the event loop to process any events that might have come in.  Next time
the program becomes idle, rendering continues where it stopped or if the
user did something that invalidated the stuff already drawn starts from
scratch again.  Every few seconds the partial drawing is displayed so
that the user can see the progress and to make it easier to interact
with the drawing.  Python's generators make that kind of thing
relatively painless to code.

   Undo is more complicated and an issue on its own. Some panels have
   non trivial content and therefore an undo-function would be useful (a
   good example is the text entry window of the multiline text
   plugin).

I think such panels are quite rare.  So far only the multiline text
plugin uses one.  I'd prefer not to have such things at all, but for
mutliline text it might be better to have one.


   [named styles panel]
   XXX: Should this panel also be a drag source ?  Of property values ?
   Or named styles ?

When used as a drag source it should be for named styles.  An
alternative would be to drag a style by clicking and dragging on the
name, but to drag a property value by clicking on that property.


   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/