"Daily Driver" package for essential tweaks, device specifics etc

Devices
#1

Hi folks,

I was thinking about how we could better support the particulars of each device + address some of the behaviours of SFOS that have become a bit long in the tooth.

Basically fork off and package up the best patches, tweaks and services that are scattered across OpenRepos, this forum and elsewhere into a single (or 2, i’ll get to that in a second) RPM package that can be installed by users of a specific device, with the goal of making Sailfish as daily drivable on that device.

Given the most recent addition to my SF device stable is a Xperia 10 II (and the device I’m daily driving as my work phone, running paid X), I’m going to get the ball rolling here with specifics around that device.

Now there are going to be QOL tweaks and package that are applicable to all devices and maybe there should be a “Daily Driver” base package that includes the common tweaks with an additional “Daily Driver X device” package that if installed pulls in the base changes + the device specific ones.

Anywho, I’m hoping to A) crowdsource a list of common tweaks, patches and services and B) hardware specific ones (for the 10 II).

With any luck we can create a thread / device with a dedicated and maintained package on OpenRepos as the output.

Examples of the sorts of things I’m hoping for here…

Common:

  • Disable the lock screen animations: mcetool --set-lockscreen-animation=disabled
  • Swapping out the default weather app, daemon and event view with MeeCast by default (packages on OpenRepo for this, 3 in total)
  • Reduce animation durations (Haven’t seen anything on this but we can all agree, the animation are all painfully slow)
  • Disable swipe carousel between the task switcher and event view. Package for this on OpenRepos.
  • I get why the gestures were designed with one handed use in mind, but having a “traditional” gesture setup that aligns itself with Android and iOS (without losing thet SFOS “magic”) might be a better default. We could collectively decide on what a “better” default gesture setup looks like in 2024.
  • Any other common packages you run and think are essential.

10 II Specific:

Etc.

Feel free to shout at me if you think this idea is silly or to discuss if you want to tease it out further but if you could be so kind,

When making a suggestion for an inclusion into either category, could you include whether it’s a generic (“common”) improvement or a “device specific” one and link to any resource, source, GitHub, OpenRepos link, patch file/service/script etc available.

Curious to hear everyone’s thoughts!

EDIT: Notes

Git repo for packages gathered: GitHub - patrickjquinn/sfos-dd-x10II: Collection of packages and scripts to smoothen out the process of daily driving Sailfish X on the Xperia 10 II

Patches:

1 Like
#2

Regarding the animation speed: there is a patch in patch manager to alter this to the users wishes, but it stopped to work, I think with update 4.3. It might be possible to revive this.

#3

Would you happen to have a link? I can create a notes section down the bottom that captures stuff like that. + and GitHub as a working space.

A lot of patches I’ve run into (and that have been referenced above seem to be incompatible with either the latest version of SFOS, aarch64 or are just unmaintained.

That seems like a good start for sure.

#4

https://coderus.openrepos.net/pm2/project/animation-settings

1 Like
#5

Thanks David,

Update the original post with the repo and added a GitHub link for everything captured going forward.

#6

First things first: i completely disagree that anything is essential to make any of the supported models a good daily driver. I haven’t even looked at patches since the calendar app started remembering that i want notifications by default back in the 1.X days.

Calling gestures that were invented much later, likely inspired by SFOS/Meego, “traditional” is a bit rich. But on the other hand, i’ll be the first to argue that the Windows-style keyboard shortcuts (plus organic evolution over the years) is far superior to Unix/Emacs/whatever.

Though bear in mind that lots of people here will have no idea what the gestures look like in Android/iOS, because we actually have been daily-driving SFOS. All i really know is that they’ve had to compromise to not conflict with legacy app design (as opposed to having had them from the beginning).

Are you saying we are missing out? What do they do better? (Or is it just your muscle-memory?)

You say one-handed like it is a bad thing. What would characterize a “two-handed” gesture - and why is it better?

5 Likes
#7

Just opionions: As I’ve recently had to revive a phone (android) for my son, I can assure everyone that neither android, nor IOS have done anything to improve gestures in the UI/UX recently.

the only ‘default’ that I find tolerable is the SFOS/ meego style. My maemo N900 was different, to be sure, but much more a desktop in the pocket and much less the touch type interface we have today. Every time I look a games ui (slowly working on a next game for sfos) the peculiar and interesting bits of designing for multiple finger drag gestures (with vectors in n dimensions) eat up all my time. I find it astounding that in the last 15 years so little has happened. Perhaps with the exception of games.

4 Likes
#8

I think people are reading my suggestion as an attack and specifically hyper focusing on my comments re: gestures.

For context sailfish has historically gotten gestures right. Switching and killing apps is the only area I view as needing some work, especially on massive screens which weren’t thing on phones when Jolla designed those gesture patterns.

That’s all I was saying in that small segment of the above.

Also, “traditional” gesture patterns in modern OSes do indeed borrow from sailfish but more heavily cog off the work done by the Palm team’s work on WebOS. WebOS (from an academic usability standpoint and from experience) nailed the app switch and kill model hence why it’s become the standard.

The rest (and majority) of what I was saying, is hardware specific support for things like AGPS being borked for example on this decide (the Xperia 10 II), background blur causing massive frame rate drops when switching apps, weather and the weather event view being FUBAR etc. all of these device specific quirks can be addressed with some device specific patching.

Most supported and community port devices have their own need for tailoring that could be addressed in the manner I’ve described above. The core team are most likely lacking the bandwidth to support and maintain each device to the levels they did with the 1 and C back in the day given everything, which is where we the community can help out (given the vested interest we have in the devices we daily drive.)

Lastly, I bought the Meego n9 day 1, bought the Jolla Phone day 1, have bought 3 X licenses across 3 devices, bought a Gemini at the first murmur of sailfish support and rotate between Ubport, Phosh, Sailfish, Android and iOS so no, it’s not muscle memory and no, I don’t hate the way Sailfish works, quite the opposite.

1 Like
#9

You misunderstand. I wanted to prompt you to explain fully what the problem and/or room for improvement consists of.

People have different preferences, so that everyone would have come to the same conclusions on what should be changed is basically impossible. Though, people agreeing on certain things after a good motivation has a much higher probability of success.

I count 5 common and 3 specific suggestions.

The reason i went for touch was that the could be something there, which i did not know.

Let’s pick on another thing then:

Why on earth would you do that? Sure it only needs to go one way, but people use the phone with alternating hands and having both is probably ergonomic for that. And unless it is done in favor of something else, what would the benefit be?

1 Like
#10

I don’t agree with this. You mean the animated float of N number of apps with swipe away to kill? I often have to help older users. I explain to them, use this gesture to bring up a carousel view of all the ‘running’ apps (that I need to explain). Now swipe these away to get some resources back. With more modern high ram devices this has become less of a thing, but I know a lot of older people who just don’t see how it works. On sfos, you have a flat view and X. I have to admit I’m a user that rarely has more than 4 or 5 apps running (usually 2) and am in the habit of closing things. But, It’s not like I’ve done testing beyond the tech support for the 70+ set recently :slight_smile:

1 Like
#11

To be truthful your comments on the carousel package are fair. My intention was to provide examples of behaviors that make more sense on the large screen devices that tend to be the standard but this is a poor example.

I really just want to spark conversations around the biggest gripes most people have that could be fixed through patching. Both across the board (whatever they may be if there is even any big ones) and on this xperia 10 II specially (or which i know there are many given im grappling with them now).

If it transpires the base platform is fine for most people then I can shift focus squarely to device nostic changes.

If we narrow the conversation around common stuff to ‘its good but it could be great, what does great look like in 2024?’ that might be a better dialog here.

And obviously we can still highlight the issues people are facing with 10 II so we can figure out how to go about addressing those/create a template for other devices.

Again TLDR; sorry if I came across as hostile, the idea is to collect gripes, potential fixes with the goal of bundling them up and maintaining them across subsequent SFOS versions with the potential of getting the changes upstreamed (thanks to the IRC for the final line of reasoning there).

1 Like
#12

Endless bikeshedding commences. As this thread already proves. :popcorn:

1 Like
#13

Ultimately I’ll be deciding whats probably best for most people as i’ll be maintaining. You can’t please everyone but you need to at least ask their thoughts on the subject before acting unilaterally :slight_smile:

#14

I have called for this before.

  • Storeman – absolute necessity even if @attah disagrees.
  • Nephros’ Edge Swipe – I have mine at 100px.
  • Advanced Camera.
1 Like
#15

Havent checked out Advanced Camera but will do so now.

Have Nephors Edge Swipe set up here, it’s good, still trying to find the right default value for to be used in a dedicated patch.

On the 10 II i’m using Nephors Pure Black backgrounds patch as A) this is an OLED screen, so why not have only the pixels we need on and B) it’s fixed the stutter I was seeing when app switching, open the app grid etc. It’s nearly locked at 60fps now so i’m 100% including that as default in this package for the 10 II.

3 Likes
#16

Also your point to disable the carousel between witcher and home screen is conviniently solved by a patch, and this one is even in a working state:
https://coderus.openrepos.net/pm2/project/sfos-patch-homescreen-no-carousel

thinking about it, I doubt there is an advantage in packaging these for open repos over pulling them from patch manager web catalogue individually (and only those you really wnat to have)

#17

Yep, have that running too! big improvement as I’ve always found the carrousel confusing and unintuitive (but this may just be me).

2 reasons I’d fork and package, 1 is OSv compat. A lot of pacakges that i’ve found that could be potentially useful have drifted out of compatibility. Mostly because they’re not being actively maintained. And 2 is discoverability, having to do this level of research to figure what as a new user i’m likey to need to improve the experience on my specific device is not ideal.

This way you can simply search your device in Storeman and go. Anything you want to disable can be done via Patchmanager.

The 2 distribution options are, a repo for each device with specific patches and packages with one master bookmark package that has dependencies on other packages or a mega package which applies everything you’re likely to need and is required for smooth operation (required meaning that transparency patch previously mentioned etc) in a single shot. Not sure which is best quite yet.

2 Likes
#18

Regarding patches and the “compatibility” field in Patchmanager: all my patches are compatible with the latest SFOS version (4…24) but they are only marked as compatible up to the last version (4…15). That’s simply because re-uploading tons of patches manually is a pain, and it’s not worth it to only fix that field. I assume it’s the same for other patch authors.

I for one always appreciate if people drop me a line if a patch actually becomes incompatible :slight_smile: .

Instead of forking patches and stuff, I would recommend to go this route. Most things are available as RPMs, and patches from the web catalog could be installed in the post-install RPM scriptlet. It also saves you the trouble to get attributions and licensing right.

1 Like
#19

Yep i’m heavily leaning towards doing this with the bookmark approach to be honest!

1 Like