Now just 23 bugs to fix before release. We can get there with your help.
The second Beta of Vivid (to become 15.04) has now been released!
The Beta-2 images can be downloaded from: http://cdimage.ubuntu.com/kubuntu/releases/vivid/beta-2/
More information on Kubuntu Beta-2 can be found here: https://wiki.kubuntu.org/VividVervet/Beta2/Kubuntu
Apologies but upgrade from Kubuntu 14.10 is currently broken due to bug 1426132; a fix will be available shortly.
As you probably know by now, Gitorious is shutting down. A lot of history sits on that site, and much of the code is no longer maintained. Browsing around, I ran into the maemo-tools that has not been touched since 2013. There are still some useful stuff there, so I decided to save it. All tool repositories has been cloned to the maemo-tools-old organization on github.
As I’m only a happy user, I would love to invite the original maintainers, or other interested developers to come work on it, so if you want an invite to the organization so that you can maintain the code, just drop me a mail at e8johan, gmail, com.
It has been very quiet around WEC platform support in Qt, and you would have been forgiven for thinking that nothing was happening. But behind the scenes, we have been tackling some pretty hard issues. We just did not blog about the ongoing work……until now.
Be assured that the platform is still maintained and there is work happening. Here is a short overview of the work my co-worker at KDAB, Andreas Holzammer and myself have done on the WEC support.
Qt Multimedia is still listed as a not supported module for WEC. This has changed slightly as we reintroduced the ability to playback audio files based on the DirectShow backend: https://codereview.qt-project.org/#/c/93093/.
We also tried to restore the Video support, but faced unknown error messages from DirectShow. The idea of reviving the support is not gone, but delayed until we find a solution.Deploying Qt Applications
Deployment of Qt applications can be quite a hassle. You have to know which plugins and modules your application uses and make sure all the required files that are not stored in resource files are deployed. This is especially bad if you have Qml files and plugins. The Qt Company introduced a very useful tool to ease the deployment on windows, called windeployqt. In January we finally got the support for WEC in the windeployqt tool upstream: https://codereview.qt-project.org/#/c/92707/.
This helps to simplify the deployment of Qt applications onto a target. You still have to manually copy the files and the libc++ runtime to the device, but all the Qt dependencies are correctly packaged to a folder of your choice by running a simple command.Multitouch Support
Last but not least we have integrated a new feature into Qt 5.4. We introduced multitouch support for WEC based systems, this means we have two-finger multitouch working in Qt on WEC platforms. This happened in January when we implemented support for GID_DIRECTMANIPULATION: https://codereview.qt-project.org/#/c/104040/.
Only two touch points are supported due to the very simple WEC api for this, which only offers us two. The new feature allows WEC7 Qt application to use all the Desktop gesture recognizers.
While we were implementing the multitouch feature we discovered that the delivery of touchpoints and gestures was not working properly. The events weren’t reaching the correct widgets most of the time. The reason was a porting bug from Qt4 to Qt5, where the new call for the Desktop api was available on WEC7 but didn’t work properly. This led to the inability to find the correct child window for given coordinates. The bug we fixed was QTBUG-44022.Ongoing work
As WEC7 is already a very old platform and Microsoft has already released the successor, we were looking for an integration of WEC2013 as a supported Qt5 platform. Recently we succeeded to compile and deploy a Qt5 application to WEC2013. Our hardware platform still gives us trouble with Qml Shader elements, but simple QtQuick2 applications are working already. The port will go into Qt very soon. First we need to verify what features are working and take a look where we can now actually use the more feature-rich desktop code paths. This should ease maintenance and will allow us to fully leverage the capabilities of a new platform.
We will blog about the release of Qt5 WEC2013 platforms support in the near future when we have pushed the support upstream.
The post The current state of Windows Embedded Compact(WEC) platform support in Qt appeared first on KDAB.
Of course, with Free Software, there is a challenge. Help us find the missing icons.
Jonathan Riddell ask on planet kde in November 2014 if we can make a Breeze icon set for LibreOffice. He also start a wiki page about the used icons. In the end of November Uri the main icon designer make 150 LO icons and after that the infrastructure in LO was prepared to have the posibility for another icon set (https://gerrit.libreoffice.org/#/c/13043/)
Now 4 Months later I proudly present the new LO Breeze icon set. We make more than 2.500 icons so that the Breeze LO icon set is mature. In future we can offer Oxygen and Breeze icons for LibreOffice. What do you say? I say whow. And I say thanks to the LibreOffice design team to offer us the opportunity to customize LO and for the warm welcome. Maybe breeze will be the backup for Sifr the LO monochrome icon set, because breeze is much more complete than Sifr. You be welcome to change this ;-)
Now we have an easter egg challange for you. The last missing icons are sometimes not easy to find. So download the daily build (please wait until 26.03. I was to fast with the blog post) with the new breeze icons and search for missing icons. please comment on the blog post with an screenshot and a short description.
In addition to LO we also make Breeze icons for Kdenlive, Labplot, Yakuake and now I start with Digikam. If you want Breeze and Breeze-dark icons for your app, leave a post on the VDG Forum or an Issue on the Breeze Git repository.
We have also a realy nice resolution for icon temes, look and feel packages (megathemes) and app specific icons. YOU as the app developer can say which icon set you will support primary in your app. For example Oxygen. So you have to offer all app icons for oxygen. If the user want to use breeze-dark in the breeze-dark iconset from the system the app specific icons are included. So the user get an consistent look and feel on breeze and breeze-dark and the developers can offer what they like.
Of corse you can join us. Monochrome icons are sometimes difficult to find the right recognizion but easy to design. At google code in I had some realy realy good icon designers like Artem (no designer) or Buno. I will hope they join us again and you too. So leave a icon on https://github.com/NitruxSA/plasma-next-icons.
I ask my google code in student Artem why he support KDE:
My name is Artem, i’m 17 years old programmer from Amursk, a small town in the far east Russia. I’m study in public school and lead an ordinary life. I support KDE because… To be honest, i don’t know. It’s just fun. I do useful things and its great. Btw,i don’t even use Linux (i used to use it, and i wish i will switch my main os to kde based linux distro in the future, when dotnet will be officially crossplatform).
I’ve visited both FOSDEM and SCALE over the last weeks, where spoke with dozens of people and gave talks about ownCloud 8. We’ve been getting a lot of positive feedback on the work we’re doing in ownCloud (thanks!) and that has been very motivating.Does it scale?
A question which comes up frequently is: “What hardware should I run ownCloud on?” This sounds like a simple questions but if you give it a second thought, it is actually not so easy to answer. I had a small cubox on the booth as a demonstration that this is a way to run ownCloud. But development boards like the Raspberry Pi and the cubox might give the impression ownCloud is only suitable for very small installations – while in reality, worlds’ largest on-premise sync and share deployment has brought ownCloud to 500,000 students! So, ownCloud scales, and that introduces the subject of this blog.
If you look up the term scalability on wikipedia you get the explanation that software scales well if you get double the performance gain out of it if you throw twice the hardware at the problem. This is called linear scalability, and rarely if ever achieved.The secret to scalability
ownCloud runs on small Raspberry Pi’s for your friends and family at home but also on huge clusters of web servers where it can serve over hundreds of thousands of users and petabytes of data. The current Raspberry Pi doesn’t deliver blazing fast performance but it works and the new raspberry pi 2 announced last month should be great hardware for small ownCloud deployments. Big deployments like the one in Germany or at CERN are usually ‘spread out’ over multiple servers, which brings us to the secret sauce that makes scalable software possible.
This secret to building great scalable software is to avoid central components that can be bottlenecks and use components that can easily be clustered by just adding just more server nodes.How ownCloud scales
The core ownCloud Server is written in PHP which usually runs together with a web server like Apache or ISS on an application server like Linux or Windows. There is zero communication needed between the application nodes and the load can be distributed between different application servers by standard HTTP load balancers. This scales completely linear so if you want to handle double the load because you have double the users, you can just double the number of application servers making ownCloud perfectly scalable software.
Unfortunately an ownCloud deployment still depends on a few centralized components that have the potential to become bottlenecks to scalability. These components are typically the file system, database, load balancer and sometimes session management. Let’s talk about each of those and what can be done to address potential performance issues in scaling them.File system scalability
The file system is where ownCloud has its data stored, and it is thus very important for performance. The good news is that file systems are usually fast enough to not slow down ownCloud. A modern SSD, RAID setup, NFS server or Object Store can deliver data rates that are a lot faster than the typical internet network uplinks so you rarely bump into limits with data storage. And if you do, there are solutions like GlusterFS which help you scale performance quite easily. On the App server, a properly setup and configured Temp directory is important to achieve good performance as data has to flow via the ownCloud installation to the user (sync clients or web interface).
Sometimes, this isn’t enough. If you have to handle petabytes of data, ownCloud 8 offers a solution developed together with CERN. This solution lets ownCloud act as a storage broker to direct read and write requests directly to the storage node where the data resides. The result is that that no actual payload flows through the ownCloud servers anymore and the storage performance is entirely dependent upon the data storage itself. Thanks to this solution, the file system storage should never be the bottle neck for ownCloud.Database scalability
ownCloud uses a database to store all kind of metadata so it depends on a database which is very fast and scalable to keep performance up. ownCloud can use enterprise databases like MSSQL and Oracle DB which offer all kinds of fancy clustering options. Unfortunately they are proprietary and not necessarily cheap. Luckily there are Open Source alternatives like PostgreSQL and MySQL/MariaDB which also offer impressive clustering and scalability options. Especially MySQL combined with a Galera cluster is a very nice and fast option that is used by a lot of the larger ownCloud installations.
Note that scalability doesn’t always mean big! Scalability also means that ownCloud should run fine on very tiny systems. Some embedded systems like the first Raspberry Pi had very limited RAM. In such situations it is nice to use SQLite which is embedded in the PHP runtime and has a very tiny memory footprint, saving precious system resources. This is is all about choice for the right system size!load balancer scalability
If you have more than one application server than you need a way to distribute the incoming requests to the different servers. ownCloud uses a standard protocol like HTTP so that off the shelf solutions can be used for load balancing. There are standard and enterprise grade appliances from companies like F5 that are very fast and reliable if used for redundancy with a heat beat. Nowadays there are also very good and affordable options like the Open Source HAProxy on top of a standard Linux system available. This also works very well and is very fast. If you really have a lot of traffic and don’t want to buy hardware appliances you can combine several redundant HAProxy servers with DNS round robin. This has to be done very carefully so that you don’t compromise your high availability. There are several blogs and articles out there describing how to set up a system like this.Session management scalability
There are two fundamentally different ways to do session management which are both supported by ownCloud. One is local session management on the application servers. The other is a centralized session management. I don’t want to discuss the pros and cons of both solutions here because they are a lot of aspects to consider. But with regards to scalability I want to mention that the simpler solution to have local session management together with sticky connections has the benefit that it does not need a central component. This means that it provides linear scalability. If a centralized session management is used then something like memcached is recommended and supported by ownCloud because it can also scale easily internally.summary
ownCloud has been designed to scale from tiny embedded systems like a Raspberry Pi for a few users to a standard Linux server for a small workgroup to a big cluster for several hundred thousands of users. A wide variety of solutions and technologies can be used to make this possible and if you are interested in ways how to do this than have a look at the owncloud documentation for more information and look at the third party resources and white papers available for this on owncloud.com
I'm holidaying in Alaska for a few weeks around June, anyone has been there and can share the stuff we should totally not miss/do when visiting?
Last week I had to work with docutils, a Python library to turn reStructuredText (.rst) into documentation. I was using it to extend a Sphinx-based documentation I am setting up. It was quite a frustrating experience: despite loads of search, I could not find any simple, working examples demonstrating Docutils API usage. To save me (and possibly you) some more frustration next time I need to use this library, I am writing down a few examples.
My goal was to create a custom Docutils Directive. A Directive is a class which can be referred to from a .rst file to generate custom content. Its main method is run(), which must return a list of Docutils nodes, representing the custom content. Each node can itself contain other nodes, so run() actually returns a list of node trees.
Available nodes are listed in the Docutils Document Tree. reStructuredText is powerful and expressive, which means creating simple text structures can require quite a lot of nodes, as we shall see.
Let's start with an "Hello World", a simple paragraph:from docutils import nodes # ... class HelloWorld(Directive): def run(self): para = nodes.paragraph(text='Hello World') return [para]
An error I made a lot when starting was to pass the text of the paragraph as a positional argument. I kept writing that:nodes.paragraph('Hello World')
Instead of this:nodes.paragraph(text='Hello World')
It does not work because the first argument of paragraph() is the raw source: the string which would produce the paragraph if it came from a .rst document.
Next example, let's create some sections, the equivalent of this .rst source:Hello ===== Some text. A Level 2 Title --------------- More text.
The code:class Sections(Directive): def run(self): section = nodes.section() section += nodes.title(text='Hello') section += nodes.paragraph(text='Some text.') subsection = nodes.section() section += subsection subsection += nodes.title(text='A Level 2 Title') subsection += nodes.paragraph(text='More text.') return [section]
Let's now create a bullet list, like the one which would be created by this .rst:- Apples - Oranges - Bananas
This is done with a bullet_list node, which contains list_item nodes, which themselves contain paragraph nodes.class BulletList(Directive): def run(self): fruits = ['Apples', 'Oranges', 'Bananas'] lst = nodes.bullet_list() for fruit in fruits: item = nodes.list_item() lst += item item += nodes.paragraph(text=fruit) return [lst]
And now for something a bit crazier, what about a table? The rough equivalent of:============ ========== ======== ===== Product Unit Price Quantity Price ------------ ---------- -------- ----- Coffee 2 2 4 Orange Juice 3 1 3 Croissant 1.5 2 3 ============ ========== ======== =====
This one is a bit more involved:class TableExample(Directive): def run(self): header = ('Product', 'Unit Price', 'Quantity', 'Price') colwidths = (2, 1, 1, 1) data = [ ('Coffee', '2', '2', '4'), ('Orange Juice', '3', '1', '3'), ('Croissant', '1.5', '2', '3'), ] table = nodes.table() tgroup = nodes.tgroup(cols=len(header)) table += tgroup for colwidth in colwidths: tgroup += nodes.colspec(colwidth=colwidth) thead = nodes.thead() tgroup += thead thead += self.create_table_row(header) tbody = nodes.tbody() tgroup += tbody for data_row in data: tbody += self.create_table_row(data_row) return [table] def create_table_row(self, row_cells): row = nodes.row() for cell in row_cells: entry = nodes.entry() row += entry entry += nodes.paragraph(text=cell) return row
That's it for today, hope this was helpful for some of you. If you want to experiment with this, here is the source code for all these examples: docutils_snippets.py.
PS: I am no Docutils expert, this article may suggest wrong ways to do things, please leave a comment if you notice any error.
We have just opened the registration for Akademy-es 2015.
This year we are piggy-backing on the Akademy 2015 registration system since Akademy-es 2015 happens in the same place just 2 days before so we thought it made sense have a common registration for both.
More info at https://www.kde-espana.org/akademy-es2015/registro.php
See you at A Coruña!
Wrishiraj Kaushik announced SuperX 3.0 on March 23 Linux operating system for computers. This major version includes a great number of features, updated applications, new artwork, and lots of under-the-hood improvements.
Dubbed Grace, SuperX 3.0 is Kubuntu based on 14.04 LTS (Long Term Support). It features the Linux kernel 3.13.0, and KDE Application 4.13.3 desktop environment, showcasing a flat theme with bright contrasting colors. SuperX 3.0 includes the latest available versions of the Mozilla Firefox and Chromium web browsers, Mozilla Thunderbird email and news client, LibreOffice office suite, GIMP image editor, FileZilla file transfer client, VLC Media Player video player, Musique music player, Minitube YouTube downloader, OpenShot video editor, and Telegram messaging client. Apt-fast has also been integrated in SuperX 3.0 for faster apt-get functionality. The USB Modem Manager has been added in order to manage USB dongles, Indian language input support is provided via the IBus keyboard input method, an on-screen keyboard has been added, supporting both English and Indian languages, as well as a beautiful splash screen.
A great slideshow is available at SOFTPEDIA.
We plan to close the Doodle for the Randa Meetings date selection at the end of this week. So if you plan to participate please vote on the date that best fits you! And keep in mind two things:
- You might bring your partner or family with you to Randa. We started this last year and people really liked it (and Randa is a nice holiday place in the Alps too – near to the world-known Zermatt).
- If you see a lot of well-known names on the Doodle don’t think you shouldn’t be part of this. We always want to see new people with fresh energy and inspiring thoughts and ideas in Randa.
So please add yourself as quickly as possible or write me an email (fux AT kde) or ping me on IRC (unormal).
After a long period of silence I’m coming with a news: Telepathy-Morse project is “still alive” and the first release is going on.
- TelegramQt — Qt-based library which supports messaging, contact-list operations and other telegram client capabilities. The purpose of this library is to abstract from the telegram protocol details and provide a convenient API for a client application development.
- Telepathy-Morse — Qt-based Telegram client (connection manager) for Telepathy communication framework. Uses TelegramQt under the hood.
Note: In order to use Morse, you need to have a complementary Telepathy Client application, such as KDE-Telepathy or Empathy.
Note: Telepathy-Morse depends on the latest telepathy-qt version (0.9.6), which might be not available yet.
Now, let’s talk about the development, current progress and plans for the near future.
What is expected to work (on high level):
- Contact list with first/last names
- Contact avatars
- Contact management (you can add/delete contact by its phone number)
- Personal messaging (one to one)
- User typing events
- Message acknowledgment
- Own presence (online, offline, hidden)
- Loading unread messages on connect
- DBus activation
- Sessions (Means that you don’t have to get confirmation code again and again)
- Restoring connection on network problem
- Initial low-level encryption sometimes generates bad random values, which leads to “connection doesn’t work” issue.
- Can not send long messages (Missed TelegramQt gzip packing implementation; limit is about 400 characters; telegram protocol limitation is 4095 characters)
Both TelegramQt and Telepathy-Morse are Qt4 and Qt5 compatible.
Information about CMake build: by default CMake looks for the Qt5 build. You can pass USE_QT4 option (-DUSE_QT4=true) to process Qt4 build.
Telepathy-Morse almost works on the sailfish devices, but there is one show-stopper: The authentication dialog invocation doesn’t work. We do basically the same thing, as do Telepathy-Gabble (which is known to work), but it have no effect. Sadly, I don’t have a Sailfish device and didn’t test it. Big thanks are going to Teemu Varsamaki, who managed to build Morse for Sailfish, find-out authentication issue and, nonetheless, use the client with an uploaded copy of the auth-info file from desktop.
Telegram Blackberry Contest, Teletonne
I’ve contacted by the “Telegram client for Blackberry” developers. They’re use TelegramQt application in their Teletonne client and win Second prize. More details at https://telegram.org/blog/bb-results. Now it looks like they’re give up with further competition, while it’s really easy to get next prize for “the developers who make the most progress”, as there is many major improvements in TelegramQt. Sadly again, I have no good phone :-) to take a part.
There is no tarballs yet. I’m not familiar with KDE release process, but I’m going to tackle it soon. (I hope to fix the Sailfish issue)
I see three basic directions in the Telegram client development:
- Group chat
- Secure chat
- Multimedia messages, files receiving/upload
Group chat support is mostly implemented in TelegramQt library, but TelepathyQt service bindings requires changes to support (such type of) group chat. Of course, TelepathyQt client bindings have everything we need, so clients (e.g. KDE Telepathy) works well with group chat (e.g. in pair with telepathy-gabble, jabber connection manager).
In its turn, Telepathy-Morse is the first “more, than proof of concept” Qt-based telepathy connection manager, thus TelepathyQt services previously was not used so much. Telegram group chat has “not addressable” rooms and, as I see, the services might needs a little redesign to support it.
Secure chat. As I know, technically it looks like embedded telegram session with the same cryptography methods, which already implemented for the basic telegram connection. This is not a priority task for me (at least at this moment).
Multimedia messages. File download capability is already implemented and used for avatars and initial photo-messages support. I need to tune it a bit for “big files” operation support. Outgoing media messages needs some significant work, because one can not just upload files “as is”, but should meet Telegram requirements, such as format, resolution, etc. I have no strong decision on the API and TelegramQt responsibility yet.
Implementation of the last task means almost automatic “done” for the self avatar changing (uploading) capability.
I have never heard about open source Telepathy stack component with multimedia message support, so, probably, there will be a lot of work. Telepathy specification have some hints on this subject.
Short note about TelegramQt test application
The test application is not intends to be telegram client for end users, but supposed to be feature full developer-oriented application with easy access to some artificial operations, just to be sure that TelegramQt works as expected. Because of TelegramQt documentation nonexistence, the test app source can be useful as API usage example as well.
Group chat with multimedia messages in TelegramQt TestApp.
Morse and TelegramQt TestApp in process of one-to-one chatting. As you can see, there is avatars in contact-list, typing status in ktp-text-ui, messages timestamp, delivery-report and a little allusion.
- KDE Project and especially David Edmundson for making this project possible.
- David Edmundson again, for moral and technical support and for the ktp-accounts-kcm plugin for Morse.
- Matthias Gehre for his work on the TelepathyQt services.
- Previous post autumn commentators, especially Alberto, who eventually made me to continue this project, instead of delaying it again and again under pressure of everyday cares.
- Teemu Varsamaki for actual code contribution, ideas, testing.
- Official TelegramQt repository
- Official Telepathy-Morse repository
- My personal TelegramQt repository (WIP, unstable, some force-push probability)
- My personal Telepathy-Morse repository (WIP, unstable, force-push warning again)
- My TelepathyQt fork with experimental features (Regular rebase on upstream master, so unavoidable force push)
- TelepathyQt code generator (can be useful for the TelepathyQt services developers)
I’m so sorry for the slow development, it’s a consequence of mine “always busy” reality. The project is not abandon and will not be abandon. I hope you’ll see an update next few months. Thank you for reading.
On Monday, 30/3, the foss-gbg group will meet and hack on 3D printers. Invitation in Swedish – tickets are free.
Välkomna på foss-gbg hackafton!
Vi träffas klockan 17:00 den 30/3 och lär oss om 3D-skrivare.
Vi får besök av Göran Frykberg som kör en 3dhub i Mölndal. Han kommer att snacka om printerteknologier och material. Han kommer även att visa lite bruksprodukter och visa varför 3D-skrivare är här för att stanna.
Vid åttasnåret drar vi vidare och umgås över en öl.
Pelagicore står för lokaler och bjuder på lättare tilltugg under tillställningen.
Gratis biljetter hittar ni på eventbrite . Antalet platser är begränsade, så först till kvarn gäller!
Göran Frykberg, Johan Thelin och Mikael Söderberg
Cutelyst the Qt/C++ web framework just got a new release, 0.7.0 brings many improvements, bugfixes and features.
Most notably of the changes is a shinny new Chained dispatcher that finally got implemented, with it Cutelyst Tutorial got finished, and a new command line tool to bootstrap new projects.
* Request::bodyData() can return a QJsonDocument is content-type is application/json
* Chained dispatcher
* Fixes on QStringListeral and QLatin1String usage
* More debug information
* Some API changes to match Catalyst’s
* Some rework on the API handlying Plugins (not the best thing yet)
* Moved to Gitlab (due to the gitorious being acquired by it)
* “cutelyst” command line tool
For the next release I’ll try to make the QML integration a reality, and try to improve the Plugins API, which is right now the part that needs more love would love to hear some advice.
Download it here.
The KDE Gardening team has at last finished the Love project KRecipes with the 2.1 release which can be found here: http://download.kde.org/stable/krecipes/2.1.0/src/krecipes-2.1.0.tar.xz.mirrorlist
After 1723 posts and several years of use, I've switched my blog from the proprietary, Google-owned-and-hosted Blogger to a self-hosted instance of the free software Ghost blogging application. If you are reading this in one of the blog agregators I'm carried on, you may have seen some old postings showing up as a result; apologies if this happens.
I've been watching the Ghost project for a while waiting for it to reach the point I could reasonably use it for my needs. It got there recently and I had the opportunity to move to a new server recently so took the plunge.
Here's what I really like about it, and why I went with it:
- It is free software. Obviously this is #1 in the list
- It is actively and openly developed, moving at a good clip
- I was able to import my Blogger blogs into it quite easily
- It is focused on minimalism
- It runs as a separate application
While the first three may be obvious in terms why they are important, I'd like to take a moment to talk about the last two.
It may sound like stating the obvious, but: I want a blogging system for my blog. Not a web site builder. Not a content management system. A blog application. As a counterexample, Wordpress has long exited the land of simple blogging system and become a website building suite. There is nothing wrong with that, but it means it diverges from my desire for a clean, minimal and elegant system for blogging. I've run a few Wordpress sites over the last few years, so I'm not just speaking hypothetically but from first-hand experience.
With Ghot, you write your blogs in a very plain and simple full-screen, two-pane user interface using markdown. No word-processor-wannabe toolbars, switching between keyboard and mouse, lots of menus everywhere. Just a text editor, a live preview next to it and all the editing and formating you could want in a blog. Tags live in a bar below, configuration in a slide-in drawer on the right, and a simple button to save and publish.
Yet in this simple system it still manages to have multiple author support, tag and author specific RSS feeds, static pages, theming ...
Since it runs as its own process, I can have systemd manage it as a separate service listening on a local socket with haproxy forwarding traffic to it. Upgrading the blog becomes a simple matter of setting up a parallel install, testing it, and when I'm happy with it changing the haproxy routing and restarting haproxy. Zero downtime, even if things go wrong. If a security problem or some other issue arrises, I can shut down just the blog and none of the other things I have running on the server are affected. I can even move it to another machine if desired without interuption.
While setting it up, along with other "must have" tools for me such as Kanboard, it reminded me of some aspects of the Kolab architecture, specficially how it is built around a swarm of services that take care of different aspects of the task of "collaboration suite" in concert with each other.
Finally, I'd like to give a shout-out to the author of the Willsong II theme. I purchased the theme after trying his no-cost Willsong 1 theme; it looks nice and professional, and I both wanted to support his efforts and get some of the nice features of Willsong II. It also happens to use the KDE Oxygen font by default, which I thought was pretty spiffy. Unfortunately I ran into some small problems with the theme after installing it. I wrote the author and he responded almost immediately and quickly identified and fixed a bug in the theme. He even customized it a bit for me, even though I didn't ask for that. So: great customer support, and he's got a few other themes with a shared common core that he's working on. If you're looking for a good Ghost theme I recommend giving his efforts a look.
Last week I merged in a few important changes for the upcoming KWin 5.3 release. The rootless Xwayland support is integrated, which means we are a huge step closer to managing Wayland clients. Rendering, input and cursor is already using the Wayland code paths and will be shared with proper Wayland clients. I have already started working on code for that and have it working quite nicely already but decided to delay the integration for Plasma 5.4.
This means that kwin_wayland starts a Wayland server, but except Xwayland there is no application which can properly connect to it. Nevertheless it’s an important step and allows to also test the code in a better way.
In addition I worked on a better support for nesting compositors. So far one had to start Weston in order to test kwin_wayland. This is of course not optimal as it makes the development setup more difficult than it has to be. So last week I looked into developing a new backend which can use an X11 window to render to. This is comparable to Weston which can be used nested on X11. The backend is relatively straight forward: it can render to the created window using either the OpenGL or QPainter compositor, accepts input events and delegates them and passes the cursor from Wayland windows to the X11 window. The tricky part is that we cannot use any of our X11 specific libraries to create the window: we don’t use the xcb QPA, so no support from Qt and we cannot use KWindowSystem as it only allows one xcb_connection and that’s already needed for the Xwayland window manager. So I had to do things myself and as I consider this just a development feature it’s probably the worst X11 client in existance (Long term KWindowSystem should be changed to support multiple connections, would be very useful for unit tests).
The new backend triggered a small refactoring which makes it easier to implement further backends like e.g. a plain framebuffer or a drm/kms. As a small reminder: there’s an open GSoC idea for implementing the drm/kms backend and application period is to close soon.
Anyway with the nested KWin it’s now possible to create a kwin_wayland instance on the X Server using kwin_x11 and on the kwin_wayland one can create yet another kwin_wayland so that we have a KWinception:Aus 2015-03-19
To start such a nested compositor use:
kwin_wayland --windowed --xwayland
Please watch the debug output for:
X-Server started on display :1
This tells the id of the created X Server (normally the next free id) and allows to start an application on the nested KWin:
KWin_Wayland picks the windowing system depending on the environment variables which are defined. For DISPLAY it uses X11, for WAYLAND_DISPLAY it uses Wayland. If both are defined Wayland is preferred. If one wants to specify explicitly one can use the command line arguments –x11-display or –wayland-display. E.g.
kwin_wayland --windowed --xwayland --x11-display=:0
For X11 there are also the options –width and –height to specify an initial size (default is currently 1024×768). On Wayland these options are currently not available, the window always opens fullscreen.
Please remember that this is pretty new code and the support is still incomplete. Feature might be missing or broken. This is at the current state expected and because of that we do not yet accept bug reports. If you find a bug which you think should be fixed, please open an editor
– Desktop actions
– Dolphin magic
– Actions and language
– Network connection edit
– Trash auto cleanup
– Undo widget removal (great for the whoops moments)
Tagged #kubuntu, of course.
Another year, another opportunity to annoy Nuno Pinheiro with some terrible “engineer art” that I produced many moons ago (see header image). This, my friends in KDE, is why you should be going to Akademy and why you should talk there. Akademy: The Social Heartbeat of KDE Akademy, in short, is the annual conference of the KDE community. If you are… Read more →