In around an hour I leave for the airport to attend Qt Developer Days in California, USA. It's been largely coordinated by the good people at ICS and KDAB and so far it seems they've done a remarkable job of it. ICS has even stepped in to offer travel support for some of the attendees, myself included, which is greatly appreciated.
I'll be presenting on a couple of topics at this Dev Days: open devices and writing full-blown applications with QML. The first topic will consist of a panel discussion as well as a BoF and I'll be doing my best to increase awareness of Plasma Active and what we've been building on top of Qt there. The presentation on complex applications written with QML is a bit more standard fare. In sharing some of the big lessons we've learned in the last two years when it comes to using QML seriously, my hope is that those in attendance can lower the learning curve, avoid common mistakes and think about new sets of best practices around QML.
Something that really excites me about QML is not only is it fast to work with and delivers great results, but it introduces a new paradigm into the Qt world while not introducing a lot of the high-level things required to actually write applications. This means the door is open for exploring new ways of doing things with an eye to better results. QML often gets set next to QWidget, but I don't think that's entirely accurate: QWidget is a tool that sits well and firmly within an existing language framework (i.e. C++) and provides a lot of pre-defined mechanism. There are a ton of useful UI bits written as QWidget subclasses and it is extremely well tested and proven by now, which gives it tremendous value, but QML allows us to break the molds that have tethered us to inflexible interfaces.
Breaking molds is not always a good thing, and I was healthily skeptical about what kind of results we'd get with QML. By taking it one step at a time, something Plasma's design allows us to do, we've found that we can replace QWidget based interfaces without our users noticing anything (other than it feels smoother :) as well as create sophisticated interfaces with easy which we would have truly struggled to deliver with QWidget. The new QML applications we've been writing for Plasma Active showcase this effectively, and I'll be expanding on these topics in my presentation at Dev Days.
Before leaving this morning, though, I updated the integration branch in plasma-mobile. This is something new we're trying out, following an ambition some of us have held for a few years now: a never frozen master branch. The idea is that all new development will happen in branches which are then folded into an integration when they are ready for it (according to the developer maintaining that branch). Testing will happen using the integration branch and when new features and bug fixes pass that testing (automated and manual) then the branches they are in will be merged into master when it is not in a release freeze. The goal is to keep master in a releasable state at all times, while also allowing developers to work on code on their own schedule. This decouples release engineering and development, allowing both to achieve their respective goals without getting in each other's way.
There are other projects that do this already, but it's a fairly new workflow within KDE and we're prototyping it, if you will, in the sandbox of plasma-mobile. We'll see how it works out over the next half year and then report back to the community what we've found. I'm optimistic that it will work well and that we will be able to recommend this to the wider KDE community, particularly for important shared components like Frameworks 5 where stability and development ease both need to be nurtured.
I'll be presenting on a couple of topics at this Dev Days: open devices and writing full-blown applications with QML. The first topic will consist of a panel discussion as well as a BoF and I'll be doing my best to increase awareness of Plasma Active and what we've been building on top of Qt there. The presentation on complex applications written with QML is a bit more standard fare. In sharing some of the big lessons we've learned in the last two years when it comes to using QML seriously, my hope is that those in attendance can lower the learning curve, avoid common mistakes and think about new sets of best practices around QML.
Something that really excites me about QML is not only is it fast to work with and delivers great results, but it introduces a new paradigm into the Qt world while not introducing a lot of the high-level things required to actually write applications. This means the door is open for exploring new ways of doing things with an eye to better results. QML often gets set next to QWidget, but I don't think that's entirely accurate: QWidget is a tool that sits well and firmly within an existing language framework (i.e. C++) and provides a lot of pre-defined mechanism. There are a ton of useful UI bits written as QWidget subclasses and it is extremely well tested and proven by now, which gives it tremendous value, but QML allows us to break the molds that have tethered us to inflexible interfaces.
Breaking molds is not always a good thing, and I was healthily skeptical about what kind of results we'd get with QML. By taking it one step at a time, something Plasma's design allows us to do, we've found that we can replace QWidget based interfaces without our users noticing anything (other than it feels smoother :) as well as create sophisticated interfaces with easy which we would have truly struggled to deliver with QWidget. The new QML applications we've been writing for Plasma Active showcase this effectively, and I'll be expanding on these topics in my presentation at Dev Days.
Before leaving this morning, though, I updated the integration branch in plasma-mobile. This is something new we're trying out, following an ambition some of us have held for a few years now: a never frozen master branch. The idea is that all new development will happen in branches which are then folded into an integration when they are ready for it (according to the developer maintaining that branch). Testing will happen using the integration branch and when new features and bug fixes pass that testing (automated and manual) then the branches they are in will be merged into master when it is not in a release freeze. The goal is to keep master in a releasable state at all times, while also allowing developers to work on code on their own schedule. This decouples release engineering and development, allowing both to achieve their respective goals without getting in each other's way.
There are other projects that do this already, but it's a fairly new workflow within KDE and we're prototyping it, if you will, in the sandbox of plasma-mobile. We'll see how it works out over the next half year and then report back to the community what we've found. I'm optimistic that it will work well and that we will be able to recommend this to the wider KDE community, particularly for important shared components like Frameworks 5 where stability and development ease both need to be nurtured.
