Re: GUI design of 0.7

[Pieter Edelman]

On Monday 08 November 2004 23:10, Bernhard Herzog wrote:
> "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.
I think this isn't really needed as there are named styles. But maybe there's 
a need for a more advanced applying of named styles, where only certain parts 
(like line thickness, color, etc.) can be applied.
>
>    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.
In my opinion, it's very UNconvenient to further edit a document while the 
update is still being applied, and it is much better to freeze the 
application until the updates is performed. 
Ig I'm not mistaken, the HIG refers to instant applying changes as a means of 
"instant preview", so that when you drag a slider for example, the changes 
are automatically corrected. IMO this is a great feature, but it can be a 
great annoyance when you're drawing is complex and takes quite some time to 
render, as was mentioned by Christof Ecker. I know this from my own 
experience with the brightness/contrast and colorizer script, that's why you 
can toggle the auto-preview of.
For me, this is probably the best (or the least bad) middle-ground: let the 
user choose whether instant or manual update (preview) is wanted.
>
>    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
Pieter
-- 
Like science? Like cartoons? Wicked...
http://funnybynature.com/