24 Oct 2016
Getting the correct dependencies and up to date version of required libraries has always been a challenge for Kdenlive users. So we are pleased to announce that we now provide binary packages for download. These packages contain the latest Kdenlive development version (git master), as well as current development versions of MLT, Frei0r, OpenCV. The GPU movit library is not included at this stage. There might be some performance hit due to the nature of the formats, but these packages will be most helpful to debug and test the alpha/beta versions so that we can provide better releases. It will also help to identify issues linked to missing dependencies or outdated libraries on your system.
So if you are ready, you can download Kdenlive's first AppImage here:
Then, simply make the file executable and run it! In a terminal:
chmod a+x kdenlive-16.12-alpha1-x86_64.AppImage
We also provide a Snap package available for testing on Ubuntu distros:
sudo snap install --edge --force-dangerous --devmode kdenlive-devel
The snap package is in the edge channel and requires "devmode" because of current limitations in the snap format.
We will provide several updates to this packages before the Kdenlive 16.12 release so that you can follow the development / bug fixes.
24 Oct 2016 8:35am GMT
23 Oct 2016
It is available at the usual place https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
Dependency freeze is in 2.5 weeks and Feature Freeze in 3.5 weeks, so hurry up!
23 Oct 2016 10:45am GMT
Mageia KDE Team just finished to push in Mageia cauldron :
- Plasma 5.8.2 ( the Plasma LTS version )
- KDE Applications 16.08.2
- KDE Frameworks 5.27.0
If you find packaging bugs don't hesitate and come in Mageia Bugtracker
And if you want to join KDE Team and help you can mail us or find us on IRC ( freenode : #mageia-kde ).
23 Oct 2016 9:35am GMT
KDE turned twenty recently, which seems significant in a world that seems to change so fast. Yet somehow we stay relevant, and excited to continue to build a better future.
Lydia asked recently on the KDE-Community list what we were most proud of.
For the KDE community, I'm proud that we continue to grow and change, while remaining friendly, welcoming, and ever more diverse. Our software shows that. As we change and update, some things get left behind, only to re-appear in fresh new ways. And as people get new jobs, or build new families, sometimes they disappear for awhile as well. And yet we keep growing, attracting students, hobbyist programmers, writers, artists, translators, designers and community people, and sometimes we see former contributors re-appear too. See more about that in our 20 Years of KDE Timeline.
I'm proud that we develop whole new projects within the community. Recently Peruse, Atelier, Minuet, WikitoLearn, KDEConnect, Krita, Plasma Mobile and neon have all made the news. We welcome projects from outside as well, such as Gcompris, Kdenlive, and the new KDE Store. And our established projects continue to grow and extend. I've been delighted to hear about Calligra Author, for instance, which is for those who want to write and publish a book or article in pdf or epub. Gcompris has long been available for Windows and Mac, but now you can get it on your Android phone or tablet. Marble is on Android, and I hear that Kstars will be available soon.
I'm proud of how established projects continue to grow and attract new developers. The Plasma team, hand-in-hand with the Visual Design Group, continues to blow testers and users away with power, beauty and simplicity on the desktop. Marble, Kdevelop, Konsole, Kate, KDE-PIM, KDElibs (now Frameworks), KOffice (now Calligra), KDE-Edu, KDE-Games, Digikam, kdevplatform, Okular, Konversation and Yakuake, just to mention a few, continue to grow as projects, stay relevant and often be offered on new platforms. Heck, KDE 1 runs on modern computer systems!
For myself, I'm proud of how the KDE community welcomed in a grandma, a non-coder, and how I'm valued as part of the KDE Student Programs team, and the Community Working Group, and as an author and editor. Season of KDE, Google Summer of Code, and now Google Code-in all work to integrate new people into the community, and give more experienced developers a way to share their knowledge as mentors. I'm proud of how the Amarok handbook we developed on the Userbase wiki has shown the way to other open user documentation. And thanks to the wonderful documentation and translation teams, the help is available to millions of people around the world, in multiple forms.
I'm proud to be part of the e.V., the group supporting the fantastic community that creates the software we offer freely to the world.
23 Oct 2016 5:22am GMT
22 Oct 2016
We're still fixing bugs like madmen… And working on some cool new features as well, but that's for a later release. In any case, here is the second Krita 3.1 beta! Yes, you're reading that correctly. Originally, we had planned to use 3.0.2 as the version for this release, but there is so much news in it that it merits a bigger version bump. Plus, with the acceptance of Julian Thijssens' Google Summer of Code work by the Qt Project, we're reaching a really big milestone:
From the next release on, Krita will officially support OSX.
That means that the OpenGL canvas works fully and that we're committed to fixing OSX-specific bugs, just like we're fixing bugs on Windows and Linux. It means we're confident that you can use Krita 3.1 on OSX and be productive, instead of experimenting. So, please test this beta, and help us find bugs and issues!
Of course, Krita 3.1 will have much more new stuff. A new brush engine that supports really big brushes, Jouni's Google Summer of Code work on adding new features to animation, Wolthera's Google Summer of Code work that adds color managed high-channel depth color selectors and soft proofing to Krita, a stop-based gradient editor, ffmpeg-based export to animated gif and video formats. And much more.
Note: the beta still contains the colorize mask/lazy brush plugin. We will probably remove that feature in the final release because the current algorithm is too slow to be usable, and we're still looking for and experimenting with new algorithms. With the current beta you will get a preview of how the user interface will work, but keep in mind that the we know that it's too slow to be usable and are working on fixing that
The second beta is also much more stable and usable than the first beta (126.96.36.199), and we'd like to ask everyone to try to use this version in production and help us find bugs and issues!
- 32 bits Windows: krita-3.0.91-x86-setup.exe (MD5 Hash: ead6024307112f5dd98b3c8c91547a85)
- Portable 32 bits Windows: krita-3.0.91-x86.zip (MD5 Hash: 4d36a3648f55137b39c4fe9238b1b5d4)
- 64 bits Windows: krita-3.0.91-x64-setup.exe (MD5 Hash: 56522b839bc04d36730518f2d42ed541)
- Portable 64 bits Windows: krita-3.0.91-x64.zip (MD5 Hash: 56e88e68a6f113e77e0b58d6fc313a8c)
- 64 bits Linux: krita-3.0.91-x86_64.appimage (MD5 Hash: 4531ee79eb67d4959b7e4ff91db25681)
There is also a snap image available in the Ubuntu App Store, in the beta channel.
- OSX disk image: krita-3.0.91.dmg (MD5 Hash: 6bd801060b189af0c6efc823a3ac41f4)
- Source code: krita-3.0.91.tar.gz (MD5 Hash: 936d256c7e889485ed4722113b2f2bcd)
22 Oct 2016 9:50am GMT
21 Oct 2016
This announcement is also available in Spanish and Taiwanese Mandarin.
The latest updates for KDE's Plasma, Applications and Frameworks series are now available to all Chakra users.
The Plasma 5.8.2 release provides additional bugfixes to the many new features and changes that were introduced in 5.8.0 aimed at enhancing users' experience:
Applications 16.08.2 include more than 30 recorded bugfixes and improvements to 'kdepim, ark, dolphin, kgpg, kolourpaint, okular, among others'.
Frameworks 5.27.0 include a new set of mimetype icons, in addition to the usual bugfixes and improvements.
Other notable package upgrades and changes:
- plasma-workspace now provides by default the ksuperkey package functionality.
- php 7.0.11. The 5.6 series is now provided as php56.
- gconf has been introduced as a dependency of plasma-pa.
- intel-ucode 20160714
- laptop-mode-tools 1.70
- openssl 1.0.2.j
- rust 1.12.0
- filesystem 2016.09
- gnutls 3.4.15
- lua 5.3.3
- vim 8.0.0045
- libreoffice 5.2.2
- kexi 3.0.0, now ported to Frameworks 5. If you get a warning about files already existing on the filesystem, please follow our FAQ documentation.
- mpv 0.21.0
- wireshark 2.2.1
- nmap 7.30
- filezilla 3.22.1
- steam 188.8.131.52
- wine 1.9.21
- q4wine 1.3.3
It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.
Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade. To be sure, please use the mirror status page to check that your mirror synchronized with our main server after this announcement.
21 Oct 2016 7:05pm GMT
Like many photographers, I have a handful of hand-made favorite presets (most of them are included in the Daily Curves Set) in my photographic toolbox. But there is one preset in particular I use more often than others. I named it Spektrum, as it's inspired by images from the Spektrum Berlin photo book by Matthias Heiderich.
21 Oct 2016 12:31pm GMT
Last official stable release was done more than 3 years ago, it was based on Qt/KDE 4 tech, after that a few fixes got in what would be 0.4.0 but as I needed to change my priorities it was never released.
Thanks to Lukáš Tinkl it was ported to KF5, on his port he increased the version number to 0.5.0, still without a proper release distros rely on a git checkout.
Since I started writing Cutelyst I had put a break on other open source projects by mostly reviewing a few patches that comes in, Cutelyst allows me to create more stuff that I get paid to do, so I'm using my free time to pick paid projects now. A few months ago Cristiano Bergoglio asked me about a KF5 port, and getting a calibration tool not to depend on gnome-color-manager, and we made a deal to do these stuff.
This new release got a few bugs fixed, pending patches merged and I did some code modernization to make some use of Qt5/C++11 features. Oh and yes it doesn't crash on Wayland anymore but since on Wayland the color correction is a task for the compositor you won't be able set an ICC profile for a monitor, only for other devices.
For the next release, you will be able to calibrate your monitor without the need for the GNOME tools.
21 Oct 2016 12:23pm GMT
You might have noticed there's KDevelop for Windows out now...
Which is already great in itself! But now it's also possible to install it via the super popular Windows package manager for Windows, Chocolatey.
Here's all you need (in case you already have Chocolatey installed on your system):
- Start a Command Prompt as Administrator user
- Type in
choco install kdevelopto install
- Start KDevelop via the Windows start menu
Here's what it does:
C:\WINDOWS\system32>choco install kdevelop Installing the following packages: kdevelop By installing you accept licenses for the packages. kdevelop v5.0.2 [Approved] Downloading kdevelop 64 bit from 'http://download.kde.org/stable/kdevelop/5.0.2/bin/windows/kdevelop-5.0.2-x64-setup.exe' Progress: 100% - Saving 90.45 MB of 90.49 MB (94839304/94887333) Download of kdevelop-5.0.2-x64-setup.exe (90.49 MB) completed. Hashes match. Installing kdevelop... kdevelop has been installed. Added C:\ProgramData\chocolatey\bin\kdevelop.exe shim pointed to 'c:\program files\kdevelop\bin\kdevelop.exe'. The install of kdevelop was successful. Software installed as 'EXE', install location is likely default. Chocolatey installed 1/1 packages. 0 packages failed. See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log). Check out Pro / Business for more features! https://chocolatey.org/compare C:\WINDOWS\system32>where kdevelop C:\ProgramData\chocolatey\bin\kdevelop.exe
Thanks a lot to Hannah von Reth for setting up the KDE Chocolatey category, including publishing the KDevelop package there!
As always, we ask you to provide us with any kind of feedback on the Windows version! It's much appreciated.
21 Oct 2016 10:08am GMT
20 Oct 2016
While Timothee Giet is working on the next Krita training video series - and it'll all be about animation! - we're cutting the price of our existing training videos!
Muses, still one of the best introduction to digital painting in general, and to Krita in particular, is now available for only €14,95!
Now just €14,95, from €24,95
And Secrets of Krita, full of in-depth hints, tricks and tips on how to get the most out of Krita is now also… only €14,95!
Secrets of Krita - Download
Now just €14,95, from €29,95
You can also get these downloads from our gumroad shop!
We still have actual DVD's, neatly printed with atractive covers available for you to order, too:
Secrets of Krita - DVD
Now just €14,95, from €29,95, including shipping
Now just €14,95, from €24,95, including shipping
Or you can get both training dvd's and the latest version of Krita for Windows, OSX and Linux on a cool credit-card sized USB stick, showing off spring Kiki.
Now just €24,95, from €39,95, including shipping
20 Oct 2016 10:59am GMT
19 Oct 2016
FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium, Europe).
Once again, one of the tracks will be the Desktops DevRoom (formerly known as "CrossDesktop DevRoom"), which will host Desktop-related talks.
We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.
Topics accepted include, but are not limited to:
- Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, Cinnamon, ReactOS, CDE etc
- Closed desktops: Windows, Mac OS X, MorphOS, etc (when talking about a FLOSS topic)
- Software development for the desktop
- Development tools
- Applications that enhance desktops
- General desktop matters
- Cross-platform software development
- Thin clients, desktop virtualiation, etc
Talks can be very specific, such as the advantages/disadvantages of distributing a desktop application with snap vs flatpak, or as general as using HTML5 technologies to develop native applications.
Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2016 schedule might give you some inspiration.
Please include the following information when submitting a proposal:
- Your name
- The title of your talk (please be descriptive, as titles will be listed with around 400 from other projects)
- Short abstract of one or two paragraphs
- Short bio (with photo)
- Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request.
How to submit
All submissions are made in the Pentabarf event planning tool: https://penta.fosdem.org/submission/FOSDEM17
To submit your talk, click on "Create Event", then make sure to select the "Desktops" devroom as the "Track". Otherwise your talk will not be even considered for any devroom at all.
If you already have a Pentabarf account from a previous year, even if your talk was not accepted, please reuse it. Create an account if, and only if, you don't have one from a previous year. If you have any issues with Pentabarf, please contact email@example.com.
The deadline for submissions is December 5th 2016.
FOSDEM will be held on the weekend of 4 & 5 February 2017 and the Desktops DevRoom will take place on Sunday, February 5th 2017.
We will contact every submitter with a "yes" or "no" before December 11th 2016.
The talks in the Desktops DevRoom will be audio and video recorded, and possibly streamed live too.
In the "Submission notes" field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>."
If you want us to stop the recording in the Q & A part (should you have one), please tell us. We can do that but only for the Q & A part.
The official communication channel for the Desktops DevRoom is its mailing list firstname.lastname@example.org.
Use this page to manage your subscription: https://lists.fosdem.org/listinfo/desktops-devroom
The Desktops DevRoom 2017 is managed by a team representing the most notable open desktops:
- Pau Garcia i Quiles, KDE
- Christophe Fergeau, Gnome
- Michael Zanetti, Unity
- Philippe Caseiro, Enlightenment
- Jérome Leclanche, Razor
If you want to join the team, please contact email@example.com
19 Oct 2016 11:41pm GMT
The FreeBSD packages of KDE software - the KDE 4 desktop, and soon KDE Frameworks 5 and Plasma 5 Desktop and KDE Applications - have traditionally been shipped pretty much as delivered from the upstream source. We compile, we package, and there is very little customization we do as a "distro". The KDE 4 packages came with a default wallpaper that was a smidgen different from the one shipped with several Linux distro's. I think Ivan Cukic did that artwork originally. For Plasma 5 Desktop, we also wanted to do a tiny bit of branding - just the default wallpaper for new users, mind.
Thanks to the tremendously helpful Plasma crew who answered my questions about setting a default wallpaper by producing the necessary files on the spot. After a tiny amount of massaging, I've now got a package that does the FreeBSD branding of the Plasma 5 Desktop for us. Of course we retain the upstream settings and wallpapers too.
Also great thanks to Timothee Giet, for producing the image (based on his Flying Konqui) that we're now going to use as the default wallpaper - Konqui flying on BSD, that's just what we want, after all.
19 Oct 2016 9:31pm GMT
19 Oct 2016 2:25pm GMT
Two weeks have passed since the Plasma 5.8 release and our Wayland efforts have seen quite some improvements. Some changes went into Plasma 5.8 as bug fixes, some changes are only available in master for the next release. With this blog post I want to highlight what we have improved since Plasma 5.8.
Resize only borders
KWin's server side decorations have a feature that one can resize the window in the shadow area. With the Breeze window decoration this is available if one uses the border size "No Side Borders" or "No Borders". For Wayland we just had to adjust the input area of a window slightly and honor it when evaluating the mouse pointer movements.
Global Shortcut handling
We found a few bugs related to global shortcut triggering. There is some unexpected behavior for shortcut triggering in xkbcommon, which will be addressed in the next release by adding new API. For now we had to workaround it to support some shortcuts which no longer triggered. Of course for every kind of shortcut which did not trigger we added a test case so we can also in future ensure that this works once the new xkbcommon release is available. At the moment we are not aware of any not working global shortcuts on Wayland. If you hit one, please report a bug.
Support for Keyboard LEDs through libinput
KWin did not enable the LEDs for num lock, caps lock, etc. This was mostly because I don't have any keyboard which has such LEDs - neither my desktop keyboard nor my two notebooks have any LEDs. So I just didn't notice that this was missing. Once we got the bug report we looked into adding this. I want to take this as an example of the "obvious bug" one doesn't report because it's so obvious. But if one doesn't have such hardware it's not so obvious any more.
Relative pointer support
A feature we added for Plasma 5.9 is support for the relative pointer protocol.
The protocol is implemented in KWayland 5.28 and KWin is adjusted to support the relative pointer events as can be seen in the screenshot of the input debug console. This is a rather important protocol to support games on Wayland. We also plan to add pointer confinement for Plasma 5.9.
Move windows through the widget style
Our widget styles Breeze and Oxygen have a feature to move the window when clicking in empty areas. This is a feature which needs to interact with the windowing system directly as Qt doesn't provide an abstraction for it. On X11 it uses the NETRootInfo::moveResizeRequest, on Wayland support for triggering a window move is built into the core protocol. But so far we were not able to provide the feature on Wayland as we just didn't have enough information from QtWayland. For example we lacked access to the wl_shell_surface on which we have to trigger the move. So some time ago I added support to QtWayland that we can access the wl_shell_surface through the native interface. Now about a year later we can start to use it. To support this feature we need to create an own wl_seat and wl_pointer object and track the serial of pointer button press. This we can then pass to the move request on the ShellSurface. The change is not KWin specific at all and will work on all Wayland compositors.
Color scheme sync to decoration
A new feature we added in KWin 5.0 is the possibility to synchronize the color scheme from the window into the window decoration and the context menu on the decoration. On X11 this works through a property which our KStyle library sets. This was the best we had back in the early days of the 5.x series as Qt didn't expose enough information. It has the disadvantage that the sync only works with QWidget based applications and only with widget styles inheriting KStyle. For Plasma 5.9 we improved that and brought the relevant code into plasma-integration. The restriction to QWidget is gone and it works now with all kind of windows by listening to the QPlatformSurfaceEvent. This very useful event which got added in Qt 5.5. It informs us when a native window is created for a QWindow. Thus we can add our own X11 properties on the native window directly after creation and before the window is mapped.
While adjusting this code for X11 we also added the relevant bits for Wayland. We use the Qt Surface Extension protocol to pass a property to the server. That's a small and neat addition the Qt devs did to allow communication between a Qt based client and a Qt based Wayland compositor. As one can see in the screenshot the color scheme now updates also for Wayland applications.
Window icon handling in Wayland is different to X11. On X11 the icons are passed as pixmaps. That has a few disadvantages nowadays because the icons provided on the window might not have a high enough resolution to work well on high-dpi systems. The icon from the icon-theme though provides higher resolution. On Wayland there is no way to pass window icons around and the compositor takes the icon from the desktop file of the application. This works well unless we don't have a desktop file. For such windows we now started to use a generic Wayland icon as the fallback, just like we use a generic X icon as fallback for X11 windows which don't have an icon.
That's an icon which one might have noticed when using a Plasma Wayland session as every Xwayland window only had the generic X icon in the task manager. The communication between KWin and the task manager also passes the icon name around and not pixmap data. This works well for everything which isn't Xwayland where we normally just don't have the name. For Plasma 5.9 we addressed this problem and extended our protocol to request pixmap data for a window icon which doesn't have a name. Thus we are now able to also support Xwayland windows, which increases the useability of the system quite a lot.
Multi screen effect improvements
On Wayland several of our effects broke in a multi-screen setup. This is because rendering is different. On X11 all screens are rendered together in one rendering pass and we have one OpenGL window to render to. On Wayland we have one OpenGL window per screen and have one rendering pass per screen. That's something our effects didn't handle well and resulted in rendering issues. For Plasma 5.9 these issues are finally resolved.
One of the affected effects is Wobbly windows. A rather important effect given that this blog is subtitled "From the land of wobbly windows". We experienced that in a multi-screen setup the effect was only active on one screen. If the window got moved to the other screen it completely vanished.
I was quite certain that this is not a problem with the effect itself, but rather with the way how we render. As we also saw other effects having rendering issues in multi-screen setups I was quite optimistic that fixing wobbly would fix many effects.
The investigation showed that the problem in fact was an incorrect area passed to glScissor due to the general changes in rendering explained above. Rendering on other screens got clipped away. With the proper change we got wobbly working and several other effects (Present Windows, Desktop Grid, Alt+Tab for example) without having to touch the effects at all.
With that knowledge in place we looked into fixing other effects. E.g. the screenshot effect which allows to save a screenshot in the tmp directory. A few example of screenshots taken with this effect can be seen in this blog post. The problem with this effect was that when taking a fullscreen shot over all screens only one got captured. The assumption here was that our glBlitFramebuffer code needs adjustment to be per output and with that we can now screenshot every screen individually or all screens combined.
Blur and Background Contrast
Related to that are the blur and background contrast effect as they also interact with the frame buffer, though don't use the glBlitFramebuffer extension. With those effects one of the biggest problems was that the viewport got restored to a wrong value after unbinding the frame buffer object. Due to that the rendering got screwed up and we had severe rendering issues with blur on multi screen. These issues are now fixed as can be seen in the screenshot above: both screens are rendered correctly even with blur enable.
Plasma's panel got some improvements for Plasma 5.9. This started from bug reports about windows can cover not working and also auto-hide not working. Another example that it is important to report bugs.
Auto hiding panel
On X11 auto hiding panels use a custom protocol with KWin to indicate that they want to be restored if the mouse cursor touches the screen edge. It uses low level X11 code thus we also need a low level Wayland protocol for it. We extended our plasma shell protocol to expose auto hiding state and implemented it in both KWin and Plasma.
Search in widget explorer
We had a bug report that search in the widget explorer doesn't work. The investigation showed that the reason for that is that the widget explorer is a panel window and we designed panels on Wayland so that they don't take any keyboard focus. This is correct for the normal panel, but not for this special panel. We adjusted our protocol to provide an additional hint that the panel takes focus and implemented this in kwayland-integration in a way that the widget explorer gains focus without any adjustments to it.
KRunner as a panel
Of course there are more potential users for this new feature. One being KRunner. Once we had the code in place we decided to make KRunner a Panel on Wayland which brings us quite some improvements like it will be above other windows and on all desktops.
19 Oct 2016 7:52am GMT
18 Oct 2016
One of the key points of Plasma is while giving a simple default desktop experience, not limiting the user to that single, pre-packed one size fits all UI.
Its strength is to be flexible to greatly different user needs, "Simple by default, powerful when needed".
Several years ago, the Visual Design Group had the idea of making easy to build and share desktop layouts to make easy to test wildly different user interfaces, see this old post by Thomas on the topic.
Since then, work on it has been going on, mostly on the infrastructure needed to make it a reality, and in Plasma 5.8 the first pieces are there, tough still far from the complete experience we want to offer.
The support for Look and Feel packages is there since a while (5.3 or so) that's what one of those package can do:
- Provide a default layout for when Plasma starts for the first time, it was used for distributions to personalise their UI, but now is easier for users as well.
- Provide some default look options, like what color scheme to use, what icon theme etc
- (advanced) provide the actual implementation of some UI, such as KRunner, the Alt+Tab window switcher dialog, the lock screen
So far the default Plasma layout provided by the Look and Feel theme was used only when starting up for the first time, on a clean user home (therefore very useful for distributions) but sice Plasma 5.8, in the Workspace theme -> Look & Feel section of system settings there is an option to load the new layout when switching the look and feel theme. Not as default as is a destructive action that will remove your current Desktop setup.
- Create a new Look and Feel theme
- Edit the metadata and thumbnail of a locally created/installed theme
- Create a defaults file based upon your current setup as well, such as color scheme and icon theme
The last two are the central part of sharing your idea of "the perfect desktop" with others, linked with the integration between the Look & Feel systemsetting module and the KDE store, also new in Plasma 5.8.
It's still a preliminary feature, as ideally in the future if your shared Look & Feel theme depends for instance from a particular icon theme or a particular 3rd party plasmoid, the store integration will download those dependencies as well.
18 Oct 2016 4:01pm GMT
My Plasma Desktop in 2016On Monday, KDE's Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?
Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.
With these big words out there, let's have a look at some specifics we talked about.
Release schedule until 2018
Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:
- Plasma 5.9: 31 January 2017
- Plasma 5.10: May 2017
- Plasma 5.11: September 2017
- Plasma 5.12: December 2017
- Plasma 5.13: April 2018
- Plasma 5.14 LTS: August 2018
A cautionary note, we can't know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt's release schedule. Here's what we intend to do, it is really our "best guess". Still, this aligns with Qt's plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?
UI and Theming
The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.
The menu button is a first sign of the global menu returning to PlasmaOne thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app's window (for example at the top of the screen). We're currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.
Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs' custom, but sometimes incompatible locale handling classes.
The next releases overall will bring further improvements to our Wayland session. Currently, Plasma's KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn't seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma's Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there's some upstream bug-fixing needed, as well.
One thing we'd like to see to improve our users' experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it's tested, it will contain bugs.)
Plasma's Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack's footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.
Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma's feature-set.
We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.
18 Oct 2016 12:29pm GMT