Big Screen Extensions should only be in the new LIBOPIEUI2.

We can remove it without risking binary incompatible as these classes
were not in the 1.0 API release

1 files changed, 0 insertions, 81 deletions

diff --git a/libopie/big-screen/IDEAS b/libopie/big-screen/IDEAS
deleted file mode 100644
index 27a4d6e..0000000
--- a/libopie/big-screen/IDEAS
+++ b/dev/null
@@ -1,81 +0,0 @@
-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
\ No newline at end of file