summaryrefslogtreecommitdiff
path: root/libopie/big-screen/IDEAS
authorzecke <zecke>2004-03-05 22:58:06 (UTC)
committer zecke <zecke>2004-03-05 22:58:06 (UTC)
commitb4ec902435df4e3c834b7790c1dc70a235157477 (patch) (side-by-side diff)
tree56f855525c3da4ca9efd02c148a967a41cc4cdcb /libopie/big-screen/IDEAS
parent3dd27f86cf3865b771258d80048190e0ef6c3177 (diff)
downloadopie-b4ec902435df4e3c834b7790c1dc70a235157477.zip
opie-b4ec902435df4e3c834b7790c1dc70a235157477.tar.gz
opie-b4ec902435df4e3c834b7790c1dc70a235157477.tar.bz2
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
Diffstat (limited to 'libopie/big-screen/IDEAS') (more/less context) (ignore whitespace changes)
-rw-r--r--libopie/big-screen/IDEAS81
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