blob: 27a4d6ef66645a22bad170b7f69d893b20cb1fac (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
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
|
