The Sprint in Geneva has been a bustling experience, there’s huge amounts of throughput from every participant, and seeing the progress is exciting. There will be a great many blog posts from many people with thrilling progress. I can’t spoil everyone’s work, but I can share at least a few things.

The first is weather! It was previously announced that Plasma 5.6 will be seeing the return of the weather widget. Lots of design work and planning has been done for it and while not everything we discussed will make it in for this release I do happily get to show off our new Breeze weather icons;

There’s more which will be added, but this is the base set which reaches parity with the Oxygen weather icons. Things like high wind, smog, and sandstorms are all in the works.

I’m very excited to announce an updated colour palette. The palette that we’ve been was the formal ‘core’ Breeze colours with an few extended colours I threw in for icons. While it got the job done, we’ve very obviously been using colours not in the official palette for icons using pastels and off-white tints on several occasions. The extended colours were also a bit ad-hoc, with some cases where gaps in hues and luminosity would limit what we could do if we rigorously adhered to the scheme – one thing I did in the wallpapers . Here’s the third iteration of our palette;

It’s not yet in the wiki, but we do have it in GPL format for use in Inkscape, Krita, and GIMP (special thanks to the colour dropper widget which greatly speeded up the process). It’s not completely 1:1 with our existing colours, but it’s close enough and we’ve played loosely enough that it’s not obvious which upcoming icons use the new palette and which use the old. Eventually we may look at more formally updating existing icons, but it’s a low priority. I’m very excited for what this palette will let me do with wallpapers, as I can now make brighter wallpapers without them being over-saturated.

There’s so much more happening, but it’s impossible to write about every detail.

Support the great work of passionate Contributors via the links below!
Via Paypal for one-time donations
Become an ongoing supporter and official supporting member

Yesterday I landed in Geneva, ready to participate in the 2016 multipurpose Sprint at CERN.

After a successful touchdown, I somehow dragged myself onto the CERN campus after over 20 hours of riding trains, flying, waiting, and running. Half dead and ready to drop I got my bearings around the campus while keeping an eye out for other Sprint Participants, and I have to say my first impressions of the facility were shock and awe; more amazing than I could have anticipated.

Of course I was too tired to appreciate it, and I kept pestering the hotel staff to see if a crashpad was ready.

All at once everything seemed to come together and I ran into Alex, Riccardo, Kai, Martin G, and Sebas in short order. Today was just my arrival day, so I wasn’t breaking out the laptop and starting intense development or planning sessions with anyone, but even in our casual conversations we all excitedly at one point or another started planning to plan exciting things.

Right now? I’m waking up, looking at the view (pictures later, probably will update this post) and ready to get started.

Support planning to plan and donate to the KDE e.V.!
Via Paypal for one-time donations
Become an ongoing supporter and official supporting member

For those who haven’t seen it already, I’m very pleased to announce that I’ve been working with Michael Larabel over at Phoronix to post an in-depth review of Plasma 5.5.

You can read it here:
KDE Plasma 5.5: The Quintessential 2016 Review

I gotta hand it to every KDE contributor; I call this review comprehensive but there’s an incredible amount of information I could not cover in a sane article, and it could have easily been twice that length while still failing to hit every feature.

From me to everyone; you’ve all been knocking it out of the park, great work, and thank you. I’m looking forward to what the KDE community brings in 2016!

Since Martin posted his Wayland progress I’ve noticed an uptick in questions about CSD, so I figure now is a good time to upload this post I’ve had sitting around, as for the past month I’ve been closely examining the concept of “Dynamic Window Decorations”, or “DWDs” and how to better implement them.

When Last We Saw Our Heroes

For those who need a primer or reminder, DWD is the sister of “Client Side Decorations”, or “CSD”s. Both CSD and DWD are methods for placing widgets in the frame area of windows to save vertical space, look cleaner, and either make applications feel unique or more integrated.

Indeed, DWDs would be themeable like traditional decorations, fully supporting transparency effects.

CSD charges the application with drawing the whole window including the frame, instructing the window manager to discard the provided frame. This is the method used on Windows, OSX, and GTK. DWD is aiming for the opposite approach; the window manager continues to draw the window frame, but the application can request certain widgets to replace the window title. Martin Gräßlin plans to keep as much as possible on the server-side as there are many important advantages including customisation, stability, trust, and integration.

DWD “1.0” Was Getting Complicated

One thing CSD will always have over DWD is customisation; when an application has free reign over the whole window it can literally do anything; it can make windows round if it wants to, it can invent crazy widgets and put em’ in the title area, and more. DWD isn’t suited to this, and while designing the first iteration of the protocol I tried to bang a square peg into the round hole by providing those many possibilities.

In my infinite wisdom I re-invented X, with a sprawling protocol that covered dozens of edge-cases which would likely never be used. Even with that, people still complained about the fact that many customisations would still impossible. People also didn’t like the KDE crew being the stewards of this protocol, as different environments want to do different things.

DWD, as originally envisioned, had to change – it was just too complicated and inflexible. Listening to the feedback it was clear the protocol had to be simple, flexible, and tractable. A large requirement was also making it able to grow outside of KDE with or without our ‘approval’.

DWDs New Approach

DWD, as I have drafted it, has been boiled down to a discovery service whose sole purpose is getting apps and window managers to figure out compatible protocols, and specify some standard UI controls which will use those protocols.

Here’s the quick overview on the current core “DWD Protocol”, again, as of my current draft (which could totally be rejected):

• DWD will be organised into “extensions”. Extensions are just blueprints listing required D-Bus specifications, widgets/controls, and options.
• Applications and the Window Manager handshake for compatible extensions.
• Applications tell the Window Manager what controls from those extensions it should display, and how it wants them laid out.
• Applications hide their native controls.
• DWD is done and gets out of the way at this point. Control is handed to specifications like MPRIS2, and Window Managers (or Plasma) control the app through those protocols using the requested controls.

That’s it, DWD “2.0” in a nutshell.

KDE will need to create some reference extensions (plus some D-Bus specs) and hopefully everyone will be happy enough to standardise on the basics. From there any environment can create specialised extensions for DWD, we can work with extensions we like, and maybe standardise on the really useful ones (much like libinput has been folded into many environments). If someone makes an awesome extension that handles admin access requests, we could use it. If we make an extension that handles progress charts, someone else could adopt it. I’d like us to develop two reference extensions: a basic toolbar extension, and an MPRIS2 extension.

Advantages over “1.0”

Security is the biggest upside to offloading work on other protocols. DWD doesn’t care how the standards are implemented, so they can be as secure (or insecure) as they choose to be. Security issues or weaknesses in the protocol itself will be mitigated, as the protocol is much smaller. Patches for applications or changes to functional protocols can be made without breaking DWD.

Integration is also another bonus. Parts of the desktop can integrate the protocols extensions use, without DWD needing to explicitly support it. The best example is MPRIS2, which already exists and has amazing support everywhere. The idea behind DWD is that we create more MPRIS-type extensions as we need them.

Finally, core DWD is out of the hotpath for data passing. Window Managers don’t need to be “like X” and conform to complex drawing and customisation tasks. Hopefully as a de-stresser to Martin, this method of offering DWD will be much more easily implemented in a plugin architecture which can be gradually expanded upon. We won’t need to have the full protocol out-of gate, and environments can start with the bare basics and evolve as useful extensions are finalised. I don’t know how he might want to do it, but DWD extension plugins could be potentially be maintained entirely outside of Kwin (or other Window managers) if we play our cards right.

The Downsides

Nothing is perfect, so of course there are downsides;

Customisation.

The big elephant in the room. Going over more standard protocols (and not bloating the new specification) means applications will have no say over how content is styled in the window. I considered this for a while and ultimately decided that it’s O.K.

We could still offer a few more standardised ways of doing common things we do today, such as passing a colour palette to sync with the window, but outside of the handshake I’ll push for an extension-over-integration policy.

The application doesn’t need to know how things are done, only that they’re getting done. The WM knows more about the environment it’s in than the application; functionality is what matters. The volume button on a computer might be shown as a slider, but on a touch-device it may be a larger button with a popout slider. Maybe a phone will simply use the hardware controls. It’s up to whatever is managing the control.

For people already seething with rage ready to point at me and say “Linux is about choice! Applications should choose what their UIs look like!” I will point out; applications can chose not to use DWD. They can choose to implement a CSD-based application. But lets be real here: when we find a need for speciality widgets, if they are really something useful, their host toolkits/environments can always add the extension.

Generally though, if an application is doing something really unique it’s probably doing it’s own thing anyway – like Chrome/Chromium – or breaking the local HIGs. If you absolutely need to save that 18px while also showing a one-of-a-kind rainbow-powered rocket-widget which must be in the frame… CSD is the price of needing to be that special.

Fragmentation.

With anyone able to create extensions, there’s a change we might have a situation where two environments create two similar offerings. For this, I believe it’s a chance for everyone to experiment, and then work together to standardise. The one thing this means is that applications created for another environment might take longer to get CSD-like functionality, though they should present their interfaces in their traditional application UI.

I think this is still better than CSD, as often a broken CSD is unusable vs a DWD which will simply not conserve space.

DWD

So, in the end, this is the direction DWD has gone. Keep it simple, let anyone decide how it should be used, and piggyback off of proven protocols.

MPRIS2 shows what a purpose-driven protocol can do, and already has lots of examples of “remote control” interfaces. Outside of MPRIS2 we would create missing D-Bus specifications which would hopefully make the wider applications library accessible in a similar manner. Specifications for things like progress management, search, sharing, and many others could be created which will benefit applications, and allow deeper desktop integration for everybody.

For those who saw the previous designs in my original DWD blog post, not much has actually changed visually. Everything I posted is still possible, but now we have a much more practical way to do it which I am much more confident we could reliably implement and share.

I made a promise to myself about a day ago that I would not touch my recently-arrived Steam controller until I finished a few of my projects. After successfully not touching it yesterday, I caved like a wet blanket and set my alarm for two hours of play – maybe I wouldn’t be going into the deep end, but I figured I should at least see how my investment panned out considering the unique aspects of the controller.

I don’t get to play games often, but the odd session once or twice a month is necessary to ensure my head doesn’t pop from overworking myself. The only downside is my increasingly awful wrist which sounds and feels more like a cement grinder from mouse-and-keyboarding all day during work and play; so I use a controller sometimes. This is hard though, since even the “best” controller (Xbox 360 brand) doesn’t do most games I enjoy, and I can’t play first-person games (like Amnesia or SOMA) on a controller – I just hate doing it.

So I ordered a Steam controller, and excitedly unboxed it and plugged it in under Valves promise it was a cure-all for PC games. For the first 20 minutes, I can’t say I was impressed. My first 20 minutes with the Steam controller made me yearn for the Xbox controller again.

The Steam controller did have some immediate and notable aspects; I did not expect the haptic feedback to be so incredible. I was expecting an smartphone-esque situation where you shove your finger onto a flat surface and get no tactile feedback. Somehow they got it to work, how a little rumble could make the matte surface somehow feel tactile and real I can only attribute to black magic. It is also incredibly clicky, with many buttons having a nice mechanical snap. The unit is firm and solid as well, and I feel like I could really wrench at it during an intense moment.

But that wasn’t saving my lackluster ability to play Borderlands with it; I was having a bad time because of awkward controls. At this point I had clocked in about 5 minutes of gameplay and 15 minutes dicking around with the controller – failing because the customisation was nothing short of overwhelming. I decided to move onto the next game: Alien Isolation. I had clocked in a few minutes a couple weeks ago or so, and I decided to see if I could have better luck there. The recommended controls were sluggish, and I found myself getting a bit of a cramp because the controls were insensitive and slow. I was sick, thinking “$60 for this?”.

Then I discovered “Community Profiles”, mentioned as an input tip at the bottom of the screen. If one thing was “make or break” for this device, community controls would make it. Community profiles are complete controller configurations created by other players,  listed by popularity. The most popular control scheme described itself as being “ACTUALLY FUCKING USEFUL”. I selected that one. And about 10 seconds later I was completely sold on the Steam controller.

This specific scheme was fast, responsive, accurate, and I can only say it deserved its place as being the control scheme used by nearly 3X the users as the default layout. I stopped thinking about the controller and I’m absolutely impressed to say the least, able to effectively use the trackpad and flick around with mouse-like ease.

Since using a good control scheme, I quickly reversed my previous faltering position on the controller. I had never, ever in my life considered first-person games “playable” on a controller. I’ve never liked it, but on the Steam controller I think I actually *prefer* ditching the mouse.

The main achievement is the speed and accuracy the controller provides compared to a traditional controller. The default game controls set for the Steam controller were unusably slow and almost too conservative… But a more optimal configuration, while not as accurate as using a mouse, in some ways is more responsive as you only move your thumb – not your whole hand as with a mouse – which feels a touch faster and less strenuous. Wonderful for my awful wrist.

Though I haven’t used it yet, you can offset this tradeoff though “Input Modifiers”. You set one input on the controller to be a modifier, and it will change the behaviour of another input. A good use-case is if you are a sniper in a game, and you want your aiming touchpad to be made slower and more precise when using your scope. You make the scope button your modifier, and suddenly you are able to manoeuvre effectively while running and be hyper-accurate while shooting. I’m looking forward to trying Left 4 Dead later with it.

Despite the very positive results with software schemes, I will complain a bit about the feel of the controller. The trackpads are what I worried about the most, and I’m glad to say they delivered – but because of their massive size it forced Valve to move their buttons closer to the centre of the controller. This makes the analog stick and action buttons a bit hard to reach, and I found my left hand had a more awkward grip trying use them. The triggers were well placed, but the shoulder buttons seem specifically designed to be difficult to reach; they stick out compared to the triggers so you have to move your otherwise comfortable index fingers up, over, and out to hit them. Generally speaking the controller doesn’t allow me to have access to all buttons at a given time, and I do need to either stretch my fingers or rotate my hand a but to reach some buttons no matter how I hold the controller. Finally, I feel like portions of the controller should have been rubberised a bit; because your hands are more in-front of the Steam controller compared to contemporary controllers, I do feel like I want a little more grip on the unit.

Overall, I’m now very impressed. Probably the biggest thing is making sure you check the community control schemes if you find yourself bemoaning the generic scheme. From what I understand some games do have specific built-in schemas, but if it doesn’t it’s a safe bet to assume someone has decided to share their ultimate controller layout with the world, and it will probably do the job very well. I have average hands and I’d say the controller makes me consciously reach for some buttons at times, but this isn’t a deal breaker and the controller does what it does so well I can forgive some button-placement fumbles. It’s also the most customisable controller I’ve ever seen and the Steam client allows you to customise everything to a ridiculous degree, which is definitely the secret-sauce to why it can work well with so many different games.

If you play Steam games and have $60 to spare I recommend the Steam Controller, though if you have small hands you may want to find one in the wild and see how it feels first. If you pick one up do try community control layouts as they literally make-or-break your ability to play a game as a poor scheme will make the controller feel useless – but a good scheme will blow other controllers out of the water.

With Halloween settling down and children retreating back to their lairs so they can bathe in their sugary loot, it’s time to post an update, and not just any type of post – but a Spooky Scary Post-Halloween Monster Post!

Wallpapers

Before I get to show-and-tell I wanted to make a quick digression to something we noticed a few months ago after the 5.4 wallpaper was released…

There has always been some pretty harsh criticism against the wallpapers I’ve produced, some of this comes down to being bolder and more vibrant in our designs, and some of it some of it comes down to the fact that my early work was genuinely bad. We listen to comments wherever they come from (even if we don’t specifically reply), be it a forum on a news site, Reddit, or imageboards. Until Plasma 5.3 though the criticism lacked constructiveness and was mostly just mud-slinging. The Plasma 5.4 wallpaper though must have crossed a threshold at some point, because the entire VDG very specifically noticed an uptick in constructive criticism, and a it had a heavy influence on the 5.5 wallpaper.

What this all comes down to and what I really want to say is this; do be critical of our work! But be critical in a constructive way, so we can build on your comments. Calling a wallpaper “dogshit” doesn’t give us much to work with, but pointing out the Dutch Angle of the last wallpaper as being too extreme – that we can work with and improve the next wallpaper. Since we had the feedback, I’ll go over the two main points we’ve heard.

#1: The Brightness / Saturation.
More often worded as “the author must have eaten his crayons before puking on the screen” this was a result of how I initially imitated the 5.1 wallpaper with the Breeze palette, and absolutely failed; so much in fact that I think it may have affected the perceived colours of later wallpapers.

While some people certainly enjoyed the lighter wallpapers the main comment was that the over-saturated wallpapers were too much. Interestingly, wallpapers on Plasma 5 have been trending towards darker tones, below being some swatches I quickly composed of our wallpaper history:

When I started making the wallpapers at 5.2 I had decided to stick with the official Breeze colour palette, which is geared towards icons. This meant that working at the same luminosity Nuno used for the 5.1 wallpaper would oversaturate mine, which is what happened. It’s worth noting that the 5.2 wallpaper was made purely for personal use, and it was only by a fluke that we used it in production. With 5.4 I think we approached the tipping-point of appropriate brightness/saturation, and I think we’re closer to the ‘right’ amount now considering out palette.

#2: The Dutch Angle / Drug Induced Wallpaper
This is a simple fix: stop using intense angles. But! If everything is made flat it becomes visually uninteresting. As a matter of fact none of the KDE wallpapers have been perfectly level, except Nunos original wallpaper which had clear vertical orientation. I think this was just because 5.4 was so extreme, and also because there were no other mounting points a user could visually register.

With the ‘acid trip’ feel of the last wallpaper, I think it was (again) the dutch angle throwing users off a bit along with the fisheye lens of the horizon line. I do worry that such a perception may impact the professionalism of the desktop, so for future wallpapers I may attempt to better avoid this moreso – though this wallpaper does maintain a more organic shape, which I expect may get dinged on that score.

So, what’s in the pipe for 5.5?

I’m very excited to announce we will be shipping 3 wallpapers this upcoming release. The two below continue the evolution seen in previous wallpapers. They are “Event Night” and “Event Day”. Event Night will be the 5.5 default.

Lionel Chauvins’ “Pastel Hills” will also be available, which harkens back to Nunos original design using a lighter pastel palette. I also have the feeling this is the first wallpaper we have distributed made with Blender. I highly recommend checking out his new KDE-look account if you like the smooth jazz that is his wallpaper, hopefully he uploads his other works. 😉

5.5 Wallpaper Contest
Finally, Andreas is continuing his wallpaper contest; the deadline is in roughly 9 days, so if you have a beautiful image you want to submit please jump in and submit your wallpaper!

KDE.org

KDE.org is undergoing a redesign which should one day present a more unified and consistent interface across the myriad of systems we currently use.

The most obvious issues with the current site are twofold; there’s no consistent navigation, and no two systems look alike. Because we have so many systems which are largely incompatible and/or on completely different hardware, we’re taking a unique approach to the new design so we can begin to unify the disparate designs.

We’re building the user-facing elements as a modular set of pieces which can be arbitrarily inserted onto any website, regardless of the technology or hardware they use, as long as they support even the most primitive skinning. These modular pieces are self-contained, and should be fairly easy to insert into existing systems until larger changes can be made.

I’ll have screenshots later (maybe a video) once I finish up a few more modules for feedback. Unfortunately I’ve had exceptionally busy weekends (when I get most of my work done) and haven’t been able to make the progress I had hoped for. I’ll post more on that later.

Fiber Browser

Because I have been swamped with smaller projects I’m temporarily going to put Fiber on hold to nail other things down, as I want to give more time to immediate smaller impacting projects across KDE as a whole, rather than constantly scrambling around several half-finished todos.

The original plan was to have a version which would be “presentable” at Sprints so I could garner interest, but that will be dropped. One thing that has become clear is that other developers will want to work on it regardless of me ‘promoting’ it, so I’m comfortable in the thought that I could assemble a small team later on. Also, the main KDE devs are busy enough anyway.

Next, after (very careful) consideration I may temporarily drop CEF and pick up WebEngine when I seriously resume the project. Fiber is a one-man band, and to say CEF integration has been nothing short of a pain would be an understatement. I feel like the most important aspect of Fiber will be a rich, deep API and modular design – but with so much focus on getting CEF functional it simply sucks the life out of the entire project. Instead, I may shift to a CEF port as a “Fiber 2.0” feature (hopefully when other devs may maintain the APIs), which should help as by then Servo will be more mature and I can test it as the primary renderer.

Unofficially I may still chip away at it – but for now I’m more comfortable saying it’s on pause while I focus on my todo list. I will resume work on it once I’ve bumped off a few smaller things, and hopefully It’ll speed up development a bit by switching to WebEngine for the 1.0 release along with having fewer balls to juggle.

Polish Effort

Before I say anything else, hats off to Hugo for his work. I’m not going to lie: I threw him to the wolves on this one (unintentionally!), and he’s solo’d the real work going into Breeze polish. So, hats off to Hugo for being blazingly awesome!

On the design notes, one thing that became apparent somewhat quickly was the fact that the design I presented began to heavily diverge from the current Breeze design, so much as to be considered a different design entirely. I’m still debating how to handle this, as this is one area where I wanted to free up time so I could more properly contribute.

In terms of stuff getting done, we’ll have some pleasing adjustments to several visual elements such as menus and pixel-tweaks. We’ve also identified several issues such as misalignments in applications, dark-theme colour woes, and inconsistent spacing; I don’t believe we have fixes in for everything, but I’m confident in my ability at throwing Hugo to the wolves. ;P

DWD

There’s not much to report here, but a couple people have been wondering about this. For those not in the know, DWD will be a protocol-driven solution for widgets in the titlebar, similar to the CSD approach that is the Gnome headerbar.

Mainly I’ve been working on the specification, and it’s been pointed out that DWD as a technology will never be suited for insanely weird and creative widgets. To mitigate this I had written some crazy crap about all the special and unique ways a widgets might be customised, and I realised it was pointless to try matching the “creative potential” of CSDs with endless options. I did a thought experiment and swung the other direction;

What if instead of offering primitive widgets with crazy tweaks DWD focused on higher-level but rigid purpose-driven widgets? You don’t request a slider with a volume icon, you request a volume widget and feed it a few channels. Instead of a lineedit you’d just put up a search box… And this approach shaped up surprisingly well.

The general mindset is the idea that CSD eschews system integration in exchange for more radical customisation. DWD on the other hand is about integration though standards – and the initial spec didn’t play to that strength. The main downside to this new spec is the fact that we do sacrifice more creativity in the headerbar, but I looked at it, and in most screenshots of Gnome CSD widgets seem remarkably standardised as well. I’ll be doing a post later which gets into details and pretty pictures but this seems to be the direction to move towards.

That’s all, folks!

Random Sluggerfly!

Thing-Explainer is a book being written by XKCD’s Randall Munroe which tries to explain complex concepts and objects – using only the 1000 most common words in English.

He released is writing tool “Simple Writer” today which makes sure he doesn’t use an “uncommon” word, and I *had* to try it. After being disappointed by “Little Red Riding Hood” using common language, I decided to turn up the heat a bit and re-write the Wikipedia entry on Hard Disk Drives…

It’s actually really, really hard in spots.

A spinning drive, “hard drive”, hard plate drives or fixed plate is a information keeping thing used for storing and getting computer information using one or more hard fast spinning plates coated with special stuff that keeps information. The plates are paired with special heads put on a moving arm which goes up and down, which read and write information to the plate surfaces. Information is read in a from anywhere it finds it, meaning that single blocks of information can be stored or read in any order rather than one-by-one. Spinning Plates keep stored information even when powered off.

Made by World Business Machines  in 1956, Hard Plates became the most used runner-up information keeping thing for not-different computers by early 1960. Made better over time, Hard Plates have stuck with this position into todays big computers and personal computers. More than 200 companies have made Hard Plate things, though most of them are made by other companies. World wide spinning plate money gatherings were US $32000000000 in 2013, down 3% from 2012.

The main points of interest of plate drives are how much they can hold, and how fast it can read and write. How much it can keep is written in number-letters telling us how many 1000’s it can hold. In most cases, most of what it can hold is not for people because it is used by the map of things in the system and the thing that makes the computer do stuff, and sometimes built in mirrors of the stuff in case things go wrong and it has to be fixed. How fast they can go is kept by the time needed to move the heads reading stuff to a track or plate (usual look time) and the time it takes for the wanted part to move under the head (usual time until it gets where you want it, which is held back by how quick it can spin around each minute), and finally how quickly the stuff is pulled (read time).

The two most usual forms for todays spinning plates are 3.5 fingers wide for tall personal computers, and 2.5 fingers for small flat computers. Hard plates are joined to systems by information sharing lines such with different ways of sharing the information.

As of 2015, the main other way of keeping information is flash memory in the form of drives that do not spin, which are quicker at sharing information, less chance of breaking, and takes less time to find information, but spinning drives remain the main way for keeping stuff because it is less money to keep things on the drives. However, drives that do not spin are taking over spinning drives where being quick, eating power, and less problems are more important.

It’s been about a month since my last update? Maybe I should post something.

Fiber has been a bit slow moving, partly because I’ve just been slow and hitting other projects, but mostly from toying around with CEF. One prominent issue is the fact that the current crop of CEF examples and samples are using a mix of GTK and X. Many outdated questions and forums on the web bring up Qt and CEF, but with the relatively limited time I have to work on the project it has made things feel slightly more arduous than it needs to be when there’s no answer to the problem. Part of this is the fact that Qt has WebEngine/WebView, so CEF integration is a niche topic. It’s nothing insurmountable, but I might need to accept a temporary dependency on X. This annoys me, but the project needs to move forward and I can’t be stuck spinning my wheels. At the lowest level of the application I will need platform-specific code anyway, I simply wanted to see how long I could avoid it.

“Did you ever solve for X?”

(more…)

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.