|
Heavy refactoring and work on merging translation branches in Lokalize (which is renamed from "Kaider", and moved from playground to kdesdk). Work on a question editor in KEduca. Work on real-time cloud imagery in Marble. An initial implementation of a new undo stack in KWordQuiz. The start of a KAlgebra, Rot13, KWorldClock, and Pastebin Plasma applet, with the inclusion of more functionality from KDE 3.5 (such as the multi-row taskbar panel) in Plasma. Progress in scripting support and functionality in Plasma. The "Now Playing" data engine and applet, and the fuzzy-clock Plasma applet move into kdereview. Viewports support declared "complete" on the KDE desktop. "FlipSwitch" window-switching effect in KWin. The start of a KIO slave for handling arbitrary NEPOMUK resources. Draft implementation of a KABC resource based on Akonadi. Wholesale merges from the enterprise branch of KDE-PIM back into the main KDE branch. Move to complete support for the MPRIS media player interaction standard, and support for Video CD's and Audio CD's in Dragon Player. Dragon Player moves from kdereview into kdemultimedia for KDE 4.1. Last.fm streaming radio now works in Amarok 2. Work on gradient editing in Karbon. The Kooka scanning application finds a new maintainer, with various initial improvements. KSystemLog moves from playground into kdereview. Krone, a simple expense manager for KDE 4, is added to KDE SVN.
|
New KDE developer Martin Graesslin introduces a new KWin effect, "FlipSwitch", which models a window-switching effect seen in Windows Vista:
|
At the University I attend, I am enrolled in an OpenGL computer graphics course, and so I learned the basics of OpenGL programming. With the upcoming KDE 4.0 release, I thought about trying to see if I could write a small effect for KDE. This was around Christmas - I was missing the "seasons" effect. So, inspired by Compiz Fusion's Snow Effect, I implemented this effect for KDE.
This effect uses OpenGL, but there is no 3D animation. So I thought about trying to implement something that is really 3D. I got the idea to implement something like Windows Vista's Flip 3D (I have never seen this effect properly, so I don't know how close my effect is :)). That is, all windows are displayed on a three dimensional stack and rotated so that all windows can be seen (at least a small part of each). If you switch the window, the next or previous window will appear on top of the stack. In fact the whole stack is moved.
The most difficult part of the implementation was the third dimension. As far as I know, all existing effects are only 2D. So I could not just copy and paste. It was a lot of trial and error. Finally I had some working code. The windows appeared in the frustum, and moved along the z-axis. From that point on I could rely on the methods I learned in the OpenGL course: move every window to the correct position with glTranslatef() and rotate it with glRotatef(). The next step was to animate the whole scene. This is quite simple, as you can just move the whole scene with the help of glTranslatef(). So if you press Alt+Tab each window "flies" to the next position.
Writing this effect was mainly practice for my OpenGL course. But I am also glad to be able to give something to the community after taking for so long! I hope to find time to write some more fancy effects and to help make KDE even better :)
|
|
Sebastian Trueg writes an update on K3b for KDE 4 (pre-alpha, but running):
|
Porting to K3b has progressed quite a lot these last days. After Laurent Montel (the KDE4 porting machine) did all the heavy lifting, including making it compile and porting almost the complete build system (great work, Laurent!) I started to make K3b work again. And a lot of stuff already does.
K3b still makes heavy use of kdes3support though. This mainly includes all the listviews and K3Process. The latter will be hard to port, since K3b directly links the stdout and stdin file descriptors of processes such as mkisofs and cdrecord to gain maximum performance when piping data during on-the-fly burning. With QProcess there is no way to access the file descriptors directly (at least no portable one as far as I know). Thus, I would have to do a lot of signal-slotting since there is also no way to use QProcess synchronously in a multi-threaded application. I would love to get some good ideas on this topic.
One thing I think is pretty cool and could even go into kdelibs is my K3bMetaItemModel which merges multiple QAbstractItemModels into one. You can see in action in the K3b screenshot recreating the good old places file tree, including the devices. I actually think a places view like this should also go into Dolphin or Konqueror. At least home and root could be merged properly like this. Anyway, I think it is nice and useful.
Another thing in the current K3b trunk is the complete change of the K3b plugin system. It used to have its own implementation (whilst now I use proper KServices), and the configure widgets are KCM modules which means I can use Rafael Fernández López's awesome plugin configure view. He already promised to make the checkboxes optional, since in K3b you cannot disable plugins. Anyway, it looks nice, works great, and prevents a lot of code duplication.
Last but not least, we have a look at one of the action dialogs just to show that they work again. Now while this may seem like no big thing, you should have seen how it looked before it was ported properly to KDialog, the new QComboBox, and the new QWidget background behaviour!
All in all, porting K3b to KDE 4 is mostly mind-numbing work consisting of fixing compile errors, then fixing crashes, then making it actually do what it should do, and finally to remove any trace of kde3support. But sometimes it is fun, too, for example when implementing the K3bMetaItemModel, or when I can reuse many cool new KDE technologies. Solid comes to mind, although K3b does not make much use of it since it has its own device detection that is optimized for optical devices and gathers much more information than Solid does (Kévin Ottens, I know we talked about this a long while ago, but what can I say: I was lazy in this regard. ;)
By the way, I could use some help on the porting. I think there are even a lot of small things which can be considered JJs. Some small things come to mind: port the audio output system to Phonon, make the K3bDeviceDelegate paint nicer devices in the file tree, extract all the nice KFileItemDelegate goodness including animated hovering and put it into a generic KItemDelegate to be reused for the devices (and many more items throughout KDE for that matter), and so on...
|
|
|
|
Development Tools |
|
David Nolden committed changes in /trunk/KDE/kdevelop/languages/cpp:
|
- Correctly manage macro-blocks, deleting them when they aren't needed any more.
- Fix a bug in the environment-manager, which makes it more correct. However this increases memory-usage by creating more contexts, so we will need more optimization
- With simplified environment-matching enabled, correctly support files that define completely different content depending on a macro in the header-section, by tracking the preprocessor branching-hash while creating the content-context.
- Add a test for this to test_cppcodecompletion.
- Share include-path lists to save some memory
- Store the content start-line(behind includes) in environment-files. This will give us a place to automatically add new includes, definitions, etc. |
|
|
|
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/optimise)
![[*]](/images/standard/other)