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

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.

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

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

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:

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

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

This week I created some other scripts:

• autogenerate_export_header.sh: When we remove kdelibs4support we want to remove kdemacros.h file too. But in each lib we export symbole which uses kdemacros.h for export macros. If you want to remove it, you must to use "generate_export_header" cmake macro. It will generate header directly. Very easy to use it: autogenerate_export_header.sh <foo>_export.h
• convert-kcolordialog.pl: This script ports KColorDialog::getColor to QColorDialog::getColor (not it's not just a one line script )
• convert-kmenu.pl: Now it supports replacing addTitle by addSection
• convert-kcmdlineargs.pl: When we convert kcmdlineargs we need to port K4AboutData and KApplication. This script help you to do it.

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 7:22pm GMT

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.

21 Jul 2014 10:38am GMT

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:

• xorg-server 1.15.2
  
• linux 3.15.5
  
• systemd 214
  
• mesa 10.2.4
  
• calligra 2.8.5
  
• qt 5.3.1
  
• nvidia 337.25
  
• catalyst 14.4
  
• xf86-video-ati 7.4.0
  
• digikam 4.1
  
• libmtp now includes Jolla phone/Sailfish OS support.
  
  Please note that the mesa package was splitted in the following packages: mesa-libgl, opencl-mesa, ati-dri, intel-dri, nouveau-dri, svga-dri. libgl is now provided by the corresponding mesa-libgl, nvidia-libgl or catalyst-libgl package. Pacman should be able to resolve dependencies correctly once you perform the update, so that the appropriate libgl package is installed. The nvidia-bumblebee package has been replaced completely by nvidia. The bumblebee package now provides the corresponding nvidia-libgl. So nvidia users with optimus technology should install mesa-libgl, nvidia and bumblebee to use their hybrid card.
  
  It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue - please ask or report it to the related forum thread.
  
  As always, make sure your mirror is fully synced before performing this update. To check, run mirror-check in Konsole, or use the Mirror-Check application found under the "Internet" category in the application launcher.
  
  

20 Jul 2014 9:28pm GMT

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

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:

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.

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:

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:

• QML installed module: QML module that is installed on the user's system, for instance by a KDE package. Unfortunately, QML does not have system-wide include paths as Python and Ruby do, each QML application provides its own search path. Luckily, most QML applications either use only Qt-provided modules (and they have been supported for a long time now), or use KDE-provided ones. KDE installs all its modules in /usr/lib(64)/kde4/imports, so they are quite easy to locate. An installed module consists of a directory that contains .qml files and possibly .so files. The library files (that can be mixed with plain .qml files) contain additional native components, implemented in C++.
• QML binary module: Library that contains QML components. The .so files I was talking about hereabove are QML binary modules.

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:

Uh oh! A .so file!

Enter qmlplugindump (the file is cached for later reuse)

Components exported by Plasma Core

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:

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

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

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

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.

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

19 Jul 2014 3:52pm GMT

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

• Jack support
• Video support by default
• Ability to share screen
• Ability to stream videos, images and text files
• Support GnuTLS as an alternative to OpenSSL
• Persistent camera configuration (per device)
• Switch video sources during a call
• Enable or disable video per account
• Packet loss concealment
• RTCP support
• Builds with clang

libqtsflphone

• Pluggable history storage
• Improved pluggable storage backends
• Datasource extensions support

KDE client

• Now a fully featured contact manager
  • Add, edit and manage contact sources
  • Delete contacts from the interface
  • Attach contact sources to auto completion or presence tracker
• Basic video effects like rotate or enforce aspect ratio
• Video full screen mode

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

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

Donate €5,00 EUR Postcard €15,00 EUR Postcard and stickers €25,00 EUR Digital Download of the Muses DVD €50,00 EUR USB Stick with Krita €100,00 EUR Comics with Krita DVD plus signed comic €150,00 EUR Dedicated Tutorial by Wolthera €250,00 EUR Pick your own priority €750,00 EUR A month of dedicated development €2.500,00 EUR

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!

• http://heap.kogmbh.net/downloads/krita_x64_2.8.79.13.msi

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.

• http://www.valdyas.org/~boud/krita-2.8.79.13.dmg

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