Steam’d Controller

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.

Spooky Scary Post-Halloween Monster Post

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:

swatchesWhen 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.

desktopWallpaper-event-1.0-kvermettedesktopWallpaper-event-light-1.0-kvermette
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. 😉

2560x1600

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!

sluggerfly

Random Sluggerfly!

I converted the opening of Wikipedias’ “Hard Disk Drives” article into Thing-Explainer logic

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.

Fiber, X, Ad Blocking and Tracking

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…)

The Fiber Engine Poll, Updates, and Breeze

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 Update; WebEngine vs CEF

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.org Redesign

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

New artwork coming in 5.4 & the tale of a troublesome wallpaper

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/

image10430After “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…)

Google Deep Dream ruins food forever.

Google Deep Dream is an interesting piece of AI software which looks for patterns in pictures, much like humans may look for patterns in clouds. Deep Dream has been trained to find a few things, like eyes, animals, arches, pagodas, and the most fascinating part is that Deep Dream can also spit out what it “saw”. Then Google opened Deep Dream to the public and people started loading tonnes of images into the system, and when you combine food with Deep Dream it turns into the stuff of nightmares.

RUN NOW OR FOREVER RUIN FOOD FOREVER! Here’s pictures of food turned to ghoulish nightmare-fuel courtesy of Deep Dream;

Nope. NOPE. Great start. Never eating takeout again. At least nothing bad can happen to the humble doughnut.

Duncan Nicoll, thank you. Via Ibitimes

Duncan Nicoll, thank you. Via Ibitimes

GREAT. FANTASTIC. I didn’t like doughnuts anyway. ARE THOSE LEGS?

Ibitimes also had this. Spaghetti & nightmares.

Ibitimes also had this. Spaghetti & nightmares.

I loved pasta. I did once. Then, this. Now never again.

Asian soup via Reddit. Dammit Reddit.

Asian soup via Reddit. Dammit Reddit.

Asian soup creeped me out anyway. BUT IT DOESN’T HELP WHEN THE SOUP LOOKS AT YOU WITH MANY, MANY PUPPY DOG EYES.

Via Vr-Lab

Via Vr-Lab

Hey, look, what a diverse menu of terror!

I’m never, ever eating Asian again. Why does so much of it look fishy?

Thanks, again, VR-Lab.

Thanks, again, VR-Lab.

I, too, would be in the foetal position if my soup was a WRITHING MASS.

VR-Lab.... Shtap. Please.

VR-Lab…. Shtap. Please.

NO. NOT PIZZA TOO. I’M OUT.