Re: A try at GNOME MDI

["Ben 'The Con Man' Kahn" <xkahn mail cybersites com>]

On 9 Apr 1998, Tero Pulkkinen wrote:

> If I'm not mistaken, this MDI is very near what we currently have
> handleboxes, but handleboxes are not that bad with it. People who
> like MDI's will like handleboxes more.
> 
> What should be done is to make more variations of what those handleboxes can
> do. I would prefer the following things for them(these all are optional and
> maybe usable/modifiable in runtime):

> 1) Minimizing handlebox while its inside the main window -- just small
>    handle is left for maximizzing it. This hides the content only.
>    (if you have seen netscape with motif toolbars, you know what I mean --
>     this is what I thought handleboxes are first when I saw them)
> 2) getting a new window out from handlebox (this we do have)
> 3) Connecting window attached to the handlebox - so that minimizing the "main"
>    window will minimize all windows separated from it
> 4) moving "content" of handlebox to another position in the widget hierarchy 
>    (maybe to another handlebox via drag&drop.) This allows people to build
>    different kinds of tools and containers for them and let people modify
>    layout of the applications in runtime.
> 5) A handlebox without content could be turned into "dropping zone" via a flag.
>    (this would allow people to drop a window to this zone via drag&drop)  
> 6) Disabling handlebox completely -- i.e. hiding the extra border
>    which allows more operations to do with the area. This would allow
>    people to use handlebox on places where it'd otherwise look just waste of
>    screen space, but where it could be enabled and used to deattach
>    the content.

> This alllows floating toolbars, organizing the desktop by moving toolbars
> around, hiding unwanted toolbars out from sight sometimes...

> The main problem with mdi's are that the content is somewhere hidden
> behind the border of the main window and moving it around is
> clumsy. Handleboxes get rid of that problem, while still providing the
> same advantages than MDI's give.

> Maybe some of these functionalities would be better live inside
> different widgets and then create a widget which collects all features
> to one widget for easier use.

	This is close to what I was thinking.  Look at Photoshop for an
example of this behavior.  (If I undersatdn you correctly.)  The buffer
interface is close to this as well.  So an example would look like this:
 _______________________________________
| GnoWord                               |
|_______________________________________|
| ________    ________    _________     |
|/Doc1.doc\__/Program1\__/Cat&Moose\___ |
||            ---------  -----------   ||
||        There comes a time...        ||
||                                     ||
||_____________________________________||
|_______________________________________|

	Each tab can be dragged out of the window.  When this happens, a
new window is created (at the same spot!) with the contents of the tab.
I'm not sure why minimizarion would be needed, since clicking on a
different tab would just switch and conceptually minimize the old tab.
Tabs could both be displayed on the screen at the same time by dragging
them to different windows.

	This leads to some problems.  Each application needs to be able to
define drop types.  So an office application could drop a document type
(which includes word processor, spreadsheet, etc.)  Whereas this same
application could have a dialog box type as well...  These probably should
be able to be combined.  And so one drop type, can't work with another
drop type.


------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
 If you love something, write it in C; if it compiles, it is yours; 
                     if it doesn't, it never was.