11th March 2007by Danny Allen
I actually haven't made any big feature commits since the original port - a few fixes for bugs in my code, and a few small changes, but that's it. I have, however, filled up about half a notebook with scribles on different ways to add different things. I've finally settled on how I want to implement everything, and the first commit might come through within a couple of weeks (please don't hold me to that - schoolwork might get in the way).
When I started, KSpaceDuel was already ported to KDE 4, it just didn't use SVG graphics yet. I wrote the SVG patch over a couple of afternoons (the first day was actually spent doing API documentation, so it was a one-afternoon patch). The engine already used QGraphicsView and QGraphicsPixmapItem, so all I had to do was switch it to QGraphicsSvgItem (but don't tell anyone that - they all still think it must have been hard to port to SVG :-P). I'm pretty sure that Dirk Rathlev did the original KDE 4 port of the game. You should really talk to him, too, since he was sort of the unofficial maintainer for a while.
My list is mostly short-term stuff. Sound, multiplayer, and savable configurations are all things I want to get in before KDE 4.0. Creating new areas of space will probably require a lot of work on the physics and AI - the two most important parts of the game, actually. I don't want to mess with them until I really know what I'm doing. So that will be more long-term, possibly KDE 4.0 though, depending on how long the rest of KDE 4 takes to get ready.
KSpaceDuel is actually really fun to work with. The code is very clean and organized, and most of it is well-commented. My issues now are mostly about learning APIs, not fighting with the way KSpaceDuel is designed. I need to learn Phonon, GGZ, and some of the more advanced KConfig features before I can get back to coding. I think I've just about figured out all the multi-configuration stuff, but it's still going to be a pain to code. Until I have a chance to do a couple of test apps, I'm putting that on the back burner. Sound first, then GGZ, then back to the configuration stuff.
KSpaceDuel is actually my first real KDE development experience. I've done some small code tweaks on my own system, but I've never actually submitted any patches to KDE before taking over KSpaceDuel. It's a pretty awesome feeling being involved in the coolest GUI project on the planet.
In Japan, it is referred to as Gomoku (or freestyle Gomoku), where for centuries it has been played on a Go board. This name seems to be the dominating English name as well, but other names I have seen are Connect Five, X and O's and Five in a Row. In German it is called "Fünf-in-eine-Reihe" and in Swedish it is either "Luffarschack", "Fem-i-rad" or "X&O". In Europe, it is mainly played with pen and paper.
The game rules are rather simple. X starts (in Japan, "black" starts) to place his mark. A placed mark cannot be moved and nobody can place a mark on top of an already-placed mark. The two players take turns to place their marks and eventually one of them will have connected five marks in a line and thus wins.
I developed the AI code in Java some years ago as my examination task from the Swedish "gymansium" school (Upper Secondary School). Since I haven't had anyone to play with since then, I decided to port it to KDE 4, partly so I could play it against the computer, and partly to refresh my Qt 4 skills.
Before a release, I would like to introduce theme support in the already-present SVG rendering, thus allowing both European and Japanese variants. Also, I would like to clean up the rendering code, making it faster and less memory demanding. As the game is unbalanced (i.e. whoever starts is guaranteed to win rather quickly with "perfect play") I would also like it to alternate whether the AI or the human starts, to make it "equal". Furthermore, I would like to kidnap an artist and blackmail him for some decent artwork. However, the game is already fully complete, so I could at any time check out the Subversion repository and release that as version 1.0.
In the long term, I have planned to add an adaptive AI mode to the game. This means that the game adapts itself to the skill of the human player, so it is always challenging but never "impossible". Also, I'd like it to be included in KDE 4.0 :)
Personally, I started monitoring KDE mailing lists five years ago, hoping to start contributing. But I always hid beneath the protective laziness of Java, which I perceived as a more convenient language. A year ago, I decided to learn C++, so I enrolled in a university course and worked a lot with Qt 4 during my Google Summer of Code project. The past winter I worked part-time as a C++ laboratory supervisor at my university and a few weeks ago I got re-involved in KDE. Mainly with this project, but I have something a lot more complex hiding on my hard drive ;). Though I doubt I will ever finish that (unless I am somehow paid to work full-time on it for a month or two). Still, I consider myself a KDE junior developer.
If anyone has any more questions, come and talk to me! I'm lurking in #kdegames and #kde4-devel on irc.freenode.net most of the time (alias 'hrafnahnef').
Marble is a generic geographical widget providing a globe that people can browse the world with. I recently added support for co-ordinate grids and initial Wikipedia integration. I also started ways to measure distances between placemarks. Some recent screenshots:
I'm currently aiming for a move to the kdereview module within the next 10 days and a move into kde-edu (right in time for KDE 4.0) once the review weeks have passed.
By that time, Marble should have also basic KDE-ification which would include the following extra functionality:
- saving maps (in PNG)
- printing maps
- copying maps to the clipboard
- proper documentation
- proper CMake inclusion
This would still be right in time for a possible feature freeze on May 2nd and offer enough time to solve remaining issues and take delays into account.
I already talked with Albert Astals Cid of KGeography in the past about possible sharing of funcionality between the two applications in the future to varying extents. Whatever the solution will look like, I personally think that this can only be fully addressed after KDE 4.0 has been released. Currently, KGeography uses bitmaps imagery to store and display data, which is pretty inefficient in terms of flexibility as well as filesize. Marble uses a smart combination of vectors and bitmaps, which basically offers improved quality for the maps, better accuracy, more flexibility and all this at much less file space utilisation than KGeography needs to cover the world fully. I consider the availability of a 2 Dimensional view for Marble an additional requirement to merge functionality. And this feature won't be implemented earlier than the Google Summer of Code 2007, for which I offer my mentorship.
So that's one of the reasons why merging functionality between KGeography and Marble in some way will likely have to wait until KDE 4.1.
if you svn up the playground/artwork/Oxygen dir, don't have a heart attack. the icons are now in kdelibs. please commit final work there from now on.
we still need to work out a few issues including:
- generating new png's from the svg's
- porting of the code base
- i have patches for libs and base already together and apparently a few others are also done?
*pops the champagne*
|Commits||2341 by 210 developers, 4845 lines modified, 1707 new files|
|Bugs Opened||241 in the last 7 days|
|Bugs Closed||272 in the last 7 days|
|Aaron J. Seigo||
Internationalization (i18n) Status
|British English (en_GB)||
Bug Killers and Buzz
|Albert Astals Cid||
|Adriaan de Groot||
|Aaron J. Seigo||
There are 148 selections this week
Bring language support infrastructure back to KDevelop4.
The new language support framework is modelled after project management architecture we have already with following components:
- LanguageController to load languages when code files are activated
- Language - the class to represent particular language (in the future with common stuff like background parser, etc.)
- ILanguageSupport - the extension interface to be implemented by actual language support parts
The main features of this framework:
- as many language supports as necessary may be loaded at the same time
- language supports are loaded on demand (depending on the mimetype of current file)
- several language supports can be activated for the current file (useful for mixed-source stuff like html+php, html+ruby, c+sql, doxygen+c++, etc.)
Allow plugins to depend on other plugins by providing their X-KDE-PluginInfo-Name.
IMHO this is better than creating multiple equally looking extension interfaces.
This is needed for example to have the QMake support depend on a QMake Builder without the need of a special QMakeBuilder extension interface that would mostly look like the IProjectBuilder one.
Apply attachment 19873 from Antoine Dopffer:
> This patch creates a new dialog for collecting the "Import project" params
> (directory and programming language) and searching the files that match the
> This patch works for me but: It uses features that exists only in QT4
I.e. this feature will be available in the KDE4 based Umbrello 2.0 release.
quick document switcher, default shortcut CTRL+1.
While entering text in the text field the document names and document urls are searched for matching text.
While entering text in the text field key_up and key_down navigate the listview.
If the list view has the focus everyting except key_up, key_down is redirected to the text box.
If the dialog is left with accept the plugin switches the view to the document selected in the list view.
This makes switching between documents easier, if there are a lot of them open
avoid flicker when changing the active document.
the qt4 documentation claims that using mainWindow()->toolBar()->setUpdatesEnabled (false); is enough, but in practice, we need to disable painting on the window, hide the toolbar, do the "drawing" and then show the toolbar again, and enable painting on the main window.
i also fixed some indentation problems with this function.
Bring c++ parsing and duchain creation back:
- resurrected all features of c++ lang support except for code model
- added convenience method to IProject interface to get a item for a file and another one to get a list of files
- added convenience method to IProjectController interface to get a list of projects
- added parse mutexes to ILanguage/Language (they were in disabled KDevLanguageSupport)
- reenabled parse job creation and running
Make New lesson button work.
Delete all <no lesson> stuff in favor of adding vocabulary without a lesson to "Default lesson". This should still be compatible with all old files and old versions will still be able to read the files.
Because the <no lesson> is away KVTLessonModel no longer needs an internal lesson list but is again directly using the data from m_doc.
KVTLessonView now has a slot to add a new lesson. The old way still works (property dialog) but currently does not update the lessonview.
digikam from trunk : first approach to use a blending level to merge coloring taint in red eyes correction tool. level hardcoded to 64 give good result, but a clean tool dialog with a slider and a preview look better to set this parameter to the right value.
Photographers : please, i need pictures with Red Eyes face to test. Please send me some samples files by private mail (caulier dot gilles at gmail dot com). Thanks in advance...
digikam from trunk : "Et voilà..." The new digiKam 0.9.2 Red Eyes correction tool is complete and ready to use. With this commit, There is a new slider to set the Red Color Threshold adjustment.
The screenshot is updated:
- Provide digikamalbums:// URLs to KIO::del
This reliably removes the entries from the database.
It usually worked before because the KDirWatch would trigger a rescan,
but under certain conditions (saved as and then deleted immediately) it did not work.
- In AlbumIconView, move the KIconEffect::visualActivate to the click action. This is more homogenous: It is now associated with a click on an icon, regardless if for preview or image editor.
digikam from trunk : Solarize plugin is now a "Color Effects" tools pack witch include :
- Solarize Photograph.
- Simulate Velvia Color Film (Vivid Saturation).
- Simulate Neon light.
- Color Edge detection.
Future others Color algorithm will be add to this plugin. No need to create new one.
Start to fix internal highlighting code - it used different path to the external highlighting. Now there is still a delay to first draw issue, but I'm not sure what's causing that yet.
Change the search highlighting code to use an all-encompassing range.
Not sure why this was required (or even if it is any more). Might be related to the above issue.
Seems that we have to watch all highlighted ranges rather than just dynamically highlighted ones (much easier, and hopefully not really any slower)
Also add a few signals to the code completion + implement.
A notification about logout canceled by some application ... usually one of those broken ones like Skype (<a href="http://websvn.kde.org/?rev=627435">r627435</a></a> from trunk).
* New approach to handling scrolling views on the same session independently. Added ScreenWindow class which represents a window onto a terminal screen. Each terminal view has one screen window associated with it.
This breaks the original design choice of not having the view know anything about the session it was displaying, but I feel that no longer makes sense when there is more than one view on a session.
* Add methods to support tooltips in filters
* Add start of new history size dialog which I hope is easier to understand.
* Internal renaming for clarity
ca -> Character
cacol -> CharacterColor
CO_XYZ -> COLOR_SPACE_XYZ
ca.c -> ca.character
ca.r -> ca.rendition
ca.f -> ca.foregroundColor
ca.b -> ca.backgroundColor
* Ported KMetaData to the basic Nepomuk annotation ontology NAO. This ontology is still not final but close.
* Added the Nepomuk Information Element Ontology NIE which provides file and emails and stuff (this one is even further away from being final but we need elements such as files and emails and maybe this allows people to comment and add their properties.
* Added support for pseudo-multi-inheritance, ie. generated classes get converter methods for their parent types if they have more than one. Sadly we cannot use real multi-inheritance since everything is derived
By default, honor umask of the user when saving attachments, but offer a config entry (without user interface) for those who explicitely don't like that ([General] section, disregardUmask boolean)
Re-edit shape up.
* Improvements on signature handling.
* Composer auto selects the proper identity on re-edit.
* Re-edit includes the InReplyTo header. (Closes Bug 142652)
* We now include the signature used to sign the message in a message header when messages are saved as drafts. These headers are used to replace the existing signature with the new one, when using more than one mailody client to access the saved drafts, in situations where the identity/signature settings are unavailable.
Make the layout style configurable and implement another style, namely Grid.
Now there's GuiHandler::Vertical which will add the labels above the widgets of the elements (just as it was before) and GuiHandler::Grid, which will put the labels at the left and the widgets at the rigth, properly aligned in a grid.
That makes the whole GUI more appealing, usable and prefessional.
Change the way collections are represented in the server, based on what we discussed in Osnabrueck:
- use a numeric unique id to identify collections
- the collection hierarchy is now explicitly defined by the parent collection id instead implicitly by the path
Most of the interface is not yet changed, HandlerHelper contains two methods to convert between the old path-representation and the ids.
There is also a new FETCH-like collection list command (AKLIST), which is incompatible to IMAP's LIST, but much more suitable for our needs.
Yesterday casper said something on IRC, he said that you can't put document-DPI zoom in the zoom manager. I thought a little about it and it struck me that we've been attacking this rasterizing of flake-shapes from the wrong angle.
The viewConverter for this special case is to convert from flake-internal to krita-internal. Meaning that (user)zoom-level is irrelevant. Only the image-wide DPI is relevant.
After that it was a simple task of writing a new implementation of the KoViewConverter interface based on that, and we're set.
This fixes a design error in the layer box.
Dockers will outlive their views if the mainwindow is reused for anothe document, for example by loading another document into it. So don't use a pointer to the view in the docker.
This again allows you to close the document and open a different one.
add the general program editor (remains to do: renaming the program, make the add and delete buttons useful)
add the ui to create the "dynamic brush" as the paintop optionadd the filters list program editor (remains to do: finish the transform filters's editors)
Implement new feature; autoscroll. For all flake-tools we will scroll the canvas when there are mouse-move events with left button down.
This means that all tools (and apps, naturally) in the whole of koffice now have a nice and consistent feeling way to move the canvas by dragging.
Rebuilt the KisPreviewWidget and updated it's users. It now uses the original image to run the filter on and 'chunks' the processing so the user doesn't get bored. There is a progress widget. most filters work fine with this but I changed KisBlurFilter so it doesn't support threading so the preview looks ok.
Allow for lyrics scripts to work as meta_lyrics scripts, with the ability to specify site, site_url, and add_url as returned paramaters in the fetched lyrics. Still falls back to parameters set in the .spec file.
Patch by Sergio Pistone.
started working on allowing scriptable service items to call a script to populate their child items (instead of having to populate all items at once).
Implemented a very simple version of the shoutcast browser as a script as proof of concept.
Note that this script currently uses a hardcoded callback path.
This commit will most likely be flagged as unsafe due to the calling of the external scripts. :-)
Splitting the service browser into two seperate tabs, Stores and Internet Content. Both are Service browsers, one containins the Magnatune store and the other (it is not empty, it only appears that way to the uninitiated) contains the scriptableServiceManager and will show any services added by scripts and any other stuff we deem should be moved here
* added the temp optional option "usekross" to be able to switch easy between the original python and the Kross scripting backends. E.g. "superkaramba --usekross aero_aio.theme" to use Kross or "superkaramba aero_aio.theme" to use the old engine.
* d-pointer for the KarambaInterface class
* moved the connect's and the sys.path hacks from the scripts into the KarambaInterface class. Afoto und Aero should run without any change with Kross now.
* seems KarambaWithKrossPython does leak mem :-/ TODO for next days.
Woho! Fix odd bug in the replay. QTimer and signal/slots was far more gutty than I had hoped them to be. But, now I think I have learned how to use them as well. (Sometimes in very rare circumstances you really miss Java. Last two hours spent could have been as simple as "Thread.sleep(700);"...)
Now Replay should work as expected. Furthermore, the replay function isn't activated until GameOver.
Change the start player's color in the settings dialog depending on who really is the start player.
Note: This directly sets the UI buttons in the KConfigDialog which is not really nice and also requires the dialog to be modal.
However, KConfigDialog seems to not allow any other way of changing its elements once it has been shown. Anybody knowing a better solution feel free to improve it.
Speed up Playlist::saveXML by about 40% by writing to the stream directly and careful buffering. The method is critical, as it runs every time the playlist is changed, so improvements here affect overall responsiveness. In my build ~5100 items saves in ~2.2s instead of ~3.6s
Patch by Ovy:
Simplify, speed up AtomicString using QT4 thread safe refcounting.
Simplifications: no more lazy deletes, checking for main thread.
Speed-ups: refcounting is generally outside the store lock now; some methods became trivial and could be inlined easily.
@Ovy: moving the ~AtomicString() definition to the cpp file fixed the linker problem for me.
Okay, this is a pretty intrusive commit.
Basically, I've reworked the system a bit to try and use the cmake variables a little more properly.
First, I've moved the qtdbus headers into header_list and removed the corresponding stuff from the .pl files. We can determine if the QtDbus stuff is installed via cmake now.
Second, I've commented out the call to grab_qglobal_symbols in qtguess.pl.cmake.
I can't see what it's actually helping to do anymore since we can use the compilation test to determine where there are QT_NO or QT_ defines. Moreso, the latest versions of Qt define license information in QT_EDITION variables in qglobal.h, and this subroutine cannot read them properly and parse them. This causes build failures due to errors about "QtLicenseForModule". Not calling this method anymore fixes these errors and doesn't seem to change the overall way things are built as best as I can tell.
Third, all of the headers in header_list have had the prefix directory stripped and I've reverted to the simple .h name. This is because we can grab each of the individual package directories from cmake, and for frameworked directories this makes things nicer.
Fourth, I've recommented out a lot of the excludes in generate.pl.cmake. I've actually been successful in getting smoke to build with some of these headers, so I thought perhaps starting over from scratch would be good here. We can re-uncomment them out as needed.
Last, I've reworked some of the build system items in CMakeLists.txt. This is again to be somewhat smart of how cmake is able to figure out things for us.
I've tested this on OSX (Framework Qt 4.2.2) and Linux (normal Qt-4.2.2) and it builds, compiles, and links on both. That's not to say I didn't make a mistake, or overlook something egregious. Please let me know if I did, hopefully in a nice way.
The Big Unification Commit for the kdev-pg based parsers, respectively their CMakeFiles.
Uses optional dependencies on kdev-pg, kdev-cmg and flex, and falls back to copying from SVN when one of those is not available.
Sorry for making those CMakeFiles so ridiculously big, but I really think I got the best possible build configuration for those parsers now.
Move the Ruby language part into kdevelop4-extra-plugins.
This one is pretty much a plain parser, without any KDevelop integration. Also, because of the complexity of the language, it will probably require other means of code analysis than just making use of the information coming from the parser.
digiKam from trunk : NEWS file is restored. I have created a NEWS.0.9.0 and a NEWS.0.9.1 to be more readable.
The NEWS file is the current implementation report. It will be renamed NEWS.0.9.2 when final release will be done.
To developers : please continue to comments this file with the current implementation from trunk (bugfix from B.K.O and New features). The NEWS file is very important to give a serious developement quality report for end users.
* move enums to exist inside the namespace instead of being global
* Rename enum values to be CamelCase
* Split KoPageFormat and KoPageLayout in individual files
Stop compiling the page-layout widgets since they are too complex for most apps, and since 2.0 not complex enough for kword. So the plan is to make new ones in kword and see if there is something available for reuse afterwards.
The kword page-dialog is a still work-in-progress, doesn't work yet.
Do not antialias the painting of shapes when the DPI of the underlyng image are high enough.
Well, I hope this is what it does as here I always get the image drawn antialiased, so this just theoreticaly removes one of the two antialiassing steps. Not really easy to spot. Hopefully someone on i386 can confirm.