~alan-griffiths/miral/trunk-1

« back to all changes in this revision

Viewing changes to tasks_for_the_interested_reader.md

  • Committer: Alan Griffiths
  • Date: 2016-04-11 10:27:12 UTC
  • Revision ID: alan@octopull.co.uk-20160411102712-tofjao10rywgkmqg
A bit of documentation

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Tasks for the interested reader
 
2
===============================
 
3
 
 
4
MirAL needs to grow based on feeback on what shell developers really need. The
 
5
simple miral-shell example is around the "minimally viable product" point. That
 
6
is, it can be used but isn't very satisfying. Also the encapsulation provided
 
7
by libmiral is leaky.
 
8
 
 
9
 
 
10
Fixing the leaky encapsulation
 
11
------------------------------
 
12
 
 
13
Currently, some types from the Mir server API are exposed by MirAL. These need
 
14
suitable wrapper classes providing, and the corresponding #includes removing
 
15
from include/miral/*.h. Finally, the mirserver pkg_check_modules() and  
 
16
include_directories() options need removing from miral-server/CMakeLists.txt
 
17
 
 
18
 - mir::graphics::DisplayConfigurationOutputId
 
19
 
 
20
 - mir::scene::SurfaceCreationParameters and mir::shell::SurfaceSpecification
 
21
   these are very similar to each other and overlap with miral::SurfaceInfo.
 
22
   All three could be combined into a single type.
 
23
   
 
24
 
 
25
ABI stability
 
26
-------------
 
27
 
 
28
There are some aspects of the current interface that are of concern for the
 
29
stability of the ABI. In particular, classes with accessible data members or
 
30
with virtual function tables can only be modified in restricted ways.
 
31
 
 
32
 - miral::SurfaceInfo and miral::SessionInfo these would be better implemented
 
33
   using the CheshireCat/pimpl idiom allowing properties to be added without 
 
34
   breaking ABI.
 
35
 
 
36
 
 
37
Missing functionality
 
38
---------------------
 
39
 
 
40
To make use of miral-shell more satisfying there are a lot of pieces of work
 
41
needed. Some are simple improvements to the sample shell, other may need 
 
42
additions to libmiral to expose additional Mir functionality.
 
43
 
 
44
 - Titlebars. The default "canonical" window management strategy paints
 
45
   grey rectangles for titlebars. The "tiling" window does not offer them
 
46
   at all. They should contain the window title and sizing controls.
 
47
   
 
48
 - Better integration of startup animation. A short animation is played on
 
49
   startup. Ideally this should remain visible until a client is launched,
 
50
   fade out over the top of the client and resume when the last client exits.
 
51
 
 
52
 - Launching internal clients. Currently a short animation is played on
 
53
   startup. Shells ought to be able to launch internal clients at any time.
 
54
   
 
55
 - launching external clients. There's currently an option to launch the
 
56
   gnome-terminal at startup. This would be better with Ctrl-Alt-T. But note, 
 
57
   forking from a running server (with multiple threads and owning system
 
58
   resources) is a Bad Idea(tm).
 
59
   
 
60
 - launching startup applications. There's currently an option to launch the
 
61
   gnome-terminal at startup. A more general approach is desirable.
 
62
   
 
63
 - Wallpaper. The default black background is boring.
 
64
  
 
65
 - Shadows, animations and other "effects".
 
66
 
 
67
 - Add virtual workspaces. A virtual workspace represents a group of surfaces
 
68
   that can be switched away from (hidden) or to (shown) in a single action.
 
69
   Each surface belongs in a single virtual workspace. A virtual workspace
 
70
   represents a group of surfaces that can be switched away from (hidden) or 
 
71
   to (shown) in a single action. Each surface belongs in a single virtual
 
72
   workspace.
 
73
 
 
74
 
 
75
The tiling window management strategy
 
76
-------------------------------------
 
77
 
 
78
This code was originally written to prove that different strategies are 
 
79
possible, without much consideration of being useful. Here are some suggestions
 
80
for a better approach:
 
81
 
 
82
 - top level surfaces ought to fill the tile when created
 
83
 
 
84
 - the tiling algorithm ought to lay surfaces out as follows:
 
85
 
 
86
    - Single surface: takes up the whole screen
 
87
    
 
88
    - Two surfaces: The screen is split in two tiles of equal width (half the
 
89
      screen’s width) and full height. Each surface is placed in a tile (left
 
90
      or right), with the newest surface occupying the left tile.
 
91
      
 
92
    - Three or more surfaces: The screen is split in two tiles of equal width
 
93
      and full height, as in the previous case. The newest surface occupies
 
94
      the left tile. The right part is now further divided vertically into
 
95
      smaller tiles having equal height, to host the remaining surfaces, with
 
96
      older surfaces being closer to the bottom.
 
97
 
 
98
  - Add a titlebar to the top of the screen. The titlebar should be split evenly
 
99
    into horizontal blocks, one per tile. Each block containing the title of the
 
100
    top-level surface. The focussed tile is highlighted. Clicking on a title
 
101
    selects the corresponding surface.
 
102
    
 
103
    
 
 
b'\\ No newline at end of file'