Ubuntu UI Toolkit - who would join me if I tried to move it to QQC?
Disclaimer: I have not yet decided to start this at all, as alone I will have neither enough time nor skills to develop it. However, if a few more people joined, it might be possible to happen. Even in that case not in the nearest future.
I'm thinking about rebooting the UITK. However, my time and Qt skills are not sufficient to develop and maintain the project alone. I'm sharing my vision though to ask if there are any people which would be interested in joining - in that case maybe it would be possible to start indeed.
Vision - meet Suru UI
I think that calling what I would like to achieve a toolkit is a bit overkill, the reasons will be explained in this post. Also it would be no more tied to Ubuntu. I believe Suru name is good though - it's a design language that I would like to continue.
Qt Qucik Controls
That the toolkit should be rewritten - but not from scratch. Qt Quick Controls should be took as a base. On this two new modules should be build - modules that are independent from Ubuntu and can be used seperately as well as both together.
The first part of the jigsaw would be the QQC Suru style. I would like to strictly follow the designs created by Canonical and recreate a look and feel they intended to create with UITK - including color pallette, Ubuntu font-based shapes, etc.
However, I would not like to mimic what we currently have on Ubuntu phones - insted I wish to look ahead and follow the design guidelines which hadn't materialized before Ubuntu phones have been axed.
The reference is here: Ubuntu App design guidelines contains much detailed information and lots of mockups packed with it. Mockups depict a popup menus, radio buttons, new styling for buttons and more. This is the style I would like to strictly follow.
The other part would be Suru Controls. Its goal is to provide an extra set of controls that cover the UITK's convergent functionalities - bottom edge, swipable list items, adaptive page layout, headers with actions etc. The controls should be style-agnostic and - if possible - ready to be used with whichever Qt style (however using them with other styles is less important than functionality).
Suru Controls should be based on QQC 1.x - QQC 2 are not available in Qt 5.4, which is currently used on phones. If the version was bumped someday, Suru Controls should be moved too.
Well, for whatever. Someday Suru UI could be adopted by core apps (if they find maintainers), Yunit... but also many other third party developers who currently stay away from UITK because it is not portable.
What would be the plan?
- Estabilish the development: gather developers, mockups, guidelines, create repository, GitWhatever project etc.
- Create Suru Style at first and make it cover the controls available in standard QQC.
- Create the additional controls. Move one or two smaller core apps to Suru UI to be able test on them.
- After the functionality is in place, we can think what more can we to achieve even better convergence experience - new designs, controls etc. But still with respect to the current UITK concepts - rather to enrich them not to replace them.
As I said before. It's a thing I would like to do, but my time and Qt experience are very, very limited - and even if the team managed to be created, I probably wouldn't be the most active developer in it. I am posting this though to share the vision and look around if there are any people here willing to join forces.
@sverzegnassi can maybe help you kick ass xD
@Mitu, "suru" or "zuru" is slang for "turd" in Spanish.
It comes from "zurullo".
It's better you know it before it's too late.
Ah, OK. Good to know - actually the name is the least problem here and can discussed/changed of course. Canonical did use it though (and probably someone knew the Spanish meaning there), so maybe there will be no need. We'll see later if any developers willing to help appear.
@Mitu, on the other hand you're idea is amazing.
@advocatux Was chosen by Canonical, didnt they got any Spanish guys on board xD
@advocatux Nah. That is too picky. I've never heard of «suru» to reference «zurullo».
I'm in. If I can help
@CiberSheep, maybe is not slang in the whole country but I've heard it in certain places like Andalusia.
@advocatux I would not worry at all. Not even a second about being «missunderstood» or laught at
Qt Quick Controls should be took as a base.
Why not kirigami?
I was actually hoping to investigate that option in Yunit sometime in the future.
Yes, I know about Kirigami, haven't investigated it though. It raises a few questions:
- How themable is it? Would it be possible to style it to look exactly like Ubuntu UI toolkit looks now?
- Does it depend on KDE libraries? I'd like to avoid it with Suru Controls and depend only on pure Qt.
- How are its concepts close to Ubuntu's UI Toolkit? On the screenshots I can see headers, something that seems to look like adaptive page layout... would it be possible to add bottom edge components, list items swipable to both directions (left & right), context menus etc.? How extendable would Kirigami be?
If Kirigami could let achieve the goals I mentioned above, it could make a good base - however I'm not convinced yet. It's like extending an extension and it would make Suru dependent on yet another project. Some of the Kirigami navigaion concepts differ from UITK - could those moved from UITK coexist with them or replace them in those places where you used Suru's components instead of Kirigami's and blend well with the rest? Personally I prefer to depend on as little things as possible (and reasonable).
Sure, there is a possibility to use Kirigami as is or just create a Suru style for it - but this is not the goal I described and would like to achieve - to fulfill not only the Suru visuals, but also its design language and navigation concepts.
@CiberSheep, yeah it's definitely better "grief" in Finnish than "turd" in Spanish hahaha
I'm afraid that now we re the official «offtopic-ers»
@jsalatas I can really see the reasons why you're interested in Kirigami, it's a fast evolving project and embraces convergence. Since - that's what I understood - they will keep the same public APIs between version 1.0 and 2.0, Kirigami could make your life easier, since you could start using it now and be confident that your shell will support QQC2 in future (Kirigami 2 is based on QQC2 as well).
Anyway, I guess what @Mitu proposed here is in no way affiliated to UBports. I've been trying to port the Suru design to QQC2, and I'd honestly prefer as well to be fully indipendent on this, at least at first.
I don't know how Kirigami 2 will actually work but, if it will support the QQC2 styling framework, there might be some chance that a Suru theme would be equally supported.
i stumbled over this topic again after reading it with great interest when it was opened and now the team has forked UITK-1 (for documenting purposes i think) so i thought maybe it is time to talk about it again?
As far as i have seen it (yes i was stalking your github stefano ;-P) stefano has already begun with the project here, if you are still interested Mitu, maybe you can participate in the effort? I would like to help but cannot do much except perhaps gather info and trying to bring people with skills together (qed ;-)).
I also don't know whether this is old news for you but Canonical seems to have been working on the UITK-2, based on QQC2, maybe there are some things there that can be recycled?
Any news about this thread?
I think @sverzegnassi has been working on the Suru style for QQC for some time. Would you share some information on what the status is and if anything has been done not only to style, but also SDK components (bottom edge, headers, swipeable list items etc.)?
I decided not to take up any work in it currently and focus on an idea that might someday evolve into a decent app. I'll not shere more information though, as there is still a long way ahead and the entire thing is uncertain.
But if the app will approach to materialization, I'll definitely consider implementing in QQC2 (if Suru style and component set is in good shape enough by this time), and maybe help out with the SDK in that time.