|
|
|
Posted
8 months
ago
by
Alex Fiestas (afiestas)
Fixing mtp support for various pieces of the workspace I realized a small paper-cut I could do to improve the experience when handling external devices such pendrive or usb hard drive. The paper cut is quite
... [More]
simple, before these patches we were using the “device description” for all devices, which make sense for devices always plugged into the computer for example the normal Hard Drive where your operating system is usually installed, but it doesn’t make sense for removable devices.
You will understand this better and quicker with the following screenshots:
and after
Patches are under review, if everything goes ok and I’m not breaking anything (little bit concerned about freeBSD support) will backport this to 4.9.
Cheerz !
[Less]
|
|
Posted
8 months
ago
by
Luca Beltrame (einar77)
As others, bigger members in the KDE community say, “nobody will do it for you, and therefore they will”. The patch from the title comes from such a story. Let’s give some background first: I’m really a heavy activity
... [More]
user, especially when working. My home PC has about five activities, my work one 3, and I managed to compartimentalize the various “topics” that each activity does pretty well.
After an update a couple of weeks ago from the latest code from KDE git, I started noticing weird behavior. Activities would not start when stopped, and there was no way of getting an application on a single activity. As I had set up KWin rules, that made things even worse.
Like many KDE users before me, I found myself in front of a bug.
We got a problem… what to do?
What to do, indeed? First of all, I opened a bug report. There’s no way a KDE developer can find a bug if it occurs only to me if I don’t tell him/her. And since emails and IRC communication tend to get lost, it’s always better to use the bug tracker. However, my initial report was very sloppy, as I didn’t know what was the cause. There was no way it could be useful for Ivan (the kactivities library’s developer).
Hunting the beast
So first, I tried to investigate more about the conditions of the bug. What would trigger it? Why sometimes it seemed not to appear? I tracked it down to KWin’s handling of activities: setting up fresh activities meant that they worked, but only if it was restarted. I thought about pinging Martin, KWin’s maintainer, but I was not sure it was the right cause. As the bug made my activity usage worthless, I had two options: put up with it, or do some of the dirty work myself.
I chose the latter.
I have been learning C++, and while I’m not even close to being able to do something in Qt/KDE, it was enough for me to plant some debug information in KWin and in kactivitymanagerd, the activity manager daemon. After about two hours of tests and recompiles (remember, I’m quite inexperienced!) I found that KWin was not getting the lists of activities correctly from kactivitymanagerd.
But it was working before, wasn’t it? Exactly when, though? In that moment, I remembered that git offered a tool that would help me: git bisect. About thirty minutes later I found the commit causing the regression I was seeing. I then added all the information to the bug report. Not content, I also asked a few other people to reproduce it.
The solution
One of these was Aaron himself, who confirmed the issue and then brought it up to Ivan’s attention. With the information he had, he was able to find the cause and commit a possible fix to KDE’s git repository.
So what’s the conclusion of this? I doubt this would have happened without actually doing some of the dirty work myself. This does not mean you really need to go to these lengths when doing a bug report, but when you encounter one, try to give as much as information as possible: as you could see, my initial hypothesis of KWin being the culprit was not correct. If you file detailed bug reports, not only the developers will be able to fix the bugs faster, but it will also make their lives considerably better.
FOSS is all about collaboration and sharing: sharing my time to investigate an issue and helping the developer fix it made the software better for those that will use it tomorrow, or in the next version. And this is also possible thanks to the strength of the KDE community. [Less]
|
|
Posted
8 months
ago
by
Tom Albers
Day 1 started at 9h, I was explicitly reminded that I was 10 minutes late. After a great breakfast we went to our conference room. Nothing mini about the conference room in this mini sprint. We started a hangout with Ben Cooksley so we spent the
... [More]
morning working together. First matter we needed to fix was the start of the User Working Group. We have setup the site a month ago and it was ready for prime time. You can read about it on the UWG-website. There is also a forum now. I invite you all to read the mission of this working group on the site, fill in the survey and become a part of the new User Panel.
After that Ingo and me catched up on some work within the sysadmin and webteam. We started evaluating the main site. Last year at the WebWorld-meeting we decided that the new site should be revamped and we choose WordPress as CMS. Now a year later we still don’t have that site live. And it’s not going to happen. We simply don’t have the resources to get it up and running. What I suggested is that we stop trying to do it in WordPress and switch to Drupal. Changing the tool does not magically make the site, but what it does do is making it maintainable. The Dot is already Drupal and behindkde.org as well. That means the theme is finished and we can just focus on getting the content right. I’m personally motivated to get that new site live as soon as possible. If you want to help, drop a comment, if you don’t want to help, that’s fine, just don’t complain afterwards that links to the site are broken or content is missing or stuff like that.
For dinner we drove up to Dortmund where we ate at Mongos. You can get some pictures here. When we arrived we ended up in a crowed heading for some soccer match. And when we were done eating we … ended up in the same crowd leaving the stadium. Ah well.. dinner was good and we had a chance to brainstorm a lot. For example about bugs.kde.org. We really need to draw up a plan for that site. Each year we throw more iron at it to keep it running. But it is a beast. Basically we need to split it up into crashes, wishes and bugs and then we need to decide if bugzilla is the right choice for each of those categories. I’m betting it won’t be. We decided that we will work on a document which will layout the plans for the future of bugs.kde.org. Again if you want to be involved with drafting that document, leave a comment. If not… ah well, you know what i’m going to say.
Another big item we discussed was the future of subversion. Or rather, the lack of future for subversion. The sysadmin team is maintaining a complete infrastructure for subversion and for git. I think that’s silly and a waste of resources. Now a server is devided in two, one reviewboard for svn, one for git. Anonsvn and anongit servers. Commit hooks for svn and for git written in completely different languages. We are a big project, but we can’t maintain two. We need to shut down subversion at one point in time. It does not need to be tomorrow, it can be in a year or so, but it still needs a date to ever happen. We will draft a proposal up and sent it around for feedback.
Now we are back in the Conferenceroom, looking at the results of the UWG survey which holds quite some interesting results. Can’t wait to analyse it in more details and show the results to you all. More tomorrow! [Less]
|
|
Posted
8 months
ago
by
Martin Gräßlin
I’m very excited about a change I have been working on for KWin since yesterday and which has entered the review process today. The result of it can be seen in this debug output of KWin: kwin(17876)
... [More]
KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(17876) KWin::SceneOpenGL::createScene: Forcing EGL Windowing System through environment variable
kwin(17876) KWin::EglOnXBackend::initRenderingContext: EGL version: 1 . 4
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TURKS
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20
Driver: R600G
GPU class: NI
OpenGL version: 2.1
GLSL version: 1.20
Mesa version: 8.0.4
X server version: 1.12.3
Linux kernel version: 3.2
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
kwin(17876) KWin::ShaderManager::initShaders: Ortho Shader is valid
kwin(17876) KWin::ShaderManager::initShaders: Generic Shader is valid
kwin(17876) KWin::ShaderManager::initShaders: Color Shader is valid
kwin(17876) KWin::SceneOpenGL2::SceneOpenGL2: OpenGL 2 compositing successfully initialized
Everything looks quite normal. OpenGL 2 based compositing, everything works fine, all effects load. But still there is something very exciting going on. Instead of GLX, the EGL backend is used, which has been written for the OpenGL ES 2.0 compositor. But this is the normal KWin, not the kwin_gles. We run OpenGL over EGL. To do so the current patch uses an environment variable KWIN_OPENGL_WS which can be set to egl. By default we still use GLX as that’s the safest what we can get at the moment with the available driver collection (and our egl backend needs some more love to be honest). It shows how important the refactoring which I have blogged about last week has been: without it this change would not have been possible.
This is a very exciting change as it means we have one backend to serve both OpenGL and OpenGL ES 2.0, it is also very exciting as it means that KWin is already prepared for the proposed new OpenGL ABI, which will deprecate GLX. The current OpenGL ABI pulls in GLX even if you don’t want GLX at all. I’m very happy that we have this EGL backend as this can turn out to be very important for the adoption of the new OpenGL ABI. It has been noted during the discussion at XDC that there is a chicken and the egg problem by distributions not providing EGL and software therefore not using EGL which means distros do not provide EGL. We can help here as we are a component which most distributions ship and which now requires (currently still optionally) EGL.
As a free software user I’m also excited that this is a change fully built on top of the free OpenGL stack. For a long time quite some functionality of KWin had only been available with proprietary drivers. Now not only the free OpenGL stack provides all we need, it also allows us to move into areas where the proprietary drivers are not yet. With my KWin developer hat on, I of course hope that the proprietary drivers will start to provide EGL, too.
Last but not least I am excited about this change as it is another small step on our long road through the country. It means that changes which will need to happen in the future can also be provided to the OpenGL version of KWin even if we do no longer use GLX as the primary backend.
Tweet
Buffer
[Less]
|
|
Posted
8 months
ago
by
Sebastian Kügler (sebas)
I’m on my way back from the Randa Meetings, where a few teams in KDE came together to collaborate on the next steps in their respective subprojects. I’ll post this to my blog after arrival, but as I’ve got some time to kill here in
... [More]
Basel, Switzerland, close to the German border, I decided to recap what we’ve been up to in the past days. I’ll concentrate on what the Plasma team has been working on. Present were Marco, Aaron, Afiestas, Giorgos, Antonis and myself. Giorgos and Antonis are still relatively new to the Plasma team, they concentrate on on making Plasmate rock, but have also done some excellent work this week on libplasma2. I’m happy to see the influx of enthusiast and skilled new developers in the team, as that reduces the busnumber and makes it easier to achieve our audacious goals.
Speaking of goals, we came to Randa with the plan to achieve a critical mass towards libplasma2. But what is libplasma2 exactly? Well, while we had some plans where to go with it, there were still a few items unclear — but not anymore! One of the big ticket items was the future of QGraphicsView in Plasma. QGraphicsView had been introduced in Qt 4.1. It’s basically a canvas on steroids, that gained features to create a fluid, widget-based UI using it. In Qt4, QtQuick uses QGraphicsView as its rendering backend. QGraphicsView is heavily based on QPainter, and employs a procedural way to rendering the UI. In Qt5 and QtQuick2, graphical display is supposed to move to an OpenGL scenegraph, making it possible to move much of the work involved to display a UI into hardware, so your GPU can do its magic with your UI. The benefit for the user is mainly that we’re able to have a much better performing rendering engine underneath (so smoother graphics), and more CPU time left to do the real work of your application. (One side effect will likely also be that we save a bit of power on mobile devices, as the GPU is much more efficient in doing these tasks – it has been optimized for it. (Experts say that the saving is in the range of an order of magnitude. Wether or not it will be noticeable to the user in the end, we’ll have to see later.)
As the OpenGL-scenegraph-based rendering is an entirely different paradigm compared to the procedural QGraphicsView, we have to rethink our use of QGraphicsView. Unfortunately, QGraphicsView is deeply ingrained into Plasma’s architecture. Even more unfortunate is that it’s not as bugfree as we’d like it to be, in fact much of the occasional rendering glitches you sometimes see in Plasma-based UIs are caused by QGraphicsView problems. Moving away from QGV and towards scenegraph is likely to solve this whole class of problems.
So one thing is clear, we want to move towards scenegraph. But what about all the old, QGraphicsView-based code? Well, we already started moving components of Plasma Desktop one by one to QML. This has begun with Plasma Workspaces 4.8, a lot more has moved in the 4.9 cycle, and yet another batch will move with 4.10, which will be released in January 2013. Our credo has been that we want to ship feature-equivalent ports, in order to keep the impact for the user as minimal as possible. There will be a point, however, when we will have to remove support for QGraphicsView in libplasma, and that will likely be libplasma2. We expect this work to take still more than a year, so also third party developers get ample time to move their code to the (much nicer) QML way of doing UI. But why not keep support for QGraphicsView? Well, it’s not that easy, as scenegraph and QGV are due to their respective paradigms more or less mutually exclusive. We’ve spent quite some time trying to come up with solutions that guarantee maximum amount of backwards compatibility, but we also had to ask ourselves if we have the manpower to implement and maintain workarounds for the incompatibilities between scenegraph and QGV. Moreover, what would the impact on our APIs and our code be? the tradeoffs were quite horrific, so in the end we decided to bite the bullet, and remove QGV from the frameworks5 branch. But what will Plasma2 with out QGraphicsView become? What we came up with is actually a very neat and clean approach: Our classes that currently manage the workspace (Corona, Containment, Applet) will become abstract managers that concert how components work together. Containments and Applets will have their UI written in QML (so we can do the rendering in the scenegraph, thus in the graphics hardware). They are extensible through C++ and various scripting languages that have bindings for Qt. This way, you can choose to implement the business logic in your favourite procedural language (C++, Python, Ruby, QtScript, etc.) and do the UI in a declarative way. Things like theming, localization, distribution, and all that will still be offered by the platform.
In Marco’s preliminary branch, where he removed support for QGraphicsView from libplasma2, the result is quite spectacular. The library is already about 30% smaller, and will likely lose another big chunk of code. That means more maintainability, a smaller memory and disk footprint and faster startup. As the functionality of QGraphicsView is more or less a subset of what we can do with QML, it’s not any less powerful or flexible. Just smaller, leaner and meaner (and also a bit easier to grok for developers using our APIs).
As you can see, we have been quite productive during this year’s sprint in Randa, and the above is only one part of what we’ve worked on. We’ve also made quite a dent into our TODO list for the KDE Frameworks 5 port, reviewed lots of patches, fixed bugs left and right, made existing code faster, and caught up with each other on various side projects. This all would not have been possible without the sponsors of the event, and the 287 people who donated through our fundraiser campaign to make this great event in a scenic location possible. Thank you all! [Less]
|
|
Posted
8 months
ago
by
David Edmundson (d_ed)
When dealing with bug reports, getting bugs that you can't reproduce is one of the worst situations to be in. Without the right information it's impossible to progress. Knowing where the bug is is 90% of bug fixing, if we are unable to reproduce
... [More]
something it's frustrating for everyone involved.
This week two bug reporters have stood out as being absolutely fantastic. So much so, they deserve a shout out on PlanetKDE.
Mohammad Al-Rashed, when he encountered a bug we could not reproduce, not only managed to find out it was reproducable if KWallet was disabled, but recorded and sent us a video of it happening. With this extra information, the bug was fixed within a day.
I also had a bug in LightDM that I couldn't shake. The bug only appeared in OpenSuse, and caused the entire KCM to crash. Weirdly, it never crashed when launched from kcmshell, but would crash every time it was invoked from System Settings.
I challenge anyone reading this could have a guess as to what would cause that, I certainly couldn't. Without being able to reproduce this I had absolutely no hope of fixing this.
Alin Marin Elena kindly went to the effort of giving me SSH access to a machine he set up specifically to reproduce this bug. That night I was able to work out what caused the crash, and another developer Hrvoje Senjan managed to trace it to the specific compile flag being used in the Suse packages that caused this bug to manifest itself.
The moral of all this is if you're waiting on a developer to fix a bug, be proactive and go beyond the call of duty to help supply all the information needed to fix it. [Less]
|
|
Posted
8 months
ago
by
KDE User Working Group
You wanted it, now you get it. Today we officially kick off the KDE User Working Group. The group is intended to bridge the communication gap between users and developers, with an overall goal of fixing communication problems. To help achieve
... [More]
these goals, we have created a
website at uwg.kde.org, which will serve as our platform for interacting with people.
On the website we have published our mission statement, which gives a small summary of what
we are up to. It also contains the notes of our meetings. We are trying to do regular meetings,
and as we use public meetings everyone can join in.
We want regular communication with and between users and developers. That is why we need
a User Panel, a group of people who find it ok that we approach them regularly and ask them
some questions and for feedback in general. Ask how we are doing, if we are improving, etc. If
you are interested in participating in this User Panel you can sign up here.
We have also created a survey. Before we get really active, we want to know where we stand.
How is KDE doing, what are we doing wrong and what should we focus on. We can then repeat
some of the questions in say 6 months or a year and see if we have improved. We invite those
interested to please complete the survey and help us here. No sign up needed, no strings
attached, just takes 5 minutes of your time. [Less]
|
|
Posted
8 months
ago
by
Alvaro Soliverez (Hei_Ku)
Last week I posted a junior job, to add support for Activities in KMyMoney. Well, I’m happy to say Alexander Jones sent us a patch, and it’s now in trunk, for everyone to try. For those of you daring enough to build from git
... [More]
master, you can go and try it. If you are not crazy enough, you’ll have to wait for the release of KMyMoney 4.7.0.
Once again, thank you Alexander on behalf of KMyMoney users.
UPDATE: Added a missing FIND_PACKAGE, found by Stephane. [Less]
|
|
Posted
8 months
ago
by
Tom Albers
After the big meeting in Randa last week, there is probably the smallest sprint ever going on in the Linux Hotel in Essen. Just Ingo and me. Ingo is in love with my Android transformer, he already named it Eloise :). I probably wont see the
... [More]
device back this weekend or even after it. Leave a comment if you know a good price I can ask Ingo for it.
Signing off now, seems like breakfast is at 9 and Ingo wants to stick to it. Pfff….
Plans for this weekend involve pusing UWG, fixing the translation system of the wiki’s, do some web and sysadmin stuff. I’ll be more concrete tomorrow! [Less]
|
|
Posted
8 months
ago
by
Jos Poortvliet
At the LinuxDays* conference in Prague we have a 'special' track about the effects of modern Media on our life - think about the risks of not owning your data in the cloud (and what is done against that by awesome people building Free networks and
... [More]
open cloud software), the benefits open source can bring (using open source technology and methods for disaster relief), and more.
I specifically wanted this track because I believe it is important to think about why we do what we do and to introduce people to the 'spirit' behind Free Software.
We've got a handful of really interesting speakers lined up there and we should promote that. The topic is important and of course it'd be good if more people showed up!
A good way of promoting this is by giving people a taste of what will be discussed through doing a few interviews with these speakers. You can find the list of speakers on this page and I have contact details of all of them. As questions, the following would most likely get (and keep) them talking:
Tell us about yourselfWhat will you talk aboutHow did you get involved with that and why do you care about it so much, why does it matter?What do you have to say to the (potential) visitors of the conference, what would you say is your message?
It would of course be even more awesome if we could interview some of these folks on video, say via a Skype or Google Hangout session...
Anyway, I need someone to help me with this. It is easy: all you have to do is mail these folks (I'll give you their addresses), ask them if they ware OK doing an interview, if OK either do the skype/google hangout session (maybe together with me?) or mail the questions, collect the answers, maybe do a bit of back-and-forth if things are unclear, and put it all in 1 or a few articles with me.
Upside: you not only get to help a big Linux event in Prague and do a bit of writing with someone who has some experience, but you also get to chat with these very interesting folks!
Who wants to help? Mail me... jos at the opensuse servers ;-)
* and openSUSE Conference and GENTOO miniconf and SUSE Labs conf... If you have a 4-in-one conference, no common name (but a common slogan: Bootstrapping Awesome), how do you call it? Hard, hard... Poor me... need to think about that next time we co-locate :D [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.