if that is what is needed to finally leave behind the comfort blanket of QT 5.6 licensing then let’s do it!
upgrading to a modern and open framework would be better?
5 Likes
I also thought about KDE Kirigami a lot. I do love the Jolla Silicia UI, but the QT version is so heavily outdated. I do not have much experience with QT or KDE Kirigami itself, but maybe it is possible to apply the Jolla UI into the framework itself, or atleast forking it. We do need an updated developer experience to get more dev’s involved.
3 Likes
Using Kirigami or similar would remove the need for jolla to manage silica. Anything that could free up resources at jolla should be considered.
3 Likes
“Just replace one framework with another” is such a useless position to hold - it doesn’t address any of the obvious concerns. What about current design paradigms? What about migration of current apps? What about all current UX in general?
From what i can tell Kirigami is the usual desktop-y point-and-click. SFOS uses gestures to great advantage.
15 Likes
I don’t think this thread is a forced replacement. It is a discussion about options we do have to get rid of the old qt5 versions. I think it is worth to take a discussion.
As mentioned, I do love the Jolla Silicia UI, but i do not see any progress here from Jolla. Maybe I have missed it.
You addressed good points, which would probably be valid for every upgrade option (upgrade, migration, ux)
I am not an expert of QT, but as mentioned in the kirigami docs, it is using QtQuick Controls 2 and this have been developed on focus touch components:
Qt Quick Controls was originally written with touch interfaces as the primary focus. While it is already possible to develop desktop interfaces, work is ongoing to provide a more native look and feel.
2 Likes
There were! First, Jolla is independent again. Now the are thinking about providing 2 versions of Silica. One closed-source and one open-source for the community with an upgraded version of Qt. See this comment for further information: Android Enshittification process -> Let's promote Sailfish OS - #31 by JoshStrobl
8 Likes
I wonder how many sales would be necessary to make a commercial qt license a possible option
My understanding is, that to sell devices with software built on top of Qt, you need something better than the most basic of licenses. Pure guess with no background in the licensing business, but I doubt you can get one for less than 5k-10k€ per developer per year, and then you’ll probably still have to pay a couple of euros for each device sold.
Would it be possible to circumvent the need for a commercial license by splitting SFOS into parts, where one part contains only the bare minimum core parts of the OS with new Qt, and the licenses of the included parts would not cause problems with Qt’s open license? Users could then port any Framework they wanted to this free core part, or obtain the rest of the SFOS, including Silica UI, as part of the SFOS trial/paid license.
In my job I have been working with Qt6 for a long time. Being forced to use Qt 5.6 for SFOS app development lost my interest for writing apps. I have therefore been waiting (for years) for Jolla to decide how to handle Silica + Qt6. Earlier this year I got tired and started looking into Silica myself.
I have since then started porting Silica to Qt6. I have ported many of the BSD licensed qml files and reverse engineered some closed source logic (i.e. guessed how it should work). Basic functionality is (mostly) working now (i.e. PageStack/Pages, Pushup/Pulldown menus, Buttons, Icons, ComboBoxes, ContextMenus etc). There is however a lot work left to get it usable. Given that parts of Silica is closed source the port will likely never be feature complete but it should give Silica look and feel for Qt6 development.
Note that I have not discussed this with Jolla so there may be licensing issues preventing this from being released even though I only have reused BSD licensed qml files.
My main reasons for this were:
- Use Silica functionality for app development in Qt6
- Do app development by compiling directly for linux instead of cross compiling (development is a lot more fun when compiling is faster)
26 Likes
This is only a discussion, we all want the same thing; Sailfish and Jolla to succeed.
Sailfish is a niche within a niche, attracting developers to come and write applications and maintain the OS for free is always going to be a struggle. Being part of a bigger community would have benefits.
Kirigami is well established and maintained outside of Jolla, plasma mobile has a large community and lot of existing applications.
If a single company goes away the apps can be used on other platforms. The applications work across Linux mobile, Android and desktop.
The next Jolla phone might support USB-C video; enabling convergence where the phone would become a desktop environment when plugged into a keyboard, mouse and monitor. Silica doesn’t support desktop usage, with much of the UX being touch only. Convergence / scaleable applications are already provided by Kirigami.
With the stores (Jolla, CHUM and Openrepo) it is the exception when an application is maintained, many no longer install or work. Forcing an upgrade might clean up.
Plasma mobile provides Kwin a modern compositor, this is an area SFOS that needs attention.
Plasma mobile provides an up to date browser, another area of SFOS that needs attention.
Plasma mobile provides a gesture only mode that is similar to SFOS.
Jolla has value to offer through the AppSupport and Sailjail.
2 Likes
Is this work published somewhere?
No, not yet. It is not ready to be released yet. I originally intended to wait mentioning this until it was more complete but since there were discussions here about upgrading Silica I decided to mention it to avoid someone starting redoing the same work that I have done so far.
9 Likes
Aha, i see your line of reasoning - you are mixing in some undeclared wishful stuff.
My current SFOS phone supports USB-C video, and i have no chance of getting video-out from it anyway.
I have literally never heard anyone use Samsung DeX. I don’t believe in convergence. Tho devices - one of which is a lot more powerful - is not an issue to me. I do rather different things on the phone and on a full computer.
Sharing effort with the wider Qt/KDE ecosystem is a good idea - but it really takes a lot more care than “just switch and all will be good”.
You can already install e.g. Angelfish with the optional Qt6. (Same for general KDE apps, no?)
Basing on Firefox and making a fully native experience is a deliberate choice. Maybe it didn’t age great, but it was a good one for a long time. And if we can stay off the Chrome doom-train, i wouldn’t mind.
Got any links? I’m not finding it.
4 Likes
2 posts were split to a new topic: Dex and Sailfish
Can’t wait to try it! I have the same idea in my head for long time, but there was always something more important to do 
It don’t have to be feature complete, remember famous quote: “If you’re not embarrassed by the first version of your product, you’ve launched too late.”
It would be great to have Silica UI for local development or available for Nemo Mobile or even Android…
8 Likes
I have always been embarrassed. Thanks for the quote to continue on my track 
1 Like
I for one as a maintainer of a number of apps have a deep and abiding dislike of most kde libraries. Without getting into details, I have re-encountered some of that disliked code while doing bits on the QT5.1.5 chum effort and recently while looking at the state of the QT6 effort on chum. That is mostly contemporary kde efforts. I would be very unhappy to be ‘stuck’ with ktrip as my option for travel planning. It’s not code I’d like to work on.
On the other hand, the plasma/kirigami stuff is there NOW in the 5.1.5 and initial QT6 porting that @rinigus and @piggz have spearheaded. So, I wonder what the point is? I want Silica and if you will, there are means to get plasma apps running on SFOS now.
Open sourcing Silica under the GPLv3 is a very good solution, too
6 Likes
both as a user and as a developer, I’d vote for spending additional time/resources (if they exist) on adding new functionality and/or fixing bugs within qt 5.6 limits rather then porting the existing functionality/bugs to qt6 (and introducing new bugs in the process) 
6 Likes
As far as I understand it, this is the real solution:
keeping silica as ‘secret sauce’ on QT 5.6 (where the licensing permitted this), might have seemed like a bright idea at the time, now however i think it’s clear that it’s holding back the entire SFOS ecosystem.
6 Likes