Re:Re: GUI design of 0.7

[C. Ecker]

On Tue, 9 Nov 2004, Bernhard Reiter wrote:

> > On Sun, 7 Nov 2004, C. Ecker wrote:
> > > I wrote a proposal for the GUI design of skencil 0.7. It is very
> > > unfinished  and only ment for discussion.
>
> Here is what I have noted down yesterday during a train ride,
> while reading the pdf version.
>

>Notes about Christof Ecker's Skencil GUI Guideline Proposal (from
>20041107)
>Bernhard Reiter <address@hidden>
>(20041108)

>First:
>       Christof: Thanks for this great work,
>       the thirteen pages are well written.
>
>(I haven't read the Gnome Human Interface Guidelines (GHIG);
>if it is helpful, why not add a link to the document?)
Lazyness. Here it is: http://developer.gnome.org/projects/gup/hig/

>Terms:
>
>When reading about "Panel" I got reminded of "Inspectors".
>What I have liked a lot in NextStep was, that most
>GUI's were designed having an inspector for the object that was selected.
>The inspector was a panel that could be placed on the screen and stayed
>there
>only changing it contents when you selected a different object.
>To me this catches the nature of graphic objects with properties nicely.

Very good! I have been looking for a term to distinguish the different
kinds of panels. I will change to "Inspectors" in the proposal.

>MDI vs. SDI
>
>I never liked the CSDI nor the MDI-in-one-window, because
>CSDI gives the disadvantages described and MDI-in-one-window seems
>to make up for bad window managing.
>In Nextstep, the MDI actually worked; they let tools and inspectors
>relate to the active window.
>Actually the solutation put forward is close to the NextStep way
>and I support it. I suggest looking at GnuStep and add a panel listing
>the open documents, that can easily placed somewhere.

I will do that.

>Graphic Design:
>
>(The naming of the section could be improved I guess, because it about
>finding a good method of organising the work bench.)

Any suggestion ?

>I think that the grouping in your examples is not too bad.
>It started me thinking about the four icons
>for the foreground background settings.
>They use quite some space and we could try to represent it smaller.
>My Idea:
>What about a small "panel" that display the situation
>of the currently selected object. (This can be an object or a layer, btw)
>Then the mouse (and the mouse wheel) could be used to drag the object
>up and down. The user experience can be improved in showing the real
>stack
>situation. So if there are only three layers at this point, then we only
>present three layers and not four like in the icons currently.
If I understood that the right way you are suggesting something like the
selection (former "tree view") panel where only selected objects are
displayed. Sounds good. A problem of the tree view certainly is that it becomes
very complex when the doc contains too many objects. Are there situations
when one needs to see all objects, not just the selected ones ? Probably
not. OTOH the treeview is convenient to select objects, which would not be
possible then. Hmmm, I am a bit undecided about that.

>Actually I like the remote control metaphor, because people remember
>the functions because of shape, color, icon, location, but mostly how it
>feel when pressing the button. This is where the methaphor ends, unless
>we make force-feedback mice a prerequisite for Skencil.
Right.But the point is that a simple matrix organization which is
suggested by the HIG, or even a grouped matrix organisation is complex
(unuebersichtlich?).

>Auto Apply and Auto update:
>
>To make the application non-blocking when doing a change can be done
>by threads or an event loop that includes the rendering.
>If possible I would prefer the "idle" rendering because it is much easier
>to handle technically. But this might be out of scope of the paper
>as the idea is clear:
>If we want immediate changes, we cannot block the user actions.
>
>To the undo problem:
>What speaks against only having one undo buffer per document?
I want a wordprocessor-like text panel. At least for this panel it would
be needed. Also probably for user plugin dialogs. There should at least be
the possibility to have such panels.

>So no states in panels, which would mean we need to find a solution for
>the immediate apply problem.
>How about:
>       A change in a panel will put the action on the queue
>       and next time the object is called, it will start doing the
>changes.
>       Each time a part is finished, let's say x% the action returns.
>       Two things can happen now:
>               1. The user changes the action, then the x% will be
>discarded.
>               2. It reached 100% then the undo object will be created
>
>       Example: The user selected 100 Kilo objects and opens the color
>panel.
>       He selects red, and the change start to be made.
>       Now he gets second thoughts and changed this to green.
>       By now 30% of the objects have been changed to red, this action
>       is stopped and the change to green starts.
>       The user closes the panel when 70% have been changed
>       and does something else.
>       When 100% of the objects are green, an undo object is placed
>       for the document.

The user would be extremely fast then, or his computer extremely slow.
Changing propoeties is not the time consuming factor I guess, instead
redrawing is the problem. You r suggestions sounds as it would work, but
also to be complex and I would be happy if we could avoid it.

>
>       Note that the user can meanwhile already have selected a line
>width
>       of 2, but that change would have to wait in the action queue
>       until the color change it done and then create its own undo
>object.
>
>Property Panels:
>
>       I agree that property panel window resizes should be avoided.
>       In reference to the inspector model it might be interesting to
>think
>       about representing the propteries of one object in one window
>       with tabs and not having three windows which might not apply to
>all
>       objects.
Would also be ok from my point of view.

>Drag and Drop:
>       Using the context menu to start drag and drop is partly
>       defeating the purpose of point, click and drag.
>       The object propierties menu will work for now, but it seems
>       even better to me to have a small handle beside the "value"
>       representation which can be used a drag source.
>
This too,

Christof