Yesterday I did lead my first 30 meters pitch (Girotondo, 5c in Finale Ligure) that’s quite another level of scary compared with the ~15 meters stuff I was used to, and quite literally “pushing your comfort zone”.
When you see the last quickdraw you placed 3 meters below you (and the ground 20-something) and the next bolt just a couple of moves away.. just a couple too much, all fibers in your body tell you “give up”, fingers are starting to slip, they want to slip.
But you really rather not want to give up, because again, the last quickdraw you placed is 3 meters below you, so the fall will be very long (and scary, and potentially painful), and because what the hell, you came all the way up there, just to give up?
You just say fuck pain, fuck the fear, and just keep moving forward, one slow move at a time, just try to clip a quickdraw to one last bolt, and then I’ll maybe give up there, after all even if I fail, yes the fall will be long and scary and potentially painful, but at least I know I failed trying. All the safety precautions were taken (is a surprisingly safe thing to do, once you go manically through the checklist, it’s a *very* security conscious community) so while accidents do happen, usually the “worst thing that can happen” is “not very much”. In that controlled environment you learn to replace pretty quickly the “should do this”, “should have done that when I could” with the “just go for it”.
This post wanders quite off topic… but has a lot of pretty pictures indeed 😉
Sometimes I ask myself why I am a software developer, the answer in the end is that I always enjoyed creating things, whatever it is going from being sketched out totally in my imagination to finally seeing it in the flesh. Writing software, especially graphical software can be very satisfying exactly because of this mental process of seeing the thing you thought about slowly forming and starting to actually working, with the gap between the mental image and the real thing narrowing more and more (yeah, I’m one of those heavy visual thinkers that can think almost exclusively by images).
But sometimes nothing can replace the satisfaction to create an actual, beautiful object, and I also feel manual skills are something that we should cultivate much more, I feel more complete if every now and then I do something that a) I don’t know anything about when I start and b) it’s a difficult manual skill to craft.
That’s also why before drawing the svg for the Kirigami banner
I “had” to make some experiments of an actual kirigami…
But this post is not about that.
Almost a year ago, a friend of mine told me that he wanted to learn a bit to hack on some simple Arduino stuff, and you know what? I wanted too.
I have this stubborn quality that makes me to go quite overboard when I decide to do something (especially if is not for myself) and not to stop until is done, actually useful and pretty, so if we are doing some Arduino project, let’s do something that has an use and that will be pretty… and that’s how the project “Bagnur” started (means watering can in Piedmontese language).
Of course it needed a logo :p
The project is one that is seen again and again on the interwebs, so is just a remix of existing ideas rather than something truly innovative: the Arduino takes data from a soil moisture sensor (different humidity in the soil changes current conductivity), to figure out how much water the soil of a potted plant has.
When is dry enough it opens a solenoid based valve to pour enough water in, and the moisture sampling goes on and on, hopefully stopping you from killing those poor potted plants from thirst after forgetting watering them for days 😉
The final hand made steampunk-like package
The moisture sensor is based on the LM393 chip, the solenoid valve is similar to this one (hilariously overspec for this project, love this kind of overkill).
So we know the Arduino output pins have a too weak current to operate the valve, it will have to be powered separatedly: the Arduino will close its circuit with a transistor, I had just salvaged an E13007 NPN transistor that had useful charateristics (low base-emitter saturation voltage, resists quite heavy loads) from a broken ATX power supply.
This makes things a bit more interesting, luckily in the end a single power source was enough to power the Arduino and the valve in parallel, probably not particularly recomended, but cheap and compact (having 2 different power bricks for such a sillyness wouldn’t have been particularly fun for day to day use).
To make the project a bit more interesting, we have a potentiometer that will regulate how much water the plant needs, different plants, different needs and one of those pretty RGB LEDs, that will be the “output UI” of the thing.
The state of the led will be:
Fading from pure red (soil bone dry) to pure green (soil soaking wet) with all the values in between
Fading to blue when the valve is open, and the plant is being watered
The LED will stay usually at a very low power, the sensor will do a reading every 10 seconds or so, when this happens the LED will fade to full power with a nice animation
For the final thing, I decided to use an Arduino Nano compatible board, based as well on the ATMega 328 chip, since I don’t need many pins or performance, it just has to be as small, low power and cheap as possible.
In this Github repo there are both the source code of the program running in the arduino and a couple of schematics drawn with Fritzing, so it should be of easy replication and improvement… if someone really wants to 😉
The final board will be in an hand-made case made of wood that gives it a cool almost “steampunk” look: that was honestly for me the most fun part of the project of all, probably because was the farthest from what I usually do, the most low-tech, hand skill demanding part (and slightly dangerous… yep, it involves rotating blades :p).
Video of the thing in action
This videos shows some assembling steps and the thing in action, both opening the valve automatically based on the moisture sensor values and manually with the button on top.
Let’s start from the usual prototyping with the classic Arduino Uno/breadboard combination (here still with different colored leds instead of the final single RGB one)
After the breadboard prototype is done, let’s start to lay out the components on a perfboard, to make it look more like a final prototype, usable day to day
First components attached to the perfboard. The Arduino Nano will connect it as a daughter board.
Yep!, i definitely need to improve my soldering skills, but I swear, even if is kinda ugly, it works like a charm 😉
Still some components missing, already attached to the wooden base
As I mentioned, for me the most interesting part was to build a wooden case from scratch, from a raw plank of wood, trying to master some of the classic woodwork tecniques.
The plank is made thinner and smoother via a thickness planer; after this step the setup of the machine changes becoming a surface planer for a more precise and smoother retouching. The process repeats until the wood reaches the desired thickness.
Did i mention, ROTATING BLADES?
All the sides of the box are done
After the box has been glued, it has to be tied very, very tightly as the glue dries
The joints are not very precise …yet
…But some aggressive sandpapering for sure helps, best if done with a Sander
The lid of the box with a translucent, water proof paint, attached to the top are the moisture sensor, the RGB LED and a button to manually open the valve.
The complete device, ready to be closed. The wires on the left control the RGB LED, the blue and green wires in the middle control the button, the wires on the right control the moisture sensor.
The completed little, mean machine.
It has been an insanely fun project, and I am sure my technique can still improve in all areas (designing an electronics board, soldering, woodwork…). If I’ll keep trying to improve with new projects I don’t know yet, but the recomendation I can make is get out of the comfort zone of your day-to-day work and experiment: you have only to gain, if only for the act of doing things wrong, without which there is no learning.
Over the second week of March I’ve been at the sprint at CERN.
It has been an amazing experience seeing those very big toys, where the cutting edge research is done (noted with satisfaction the presence of Plasma desktops in the CMS control room)
On my side, some interesting little things happened:
All new systemtray finished and merged
During the sprint I’ve merged a thing i was working since a while: the system tray of Plasma was one of the most complicated plasmoids out there due to the very peculiar things it does.
Its code was really showing its age (it surviced at least 3 portings across different technologies) and even tough the old Xembed-based systray icon protocol was dropped, its architecture was still decidedly all
It has now been completely rewritten, its code is now way simpler, using less layers of proxymodels and went from ~2000 locs of C++ to ~300
While completely new, the users shouldn’t even notice any UI change, the only noticeable change should be less bugs and working better 😉
During the sprint, a new repository was born.
What was Plasma Mobile components is now residing in a separate git repository: https://quickgit.kde.org/?p=kirigami.git Kirigami (The names comes from a Japanese paper folding craft similar to Origami, but unlike Origami cutting the paper is allowed) is a set of QtQuick components at the moment targeted for mobile use (in the future desktop as well) targeting both Plasma Mobile and Android. It’s not a whole set of components, all the “Primitive” ones like buttons and textboxes are a job for QtQuickControls (soon QtQuickContrls2) but it’s a set of high level components to make as easy as possible making applications that look gorgeous on mobile devices that follow the Visual Design Group UI guidelines.
The target of those components is anybody that wants to do an application using QtQuick as its main UI, especially if targeting a mobile platform, without adding many dependencies. They work both in Plasma Mobile and Android.
It will eventually become a Tier-1 KDE Framework.
While I was refining the components, it turns out a piece of desktop software just has its first release of its Android port, it is already using a tech preview of the Kirigami components: it’s Subsurface a dive log software started some years ago by Linus Torvalds (in GTK+) and recently ported over Qt (here a talk by one of its main developers Dirk Hohndel about the porting process https://www.youtube.com/watch?v=ON0A1dsQOV0)
It’s awesome having already an early adopter (which has been a pleasure to work with) for the components and also means we are getting a ton of feedback on it.
Quoting from the announcement:
“KDE Neon is the intersection of these needs using a stable Ubuntu long-term release as its core, packaging the hottest software fresh from the KDE Community ovens. Compute knowing you have a solid foundation and enjoy the features you experience in the world’s most customisable desktop.”
This is pretty exciting for anyone who wants a stable core system with a setup of KDE Plasma software on to as recent as possible, setted-up and configured as good as possible, with hopefully less issues like “distro X has a slightly outdated version of kibrary Y which is know that makes app Z crash”.
Hell, I was so excited that during a sleepless night, I has been completely possessed by the Muse and I had to do this artwork based on a riff of its logo:
NEON written as a neon sign, how original :p It’s pretty tacky but it’s intended to be, here for your viewing pleasure at a typical wallpaper resolution.
Yesterday I was notified of this little neat project: github.com/encharm/libsystemtray
(And yes its author would be very happy about feedback patches and so on 😉
Basically it’s a pure C++ library with very few dependencies that implements the support for StatusNotifierItem enabling systemtray icons in KDE Plasma 5 and Ubuntu Unity.
recomonded to be used by C++ applications that don’t actually depend from Qt or GTK and want to keep their dependency footprint very small (it’s Mit licensed so should be ok to use it from an app based on any license)
So now there are officially no excuse to not use our new shiny system tray 😉
This is the second part of my ramblings about the Plasma 5 release, just after it come out.
This is a very important moment, after a massive amount of work.
What are the most important things that can make a free software project successful or not?
To me are principally two: user experience and developer experience.
The first release of Plasma 5 will start to make use of the work of a newly formed group in the KDE community: the Visual Design Group.
I’m very impressed how they managed to get a firm grip of many issues that are always been a problem in KDE software.
They are not only doing nice pictures, but rather starting to give real guidance to the design direction of the future Plasma and applications by KDE.
On the 5.0 release, the most visible thing will be the Breeze theme, that while still far to the final vision, it starts to show the clean and functional style (funny trivia: I remember discussing on the VDG forum about pure flat design versus using 3D effects for “interactive” controls, to give depth and intuitiveness for interactive areas… months before Material was presented. Those guys are definitely onto something.)
But it of course doesn’t stop to a theme and some icons:
what is more deep and a long term plan is to review the look, refinement and usability of pretty much.. everything.
Good design means also every single application has a clean and functional layout, and its “interaction flow” is logic, intuitive and derived from user needs rather than the technical details of the application.
An example of those things still to come is the new layout of System Settings that will come in little piece by piece, one by one in the future releases (The 5.0 release already has a new categorization, each release will move it a step more towards the final design).
Freedom, in all aspects
A big challenge in the design of Plasma 5 is that while providing a very simple and appealing experience out of the box, our central value is to put our priority in serving the different exigences of different kinds of users, because, as for devices, one size does not fit all.
The Plasma workspace is now even more flexible, on different devices it will sport completely different default user interfaces, because different use cases and different input methods require a different way to interact and a different way to present information (as lately even Microsoft discovered, in the very hard way).
And not only that, on your desktop or laptop, you can “build” a workspace experience as you please, optimized to your preferences.
We will never force you to a panel in a particular side of the screen, or to one task manager mode (taskbar vs dock) or to a particular desktop layout.
We well know that this makes the design process more difficult, but often the “easy” solutions are not necessarily the “correct” ones.
We give you a desktop that can adapt to you, rather than giving you a desktop you have to adapt to.
In later years, with the bigger emphasis on the user experience, the experience for developers started to take the back seat.
But we are a free software project, and its success is measured not only in users, but also in how many people would want to engage in an active way, and how comfortable are developers to work on the projects.
Being built on a foundation as strong as Qt, the software by KDE can also offer amazing tools for developers.
The recently released KDE Frameworks 5 is an important step in this direction: the KDE libraries are not anymore a big monolith but a set of very small, useful and independent libraries.
The base of the Plasma Shell is a framework as well: the Plasma framework, composed principally by two things:
The Plasma library: is the good old libplasma.. but it’s way slimmer and more focused than the KDE4 version: It doesn’t offer graphical widgets anymore, and doesn’t make any assumption on what graphic engine will be used (One could even build a shell completely based upon QWidgets with it, just because :p).
It continue to provide easy access to packages, dataengines, asynchronous services and the save and restore functionalities of the layout, known as the Corona. The library solves problems that are out of scope for QML: from a surface with interactive graphical elements in it, it brings it to a “full featured desktop shell”.
The second part is instead a set of runtime components, of QML bindings that offer QML access to the Plasma facilities such as dataengines and svg themes and a set of graphical components to use in QML plasmoids and applications, such as buttons and text fields, that are converging, and will converge more and more with the upstream QtControls project.
In future releases there will be a comeback of the kpart to easily include qml-based informational dashboards into applications, and a runtime to launch plasmoids as simple independent mini applications.
Looking at the future
So, what are we planning for the future?
The stable, default core Desktop project will become more and more stable and polished, but the development focus will touch other use cases as well.
The Plasma Active port to Frameworks 5 is ongoing, as well the Plasma Mediacenter port, so the “different shell for different devices” story will be complete.
Of course our focus is not only about KDE on different devices, but also making KDE work tightly integrated with other kind of devices, thanks to projects such as KDE Connect. Interestingly, The Plasma Workspace 4.x series is today the environment with the tighter integration with smartphones (only with the next releases of their operating systems Apple is catching up, with a quite similar feature set).
You can expect this integration work being even more complete in future releases of Plasma 5.
Finally, the artwork presented in 5.0 is only a preview of what is still to come from the Visual Design Group: more icons, more complete widget set, more and more applications will receive a makeover look-wise and most importantly usability-wise.
We are very, very near the release of the new Plasma release by KDE (more on the nomenclature later).
This is the first entry of a short series of blogs that take a look about the past and the future of Plasma, what we learned from the 4.x series, what changed, what we can take away and to expect for the future.
First, we were (and we still are) very happy about the status of the Plasma desktop as seen in KDE 4.x, but this doesn’t stop to wonder what can be improved.
The Plasma Desktop started to migrate towards QML since quite some time, but it was clear that the real focus in Qt 5.x would have been QML2.
That’s awesome, because QML2 solves many limitation in performance that QML1 and the QGraphicsView framework had in Qt 4.x.
But that was also a problem, since Plasma1 was tightly coupled with QGraphicsView, this meant: a lot of work ahead.
What we wanted, was the plasma platform itself completely independent from any graphical system itself.
From a big monolith-that-provides-everything, libplasma would have become a way smaller library (roughly 1/3 of the code of the plasma library in 4,x), providing a *model* for the layout, and utils as painting utils and the usual data access, but the representation of this model, would have been completely up to the shell (more on that next entry).
I remember starting a branch of libplasma back in summer 2011 at the Berlin desktop summit (that was also when the Frameworks development seriously started to seriously gain steam). The thing lived as mostly a proof of concept for a while.
Fast forward at the end of 2012 and we had a minimal shell that started correctly and could correctly restore a layout of applets, in a minimal desktop (no panel yet!).
The work proceeded and the features got back one by one.
In the meantime many new people joined the effort (Some thanks to Blue Systems, some volunteer) significantly speeding up the process.
Fast forward to the beginning of 2014 and it was possible again to use it as a basic main desktop (eat your own dogfood).
Just to give a little idea of the amount of work, there are around ~5100 Plasma5-related commits only on the plasma-frameworks repository, if we count all the workspace parts, it would be a way bigger figure.
It has been a long road, with some (quite) rough moments in the middle for sure, but looking back I’m pretty proud of what we achieved, of what i did, and what every single member of the team did to get here.
But this, this is
Just the beginning
This is the first release of a new chapter of Plasma, in which a new release method will be used to celebrate the diverity of the KDE community.
We used to have a 6 months “big release” of all things KDE, called in the beginning just “KDE”, then “KDE SC”, but this release is not that anymore, because KDE grown a lot in the past years, is not just that anymore, and “a single release of everything” scales only so much.
So, let’s take a step back and see what is KDE: it is a community that can offer you a range of very different things:
Want a primary user interface for your Desktop, Laptop, Tablet, Media Center? There is Plasma, tailored explicitly for the particular device is running on. Desktop and laptops have an interface optimized for mouse,keyboard and trackpad input, Plasma Active and Plasma Mediacenter are instead tailored on the constraints those different kind of device pose instead.
Do you need a particular application for a particular task? The KDE community offers a wide range of applications, from media players, communication tools, games, to a kickass office suite, to one of the best painting applications on the market (not best on Linux, not best among Open Source ones, the best, period) and countless others. They are free software, they are multi platform and supported by a vibrant community of developers.
Are you a Qt developer that is working on a new application, and need more functionality? KDE Frameworks offers a wide variety of libraries and frameworks to chose from that can dramatically decrease the amount of work needed to do a big, polished application.
And in the latter case, if you want, of course your project is more then welcome to join in the KDE family, as other formerly external projects already did, like KDEnlive or GCompris
This release of The Plasma Desktop Workspace can be used for day to day use already, even tough it’s based on very new technology, so some youth problems are expected as well. Also, while the integration between KDE4 and Plasma5 applications is good, you may want to wait more applications ported to Frameworks 5 before jumply completely full on a pure Plasma 5 environment.
So, when a new version will arrive? how do you check if new applications come?
The development cycle will be much faster now: you can expect a new release of the KDE frameworks (so the libraries, *not* the applications) every month, while Plasma5 will be each 3 months instead for now.
Anyways, new goodies should hit your distro of choice way faster than it used to be in the past.
Next time, I’ll write about what to expect in this release and the next ones about the user experience, the developer experience, and random musings on the future.
Starting from today, there is a new category in kde-look.org explicitly for Plasma 5 QML2-based plasmoids.
As it used to be, they can be browsed, installed and uninstalled directly from the “Get new widgets…” option in the Add widget interface.
As you can see, the list is rather empty right now, but I’m looking forward to see the plasmoids published by the community.
You may have heard that KDE Plasma Next won’t support anymore the old X11,Xembed-based systemtray icons.
(More information here)
Years ago, we developed a nicer, model/view based alternative in which is the shell that actually draws the systemtray icon, allowing better integration with the workspace, it’s a specification that is now shared between KDE and Ubuntu Unity.
All KDE applications use it already, Qt4/Qt5-only application will use it depending on a small patch (and soon Qt5 will do out of the box)
But also GTK has some options: until today I was aware only about the Ubuntu’s appindicator library, but I have just been contacted by the author of another neat library, that can be found here on GitHub.
It’s a very small, few dependencies GObject-based library that allows a GTK3 application to export and control a statusnotifier-based systemtray icon. I just tested it on KDE4 and Plasma Next and seems to work quite well.
So if you have a GTK application that is using a systemtray icon, and you would like the icon to be integrated in the next version of Plasma as well, now you have an option more (and of course, the author will be happy of any patch/bugreport/bugfix).
Work in Plasma Next is proceeding frantic as usual.
We are around a week from the release of the first Alpha (mark your calendard from a week from now), and the feature count is getting close the current release of KDE Plasma Desktop, in order to get the transition as smooth as possible.
Of course we aren’t trying to just do a carbon copy port, but to give some nice new features and improvements, such as a dramatically better behavior of the system tray (no more weird popups-from popups!), waay better support for high DPI screens and a nice new rewamped notifications system and UI.
The big thing tough is the new capabilities of the frameworks: KDE Frameworks 5 and the new Plasma Framework, with a desktop shell all based on QML2: so many things that in the past we couldn’t do, now will be possible.
And now as usual, a sneak peek of something that will not be in the alpha release yet.
The KDE Visual Design Group is doing a terrific job across very different areas of Plasma Next, the little area I’m collaborating with is the Plasma theme itself (a lot more nice stuff in many different areas will arrive from them in the future). I must say I’m impressed by their work.
But what if I have a screen with a ludicrous amount of DPI?
All of this is heavy under construction, so is still subject to a *lot* of changes until the final version 😉