I Use This!
Activity Not Available

News

Analyzed 3 months ago. based on code collected 8 months ago.
Posted over 8 years ago by Matthias Klumpp (ximion)
It is time again for another Tanglu blogpost (to be honest, this article is pretty much overdue ). I want to shine a spotlight on the work that’s done in Tanglu, be it ongoing or past work done for the new release. Why is the new release taking ... [More] longer than usual? As you might have noticed, usually a new Tanglu release (Tanglu 4 “Dasyatis”) should be released this month. We decided a while ago, however, to defer the release and are now aiming for an release in February / March 2016. Reason for this change in schedule is the GCC 5 transition (and more importantly the huge amount of follow-up transitions) as well as some other major infrastructure tasks, which we would like to complete and give them a good amount of testing before releasing. Also, some issues with our build system, and generally less build power than in previous releases is a problem (At least the Debile build-system issues could be worked around or solved). The hard disk crash in the forum and bugtracking server also delayed the start of the Tanglu 4 development process a lot. In all of these tasks, manpower is of course the main problem Software Tasks General infrastructure tasks Improvements on Synchrotron Synchrotron, the software which is synchronizing the Tanglu archive with the Debian archive, received a few tweaks to make it more robust and detect “installability” of packages more reliably. We also run it more often now. Rapidumo improvements Rapidumo is a software written to complement dak (the Debian Archive Kit) in managing the Tanglu archive. It performs automatic QA tasks on the archive and provides a collection of tools to perform various tasks (like triggering package rebuilds). For Tanglu 4, we sometimes drop broken packages from the archive now, to speed up transitions and to remove packages which got uninstallable more quickly. Packages removed from the release suite still have a chance to enter it again, but they need to go through Tanglu’s staging area again first. The removal process is currently semiautomatic, to avoid unneccessary removals and breakage. Rapidumo could benefit from some improvements and an interactive web interface (as opposed to static HTML pages) would be nice. Some early work on this is done, but not completed (and has a very low priority at the moment). DEP-11 integration There will be a bigger announcement on AppStream and DEP-11 in the next days, so I keep this terse: Tanglu will go for full AppStream integration with the next release, which means no more packaged metadata, but data placed directly in the archive. Work on this has started in Tanglu, but I needed to get back to the drawing board with it, to incorporate some new ideas for using synergies with Debian on generating the DEP-11 metadata. Phabricator Phabricator has been integrated well into our infrastructure, but there are still some pending tasks. E.g. we need subprojects in Phabricator, and a more powerful Conduit interface. Those are upstream bugs on Phabricator, and are actively being worked on. As soon as the missing features are available in Phabricator, we will also pursue the integration of Tanglu bug information with the Debian DistroTracker, which was discussed at DebConf this summer. UEFI support UEFI support is a tricky beast. Full UEFI support is a release-goal for Tanglu 4 (so we won’t release without it). At time, our Live-CDs start on pure EFI systems, but there are several reported issues with the Calamares live-installer as well as Debian-Installer, which fails to install GRUB correctly. Work on resolving these problems is ongoing. Major LiveCD rework Tanglu 4 will ship with improved live-cds, which e.g. allow selecting the preferred locale early in the bootloader. We switched from live-boot to manage our live sessions to casper, the same tool which is also used in Ubuntu. Casper fixed a few issues we had, and brought some new, but overall using it was a good choice and work on making top-notch live-cds is progressing well. KDE Plasma Integration of the latest Plasma release is progressing, but its speed has slowed down since fewer people are working on it. If you want to help Tanglu’s KDE Workspace integration, please help! For the upcoming release, the Plasma 5 packages which we created based on a collaboration with Kubuntu for the previous Tanglu 3 release have been merged with their Debian counterparts. This action fortunately was possible without major problems. Now Tanglu is (mostly) using the same Plasma 5 packages as Debian again (lots of Kudos go the the Kubuntu and Debian Qt/KDE packagers!). GNOME The same re-merge with Debian has been done on Tanglu’s GNOME flavor (Tanglu also shipped with a more recent GNOME release than Debian in Tanglu 3). So Tanglu 4 GNOME and Debian Testing GNOME are at (almost) the same level. Unfortunately, the GNOME team is heavily understaffed – a GNOME team member left at the beginning of the year for personal reasons, and the team now only has one semi-active member and me. Other An fvwm-nightshade spin is being worked on . Apart from that, there are no teams maintaining other flavors in Tanglu. Security & Stable maintenance Thanks to several awesome people, the current Tanglu Stable release (Tanglu 3 “Chromodoris”) receives regular updates, even for many packages which are not in the “fully supported” set. Tangluverse Tasks Tasks (not) done in the global Tanglu universe. HTTPS for community sites Thanks to our participation in the Let’s Encrypt closed beta program, Tanglu websites like the user forums and bugtracker have been fully encrypted for a while, which should make submitting data to these sites much more secure. So far, we didn’t encounter issues, which means that we will likely aim for getting HTTPS encryption enabled on every Tanglu website. Tanglu.org website The Tanglu main website didn’t receive much love at all. It could use a facelift and more importantly updated content about Tanglu. So far, nobody volunteered to update the website, so this task is still open. It is, however, a high-priority task to increase our public visibility as a project, so updating the website is definitely something which will be done soon. Promotion It doesn’t hurt to think about how to sell Tanglu as “brand”: What is Tanglu? Our motivation, our goals? What is our slogan? How can we communicate all of this to new users, without having them to read long explanations? (e.g. the Fedora Project has this nicely covered on their main website, and their slogan “Freedom, Friends, Features, First” immediately communicates the project’s key values) Those are issues engineers don’t think about often, still it is important to present Tanglu in a way that is easy to grasp for people hearing about it for the first time. So far, no people are working on this task specifically, although it regularly comes up on IRC. Sponsoring & Government Tanglu is – by design – not backed by any corporation. However, we still need to get our servers paid. Currently, Tanglu is supported by three sponsors, which basically provide the majority of our infrastructure. Also, developers provide additional machines to get Tanglu running and/or packages built. Still, this dependency on very few sponsors paying the majority of the costs is very bad, since it makes Tanglu vulnerable in case one sponsor decides to end sponsorship. We have no financial backing to be able to e.g. continue to pay an important server in case it’s sponsor decides to drop sponsorship. Also, since Tanglu is no legal entity, accepting donations is hard for us at time, since a private person would need to accept the money on behalf of Tanglu. So we can’t easily make donating to Tanglu possible (at least not in the way we want donations to be). These issues are currently being worked on, there are a couple of possible solutions on the table. I will write about details as soon as it makes sense to go public with them.   In general, I am very happy with the Tanglu community: The developer community is a pleasure to work with, and interactions with our users on the forums or via the bugtracker are highly productive and friendly. Although the development speed has slowed down a bit, Tanglu is still an active and awesome project, and I am looking forward to the cool stuff we will do in future!   [Less]
Posted over 8 years ago by Krita News
Here’s Nathan’s overview of the Instant Preview beta: And the animation toolset:
Posted over 8 years ago by Aaron Seigo (aseigo)
Erlang is a very nice fit for many of the requirements various components in Kolab have ... perhaps one of these days I'll write something more in detail about why that is. For now, suffice it to say that we've started using Erlang for some of the ... [More] new server-side components in Kolab. The most common application protocol spoken in Kolab is IMAP. Unfortunately there was no maintained, functional IMAP client written in Erlang that we could find which met our needs. So, apparently the world needed another IMAP client, this time written in Erlang. (Note: When I say "IMAP client" I do not mean a GUI for users, but rather something that implements the client-side of the IMAP protocol: connect to a server, authenticate, run commands, etc.) So say hello to eimap. Usage Overview eimap is implemented as a finite state machine that is meant to run in its own Erlang process. Each instance of an eimap represents a single connection to an IMAP server which can be used by one or more other processes to connect, authenticate and run commands against the server. The public API of eimap consists mostly of requests that queue commands to be sent to the server. These functions take the process ID (PID) to send the result of the command to, and an optional response token that will accompany the response. Commands in the queue are processed in sequence, and the server responses are parsed into nice normal Erlang terms so one does not need to concern themselves with the details of the IMAP message protocols. Details like selecting folders before accessing them or setting up TLS is handled automagically by eimap by inserting necessary commands into the queue for the user. Here is a short example of using eimap: ServerConfig = #eimap_server_config{ host = "192.168.56.101", port = 143, tls = false }, { ok, Conn } = eimap:start_link(ServerConfig), eimap:login(Conn, self(), undefined, "doe", "doe"), eimap:get_folder_metadata(Conn, self(), folder_metadata, "*", ["/shared/vendor/kolab/folder-type"]), eimap:logout(Conn, self(), undefined), eimap:connect(Conn). It starts an eimap process, queues up a login, getmetadata and logout command, then connects. The connect call could have come first, but it doesn't matter. When the connection is established the command queue is processed. eimap exits automatically when the connection closes, making cleanup nice and easy. You can also see the response routing in each of the command functions, e.g. self(), folder_metadata which means that the results of that GETMADATA IMAP command will be sent to this process as { folder_metadata, ParsedResponse } once completed. This is typically handled in a handle_info/3 function for gen_server processes (and similar). Internally, each IMAP command is implemented in its own module which contains at least a new and a parse function. The new function creates the string to send the server for a given command, and parse does what it says returning a tuple that tells eimap whether it is completed, needs to consume more data from the server, or has encountered an error. This allows simple commands can be implemented very quickly, e.g.: -module(eimap_command_compress). -behavior(eimap_command). -export([new/1, parse/2]). new(_Args) -> <<"COMPRESS DEFLATE">>. parse(Data, Tag) -> formulate_reponse(eimap_utils:check_response_for_failure(Data, Tag)). formulate_reponse(ok) -> compression_active; formulate_reponse({ _, Reason }) -> { error, Reason }. There is also a "passthrough" mode which allows a user to use eimap as a pipe between it and the IMAP server directly, bypassing the whole command queueing mechanism. However, if commands are queued, eimap drops out of passthrough to run those commands and process their responses before returning to passthrough. It is not a complicated design by any means, and that's a virtue. :) Plans and more plans! As we write more Erlang code for use with Kolab and IMAP in general, eimap will be increasingly used and useful. The audit trail system for groupware objects needs some very basic IMAP functionality; the Guam IMAP proxy/filter heavily relies on this; and future projects such as a scalable JMAP proxy will also be needing it. So we will have a number of consumers for eimap as time goes on. While the core design is mostly in place, there are quite a few commands that need to be implemented which you can see on the eimap workboard. Writing commands is quite straightforward as each goes into its own module in the src/commands directory and is developed with a corresponding test in the test/ directory; you don't even need an IMAP server, just the lovely (haha) relevant IMAP RFC. Once complete add a function to eimap itself to queue the command, and eimap handles the rest for you from there. Easy, peasy. I've personally been adding the commands that I have immediate use for, and will be generally adding the rest over time. Participation, feedback and patches are welcome! [Less]
Posted over 8 years ago by Olivier Churlaud (ochurlaud)
Hey there! You might have heard of my proposition to reorganize the wikis. I posted it on kde-devel, kde-www and kde-community. What’s the point? You might have seen that Techbase [1] is a mess[citation needed]. It’s quite hard to know if an article ... [More] deals with KDE4 or KF5 as plenty of the pages are drafts for another draft that is almost done… but almost. What’s the plan? So basically, our part in the sprint would be to take Techbase, read most of the documentation, and order/tidy up. This would entail putting all the KDE4-related pages in a new namespace, the drafts and unneeded pages in an other (to review before being removed),… It’s also about planning for the future: do we accept to do a sprint for this every N years? Or do we introduce a sort of validating process for what is going to be in the wiki? And all the ideas that can come to you as well. And that’s not all! We are kindly invited for this sprint by the teams of WikiToLearn, Plasma and KDEEdu, so we’ll meet all these humans who were hidden under names and pseudos. And that’s nice! (Yes, it will be my first Sprint, and also the first time I meet KDE developers for real…). Where and when? Here comes the best part: the Sprint will take place at CERN. I don’t know if we’ll get to visit (but I hope so), but already having been there, I can say being in the place is already quite exciting! So let’s meet on March 7th in Geneva! How do I join? Here is the link where you need to register if you want to join physically: [2]. Please choose Wiki/Documentation as the team you are joining. Here are the directions to get to CERN: [3]. Is it possible to give a hand remotely? Of course it’s possible. I don’t know how it is going to be organized to deal with the different timezone but any kind of help is welcomed, always! And now? I’ll drop a link on the mailing-lists so that we prepare the Sprint some time ahead… But I think that there is no hurry See you there and in the mean time: Cheers and have fun! Links [1] Techbase: https://techbase.kde.org/ [2] Register here: https://sprints.kde.org/sprint/291 [3] Get to CERN: http://home.cern/directions [Less]
Posted over 8 years ago by Mirko Boehm
Today Hyundai Motor Company and Kia Motors Corporation are joining the Open Invention Network as community members. Linux and Open Source software are becoming a mainstay in automotive computing. With the first global automotive companies joining ... [More] OIN, a trend has been set towards Open Source collaboration and patent non-aggression in the automotive industry. The news is in the press here on Yahoo Finance, here on Fortune.com and in many other places. OIN’s community practices patent non-aggression in core Linux and adjacent open source technologies by cross-licensing Linux System patents to one another on a royalty-free basis. Patents owned by Open Invention Network are similarly licensed royalty-free to any organization that agrees not to assert its patents against the Linux System. Within OIN, I am responsible for the maintenance of the Linux System Definition, the field of use for OIN’s patent non-aggression pledge. I am very proud of the great work the OIN team does to protect Linux and Open Source. The OIN license can be signed online. Ask your company to join the Open Invention Network community, please!Filed under: English, FLOSS, KDE, Linux, Open Invention Network, OSS, Qt Tagged: FLOSS, FSFE, Linux, OIN, technology [Less]
Posted over 8 years ago by Aaron Seigo (aseigo)
These days, the bulk of my work at Kolab Systems does not involve writing code. I have been spending quite a bit of time on the business side of things (and we have some genuinely exciting things coming in 2016), customer and partner interactions, as ... [More] well as on higher-level technical design and consideration. So I get to roll around Roundcube Next, Kube (an Akonadi2-based client for desktop and mobile ... but more on that another time), Kolab server hardware pre-installs .. and that's all good and fun. Still, I do manage to write a bit of code most weeks, and one of the projects I've been working on lately is an IMAP filter/proxy called Guam. I've been wanting to blog about it for a while, and as we are about to roll version 0.4 I figured now is as good a time as any. The Basics of Guam Guam provides a simple framework to alter data being passed between an IMAP client and server in real time. This "interference" is done using sets of rules. Each port that Guam listens has a set of rules with their own order and configuration. Initially rules start out passive and based on the data flow may elect to become active. Once active, a rule gets to peek at the data on the wire and may take whatever actions it wish, including altering that data before it gets sent on. In this way rules may alter client messages as well as server responses; they may also record or perform other out-of-band tasks. The imagination is the limit, really. Use Cases The first practical use case Guam is fulfilling is selective hiding of folders from IMAP clients. Kolab stores groupware data such as calendars, notes, tags and more in plain old IMAP folders. Clients that connect over IMAP to a Kolab server which are not aware of this get shown all those folders. I've even heard of users who have seen these folders and delete them thinking they were not supposed to be there, only to then wonder where the heck their calendars went. ;) So there is a simple rule called filter_groupware_folders that tries to detect if the client is a Kolab-aware client by looking at the ID string it sends and if it does not look like a Kolab client it goes about filtering out those groupware folders. Kolab continues on as always, and IMAP clients do as well but simply do not see those other special folders. Problem solved. But Guam can be used for much more than this simple, if rather practical, use case. Rules could be written that prevent downloading of attachments from mobile devices, or accessing messages marked as top-secret when being accessed from outside an organization's firewall. Or they could limit message listings to just the most recent or unread ones and provide access to that as a special service on a non-standard port. They could round-robin between IMAP servers, or direct different users to different IMAP servers transparently. And all of these can be chained in whichever order suits you. The Essential Workings The two most important things to configure in Guam are the IMAP servers to be accessed and the ports to accept client connections on. Listener configuration includes the interface and port to listen on, TLS settings, which IMAP backend to use and, of course, the rule set to apply to traffic. IMAP server configuration includes the usual host/port and TLS preferences, and the listeners refer to them by name. It's really not very complicated. :) Rules are implemented in Guam as Erlang modules which implement a simple behavior (Erlangish for "interface"): new/1, applies/3, apply_to_client_message/3, apply_to_server_message/3, and optionally imap_data/3. The name of the module defines the name of the rule in the config: a rule named foobar would be implemented in a module named kolab_guam_rule_foobar. ... and for a quick view that's about all there is to it! Under the hood I chose to write it in Erlang because the use case is pretty much perfect for it: lots of simultaneous connections that must be kept separate from one another. Failure in any single connection (including a crash of some sort in the code) does not interfere with any other connection; everything is asynchronous while remaining simple (the core application is a bit under 500 lines of code); and Erlang's VM scales very well as you add cores. In other words: stability, efficiency, simplicity. Behind the scenes, Guam uses an Erlang IMAP client library that I've been working on called eimap. I won't get any awards for creativity in the naming of it, certainly, but "erlang IMAP" does what it says on the box: it's IMAP in Erlang. That code base is rather larger than the Guam one, and is quite interesting in its own right: finite state machines! passthrough modes! commands as independent modules! async and multi-process! ooh! aaaaaah! sparkles! eimap is a very easy project to get your fingers dirty with (new commands can be implemented in well under 6 lines of code) and will be used by a number of applications in future. More in the next blog entry about that, however. In the meantime, if you want to get involved, check out the git repo, read the docs in there and take a look at the Guam workboard. [Less]
Posted over 8 years ago by Jean-Baptiste Mardelle (j-b-m)
We have been working hard over the past months to improve stability, polish the interface and continue our big code cleanup. Kdenlive 15.12.0 will be released next week, and here are some of the changes you will get with this new version: New ... [More] Features We managed to add a few nice features. here are a few of them: Timeline effects and Bin effects can be temporarily disabled and re-enabled in 2 clicks A basic implementation of a copy / paste feature has been added, which allows you to save a part of your timeline and import it later inside another project with all effects and transitions being editable Track transparency: a simple click allows you to enable / disable transparency for a given track Icons now automatically adapt their color scheme (light or dark) to the UI theme More infos on the features should hopefully be published soon... General Workflow Improvements We did several small but nice changes to improve the workflow. Several context menus and buttons have been reviewed and changed to make the most useful features easier to find. You can also now drag an effect in the clip monitor to add it to the selected clip. Or define favorite effects that will be available from a quick pull down menu in the main toolbar... just to name a few of the changes. Stability We fixed many crashes and timeline corruption problems, so we hope you will enjoy working with this version. Testing Vincent Pinon started work on packages for Kdenlive's development version so that we can get more feedback before releasing a version. Team and Events As previously said, the Randa Meeting really helped the Kdenlive development, and we also hope to organize a small Kdenlive coding sprint in the first months of 2016. Mario Fux stepped in to organize a Kdenlive Café which will be a great opportunity to exchange about the present and future of Kdenlive. And as usual, several very motivated users really helped us improving Kdenlive by reporting issues, following and testing the fixes, proposing ideas, features and patches on the bugtracker, so a big thanks to them. [Less]
Posted over 8 years ago by Krita News
Here’s Nathan with a new update: I’m back with a new batch of tutorials for you! As promised, here are the overviews of the Beta instant preview and animation toolset in Krita. The next batch of tutorials will come at the end of the week, with the ... [More] 3rd part of the rocks painting series. And another video will focus on creating life bars, an essential UI element in many game genres, in Krita. I’m delaying the video about the tangent brush engine. I’ve written the overview, but I want to add 2 examples using Krita and Blender to show you how to use it in practice. It’s all coming out next Tuesday! The campaign is now over 150% funded! Less than €2000 to go and we get to the first stretch goal. Pretty cool, isn’t it? I’m going to do my best to get there, and beyond! [Less]
Posted over 8 years ago by Martin Gr&#xE4;&#xDF;lin
In this blog post I want to outline some thoughts on how the gaming experience can be improved on Linux. Situation on X11 On X11 the big problem for gaming is the Compositor. Games need access to the GPU and need to pretty much exclusively use the ... [More] GPU. Compare to a true console like a PlayStation: while the game is running you can be sure it’s the exclusive user of the GPU. The way how compositing works on X11 this cannot be provided. There is the compositor which needs to render the scene. The setup looks simplified like: Game renders through OpenGL/GLX X-Server notifies Compositor through XDamage extension Compositor schedules a repaint for changed area Compositor uses the XComposite extension to get a pixmap for the Game window Compositor binds pixmap to an OpenGL texture Compositor renders the texture using OpenGL/GLX to the composite overlay window X server presents the rendered image from the Compositor through kernel mode settings In this setup we have a few things which are not optimal for a fullscreen game: the roundtrips through Xserver-compositor and the possible delay added by the compositor. In such a setup the compositor will always slow down the game as it performs vsync, etc. Workarounds on X11 There is an existing solution to improve this which is known as “unredirection of full-screen windows”. The idea is that if there is a full screen window the compositor won’t run for it and the “normal” non-composited functionality of the X server is used. In my opinion this is the wrong solution to the problem, because the Compositor is still running, it still gets damage events (from possibly other windows) and might start to composite the scene at any time again (e.g. a notification pops up as a override-redirect window). In KWin/Plasma we have a better solution: blocking compositing. We can do that as we do not require compositing, other environments which require compositing can only use unredirection as best measurement. In fact we even have high-level API for games to tell us that they want to block compositing. It’s just one X atom, please use it. This also explains why in KWin/Plasma the option to fullscreen unredirection is not enabled by default. It has drawbacks for a non-gaming usage, while we offer a better solution for games. It also explains why I don’t care at all about gaming benchmarks through the PTS as that in my opinion tests an invalid setup for us. If we cared about it, it would be easy to just ensure that the games used by PTS disable compositing. Situation on Wayland On Wayland the setup is better as we don’t have X11 in between. So a setup looks like the following: Game renders through OpenGL/EGL Compositor gets notified through wl_surface damage Compositor directly presents the wl_buffer through KMS as it knows there is nothing else to see So the situation is much improved in an ideal case. I need to point out that KWin doesn’t support this ideal case yet and still renders through OpenGL, but that’s where we are going to. But I think there are still problems. Our Compositor still gets damage events from other windows, it gets woken up, etc. Running a game in a desktop environment means that there are other session processes which the game needs to share resources with. We want to have a PlayStation like setup: game everything, everyone else nothing. I don’t want KWin to take away important CPU/GPU time from the game. Kernel Mode Settings in games So what can we do? I thought about this and propose that we change gaming completely on Linux: remove the windowing system! Games should talk to kernel mode settings directly, games should interact with libinput directly. Let’s remove everything in between, we don’t need it, it only can worsen the gaming experience. When a fullscreen game starts, it can create a “sub-session” on a new virtual terminal and become the logind- session controller for that session. This would allow the game to open the device files for rendering and for input just like a Wayland compositor does. Rendering could be done through EGL on top of DRM/GBM just like a Wayland compositor. The game would have full control over rendering, there is no desktop environment to slow it down any more. And it would have control over mode setting. Need a different resolution? No problem, just set it. On a desktop environment that’s always problematic (terrible on X11, better on Wayland). For games in windowed mode nothing should be changed, those should stay on the desktop environment. Of course this would remove all interaction with the desktop environment. This is something which needs to be considered, like how to get Mumble to work in such a setup? Maybe the game could launch its own Wayland server? That breaks Alt+Tab! Well not really. For one on X11 at least games often grab the keyboard, so Alt+Tab won’t work anyway. And of course one can still switch with ctrl+alt+f1 to the running session. Games should also have a common way to achieve this in my opinion. There are certainly a few things which still need to be solved to get there, like how to start such a sub-session, how to return to the running session without needing to unlock the screen. The experience should be as good as on dedicated gaming console. So it’s still some work, but I think this is work well invested and better than trying to somehow make games work in Desktop Environments as that just cannot work as good as a dedicated gaming console. [Less]
Posted over 8 years ago by Randa Meetings
The end of the year is near and this year’s Randa Meetings ended quite some weeks ago. But just some days ago we published an extensive report about the happenings at this KDE Tech Summit: Randa Meetings 2015 – Huge Success Again. I’d say it’s worth ... [More] reading and looking at the pictures. And this edition of the Meetings wouldn’t have happened without the great help of supporters, donators and sponsors (in alphabetical order): All the supporters in our fundraiser BAR Informatik Biel/Bienne budgetcomputer.ch – used hardware ch/open – Swiss Open Systems User Group Edeltech Ioda-Net Sàrl Puzzle ITC Raiffeisenbank Mischabel-Matterhorn And last but not least all the local people in kitchen, house and surrounding that made this event possible. Thanks a lot to you! And if you want to be on this list next year don’t hesitate to contact us. So what about the future of the Randa Meetings? They will happen again next year and we’ve already a main topic: Multi-platform end-user application development: Bring KDE Apps to other platforms and strengthen them on their free home platforms. This might include stuff like improving KDE Frameworks 5 on other platforms like MS Windows, Android or Apple’s MacOSX, presenting and discussing how distribution works on other systems than GNU/Linux (Windows installers, app stores and application bundles) and learning from the experience projects like Krita, digiKam, Rkward, Kdenlive & Co collected. We’d like to bring this information to more KDE Apps and work on this together. So if you would like to bring your KDE Application to other platforms than just GNU/Linux, have some knowledge about Qt on these platforms or “just” know a lot about how to integrate software on these platforms hesitate and add yourself to the date selection Doodle. We need to start early as the house is quite occupied in the summer months and there is a lot work ahead to make another edition of the Randa Meetings happen and another huge success. [Less]