Please don't limit cover actions to one in SailfishOS 2.0 [answered]

@Christian Emlek i understand what you mean. but i think that not so fair against jolla-team, if you force them to go, if you are not satisfied. You know, they make a lots of effort to listen to the community. There is some people where the swipe is complete unnatural (not me, i love the swipe). I find their decision normal. And the good way on our side, if we are against it, is to tell it (what you do...right), but in a constructive way. We have understand, that really important for you. But why not present a suggestion. I have one, and i'll present it in a thread, then. Hope that you could participate on it.

here

exactly Christian, yesterday i borrowed jolla to totally non-pc oriented guy, i only show him how to swipe to home screen or close app and how coverpages works. he said omg thats superfantastic and addictive! that will be my next phone.

swipes made sailfish OS Unlike, but sadly, android or ios users pushes their (devs,bosses...) ideas to that way of some buttons and focusing on the operation instead of doing same thing but fast and on blind ,

why dont you implement Home button, be more like others and then get more customers??? huh pretty Unlike style

Yes, after seeing the video I can definitely see why they are removing the second cover action from the stock applications. Pheraps it would be a good idea to keep two cover actions but having them activated via an up/down swipe (that will not clash with the lockscreen or the application drawer anymore).

@ossi1967 perhaps that some people have wider finger, and with the capacitive aura or the finger activity zone on tablet is so wide that it could not give the place for 2 near of each other.

I understand that jolla think on those people. that great. But, there is other people who are skilled on the swipe gesture of it.
It is not natural for new users, that's right. But it is so practicable.
I think it should be a compromise of it. The cover-action as tapping should be the default possibility. But an option should be as swiping, if user want it.
Would be nice that Jolla-dev not forget, what the user want. I am sure that a lots of people want a tap, but i am sure too that a lot of users want a swipe.

This is the reason behind changing it to a tap: https://twitter.com/JaakkoRoppola/status/572442402612518913

I still don't get why they are removing the second one, but I think that this change (tapping) is most unfortunate - it will be very confusing, having to tap on a certain part on the app cover to open the app, without triggering an action. Especially for new users...

I understand the thinking behind this change, but I don't like it at all. As stated before, in my opinion the cover swipe action is one of the best elements of Sailfish UI...

Furthermore, one action is not enough. E.g. I like the cover actions Tweetian uses and wouldn't know which to discard. Furthermore some cover actions trigger something (e.g. refreshing) without opening the app.

@mikelima i agree with you that is not possible to make some fast conclusion for the end version of the os. as you said, maybe there will be a new handle design, or the end-design was not really completed, and an other way is found for having it. who knows.

but i agree that the action in could make some reactions. and i think this thread is not bad. That's great that g7 was aware of it, and put it on front. Then maybe we will know more about the plan that currently work (i hope).

The comment is for the whole CoverActionList. Source code can't be interpreted differently, it just does what you tell it to do.

The CoverActions in Silica are wrapped inside a CoverActionList. In the browser's case, there is a CoverActionList with inside the add new tab and refresh actions.

With the commit mentioned in the OP, they inserted a new CoverActionList with only the Add New Tab action that is enabled only when the SailfishOS version is 2.0 or greater.

The comment they put is only to remind them to remove the older list with both the actions (the one we have in SailfishOS 1.x) once SailfishOS 2.0 is released.

This leads me to believe that the change is not for technical reasons, but for design ones.

I understand more or less what you mean, maybe you have right. That's clear what the code means, i understand it in this way too. But it doesn't really reveal what is it planed for the long term. Software Requirement are not published. I still give it for a solution before release.

And sorry, but a not really documented comment at this level of code, which bring just confusion for people who are not in dev-team, has nothing to do inside. maybe i'm wrong, I refer just to some coding "codex" that i use in my environment. Definitively i would not do this, in the way of the coding line that i know...

Please don't forget that the os is on dev. Could you tell me what is motivation to activate a code, depends on the software version? The code is for os v2.0 and more, but will never to stay at v1.x. If it should disappear, then better is completely to delete the code, instead of produce dead-code to activated/deactivated on demand. If this type of coding appears in lots of part of source-code, it take a lots of place, and resource for nothing (that's my thinking). The code make for me a nonsense. That's why is for me not definitive. but i can't be 100% sure. human are so unpredictable!! ;-)

That is good that the vote still goes up, so that some people will be aware. and let us see what does the jolla-men in charge will answer.
maybe it could be an other design type that it need it.
I am curious on how will this theme evolve....

There is a version check because that code will probably be used in update12 and update13 (and I'm assuming here that SailfishOS 2.0 is update14, but it's only a guess), which are still SailfishOS 1.x.

They will remove the old CoverActionList on SailfishOS 2.0 simply because the browser on older updates won't be updated anymore.

@g7 you told: "...They will remove the old CoverActionList on SailfishOS 2.0 simply because the browser on older updates won't be updated anymore."
Where or what are your sources? you seems to be really good informed...

I disagree with this. A widget like seen on e.g. N900 is something that is permanently visible to the user. Like maybe the upcoming changes for home screen. There you can place a widget like weather forecast you name it.

An application cover opens once the app has been launched. Therefor the cover on the current running applications grid is just fine to have coveractions with it. Limiting actions will reduce smart behaviour if there is no other alternative ui voodoo coming.

I don't mind widgets at all.. and i hope it is added at some point, but something more contextual and temporary is also really nice imho. Cover actions are a good way to achieve this, and two is a nice non-confusing, rather fail-safe number.

@Nekron: Widgets on the N900 (or on Android) are already tied to a concept of a multiple-screen desktop; so, the widgets are in fact not permanently visible (unless the user only uses one screen for their desktop). Nor are they visible when a normal-sized app is running; nor when the screen is locked or dark. In short, I think users of cellphones that do have widgets are already comfortable with the idea that they have to do something to make a widget visible. :)

The "cover actions" concept provides some of the functionality of a widget, but at a cost: very few controls can be provided to each app, and they must all work in exactly the same way. Providing a full-fledged widget interface would provide a great deal more flexibility for certain apps that work well as a widget (weather, music player, etc.), and allow users to access these controls from a fixed location in the UI (as has been asked in other TJC questions).

@Copernicus: I strongly disagree - to me the active covers are the most interesting and unique part of the whole Sailfish UI. And for me it's perfect to have the two actions - swiping left and right - for each app. E.g. in music player, it is actually easier and faster to pause or switch to next song using the cover action than hitting the button in the main app's UI (driving in my car, I can find the app cover with my thumb and swipe "almost" without looking, while it takes half a second of my concentration to locate the "pause" button and hit it (since it is smaller).

@casanunda: I will concede that the active covers are indeed "interesting" and "unique", but I just don't find them a worthy replacement for widgets. There are many widgets where just a few more controls would make a lot of difference; for example, a media player with three controls (previous, play/pause, next), or even better, five controls (previous, rewind, play/pause, fast-forward, next) can make managing media a whole lot easier. Also, if you're going to interact with the app, a miniature view of what the app looks like on the full screen is not terribly useful; it's easy to recognize the app (which is useful when managing running apps), but too small to easily see the details.

Managing apps and interacting with apps are different tasks, with different requirements. I would just like to keep the two separate. :)