| -rw-r--r-- | libopie/big-screen/IDEAS | 81 |
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 |