Now that PDAs get a VGA resolution and Opie runs on Webpads
and could be used as a Kiosk secure environment the design
decision that were right for a 320x240/240x320 doesn't necessary
to be right for bigger screens.

Remember most desktops a few years ago had only a resolution 
of 800x600.
Then also to remember is that a webpad with 640x480 is different to
a PDA with the same resolution. The PDA has a much smaller
physical display.

With higher resolution the feeling of a desktop comes.

Problems with current Opie:
    -InputMethod use full width but most of the times are not high enough
     This actually makes it harder to input and looks stupid.
    -ToolBars only feels strange on bigger screens. Maybe do it like WinCE3 does
     share the ToolBar with MenuBar if they're too big for the screen allow handles
     to either show the left or right side. Note that the handle from Qt looks 
     bad and should be patched away
    -The Escape/Close back to View does not make sense on bigger screens and desktop
     on a desktop you might even want to show multiple views and detach from the 'system'
     view
    -Modality. Dunnow how you get back to the enter dialog without modality in Qt/E fix it?
     On bigger screen this is not the problem you can move windows. But you should try
     to be less modal in the future.
     I've added a small to qpeapplication to iterate over the toplevel widgets 99% 
     ( click on the taskbar to iterate over the widgets first time nothing is changed )
     , BUT it should be avoided to use modality showMaximized(), exec()
     INSTEAD we will use a modal helper where one can register to show a dialog for uid
     type and will get a signal once the settings need to be applied, rejected or discarded.
     This way you can almost work like with exec(), do not need to care for freeing.
     Problems sometimes to have more than one dialog in memory is expensive. Allow queueing
     and reusing this widget ( only set the Record new? )
    -Viewing on bigger screens you may want to have a seperate viewer widget ( topLevel ) which
     might also get spon off from the normal operation. The (X) close go back does not make
     sense on bigger screens and feels strange
    -Sizing and Auto sizing of widgets
    
Widgets and Classes

    Toolbar/Action and Popups:
	While KParts with XMLGUI provide a fantastic technology to change the GUI
	on the fly. Parsing these GUI descriptions is not an option for PDAs
	specially not on start up.
	Instead we will need to use normal object in this case QAction and QPopupMenuss. We
	will then group these Actions into groups. Each group can have children and one
	parent. Each group has two attributes one for the menubar and one for the toolbar.
	Attributes for each might be | together. Always, Never, Auto are the attributes I 
	can think of tonite. Always will place this group always there, Never yeah never, 
	Automatic lets the later described Manager decide. Also one could or MightSpinOff
	to a group. This way a child group might get spon off if enough place is there.
	You cann add QAction and QPopupMenus to the group the Group will not take owner ship
	and you might use your QAction in other places as well.
	Toplevel groups need to be registered to the manager and this manager will depending
	on global settings place and control MenuBar and ToolBar/ToolBar.
	This allows to dynamically create toolbar on the fly

    Modality class:
	It'll be a template with a QSignal to tell about changes and a method to get to know
	which action to be applied. It has three template parameters one for the WIdget used
	and one for the type of uid and the last for the editor widget which
	at least needs to provide some methods as well.
	If you need to edit an widget you simply tell the helper about it. If present it'll
	raise the widget or either queue it or create a new editor depending on a policy
	one can set manually or get from the system.
	
    Viewing:
	We will provide a special OWidgetStack which either is a real QWidgetStack or a QList
	of toplevel widgets to be raised. One has to see how one can use it with todolist
	and datebook. specially the switching back and forth need to be handled but with possible
	no code reordering ( least intrusive )
    Viewing II:
	Example Advanced FM has a tabwidget but on a SIMpad it would make perfect sense to use a
	QSplitter or QVBox. We will provide an OSplitter which either provides the one
	or the other widget depending on the size
	
	
These small changes ( replacing Q with O + bit more) should make Opie a better environment for 
bigger screens. The additional library memory is a fair trade off and memory can be recovered
by other technics