For example, if we are drawing in a big picture, we typically change only a small piece of the image at a time. Most parts aren't changed at all, and can be swapped to disk without much of a cost.
Another example is undo data. If you start painting, we need to store information about past image states. Usually this information will not be needed anymore by the user, but we have to store it for the unexpected case where it *will* be needed. This information can just as well be stored in disk, instead of sitting in the memory.
Reducing the memory footprint is extremely important, especially on machines with less RAM: if we would not manually swap out our data, other applications of the user might be swapped out, which is usually undesirable.
Now, our specific implementation of paint devices led to some interesting advantages over other applications like The GIMP. Unfortunately for us (and luckily for The GIMP), our tile backend was good enough to get along with, so we didn't innovate as much anymore. However, with GEGL picking up a lot of steam lately, this means that we are starting to miss out on some very cool features that the GIMP will have (or even has already). To ensure that Krita is also able to do those things, I've been slowly reworking our old backend code into a more flexible design (as far as the other API allows for that, of course).
One of the major issues I have worked on up to an initial stage is trying to make the tiles backend somewhat more robust in a multi-threaded environment. Our old code was pretty ugly in that regard. The code regarding tile management was safeguarded by a single big lock (called the "Big Krita Lock" ;-)). After the rewrite, I'm hoping that more parts will be more usable in a multi-threaded context. Some work still remains to be done, but I'm hopeful that with the new code, it should be a lot easier to implement the required changes than with the Krita 1.6 framework (famous last words!).
Another new feature that is already implemented is the introduction of shared tiles. This means that multiple paint devices can have a single source of tiles in memory (a sort of implicit copying of tiles). We already had a rudimentary approach for a single kind of tile: the "default" tile. That meant that if a paint device was read at a place where the corresponding tile wasn't yet created, it used a single tile as a "source" for all those empty spots.
Unfortunately that approach wasn't scalable enough to be used throughout Krita. The rewritten code takes care of that, and we should be able to have several whole paint devices share the exact same tile data.
The feature I've been playing with most recently, is the ability to load the content of paint devices directly from image files. The old (and current) way of loading an image file is to read in the image, and copy all data into a paint device (or multiple devices in case of multiple layers). This unfortunately means that you have the same data available twice: all data for the layer is already present in source image, and then we load it into Krita (and then swap it out again) anyway.
Giving paint devices the ability to get their data directly from a file thus means that we cut out this middle step. In the long run, this should give an improvement in memory/swap usage of *big* image files. Of course, this implies a penalty because you have to decode part of the image each time you want to access some tile data. We'll just have to find out at which point it will be in our favor to use this approach.
Currently this functionality is merely implemented at the backend level, so Krita just has some nice code that abstracts most ugly things away from the file format people. I've ensured myself that the backend works (at least decently) by writing a unit test that fakes loading an image from a file directly. I'm guessing that in time, other Krita developers who have greater affinity with the image loading code will try to implement the code needed to load specific image formats.
The most interesting surprise while developing all this, is that my new code unintentionally detects some new Krita memory leaks :-). At Krita shutdown, the new code has much more stringent consistency checks, including one that complains if it thinks it's leaking tile data (which it did!). Much to my surprise, if I enabled the check, it got triggered by some different places in Krita that appeared to leak memory at exit.
As for the future, I'm hoping to iron out all the bugs, of course ;-). Obviously, I'd like to see more features, and one of them that I've been wanting to implement for more than a year is a MipMap for the paint devices at the tile-level. It's something that GEGL and The GIMP already have, and I think that Krita would also benefit from it. Basically, the idea is that you efficiently pre-"render" some scaled-down versions of your image, so that you become a lot faster when zooming out.
Another thing that would be very cool is sharing of a single paint device across applications. This would be quite interesting for collaborative painting applications. GEGL already has some support for this (this was demonstrated at Libre Graphics Meeting 2008 very recently), and I'm hoping that Krita will join the club. My work towards loading tiles directly from "disk" should be generic enough to also easily allow files to be loaded from the network and so on. I'm guessing that the hardest part there would be handling the synchronization issues, etc (but without trying an implementation, I don't know for sure).
There are of course lots of other things on the todo-list, but they are more small implementational details (like using QAtomicInt now that it is available for real through Qt 4.4). That's it for now!
Note: People wanting to try out this code will have to manually enable it at compile time. Just change the USE_OLD_TILESYSTEM value in krita/image/CMakteLists.txt. Be aware that most changes are not visual, and that there remain some known issues with the code!
- Ported the old version to KDE 4
- Now it uses the Model/View design to list colors
- Added new features, like moving items
- Improved the load dialog
- Fixed all the bugs from the previous version
My goal is to create a fun and useful application to edit and create color palettes.
The problems that this application solve are basically the creation and editing of color palettes. While there are many tools that can do this, they are often non-Free software. There is Agave from GNOME which tries to assist in the same tasks. Many image editors like Krita, GIMP, and Kolourpaint have embedded widgets/dialogs to manage the color palette, but with KColorEdit this task is performed in a better way, and all of these image editors can import the files that KColorEdit creates.
With the current state of KColorEdit, you can perform all the things of the previous version and more, like adding comments to your palette, moving the items, adding a name to your palette, view a description of your palette, manage 2 views of your palette, and so on.
In the near future, I want to ensure KColorEdit has the same features of many tools that perform the creation of palettes. Also, I will continue to report the status to Artur.
In a technical way, here are the things that KColorEdit should do in the future:
- Select a color from an image, the desktop, and from a gradient
- Show the colors with many schemes, like complementary colors (the complement of the current color)
- Add many colors to the palette in a "line", meaning that if I define a line in some colorspace then the application automatically adds all the colors that follow this line (with a delta).
I'm not sure if you are familiar this feature, but let me say that it could be very useful.
- Generate a "presentation" of the palette, you can define how to view the palette (aside from default views)
- And finally, add the undo/redo feature with the Memento pattern, but I think that KDE 4 has its own implementation of this pattern.
- This application would be more easy to maintain (and also I think other apps) if we had a common API to represent color selection, for instance the color selector of KColorDialog is an embedded widget, it would help more if this "selector widget" was someting like a KColorSelector class in the API, the same with the color selector of Krita (i'm talking about the triangle color selector that looks similar to the GTK color selector), this would be for instance named KGtkColorSelector.
In short we should define a common interface for color selectors. I had to cut code of KColorDialog and KOffice to use those implementations (of course I respect the credits).
- There isn't a "KColor" class that wraps QColor, but there are so much actions that this class could do, like get the luminance of the color, or convert between colorspaces, etc. I think that there is a class named "KColor", but it is in the playground module, and so I can't used.
- KColorCollection doesn't have support for comments, only for one description.
- It would be great if all palette stuff had a model/view design, KColorCells (possible view) and KColorCollection (possible model) do not follow this concept.
|Commits||3284 by 247 developers, 8218 lines modified, 1593 new files|
|Bugs Opened||481 in the last 7 days|
|Bugs Closed||422 in the last 7 days|
|Aaron J. Seigo||
Internationalization (i18n) Status
Bug Killers and Buzz
|Aaron J. Seigo||
|Aaron J. Seigo||
|Adriaan de Groot||
There are 216 selections this week
+ Fix bug #162059: when leaving the program in Horizontal coordinates and not tracking on the sky, the initial position on next startup should be the same Alt/Az coordinates. Fixed.
+ When leaving the program tracking on a star named "star", the initial position on the next startup should be that same star, Fixed.
They seem like simple fixes, but it actually took quite a bit to fix these. Another symptom of the bubble-gum-and-duct-tape nature of the startup code...
Is it worth trying to backport this fix to the 3.x codebase?
Are we going to have 3.5.10?
Well, that wasn't so hard after all.
KStars no longer exits when starting up below the horizon. I simply moved "show()" so it came before initFocus().
As a bonus, the user will now see the below-horizon view rendered before the message box appears, so they can make a more informed decision about resetting or not...
This fixes the most obvious issues with the tile downloading.
The only real other issue left is speed: We need to improve the HttpDownloadManager to have better algorithms to better prioritize the currently needed tiles.
- Fix what is probably Marble's most hated bug:
Tiles being "stuck". The culprit: when a new tile was successfully downloaded and the temporary "replacement" tile was still in the cache, that replacement tile should have gotten removed from the cache to make way for the real one.
- Increase number of activated downloads to hopefully get the speed a little bit up
when going back in history apply the keyboard focus to the the previously shown directory
Fix "Show 'New Tab' and 'Close Tab' buttons on tab bar" setting not being applied correctly on startup.
Test for the tab bar being explicitly hidden with isHidden() rather than just isVisible() which will return true if the setting is applied before the container widget is shown.
Fix a KJS crash on gmail.
The problem was that in some cases, such as event evaluation (which is a function context with callingContext being the globalExec) we would break the chain of active execStates.
That meant we couldn't update them right when moving the stack due to expansion (It also means that they won't get marked sometimes.
Good thing I didn't put in smarter stack code that never puts in things yet --- otherwise it would take 3 days to debug instead of half a day)
Don't crash when replying to HTML mail.
At least on OSX and Windows the job can't be accessed after the nested event loop returns, as the primary event loop will be entered from quit(), which processes delete events (from deleteLater()) which nukes the job.
Cache the audit log in the executor to work around this.
Scary problem, this is probably relied upon a lot, with KJobs all over the place.
Handle mimetypes properly when exporting images.
I consider wish #113014 implemented now.
Fix runaround-policy "No Runaround" to work properly.
Details: When a no-runaround frame intersects with a textframe the proper behavior is to suspend text layout for the whole intersection.
The previous implementation would suspend text layout for the entire frame, which could cause infinite layout-loops.
Bugfix: In a multi-soundcard scenario it was not possible to configure the Views independently (e.g. PCM hidden for ALL Views or shown for ALL Views).
KMix in KDE4.0 wrote wrong group names like [View.Base.Base.Front:0], with a duplicated "Base" which should have been the SoundcardId, like in [View.Base.ALSA::HDA_NVidia:1.Front:0]. Workaround: If found, write back correct group name.
After all Views are filled, delete all bad groups.
remove hydrogen's stuff
Removed Hydrogen's hack which was supposed to make the Progress-Slider smooth; this hack could never have worked correctly.
Instead, I made it so that the engine sends out timer ticks with a shorter interval, which gives us more precision, and it also eliminates the weird bugs.
Additionally I made the code simpler and cleaner.
Fix a bug in trunk causing JuK to close (not crash although that's what it looks like) when:
* JuK is closed to system tray
* You click on the cover in the track announcement popup, and
* You close the big cover that pops up.
In this situation, Qt thinks that the "last window" has closed and quit()s JuK.
Fix bug 144427 (JuK crashes if main window open on logout) in KDE 4.0.
I was not able to reproduce but the reporter did a very good job of hunting down the cause and came up with a patch which I tweaked to fix the underlying issue. Basically, we do too much in queryExit().
We already had a slot called slotAboutToQuit() (which was similarly mislabeled) so I used the "official" means of hooking up to QCoreApplication::aboutToQuit(), and implemented the reporter's patch of setting the deleted object to 0 in case we try to delete it again somehow.
Forgot to backport this to KDE 3.5, which is what bug 144427 was reported against.
The bug report was so useful that I want to reward the reporter so if you're still using 3.5, it should crash less now.
* duplicate options regarding default route removed
* auth type on ipsec import fixed
* default section type handling fixed
* translation updates
* use network option added
* psk secrets file fixed on ipsec import
* option for open profile manager after import added
* option for ipsec vpn mode (transport/tunnel) added
* cert path on ipsec import fixed
* private key on ipsec import fixed
* debug options in preferences dialog fixedhttp proxy options in preferences dialog fixed
Make level 8 a lot easier
* Add explanatory label in "Measure" tab
* When saving, set default extension to .cml
* Much more helpful error messageboxes when saving fails.
* Disable zoom eyecandy
* Remove Help button (sorry Joh, it was great in 4.0 but with the much expanded feature set in 4.1, that material now makes much more sense to have in a separate handbook. SVN remembers the text that you wrote, which is still a great starting point for that handbook section).
Parleypractice now loads from vocab files and has a "show answer" button (which is the beginning on a Hint framework)
* Make the interface prettier (it's improving...)
** Spacing, perhaps?
** Statistical summary dialog on quit
This starts the implementation of some of the API objects needed, like App, Console, Data, Document, Field, FullScreen, Spell, Util.
Also, workaround the fact that we cannot change the read-only status for form fields.
Interface Haar calculation with database.
Methods accept filename, imageid, with preloaded QImage or DImg.
The obtained Haar::SignatureData is serialized into a QByteArray (class DatabaseBlob does that with the help of QDataStream) and written into the ImageHaarMatrix table.
Modification data and unique hash from the Images table (identifying the current file) are copied to the table.
The original paper suggests a data structure where (for each color channel, for positive and negative) for each pixel a list contains those imageids that have a significant coefficient at that place. Such a structure requires pre-reading and approx. 5MB/10,000 images.
The current approach here does it the other way round.
It reads each sigle signature from the database, goes through its list of pixels with significant coefficient, and looks if the query signature has significant coefs as well at that pixel.
A simple benchmark searches 750*133 images (->100,000) in three seconds on my (relatively slow) machine.
Of course, I may have introduced bugs, which will show up once we have a GUI for creating searches. (searching for identical images works)
kipi-plugins from KDE3 branch : several improvements into FlickrExport tool:
- added support RAW files: embeded JPEG preview is used to export RAW image to Flickr
- all others image formats supported by Qt are properlly drived now. The uploaded image is always converted to JPEG. Uploading work with previous implementation _only_ if image been resized.
- plugin dialog layout rewritten. more suitable.
kipi-plugins from KDE3 branch : FlickrExport tool : UTF-8 support
- Use KURL to host addPhoto url
- new method to compute MD5 signature based on KURL.
I have tested to upload photo using accentuate char from Tags or comments.
Now all work fine.
Full parsing of doctype by the HTML Tokenizer
patch by Gustaw Smolarczy, improving upon a webkit patch.
slightly modified to provide a turnaround for broken behaviour of KHTMLPart::write() noticed by Gustaw.
Fixing Acid 3's 18th test.
Add a command-line option --force-transparency which enables support for transparency even if no compositing manager is running when Konsole is started.
* complete attention blinking implementation; not configurable, but that would be a feature rather than a regression fix
* move out the static items, put them in the applet class and use that between all items.
* disable the fade in/out animations for now as they are way to slow atm =/
we really need to do some profiling of this code as it feels rather slow now, and it should be very snappy
Before we make a contaiment out of it (are we going to make it for 4.1 with the freeze?), and we're able to choose it, at least add an option to make folderview's background transparent, so it doesn't hurt your eyes. ;-)
Not sure about what doing by default, but I guess I'll keep it opaque (as it is now), so people understand that is a plasmoid.
ACK'd on review board by logixoul.
Add item part namespaces.
This is necessary to distinguish between remote parts that can be retrieved from the resource (payload) and local parts (attributes), which again is necessary to finally implement all the fetch modes advertised in ItemFetchScope.
Existing data should be converted correctly, but you need to update the server as well as the client library.
* Ladies and getleman: introducing the HTTPStream class, wrapping shttpd_printf call and allowing me to avoid:
- shttpd_printf(arg, "%s", string) all around in the code
- sending HTTP headers everytime I want to output something
- having to write arg->flags |= SHTTPD_END_OF_OUTPUT
* typedef struct shttpd_arg Request (hides shttpd_arg data type)
* removed some bits of code used for testing
Lots of work on the new background.
* Push rendering the background down to the MainWindow and make everything else transparent to make it shine through
* Add a few custom widget subclasses that do not render anything themselves
* Remove rendering of the backgronud from other widgets
This commit represents work in progress and there is still some serious wonkyness ( if that is not already a word, I hereby declare myself the inventor ) going on with the context view, and lots of dead code that I need to remove.
* mschap auth selection added (pptp)
* mschap-v2 auth selection added (pptp)
* option for disabling ipx added (pptp)
* option for disabling tcp header compression added (pptp)
* option for disabling magic number negotiation added (pptp)
* option for disabling protocol field compression added (pptp)option for disabling address/control compression added (pptp)
* lzo compression is now disabled by default (openvpn)
* psk fixed at openvpn config file import fixed
* authentication algorithm fixed (openvpn)
* automatic auth inconsistency fix fixedfinal picture in profilewizward added
- Use all three mouse buttons for different types of toggles (lmb: undefined/on/off mmb: undefined/off rmb: undefined/on)
- GUI deuglification: (some) colors and number positioning
- SOME changes in datastructure:
- prepare for multicolored games
- store _state_ of grid entries in addition to color
- be able to convert hints (list of numbers) to QString for serialization
Optimizations to the import-structure stuff:
- Allow doing "temporary" imports, which is imports that are not recursively propagated into importers(needed in C++).
- Do not maintain the shortest path for now, it's too slow in very complicated cases. Any path is ok.
- Do not compute the recursive imports until they are requested for the first time. This saves us from expensive computations where it's not needed.
- Add mechanisms to import and unimport multiple contexts at a time, for speedup.
All this stuff has a test in kdevelop, and it still succeeds.
- Move the thread-priority setting into the preprocess-job, so it's done earlier.
- Do less importing of contexts in cppparsejob, and flag temporary imports as such using a new flag.
- Add temporary imports using the new mechanism for that added to TopDUContext.
Together with the patches to TopDUContext, this greatly reduces the bottleneck in that area, so far that we can now start worrying about other stuff like memory-usage again.
Improve performance when rendering CSS opacity layers, by using CompositionMode_DestinationIn to reduce the alpha of the layers before rendering them, instead of using QPainter::setOpacity().
With this change we no longer end up in QPainterPrivate::draw_helper(), and the rendering is fully accelerated in hardware with drivers that accelerate Xrender.
Noticed when debugging why KJS is ~7% slower with g++-4.3.1-pre than with 4.2.3:
When doing immediate number -> value conversion that can't result in an immediate value, we don't have to check whether it fits into immediate again at runtime, so can just use jsNumberCell and saves some cycles.
obvious optimization that occurred to me while standing up to go make dinner: now only actually new match results will get traversed twice, and then only when there are existing items that haven't been claimed yet.
in practice this is rare, so this is nearly as efficient as the original algo and may well be an even call now without the updateId stuff.
Avoid going through the whole toString-property-lookup-deal when converting a object value to a UString, when the programmer isn't certifiably insane (AKA when toString on strings isn't customized)
This is about a 1% speedup on SunSpider, primarily because it reduces GC heap allocations by 2.35%
_Greatly_ optimize rendering by not repainting the _entire_ main window background if just a little part of it ( such as the part below the slider in the toolbar ) changes.
Interestingly enough, this brings back to life the "stitch the background together" code that I all but discarded yesterday.
if we look up a feature, and of the known providers it is only supported by the default provider, don't go scanning the drive to see if there's a plugin to take precedence.
this optimizes usage of built-in features, so that if there's no plugin present for, say, "sha1", the qca app won't hit the disk drive every single time it is invoked just to see if a plugin supporting "sha1" has appeared.
the drawback is that if you want a plugin to take precedence over the default provider, then it needs to be installed before the application is run (or, the app can use QCA::scanForPlugins during runtime, to force the plugin to get noticed).
· - make use of new settings model in KXSLDbg
· - provide a KControl configuration dialog (not compiled nor used for KDE 4.1)
· - refactor how outputmodel is created
· - remove redundant configuration dialog implementation
- bug/bug fixes
· - correct how the KXSLDdg toolview is shown in Quanta
· - correct the declations/implmentation of KDevKXSLDbgViewFactory functions (add virtual keyword as required)
· - add missing xsldbg-source icon for "Run .. KXSLDbg" menu
· - hide the KXSLDdbg tool bar items if KXSLDbg is not ready to run
· - the menu item "Run .. KXSLDbg" now acutally starts/stops KXSLDbg as intended
· - correctly load/save configuration when "Run .. KXSLDbg" menu item is used
Remove the ugliest hack in the world. David if you find that an API doesn't work the way you need it to, you shouldn't use it. #define private public is not acceptable in KDevelop codebase.
Also disable teamwork as it now won't compile anymore, as soon as a maintainer steps up to fix this it can be re-enabled.
Parleypractice is now entirely seperate from Parley proper (a different cmake project) and right now has a basic QString-based question and answer test working.
I'm using WoC for everything; I think this will give me a lot of flexibility later on.
Thanks to some help from #kde-devel and jpwhiting, I got inheritance of the eduwidgets from both the interfaces and the qwidgets working without Qt complaining.
TODO in the near future:
* Get question/answer sets loading (the test questions are hardcoded atm ;) )
* Play with SVGs some
* Make the test application prettier (its really rough right now)
* Implement the Hint EduWidget
First SoC commit!
- Given that the previous OSM tile shipped with Marble was licensed under the Creative Commons Attribution-ShareAlike 2.0 license and given that Debian doesn't approve this license as a "free" license we replace the very low resolution tile by a simple blue square for now.
Later on we'll add a public domain map in the style of the original OSM tile.
* guard slightly beter in the hover against invalid indexes
* don't flicker the current desktop
* remove some unused variables
* don't talk about "panels" in comments. one should be thinking about containmnets, not panels
this code could really use a good scrubbing. it's a little crufty in places.
Commit to beat the feature freeze :-)
Add new tabs to QPrintDialog to set CUPS printing options. This includes n-up printing, page borders, banner pages, mirror pages, and job scheduling.
This change requires the final release version of Qt4.4 as it relies on a patch not present in the RC or betas. The tabs will also only appear in apps that call KDEPrint::createPrintDialog to obtain a QPrintDialog (I'll be fixing most apps that don't currently do so).
What doesn't work: the CUPS detection routine needs more work, and the Job Options table is a bit crashy, but everything else should be fine. Oh, and the ugly n-up icons (borrowed from KDE3) need replacing in the style and size of the existing Qt Colour Mode icons (see options tab).
Memo to self: Now I must send Danny the promised article...
opening the desktop toolbox on hover was never going to work perfectly, and would be a bit of a problem for touchscreens (they make the mouse jump instead of moving smoothly) - so it no longer happens.
the toolbox just lights up on hover now, and opens on click. it still closes on the hover leave event, though.
this makes the code a lot less hackish and should produce the least frustrating behaviour possible.
it's also a bit more like the panel cashew behaviour.
in the kde-core-devel thread "Kubuntu Settings in KDE" Riddell suggested setting NoDisplay=true on systemsettings.desktop, to prevent it appearing twice in the Computer tab, and in the Applications tab.
This solution goes too far, because you then cannot find the app with the search tool.
This patch adapts the Applications tab to ignore any apps that are configured to appear in the System tab, using a new static method in the Kickoff namespace to obtain the list in both System and Applications models.
Remove close buttons on individual tabs and replace with a single close button on the right of the tab bar when the "Show 'New Tab' and 'Close Tab' buttons on tab bar" option is enabled - which brings tab management back to the way it was in KDE 3.
Several users (esp. those working with laptop trackpads) were having problems with accidentally closing tabs.
It seems KTabBar's close buttons need some refinements before they can be used in the terminal.
Move handling of "Open With" actions from KonqPopupMenu to KonqMenuActions, for more code sharing with dolphin.
Move info about the items related to the popupmenu to KonqPopupMenuInformation, to share this between KonqPopupMenu, KonqMenuActions and the upcoming plugin support resurrection.
Steal some code from applethandle.cpp (I typed it by myself, I only looked there, honestly! ;))
Use Plasma::View to show notifications widget in a toplevel window.
View doesn't track widget's size changes so it quickly becomes ugly on any new notification :-P
kdebase shouldn't depend on stuff in kdemultimedia and extragear.
Instead, we use our own copy of the xml descriptions of the dbus interfaces, which seems reasonable - these interfaces (or, at least, the small subset nowplaying uses) should be pretty stable, and a change in the interface shouldn't cause more trouble than nowplaying no longer supporting them.
- Applet rewrite (clean build recommended, or just removing the .desktop file and the plug-in library file since the name
of the plug-in (applet) has changed
- Added a new widget - HoverIcon
- Configuration switched to the new framework in plasma
Initial commit of new MSWord-to-ODF filter.
I didn't enable it in cmake yet - just add the msword-odf directory in the same place as the other msword directory in CMakeLists.txt if you want to use it.
This code should compile and produce an ODT with the text from the .doc, but it's not formatted at all.
That's next on the list.
There's also a lot of commented-out code from the other filter, which can eventually be removed.
Improve crossfading in JuK trunk to not sound like a catastrophe for the first half second. I think the order of inserting effects into the audio path has something to do with it, so I've reordered everything to be ready before starting the next track.
In addition you shouldn't get huge volume jumps when crossfading rapidly and I've improved the memory allocation lifetimes.
Unfortunately you still sometimes get a bit of high-volume at the beginning of the next track but I don't think that is juk's fault.
Nev background element from leeo. I changed the highligts from using white to using the "Base" color from the palette.
This is white in many cases, but for very dark themes it is usually not.
This makes the highligts much more subtle on dark themes.
Now I just need to find that touch of color I keep ranting about.
Import of the new GameStorage classes.
In the next days, these will replace most of the current storage logic.
The new GameStorage is designed to be flexible and lightweight, to be eventually moved to libkdegames in case that other game programmers are interested in using this framework.