Docking windows?

Agostino Russo agostino.russo at moorecap.co.uk
Thu Dec 1 16:14:15 CET 2005


> Why? 

This interface is now quite common in several IDEs. Not least because it
makes it easier to layout several windows so that you can see them
simultaneously and it makes a better use of the screen real estate. The
same issues are not necessarily restricted to IDE environments and might
be generalized to desktop interaction. Moreover the approach would be
optional and possibly disabled by default. You can always work with
traditional floating windows if you prefer so, in that case there is no
overhead at all. But, from my experience, whenever people have the
possiblity to use the  docking/notebook interface (in an IDE), they tend
to use it more than they use MDI stacked floating windows. 

For a similar implementation at application level see
http://www.snakesoft.net/wxifm . The main difference is that there is no
need to use special sash window widgets or similar, normal window
borders with resize callbacks can be used instead thus minimisizing
changes to graphical user interface and behaviour. 

Forget about tabs for the time being. Tabs are not strictly necessary
and could be implemented in a later stage or not be implemented at all. 

> _Never_ say that, especially if you hope other people will do the
work. 

In fact I was thinking I might give it a go at it, provided there is
some interest in the project and I get the support from some more
experienced members.

> Huh? That's a wee bit complicated, wouldn't you say? 

Following is what I think is required, if you exclude tabs, most of the
code relates to handling resizing of existing docked windows:

Window Move Event:
* Show dropzone icons, rendered on top layer but below pointer
** 4 icons on the screen borders (for docking above/below with fully
maximized width and hight of 1/5 of screen, or left/right with fully
maximized height and width 1/5 of screen)
** 4 icons inside the docked window under the cursor (for docking it
above/below/left/right taking up half of the available space) + 1 mid
icon for docking as new tab (if tabs are implemented)
** 1 icon inside the floating window under the cursor (dropzone creates
a new tab in floating window, if tabs are implemented)

Window Dock Event (triggered when a window is dropped on a DropZone)
* Resize existing docked windows as appropriate 
* Lock borders as appropriate ( = register resize action callbacks with
border resize event of adjacent windows)
* Unlock borders as appropriate ( = unregister resize action callbacks)
* Store dropzone info (which of the 4 window-dropzones or which of the
4-5 window-dropzones and for which window), used for redocking
maximized, minimized, shaded windows once restored.

Window Undock Event (triggered when a docked window is moved, closed,
resized, moved to different desktop, minimized)
* Resize existing docked windows as appropriate 
* Lock borders as appropriate 
* Unlock borders as appropriate 

Window Border Resize Event (not much to do here):
* Ignore resize action for borders adjacent to screen borders
* For the rest callbacks are used (in callbacks there must be a
mechanism to avoid reciprocal calls and infinite loops).

Window Drop Event (not much to do here):
* If inside dropzone: call Window Dock Event 
* Else: move the window as usual

Window Restore Event (not much to do here):
* If window was previously docked and if stored dropzone can be used
[i.e. if the dropzone used was a screen-dropzone OR (window-dropzone and
the window is still docked)] call Window Dock Event


********************** Legal Disclaimer **********************

The information contained in this e-mail message is intended only for the use of the individual named above.  If the reader of this e-mail message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message is strictly prohibited.  If you have received this message in error, please immediately notify us by telephone at 020.7470.7400, and destroy the original message.  Regulated by the Financial Service Authority




More information about the Xfce4-dev mailing list