The Subsurface development team proudly announces release 4.3 of Subsurface, an open source divelog and dive planning program for Windows, Mac and Linux.Some of the changes since Subsurface 4.2
Subsurface now supports flexible filtering of the dive list. When the filter is opened,one can specify a combination of different criteria like tags, people who were on the dive, dive site, suit, etc. While filtering one can see how many dives
match any of the criteria, and how many dives match the combination of the selected criteria (see the panel below the main menu in the image below)
When editing a dive, one can now copy information about a dive and paste it into one or more other dives. This makes it easy to add the same equipment, buddies, tags or other aspects of a dive into a group of dives with similar characteristics.
The dive profile now offers an easy to understand tissue saturation graph that shows tissue saturation at any point during the dive. (See image below)
In the dive profile one can turn on an improved visualization of the gas combinations used during a dive (aka “tank bar” with different gases represented by different colours, see image above).
Owners of the Heinrichs & Weikamp OSTC 2 and 3 as well as dive computers in the popular Suunto Vyper family of dive computers can configure the settings of their dive computers using Subsurface.
For a number of dive computers Subsurface now downloads additional data and shows them in a new tab on the screen. This includes (depending on the dive computer) information like battery levels, no fly times, Gradient Factors used during the dive, etc. This feature is enabled in all official Subsurface binaries and includes the Uemis Zurich SDA. When building from source this requires a custom version of libdivecomputer (as explained in the INSTALL file).
The dive planner now offers the ability to re-plan dives and to create duplicate dive plans in order to plan multiple scenarios.
We added support for several new dive computers including the Suunto EON Steel, Aeris A300 CD, and Aeris F11.
Subsurface can now import dive logs from Liquivision and Cochran software as well as the new Suunto DM5.
We made many improvements for UDDF and CSV import, UDDF export now complies with the latest version of the standard.
Many issues with the HTML export were addressed.
Initial support for closed circuit rebreathers (CCR) and pSCR was added. Dive logs from the Poseidon MkVI CCR can be imported. Visualization of dive logs as well as dive planning should work — but this feature is fairly early in its development and we assume that there may be a few bugs and mis-features hidden in this area. Here is a dive profile for a Poseidon MkVI:
Other notable improvements
- Import of manually logged dives (e.g., from an existing paper logbook) is now much better documented in the user manual. Instead of having to individually enter each dive with the graphical profile editor users can add all their dives in a spreadsheet and import the data from there into Subsurface in one single operation.
- Many other small improvements to the planner
- Many small UI changes for better use on small displays (tighter columns and column headers on the dive list, the toolbox of icons no longer
forces a minimum height of the profile, etc)
- Improvements on HiDPI displays
- We fixed an annoying bug where when starting to edit a dive the pop-up with completions would cover the edit line (this usually happened when editing tags)
- For the (rather unusual) dive computers that send a heading event in every sample we automatically declutter the profile display now
- The Windows installer is smarter: the 64bit installer refuses to install its binaries on a 32bit OS and conversely the installer warns you when installing 32bit binaries on a 64bit OS
- Better synchronization with divelogs.de, including support for multiple tanks
- There appears to be a bug in Qt: when changing the password needed authenticate with a proxy, Subsurface will not use the new password until after a restart
I am happy to announce that new version of Bluedevil is out!
On 3rd December, I have released Bluedevil 2.0. It was a first stable release that supported Bluez 5 and it contained mainly crash fixes over 2.0-rc1. Unfortunately, there was also a big regression.
Libbluedevil was automatically enabling (power on) all adapters that have been found. However, this behavior was causing issues that even if the user disabled Bluetooth, it was enabled again after reboot. So the libbluedevil was adjusted not to automatically change powered state of any adapters. The problem is that Bluez is not enabling adapters at startup, so as a result, Bluetooth was now always disabled on startup.
In the new 2.1 release, powered state of all adapters is saved and restored in Bluedevil daemon. Another change is that the alias of adapter will be used in every place where name of adapter is displayed. It was always possible to change alias of adapter in KCM, but it wasn't actually used anywhere.
There is also one small improvement in kio_obexftp. It will show icons of storage types in root folder of obexftp filesystem. It should work correctly with Nokia (S40, Symbian) and Android (KitKat, Lollipop) devices. If you find any issue with the icons, please let me know.
Storage icons on Android phone
Bugs fixed in 2.1:
- remember powered state of all adapters #337193
- monolithic (Bluetooth icon) will now be correctly hidden in system tray when all adapters are powered off #341768
- monolithic will now be removed from system tray when there are no adapters
- action to send files over Bluetooth will now be shown only for file that can actually be sent (only local files)
- PIN in pairing wizard will now be accepted only after clicking "Matches" button
- kio_obexftp should now better handle errors and correctly reconnect after losing connection #321560
- kio_bluetooth will not crash when trying to access invalid device
For my job, I need to take care of the support of old Linux distributions for our products, therefore I experimented in building Qt 5.x for Red Hat Enterprise 5 (or CentOS 5 or other clones).
Whereas Red Hat Enterprise 6 works more or less out of the box, to build Qt (even without WebKit and Co.) on Red Hat Enterprise 5, more work is needed. Even the xcb library is not yet existent there.
Therefore, here a small howto, for other people having problems with building it. It contains some hacks and any input is for sure nice to have as an comment (to help others to avoid my faults).
Disclaimer: I am not responsible for creating a completely messy and buggy Qt 5.x build :=)
First, lets assume you have some CentOS 5.11 box or chroot.
You will need some new development toolsets to get rolling:
wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo -O /etc/yum.repos.d/devtools-1.1.repo
wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
I tend to use the version 2, version 1.1 does work, too (GCC 4.7.2 vs. 4.8.2).
We will needed EPEL, for a more up-to-date python (2.6, for xcb):
rpm -i epel-release-5-4.noarch.rpm
Then, lets install the minimal deps (I install both toolsets, you can choose one):
yum install devtoolset-1.1 devtoolset-2 python26 fontconfig-devel libX11-devel libXau-devel libXext-devel libXrender-devel
Then, get some compile shell ready:
scl enable devtoolset-2 bash
I will just for excercise build Qt and stuff into /tmp/usr/(qt)?
To build Qt, you need libxcb, get that (with deps):
# package config for xcb stuff
# xcb proto
tar -xzf xcb-proto-1.11.tar.gz
# pthread stubs
tar -xzf libpthread-stubs-0.3.tar.gz
tar -xzf libxcb-1.11.tar.gz
Now we are ready to build Qt 5.4, at least some parts ;=)
I skip here the GL stuff, I don’t need it and I skip some other modules.
# unpack qt
tar -xzf qt-everywhere-opensource-src-5.4.0.tar.gz
# no perf events => patch that out, won’t compile, at least not for me because of missing syscall/broken kernel header
sed -i “s/#define QTESTLIB_USE_PERF_EVENTS/#undef QTESTLIB_USE_PERF_EVENTS/g” qtbase/src/testlib/qbenchmark_p.h
# configure with some defines to work on centos 5 (fake some defines)
./configure -R ‘\\\$$ORIGIN’ -D _X_INLINE=inline -D XK_dead_currency=0xfe6f -D XK_ISO_Level5_Lock=0xfe13 -D FC_WEIGHT_EXTRABLACK=215 -D FC_WEIGHT_ULTRABLACK=FC_WEIGHT_EXTRABLACK -v -opensource -confirm-license -sysconfdir /etc/xdg -prefix /tmp/usr/qt -release -shared -qt-zlib -qt-libpng -qt-libjpeg -qt-pcre -qt-xcb -qt-xkbcommon -xkb-config-root /usr/share/X11/xkb -no-xcb-xlib -c++11 -nomake examples -nomake tests -no-dbus -no-icu -no-opengl -skip activeqt -skip androidextras -skip connectivity -skip enginio -skip location -skip macextras -skip multimedia -skip quick1 -skip sensors -skip serialport -skip wayland -skip webchannel -skip webengine -skip webkit -skip webkit-examples -skip websockets -skip winextras -skip x11extras
# build and install
=> You have some Qt, but keep in mind you need to bundle at least the libxcb.so* library, as your Red Hat Enterprise 5.x guys won’t have it!
I got a copy of the Application Development with Qt Creator, 2nd ed. for review, so I decided to post the review here – KDE is still the greatest Qt community in the world, and we have more than a few students and teachers in it which might benefit from a book like this one.
Before I start, I ought say that lately I’m used to reading some more involved material on C++, Haskell and category theory. I’m just pointing this out in the case I sound a bit more negative in this review than the book deserves.Target audience
First of all, who is this book meant for? It seems to be aimed at CS students (or others who had no contact with Qt before) who want to learn Qt when they already know C++ to some degree. It generally requires only basic understanding of C++ – I’m even wondering whether a lonely Java or C# programmer would be able to start coding in Qt with this book, without any prior knowledge of C++ (if somebody tries to, please let me know how it fares).Topics covered
A solid part of the book covers the Qt Creator, from its debugging environment to QWidget and QML UI designers. These parts are nicely written, and provide sufficient explanations for anybody to get started with it. There are a few places where a graphical representations would make more sense than textual explanations (QWidget layouts), but I guess those are simple enough not to need the explanations at all.
Other parts cover topics from Qt’s collection classes, network connections and xml parsing, to Qt Quick with multimedia and sensors. The topics are not covered in-depth, but rather provide a brief overview. Each section includes explanations of most important classes, their APIs and how they are used.
Due to its brevity, I think the book misses to mention a few important bits like QMutexLocker while talking about mutexes, or to explain the difference between QList and std::list (like why the former is less evil than the latter :) while comparing them.
The chapter that I was positively surprised to see is the “Optimizing Performance with Qt Creator” which deals with QML performance analyser and Valgrind. It is usually not a topic covered in beginner courses, and it really ought to be.Summary
Now, a short summary that does not really sum up anything. I can not make up my mind about this book.
The fact it focuses only on Qt, and does not cover it in-depth, would make it insufficient for my course (I teach C++ and Qt to the final year B.Sc. students).
I can see it as a viable (and even good) option for the early CS courses if the students have already had some basic programming course that covered C++ basics beforehand. For this stage of learning, the covered topics tend to be interesting (UI, multimedia), useful (IDE, profiling) and not over-demanding.
I realise I’m hammering on about students. It is simply because the author implied that they are the target audience, and due to my position at the university.
What about everyone else?
Since I can not make up my mind, and say “buy it!” or “run away!”, my advice is to go to the store and check it out for yourself. It is well written, and easy to read, but you should see whether the format suits you. It can be a nice introduction to Qt if you are not from around these parts. I’ve found the chapter 7 to be the most representative of the rest of the book, so when you check that one out, you’ll know what you are getting.A few more bits
Unsorted and uncovered parts from my notes:
- I haven’t checked out the price-tag, didn’t want to influence my expectations;
- I’m sometimes overly harsh when reviewing things – when I find dubious and incorrect statements (and expect the author to know better), I can go berserk – it did not happen in this case, not once;
- I sometimes get annoyed by layout and printing errors – it happened only once or twice with this book :);
- Thanks to Packt for giving me the book to review.
KDE e.V. has been successfully supporting the KDE community for over 17 years. For many of them we had the tremendous help of a business manager, several interns, an event manager and countless volunteers to be able to do this. In the coming years we want to be able to support the KDE community even better. In order to do this we need strong support from an Executive Director. The Board of Directors has decided to hire someone for this position in the coming months. We are looking for a passionate individual who understands our community and can drive our business interaction. Do you want to be a part of bringing great software to millions of users? Do you want to really make a difference for a Free Software non-profit? Then this is the job for you! If you would like to know more about the position please read the job ad.
Would you like to tell us something about yourself?
I only paint digitally. Even though I love the way traditional paintings look, I haven’t painted traditionally. A #2 pencil was my first tool for drawing when i was a child, and is still my favourite. I’ve tried various pencils, charcoal, and made a horrible mess with graphite dust, but none of them ever worked as well for me as the pencil.Do you paint professionally or as a hobby artist?
I paint as a hobby, and only recently did this become an obsession. I spend most of my time painting when I’m not working or adventuring with the family. I’m a performance engineer by day.When and how did you end up trying digital painting for the first time?
About 5 years ago my family gifted me an intuos3 for Christmas. I started looking into drawing/painting programs and came across Mypaint. 30 seconds later I was addicted to digital painting. From there, I just experimented with any drawing software that would run on Linux.What is it that makes you choose digital over traditional painting?
So many reasons. Digital seems effortless in comparison to traditional mediums. And the whole field of digital painting is still relatively young. There are so many ideas out there on how to improve upon what we have and new ideas to push the boundaries. Hardware and software are always improving and becoming more portable. Who knows what digital painting will have to offer in 5 years. I just know that i want to be part of it. Plus, it would be a big investment in time and money to acquire materials and knowledge in traditional mediums.How did you first find out about open source communities? What is your opinion about them?
I’ve been working on Linux since college – about 1998. FOSS is awesome and I am thankful to live in a generation where it is so prevalent.Have you worked for any FOSS project or contributed in some way?
I haven’t worked for FOSS projects yet, but what a great idea for a New Year’s resolution. I’ve worked as part of teams that generated open source tools and upstream patches for existing drivers/kernel, but nothing directly.How did you find out about Krita?
After I was comfortable with Mypaint, I started to branch out to see what else was available. Being able to incorporate textures and textured brushes was high on my things to try. Gimp was painful for me to use for painting, so I dropped it. That’s when I came across Krita on some blog that was listing Linux painting software.What was your first take on it?
It was a little rough around the edges when in canvas mode, but other than that, worked very well for me.What do you love about Krita?
I am still finding new features, brushes, filters, etcetera that I incorporate in my art. My favourite discovery so far: the sketch speedpaint brushWhat do you think needs improvement in Krita? Also, anything that you really hate?
Being a portrait painter, getting a likeness had a lot to do with proportions and measurements. The feature I would like most would be to open my reference and have it automatically zoomed & panned to the same part as the canvas.
As for things I hate, there are none.In your opinion, what sets Krita apart from the other tools that you use?
1) The set of features : I don’t need any other tools with Krita. It is the best combination of editing and painting tools in one spot.
2) Krita is solid and reliable. I have crashed Mypaint, Gimp, and Painter and have had images corrupted by it. Never with Krita. 8000 px square, 600 dpi – no problems.If you had to pick one favourite of all your work done in Krita so far, what would it be?
“Surprised to see Me?”What is it that you like about it? What brushes did you use in it?
The expression came out really well and while i was worried blue hair may have been overboard, the colors are awesome. As for brushes, I didn’t use many – HB pencil for sketch/measurements, basic block, smudge and sponge for painting..Would you like to share it with our site visitors?
Of course! It’s the featured image of this post.Anything else you’d like to share?
I’d rather paint than maintain a site. If anyone would like to contact me or see what I’m up to, check out deviantArt: http://kynlo.deviantart.com
After adding the first theme, I was working on a theme on nature. That theme represents the basic elements in the nature such as trees, flowers and etc. Since KDE Pairs is developed for pre school children the objects represented in the themes should be familiar and educational to them. Following are some screen shots after adding the theme nature to the game. These screenshots represents the different game modes such as logic, pairs, relations and words.
Filed under: KDE, Open Source Tagged: KDE, KDE edu, Pairs, Season of KDE, SoK, theme designing for pairs, Themes
Well, Marley might be dead, but Krita ain’t! So, here’s what’ll be the last beta build of Krita before the festive season really breaks lose. Apart from building, the Krita hackers have had a pretty good week, with lots of deep discussions on animation and coding safety, too.
Oh — and there’s a seasonal surprise for you, if you start one of these builds!
In the new builds, not quite beta 2 yet, just another build in between the last beta and the next beta, there are the following fixes:
- Stefano Bonicatti fixed a bunch of memory issues, and is tracking more and more of them — also threading issues, and issues with AMD graphics cards.
- Boudewijn added a new option to use Krita to convert images: krita bla.png –export –export-filename bla.jpg will convert bla.png to bla.jpg. This replaces the calligraconverter utility.
- The ‘hairy brush’ is now called the ‘bristle brush’
- PDF export has been fixed to export landscape as landscape and portrait as portrait, instead of everything as portrait, when using any paper size except A4. (A4 already worked fine).
- The filter dialog (filters, filter layers, filter masks) no longer show a big thumbnail. The thumbnail was getting in the way of the filter’s name, and frequently didn’t get rendered correctly/.
- Deleting the last node (layer or mask) in a group would lead Krita to having no node selected, causing crashes in filters. That got fixed, too.
- On loading or creating the first image, the default tool is once again the freehand brush, and besides, the tool options are now shown.
- Select-all is back
- In tab-mode, the tabs now keep the right caption
- A crash when flattening layers was fixed
- Jouni Pentikäinen fixed the outline cursor preview of a rotating brush
- Selecting a document size specified in anything but pixels was broken; that works now, too. Thanks to Joe for the detailed bug report!
- Every open subwindow can now have its own exposure and gamma settings, when a HDR image is loaded an OpenColorIO is active
- A bunch of fixes to the tablet subsystem were committed by Dmitry. Painting should be much smoother now — and we’ve also figured out why some n-trig devices do weird stuff. They tell us their maximum pressure is 255, but then send us tablet strokes with pressure in the 0 to 1024 range!
- Wolthera fixed an issue with darkening around the color smudge brush’s radius
- Dmitry made it possible to drag & drop layers from one subwindow to another.
- And made it possible again to drag & drop images from web-browsers
- The locked status of docking panels now is kept properly
- (But on Windows, the minimum width of the toolbox now is three icons — investgations are ongoing)
- Scott cleaned up the precision setting in the brush editor
- Lukáš worked like a beaver on the G’Mic plugin and updated it to the latest version, added proper layer synchronization — and, tada! — on Linux/X11 enabled the interactive filter feature. Interactive Colorize now works on Linux, from within Krita. Press Space for the best effect!
- Sven and Stefano fixed a crash when opening one image after closing another and changing the OpenGL settings in between.
- Timothée Giet updated all color-smudge brush presets
- Dmitry fixed a crash in the duplicate brush engine when using a tablet device
- Sven fixed loading brush presets from bundles
And that ties in with a lot of work Wolthera has done. Building on Victor Lafon’s work earlier this year to make it possible to package resources — brushes, gradients, patterns, everything — in bundles, she’s hit her stride and figured out what was broken and what needs to be added. But… It’s already possible to load a bundle into Krita, and use the resources!
There are still 230 bugs at the moment, down from 234, even though we fixed more than thirty bugs! Some of these bugs might cause dataloss, so users are recommended to use the beta builds for testing, not for critical work!
For Linux users, Krita Lime will be updated on Monday. Remember that launchpad is very strict about the versions of Ubuntu it supports. So the update is only available for 14.04 and up.
OpenSUSE users can use the new OBS repositories created by Leinir:
Windows users can choose between an installer and the zip file. You can unzip the zip file anywhere and start Krita by executing bin/krita.exe: this only works if you have the right Microsoft Visual Studio C runtime library. Otherwise, use the MSI file. We only have 64 bits Windows builds at the moment, we’re working on fixing a problem with the 32 bits build.
OSX users can open the dmg and copy krita.app where they want. Note that OSX still is not supported. There are OSX-specific bugs and some features are missing.
So far i have ported the build system and it has already bean pushed to the frameworks branch of KNetWalk. You can have a look at my progress at http://quickgit.kde.org/?p=knetwalk.git on frameworks branch.
App is able to build and install successfully on kf5 on my local system. I will push other changes soon.
Now I am looking forward to port ui as now app is crashing because ui is not ported.
garvit@beast:~/dev/sok/knetwalk/build$ cmake ../
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found KF5CoreAddons: /usr/lib/x86_64-linux-gnu/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version "5.3.0")
-- Found KF5Config: /usr/lib/x86_64-linux-gnu/cmake/KF5Config/KF5ConfigConfig.cmake (found version "5.3.0")
-- Found KF5ItemModels: /usr/lib/x86_64-linux-gnu/cmake/KF5ItemModels/KF5ItemModelsConfig.cmake (found version "5.3.0")
-- Found KF5WidgetsAddons: /usr/lib/x86_64-linux-gnu/cmake/KF5WidgetsAddons/KF5WidgetsAddonsConfig.cmake (found version "5.3.0")
-- Found KF5WindowSystem: /usr/lib/x86_64-linux-gnu/cmake/KF5WindowSystem/KF5WindowSystemConfig.cmake (found version "5.3.0")
-- Found KF5Codecs: /usr/lib/x86_64-linux-gnu/cmake/KF5Codecs/KF5CodecsConfig.cmake (found version "5.3.0")
-- Found KF5Archive: /usr/lib/x86_64-linux-gnu/cmake/KF5Archive/KF5ArchiveConfig.cmake (found version "5.3.0")
-- Found KF5DBusAddons: /usr/lib/x86_64-linux-gnu/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake (found version "5.3.0")
-- Found KF5DNSSD: /usr/lib/x86_64-linux-gnu/cmake/KF5DNSSD/KF5DNSSDConfig.cmake (found version "5.3.0")
-- Found Gettext: /usr/bin/msgmerge (found version "0.19.2")
-- Found PythonInterp: /usr/bin/python (found version "2.7.8")
-- Found KF5Declarative: /usr/lib/x86_64-linux-gnu/cmake/KF5Declarative/KF5DeclarativeConfig.cmake (found version "5.3.0")
-- Found KF5I18n: /usr/lib/x86_64-linux-gnu/cmake/KF5I18n/KF5I18nConfig.cmake (found version "5.3.0")
-- Found KF5GuiAddons: /usr/lib/x86_64-linux-gnu/cmake/KF5GuiAddons/KF5GuiAddonsConfig.cmake (found version "5.3.0")
-- Found KF5Service: /usr/lib/x86_64-linux-gnu/cmake/KF5Service/KF5ServiceConfig.cmake (found version "5.3.0")
-- Found KF5ConfigWidgets: /usr/lib/x86_64-linux-gnu/cmake/KF5ConfigWidgets/KF5ConfigWidgetsConfig.cmake (found version "5.3.0")
-- Found KF5ItemViews: /usr/lib/x86_64-linux-gnu/cmake/KF5ItemViews/KF5ItemViewsConfig.cmake (found version "5.3.0")
-- Found KF5IconThemes: /usr/lib/x86_64-linux-gnu/cmake/KF5IconThemes/KF5IconThemesConfig.cmake (found version "5.3.0")
-- Found KF5Completion: /usr/lib/x86_64-linux-gnu/cmake/KF5Completion/KF5CompletionConfig.cmake (found version "5.3.0")
-- Found KF5JobWidgets: /usr/lib/x86_64-linux-gnu/cmake/KF5JobWidgets/KF5JobWidgetsConfig.cmake (found version "5.3.0")
-- Found KF5TextWidgets: /usr/lib/x86_64-linux-gnu/cmake/KF5TextWidgets/KF5TextWidgetsConfig.cmake (found version "5.3.0")
-- Found KF5GlobalAccel: /usr/lib/x86_64-linux-gnu/cmake/KF5GlobalAccel/KF5GlobalAccelConfig.cmake (found version "5.3.0")
-- Found KF5XmlGui: /usr/lib/x86_64-linux-gnu/cmake/KF5XmlGui/KF5XmlGuiConfig.cmake (found version "5.3.0")
-- Found KF5Crash: /usr/lib/x86_64-linux-gnu/cmake/KF5Crash/KF5CrashConfig.cmake (found version "5.3.0")
-- Found KF5Bookmarks: /usr/lib/x86_64-linux-gnu/cmake/KF5Bookmarks/KF5BookmarksConfig.cmake (found version "5.3.0")
-- Found KF5KIO: /usr/lib/x86_64-linux-gnu/cmake/KF5KIO/KF5KIOConfig.cmake (found version "5.3.0")
-- Found KF5NotifyConfig: /usr/lib/x86_64-linux-gnu/cmake/KF5NotifyConfig/KF5NotifyConfigConfig.cmake (found version "5.3.0")
-- Found KF5NewStuff: /usr/lib/x86_64-linux-gnu/cmake/KF5NewStuff/KF5NewStuffConfig.cmake (found version "5.3.0")
-- Found KF5KDELibs4Support: /usr/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake (found version "5.3.0")
-- Found KF5: success (found version "5.3.0") found components: CoreAddons Config ItemModels WidgetsAddons WindowSystem Codecs Archive Config DBusAddons DNSSD Declarative I18n GuiAddons Service ConfigWidgets ItemViews IconThemes Completion JobWidgets TextWidgets GlobalAccel XmlGui Crash Bookmarks KIO NotifyConfig NewStuff KDELibs4Support
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/garvit/dev/sok/knetwalk/build
Make Log can be find here : https://gist.github.com/garvitdelhi/0e21a095dcfc8cfef170
Plasma 5 pushes QtQuick to the limits. It sounds like a cheesy marketing line, but it's true. Unfortunately this isn't a good thing. Although Plasma 5.1 is somewhat stable we have had some crashers, and whilst we've worked hard to fix the ones that are ours a sizeable number of these were caused by problems deep inside Qt.
Fortunately Qt 5.4 has just been released. It contains countless bug fixes that really improve the situation; several of which were even written by me and the rest of the Plasma crew.
We need people with Qt 5.4 (hey all you Arch people) to help go through all open crash reports and test if they still happen since upgrading.
I don't like closing bugs wtih a vague "it seems to work for me" without getting at least a second opinion, I may be overlook something and it's not fair on the original reporter.
I've added a quick link to the high priority candidates
And feel free to help go through the rest of our list
So far everything is looking very positive towards having a completely rock solid Plasma 5.2 in January; lets make it happen.
I always have been a huge fan of astronomy, stars, cosmos etc. I must admit that I find it absolutely breathtaking, especially, looking at particular constellations, the way they combine into jewelry shapes that have lots of similarities with known objects. Interesting, somewhere in space there could be a guy like me, looking at sky and finding other objects…
KDE Edu has an outstanding project, called KStars. It provides functionality for observing stars and constellations we have there on sky. First of all, it has a huge impact on educational programs: teachers can use it on astronomy lessons in high school. It does good calculation job and precise enough to be used in scientific researches.
At the moment, KStars has nearly 100 contributors. People has been working on it for a while and you can see a good outcome so far. Still, software can’t be perfect at all and there are always a few features in TODO list. In case if you are interested in contributing to KStars, I have good news for you, there are jobs to do. If you feel yourself rather like a beginner, don’t be afraid, there are some junior jobs as well!
So if you are not a software developer at all, don’t be upset, you always can do some testing/packaging job for different platforms KStars team, they will really appreciate it. By the way, there is a good guide about building KStars from source also, that’s a good point to start with.
Hope you will have fun with KStars!
The first thing to do is to open the Cat's Guide To Building Krita, because that's the base for what I'm going to try to explain here. It's what I use for developing Krita, I usually have every version from 2.4 up ready for testing.
With 14.12.0 we've introduced full changelogs for KDE Applications releases; you can see it at https://www.kde.org/announcements/fulllog_applications-14.12.0.php.
To generate this changelog we diff from previous release to the released one and use the commit message with a few annotations for stuff like REVIEW: BUG: etc.
This means the world is now going to see your commits more so spend 3 seconds when writing them instead of 0.5 ;)
If someone wants to improve the page (I'd like to have a checkbox that shows only commits that fix bugs) please contact me :)
The code lives in the release-tools repo (this is probably my longest python script, so be gentle ;))
I have finished porting Lokalize to KF5, you can build it using kdesrc-build script.
Also I'm working on a stripped down version of Lokalize for Windows and for OS X which doesn't need KDE. Follow the links to get .exe and .app prebuilt for you (Windows XP+, OS X 10.9+)
Remember this is the first public preview release, so don't expect more than simple editing of PO and XLIFF files. Features that are missing but are planned for integration into win+osx versions:
- File search and replace window with Quality Assurance feature
- Stemming for the glossary
- Calling odf2xliff and xliff2odf console tools from Lokalize
Please report bugs, crashes and features you would like to be implemented first down in the comments.
KUniqueApplication: please see a code inside Q_OS_WIN32 in main.cpp for the way how to open files in an app instance that is already running. For OS X you only need to install an event filter on qApp that reacts to QFileOpenEvent event.
In our current kdepim code we use some classes throughout the codebase. I’m going to line out the problems with that and propose how we can do better.The Application Domain
Each application has a “domain” it was created for. KOrganizer has for instance the calendar domain, and kmail the email domain, and each of those domains can be described with domain objects, which make up the domain model. The domain model of an application is essential, because it is what defines how we can represent the problems of that domain. If Korganizer didn’t have a domain model with attendees to events, we wouldn’t have any way to represent attendees internally, and thus couldn’t develop a feature based on that.
The logic implementing the functionality on top of those domain objects is the domain logic. It implements for instance what has to happen if we remove an event from a calendar, or how we can calculate all occurrences of a recurring event.
In the calendaring domain we use KCalCore to provide many of those domain objects and a large part of the domain logic. KCalCore::Event for instance, represents an event, can hold all necessary data of that event, and has the domain logic directly built-in to calculate recurrences.
Since it is a public library, it provides domain-objects and the domain-logic for all calendaring applications, which is awesome, right? Only if you use it right.
KCalCore provides additionally to the containers and the calendaring logic also serialization to the iCalendar format, which is also why it more or less tries to adhere to the iCalendar RFC, for both representation an interpretation of calendaring data. This is of course very useful for applications that deal with that, and there’s nothing particularly wrong with it. One could argue that serialization and interpretation of calendaring data should be split up, but since both is described by the same RFC I think it makes a lot of sense to keep the implementations together.Coupling
A problem arises when classes like KCalCore::Event are used as domain objects, and interface for the storage layer, and as actual storage format, which is precisely what we do in kdepim.
The problem is that we introduce very high coupling between those components/layers and by choosing a library that adheres to an RFC the whole system is even locked down by a fully grown specification. I suppose that would be fine if only one application is using the storage layer,
and that application’s sole purpose is to implement exactly that RFC and nothing else, ever. In all other cases I think it is a mistake.
The domain logic of an application has to evolve with the application by definition. The domain objects used for that are supposed to model the problem at hand precisely, in a way that a domain logic can be built that is easy to understand and evolve as requirements change. Properties that are not used by an application only hide the important bits of a domain objects, and if a new feature is added it must be possible to adjust the domain object to reflect that. By using a class like KCalCore::Event for the domain object, these adjustments become largely impossible.
The consequence is that we employ workarounds everywhere. KCalCore doesn’t provide what you need? Simply store it as “custom property”. We don’t have a class for calendars? Let’s use Akonadi::Collection with some custom attributes. Mechanisms have been designed to extend these rigid structures so we can at least work with it, but that only lead to more complex code that is ever harder to understand.
Instead we could write domain logic that expresses precisely what we need, and is easier to understand and maintain.
Zanshin for instance took the calendaring domain, and applied the GettingThingsDone (GTD) methodology to it. It takes a rather simple approach to todo’s and initially only required a description, a due date and a state. However, it introduced the notion that only “projects” can have subtodo’s. This restriction needs to be reflected in the domain model, and implemented in the domain logic.
Because there are no projects in KCalCore, it was simply defined that todo’s with a magic property “X-Project” are defined as project. There’s nothing wrong with that itself, but you don’t want to litter your code with “if (todo->hasProperty(X-Project))”. So what do you do? You create a wrapper. And that wrapper is now already your new domain object with a nice interface. Kevin fortunately realized that we can do better, and rewrote zanshin with its own custom domain objects, that simply interface with the KCalCore containers in a thin translation layer to akonadi. This made the code much clearer, and keeps those “x-property”-workarounds in one place only.
A useful approach to think about application architecture are IMO layers. It’s not a silver bullet, and shouldn’t be done too excessively I think, but in some cases layer do make a lot of sense. I suggest to think about the following layers:
- The presentation layer: Displays stuff and nothing else. This is where you expose your domain model to the UI, and where your QML sits.
- The domain layer: The core of the application. This is where all the useful magic happens.
- The data access layer: A thin translation layer between domain and storage. It makes it possible to use the same storage layer from multiple domains and to replace the storage layer without replacing all the rest.
- The storage layer: The layer that persists the domain model. Akonadi.
By keeping these layer’s in mind we can do a better job at keeping the coupling at a reasonable level, allowing individual components to change as required.
The presentation layer is required in any case if we want to move to QML. With QML we can no longer have half of the domain logic in the UI code, and most of the domain model should probably be exposed as a model that is directly accessible by QML.
The data access layer is where akonadi provides a standardized interface for all data, so multiple applications can shared the same storage layer. This is currently made up by the i.e. KCalCore for calendars, the akonadi client API, and a couple of akonadi objects, such as Akonadi::Item and Akonadi::Collection. As this layer defines what data can be accessed by all applications, it needs to be flexible and likely has to be evolved frequently.The way forward
For akonadi’s client API, aka the data access layer, I plan on defining a set of interfaces for things like calendars, events, mailfolders, emails, etc. This should eventually replace KCalCore, KContacts and friends from being the canonical interface to the data.
Applications should eventually move to their own domain logic implementation. For reading and structuring data, models are IMO a suitable tool, and if we design them right this will also pave the way for QML interfaces. Of course i.e. KCalCore still has its uses for its calendaring routines, or as a serialization library to create iTip messages, but we should IMO stop using it for everything. The same of course applies to KContacts.
What we still could do IMO, is share some domain logic between applications, including some domain objects. A KDEPIM::Domain::Contact could be used across applications, just like KContact::Adressee was. This keeps different applications from implementing the same logic, but of course also introduces coupling between those again.
What IMO has to stay separate is the data access layer, which implements an interface to the storage layer, and that doesn’t necessarily conform to the domain layer (you could i.e. store “Blog posts” as notes in storage). This separation is IMO useful, as I expect the application domain to evolve separately from what actual storage backends provide (see zanshin).
This is of course quite a chunk of work, that won’t happen at once. But need to know now where we want to end up in a couple of years, if we intend to ever get there.
As you saw I continue to work on 4.14 branch, in parallel I work on KF5 porting.
Why do I continue to work on 4.14 ?
Because KF5 kdepim version will not arrive before that AkonadiNext will be stable, so it will take time. AkonadiNext is writing from scratch.
I don’t know if you remember but during porting to akonadi, kdepim 4.4 was not improving during 2 years, no bug fixing, nothing. It was a very bad idea.
So I decided to continue to fix 4.14, until we release KF5.
What do I do in 4.14 ?
I continue to fix bug. And there is still a lot of bugs
I try to make it stable.
During this period I try to write a lot of unit-test on this branch.
Why do I write unit test ?
Because there is not unit test on kdepim It’s a good reason.
But there is a second reason, as I port kdepim to KF5 and it’s not stable to use it, I can’t know if all works fine. So I create unit test, I verify that it works on 4.14 and after that I just need to run unit test on KF5 to be sure that it works fine on KF5 too.
What do I do when I add a new feature in KF5 ?
Now each new feature that I add, or feature will add in kdepim will have a unit test.
So in KMail or in each lib/apps that I maintain in kdepim, I will not accept new feature if there is not unit-test, because it’s very useful and I don’t want to write them after
It’s a pain when we need to write unit test on a code that we didn’t write.
And sometime code is not adapted to create unit test so it’s necessary to rewrite it. (I rewrote some code in 4.14 to allow to create some unit test).
It’s more easy to create unit test when we write feature that write them after.
The first Alpha of Vivid (to become 15.04) has now been released!
The Alpha-1 images can be downloaded at: http://cdimage.ubuntu.com/kubuntu/releases/vivid/alpha-1/
More information on Kubuntu Alpha-1 can be found here: https://wiki.ubuntu.com/VividVervet/Alpha1/Kubuntu
KDAB engineers have contributed lots of code to Qt during the last few months. Once more, KDAB is the second largest contributor to Qt (the first being The Qt Company itself). The commit stream has been constant, as you can see in this graph showing the last 16 weeks:
In this blog post I’ll show some of the notable features developed by KDAB engineers that you are going to find in Qt 5.4.Qt WebChannel
The ultimate cause of this lost feature is that modern HTML engines employ multiple processes for performance and security reasons, and therefore the same kind of deep integration that the WebKit Bridge made possible was not available any more.
The WebChannel brings back this awesome functionality, and it extends it even further — it is now possible to export QObjects to any remote browser, that is, not only the WebViews owned by the very same Qt application.
For more information, please refer to this blog post by my colleague Milian Wolff.The Declarative State Machine Framework
Back in the day, Qt 4.6 introduced a State Machine Framework based on SCXML. It consisted of a few C++ classes to build state machines out of individual states and transitions, and had quite a nice feature set: it supported parallel states, final states, history states, guarded transitions and so on.
Unfortunately, writing state machines by hand requires a lot of boilerplate C++ code. For instance, in order to add a transition to a new state, we must create a new QState object, create a new transition object, and finally add the transition.
Ford Motor Company, in a technical partnership with KDAB, has generously contributed high-level QML wrappers for the C++ state machine. The new technology goes under the name of Declarative State Machine Framework; it uses QML as a Domain Specific Language (DSL) for writing declarative state machines, while being backed by the full C++ state machine framework.
DSM allows users to create state machines using QML, therefore removing the need of boilerplate code, resulting in a nice and compact representation for state machines.
What’s more, it also allows removing the imperative bits from the state machine (that is, which properties should be updated when entering a state); it instead enables any given QML element to bind its property to whether the state machine is in a state or not.
Please refer to the module documentation for more information, as well as the short talk by my colleague Kevin Funk from this year’s Qt Developer Days.QNX co-maintainership
Due to KDAB’s sustained efforts into supporting QNX, we’re very pleased to hear that my colleague Rafael Roquetto has been nominated co-maintainer of the QNX support in Qt. He’s going to join the ranks with our colleague Bogdan Vatra, maintainer of the Android support. Congratulations, Rafael!Other contributions
In no particular order:qmllint
qmllint is a syntax checker for QML files. You can therefore run it on your QML files before shipping them with your application, or add a qmllint step to your CI system / SCM hooks. If you want to know more, please refer to this blog post by my colleague Sérgio Martins.New hooking system for tooling
Qt has always had a number of private entry points that were supposed to be used by debugging/profiling tools. Unfortunately, due to aggressive compiler optimizations, those hooks were almost always compiled out in release builds, and therefore their usage on any platform but Linux/GCC was extremely problematic.
KDAB’s Senior Engineer Volker Krause developed a solution for this problem, which can be found in Qt 5.4.
The main user of this feature is of course GammaRay, one of the KDAB’s flagship products. GammaRay is a free software solution that provides high level debugging for Qt, allowing the developer to inspect individual subsystems of any complex application.Lots of bugfixes
Working on real projects, we do know that code does not always behave as advertised. At the same time, we strive to make Qt the best product for cross-platform, high-performance application development.
Therefore, it should not be a surprise that KDAB engineers fixed over 50 reported bugs between Qt 5.3 and Qt 5.4 (and, of course, fixed even more problems which didn’t even have an associated bug report!). Only a few weeks ago KDAB launched a new service, FixMyQtBug, to help companies building products using Qt which are struggling against upstream bugs; our skills and dedication show that we indeed are the experts when it comes to Qt, and we are willing to fix your Qt bugs as well.
Dear digiKam fans and users,
The digiKam Team is proud to announce the release of digiKam Software Collection 4.6.0. This release includes many bugs fixes in Image Editor and Batch Queue Mananger. Thanks to Maik Qualmann and Jan Wolter to propose patches in KDE bugzilla.
Inge, Tobias and I founded KO GmbH in 2007 in Magdeburg. We named it KOfficeSource, because we believed that KOffice, which is Calligra these days, was getting ready for the big time, especially on mobile. Nokia was beginning to invest heavily into open source, Intel joining in with Moblin, the times were heady and exciting! After a bit of rough-and-tumble about the name, we renamed KOfficeSource GmbH to KO GmbH and from 2010 on, we were in business!
For a couple of years we had a great time. We ported Calligra to Maemo, Meego, Sailfish and Windows. We created half a dozen mobile versions of the core Calligra applications: viewers, editors. Along the way, we found some other customers, next to Nokia and Intel: NLNet helped with the port to Windows, SKF used Calligra in their Orpheus ball-bearing modeling tool as the report-writing component, ROSA was getting interested in the WebODF technology we had developed together with NLNet.
Then things began to go awry. Even after dropping Meego, Nokia was still a customer of ours for some time, but we were doing prototype stuff in j2me for Asha phones. Not really exciting! ROSA went broke. We lost SKF as a customer when they had to reorganize to turn their development process around. Other customers had to cut down -- and we were also basically a bunch of tech nerds with no idea about doing sales: until now we never had to do sales.
Which meant that we failed to build enough of a business to sustain ourselves. We tried to expand, with Krita being an obvious choice for a mature product. But that still needed sales, and we failed at that, too.
So, from January on, I'll be no longer with KO GmbH. The Krita Foundation has taken over Krita on Steam and the support for the Krita Studio customers. We'll first release Krita 2.9, which is going to be awesome! And then, I'll be looking for work again, as a project lead or developer, freelance or with a company, on Krita or something else altogether.