Diffstat (limited to 'libopie2/opieui/big-screen/IDEAS') (more/less context) (ignore whitespace changes)
| -rw-r--r-- | libopie2/opieui/big-screen/IDEAS | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/libopie2/opieui/big-screen/IDEAS b/libopie2/opieui/big-screen/IDEAS new file mode 100644 index 0000000..27a4d6e --- a/dev/null +++ b/libopie2/opieui/big-screen/IDEAS @@ -0,0 +1,81 @@ +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 |