| -rw-r--r-- | libopie/big-screen/IDEAS | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/libopie/big-screen/IDEAS b/libopie/big-screen/IDEAS new file mode 100644 index 0000000..27a4d6e --- a/dev/null +++ b/libopie/big-screen/IDEAS | |||
| @@ -0,0 +1,81 @@ | |||
| 1 | Now that PDAs get a VGA resolution and Opie runs on Webpads | ||
| 2 | and could be used as a Kiosk secure environment the design | ||
| 3 | decision that were right for a 320x240/240x320 doesn't necessary | ||
| 4 | to be right for bigger screens. | ||
| 5 | |||
| 6 | Remember most desktops a few years ago had only a resolution | ||
| 7 | of 800x600. | ||
| 8 | Then also to remember is that a webpad with 640x480 is different to | ||
| 9 | a PDA with the same resolution. The PDA has a much smaller | ||
| 10 | physical display. | ||
| 11 | |||
| 12 | With higher resolution the feeling of a desktop comes. | ||
| 13 | |||
| 14 | Problems with current Opie: | ||
| 15 | -InputMethod use full width but most of the times are not high enough | ||
| 16 | This actually makes it harder to input and looks stupid. | ||
| 17 | -ToolBars only feels strange on bigger screens. Maybe do it like WinCE3 does | ||
| 18 | share the ToolBar with MenuBar if they're too big for the screen allow handles | ||
| 19 | to either show the left or right side. Note that the handle from Qt looks | ||
| 20 | bad and should be patched away | ||
| 21 | -The Escape/Close back to View does not make sense on bigger screens and desktop | ||
| 22 | on a desktop you might even want to show multiple views and detach from the 'system' | ||
| 23 | view | ||
| 24 | -Modality. Dunnow how you get back to the enter dialog without modality in Qt/E fix it? | ||
| 25 | On bigger screen this is not the problem you can move windows. But you should try | ||
| 26 | to be less modal in the future. | ||
| 27 | I've added a small to qpeapplication to iterate over the toplevel widgets 99% | ||
| 28 | ( click on the taskbar to iterate over the widgets first time nothing is changed ) | ||
| 29 | , BUT it should be avoided to use modality showMaximized(), exec() | ||
| 30 | INSTEAD we will use a modal helper where one can register to show a dialog for uid | ||
| 31 | type and will get a signal once the settings need to be applied, rejected or discarded. | ||
| 32 | This way you can almost work like with exec(), do not need to care for freeing. | ||
| 33 | Problems sometimes to have more than one dialog in memory is expensive. Allow queueing | ||
| 34 | and reusing this widget ( only set the Record new? ) | ||
| 35 | -Viewing on bigger screens you may want to have a seperate viewer widget ( topLevel ) which | ||
| 36 | might also get spon off from the normal operation. The (X) close go back does not make | ||
| 37 | sense on bigger screens and feels strange | ||
| 38 | -Sizing and Auto sizing of widgets | ||
| 39 | |||
| 40 | Widgets and Classes | ||
| 41 | |||
| 42 | Toolbar/Action and Popups: | ||
| 43 | While KParts with XMLGUI provide a fantastic technology to change the GUI | ||
| 44 | on the fly. Parsing these GUI descriptions is not an option for PDAs | ||
| 45 | specially not on start up. | ||
| 46 | Instead we will need to use normal object in this case QAction and QPopupMenuss. We | ||
| 47 | will then group these Actions into groups. Each group can have children and one | ||
| 48 | parent. Each group has two attributes one for the menubar and one for the toolbar. | ||
| 49 | Attributes for each might be | together. Always, Never, Auto are the attributes I | ||
| 50 | can think of tonite. Always will place this group always there, Never yeah never, | ||
| 51 | Automatic lets the later described Manager decide. Also one could or MightSpinOff | ||
| 52 | to a group. This way a child group might get spon off if enough place is there. | ||
| 53 | You cann add QAction and QPopupMenus to the group the Group will not take owner ship | ||
| 54 | and you might use your QAction in other places as well. | ||
| 55 | Toplevel groups need to be registered to the manager and this manager will depending | ||
| 56 | on global settings place and control MenuBar and ToolBar/ToolBar. | ||
| 57 | This allows to dynamically create toolbar on the fly | ||
| 58 | |||
| 59 | Modality class: | ||
| 60 | It'll be a template with a QSignal to tell about changes and a method to get to know | ||
| 61 | which action to be applied. It has three template parameters one for the WIdget used | ||
| 62 | and one for the type of uid and the last for the editor widget which | ||
| 63 | at least needs to provide some methods as well. | ||
| 64 | If you need to edit an widget you simply tell the helper about it. If present it'll | ||
| 65 | raise the widget or either queue it or create a new editor depending on a policy | ||
| 66 | one can set manually or get from the system. | ||
| 67 | |||
| 68 | Viewing: | ||
| 69 | We will provide a special OWidgetStack which either is a real QWidgetStack or a QList | ||
| 70 | of toplevel widgets to be raised. One has to see how one can use it with todolist | ||
| 71 | and datebook. specially the switching back and forth need to be handled but with possible | ||
| 72 | no code reordering ( least intrusive ) | ||
| 73 | Viewing II: | ||
| 74 | Example Advanced FM has a tabwidget but on a SIMpad it would make perfect sense to use a | ||
| 75 | QSplitter or QVBox. We will provide an OSplitter which either provides the one | ||
| 76 | or the other widget depending on the size | ||
| 77 | |||
| 78 | |||
| 79 | These small changes ( replacing Q with O + bit more) should make Opie a better environment for | ||
| 80 | bigger screens. The additional library memory is a fair trade off and memory can be recovered | ||
| 81 | by other technics \ No newline at end of file | ||