Some weeks ago I ran a poll to see what would be the preferred rendering engine for Fiber, and so I figure now is the time to post results. There was a surprising amount of misinformation/confusion running around about what each option potentially meant which I hope to clear up, but overall the results were so compelling I doubt stripping the misinformation and re-running the poll would return a different result.

Third Place: Port to CEF Later

“Porting to CEF later” was the lowest voted option at ~18% of the ballet, and in retrospect it makes sense since it’s just a poor solution. The only upside is that it gets an obsolete implementation out the door (if that’s an upside), but it makes things complicated during an important phase of the project by putting an engine change in motion while trying to flesh out deeply tied APIs. Not good.

Oddly some people wanted a WebEngine/CEF switch and took to this option as Fiber having such a switch. Considering CEF proper is based on Chromium/Blink (which is what WebEngine uses) it’s a bit like asking to take two paths to the same destination; there are differences in the road but in the end both ways lead to Blink. There will be no switch for Cef/WebEngine because adding one would bring down the API potential to the lowest common denominator while increasing complexity to the most advanced method.

Runner up: Use WebEngine

“Use WebEngine” was the runner-up at 24% of the vote. The main prospect behind this is that it would result in a shipping browser fastest, but it also works under the assumption that it may increase code compatibility between Qt-based browsers – but the architecture of Fiber I believe will be very alien compared to contemporary solutions. If there are chances to collaborate I will, but I don’t know how much of that will be possible.

There was also a segment that voted for WebEngine thinking CEFs was just a more complicated route to Chromium, being confused about the road to Servo.

Winner by a mile: Go Exclusively CEF

It’s no surprise that in the end “Use CEF” trounced the remainder of the poll at 59% of respondents voting in favour of it – more than both other options combined or any individual option doubled. From the comments around the internet one of the biggest reasons for the vote is Servo as a major differentiating factor between other browsers, and also because it would help mitigate the Webkit/Blink monopoly forming on non-mozilla browsers for Linux.

This excites me as a web developer, and I’m likely to try pushing Servo as the default engine as it will likely be plenty good by the time Fiber is released. Sadly, I believe there were a few votes placed thinking that Fiber would ultimately usher in a “QCef” or “KCef” framework; and I don’t think this will be the case.

On making a Frameworks 5 API I considered it as a super-interesting Frameworks addition, but after careful consideration I realised there just aren’t too many projects which would benefit from what would be a substantial amount of work. Another issue is that I think the QWebEngine is appropriate for most projects, and that anything more is needless complication. The Qt developers have done a good job picking the right APIs to expose which suits common needs, and I imagine the additional complexity would only hurt projects adopting such a library; it’s killing a mosquito with a cannon. Plus, QWebEngine will evolve in good time to fill any common needs that pop up.

What will Fiber do?

Fiber is going to go exclusively CEF. I’m in the process of fiddling CEF into the browser – but CEF is a bit of a beast and about 3/4 of my time is simply reading CEF documentation, examples, and reading the source code of open projects using the utility. My main concern is properly including CEF without requiring X11; it’s possible, but the Linux example code isn’t using Aura, and the implementation examples are GTK-based as well. Qt and KF5 have solutions, but I’m reseaching the best route to take.

In terms of what engine Fiber is using (Servo vs Blink) I’m going the generic route; you can drop in simple config files pointing to CEF-compatible executables, and when configuring profiles you can pick which engine you would like to use based on those files. This engine switch is already present on the command line and in the “Tuning” section of the profiles manager. This means you can have different profiles running different engines if you choose. There’s a second command-line option which will launch a new instance of Fiber with the engine of your choice running one-time for testing purposes. For the purposes of the default, I’ll probably push Servo.

CEF will not drive UI

Indirectly using CEF means QML may become the exclusive language of UI extensions, popups, and config dialogs. Mainly this is because of the additional abstraction and effort required to offer CEF in several contexts, but it also puts a much cleaner separation between browser and content and will likely make securing the system easier. Extensions will be required to offer pages in HTML.

If you’re using QML, your writing chrome. If you’re using HTML you’re writing a page.

This is also more in-line with the Plasma Mobile guidelines, and though I severely doubt you’ll see Fiber become a mobile browser any time soon this keeps the door open for the far future. In two years I’d rather not break a significant number of extensions for mobile inclusion; I’d rather just have things work, maybe with some minor layout tweaks.

There are real pros and cons to QML as the only way to extend the browser UI, and probably one of the largest I worry about is the fact that QML has a significantly smaller developer base than HTML. On the plus side QML is able adapt to platforms, meaning we might not need to divide extensions between desktop and mobile – that would simply boil down to layout tweaks. All this means is instead of having many extensions of questionable quality, we will aim to offer fewer but higher-quality extensions.

On Progress

Progress is steady. Probably an hour to two of work a night goes into the project, and extra time on weekends as freedom allows. It drives people nuts that I’m taking my dear sweet time on this, but when the groundwork is done there will be a solid base for others to help quickly build on.

I’ve introduced threading into some parts of Fibers management tools, and made significant improvements with how Fiber manages internal data caching for profile data. This all got started when I noticed a split-second of lag on a slider, and realised the long-term implications. Threading was introduced so when the database models are working they do not lag the main thread, and the layer which talks to the model now caches the data and only communicates with the model when one is out of sync. The next step will be to add some internal very coarse timers and event tools which will delay hard data saves until they can be batched efficiently or must be written, and possibly a check to prevent the saving of idenitcal data.

While this may not matter as much for the management tools I’ll be applying these techniques on an extension-wide bases; this will save power, keep Fiber highly responsive, make it CPU wake friendly, and avoid hard drives wakeups – even when bad extensions might behave in “thrashing” behaviours. Ironically this first performance exercise has made me confident that even with many “slow” javascript-driven features, Fiber may become a highly performant browser by virtue of having extremely fine-tuned APIs which give blanket improvements.

One of the most annoying but necessary changes was porting Fiber from QMake to CMake. Originally I had the intention to prototype using QMake, switching to CMake later for the “real” work. As things would have it the prototype had simply evolved and I realised it would just be easier to port it. As I’m not terribly familiar with CMake this started off painfully, but once I realised what CMake was trying to encourage I fell in love and things just clicked.

During the CMake port I also took the opportunity to strip out vestigial or prototypical code and do some housekeeping, which certainly cleaned things up as I not only removed files but also disposed of bits of code too. I also removed all traces of WebEngine which I had used during the earliest prototype phase; the next time Google pops up, it’ll be with CEF.

I’ve also started incorporating the first KF5 libraries into the project. The libraries are very well organised, and also well documented. Finally, I need to compliment Qt and state how amazing the toolkit is. Really. Some of the most notable changes were trivial by Qt making smart use of its internal structure, and even though I’m hardly a veteran developer Qt and it’s extremely good documentation has allowed me to make smart, informed decisions. Really guys, good job.

On other projects

Moving away from Fiber, right now we’re doing a lot of work on refining the Breeze theme for Plasma 5.5 in this thread, where we’re running down paper-cuts on the design and building the next iteration of the style. Ideally, we’d like to see a much more consistent and well-defined visual structure. Later on we will start to address things like alignment issues, and start targeted papercut topics which will address specific visual issues. If you’re interested, please read the entire thread as there is lots of design discussion and contribute your thoughts.

Remember, constructive feedback is the easiest contribution anyone can make to an open-source project!

Fiber has seen some active development, and over the course of a long 3-day weekend full of hacking I’m glad to say that exactly 0 progress has been made! Of course that would be a bit of a fib, I’ve spent the weekend re-factoring all of the profiles code and organising the codebase structure.

I also spent a good chunk of my time reading Qt and KDE coding guidelines and documentation on how files and classes should be structured, and then I applied that information to Fiber. The result now is well commented code, and consistent naming conventions in-line with other Qt/KDE projects.

But re-factoring code isn’t what I’m really interested in talking about…

WebEngine vs CEF

When I started Fiber I worked under the assumption that WebEngine would be the engine for this browser; it’s an official Qt extension, being actively developed, and isn’t going anywhere. After Fiber kind of came into the light I had a comments and emails pointing me to CEF, the “Chromium Embedded Framework” as an alternative to WebEngine.

After doing research it’s severely divided my thoughts on what to use.

What is it?

CEF started as a Chromium-based project meant to create a stable API relative to the rapidly changing engine, something non-qt applications could use as easily and reliably as Qt applications do with WebView . While it started off as just an implementation CEF has a defined stable enough API that it turned into a sort of pseudo-standard. Servo, Mozillas new wonder engine is actually building itself to be a native CEF implementation, meaning that future Firefox will actually be a CEF-based browser.

CEF, despite being not so well-known, is actually used by some very high-profile companies which lends credence to the longevity of the project. Adobe, Valve, Blizzard, Amazon, and other big names have thrown their chips behind CEF. Valve in-particular bases their Steam client on the thing.

Pros and Cons

Cons

Not everything is rosy and bright in the world of CEF; there are always downsides. The first and biggest downside is the fact that CEF doesn’t have a Qt library. The Qt guys didn’t decide on this arbitrarily as they have a different goal for the WebEngine API. At minimum CEF means more complicated work than using an established Qt API.

CEF and having multiple engine options also means that we may see two entirely different sets of bugs coming in, depending on whether or not a person is running Fiber-Chromium or Fiber-Servo in the future. This doesn’t even include potential future CEF implementations; who knows what might show up in 5 years.

I would also like Fiber to be extremely portable, which makes CEF more of a concern; WebEngine currently supports mobile, but CEF will only have Android support ‘in the future’. Since Plasma Mobile includes a more malleable stack I have less doubts that Fiber will run fine on that, but I would like to see Fiber eventually run on Android.

Finally, CEF will add a lot of weight to the browser as an external dependency, to the tune of at least 40MB at minimum. This is more due to WebEngine being part of Qt and already being on the system – but CEF isn’t, and so the rendering engine is a separate binary to distribute. If a distro ever eyes Fiber as a default browser it means there’s over 40 extra reasons to consider a slimmer browser which makes use of more common libraries. Granted, just about every major browser is packing pretty big binaries anyway – but it’s still wasted space.

Pros

One thing that’s kind-of well-known is that WebEngine doesn’t have a particularly deep API (yet). For most applications this is fine as the utility is just used to display some content and hook a few things in so the app can talk to the page in an efficient manner. Fine for the use-case that Qt envisions. For a full-on browser though WebEngine lacks a lot of important interaction points, and though I Initially doubt Fiber will be able to make use of deeper integration in a meaningful way, as time goes on it’s a serious advantage to lose, especially since I don’t know the roadmap for WebEngine and what they plan to add.

WebEngine and WebView also have bad security reputations – I don’t know the specific issues, I just know those issues are prominent enough to see Fedora choose not to ship it. CEF doesn’t seem to have this perception as far as I know. That being said I’m not a guru-level C++ programmer so I’m not disillusioned to the fact that I’ll inject my own security shortcomings; though I won’t have the worry of breaking downstream applications in the quest to fix those issues.

There’s concern in the web development community of a WebKit/Blink monoculture. Outside of Gecko, there’s no longer any rendering engine variety for the Linux community. While I doubt Blink will ever “slack off”, the fact is Blink has undue weight over the web because of its sheer dominance. With more variety it means Blink has to keep in-line with the wider browser community rather than driving it. Gecko, Trident, Edge, and Servo all push Webkit/Blink harder in the same way many desktop environments push KDE to be better.

But the absolute biggest advantage in my opinion is the fact that CEF will offer Servo in the future as well as Blink. It means that we will be highly portable in our choice of rendering engines, able to swap out quickly. If we tightly integrate with Webengine it means Fiber won’t have mobility in the future, but through CEF if one of the engines gains a significant technical lead we can change the engine easily.

The Poll

We have three options for Fibers engine of choice, and I’d like the people who may ultimately use the browser to decide, as I’m really truly torn!

1. Stick with WebEngine. It’s simple, easy, fast, supported. Fiber already has WebEngine running.
2. Start with WebEngine and just get the browser up-and-running, later make the transition to CEF. It would be fast at first, but it will complicate things later on as we make the transition, especially if there’s several extension APIs connected with WebEngine.
3. Write Fiber to use CEF natively. This will probably result in a more performant browser, and will allow deep integration; though it would still be slower to develop than just using WebEngine.

[polldaddy poll=9012714]

(Don’t see the poll? Click here!)

Finally, if you have comments, please post them below and elaborate on what drove your decision.

KDE Frameworks, Plasma desktop, and our community have a rich history of nearly twenty years in creating great open-source software, making us a truly historic organisation of passionate developers; and along with that history some of our online infrastructure has begun to show its age. The KDE.org website and its various sections are the front door to the KDE ecosystem, it is how people new to KDE will judge us and it’s where our developers, translators, artists, and community members know their hard work will be presented to the world.

Recently there’s been a minor movement in the KDE community hive-mind stirring about our web network, and it’s increasing need for a significant update. Some of this has been separate, some in groups, some know about the others but not vice-versa. There was a BOF at Akademy which also focused on a new website and goals.

We’ve opened up a new community forum with the dedicated task of modernising our legacy infrastructure to create a unified effort. Everyone wanting to participate will have the goal of revitalising the KDE.org website for our 20th anniversary, giving us a strong infrastructure to celebrate a stronger foundation for the next 20 years of KDE, community, and open-source.

The WWW team, Promo Team, and VDG have all expressed desire to build a better KDE.org, and we’d all like to see the wider KDE community to contribute! You don’t need to be a web developer or server administrator to chip in; even if it’s a few minutes of feedback or a single idea, we would like to see you participate! We plan to build this website on a foundation of respect and openness – everybody and all constructive input will be welcomed.

There’s no specific goal to have the whole network completed; there’s a huge number of assets and each one is unique, but I believe it’s reasonable to have many of our most prominent pages and sections converted in time for our 20th anniversary – October of next year, roughly. Beyond that, we’ll work section-by-section page-by-page to ensure KDE.org is as amazing as it can be.

Click here to go to the forum

It’s been a while since I’ve posted about Fiber, so here’s a brief update.

(more…)

For the past month I’ve been slightly more active than usual, and I’m excited for this release and some of the art I’ve managed to throw into the pipe;

Icons, Icons!

I would like to make a special mention that not all of these icons have been greenlit, and several of them are pending approval and may be dropped/require changes. Some were literally finished minutes ago while others have already been integrated into projects. \o/

After “harmlessly” throwing in a couple monochrome icons from my personal projects, I found myself reading a few of the icon requests and one thing lead to another… Now I’ve pushed in somewhere around 25 new icons, mostly towards apps with the goal of filling in gaps of common applications. These new icons will hopefully bring a much more cohesive launcher menu, with more core and popular applications having Breezy icons.

Some of these may be shunted to an extended repo; 3rd parties get antsy when they see their logos get “breezified”, so “branded” icons need to occasionally be separated from the main repository to avoid troubles and takedown requests.

Lastly but not least; Uri and Andreas have been nothing short of awesome in helping me get these out, thanks guys!

The tale of an annoying, terrible, awful wallpaper, and How I Made it.

I’d like to say that I’m less a man and more a force of nature – one able to sweep my hand and make art bloom at will… But this would be a lie, and occasionally getting art out there makes the only force I can muster feel like a fart in the wind. The new wallpaper for 5.4 just did not want to be made, and took days on and off trying to figure out what to do. I nearly just suggested we ship a backup wallpaper I had on the sidelines.

Eventually ideas got figured out, and after an unstructured failure (again, making me look at “the backup”) I started taking screenshots while using a more structured approach. I imagine I wanted all reading this to feel my pain. Either that or laugh. One of the two. Either way, the new wallpaper was one of the more involved processes used for a Plasma 5 wallpaper, and here are the steps for how it came together;

(more…)

It’s been one heckuva road, but I think the dust is starting to settle on the UI design for Fiber, a new web browser which I’m developing for KDE. After some back-and fourth from previous revisions, there are some exciting new ideas in this iteration! Please note that this post is about design experiments – the development status of the browser is still very low-level and won’t reach the UI stage for some time. These experiments are being done now so I can better understand the structure of the browser as I program around a heavily extension-based UI, so when I do solidify the APIs it we have a rock-solid foundation.

Just as an aside before I get started; just about any time I mention “QML”, there is the possible chance that whatever is being driven could also alternatively use HTML. I’m looking into this, but make no guarantees.

As a recap to previous experiments, one of the biggest things that became very clear from feedback was that the address bar isn’t going away and I’m not going to hide it. I was a sad panda, but there are important things the address bar provides which I just couldn’t work around. Luckily, I found some ways to improve upon the existing address bar ideology via aggressive use of extensions, and slightly different usage compared to how contemporary browsers embed extensions into the input field – so lets take a look at the current designs;

By default, Fiber will have either “Tabs on Side” or “Tabs on Bottom”; this hasn’t been decided yet, but there will also have a “Tabs on Top” option (which I have decided will not be default for a few reasons). Gone is the search box as it was in previous attempts – replaced with a proper address bar which I’m calling “Multitool” – and here’s more about it why I’m a little excited;

Multitool

Fiber is going to be an extensions-based browser. Almost everything will be an extension, from basic navigational elements (back, forward), to the bookmarks system – and all will either disable-able or replaceable. This means every button, every option, every utility will be configurable. I’ve studied how other browsers embed extensions in the address bar, and none of them really integrate with it in a meaningful and clearly defined way. Multitool is instead getting a well-defined interface for extensions which make use of the bar;

Extensions which have searchable or traversable content will be candidates for extending into the Multitool, which includes URL entry, search, history, bookmarks, downloads, and other things. Since these are extensions with a well-defined API you will be able to ruthlessly configure what you want or don’t want to show up, and only the URL entry will be set in stone. Multitool extensions will have 3 modes which you can pick from: background, button, and separate.

Background extensions will simply provide additional results when typing into the address bar. By default, this will be the behaviours of things like current tabs, history, and shortcut-enabled search. Button extensions in mutitool will provide a clickable option which will take over the Multitool when clicked, offering a focused text input and an optional QML-based “home popout”. Lastly, “separate” extensions will split the text input offering something similar to a separate text widget – only integrated into the address bar.

The modes and buttons will be easily configurable, and so you can choose to have extensions simply be active in the background, or you could turn on the buttons, or disable them entirely. Think of this as applying KRunner logic to a browser address bar, only with the additional ability to perform “focused searches”.

Shown on the right side of the Multitool are the two extensions with dedicated buttons; bookmarks and search, which will be the default rollout. When you click on those embedded buttons they will take over the address bar and you may begin your search. These tools will also be able to specify an optional QML file for their “home” popout. For example the Bookmarks home popout could be a speed-dial UI, History could be a time-machine-esque scrollthrough. Seen above is a speed dial popout. With Bookmarks and Search being in button mode by default, just about everything else that performs local searches will be in “background mode”, except keyword-based searches which will be enabled – but will require configuration. Generally, the address portion of Multitool will NOT out-of-box beam what you type to a 3rd party, but the search extension will. I have not selected search providers.

We also get a two-for-one deal for fast filtering, since the user is already aware they have clicked on a text entry. Once you pick a selection from a focused search or cancel, the bar will snap back into address mode. If you hit “enter” while doing a focused search, it will simply open a tab with the results of that search.

Aside from buttons, all the protocol and security information relevant to the page (the highlighted areas on the left) will also be extension-driven. Ideally, this will let you highly customise what warnings you get, and will also let extensions tie any content-altering behaviour into proper warnings. For example, the ad-blocker may broadcast the number of zapped ads. When clicked the extensions will us QML-driven popouts.

Finally, the address itself (and any focused extension searches) will have extension-driven syntax highlighting. Right now I’m thinking of using a monospace font so we can drive things like bold fonts without offsetting text.

Tabs

Tab placement was a big deal to people; some loved the single-row approach, others wanted a more traditional layout. The solution to the commotion was the fact that there isn’t a single solution. Tabs will have previews and simple information (as seen in the previous round of designs), so by default tabs will be on the bottom or side so the previews don’t obstruct unnecessary amounts of UI.

Fiber will have 3 tabbing options; Tabs on top, tabs on bottom, and tabs on side. When tabs are “on side” it will reduce the UI to one toolbar and place the tabs on the same row as the Multitool, and should also trigger a “compressed” layout for Multitool as well.

There will be the usual “app tab” support of pinning tabs, but not shown here will be tab-extensions. Tab extensions will behave like either app tabs or traditional tabs, and will be QML-powered pages from extensions. These special tabs will also be home-screen or new-tab options, and that is, largely, their purpose; but clever developers may find a use in having extension-based pages.

Tabs can also embed simple toggle-buttons, as usual, powered by extensions. Main candidates for these will be mute buttons or reader-mode buttons. There won’t be much to these buttons, but they will be content-sensitive and extensions will be required to provide the logic for when these buttons should be shown. For example, “reader mode” won’t be shown on pages without articles, and “mute” won’t be shown on pages without sound.

Current Progress

The current focus in Fiber is Profiles, Manifest files, and startup. Profiles will be the same as Firefox profiles, where you can have separate profiles with separate configurations. When in an activities-enabled environment, Fiber Profiles will attempt to keep in sync with the current activity – otherwise they will fall back to having users open a profile tool.

The manifest files are a big deal, since they define how extensions will interact with the browser. Fiber manifest files were origionally based on a slimmed down Chrome manifest with more “Qt-ish” syntax (like CamelCase); but with the more extensive extension plans and placement options there’s more going on with interaction points. There’s a decent manifest class, and it provides a reliable interface to read from, including things like providing missing defaults and offering some debugging info which will be used in Fibers extension development tools.I’m using DBus for Fiber to check a few things on startup; Fiber will be a “kind of” single-instance application, but individual profiles will be separate processes. DBus is being used to speak with running instances to figure out what it should do. The idea behind this setup is to keep instances on separate activities from spiking eachother, but to still allow the easier communication between windows of a single instance – this should help things like tab dragging between windows immensely. It also gives the benefit that you could run “unstable” extensions in a separate instance, which will be good for development purposes.I wish I could say development is going quickly, but right now my time is a bit crunched; either way things are going smoothly, and I’d rather be slow and steady than fast and sloppy.Development builds will be released in the future (still a long ways away) which I’ll be calling “Copper” builds. Copper builds will mostly be a rough and dirty way for me to test UI, and will not be stable or robust browsers. Mostly, it’ll be for the purpose of identifying annoying UI patterns and nipping them before they get written into extensions.

By now the news has spread quite quickly; the Ubuntu Community Council (or “CC” for short) had attempted to boot Jonathan Riddell as a community leader, asking him to “take an extended break” from the Kubuntu Council (“KC” for short) citing personality conflicts and breaches of the Ubuntu code of conduct.

So, what just happened? On the various news sites and through some broken telephones there’s several misconceptions about what happened. Being an outsider the whole issue is rather complicated, I know nothing of the structure around Canonical, Ubuntu, and these councils and how all this relates to Kubuntu.

This isn’t going to be a post about the he-said-she-said arguments, but is more of an outsiders explanation into how all this fits together and what it really means.

I’d like to mention I’ve received corrections in the comments, and would like to give a thank-you to the commenters for their feedback.

What is the Community Council? How does it work?

The Community Council is the highest governing body representing the Ubuntu umbrella of projects, including its derivatives. The CC is a democratic organisation with 7 seats available for elected representatives and a 8th tie-breaking seat being reserved by Mark Shuttleworth. The group uses a well defined electoral process which receives votes and nominations from the Ubuntu membership and community at large.

The group manages non-technical communication and governance of the Ubuntu project and derivatives. An important part of this event is the mandate that the council operates transparently to the wider community, the idea being that they would also serve as a bridge between the commercial arm of Canonical and the open-source community at large.

What is the Kubuntu Council?

Just like a larger governing body, the Community Council has delegated sub-councils to represent larger projects within the community. The Kubuntu Council is one such branch managing the KDE-oriented Kubuntu project. Like the CC, the Kubuntu Council is composed of members elected by the community.

When the system works the idea is that the Kubuntu Council will take care of project-level matters independently, and the Kubuntu Council lead will attend meetings to trade information and matters upstream with the Community Council.

So… Does Canonical Own Kubuntu?

I will note here that Canonical is not one of the active parties in this dispute – this section is only meant to clarify misconceptions I’ve seen online, and to help explain the next sections.

Canonical owns the trademark for Kubuntu – so as a ‘brand’ they own Kubuntu. Beyond that Canonical does not directly fund Kubuntu, instead they offer infrastructure in the form of repositories and servers, where Kubuntu is allowed to piggyback off the Canonical/Ubuntu project network and work more closely with upstream resources.

But Canonical does not employ the Kubuntu staff; previously they did employ staff but Blue Systems stepped in when Canonical cut funding. Blue Systems has since become a much larger part of what drives Kubuntu than Canonical. Both of these together have made Kubuntu (as a project) much more than a solely Canonical venture.

In over-simplified terms Canonical owns the franchise and Blue Systems runs the hottest ‘non-headquarters’ location.

Who is Jonathan Riddell?

Jonathan is an ex-Canonical employee who was scooped up by Blue Systems after Canonical cut funding.

Part of Canonical cutting Kubuntu funding was terminating Jonathan as an employee of Canonical. He essentially retained his position in all community aspects of Ubuntu, just without the paycheque: he is a Kubuntu Council member, has access to the Canonical infrastructure, and helps manage the Kubuntu project.

Blue systems picked him up and he is able to work full-time in an almost identical capacity that he did as a Canonical employee.

What was the Ruckus?

Mainly, there’s some conflicts between Riddell and members of the core Community Council. Riddell had repeatedly pushed several issues which the council was unable to fulfil, leading to frustration on both sides. In the end both sides showed the stress they were under, at which point the Community Council privately decided they would oust Jonathan from the Kubuntu Council.

The KC replied arguing that the decision was not made transparently, questioned how much power the Community Council should have over the community-elected Kubuntu Council roster, and was incensed by the CC not retracting the decision before a transparent conversation. The Kubuntu Council didn’t want to negotiate “with a gun to [their] heads”.

Who Ultimately Gives the Orders?

The Kubuntu Council is bound by their constitution to obey “legitimate orders” from the Community Council; if the CC makes a decision in line with the Code of Conduct and its own constitution the Kubuntu Council must obey that request. But no provisions have been made for when the two groups disagree over a decision. The Community Council may be forced to cut off Jonathan or supporters from Ubuntu support infrastructure, such as Canonical repositories and funding, and the group has already stated that he is keeping his upload rights and ability to request funding. However given the hostilities, revoking those privileges might be a hardball solution, and one that the Kubuntu Council may not have control over.

The reason Kubuntu believes it can reject an authoritative attempt is threefold; it had never happened before so there was no ‘precedent’, there was no warning for Jonathan to correct the ‘behavioural issues’, and the largest reason is because the Kubuntu Council does not feel the decision was legitimate.

The entire issue hinges on the legitimacy of the order; Kubuntu Council only has to obey legitimate orders, and questions whether a decision made behind closed-doors when the mandate is transparency be considered legitimate.

In short: yes the Community Council can remove people from its sub-councils, but it might have terrible fallout if done improperly. They can’t really tell the Kubuntu crew what to do if Kubuntu doesn’t find the orders legitimate. But if push comes to shove it is possible for the Community Council and Canonical to revoke infrastructure access if a resolution cannot be found.

What Happens Now?

Right now the Community Council is exerting control over projects using their infrastructure much like a company would manage employees; if someone isn’t in line they can be moved, removed, or suspended without public debate.

The problem with this strategy is the fact that communities don’t like being dictated to, and in attempting to do so rubbed the community the wrong way. The Community Council literally gave an order and the Kubuntu Council said “no”. So what happens now?

By removing Jonathan from his position in the Kubuntu community, it also affects his value for Blue Systems. If he were removed, it brings into question what Blue Systems and the community would do in response; Riddell is a Blue Systems employee and carries significant community favour from KDE users.

The first thing that can happen is… Nothing. Birds will sing, grass will grow, and the KC will make the CC grit their teeth a bit. Maybe Jonathan will be removed after a more transparent meeting, maybe not. If the KC doesn’t remove Jonathan, then it may force Canonical into an awkward situation where it must back the council and start cutting off infrastructure.

Second, if this is resolved, Mark and the Community Council may revise its community strategy and put in safeguards for these situations and possibly enforce a more formal structure over the ad-hoc sub-community model. This would need to apply to all communities as singling out specific projects would simply inflame the situation, in the future preventing other projects from entering a similar situation.

Third, instead of a split the Kubuntu crew might attempt to separate their internal governance a bit; possibly designating a separate group to work with the Community Council while the main leadership remains as-is. Ubuntu can work with their partners effectively without disturbing the leadership, but this solution complicates communication and doesn’t fix several underlying issues.

The next thing that may happen could be the start of a more gradual separation; Kubuntu as a project may slowly take on more infrastructure, growing apart and leaving the nest – maybe with Canonicals blessing and the transfer of the Kubuntu trademark. Who knows.

Lastly both sides could calmly file into a room before sizing up chairs to throw at each other; terrible words being said about peoples mothers before forking Kubuntu into ‘Librebuntu’. This would hurt as the Kubuntu and KDE developers already have poor relations with Canonical, meaning a fork would likely lead to a mass exodus from Kubuntu to the new project (much like the LibreOffice fork). While the freedom of not having Canonical or the Community Council dictate policy would be refreshing, the loss of infrastructure would be a certain setback.

In the End… ?

In the end, I think we all simply hope that projects, companies, communities, and benevolent dictators can all work together in relative harmony. The situation isn’t ideal, but a major part of building strong communities is occasionally finding out something doesn’t work – and fixing it; hopefully to the benefit of everyone involved.

Right now both sides are holding strong in a ‘grey zone’ with their actions – the CC seems to be meting out harsh decisions without clear policy, and the KC is refusing to listen until the CC backpedals on its position.

That’s my breakdown of the politics; I hope it helped and provided insight into this whole messy affair. I hope to gets all sorted out in the long run. If I have anything wrong, please do let me know in the comments and I’ll make the relevant corrections.

With the Sprint behind us and the Freeze coming up next month, the VDG has made it’s agenda for the coming weeks, and I figured I’d share some highlights I’m working on, and a couple I’m personally looking forward to.

Wallpapers

Andreas is doing a fantastic wallpaper contest which I hope many of you will participate in; the goal is to get wallpapers for weather-based wallpapers, and to also get several new wallpapers into circulation. It doesn’t have to be weather wallpapers – if you have a wonderful high-resolution graphic, submit it!

In addition to pulling in community work, we’re going to change up the release cycle for new wallpapers: Previously, wallpapers were updated every second version, but now we will add a new wallpaper for every release of Plasma!

Avatars

The current crop of standard avatars have aged gracefully, but we’re looking to refresh them. We have a new crop of avatars based on history-changing individuals and fairy-tale children. Eventually we will expand the set to include a range of personalities.

Credit for the design goes to Jens Reutersberg who created the fantastic VDG profile pictures.

Decorations

We may be looking forward to a new alternate decoration; originally based on Breeze and the result of a first-time hack gone too far, “Chroma” may be appearing! Somewhere! Where it shows up all depends on my laziness and incompetence. I assure you I am only mostly lazy and incompetent.

There’s a few things that need to be done with it, mostly in regards to properly breaking it out from Breeze to be it’s own decoration, and learning to properly submit it.

Akademy

Several VDG members are looking to show up at Akademy, so if you’re looking to hear an awesome talk or two there will be some design talks in the future. I won’t go spoilertastic, but I’m looking forward to it, or dying trying to get there – you should be to!

Just over 2 weeks ago I stepped off a plane, putting my heels onto Canadian soil after spending a week participating in the Plasma 2015 Sprint. The entire experience was exhausting in the best of ways, and after landing home my throughput was thoroughly trounced for some time as I settled back into normalcy. But lets rewind to the beginning;

The day of my arrival in Barcelona it would be a far cry to say I was nervous – in the moments before pressing the buzzer I was in a downright terror! These people will realise I’m an idiot! Ship me back to Canada on the next canoe! Needless to say only minutes in to the sprint not only were my worst fears completely unfounded – but I met a group as welcoming as they were brilliant.

Finally, I think I have the perspective to share my experience. I won’t try to recap the entire event, I will mainly focus on VDG work.

But first! The People of KDE

I met about a dozen dedicated and hard-working developers in the Blue Systems office during the sprint, and it needs to be said just how great these people are – each and every one passionate about their respective fields and projects. I’d really just like to give a shout-out to everyone I met in the Sprint. They’re the kind of people who make you smarter by proximity, and they welcome you to do it. For anyone invited to a Sprint I highly recommend jumping on the chance; you will be enriched for doing it.

Drawing Konquis

After arriving mid-day Jens Reuterberg headed the idea to begin creating and stockpiling promotional graphics. Essentially we wanted vector artwork which could be used easily for things like release announcements, large print materials, web pages, etc. Jens dove head-first into logotypes, and I splintered off into doing up a pair of vector Katie and Konqui graphics during my half-day; Konqui being a direct trace, and Katie being new. You can view the original graphics by the talented Tyson Tan here.

Download Katie – Download Konqui

VDG <3 Developers

There was a great deal discussed during a pair of review and planning sessions in the first two official Sprint days. One of the biggest things (for Jens and I) was helping the VDG and developers interoperate better; for those who don’t know, the VDG communicates very differently than mainline developers.

Devs tend to focus on bug reports, mailing lists, reviewboards, and IRC. Members of the VDG tend to use Forums, Hangouts, and to a limited extent IRC. Immediately there’s very little overlap, which means at this point developers have to go to the forums to wield the VDG.

The problem lies in how forums operate; where the VDG design processes benefits from the relative chaos, it’s not good for developers looking for the ‘final word’ of the design discussion. It’s further impacted by forum conversations which don’t have definitive conclusions, or discussions which can get muddled down. When developers go to the forums they need a solid final product to build around – but on multiple occasions they end with a half dozen different designs and no clear answer on what they should do.

It was a short discussion during the Sprint, but Jens and I both immediately agreed that this is an area where the VDG must step up and refine our process.

The current idea will be sticking with the forums threads as the main creative area, but changing the way they spin down. Once we feel a design discussion has gestated, the VDG aims to have a member pull the ‘final’ design from the conversation, at which point they’ll put together a coherent deliverable developers can understand and act on, on a channel they are comfortable with.

There are still details we are ferreting out before we more formally put this into motion, but the essential aim is to move the VDG into a position where we can reliably ship usable deliverable design, on a channel developers can comfortably handle.

Breeze Applications

This only came up briefly during the Sprint as well, but is something which has been brewing for a while now – so it might be worth mentioning ‘for realsies’, essentially since I don’t think anyone pointed out that this is a ‘thing’;

KDE and Plasma have a bit of a history with names, and for many core applications we’ve been wanting a more consistent scheme for it all. At the same time, with every major tookit release (i.e. Qt4 -> Qt5) many applications need to be ported or re-written. Finally, on these major releases, visual/workflow trends have usually shifted meaning the experience of applications will also shift.

So, all this stuff going on, we figure it’s time to put a bow on it and turn this cavalcade of factors into one cohesive event, so we’ve come up with the concept of Breeze Applications.

The idea is that, coinciding with frameworks, trend, and design changes we will name a subset of the bundled applications after the current design. So for Plasma 5 we will have ‘Breeze’, for some future plasma version many moons from now we may have ‘Gust’ or ‘Wind’ applications.

What does this mean? The biggest thing is that we intend to use these ‘Breeze’ applications as standards bearers, which we hope to see other applications follow. It’s much the same way Google treats ‘Holo’ and ‘Material’, along with their base applications: This is the design, these are the examples. Ideally we intend to focus on only a few applications, which developers will be able to dissect and say ‘oh, this is the plan’. In addition, as new technologies and techniques land, we hope Breeze applications will be the frontrunners in adopting cutting-edge KDE/Plasma technologies.

Does this mean every Plasma or KF5 app will be named “Breeze X”? No. We only plan on Breeze-ifying the more simple core applications which can be easily maintained, kept up to date, and streamlined enough that the code could easily be used for reference material.

Fun fact: The bathrooms in Frankford are powered by Ubuntu!

Dynamic Window Decorations

Before I even get started on this, I must give props to David Edmonston. The man is a trooper, and I feel almost as if I tortured the poor gentleman throughout the sprint.

During the sprint I presented some of my DWD plans; technical details were discussed, implementation questions were raised, and concerns were were round-tabled. The discussion was extremely positive and productive, and real issues were ferreted out.

One of the larger questions was ‘what IPC protocol should be used?’; I personally was educated about the Wayland protocol, and that it could be used even on ‘non-wayland’ systems – since it is just a protocol and not an installed library. Ultimately, the developers present agreed that D-Bus was the way to go, the general consensus being that the protocol is known and familiar, mature, battle-tested, and isn’t going to shift or break.

I also gave my personal thoughts on how applications might access/implement DWDs, and while there’s still considerable room for discussion, it seems to be on the right track. I was cautioned by developers and I feel the need to point out: even when the DWD protocol does pick up steam it will still be years before it’s available in any meaningful way.

During the development portion of the Sprint I managed to rope David into doing some DWD work on a proof-of-concept level. Through his efforts we now have a much better idea of what obstacles we will face integrating widgets into server-side decorations, such as ensuring the draw code runs correctly/efficiently. He heroically managed to get window decorations to draw usable sliders, so we do know window decorations are capable of drawing server-side widgets.

Sadly, the proof did nearly cost David his sanity. It probably didn’t help that I was giggling like an imbecile. Sorry about that, David. I hope the tea made up for it. :/

UI Feedback

Throughout the Sprint Jens and I were able to lend our services in helping to design and streamline interfaces. Towards he end of the Sprint we also did a walkthrough of the Plasma desktop and several components to identify surface-level bugs and weak areas.

This included an extensive review of the system settings utility and its KCMS.

I also managed to chip in some light advice with a new power-manager tool, and an upcoming redesign of the Baloo settings manager with Vishesh Handa.

And a Great Deal more!

As I mentioned at the start of the post, and can only mention again; There were a lot of really great people at the Sprint – and all of them had their own projects, goals, plans, and feedback. It was really impressive to meet people who had such a deep understanding of KDE Frameworks and Plasma, able to talk about extremely complex technologies in detail over a coffee.

I, personally, learned a great deal from everyone. From being unable to compile a package to now comfortably hacking, simply rubbing shoulders with the outstanding individuals was absolutely my privilege.

There’s a great deal not in this post, but I imagine other posts will fill in the rest… So on a closing note I will say again; if you are ever invited to a Sprint, don’t hesitate to say yes – it’s an amazing experience which is beyond worth it!

I drank this. I still don’t know what it was.

Some people accuse me of being a crazy person. Others are wrong. But occasionally the seeming madness of it all will bring about good things.

Last night was a sleepless night in all the good ways; I’m excited for the upcoming Plasma Sprint, and knowing I’ll be packing myself into a cigar tube and flinging myself across the North Atlantic Ocean is too much for me to sleep over. I had promised a commenter (too long ago) I would make green cursors, so I decided to make good on my word. After it took 5 minutes I needed more; and the wafting smell of my bread maker inspired me to make a Bread cursor theme. Once that was done, sufficiently delirious, I sent my weird bready message to the VDG. They appear to have ignored it – a wise decision. They’re busy people doing actual work.

Today I opened up the cursors to see what I had done.  Nothing too terrible, and I decided it was worth polishing them up if just for the larfs. One of the touches was to add a half-pixel white outline between the crust and loaf for contrast.

When I rendered the tweaked cursors, they started to look awful because of how SVG images layer and clamp nearby vectors. Simply put on a vector edge, even if there’s another identical edge above it, both edges will affect their neighbouring pixels as opposed to the upper vector shape ‘blocking’ the lower shape.

The “desired result” is the result a designer would expect, while the actual result is technically correct.

This had the effect of making the hand of my newly minted bread cursor (with the most edges) look “washed out” because the two lighter inner layers were covering the outline.

The solution for this problem is to ‘supersample’ the cursors in our build scripts. Supersampling is when you render the image at a much higher resolution, and scale it down to the desired resolution. Instead of going directly from Inkscape to a final image, we first export each cursor to a temporary file which is 4x standard resolution and 2x double resolution. We then scale down and copy that image to the final resolutions.

The end result is going to be the option for us to more easily use sub-pixel detailing in cursors without worrying about losing smoothness; any extra detail may not be noticeable on a day-to-day level – but it’s the polish Plasma users are beginning to expect. Additionally, high-resolution cursors will also benefit because the half-pixel details will become full pixel details, and on a high-quality screens you’ll have ultra-sharp graphics.

And that’s how bread is helping make Breeze cursors pixel perfect!

Now, super-pixel-perfection isn’t that noticeable so there’s not going to be a rush to update existing cursors; but if one day you quietly notice your cursor is a little bit sharper than it used to be – you can thank bread.

—

Download The Cursors:
(extract “compiled” cursors to your icons folder to install, or download the source to edit or remix them. Golgari is a green/black theme)

Bread Source
Bread Compiled
Breeze Golgari Source
Breeze Golgari Compiled