Real Multitasking for Composing-Apps (Mail SMS MMS IM Browser)

asked 2014-01-10 12:40:58 +0300

chemist
41469 ●392 ●542 ●615

moderator

http://talk.maemo.org/

updated 2014-08-13 10:26:27 +0300

jiit

2678 ●32 ●58 ●59

admin

Have a setting to activate Multitasking on those apps needing it. (For the browser this is obsolete as soon as tabs do not reload per default anymore)

Give us a choice (setting) to have multiple windows of the same program - especially essential with communications where you often need to look at something else while composing a msg.

One way would be to have Composing windows separated form the main app with connected pulls (close-accept-send-whatever) returning to the main-app or invoking-app (sharing).

edit retag flag offensive close delete

Comments

@Milhouse requested multiple windows when composing SMS.

axaq ( 2014-01-28 20:17:22 +0300 )edit

I used an N9 and various WebOS devices and to be able to have more than one 'window' open for an app was a great feature. In WebOS I would have the message app card open and then cards for individual conversations; similar use was possible with the N9. I don't quite follow the technical discussion below but as a user I really value the feature.

I was surprised today when I stopped drafting an SMS, looked at an another existing SMS and found no draft waiting for me when I went back to the message draft I had left. I just took for granted that there would be a draft state.

Stuarty ( 2014-01-31 11:41:50 +0300 )edit

answered 2014-01-10 12:52:48 +0300

Robin Burchell _ w00t
1501 ●12 ●12 ●16

Without speaking about the design aspects of this, from a technical perspective there's at least one technical issue we'd need to get sorted out first.

Currently, applications have a single OpenGL context shared between windows, and this is kept persistently. This means you have a chunk of RAM sticking around as long as the application is open, sized depending on what sort of stuff the application is doing with the GPU.

In the future, hopefully, we'll be able to drop unused resources (technically, an application is two windows, not one: the cover, and the application, so we'd drop the main application's resources when it hits the background), in order to save these resources - meaning your device can do more without running into resource troubles.

To give you some idea of the impact this _can_ have, when we prototyped it a while ago, we were measuring around 5mb or so on average (peak was, iirc, 11mb for the gallery window) which is quite a bit when you have a bunch of windows involved.

edit flag offensive delete publish link

Comments

you could limit to one separated composing window by program - gallery is a bad example as I do not need any composing windows there... not even when sending stuff as this should open another programs composing window

chemist ( 2014-01-10 14:23:51 +0300 )edit

Is this the same as on the N9 (ignoring the meego graphicssystem stuff)? Don't you mean a "context for each window" instead of "a context shared between windows"?

If it's shared between windows then it would be cheap to let one process open multiple windows.

javispedro ( 2014-01-14 14:20:28 +0300 )edit

It's not the same (there's no software fallback), but similar in principle.

You don't want one context shared between windows, though that's the state of the current situation because:

that's not the path that upstream (i.e. Qt) have taken as of 5.2
it causes complications with Wayland (if a non-visible window causes a swap at the wrong time, your UI will block in eglSwapBuffers - we currently have a series of hacks/workarounds for precisely this problem, unfortunately)
it complicates resource saving measures, i.e. the current approach of dropping context on window hide is no longer possible, we'd need to write new code for that

In the future, we'll have a context per window (minimum of two: one for the cover window, one for the application) and drop the application's context when it goes to the background (window hidden) - but keep the cover context alive.

Robin Burchell _ w00t ( 2014-01-14 14:25:40 +0300 )edit

I failed to parse the upstream Qt part: does Qt favor the one context for each window model? Is there some blog post/docs on this btw?

javispedro ( 2014-01-14 18:48:42 +0300 )edit

"which is quite a bit when you have a bunch of windows involved. "

I think the best way to solve this would be to have the best of both worlds; make one window consolidating everything the default, and be able to split windows off (via pulley menu for instance). I don't care if I get a single random message in the consolidated view, but continous and longer conversations would be nice to single out into their own window/context.

fawz ( 2014-01-17 13:35:55 +0300 )edit

Real Multitasking for Composing-Apps (Mail SMS MMS IM Browser)

Comments

1 Answer

Comments

Question tools

Stats

Related questions

Real Multitasking for Composing-Apps (Mail SMS MMS IM Browser)

Comments

1 Answer

Comments

Question tools

Public thread

Stats

Related questions