|
|
| Re: [ANN] Non-native InternalShell implementation for SWT [message #451936 is a reply to message #451931] |
Fri, 11 March 2005 14:50   |
 Stefan Zeiger
Messages: 102
Registered: July 2009 |
Senior Member |
|
|
Benjamin Pasero wrote:
> Very interesting. What are the advantages using iShell in comparision to
> non-modal Shells that have the main-shell
> as parent?
It depends on the kind of application you're building. InternalShells
are interesting for MDI applications. These should be using sparingly
and cautiously, IMHO. If you're not sure whether to use SDI (one
top-level window per document) or MDI (one top-level window for the
application with an internal window for each document), go for SDI.
There are other uses for internal windows as well, e.g. GUI builders.
The main differences between top-level windows (with a parent window)
and internal windows are:
- Top-level windows are managed by the window manager, so they show up
in the task bar on Windows (or similar tools in other windowing
systems), internal windows don't (so you need to provide your own way of
switching between windows; this is usually done with a "Window" menu in
MDI applications).
- Top-level windows can be moved around freely on the whole desktop,
internal windows are clipped to the bounds of their desktop form.
- With a non-native implementation like mine (which may be the only
option on some platforms), internal windows use a built-in look & feel
for the decorations (good for branding) while top-level windows are
decorated by the window manager (good if you want a native l&f).
Let's get back to the GUI builder example. Such a tool could use
top-level windows for its own dialogs and internal windows for the
(internal or top-level) windows that you design. That way the internal
windows could be resized and even maximized in their desktop form while
still keeping parts of the GUI builder (e.g. a menu bar and a palette)
visible.
For complex applications with many document and tool windows, there's
still another choice: Views (non-overlapping internal windows), as used
by Eclipse and provided for your own applications by the RCP. This is
often preferable to an MDI design. It can also be combined with
overlapping internal windows by having a desktop form with overlapping
or maximized document windows in the center of the application window
and non-overlapping tool views at the sides.
PS: Take a look at Photoshop to see an awkward MDI interface. IMHO this
application could benefit a lot from a mix of overlapping/maximized
document windows and sidebar tool views.
--
Stefan Zeiger - Developer of Novocode Application Framework
Build SWT-based MVC GUIs via XML: http://www.novocode.com/naf/
|
|
|
| Re: [ANN] Non-native InternalShell implementation for SWT [message #451942 is a reply to message #451936] |
Fri, 11 March 2005 15:18 |
Benjamin Pasero
Messages: 337
Registered: July 2009 |
Senior Member |
|
|
Stefan Zeiger wrote:
> Benjamin Pasero wrote:
>
>> Very interesting. What are the advantages using iShell in comparision to
>> non-modal Shells that have the main-shell
>> as parent?
>
>
> It depends on the kind of application you're building. InternalShells
> are interesting for MDI applications. These should be using sparingly
> and cautiously, IMHO. If you're not sure whether to use SDI (one
> top-level window per document) or MDI (one top-level window for the
> application with an internal window for each document), go for SDI.
> There are other uses for internal windows as well, e.g. GUI builders.
>
> The main differences between top-level windows (with a parent window)
> and internal windows are:
>
> - Top-level windows are managed by the window manager, so they show up
> in the task bar on Windows (or similar tools in other windowing
> systems), internal windows don't (so you need to provide your own way
> of switching between windows; this is usually done with a "Window"
> menu in MDI applications).
Not sure how this is on other OS, but on Windows creating a Shell with a
Shell as parent does not show it in the
Task Bar or the Task Manager.
>
> - Top-level windows can be moved around freely on the whole desktop,
> internal windows are clipped to the bounds of their desktop form.
That's a good point.
>
> - With a non-native implementation like mine (which may be the only
> option on some platforms), internal windows use a built-in look & feel
> for the decorations (good for branding) while top-level windows are
> decorated by the window manager (good if you want a native l&f).
Another good point, though some might ask for a native look and feel
escpecially when the OS uses a Theme
that is very much different from the default one.
>
> Let's get back to the GUI builder example. Such a tool could use
> top-level windows for its own dialogs and internal windows for the
> (internal or top-level) windows that you design. That way the internal
> windows could be resized and even maximized in their desktop form
> while still keeping parts of the GUI builder (e.g. a menu bar and a
> palette) visible.
>
> For complex applications with many document and tool windows, there's
> still another choice: Views (non-overlapping internal windows), as
> used by Eclipse and provided for your own applications by the RCP.
> This is often preferable to an MDI design. It can also be combined
> with overlapping internal windows by having a desktop form with
> overlapping or maximized document windows in the center of the
> application window and non-overlapping tool views at the sides.
>
> PS: Take a look at Photoshop to see an awkward MDI interface. IMHO
> this application could benefit a lot from a mix of
> overlapping/maximized document windows and sidebar tool views.
Keep up the good work :)
Ben
|
|
|
|
Powered by
FUDForum. Page generated in 0.02132 seconds
] 
Search
Help
Register
Login
Home
