Roadmap?

[patlecat]

Hi is there a roadmap for what you intend to do in the next 6 - 12 months? I would like to know if your project is going in a direction that I like or not.

The ties to Qt are of no interest to me, I use Qt directly if I need to. But I found QML to be an abomination rather than cool and useable. If your approach would not only be smarter, faster and better integrated and offering a wide range of GUI elements ready to use and easy to theme (unlike QML) then I would totally bet on your horse so to speak.

[saturn77]

Adding some comments to patlecat's question:

1. Embedded + PC support appears solid
2. Namely, Sixty is supporting embedded (at least with an embedded OS) pretty well as the moment, with more bare metal support anticipated. Support for the PC side is there and growing.
3. Portability between embedded and PCB
4. As an embedded developer, I've often been caught were I needed to port a GUI to a small display attached to a Xilinx Zynq or Intel FPGA A53 or even Nios, but couldn't quite get there with QML. While the Qt GUI runs fine on the PC, the customer ultimately wanted to be able to port it to the embedded device.
5. Licensing - I have had quite the issues with Qt for embedded, to understand the license model. I am trusting that Sixty can improve on this situation.

I think the Sixty roadmap to me appears to be embedded -> PC -> mobile in that order . . . . .

[tronical]

What @saturn77 wrote is quite accurate overall.
Note that our roadmap is flexible and we will prioritize what is requested from our users.
As it happens, we were ready first for embedded, and managed to get a customer in this area so that's why this area is currently more polished.
We are looking forward to get more users and we are eager to implement and polish what is needed for them.

On a more fine grained level there are core features to the toolkit, such as widgets, elements or model APIs. And the other kind of feature that's particularly interesting to us are APIs that enable users to integrate with other libraries/crates.

[tronical]

If you'd like you can look at our GitHub roadmap project at https://github.com/orgs/sixtyfpsui/projects/1 . This is meant to be flexible and priorities can change, depending on the needs of our users.

[PewPewPewLaser]

https://github.com/orgs/sixtyfpsui/projects/1

This link is broken, new link is https://github.com/orgs/slint-ui/projects/1

[nic-obert]

https://github.com/orgs/sixtyfpsui/projects/1

This link is broken, new link is https://github.com/orgs/slint-ui/projects/1

Link is broken now

[hunger]

I think the best we have left is the milestones in the issue tracker. We tend to be very agile, so things change a lot all the time.

[patlecat]

@tronical

• Mobile support is surely great to allow for x-platform development but isn't my main aim. Windows/Mac/Linux support is my main playing field, where i have to offer either server or end-user applications. So in Qt this would need the use of QtWidgets for complex GUIs, whereas QML never managed to go beyond simple mobile GUIs but was cumbersome to use.

• Also it is vital to have and retain full control within C++ to not complicate code further and scatter things around like in QML. I think the proxy code produced in 60 seems to go in the right direction to handle the boilerplate binding stuff. I would prefer if no logic is ever put into the scripts, but that they remain purely descriptive in a way similar to CSS.

• Also what about adding lots of professional and modern widgets ready to use? This is also crucial and has been 1 huge point that has been neglected by Qt in the pas 20 years. Their marketing is still bad.

Hope all that is the direction you're intending to go too?

[tronical]

Yes, the first two points resonate very well. Can you elaborate a bit on what you have in mind with the third point? Are you thinking of an easy way of sharing and reusing widgets (npm style)? Or do you mean more domain specific widgets? (Or both?;-)

[patlecat]

I am tempted to say the more the merrier :D But seriously, whatever you can do to provide lots of usable pro widgets will help 60 to be adapted by more devs and companies.

• 1 way (at the beginning) is to provide lots you made yourself and provide well documented examples on how to create more
• Offer a marketplace for OS widgets to be offered by anyone, but also paid widgets by companies, those should be easily integrable into my code. Best would be with no manual configurations needed.
• An application should also be easily theme-able, that's really crucial. Like widgets should by default take appearances from a theme config file. Don't make it hard to theme, because that's what no GUI framework offers today, nor makes it easy to do.
• A SFX utility lib would also be fine to be included into the standard runtime lib. So we can use effects like glow, blur etc. easily and know that they work on all widgets reliably
• An animation utility lib would also be fine for modern GUIs, since desktop UIs are now heavily influenced by web UIs and not the other way around anymore. So we need to adopt and adapt new things quickly to stay attractive and stand out of the crowd.

What do you mean with: "domain specific widgets", what domains?
I like Juce-UI but it's also too restricted in those points and more useable for companies who have only 1 product and want to spend months customizing it, creating lots of custom widgets. But for consultants who work on projects for just a few months, this is not feasible.

[patlecat]

Please let me know if I can help more with this.