Set also the call state when changing the device mode (NB#160319)
[hildon-application-manager:kalfa-ham.git] / PAST
1 Completed features of the Hildon Application Manager
2 ====================================================
3
4 See FUTURE for planned features.
5
6 * Use HildonStackableWindow instead of a single HildonWindow. [dkedves]
7
8 * scare_user_with_legalese () notice should appear on
9   ip_install_with_info (). [vjaquez]
10
11 Instead of two sequential dialogs, join them in only one.
12
13 * Make a h-a-m/domains config directory. [vjaquez]
14
15 For dropping domain.xexp fragments, just like h-a-m/catalogues.  Also
16 see the lower priority task "config-cleanup".
17
18 * Drop support for memory cards completely [vjaquez]
19
20 Everything related to installation from memory cards should be
21 removed.
22
23 * Update the notification plugin for the new hildon status menu in
24   hildon-desktop [vjaquez]
25
26 * Remove the free space verification from the UI and move it to the
27   apt-worker [vjaquez]
28
29 * Avoiding invisible interaction flows
30
31 Currently, it is possible to start an interaction flow (using
32 start_interaction_flow, say) without immediatly popping up a dialog
33 that would represent this interaction flow.
34
35 The delays used to be shortish, but they can now be quite long because
36 of big OS updates.
37
38 For example, opening the "Details" dialog for a "OS2008 Reloaded"
39 update can take a couple of seconds and there is therefore a long gap
40 between activating the button and the dialog opening.
41
42 Two things need to be done: the preparing of large operations needs to
43 be sped up, and potential gaps in the UI flow need to be plugged.
44 This feature is about pluggin the gaps in the UI.
45
46 First, the gaps need to be identified: look for uses of
47 start_interaction_flow etc and make sure that no operation is
48 performed between calling this start_interaction_flow function and
49 showing the first dialog.
50
51 No apt-worker request can be assumed to be quick (not even things like
52 APTCMD_GET_CATALOGUES that don't require significant processing) since
53 the apt-worker might be busy with something else before being able to
54 process a quick request.
55
56 If information from the apt-worker is needed to construct the dialog,
57 the code could be changed to show an 'empty' dialog with insensitive
58 buttons and a "updating" progress banner.  When the information
59 arrives, the dialog should be filled and the buttons should be made
60 sensitive.
61
62 Please prepare a list of these cases so that we can quickly see
63 whether this approach needs to be refined in some cases.
64
65 The details dialog is already a bit special: do not make the "Close"
66 button insensitive while waiting for more information from the
67 apt-worker.  It should be possible to close the dialog at any time.
68 The apt-worker request does not need to be canceled in that case, but
69 the eventual reply should be safely ignored, of course.
70
71 Maybe some apt-worker requests need to split in two so that the first
72 half can finish quickly.
73
74 * Get rid of the temporary apt state concept [victor]
75
76 When executing a 'card-install' interaction flow, the apt-worker uses
77 a complete, separate, and temporary state that only includes the
78 repository on the card.  This feature is responsible for a lot of
79 code complexity.
80
81 The reason we have the secondary state is that we do not want to
82 download the network repository indices again and do not want to
83 recompute the caches.
84
85 However, card-installs should be very, very rare and we do not need to
86 optimize for them.
87
88 Thus, let's make the code simpler at the expense of card-installs.
89
90 First, the card-install operation will be re-defined to access the
91 network repositories during the operation.  Dependencies can be
92 fulfilled from them.
93
94 Then, the card-install will simply put the card repository to
95 /etc/apt/sources.list.d/hildon-application-manager-temp.list, and
96 remove that file afterward (via a new apt-worker command, probably).
97 For extra robustness, this file should be removed by the apt-worker
98 when it starts.
99
100 Finally, the whole temporary state machinery can be removed.
101
102 * Clean up pre-defined catalogues mechanics [victor]
103
104 The pre-defined catalogues of the Application manager should be
105 handled according to the new packaging policy (doc/packpol-conf.txt).
106
107 ** Spec
108
109 Roughly, this means that we need a strict division into catalogue
110 entries that are completely 'owned' by packages, and catalogue entries
111 that are competely owned by the user.
112
113 All the pre-defined catalogues should be owned by packages and can not
114 be edited by the user.  They are not backed up.
115
116 However, the enabled/disabled flag for each catalogue entry is owned
117 by the user: the user can still disable a pre-defined catalogue.  This
118 flag is backed up.
119
120 ** Implementation hints
121
122 Right now, all catalogue information is stored in a single file,
123 /etc/h-a-m/catalogues.  This should be changed so that only user
124 catalogues are stored there.  Packages should be able to drop files
125 into /usr/share/hildon-application-manager/catalogues/.
126
127 When reading the catalogue information, the xexps from
128 /etc/h-a-m/catalogues and /usr/share/h-a-m/catalogues/ should be
129 merged.  Concretely, the /etc/h-a-m/catalogues file contains the
130 enabled/disabled flags for the catalogues in
131 /usr/share/h-a-m/catalogues directory.  For this, packaged catalogue
132 entries need to be identified reliably: a new "id" attribute should be
133 used for this.
134
135 It is probably a good idea to remember where a catalogue has been read
136 from: after reading its xexp from a file
137 /usr/share/h-a-m/catalogues/foo, we add a <file>foo</file> element to
138 the xexp.  Then catalogues are identified by their "file" plus "id"
139 attributes, making it easier to choose unique ids.
140
141 User catalogues have no "file" attributes.
142
143 When saving the catalogues after the user has edited them, only the
144 /etc/h-a-m/catalogues file should be touched.  That is, the xexps for
145 a catalogue without a "file" attribute are written to that file, for
146 other xexps, only the "file", "id" and "disabled" attribute are
147 written.
148
149 These rules should also be followed by the
150 hildon-application-manager-config utility.  Changes made with that
151 tool count as user edits.
152
153 * Get rid of the "essential"/readonly repositories [victor]
154
155 The Application Catalogue UI dialog has a heavy use of readonly
156 repositories which are based on the repositories marked as
157 "essential", but with the new package catalogue mechanism, this
158 feature is deprecated.
159
160 The readonly flag must be activaded only when is a package catalogue.
161
162 * Get rid of file system synchronicity assumption [victor]
163
164 Some code in the Application manager might rely on the synchronous
165 nature of JFFS2.  This will be a problem should we ever move to some
166 other file system that hasn't this nature, like ext3 or UBIFS.
167
168 See
169
170     http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback
171
172 The code needs to be reviewed and appropriate fsync calls (etc) should
173 be inserted.
174
175 The xexp_write function is a good candidate since it already makes
176 some atomicity guarantees (and its documentation should be updated to
177 mention the syncronicity).
178
179 * Show repository that a package is going to be installed from
180   [victor, vjaquez-show-repo]
181
182 The "Details" dialog should be extended somehow to show the
183 repositories / catalogues that a package is going to be installed
184 from.
185
186 * Remove UI from maemo-select-menu-location [mvo, mvo-remove-menu-location].
187
188 It's annoying.
189
190 * Repairing broken packages [mario]
191
192 If a visible package is in a broken state, it should also be shown in
193 the "Check for Updates" view and updating it should try to unbreak the
194 package.
195
196 Just using mark_for_install might be good enough for unbreaking a
197 package.
198
199 Right now, packages that need to be reinstalled are shown in the
200 "Installable applications" view.  This shouldn't be done anymore.
201
202 Open issue: what about broken invisible packages?  Their brokenness
203 could be charged to the visible parents, but that will charge a broken
204 libgtk, say, on all visible packages.
205
206 * Ignoring packages that violate domain boundaries [mvo]
207
208 The Application manager remembers for each package the 'domain' where
209 it was installed from originally.  Updates to a package that come from
210 another domain are rejected.
211
212 Right now, the Application manager fails installations that have one
213 or more of these domain violations.  Instead, it should just ignore
214 packages from a wrong domain.  This will get rid of the most hard core
215 error message of the AM.
216
217 There is already a hook into libapt-pkg to deal with the domain
218 system.  This hook might be good enough, it might have to be changed.
219 Some thoughts should be spent on whether to move the whole domain
220 concept into libapt-pkg.  Maybe writing a custom DepCache::Policy is
221 the way to go.
222
223 * Speeding up preparation of large operations [mvo]
224
225 Computing an update (calling mark_install in the apt-worker, etc) used
226 to be quick enough, but now it can be quite slow since we have large
227 OS updates.  This needs to be sped up.
228
229 When performing an installation, the frontend asks the backend to
230 compute the same update three times or so.  Either the frontend needs
231 to ask less often or the backend should keep the last operation in the
232 cache.
233
234 * Automatic recovery after an interrupted operation [mvo]
235
236 When a package management operation is interrupted abruptly, the
237 system might still be able to recover by trying to complete the update
238 on the next boot.
239
240 To acomplish this, the apt-worker is run in a new "rescue" mode on
241 every boot, as early as possible.
242
243 The rescue mode will determine whether any repairs are needed, and if
244 so, will attempt them.  Determining whether any repairs are needed
245 must be fast.
246
247 Steps:
248
249 - Move flash-and-reboot functionality into apt-worker so that it is
250   available during repairs.
251
252 - Have the apt-worker write a journal for each INSTALL_PACKAGE
253   operation.  The journal entry should contain the package name and
254   the location with the packages.
255
256 - Add the "rescue" command line command which will look at the
257   journal.  If the journal is non-empty, try to finish it.
258
259 Finishing the journal means first running "dpkg --configure -a",
260 ignoring any errors, and then redoing the installation described in
261 the journal.  Then, "dpkg --configure -a --force-all" is run, for good
262 measure.
263
264 If any packages would need to be downloaded, the repair is not done.
265
266 If the required, the device is rebooted, or flash-and-reboot is run at
267 the end, or booting is allowed to continue.
268
269 UI of this to be decided.
270
271
272 * Pushing of messages into the update notifier plugin [felipe]
273
274 Product management wants to be able to notify the user about
275 significant new applications that are available for theri internet
276 tablets.  They want to use the existing update notifier statusbar
277 plugin for that.
278
279 The update-notifier plugin should be able to watch a given URI and
280 present information from this URL via the statusbar icon.  When the
281 contents of the resource behind the URI has changed, the icon should
282 start blinking; when the user taps it, the blinking should stop and a
283 menu with information from the resource should open; when the user
284 selects an action from the menu, the icon should disappear.
285
286 The original update notification functionality of the statusbar plugin
287 should have priority: the resource watching functionality should only
288 control the icon when the update notification functionality would hide
289 the icon.
290
291 The URI should be checked at the same time as the checking for
292 updates.
293
294 Final details about the UI and the content of the watched resource are
295 upcoming.  The menu should have two action items in it: "Tell me
296 more", which opens the web browser with a given URI, and "No thanks",
297 which does nothing else than hide the icon.
298
299 To get started, the content of the resource should be assumed to be a
300 xexp of the form:
301
302   <info>
303    <text>Blah, blah</text>
304    <uri>http://www.example.com/</uri>
305   </info>
306
307 This should yield a menu like this:
308
309   Blah, blah                <- insensitive
310   -----------
311   Show me more              <- open browser on http://www.example.com
312   No, thanks.               <- hides icon
313
314 It is important that checking the URI does not block the process.  If
315 needed, a separate process should be spawned (no threads, please).
316
317 * Automatic checking for updates in the background
318
319 - APTCMD_UPDATE_PACKAGE_CACHE is renamed to APTCMD_CHECK_UPDATES and
320   made cancellable at every point, not just during downloading.  Also,
321   it should not report errors at the end of the operation but store
322   them away for later retrieval.  It should also collect the
323   information necessary for the notification plugin (number of
324   available updates, classified into "OS", "Nokia", and "Other") and
325   store it away.
326
327 - The apt-worker should be able to be invoked from the command-line to
328   perform the APTCMD_CHECK_UPDATES operation.  When invoked in this
329   way, the operation should be cancellable (using SIGINT, say).  Also,
330   it should refuse to run when the apt-worker is already running as
331   the backend for the AM.
332
333 - When the apt-worker starts in its usual role as the backend for the
334   Application Manager, it should cancel already running instances of
335   itself that have been started from the command line.
336
337 - The Application Manager should have the new "Update All" button in
338   the "Check for Updates" view.
339
340 - There is a new component: the notification statusbar plugin.  The
341   notification plugin runs always and is in one of three different
342   states: invisible/visible/blinking.
343
344 - The notification plugin invokes the apt-worker in comand-line mode
345   to perform APTCMD_CHECK_UPDATES 'occasionally'.  Such a operation is
346   attempted when the following conditions are all true:
347
348   - The last APTCMD_CHECK_UPDATES has stopped (successfully or not,
349     interrupted or not) 24 hours or more ago.
350
351   - There is a active WLAN connection (no Bluetooth).
352
353   When the APTCMD_CHECK_UPDATES can not be performed because the
354   apt-worker is already running as the backend for the Application
355   Manager, the notification plugin should send a message to the AM
356   that requests it to do the operation instead.
357
358 - When the Application Manager receives such a request, it will
359   perform it as early as possible.  It is possible to do it when the
360   AM has been idle for at least one minute.  Idle means: no
361   interaction flow is active.
362
363 - The state changes of the plugin are as follows:
364
365   - when the user taps it (to open the menu), it stops blinking.
366
367   - when a APTCMD_CHECK_UPDATES initiated by the plugin itself was
368     sucessful and updates are available and the plugin was invisible
369     before, it starts blinking.
370
371   - when the "Check for updates" view in the Application Manager is
372     opened, or when the user invokes the Application Manager from the
373     plugin menu and the "Check for Updates" view is already open, the
374     plugin becomes invisible.
375
376 - The notification plugin should store its visibility state
377   permanently across reboots.
378
379 - The notification plugin should be notified by apt-worker whenever
380   the information for it changes, and the plugin should then read that
381   information and reconstruct its menu.