Verzeichnis
Planet KDEPlanet KDE - http://planetKDE.org/
Hello Planet KDE!!!
I have the pleasure to announce my new app PhotoBook! I’ve been waiting for quite some time to put the code on public and I just did this today. So what is PhotoBook?
PhotoBook is a photo management application. I know what you are just thinking! Don’t we have gwenview and digikam already?
So before everyone starts a flamewar let me explain why I did not put my ideas on those two apps (though after talking to Aurilen – gwenview he might end up using some of the ideas into gwenview).
Starting with gwenview we have an excellent Image Viewer (It’s the application description), an Image Viewer as the name says allows for viewing images, you may think “well a photo is an Image”, but not all images are photos, gwenview is an application oriented on your file system (if you enable nepomuk you can also tag all your images), you can just browse your files and view any kind of image it supports, it even has slide shows and can play clips. You don’t organize by events for example your Krita drawings…
On the other hand we have digikam a professional application with tons of filters, geolocation, tags, lighttable, colorcorrection and the list goes on. Due to this it’s more oriented for a photographer.
Both applications integrate KIPI plugins so you can even export your images/photos to several webservices.
What I noticed is that we have a gap here, well I’d like an application to manage my photos with some of the features that digikam has, but it must be a simpler application since I want my with using it. Her files are just a mess, photos all around the hard drive if it’s not me to organize it sometimes it would be a huge mess, being honest I even prefer not touching it, apart from that, every time she’s going to upload her photos she opens KolourPaint and resize image by image so the upload is faster, I tryied several times teaching how to do that with KIPI but she always forget it.
At the beginning of this year my boss showed me iPhoto, wow, that had everything I was looking for, a pretty smart importer, photos organized by events, tags, faces, places and facebook integration, not to mention that it organizes all the photos you import so you don’t have to pass through the PAIN of manually create a directory structure…
After that day I searched for a Linux app that did that, the closest was ShotWell a Gnome app, I’d use if it wasn’t by the fact that it doesn’t has an smart importer, and well I’m not a Gtk fan so I decided to do a Qt application that could fill my needs.
QML is everywhere on the news, it’s the Qt hype, I had never tried it (it was before the printer-manager QML plasmoid), playing with some Qt demos I said to myself this will look awesome with QML, drawing the solution and playing with it at first was a frustrating experience, without Desktop components it’s a major pain as I’m not very skilled with inkscape and I don’t like to waste time learning a tool just for one or two icons… so I gave up a few months ago.
Time passed and I got robbed, the window of my car got crashed, my company’s laptop stolen and so was my wife’s camera, 8 GB + what was on the laptop of photos lost, the laptop could have a backup (my fault), but the 8 GB was actually the fault of not having a tool to smart handle the import. At the same time Marco Martin (notmart), posted his improvements on a QML File Browser for Active that had a feature I couldn’t reproduce in QML.
This motivated me to get back to my old code, now I had more experience with QML, but still the pain of creating everything was there, but now I don’t really care, Qt 5.(something) will have it… then I just replace 
the core of the app is just pure Qt, even the code that provides the images, the thumbnails are all C++ code.
I have a bunch of stuff to say about what this app already does, and what it will do, but this post got too huge already… If I were you I’d be sleeping by now… 
So say Hello World!
Importer for removable media
You can find the code in https://projects.kde.org/projects/playground/graphics/photobook
As I’m no CMake expert after you compile the code you will need to create a link called qml_files that points to the qml files, and run photobook from the directory containing this link. If you know how to improve this please give me a hand.
The ui is still a bit of a mess, and PLEASE this is alpha software, the indexer might change, the directory layout might change, right now is just a tech preview…
I’ll soon make more posts about how the importer works and what you can do with it
Enjoy
Hi, I'm Matěj Laitl and this summer I've been accepted to GSoC for Amarok to work on statistics synchronization between various collections and scrobbling services such as Last.fm. Here comes my first weekly report, enjoy reading it. :-) In short, I've worked on a background worker that will associate same tracks from various sources with each other.
 |
| Obligatory screenshot. Current visible effects of activating that action are none. :-) |
- Designed core (abstract) classes that will facilitate statistics synchronization for both collection and online service tracks: TrackDelegate and TrackDelegateProvider.
- Implemented these interfaces for tracks from Amarok collections (e.g. Local Collection, iPod and USB Mass storage ones...).
- Implemented controller, singleton class that is entry point to synchronization functionality in Amarok.
- Implemented MatchTracksJob, a job that runs in background and matches tracks from multiple providers into track tuples with same meta-data.
- Encapsulating asynchronous API of some Amarok classes (QueryMaker) to be synchronous and thread-aware was a bit tricky.
- I had hard time implementing lessThan() comparison function that needs third argument for Qt's qSort(). Function template did the job, but that made MatchTracksJob non-reentrant. :-(
- It isn't clear what meta-data should participate in track matching. Some sources provide few of them (Last.fm provides just artist, album, title; sometimes less) while Local Collection and friends can provide much more. I've made MatchTrackJob generic with regards to matched fields with artist, album, title being mandatory and composer, year, track & disc number being optional.
- We've ongoing discussion with Bart Cerneels whether TrackDelegate is redundant or not. I've made sure to code in a way that it can be replaced in future without hassle.
- The GUI to show matched tracks, providers etc.
The Kubuntu Council is a group of 6 Kubuntu Members who get to vote on membership of Kubuntu Members and occasionally other decisions regarding Kubuntu.
Half the council is nearing the end of their 2 year appointment so we need to hold elections for the open positions to the council. This could be you! If you are a Kubuntu Member and are willing to turn up to Kubuntu meetings as much as possible for the next couple of years do consider putting your name forward.
Now that Marble’s OSM file parser is ready to understand the whole OSM Schema, I started messing around with the feature and geometries layout. This took me to a point where some important decisions have to be taken.
Currently the feature’s tags are stored and then some tag combinations (the most representative ones) are searched for translating them to the best fitting color and rendering style:
["landuse=landfill"] = createWayStyle( Qt::transparent, Qt::transparent, false, false );
["railway=rail"] = createStyle( 2, 5, “#989898″, “#E1E1E1″, true, true, Qt::SolidPattern, Qt::DashLine, Qt::FlatCap, true );
…
This has to be hardcoded and its not very flexible with strange tag combination that might be needed in some cases. I asked Earthwings and Tackat which color style Marble was following for rendering OpenStreetMap vector data and they told me it was Mapnik’s color style. Mapnik is an open source toolkit for rendering maps and OSM uses it for the standard layer you can find in their maps. It is possible to download Mapniks stylesheet (which is an XML file with the rendering rules) and modify it to render the way or the data you want.
So one of my questions is how would it be to directly parse this stylesheet for rendering the data just the same as in Mapnik and, even more, for people to be able to create their own styles in the future? In fact that’s what other layers do for highlighting features they want.
This question also takes me to the another one. As you might have noticed, mapnik stylesheets also define the zoom levels where features should be painted. Currently vector data is rendered no matter what zoom level the world is. For my GSoC I am going to create a tilling schema with a strategy for only downloading the necessary data for each zoom level so:
Should only the download process ask for some predefined data types depending on the zoom level and then Marble just render all the downloaded data following the stylesheet?
or
First parse the XML stylesheet to store all its values in memory and make users able to decide features’ zoom levels for when the download process asks for data?
It’s been a long way, it’s made us struggle with ugliness at some point, but now we have Pairs in place to be released with the next KDE 4.9 Beta.
Also it will come with a great new UI drawn by Abhash Bikram Thapa featuring some lovely colorful people, yay! 
If anybody is interested in the project, please get in touch with us or with the kde-edu mailing list! There’s plenty to be done: new games (sets of images and concepts), the game editor, improving the adaption in touch systems, and anything you’d like.
Thanks to everyone who has been involved in the making, especially Marco Calignano for helping and pushing me to do the work when needed, and Anne Marie for caring about the project. ^^
Hello again!
I've been fooling around with my granular particles repository these past days before do a real coding into Krita. I'm trying to optimize my simulation through a series of modifications in the code I wrote last week.
My first attempt to run this granular particles simulation was quite a big failure, since it was really slow and full of errors. I correct some small things this past weekend and during this week I implemented a neighborhood restriction to the collision detection between particles.
One of the reasons the code had a slow response was the fact that each particle was doing a collision detection with every other particle in the simulation. I initialized with 2010 particles, so we had a lot time wasted just doing useless calculations, since we only had to worry about each particle vicinity. So this time I implemented a grid so we could restrict the computation of collision only for neighbors particles. I have yet some other two improvements to test before generate some QImages: try the RK4 integrator instead of the Gear's predictor and corrector, and a more vectorizable grid construction which will be more easily implemented in a GPU.
I'm already writting a more detailed post with all the theory used behind the scenes. But if you already took a look at the code before, this update will be easy to understand. Again, the code is well commented and any questions you can contact me here in the comments or sending me a message to my Gitorious account.
See you all soon! :)
In the recent time I have observed more and more “attacks” on Apache OpenOffice by people that think the developer team and users to should stop “wasting their time” working on it and rather work on LibreOffice. For example in this recent acticle on Unixmen.
That’s not very surprising as that basically the same thing that I hear as KOffice/Calligra developer for the past years. There are continually coming people who ask why I would still work on it and waste time that could better be spend on contributing to OpenOffice. Well there are numerous reasons why I do that e.g. I like to work with the team, I like to work on Krita and time isn’t wasted if you had fun spending it. People think that the is only one way to create an office suite and that everyone should follow it and work on the same project.
So this are the reasons for me as developer. Would it be better for everyone if we all worked on the same project? I don’t think so
Diversity
There is a common thinking that you could just throw together some developers from different groups and they would like to work into one unique direction. If you e.g. take the GNOME and KDE communities and assume you wanted to merge them, it would simply not work as the visions of the desktops are different. In the same way many LibreOffice/OpenOffice users probably wouldn’t like my changes.
I think one of the nicest thing in that people can fork and try new ideas. Some will continue to evolve, some will be merged back and some will die. The same will happen with Apache Office and LibreOffice. Over time each team will put work into different areas, which causes the projects to slowly diverge. Eventually some users will prefer the one and others will prefer the other suite.
One thing I think the Unixmen article confuses is customizability and diversity. Customizability is actually quite limited e.g. no matter how much you customize KDE, it won’t become GNOME and vice versa.
Competition
I guess there has been so little competition between different office suite that people might think that a monopoly is inevitable. Currently everyone is following the approach to put everything into one gigantic suite and approximate in a one size fits all fashion what the users might need. The whole design hasn’t even changed much since the 80s. I think once office suites will get more diverse, we could see that users are going for more specialized suites that fit there needs better.
Best example are web browsers. Just a few years ago we basically had IE that did 95+% of all web surfing. There wasn’t much change in the whole thing before a number of open source browsers emerged. Now we have also Firefox, Chrome etc. and browsers are released every few weeks. One can only imagine how the landscape would look today, if the KHTML developers had joined the Mozilla team and WebKit had never existed.
Interoperability
Remember a few years back there was a label on many website “Best viewed with XY”? Once the browsers got more diverse, that disappeared more and more and the browsers themselves become more and more standard compliant.
Office suite basically have the similar problem, just much worse. A long time every big suite could do what they wanted, without having to watch other. We have come to a point were everything is judged on the basis of some crude ancient binary formats and the compatibility to them. The most important thing is to make sure that history doesn’t repeat itself and I think the best way to do that is to have different suites that implement the standard.
Conclusion
Of course I can’t predict the future and say how it will all unravel, but I think Apache OpenOffice could be a nice addition for the open source world.
Even more important in my opinion is that people stop to attack the other teams. Respect the work of other people and don’t accuse them of working for the wrong project, doing pointless work or stealing developers.
We are pleased to announce the new open-slx Weekly News 19 in the Formats PDF and EPUB.
You can find in this week (abstract):
- Updates from the Newsteam
- Maliit & Plasma Active
- New Font-Repository available
- Linux Colormanagement Hackfest
- and more...
The open-slx Weekly News 18 are downloadable there [275,50 kB] (PDF) and there [19,10 kB] (EPUB).
Because Textwriters are needing Coffe just donate anything.
Original Post: http://community.open-slx.com/news-46-open-slx-weekly-news-19-published.html
Technorati Tags:Technology, News, Mobile App, Tablet, Tablets
Download: PDF-Format [275,50 kB] EPUB-Format [19,10 kB]
Dieser Wochenrückblick wurde unter der Creative Commons by Share Alike veröffentlicht.
Hot on the heals of the awesome PulseAudio 2.0 release, I am very please to announce Mageia 2! It's been a lot of very hard work and I inadvertently ended up doing a lot more than I had originally intended but I can't complain - while it was a lot of hard work and a massive time sink for the last few months, I certainly learned a great deal and feel I've contributed to a great user experience.So what makes Mageia magic? Well I like to think it's because we've got a great bunch of people involved - not only that, we have clear guidelines about how the whole project can never be owned by a corporate interest - it's a true community distro. If this is important to you, (and it should be!) then I encourage you to get involved and help us make it even more magic.
Not only that, but while we're a young distro we come with a rich history: Mandriva. While the corporate side of Mandriva is still somewhat struggling, the breadth of experience our contributors have is much greater than our age would normally indicate.
In terms of technology, I like to think we're a very forward facing distro. We're keen to adopt and contribute to the new "plumbing" layers being developed. Like pretty much every other distro out there, we've seen the value in this standardisation process and wholeheartedly adopted the new pid 1, systemd. Unlike some others, we've clearly stated that while Mageia 2 supports both systemd and sysvinit, Mageia 3 will focus solely on systemd. We do not see value in providing a half-hearted version of three different init systems and would much rather go "all in" and provide an excellent experience with the one that looks the strongest and offers the most compelling technical advantages. This will see us providing tools to help users administer their systems better and help with bug reports and fixes upstream too.
We also strongly support our packagers and developers contributing directly upstream. Just recently the xsettings-kde project was removed from Mageia subversion and migrated into KDE git upstream such that other distros can contribute more easily.
So for these reasons and many, many more, I feel we can continue to make the magic happen!
In terms of this release specifically, there are so many people to thank. In no particular order: Anne Nicolas, Thomas Backlund, Thierry Vignaud, Dexter Morgan, Pascal Terjan, Olivier Blin and many others on the development side, the many awesome folks in the QA team, those pesky bug reporters (some who were absolutely amazing and very understanding) and those who helped get the Artwork and Marketing side of things looking nice and slick. I'm sorry if I didn't mention you by name above, but there really are many, many lovely people involved and to thank everyone individually would just take too long! Rest assured, you are all awesome! Also thanks have to also go to the good folks involved in upstream projects. For me personally that's particularly Lennart Poettering, Kay Sievers, Michal Schmidt and Tom Gundersen (and others) from systemd and Harald Hoyer from dracut (most of whole are Redhat employees with the exception of Tom who is an Arch contributor); Arun Raghavan, Tanu Kaskinen and David Henningsson from PulseAudio; to the KDE and GNOME projects and their many, many contributors and to everyone else supporting the use of Free software - don't be owned - own it!!!
This post is part of an ongoing series about developments and discussions in Qt.
Some parts of this report are still under discussion, and don’t necessarily reflect the final state of Qt 5. The target audience is people involved in Qt development itself, but without the time to follow everything that happens, and others with a strong interest in Qt, Qt 5, and the community.
This week we cover the move of QIcon and consequences that can have, continued work on Qt using UTF-8 by default, more discussions about QPA, and touch events.
QIcon returned to QtGui
With the splitting of the Widgets related classes from QtGui in Qt 5, QIcon had ended up in the widgets module. When a commit arrived which added a new class for multiple-size icons, the rationale was discussed, and the class has now been returned to QtGui. This could conceivably have favorable consequences for using icons in QML 2 code in the future, and possibly a QPA API for loading icons from standard platform-defined themes.
Cross compiling for Windows patches landed
The patches mentioned previously and discussed on the mailing list have started to land in the Qt base repository. Cross compiling on Linux for Windows targets is not part of the Qt CI system, so it is possible for it to break at intermediate times, but in general this will surely be a welcome build configuration for Qt 5.
Continued efforts on UTF-8 expectations
As noted before, Qt 5 now expects files to be UTF-8 encoded. This has consequences for static strings (char arrays defined in C++ source files), but it is only a side-effect of decoding byte data as UTF-8 by default in several parts of Qt where latin-1 was the baseline before (or where it was configurable before). Other side effects have required changes to the translation functions (which now also expect UTF-8), and in changes to QFile::encodeName.
New Visual Studio mkspec added
A mkspec was added for Visual Studio 11. The mkspec files are build description files used to build Qt itself and for 3rd parties to build software using Qt libraries, so this enables the use of Visual Studio 11 with Qt projects.
Tests and bug fixes in QtNetwork and in the QJsonDocument APIs.
Emitting signals without creating a QMetaObject
New optimizations in QObject and QMetaObject related code allows QML to emit signals lazily without creating a QMetaObject. This could lead to some encapsulated optimizations within the QML system, and also appeals to the kinds of people who are interested in the Qt meta object system in general 
.
QPA menu abstraction
The number of interfaces provided as part of QPA has grown once again to now include an abstraction for menus. The new abstraction provides virtual interfaces for menubars, menus, and items in menus. An accompanying commit implements the interface on OSX.
Efforts into touch events in Qt 5
The topic of touch and multi-touch is an important one for all modern user interface frameworks, and it has been getting some serious effort for some time. The topic has re-appeared with regard to making it work better from the start with Qt 5, so this is of course a positive development.
Another small post about new developments in Plasma Active ;)
An important use case for tablet is of course Ebook reading (being them pdf, epub or whatever).
KDE offers a very complete document reading application, that supports a wide variety of formats: Okular. It is of course an application optimized for desktop usage and does a very good job at that, but what is less known is that Okular has a very good separation between the logic of document parsing and rendering, managing bookmarks, annotation etc and the ui itself.
It has been revealed very easy to do a set of QML bindings that let opening all the supported documents by the desktop version of Okular and render them on a component directly usable by QML, alongside a very simple touch friendly application.
This application represents the document as a stack of sheets, in which is possible to flick them around, pich zoom and switching pages with a swipe gesture. A side panel that can be dragged in (common UI pattern in Plasma Active) contains an overview of all the pages as a thumbnail grid.
It's just the beginning as both the app and the reusable QML components still don't have support or UI for more complex things like custom bookmarks and annotations, that will eventually come in future versions.
Note: This is a follow up to my earlier blog entries "founding philosophers" and "the age of pragmatists". If you have not read that one yet, please do so before continuing here.
The most powerful things in the world can not be controlled. At best they can be influenced.
This can be written another, less catchy, way: a) there is a limit to the number of things that can be effectively managed simultaneously by a unit of management effort; b) management is a finite resource that demonstrates diminishing returns when scaled up in a purely vertical fashion; c) and there is a relationship between the power of a system and the size of the system. In that interplay there exists a threshold where the system loses the attribute of "controllable" as it increases in influence, and vice versa. This can be seen by analogy in natural systems like hurricanes and more literally in the complex interplay within biological ecosystems. It's simply an attribute of large dynamic systems.
Social movements attempt to shift the expectations and behaviors of people in large human systems, and they face the control/power challenge quite directly: they can't be tightly controlled if they are powerful, at best they can be influenced.
Through processes of social evolution, humans stumble upon culture and custom as a pretty decent way to manage this issue. Shared values, common expectations and communal goals allow individual actors within a large society to move in a generally coordinated fashion without requiring each to be directly managed.
Culture becomes a way to define, refine, transmit, reinforce and reassure each other of the precepts of the system. Art and ritual, governance and tradition .. they allow us to influence ourselves at uncontrollable scales. This allows hugely influential social structures to emerge that also have some measure of stability to them. On the down side, it's a slow process that is not overly efficient and can seem to work against pragmatic goals at times.
What does this have to do with Free software? It started with people defining common expectations and communal goals. To take one example: the GPL is a formulation of this in the form of a legal text. Participants communicated these social artifacts to each other, and this gave rise to a large, successful, somewhat uncontrollable movement that showed itself to have great effectivity and strength. Some pragmatic membership of some Free software communities, looking more at the costs of such an approach than the benefits, have over time steered towards mechanisms that are ultimately more manageable and controllable but far less powerful.
A common pragmatic approach is one that focuses on balance sheets alone. I was told by one well-known Free software company founder and self-appointed community leader that they invested significant amounts of money in a particular Free software project per year and then asked rhetorically "What do we have to show for it?" They were referring to a combination of community control and corporate profitability, two things they were still searching for. What they had actually gotten from it was more and better Free software and membership in the society that creates it, but that escaped them.
This kind of thinking is the result of optimizations done for the perceived benefits of the individual actors. The culture, is not being measured as part of the success or failure, and so suffers as a result. As this is a prime mechanism of ensuring stability and forward movement of large systems, this is concerning. It is also self-defeating, as without stability it is hard to build successful structures.
An interesting manifestation of this approach has been the rise of a new job position: the community manager. Managing a community is a polite way to say "We're trying to exert influence over this system of people and bring some control to it." The community manager positions currently around Free software are not community developers, community coordinators or even community "engineers" (whatever that might mean) .. they are "managers", and they are beholden not to the community but to the employer.
As such, it is not uncommon to witness a community manager repeat dubious ideas that are slanted towards and which attempt to justify their employer's interests; to see divisions created as much as unity; for the installment of systems based on loyalty-based conviction (fanaticism) that encourage highly partisanship approaches.
This is not an indictment of the individuals who hold these positions. Community managers are not somehow "bad people". I know a number of of them personally and will attest that their hearts and minds are in the "right" place. It's a systems issue: no matter who was placed in that position the result would be the same. The measurements and incentives that come with these positions create the often unfortunate results we see, all in the name of hoping to construct and manage a group of people in support of the company's interests. And everyone's heart is in the right place the whole time.
The pragmatic nature that has overtaken Free software has increasingly left behind the idea of influence by idea and replaced it with the management of economics (monetary and otherwise). If the goal is to create a new economic model for technology, we've become focused on the right things. However, if it is to create a new model for technology in society, to ensure that technology aids humanity rather than erodes it, it probably isn't, because that requires systems so powerful they can only be influence and not controlled.
Building community on ideas that tie individual actors together, and letting those communities of individual actors interact freely, guided and driven by those ideas is critical. Free software needs to find a way back to the "age of philosophers" in some fashion without losing the power of the pragmatists. We need both, with each influencing from its strengths.
I believe it is unrealistic to ask others to do that which we are not willing to do ourselves. It can also be helpful to adjust the rules of the game slightly so that the desired behavior is rewarded more strongly. Which brings me to the useful conclusion of this blog entry series.
I've written about a bunch of history and a little philosophy in these three related blog entries, the next one will wrap it all up and be about the pragmatic results that this train of thinking has led to. In particular, I will introduce two key components of Make·Play·Live that were directly influenced by this train of thought: the add-ons content system and the partner network that was recently announced.
Blog Tags:
Skrooge crashes on start with SQLite 3.7.12. The bug report is here.
Users
Your data is safe. It is not corrupted, and will be accessible again as soon as the bug is fixed. As a workaround, you can revert to SQLite 3.7.11
Developpers
I can't get in touch with Stéphane at the moment, and I don't have the skills to understand what causes the crash. Any help would be greatly appreciated ! You can read the backtrace here. I've contacted the SQLite team, of course, but didn't get an answer so far.
Edit :
The SQLite devs have looked into it and a ticket is opened in their system too
Edit 2:
The super excellent SQLite team did an amazing fast job : issue is fixed, and the fix is already available in a stable 3.7.12.1 release. Massive props to them !!!
So while quite some KDE modules have pioneered the move/migration from subversion to git as SCM, others modules have been resisting that move, for various reasons. Just, seeing the pioneers to settle successfully and to have a better life, the home-stayers get jealous and start to plan to follow in the land of better living. After all, the road and the traps to avoid are known now.
And so does now the KDESDK module. There is a page on the Community wiki as central place to coordinate things for the migration, go there if you are interested to see what is happening and how.
All known maintainers of things in KDESDK have been tried to reach. If you feel responsible for something in the module and were left out, please act now and join the new mailinglist for kdesdk. Anyone else interested is of course also invited to join 
The unmaintained things in KDESDK have been removed already (kspy, GUI for kunittest, scheck), no need to migrate that (for now, can be done later if picked up).
Comments on this post are disabled. If you want to comment, please simply subscribe to the mailinglist for kdesdk and join the discussion there, so it’s in one place!
After Martin Gräßlin’s excellent blog series for developers there is little I can add but agree on all points. I am currently adding versions to the existing open Plasma bug reports and that made me think of something:
When did YOU last test your own bug reports?
We have all submitted bug reports at some point, be this as a user, a beta tester or a developer. But when did we last follow-up on our own reports?
BKO makes it easy to follow up on my own reports as there is by default at least one saved search visible in the footer when I am logged in: “My Bugs”. Just a click on the link will show me a list of all bugs I ever reported that are still open.
As a user I try to do this on a regular basis, depending on the products I submitted the reports to, but at least on every version change. Since I am the one who reported it who else than me is the best person to actually test if the bug is still valid?
As a beta tester I of course test again when final is released.
As a developer I would probably test when I find time to, but at least on every major version change. So since 4.9 is around the corner this is a good occasion to put this on your ToDo list for the beta testing period 
Oh, and I almost forgot:
Technorati: that one is for you: DJRCBBT3H7RC
Today the ownCloud community released ownCloud 4. This is an important milestone for us as a community, for the product and for our code base.
So what are the new features?
- File Encryption
- File Versioning
- Mounting of external Filesystems (experimental)
- TODOs App
- Drag & Drop File Uploading
- Shared Calendars
- Calendar categories
- Hugely improved contacts app including groups
- Improved WebDAV, CalDAV, CardDAV compatibility
- Movable Apps
- Improved External App
- Improved Sharing of Files
- Overall Performance Improvements
- System/User Exporting/Importing
- User/Groups support via LDAP/AD
- Viewer for ODF Files
- Improved Photo Gallery
- Improved installation of 3rd Party Apps
- Logging via syslog
- New public API for App developers
- Lots of bug fixes, smaller enhancements and UX improvements.
Please check our nice feature page for more information.
This comes now only 4 month after the ownCloud 3 release early this year. We will switch back to a 3 month release cylce so you can expect ownCloud 5 at the end of August.
Even stronger KDE integration will be one of the focus areas of the next release. Currently we have the Desktop Sync Client, the Rekonq bookmark syncing, the OCS key value storage for all applications, desktop push notifications and more. Part of the next release will be deeper Dolphin integration, Akregator RSS feed syncing and KWallet integration for the Desktop Syncing Client. Looking forward to this cool Desktop/Cloud features.
Thanks to everybody who contributed and made this awesome release possible.
The core team, all the contributors, marketing people, designers, UX experts and of course all the testers and translators.
See the offical release announcement here and more information including the download on the homepage.
There are already packages for most distributions available on the Open Build Service.
I hope to see you all at our LinuxTag booth for hugs and chatting.
Frank
Going through Marble source code for parsing .osm files I suddenly realized it was not parsing Relations. As the OSM Wiki explains, these elements are used to group different geometries that have tags in common or to build complex polygons.
In fact, nowadays there’s a wide discussion whether relations should be used to reuse as much ways (OSM’s data primitive for representing lines) as possible when building geometries. Some people think it is better for search engines to have each geometry described as a way even if it creates overlapping linestrings when having one building next to the other.
Some other people think it is better to reuse the ways by creating relations that group the ways needed to create the buildings geometry.
Following this technique we have the city of Girona in Spain which currently Marble’s .osm parser renders like this.
In this first days I’ve been working on parsing relations to be able to render them as vectors. This requires to join the relations ways that build the geometry in the correct order, to distinguish whether it is an outer or an inner geometry and to read their tags in order to render the information. There are few little details that still need to be worked out but here you can see the result.
Relations can also be used for grouping long ways such as highways or railways. By doing this, renderers, gps devices, etc. know that the whole geometry is obtained by joining small ways inside the relation. So if we download an area where one of these highways is located, it’s not neccesary to download the whole highway, we would just need to download the ways that are in our area.
It’s release day today: This morning, ownCloud 4 was released! With a very cool set of features it’s even more useful and again more fun to use.
Along with that I am happy to let you know that we also released the ownCloud Desktop Client in version 1.0.2.
It is a maintenance release with a couple of important bugfixes, such as the cross platform filename encoding problem I was already talking about. Apart from that big blocker a couple of smaller, but annoying problems were fixed. Also the GUI was polished, text changes here and there and a new icon set that looks more cool and more like ownCloud.
Version 1.0.2 is also the version that is released on all big desktop platforms the first time. Now we also offer a dmg for MacOSX as well as a Windows Installer and packages for the major Linux distributions. Have fun!
If you want to talk about ownCloud, file synchronization or such, we have a booth on Linuxtag in Berlin and I will be there. I am looking forward to meeting you.
Apper has finally a new version!!
Last release is from February, not much changed in PackageKit since that time this is why you haven’t seen a new release, but this release doesn’t include last PackageKit feature (repair system). The focus I’ve put on this was fixing most of the important bugs we had in Apper, so it should be a rock solid release, it is surely not bug free as there is one bug that I won’t fix (I can’t reproduce nor have an idea how to fix, and the QML port will kill it).
The next release will include repair system, showing which packages are untrusted before installing them, and maybe some initial QML usage. Yes, I’m very excited with QML, it allows for a really cool flow especially for this kind of app, though we don’t have Desktop components yet, we can already do lots of cool stuff with it, but first I want to see Matthias work on Appstream and Software Center with openSUSE, that way we can have application data to browse without worry about the distribution!
What this new version includes:
- Automatic Refresh Cache properly fixed
- Initial Listaller support (optional)
- Supported filter added (depends on the backend)
- KDED plugin runs on a separate thread to avoid
desktop freezes - Fixed updating packages that were on untrusted repos
- Some man pages (thanks to ximion)
- Many other bug and Krazy fixes
Enjoy
Every now and then I’m visting my best friend’s mom (generation > 50a) to update her old Pentium 4 system with the last opensuse software. Each time, I have to restore her Desktop to provide the basic features like managing opened windows, add the clock again, etc. Each time, I pay carefully attention to lock the screen afterwards. Sometimes I get doubts, that they are just fooling me, but my friend declined this, of course.
This time they disarranged the screen in a very extreme way1. Take it for amusement or for considering a clearer warning of unlocking the screen. I vote for:
You might end with a coruppted system!
Please copy this into the form field below:
I asked my son’s friend and got his permission.
;)
-
Did you recognize these empty plasma panels on each edge of the screen which prevents all application to get maximized properly?↩
Until now Plasma active had an on screen keyboard that served us well, but due to its implementation had some limits that couldn't be easily overcome.
However there is a Qt based virtual keyboard project that is very promising: Maliit
It's the one that was used in the Nokia N9, and already made a good progress since the version used there.
To have a good user experience on Plasma Active it should be well integrated, both as in look and behavior with the rest of the environment. Luckily Maliit is transitioning itself as well to the use of QML to write the user interface, making very easy to switch to a platform specific UI while all the logic stays untouched (I must say I'm quite impressed by this input method framework).
This is the result of just some hours of work towards a keyboard interface that uses Plasma UI components, and hopefully it will be in the next Plasma Active release.
Speaking for myself and not for RIM
With RIM's serious push for Qt as part of the core frameworks and a more Open Source push for its ecosystem, it's the right time for me to jump in.
I Just started my initial porting of the Weather Forecast engine and applet to BlackBerry 10. It won't be Plasma based but pure Qt and Cascades UI with the kinds of effects that I really want to use.
I have to say it's pretty easy to get going. You go here: BlackBerry 10 Development
Download the Simulator VM image for the BB10DevAlpha device, get VMPlayer and the BlackBerry NDK+IDE. Qt and Cascades builds are already in the VM image.
Although we're using VMPlayer, It's ok but mouse cursor is sluggish for some reason. I'd rather we had used VirtualBox.
The only real irritant which I hope is fixed is the IDE Cascades QML previewer. It requires legacy Mesa, jpg/png libraries not found in Fedora (I use rawhide but Fedora isn't supported only Ubuntu) any more but I can workaround this issue in other ways (maybe Qt Creator for QML previewing).
Since QNX/BlackBerry 10 are POSIX, porting my code won't be much an issue. At most, I have to just re-implement some methods similar to what Plasma has in pure Qt but that won't be difficult.
I already have the plugin mechanism working. The fun part will be the Cascades UI framework to look at. It is similar to QtUi but different enough for mobile use, takes the pain of layouts out, extends QML usage and adds a rich set of functionalities that are common across the platform which I plan to take advantage of when those APIs are ready.
The embrace of Qt with QNX/BlackBerry 10 should be applauded and I hope more KDE and Qt developers look at the platform.
Porting parts of KDE to BB10 is possible but I don't know the logistics or restrictions that would be placed on it since we want a secure platform for people to trust. But I would certainly like to see KDE apps running on BB10!
Check out the Freenode IRC Channel #qt-qnx too.
CMake is a buildsystem generator developed in the open, and widely used for Qt based development. Especially when creating large or complex software, CMake can be more suitable to use than QMake. KDE was even the tipping point for the popularity of CMake in general, and with Qt 4 in particular, according to Bill Hoffman. KDAB engineers have contributed some features to CMake to ensure that the Qt 5 support for CMake is as good as possible.
KDAB contributed some new CMake Config files for Qt 5 to ensure that the integration between Qt and CMake can be even better. The updated documentation for using CMake with Qt 5 is has been reviewed and generated and repeats the relevant information in this blog post.
Finding Qt 5
One of the major changes when using CMake with Qt is the result of increased modularity in Qt itself. Whereas when finding Qt 4, with CMake you use
find_package(Qt4 COMPONENTS QTCORE QTGUI)
To find Qt 5 you can find all of the modules you wish to use with separate commands:
find_package(Qt5Widgets) find_package(Qt5Declarative)
There is likely to be a way in the future to specify the specific modules in one command, but this will not be available with Qt 5.0:
find_package(Qt5 COMPONENTS Widgets Declarative)
Building Qt 5 projects with CMake
Once the package has been found, Qt 4 users would use the CMake variables ${QT_INCLUDES} to set the include directories while compiling, and ${QT_LIBRARIES} or ${QT_GUI_LIBRARIES} while linking. Users of CMake with Qt 4 may have also used the ${QT_USE_FILE} to semi-automatically include the required include directories and required defines.
With the modular Qt 5 system, the variables will instead be ${Qt5Widgets_INCLUDE_DIRS}, ${Qt5Widgets_LIBRARIES}, ${Qt5Declarative_INCLUDE_DIRS}, ${Qt5Declarative_LIBRARIES} etc for each module used.
This is a source-incompatibility in your CMake based buildsystem which will affect porting from Qt 4 to Qt 5. Luckily though, it is easy to add source compatibility back to the CMake variables and macros using some simple variable mappings.
Building executables with Qt 5 is slightly more complex than with Qt 4. One of the changes to how Qt 5 is built and packaged compared to Qt 4 is that the -reduce-relocations configure option became the default. The effect of this is that compilations are run with the -Bsymbolic-functions option, which makes function pointer comparison ineffective, unless the -fPIE flag is also supplied when building executables, or -fPIC when building libraries for position independent code.
If Qt is configured manually, it is of course possible to configure with -no-reduce-relocations and avoid the issue, but the default will be a requirement for all third parties to add compiler flags for position independent code. This can be done in the normal way with CMake:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}
${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}")
There is a Qt5<module>_EXECUTABLE_COMPILE_FLAGS variable for each module available in Qt 5 which expands to either -fPIE or the empty string, depending on how Qt was configured. Hoewever, the -fPIE flag is really only for executables and should not be used for libraries.
Setting -fPIC globally even when building executables may also work sufficiently, but shouldn’t be the first option.
set(CMAKE_CXX_FLAGS "-fPIC")
Together with some other newer features in CMake, such as automated moc invokation, a simple CMake based build system using Qt 5 which is roughly equivalent to a Qt 4 buildsystem will look something like this:
cmake_minimum_required(2.8.7)
project(hello-world)
# Tell CMake to run moc when necessary:
set(CMAKE_AUTOMOC ON)
# As moc files are generated in the binary dir, tell CMake
# to always look for includes there:
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Widgets finds its own dependencies (QtGui and QtCore).
find_package(Qt5Widgets REQUIRED)
# The Qt5Widgets_INCLUDES also includes the include directories for
# dependencies QtCore and QtGui
include_directories(${Qt5Widgets_INCLUDES})
# We need add -DQT_WIDGETS_LIB when using QtWidgets in Qt 5.
add_definitions(${Qt5Widgets_DEFINITIONS})
# Executables fail to build with Qt 5 in the default configuration
# without -fPIE. We add that here.
set(CMAKE_CXX_FLAGS "${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}")
add_executable(hello_world main.cpp mainwindow.cpp)
# The Qt5Widgets_LIBRARIES variable also includes QtGui and QtCore
target_link_libraries(hello_world ${Qt5Widgets_LIBRARIES})
You can see though that there is a lot of repetition in the snippet, and a lot of things to take care of using.
The Qt5Widgets_EXECUTABLE_COMPILE_FLAGS use is particularly forgettable, and even difficult to get right – it should not be used if building shared libraries for example, so it requires some maintenance if that is required within the same scope as building an executable.
There is even a subtle bug which people who have unit tested their Qt 4 core-only code will know. If the -DQT_GUI_LIB definition is set (which happens if using QT_USE_FILE for example), all unit tests need to link to QtGui, even though it is not used by the tests.
That is because of some magic in the header files of QtTest. The workaround is either careful scoping of targets and directories, or tricky manual manipulation of the definitions or variables controlling how Qt 4 is found.
Towards more modern CMake usage
Starting with CMake 2.8.8, we can do a lot better:
cmake_minimum_required(2.8.8) project(hello-world) # Tell CMake to run moc when necessary: set(CMAKE_AUTOMOC ON) # As moc files are generated in the binary dir, tell CMake # to always look for includes there: set(CMAKE_INCLUDE_CURRENT_DIR ON) # Widgets finds its own dependencies. find_package(Qt5Widgets REQUIRED) add_executable(hello_world main.cpp mainwindow.cpp) qt5_use_modules(hello_world Widgets)
The qt5_use_modules CMake function encapsulates all of the set-up required to use a Qt module. It can be used with multiple arguments at once for brevity, such as:
qt5_use_modules(hello_world Widgets Declarative)
This is similar to how qmake operates:
TARGET = hello_world QT += widgets declarative
All properties are scoped to the particular target the function is used with, instead of being scoped to the CMakeLists.txt file it appears in, and affecting all libraries and executables.
For example in this snippet:
add_executable(hello_world main.cpp mainwindow.cpp) add_library(hello_library lib.cpp) add_executable(hello_coretest test.cpp) find_package(Qt5Widgets) qt5_use_package(hello_world Widgets) qt5_use_package(hello_library Core) qt5_use_package(hello_coretest Test)
Because all of the settings are scoped to the target (executable or library) they operate on, the -fPIE doesn’t get used when building the hello_library library, and the -DQT_GUI_LIB doesn’t get used when building hello_coretest.
It’s a much cleaner way to write CMake based build systems.
Looking forward, we expect a similar but more powerful feature to be possible in upstream CMake too, so that you can expect to be able to use a similar function with any CMake package.
Implementation details
One of the features of CMake that many developers who used it will be familiar with is Find files. The idea is to write a Find file for each dependency your project depends on, or use an existing Find file provided elsewhere. CMake provides a large set of Find files already, and KDE is preparing to make the Find files developed through the years available to all users of CMake.
One of the Find files provided by CMake is the FindQt4.cmake file. This file is responsible for finding Qt on your system so that you can invoke:
find_package(Qt4)
That Find file makes available the variables ${QT_INCLUDES} to set the location of header files, and ${QT_QTGUI_LIBRARIES} for linking, for example.
One of the disadvantages of this file being part of CMake, and not part of Qt, is that the file could get out-of-date. For example, when Qt 4.6 was released in December 2009 it included a new QtMultimedia module. Support for that module was not complete until CMake 2.8.2, released in June 2010.
That means that if someone wanted to use QtMultimedia, they could either have to wait for and then depend on the new CMake release, or attempt to copy the Find file into their project to work with their existing CMake version. The copying may not even work if the updated Find file uses features of the newer CMake.
Behind the scenes, Qt 5 is now found in a slightly different way too. Apart from making it possible to find your dependencies using a Find file, CMake is also able to read files provided by the dependency itself to locate the libraries and header files. Such files are called Config files, and usually they are generated by CMake itself.
A Qt 5 build, will also generate the CMake Config files, but without causing Qt 5 to depend on CMake itself.
The primary benefit of this is that the features of Qt (and the modules of Qt) which can be used with CMake do not depend on the version of CMake being used. All Qt Essentials Modules and Qt Addons Modules will create their own CMake Config file, and the features provided by the modules will be made available through the CMake macros and variables immediately.
As new modules become available, they will also be usable with CMake as soon as they are checked into a repository, so experimenting or prototyping can begin immediately and does not have to wait for a new CMake release.
Another benefit of using Config files instead of find files is that the config files have access to all aspects of the build of Qt itself including how it was configured and where it is installed to, which helps keep complexity under control when supporting static builds, and cross compiling for example.
