On Tue, 28 Dec 2004, Bryce Harrington wrote:
> Date: Tue, 28 Dec 2004 09:56:14 -0800 (PST)
> From: Bryce Harrington <bryce@...>
> To: Andreas Nilsson <nisses.mail@...>
> Cc: inkscape-devel@...
> Subject: Re: [Inkscape-devel] Suggestion for the preferences dialog
> On Tue, 28 Dec 2004, Andreas Nilsson wrote:
> > >What approach did you use to create this mockup?
> > >
> > >I gave a shot at trying to mock up something with glade, but with
> > >disappointing results. However this definitely looks doable.
It is way too hard to follow the Gnome Human Interface Guidelines.
Ideally it should be easy to do the right thing. It shouldn't be any
harder to create a graphical user interface for a program than it is to
create a web page (which really is just another kind of graphical user
interface). You've done a great job by the way, I couldn't have asked for
more (but I'll probably try later)!
I've used Borland Delphi once or twice and by comparison it is really
difficult to say nice things about Glade except that it should be a
pivotal part of the gnome desktop and it should be the easiest to use
program there is but unfortunately it is a relatively neglected part of
the toolchain (not even in the toolchain in most cases).
> Cool, it looks really good. I'm not sure if we'll be able to replicate
> it exactly, but I think we should strive to get as close as we can -
> this looks extremely good.
> > I am trying to learn Glade, but so far, all my attempts have been
> > unsuccesfull.
Took me a while to get my head around using all the boxes for layout
and now I can mockup a fairly standard application window with menus
and toolbars, haven't tried trees yet though and dialog layout is a whole
other ball of wax.
I can understand why people say it is easier to program than to use RAD
tools but in the long run I think that is much slower and there are far
less people that can help out if you do it that way.
> In fact, I had noticed earlier that we needed tree-oriented editing
> dialogs for several other purposes - the XML tree, layers, extensions,
> and possibly keyboard layouts.
> I was going to emulate the XML editor design,
As the XML Editor is likely to be gettting some serious work done as a
result of GTKMM I suppose now is as good a time as any to say that I
dislike it quite a lot but I'd probably be more comfortable with it if it
had a menubar and standard toolbar and looked more like seperate
application. Mostly I just fire up a text editor with syntax colouring
and use that instead so I haven't looked at the XML in any great detail or
tried to figure out in detail what I dont like about it.
I've been suggesting the seperating out of the XML Editor several times
because there are so many editors that could be used (any text editor,
text editors with syntax colouring, XML editors like conglomerate
and mlview). (Sorry if this isn't sounding very constructive, I'm trying
> but what you've done for
> the preferences dialog looks like it provides the same basic
> capabilities, and I'm thinking that if we can implement this design, we
> can reuse it in at least 4 places.
> One alteration I'm considering in order to support the other kinds of
> dialogs is a toolbar on the top of the dialog (see the XML editor).
Dialogs with toolbars are generally overcomplicated and overcrowded and
probably shouldn't be 'dialogs' but should make the move and become proper
> The other thing I'm wondering is that some people are going to really
> like the extra space between widgets in the dialog (and it helps us
> adhere to the HIG, as you point out),
As I've said already some dialogs aren't really dialogs and should be made
into proper application windows.
The HIG best describes Transient Dialogs and should be used for Transient
> however others will prefer more concise use of space in order to
> maximize the dialogs they can have open at once.
I prefer to call these kinds of non-transient always on dialogs as
Palettes (there may be a better term, let me know if there is). The HIG
does not take into account these kinds of dialogs and does not yet specify
how best to deal with them and in the absence of specific information the
developers of the GNU Image Manipulation Program have done exactly what
should be done for these kinds of dialogs.
(I really hope this is informative, it was my primary reason for
writing this message)
> Preferences are unlikely to be something people will want to have up all
> the time,
The kinds of preferences that need to get changed a lot are either a
bad idea that need to be fixed or belong in the menus somewhere.
(like the View menu).
> and same with extensions, however with the XML editor and layers I'm not
> as sure - what do you think?
As Inkscape gets better the XML editor will only be needed occassionally
to fix bit and pieces that there is no user interface for yet or where
users want to be extremely precise. So while at the moment developers
might be using it a lot and want to keep it open all the time I wouldn't
think that would be the best design for users.
As for Layers I'd think an onscreen palette/dialog would be needed.
If you really want to keep as many users happy as possible it should be
possible to do most of the functions available in the dialog using
alternative transient dialogs. (Adobe Photoshop has a Layers Palette but
also has a transient New Layer Dialog so if you are determined to turn off
the palette and save screen space the system is still workable. I'd
point to it as a reasonably good example of having it both ways).
Hope that helps