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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Tasks for the interested reader {#tasks_for_the_interested_reader}
===============================
MirAL needs to grow based on feeback on what shell developers really need. The
simple miral-shell example is around the "minimally viable product" point. That
is, it can be used but isn't very satisfying. Also the encapsulation provided
by libmiral is leaky.
ABI design and stability
------------------------
There are some aspects of the current interface that are of concern for the
stability of the ABI. In particular, classes with accessible data members or
with virtual function tables can only be modified in restricted ways.
- There are neither tests of MirAL code, nor of the sample code using it.
(This comes from its origin as a proof-of-concept "spike", but needs
correcting.) The test doubles supplied by mir-test-tools should be helpful.
(NB the version of mir-test-tools in Xenial is broken. lp:1583536)
- There's a lack of documentation of the preconditions and postconditions of
the API.
Missing functionality
---------------------
To make use of miral-shell more satisfying there are a lot of pieces of work
needed. Some are simple improvements to the sample shell, other may need
additions to libmiral to expose additional Mir functionality.
- Titlebars. The default "titlebar" window management strategy paints
grey rectangles for titlebars. They should contain the window title and
sizing controls.
- Titlebars. The "tiling" window does not offer them at all.
- Titlebars. GTK+ apps provide their own titlebars, better integration is
needed.
- Keyboard layouts. It should be possible to configure and use non-US keyboard
layouts.
- Better integration of startup animation. A short animation is played on
startup. Ideally this should remain visible until a client is launched,
fade out over the top of the client and resume when the last client exits.
- launching external clients. There's currently an option to launch e.g. the
gnome-terminal at startup. This would be better with Ctrl-Alt-T. But note,
forking from a running server (with multiple threads and owning system
resources) is a Bad Idea(tm).
- Wallpaper. The default black background is boring.
- Shadows, animations and other "effects".
- Menu integration with toolkits. We should probably support dbus menus.
- Add virtual workspaces. A virtual workspace represents a group of windows
that can be switched away from (hidden) or to (shown) in a single action.
Each window belongs in a single virtual workspace. A virtual workspace
represents a group of windows that can be switched away from (hidden) or
to (shown) in a single action. Each window belongs in a single virtual
workspace.
- Compositing effects. There needs to be an API for coding "effects" within
the compositor (spreads, wobbly windows, shadows).
- Customizing compositing. There needs to be a mechanism for loading custom
compositing effects. E.g. specifying a module (or modules) to load.
- Enabling (disabling) cursor when pointing devices are (not) present.
- ability to track connected input devices
- ability to control cursor visibility
- Cursor images. lp:qtmir stubs the cursor images and paints the cursor in its
compositor. Need to consider what ought to be supported here.
- Cut&Paste/Drag&Drop toolkits expect this functionality, but it isn't
provided by Mir. We ought to find a way to provide this.
The tiling window management strategy
-------------------------------------
This code was originally written to prove that different strategies are
possible, without much consideration of being useful. Here are some suggestions
for a better approach:
- top level windows ought to fill the tile when created
- the tiling algorithm ought to lay windows out as follows:
- Single window: takes up the whole screen
- Two windows: The screen is split in two tiles of equal width (half the
screen’s width) and full height. Each window is placed in a tile (left
or right), with the newest window occupying the left tile.
- Three or more windows: The screen is split in two tiles of equal width
and full height, as in the previous case. The newest window occupies
the left tile. The right part is now further divided vertically into
smaller tiles having equal height, to host the remaining windows, with
older windows being closer to the bottom.
- Add a titlebar to the top of the screen. The titlebar should be split evenly
into horizontal blocks, one per tile. Each block containing the title of the
top-level window. The focussed tile is highlighted. Clicking on a title
selects the corresponding window.
Art Resource
------------
Anyone who is able to create and propose some examples to then pick from. We
currently need:
- Default wallpaper
- Default icon (using ubuntu logo atm). Must be svg
Developer Tools
---------------
When writing tests it would be useful to be able insert wrappers around the
WindowManagerTools and WindowManagementPolicy to trace the calls.
When manually testing it would be useful to be able to have logging wrappers
around the WindowManagerTools and WindowManagementPolicy to trace the calls.
- A wrapper class for WindowManagerTools
- A wrapper class for WindowManagementPolicy
- A logging extension to the WindowManagerTools wrapper
- A logging extension to the WindowManagementPolicy wrapper
- An option to insert the above wrappers at runtime
- A feature to insert mock "expectations" into WindowInfo
- A feature to insert mock "expectations" into Window
- An option to insert logging into WindowInfo
- An option to insert logging into Window
|