Lately I found myself working on an ARM64 (aka aarch64) based system which in turn I don’t own. So I needed to get a system to build and test things on.
How?
First of all, you need to have qemu static builds installed. For example, for ArchLinux you need to get them from AUR: $ yaourt -S qemu qemu-user-static binfmt-support
And then enable the aarch64 # update-binfmts --enable qemu-aarch64
$ docker run -ti --rm -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static apol/test bash
X11
Once set up, it can be used as any regular docker image. For example passing -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix will give us access to X11, allowing to run apps: $ docker run -ti --rm -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix apol/test bash
One possibly wants to use Xephyr to test some stuff, probably on the safer side.
Similarly, you’ll get to use gdb or any tooling you need and is available for the architecture.
KDevelop
You get to code against your project against the platform you need by passing the extra required arguments, then most features discussed here apply.
Beyond…
Granted it will work rather slow, as it’s emulation, but given the alternative is not being able to work at all, I’m happy.
Note that most of this applies for any architecture, replacing aarch64 for any architecture supported by qemu (and your distro of choice): You can check /usr/bin/qemu-*-static.
On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s Builder or Qt Creator).
There are different platforms that we’ll be developing for and they need to be easily reachable when coding and testing. Both switching and interacting transparently with the different platforms.
To that end I implemented 4 approaches that integrate different runtimes:
Docker, allows you to develop directly against virtually any system. This is especially interesting because it enables to reproduce the environment our users are having: behavior on execution and project information (i.e. the imports are the ones from the target rather the ones on our local system). Docker is a wide-spread technology in the cloud, I hope many developers will see the value in integrating the deployed environment into the IDE while they are coding.
Flatpak, is a solution that targets specifically desktop Linux applications. We are talking about distributing bundled applications to users, there we have the opportunity to integrate the tooling specifically to that end: from fetching dependencies to testing on other devices (see videos below).
Android, as you know it’s something I’ve been pushing for years. Finally we are getting to a space where the IDE can help get some set up troubles out of the way.
Using the right SDK is not enough proof that the application will work as expected on every device, especially those our users will be using. Being able to easily send our application to another device to test and play around with is something I had needed for longtime. Especially important when we need to test different form factors or input devices.
In this video we can see how we can easily test an application locally and when it works just switch to Android and send to the device for proper test on the smaller touch screen.
Here we can see how we can just test an application by executing it remotely on another device. This is done by creating a bundle of the application, sending it to the device where we want to test it and executing it there.
Hassle-free contributions
You can’t deny it. You’ve wanted to fix things in the past, but you couldn’t be bothered with setting up the development environment. Both Flatpak and Docker offer the possibility to maintainers to distribute recipes to set up development platforms that can and should be integrated so that we can dedicate this 1 hour in the week-end to fixing that bug that’s been annoying us rather than reading a couple of wikis and – oh, well, never mind, gotta make dinner.
We can do this either by providing the flatpak-builder json manifest (disclaimer: the video is quite slow).
Or a Dockerfile.
You can try this today by building kdevelop git master branch, feedback is welcome. Or wait for KDevelop 5.2 later this year. 🙂
One of the things I’ve heard on every KDevelop sprint is: we should be light, like Kate but with our added value.
We’ve addressed this in many ways so far: we’ve optimized the code for performance so it’s more responsive and starts reasonably fast, we’ve made sure most done is accessible using the keyboard so we don’t feel clumsy and overwhelmed by all the options.
Today, I wanted to reflect on 2 things:
What do we miss to be that ideal light editor?
What’s a good lightness inspiration?
Otherwise, TLDR, there’s a video below.
What do we miss?
The avid Planet KDE reader will know that being light is a complex concept, there’s many ways to perceive lightness: Is Kate light? Is KWrite light?
When we talk about lightness, we generally refer to different metrics. If something is worth waiting for, we wait, and that’s fine. We don’t want to feel we’re wasting our time. A good example there I’d say it’s Chromium. It’s probably one of the heaviest beasts we run on our systems. Nevertheless, it doesn’t feel as such (at least until you run out of memory).
There’s another point of view: We bomb users with features. In fact, it’s awesome to have features and it shouldn’t be a trade-off. On the other hand we’re never using all features at the same time, optimizing that would be awesome. We should work on it: identifying the different workflows and creating user interfaces that enable them.
What’s the role model?
One of the developments that have struck me the most during last years is Kate. Instead of focusing on the editor, it went the KDevelop route: it has started to offer all of the information at once (especially odd, given that there’s quite some feature overlapping).
More generally, if I look at what others are doing, I see two major groups:
On one hand, there’s atom.io and sublime that seem to be doing something very similar. Most of the components they have we have as well, but then the focus is rather different: they have very few visual interaction components, mostly just the menu, so you can just play with the text and you know where to go look for stuff. UI’s are usually embedded in the source code view.
On the other hand, there’s Eclipse or Visual Studio that do something quite similar to what we do: present everything in the traditional desktop application way with docks and a couple of smart tricks, because they try to tackle the whole workflow problem.
I understand how we got to where we are, but I also really understand why people can prefer something like atom. My feeling is that “It doesn’t make me feel like I should be debugging while I’m coding”, even though they oversimplify on some areas.
What do I propose?
I decided that I wanted to feel what’s to work without all the clutter, so I implemented a Concentration Mode for KDevelop. I stripped most of the visual stress, so usually we’re left with the good ol’ katepart editor, with all KDevelop‘s features. I’ll become my own guinea pig: now that I have it clean, how do I use the tools? Can I still do the same things? As discussed on the mailing list, this has had some fruits already.
I think it’s really cool: code, code, code, quick open and shortcuts.
The Video!
Now, a bit of a video implementing what I discussed here.
What to look for:
We get to hide the navigation handle, leaving only the toolbar, the document title and the central view.
The toolviews are still accessible.
The menu is still accessible
For now, I can decide to just see what I’m working on. Now.
Since the beginning of my involvement in KDE and, more specifically, my involvement with KDevelop, many people have come to me and said that what we “actually need” is an SDK. So far, I never gave this much thought. Especially given that for me, the SDK was the system I’m running on and, by extension, the packaging system of my GNU/Linux distribution.
After all this time and given one of KDE Frameworks goals is to broaden our portability, I started wondering about the subject again. Some of the pieces are starting to come together already, but I still think we need to actually glue them together in a clear and pragmatic approach.
Premise: we want to build an SDK on top of the tools we generally use:
CMake, Qt, KDE Frameworks 5, Plasma, QML and C++.
For starters, we have two different major scopes: Integration with Plasma and Cross-platform facilities.
KDE Applications should be as distributable and portable as possible. On the other hand, we should be providing the tools to specifically integrate to the Plasma Workspaces.
Applications have different use-cases than the Plasma Workspaces. While applications need to be as easily distributable as possible, Plasma will want to have as much control on the system as needed to work accurately. Therefore, we want applications interacting with Qt5+KF5 and integrating through Qt abstractions, while Plasma will want to interact random components in the system regardless without fear.
What I propose:
Figure out which frameworks are portable and which are Plasma Platform integration frameworks. (e.g. KDED modules, KNotifications, Solid: are they portable? do we want to support the different platforms?)
Figure out what do we mean by supported platform (both in the case of Plasma and Applications).
Once we get there, we will be able to think about developers and:
Offer a sensible set of tools to support the development and ease testing.
Figure out a packaging plan for the libraries and tools for developers, so they can start using them for their development.
Figure out a deployment plan for the frameworks on the different platforms, so that deployed applications know how to rely on the needed dependencies.
So this are mostly thoughts, I would like to know if you’d be interested in the project. I think it makes a lot of sense to figure this out and then gather this year’s Randa meeting to make sure we’re coming up with a coherent next development platform.
Usually I don’t blog because there’s not much going on. Lately it’s been because there’s been too much things going on.
As always in communities, it’s not something somebody is doing in his corner, but some synergy coming together in a beautiful and convoluted way. Let me try to sort what I’m talking about.
The Akademy 2013 is happening soon. It’s going to be a very interesting event, KDE is evolving in a fast pace, more than most of us realize. This year’s Akademy will be crucial to the future of the project, I wouldn’t miss it.
This year, Akademy comes with a small present in it. The Akademy-es 2013 will happen in Bilbao as well, the two days before the Akademy. It’s our biggest opportunity to help people from Spain join the KDE awesomeness. If you are around and understand Spanish, don’t hesitate to join!
We’ll have talks, we’ll have discussions and we’ll tell you that you must go to Akademy. 🙂
Qt5 is gaining traction and we’re getting up to speed to adopt it through the KDE Frameworks 5 Project. The Qt contributors will be meeting in Bilbao as well, discussing what features we’ll be finding in Qt 5.2 and further. That means that they’ll be deciding what things we’ll have available for future releases by KDE!
Ok, so I’m saying that we’ll be gathering a bunch of people talking about what we do. What’s so special about that?
Well, first of all it’s not just people. It’s people who are passionate about what they do, the people who have created the KDE we all know and the one we don’t know about yet.
Personally, these are the topics I’d like to discuss about this year:
I want to talk to distributions. I want to remind them that Muon Discover will be working on their platform soon. I want to work together with them to make sure they are on board and that it will go smoothly.
I want to get in touch with the KDE Edu fellows, see what they’re up to (I hear that there’s some new awesome application coming together). I want to discuss about Khipu with them, it’s seeing some very interesting progress recently, I’m hoping to see it released soon!
The KDevelop team will be having their meeting there as well. I foresee a closer and closer KDevelop 4.6 release, and we want to make this one the best ever. Also I’d like to discuss some otherwise interesting stuff as well such as some changes in the C++ support that we’ve been discussing.
I’m quite excited about the KPeople project, as well. It’s coming together very well, getting ready for applications to adopt it. KDE Telepathy has already started worked on supporting it on some parts. Also KDE PIM should be adopting it soon, so will other projects. I want to easily interact with my friends from our applications. Awesomeness.
And last but not least, the KDE Frameworks 5 project, that I already talked about before. It’s probably the most important initiative in KDE, at the moment. Let’s push it all together, at Akademy!
I know it’s been a huge blog post, but also I think that it displays where we are. Lots of people, a big community, with smaller communities in it, coming together for a greater purpose, having beer and exchanging ideas.
As we announced recently, we’ve kept working on the stable version of KDevelop to bring you the polished software you’re looking for.
Many bugs have been fixed during the last weeks, I think we can safely say that it has improved since the last beta and of course, KDevelop 4.3.
If you want to try it now that it’s still hot, you will be able to find the tarballs for you to compilehere.
Additionally you can use the packages from some of the more popular distro’s. Feel free to follow the instructions of the packagers. For now, I’ve been told it’s already available for Fedora 18, OpenSuse KDE:Distro:Factory and ArchLinux [testing]. If you want to know about your distribution, please contact them! 🙂
Sometimes it’s hard to get started using a tool, some people call it white page syndrome, in KDevelop we had the gray page syndrome:
I guess you see what I mean.
To solve this problem we discussed many times about creating some way to Kickstart a KDevelop session properly, this is what I came up with. It’s nothing very different from what others do, but it’s ours, so that makes it immensely awesome. I guess you’ll understand about it easy by putting a video, looking forward to your feedback!
Hi!
It’s been probably too much time since we announced a KDevelop version for the last time, but hey! Here we are, as alive as ever! 🙂
Actually it hasn’t been a quiet year, there’s been quite a lot of development going on, specially with regard to stabilization, improved integration facilities and, of course, Milian’s c++11 work, which is not ready yet, but much closer than it used to.
Long story short, here we can find the packages to compile it here, together with some verbose changelogs in case you’re interested.
Also you can wait for your-favorite-distro to package it, but more on that in the future! 🙂
Today I would like to talk a little about some work I’ve been doing recently in KDevelop in order to assure we have a good path for the new KDevelop user and KDE or free software Developer.
I think that KDevelop has been quite good at being adopted by people who know their way in the development process: in few words, people who already know the language they’re using and usually they can fill any lacking feature KDevelop might have, by doing some old-style terminal hacking :). No problem with that, but apparently not everyone is born with some wizard skills, so I’d like to improve this situation.
There are many aspects that can be improved and some have been lately. One of the most annoying things that we found (mostly in Randa, in the KDevelop team and some random spontaneous meeting) to be more annoying, was our “New Project” wizard, specially when it comes to start new technology based in KDE.
This is what it looked like before starting working on it:
There are some things I don’t like here: The tree view looks clumsy and doesn’t lead the user anywhere, so whenever I have considered to create a new project from this dialog, I’ve felt violated somehow. What I’m going to show here has to be taken as a first step towards where I want future KDE Developers experience to start (if they are starting a new project).
The idea here is that the user will select, first of all, what kind of application is going to be created, roughly: KDE Application, just a standard application, a web service or whatever it’s needed. Using KDE as an example, we’ll select if we want to create a console application, GUI application, Plasmoid, etc. Finally, we’ll select the language we want to use be C++, Python or whatever it’s available.
That last step change is important, because we’re adding more importance at what we are doing (a Plasmoid for example) than if we are going to do it in C++ or Python.
From this point there’s many things to be done:
Make it possible to create new applications from the KDE Examples
Add some category information, categories are not translatable right now and they can’t have an icon. I’d like to see this improved.
KNewStuff support to download new templates?
Make sure the KDE GUI application templates are equivalent for C++ or Python.
Improve the template’s description. Add links to techbase!
Think about the templates you always wanted as a kid and contribute them!
… many other things in your imagination 🙂
If someone is interested in helping, just ping me in IRC at #kdevelop in freenode, comment here or send me an e-mail, your call! 🙂
Every project has these things nobody looks into, like these corners nobody clean. For some reason today we realized that we ¿still? have, in our repository, some files likethis.
Here there’s a good quote:
– KDE 2 is not supported, neither Qt 2.0. KDE 2 is in development and KDevelop will be ported after the next KDE 1.1.x release.
Of course, is not very clear that we’re going to port KDevelop 4 to KDE 2,… just yet. 🙂
Here’s the (not-so-)pretty picture of the day:
PS: Yes, we guess those were brought back by the git conversion but it’s still funny :).
