|
Home > Archive > Unix Programming > June 2004 > Tutorial and guidelines: Basic frame layout
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Tutorial and guidelines: Basic frame layout
|
|
| Otto Wyss 2004-06-13, 5:53 pm |
| # Do only discuss this guideline, for any other remark change the
# subject send it only to wxguide-users mailing list. Do not
# answer after the next message is sent or only to wxguide-users.
# If you think it's just "bullshit" or simply "not worth" just
# stop answering. I'll stop if I don't see any interests.
#
# Please shorten your answer and quote as less as possible. I know
# what I've written or can look in the archive.
#
# All samples have been removed to shorten the message
2. Basic frame layout
The first a user sees of an application is its initial frame layout. So
even if it might be completely changed afterwards it shouldn't be
designed hastily.
A frame layout has some standard elements like titlebar, menu, optional
toolbars, optional statusbar, etc.
2.1 Initial layout size and position
How large should the initial layout be? Usually an applications minimal
requirement determines the initial size, so i.e. a calendar just uses
the size it needs. Often the size is not easily determined since what a
user wants to do is not known. I.e. an editor window should be as large
as possible but still some room should be left so the essential parts of
the underlying desktop are still shown. Also it doesn't make much sense
to use a full window on a 21" screen.
A good practice is to set the minimal size to the smallest commonly used
screen size (640x480) minus what's needed for other desktop elements
like taskbar, home drive, etc. With increasing screen size the minimal
size might be extended, e.g. until the current letter format (A4) in
portrait mode is reached, always leaving more space for the desktop.
It's not a good idea to start an application with a maximized layout
since a user might simply switch to normal display and immediately
discovers a "stamp" sized layout. Hence the initial layout should always
be shown in normal view.
2.2 Configuring the layout
Even the most sophisticated initial layout never provides what the users
want since they might set entirely different conditions. The layout has
to be configurable so it's set the next time to the size the user
wishes.
An easy solution is to save the last used layout. But in this case the
user can't change the layout temporarily without changing the saved
layout as well. A better approach is to save the latest layout on exit
only when a certain condition is reached. This can either be a flag in
the preferences or still better through a defined exit action. This exit
action could be the activated close box with the mouse while pressing
the "command" (on Windows CTRL) key. A third (in my opinion just
additional) way is through a "save current layout position" command.
2.3 Different layouts
If an application has several different layouts, i.e. a database
information tool with reporting and a login layout, it should always
show the larges first and any other on top of the first. Of course this
also means that any layout after the first has to have an equal or
smaller size. I.e. a preference dialog should never be larger that the
working layout.
2.4 Multiple equal layouts
An application may handle multiple equal layouts, mostly for multiple
documents. These may be shown either as a notebook within a single
window or as completely separate windows. If separate windows were
chosen they should be designed in a way that switching between them with
the task manager (ALT-TAB), or similar concept, is possible.
If a application handles multiple documents it probably also takes care
that no document is opened twice. This is only possible if a single
instance handles all documents. A solution for this is the
SingleInstanceChecker, with this a second instance can be discovered and
the intended work can be sent to the first instance.
2.5 Titlebar
The titlebar of a top level window usually shows the name of the
application and the essential information about what this window
contains. It should the user allow to easily distinguish between windows
on his desktop. Special care has to be taken if an application has
multiple equal or even different top level windows. It's important that
also in this case the user is able to distinguish between them.
Most of the time the essential information is the name of the file being
worked on. Sometimes other information like "readonly" are also show.
Unless such information is necessary for the distinction of top level
windows they should be shown somewhere else. I.e. versioning information
should be moved into the "About .." box.
Titlebar decorations, like close box, etc. are not part of an
application. An application simply has to act on any event produced. In
special cases (only then) an application may decide to disable any of
these decoration.
Child windows should just show its task and if need the item acted upon,
never the applications name, since child windows may only be showed
together with the top level window. If this isn't wished a child window
should be changed into a top level window itself.
2.6 Toolbars
Toolbars usually allows to access the most important commands through
icons to give novice users an overview what they can do, but think even
novice may become accustomed to your application. Consider toolbar uses
precious screen area which could be used otherwise. Always allow to hide
toolbar for user who don't like/need them and put only items into
toolbars which are better accessable through them.
Toolbars are very usefil to contain the navigation selection between
items through a combobox. If a large set of items are used the selection
via menu is rather awkward and much easier with a combobox. Also a
combobox doesn't require an otherwise need permanent pane for navigation
between items.
To make the implementation of navigation selection easier a filelist
class was created. It handles the update of the combobox and optional a
corresponding menu. Only the use of this class is shown here. The class
itself can be gotten via here.
2.7 Statusbar
The statusbar shows all the immediately needed and active information.
It usually also shows the last action done. But it's not a good idea to
show error messages only in the statusbar.
See "http://wxguide.sourceforge.net/guidelines/basics.html".
O. Wyss
--
See wyoEditor at "http://freshmeat.net/projects/wyoeditor/"
| |
| Programmer Dude 2004-06-15, 5:56 pm |
| Otto Wyss writes:
> 2. Basic frame layout
>
> A frame layout has some standard elements like titlebar, menu,
> optional toolbars, optional statusbar, etc.
Ever seen QuickTime? (-:
> 2.1 Initial layout size and position
>
> How large should the initial layout be?
I'll devise a reasonable initial default, but most of my apps, once
used by the user recall the user's last settings.
Quite honestly, Otto, I don't really exactly agree with most of
this attempt to codify a single approach. Apps are too varied.
Your choices are fine for you, perhaps, but they don't "speak"
to me very much.
> An easy solution is to save the last used layout. But in this case the
> user can't change the layout temporarily without changing the saved
> layout as well. A better approach is to save the latest layout on exit
> only when a certain condition is reached.
I often provide two things: I recall the settings upon exit, so the
window and configs are what they were the last time the user used
the app. I also provide a "Save Default/Recall Default" feature that
allows the user to define a "default" config they can recall at will.
> [...ubersnip...]
Okay, fine for you. Not my cuppa. :-)
--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_______________________________________
______|_______________________|
| |
| Otto Wyss 2004-06-15, 5:56 pm |
| Programmer Dude <Chris@Sonnack.com> wrote:
> Otto Wyss writes:
>
>
> Ever seen QuickTime? (-:
>
Yes, why?
>
> I'll devise a reasonable initial default, but most of my apps, once
> used by the user recall the user's last settings.
>
> Quite honestly, Otto, I don't really exactly agree with most of
> this attempt to codify a single approach. Apps are too varied.
>
> Your choices are fine for you, perhaps, but they don't "speak"
> to me very much.
>
You said "I'll devise a reasonable initial default" so you seems to
agree, where is the problem?
>
> I often provide two things: I recall the settings upon exit, so the
> window and configs are what they were the last time the user used
> the app. I also provide a "Save Default/Recall Default" feature that
> allows the user to define a "default" config they can recall at will.
>
Isn't that about what I say in 2.2?
O. Wyss
--
See wyoEditor at "http://freshmeat.net/projects/wyoeditor/"
| |
| Programmer Dude 2004-06-16, 5:57 pm |
| Otto Wyss writes:
>
> Yes, why?
Non-traditional window, although more traditional than I remembered
(in my mind, it lacked titlebar and menubar, but I just booted mine
and it does, so never mind). I should have gone with my original
choice, but couldn't remember the app name: Quick CD, maybe? It's
that CD-Burner app that comes with HP CD burners...
WinAmp was a little oddball, IIRC, too.
[shrug] My only point is I thought your specification for the look
of an app was a little limiting.
>
> You said "I'll devise a reasonable initial default" so you seems to
> agree, where is the problem?
I disagreed with your specification for the initial default. (-:
>
> Isn't that about what I say in 2.2?
Yes. I was agreeing with you here. So much more pleasant that way! (-:
--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_______________________________________
______|_______________________|
|
|
|
|
|