24 Jul 2014

feedPlanet KDE

Kate “master” branch now KF5 based!

Hi,

from today on, the master branch of kate.git is KF5 based.

That means, for the next KDE applications release after 4.14, Kate will use the awesome KF5 stuff!

The KTextEditor framework is already in a good shape and most active KatePart development is since months pure KF5 based.

The same should now be true for Kate itself (and KWrite).

Pâté will need a lot of love, as PyQt5 is there, but PyKDE5/PyKF5 still in the works.

Happy hacking, help us to make KF5 based Kate awesome, too.

For 4.14: keep fixing bugs, but all new shiny stuff that might regress things really should only go into our KF5 based master branch!

24 Jul 2014 6:18pm GMT

Let’s party!

Yesterday, we released ownCloud 7. You might have read that somewhere on the internet - it was widely announced and broadly picked up. If you do not have ownCloud yet, you really should try it now, and if you are one of the people happily using ownCloud for a while, update soon!

In my opinion, ownCloud 7 is a real step ahead. So much work went into it from the brave server guys, and the result is simply impressive: It is fast, beautiful and fully focused on what it is supposed to be and do: File sync and share, even though you still have of course all the other useful stuff like calendaring and such.

Apart from the wellknown features ownCloud 7 also brings some things that you do not see on the first look. Some of these things relate to syncing and as a guy working mainly on the sync client I am especially happy about that: Already with the current released clients you will see a performance win in syncing, because ownCloud 7 handles parallel HTTP requests way better. Moreover, ownCloud 7 sends some interesting information about it's files, and the next generation of sync clients will for example know which files are shared and their permissions. We are currently working on some exciting stuff on the client side, stay tuned.

Release Party ownCloud 7

That all should be reason enough to celebrate together, because ownCloud is done by all of us in the community.

On Tuesday, august 5th, we will do a Release Party in Nuremberg, Germany. As last time, the Coworkingspace Nürnberg is hosting us. We will start at 18:00.

Everybody who is interested in ownCloud for whatever reason is very welcome to show up. We will probably have a short informal demonstration or two, but of course plenty room for questions, discussions, meet and greet with all kind of FOSS people, some core ownCloud people, nice beer and big fun.

You really should come! And don't forget to tell your friends, thanks!


24 Jul 2014 5:10pm GMT

No Gmail integration in 4.14 after all :(

Hi folks,

I'm sorry to bring bad news, but after trying to fight some last minute bugs in the new Gmail resource today, I realized that pushing the resource into KDE 4.14 was too hurried, and so I decided not to ship it in KDE 4.14. I know many of you are really excited about the Gmail integration, but there are far too many issues that cannot be solved this late in 4.14 cycle. And since this will probably be the last 4.x release, shipping something that does not perform as expected and cannot be fixed properly would only be disappointing and discouraging to users. In my original post I explained that I was working on the Gmail integration to provide user experience as close as possible to native Gmail web interface so that people are not tempted to switch away from KMail to Gmail. But with the current state of the resource, the effect would be exactly the opposite. And if the resource cannot fulfil it's purpose, then there's no point in offering it to users.

Instead I will focus on implementing the new native Gmail API and merging together the existing Google resources to create a single groupware solution that will provide integration will all Google's PIM services - contacts, calendars, tasks and emails.

24 Jul 2014 2:32pm GMT

23 Jul 2014

feedPlanet KDE

It’s Aliiiiive!

On February, I wrote a blog post entitled "Leveraging the Power of Choice", in which I described an idea I had discussed with Àlex Fiestas about making it easy for users to choose between different Plasmoids for the same task (e.g. different application launchers, task managers, clocks, …). At the time of my writing the blog post, Marco Martin already had ideas about how to implement the feature, though he said that he wouldn't have time to implement it before the Plasma 5.0 release. Shortly after Plasma 5.0 was released, Marco started implementation as promised. We decided it would make sense to start a thread in the VDG forum to collect ideas for the UI's design. Together with several other forum users (most notably rumangerst and andreas_k) we fleshed out the design, which currently looks like this:

Image of Plasmoid alternatives switching UI draft

Plasmoid alternatives switching UI, latest draft

Fast forward to today, when Marco announced on the Plasma mailing list that "now the alternatives config ui has landed.". It always feels great to see one's ideas come to life thanks to the collaboration with developers and designers. Even now, though, input is still welcome in the forum thread!

Everyone who wants to switch between Plasmoid alternatives easily, look forward to Plasma 5.1!


Filed under: KDE

23 Jul 2014 9:22pm GMT

ownCloud 7 is out!

ownCloud 7 I have just published ownCloud 7!

This awesome release brings many new features. Among them, I'm most excited about the server to server sharing.

Server to server sharing is a first step in true federation of data with ownCloud: you can add a folder shared with you from another ownCloud instance into your own. Next step would of course be to also share things like user accounts and data like chat, contacts, calendar and more. These things come with their own challenges and we're not there yet, but if you want to help work on it - join us for the ownCloud Contributor Conference in Berlin next month!

A close runner-up in terms of excitement for me are the improvements to ownCloud Documents - real-time document editing directly on your ownCloud! We have been updating this through the 6.0.x series so the only 'unique' ownCloud 7 feature is the support for transparently converting MS Word documents, but that is a feature that makes Documents many times more useful!

There are many more features, you can find more details on the ownCloud website. The official announcement blog post is here.

A big THANK YOU

This would not have been possible without the hard work of the ownCloud community, so a big thank-you goes out to everybody who contributed! We have a large team of almost 100 regular contributors, making ownCloud one of the largest Open Source projects and that makes me proud.

Of course we have a lot of work to do: revelations of companies and governments spying on people keep coming out and our work is crucial to protect our privacy for the future. If you want to help out with this important work, consider contributing to ownCloud. We can use help in many areas, not just coding. Translation, marketing and design are all important for the success of ownCloud!

The release of ownCloud 7 is not only the conclusion of a lot of hard work by the ownCloud community, but also a new beginning! Not only will we release updates to this release, fixing issues and adding translations, but the community now also starts to update the numerous ownCloud apps to ownCloud 7.

Expect more from us. Now, go, install ownCloud 7 and let me know what you think of it!

23 Jul 2014 1:06pm GMT

What’s new in kf5 porting script: port_to_autogenerate_export_header.sh and others :)

This week I created some other scripts:

But as usual it will not convert at 100% you need to be sure that code compile before to apply script, apply script, read warning about script, fix warning, verify that it compiles after that, verify that it has same features as before (and report bug if you find it :) )

23 Jul 2014 7:45am GMT

21 Jul 2014

feedPlanet KDE

Barcelona, such a beautiful horizon

KDE Project:

When life gives you a sunny beach to live on, make a mojito and go for a swim. Since KDE has an office that all KDE developer are welcome to use in Barcelona I decided to move to Barcelona until I get bored. So far there's an interesting language or two, hot weather to help my fragile head and water polo in the sky. Do drop by next time you're in town.


Plasma 5 Release Party Drinks


Also new poll for Plasma 5. What's your favourite feature?

21 Jul 2014 7:22pm GMT

What is preloading?

by Jakub Hrozek and Andreas Schneider

The LD_PRELOAD trick!

Preloading is a feature of the dynamic linker (ld). It is a available on most Unix system and allows to load a user specified, shared library before all other shared libraries which are linked to an executable.

Library pre-loading is most commonly used when you need a custom version of a library function to be called. You might want to implement your own malloc(3) and free(3) functions that would perform a rudimentary leak checking or memory access control for example, or you might want to extend the I/O calls to dump data when reverse engineering a binary blob. In this case, the library to be preloaded would implement the functions you want to override with prelinking. Only functions of dynamically loaded libraries can be overridden. You're not able to override a function the application implements by itself or links statically with.

The library to preload is defined by the environment variable LD_PRELOAD, such as LD_PRELOAD=libwurst.so. The symbols of the preloaded library are bound first, before other linked shared libraries.
Lets look into symbol binding in more details. If your application calls a function, then the linker looks if it is available in the application itself first. If the symbol is not found, the linker checks all preloaded libraries and only then all the libraries which have been linked to your application. The shared libraries are searched in the order which has been given during compilation and linking. You can find out the linking order by calling 'ldd /path/to/my/applicaton'. If you're interested how the linker is searching for the symbols it needs or if you want do debug if the symbol of your preloaded library is used correctly, you can do that by enabling tracing in the linker.

A simple example would be 'LD_DEBUG=symbols ls'. You can find more details about debugging with the linker in the manpage: 'man ld.so'.

Example:

Your application uses the function open(2).

  • Your application doesn't implement it.
  • LD_PRELOAD=libcwrap.so provides open(2).
  • The linked libc.so provides open(2).

=> The open(2) symbol from libcwrap.so gets bound!

The wrappers used for creating complex testing environments of the cwrap project use preloading to supply their own variants of several system or library calls suitable for unit testing of networked software or privilege separation. For example, one wrapper includes its version of most of the standard API used to communicate over sockets that routes the communication over local sockets.

flattr this!

21 Jul 2014 10:38am GMT

20 Jul 2014

feedPlanet KDE

Updated xorg, linux kernel, systemd and graphics driver groups of packages move into the stable repositories

This move includes updates or rebuilds of the packages that are related to xorg, the linux kernel and graphics drivers, as well as various other packages that were updated in the meantime and are made available now. In total, more than 400 packages are moving to stable.

Notable updates:

20 Jul 2014 9:28pm GMT

My way to develop with git in KDE repos

From time to time there is the discussion of which workflow is better to develop with git, etc.

I'm not going to try to convince anyone on which workflow to use, i'm just going to explain what i do and explain why i think it's useful (and even more in the multi-developer KDE environment).

Let's picture the scenario we had a few days ago where there were lots of projects with three "live" branches, i.e. KDE/4.13, KDE/4.14 and master.

What is my way to develop?
* Bugfixes go to oldest "live" stable branch
* Features go to oldest "live" non frozen branch
* Branches are merged up

So let's say that I develop a new feature to support a whole new document format to Okular. Since that is a new feature it would go to the "oldest live non frozen branch", that in this case was master since KDE/4.13 and KDE/4.14 where already feature frozen. So I commit it to master and then "Branches are merged up" which in this case means nothing since there's no branch "up" from master.

Now let's say there's a crash bug when opening a file with three monitors. Since that is a bugfix, it'd go to the "oldest live stable branch", that in this case would be KDE/4.13. And then "Branches are merged up", so i would mean 4.13 into 4.14 and after that 4.14 into master. Ensuring that 4.14 and master also have the bugfix.

I think that this is a very useful way of developing using git branches for a lot of reasons, but the biggest of them is that for a random person it is easy to know if a "branch high in the hiearchy" has all the bugfixes or not, he just have to go to KDE/4.14 and to "git merge origin/KDE/4.13", if no change is brought over, it means that for sure all the bugfixes and code that was in the 4.13 release will be in the 4.14 release, otherwise it is hard to know.

So now that 4.13 is not going to be released anymore and 4.14 is a very young fork of master, i suggest that for every push you do to KDE/4.14 you go to the master branch and merge origin/KDE/4.14. This way you will have a master that is always fully merged with 4.14 and a third party person looking at your code (like the release manager) won't have to worry if it contains all the code or not.

Happy hacking!

And of course if you disagree with me, that's fine, not that i'm happy if my reasons did not convince you :)

20 Jul 2014 7:07pm GMT

QML binary modules

Developing a new project is usually done in two phases: first, the most important features are added, and the feature list of the project quickly grows. Then, the features need to be polished, bugs fixed, and the overall usability of the project improves slowly. This second phase is often considered less interesting than the first one, but personally, I like to fix small annoyances. Fixing them makes the difference between an experimental project and one that can be reliably used by real users.

During this GSoC, I try to work in small steps, implementing a big feature and then improving it, then implementing the next feature, and so on and so forth. This works quite well and allows me to keep a high motivation in what I'm doing: implementing a big feature is exciting but also exhausting, and improving existing features mainly consists of many small and easy commits that each have a noticeable effect. This week, I'll talk about one major feature and several small corrections that I've implemented for the KDevelop QML/JS language plugin.

The fixes

Javascript has no syntax to express that "this function is a member of this class". It is not directly possible to use something like function Class.method() as in C++. Developers are therefore obliged to declare class methods using function expressions:

1
Class.prototype.method = function (a, b) { return a + b; };

The fact that method is assigned a function has an annoying implication for the QML/JS plugin: when method is declared, it is a simple variable, a member of Class that can contain anything (a function, an integer, etc). This means that method is declared as a Declaration, not a ClassFunctionDeclaration. This is not really a problem, but this prevents KDevelop from displaying the right icon alongside the methods:

Functions not recognized properly

The solution is quite simple: when a Declaration has a function type (when it is actually a function), then the QML/JS plugin ensures that a function icon is displayed. An icon may seem unimportant, but such a bug is very easy to fix (one or two lines), and not fixing it would have immensely annoyed all the users of the plugin.

Functions recognized properly

The other small feature that I've added is support for the __proto__ member of Javascript object instances. This member is used by several Javascript libraries and may also be used in a couple of QML files, so it is not going to be useless:

__proto__ and object inheritance

Other small bugs have been fixed. For instance, in a QML file, typing ANamespace. lists the components declared in the namespace, and nothing else (previously, there was some garbage, for instance the namespaces imported by ANamespace, or the built-in Javascript classes). Code-completion for import statements is now way more useful, but more on that later.

Binary QML module imports

Back to the QML world. The goal of my GSoC is to have the best possible QML support in KDevelop, because KDevelop is already the best-in-class IDE for C++ Qt development, and only lacks a good QML support. Javascript, on the other hand, already has many great IDEs and competing with them may be a bit out of the scope of a GSoC project.

My strategy to have great QML support in KDevelop is to concentrate most of my efforts on this language, while still having a robust enough Javascript support so that Javascript snippets in QML files work as expected. For instance, Javascript built-in classes were added because many of them are used in QML files.

So, this week was dedicated to importing QML binary modules and QML installed modules. First, some definitions:

Supporting QML installed modules was quite easy: KDE's KStandardDirs allows me to easily locate them, and the infrastructure for importing whole directories was already in place.

Binary QML modules were a bit more difficult because they need to be dumped before the QML/JS plugin can use them. Dumping a binary module file is the action of running qmlplugindump on them, a tool provided by Qt that takes a .so file and writes a QML module file for it. The QML module file is a valid QML file and can be parsed by the plugin.

With directory imports working, binary QML modules dumped and the dumps correctly parsed, the all the pieces fit together:

A directory containing a .so file Uh oh! A .so file!

Enter qmlplugindump Enter qmlplugindump (the file is cached for later reuse)

Listing the components of a binary QML module Components exported by Plasma Core

Members of binary QML components Members of a binary QML component

Finally, as an added bonus, I've improved the code-completion for import statements. They now list only the imports that start with what the user has already typed, and they handle installed modules:

Nicer code-completion of import statements

Testing the QML/JS plugin on real QML files has shown that QML is very nicely handled, even if there are still some small glitches (for instance, several built-in QtQuick 1.0 types and properties are still missing). Sven Brauch will also send me a list of places where the code-completion could be more useful. In fact, don't hesitate to tell me which features you would like to see implemented, I've still four weeks ahead of me!

20 Jul 2014 1:32pm GMT

What’s new in KF5 porting script: convert-kdialog.pl

When we want to remove kdelibs4support there is a class which is used by all kde application: KDialog.

Each time that we wanted to create a dialog we used it.

So it's necessary to have a script to help us to port to QDialog now that KDialog is deprecated.

When we port to QDialog, we need to add a QDialogButtonBox and mainwidget (if necessary)

As in kdepim there is a lot of KDialog I created a script for it.

It was not very easy to create it, but this script help me to port some kdialog.

But unlike others scripts that we can launch them on source file and just compile and adapt if necessary, which this script we need to look at diff to be sure that all is ok.

But I hope that it will help us during kf5 porting.

I continue to fix this script and add new porting code when I found it in kdepim.

But you can send me mail when you see a bug.

20 Jul 2014 11:16am GMT

bringing green processes to Qt

I've begun prototyping a system for green processes in Qt applications. I'm not yet at the code-writing stage, but the API is definitely taking shape and a design is starting to emerge. It's a spare-time project for me, so is progressing at a reasonable but not extremely fast pace.

I've gotten to the point where early-stage feedback from people who are interested in such a framework would be very valuable in polishing the design a bit more before laying down code. As such, I'm looking for 4-6 people to collaborate with at this early stage.

If you are interested in using green processes in your Qt application, or are simply interested in new application development patterns for Qt, and you have 20-30 minutes per week to look at API drafts and provide feedback and and/or add to the ideas that are coming together, please email me (aseigo at kde.org).

20 Jul 2014 6:01am GMT

19 Jul 2014

feedPlanet KDE

Plasma Active on QT5/KF5

Hello, this is my fourth report for my GSoC. This week I have ported the Panel for Plasma Active. The UI of the Active Panel has not changed much. As you can notice some of the Plasmoids are missing because they have not been ported yet (like the Homescreen Plasmoid), but there is no missing functionality from the Panel. Also the notification icons are invisible while they are inactive, as this is the expected behavior.

active panel without notification

active panel notifications

You can find us on #plasma or irc.freenode.net


19 Jul 2014 3:52pm GMT

18 Jul 2014

feedPlanet KDE

SFLPhone-KDE 1.4.0 released!

Savoir-faire Linux is proud to announce the immediate availability of SFLPhone 1.4.0. This release finally enables video by default. We have refactored the video implementation to be much more robust against a variety of conditions and made the configuration more flexible. It is also now possible to stream a variety of file types and even share your screen. Other interesting features include support for the JACK audio system used by audio industry professionals and hobbyists. Thanks to improvements in audio buffering, latency and resampling, audio quality is noticeably better. The KDE client now has much better Akonadi support. It can now act as a KAddressBook replacement for most phone related scenarios. There will probably be one final KDE4 release before officially making the switch to KF5. The SFLPhone-KDE logic backend, libqtsflphone, has been compatible with Qt5 for over a year, some of the UI dialogs have yet to be ported. As for SFLPhone in general, we plan to merge work that has been done in parallel for a while now to make the daemon more modular, easier to build, more secure and more portable to other operating systems.

Please update or comment on this ticket to add user noticeable changes and new features

Common features

libqtsflphone

KDE client

2 3 1

Stats

KDE client: 203 files changed, 10979 insertions, 3933 deletions, 102 commits, 36 issues closed, 19 bugs closed
Daemon: 256 files changed, 14448 insertions, 9781 deletions, 628 commits, 543 issues closed, 214 bugs closed

Get SFLPhone-KDE

Kubuntu packages are available at: https://launchpad.net/~savoirfairelinux/+archive/ubuntu/ppa

The source get be obtained from git://anongit.kde.org/sflphone-kde or from http://sflphone.org .


18 Jul 2014 10:24pm GMT

After the Kickstarter...

Running a kickstarter is very much like, well, running! Running for thirty solid days. So the weekend after the Kickstarter ended, all of us slacked off a bit, and instead of coding we did some coding! Within a week or so, the Kickstarter should be finalized, the money in our bank account and we can start opening up the surveys for the backers! We didn't reach the stretch goal that would let Sven work full-time on Krita, so the feature survey will be "Choose and Rank 12 out of 24". Dmitry is already looking into 3D transformation stuff, so let's hope that feature won't get voted out! You could also still donate to Krita, either directly, or through the rewards-enabled paypal button:

Reward Selection

Yiynova Europe noticed the kickstarter and contacted us -- they loaned us two Yiynova tablet monitors, the 19" MSP19u and the the 21,5" MVP22u to test Krita with. We already had a bug report about multi-monitor setup with other tablets than a Cintiq, so this was very welcome! And today there's a new experimental build that works just fine!

This build also contains Dmitry's new memory pool code. Krita should now be a bit faster and use less memory while painting, and especially, be better behaved with longer painting sessions. Please do test! As developers, long painting sessions isn't something we can regularly indulge in!

As for OSX, I cleaned up a lot of warnings and (probably...) fixed the available memory detection, so Krita can use more than 1GB before it starts to swap. Also, all brush engines are now available! I'm still in two minds about the OSX port, though. I will need at least a month to make a nice beta, at least two months more to get it ready for end-users... This is all coding, and maybe build two, three more dependencies.

In other news, Scott Petrovic has been really busy working on a new look for krita.org. This week, together with KDE's wonderful sysadmin team, a development version of the site went life. Read all about it on the Krita forum! There's even a link there to the development version of the new website!

18 Jul 2014 1:04pm GMT