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
|
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's duplicated logic managing the "info" data across the different window
management policies that should handled by the MirAL BasicWindowManager.
- 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.
- 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 "canonical" window management strategy paints
grey rectangles for titlebars. The "tiling" window does not offer them
at all. They should contain the window title and sizing controls.
- Titlebars. The approach to titlebars uses Mir ABIs, an alternative
approach wrapped by MirAL is needed.
Titlebars. GTK+ apps provide their own titlebars, bettter 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 internal clients. Currently a short animation is played on
startup. Shells ought to be able to launch internal clients at any time.
- 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.
- Display configuration. There needs to be a useful abstraction of outputs
and geometry. See src/modules/Unity/Screens/screens.h in lp:qtmir.
(Or maybe an internal client can use the client APIs?)
- Cursor images. lp:qtmir stubs the cursor images and paints the cursor in its
compositor. Need to consider what ought to be supported here.
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
|