|
A Trash applet, various general improvements, and support for sharing configuration layouts in Plasma. "Undo close tab" feature in Konqueror. Development continues towards Amarok 2.0, with services becoming plugins and support for the Amapche music server. Continued progress in KDevelop and KEduca. More work on album display and improved thumbnails (with RAW format support) in Digikam. A BitTorrent plugin for KGet, based on the recently created libktorrent. Directory monitoring-and-update support in NEPOMUK. Work returns to Okteta, a hex editing utility. "Connection Status" plugin removed from Kopete. Kile begins to be ported to KDE 4, whilst work begins on KGPG2. Goya, a GUI widget framework, is imported into playground.
|
Shawn Starr gives a multimedia overview of the progress of the Plasma Weather data engine and the beginning implementation of the Weather Plasmoid:
|
|
(ensure sound is on to hear the voiceover)
Hello! My name is Shawn and I have produced the Weather Plasmoid for KDE 4. Over the last few weeks, I have been busy making major progress on the Weather Plasmoid, with more changes coming thoughout this month and into the next.
Whilst the Weather Plasmoid will not rival the famous LiquidWeather SuperKaramba applet in the KDE 4.0 timeframe, it should at least rival the KWeather Kicker applet of KDE 3.
If you use imperial instead of metric for your measurements (as set centrally in your KDE configuration), the Weather Plasmoid will display the data in imperial units instead. The measurement of winds in meters per second is not yet functional in the applet but the weather ions (data sources) support this.
With this being my first KDE program, I hope to contribute more for the community and encourage people to send me ideas and possible features for the Weather Plasmoid too!
|
|
Rafael Fernández López introduces a new GUI widget framework, Goya:
|
Goya is a framework for easily adding widgets into itemviews. We could say that on itemviews we have a similar problem that Plasma (QGraphicsView) has/had (Qt 4.4 fixes this for QGraphicsView).
From my experience working with itemviews I found that sometimes it is very helpful to add widgets (for example, checkboxes, radio buttons, push buttons, etc) into itemviews. Such a use case can be seen in the plugin selector, for example.
I had to create lots of workarounds for adding only two buttons into the plugin selector itemview, and it seems that the complexity for adding more widgets becomes almost exponential!
So, I came up with a solution that consists of adding an intermediate layer between the Delegate and the View. I call this solution Goya. This makes it really easy and powerful (you can use signals and slots with Goya widgets) to use standard widgets and add them into itemviews, as the presence of a widget relies on the model, and their position on the Delegate.
Right now, the most important thing is written: Goya itself. You can currently add push buttons and combo boxes. I developed these for testing the framework, and they work very nicely. I will add other widgets very soon, for example checkboxes and radio buttons. Currently, you can also add a line edit, which I added for testing purposes, but it is not usable: you won't be able to scroll or edit text. It will only show a string with the appearance of a line edit.
Goya also tries to minimize memory usage, so if you add a button to all rows on a list view, only one button will be allocated in memory.
The utility of this project will be demonstrated by KPluginSelector, as well as KUIServer (which I plan to code when Goya is finished).
I think that adding widgets (at least push buttons, checkboxes and radio buttons) can be a very common case for itemviews, and for that reason I really think that other applications will benefit from Goya. That is the reason why I created Goya as a library.
The code can be found at http://websvn.kde.org/trunk/playground/libs/goya, and I would love to see it become an established part of KDE 4.1. There you can also find two small tests, where you can see Goya in action.
|
|
Simon St James discusses his new KDE 4 testing initiative, KDE4Daily:
|
Hi all! My name is Simon and I am the creator of the KDE4Daily project, which is my first contribution to KDE! The idea originally came from hanging around in #oxygen and observing that, whenever Nuno Fernades Pinheiro wished to see some changes to the widget style, he would need Ruphy to SSH into his machine and update and compile it for him. I thought things could be a bit more streamlined if Riccardo Iaconelli could somehow just add the changed code to a personal repository and have Nuno update to it automatically, but there were probably binary compatibility problems if they used different distributions which would prove awkward. Since virtualisation offers a way to distribute self-contained installations and have them run on different platforms, I thought this might be a way forward.
A little later I realised that this might be a good way of lowering the barrier for other people who want to try out bleeding-edge KDE but who don't run a distribution that provides up-to-date packages, or don't want to deal with the hassle of compiling. So I ran it past the KDE Promotion team and several people expressed their support for the idea, and so I set to work straight away.
The KDE4-install updater itself is not that sophisticated, technically - each build has all files hashed, and when a file changes between builds, the new version is simply globbed into a big bzip'd file. When the user updates, the list of changes is simply replayed and the replacement files are extracted into the correct places and symlinks are re-arranged, as required. This replaying is designed to be robust, so that if it fails (for whatever reason), it can be restarted without ill-effect and hopefully conclude successfully. While this aspect of the project was reasonably simple, dealing with debugging information was annoyingly difficult.
One of the technical challenges was fixing bugs / implementing features "in the field", as it were, without having to re-upload a brand new torrent, so one of the first things I worked on was a way of deploying script updates to users. Several bug fixes have been transparently slipstreamed in since the torrent was first added.
The debugging info for the KDE modules included in the KDE4Daily install is very big - approximately 512MB when bzip'd. Worse, even small changes in the source code can result in hundreds of megabytes of debug files that are not binary equals of the debug files from the previous build - generating an additional 300 MB per day of debugging info is not unusual. My upload bandwidth makes uploading this much per day unfeasible, but KDE4Daily's usefulness as a debugging aid is significantly reduced if it cannot be provided when an app crashes - without it, the backtraces given by DrKonqui are not really useful to developers.
Thankfully, the debugging info is fantastically susceptible to utilities such as bsdiff and bspatch, which help bring this down to a much more manageable 10-20MB per day of patches. So, after compiling a build, the fat, debug-filled executables are stripped and separated from their debug info and tagged in a way that associates them with this extracted debug info. Ordinarily, the way the GNU tools work means that an otherwise unchanged executable would change whenever its debugging info did (a fairly common occurrence), but a bit of jiggery-pokery and a naughty hack to GDB eliminate this inefficiency. If (not when ;)) an app crashes in KDE4Daily, a FUSE daemon written in Ruby intercepts requests for debug information from GDB, downloads a mapping that associates the executable's tag with its debug info, downloads the "original" debug info for this executable and the small patch required to bring it up to date, combines the two and then delivers the full, up-to-date debugging info to GDB for backtrace generation.
Preparing an install is about 99% automated. I only deploy a build if all modules have compiled cleanly and while there are occasional patches where one or two modules might have problems, on the whole compilation is pretty reliable. Building takes about 2-5 hours, and stripping and diffing the debugging info takes 1-3 hours. Generally, I need to upload anywhere between 20 and 70 MB per day, all-inclusive.
The torrent was uploaded two weeks ago but not widely publicised. Eventually, Aaron Seigo, Jos Poortvliet, Sebastian Kügler and Anne-Marie Mahfouf goaded me into writing a Dot article (my first!) and Jonathan Riddell helped knock it into shape. Many more people downloaded it than I had expected - I was expecting maybe one hundred or so people over the lifetime of the project, but at its peak, more than 1100 people were on the torrent! Dirk Mueller very kindly provided hosting for the updates and debugging info, and Martin and Kiyoshi provided hosting for the image itself for people who have no access to BitTorrent. Many people approached me with support and extra information (Liquidat blogged on how to convert the image so that VirtualBox users could use it) and left encouraging comments on the Dot article, and a gratifying number of people in #kde4-krush seemed to be using it! :)
I always thought it was pretty cool that when I first upped the torrent, Aaron Seigo himself was the first to hop on and has continued to seed ever since - I think this nicely highlights the "community" aspect of KDE :)
On the whole, it's been a fun challenge and overall a very positive first KDE experience - post-4.0, I hope to continue to contribute to KDE with some libs work and some apps :)
|
|
Simon also points out that the KDE build dashboard (http://ktown.kde.org/~dirk/dashboard/) is a really nice tool for checking the status of individual KDE modules before compilation, and it seems to be relatively unknown amongst users who try to compile KDE itself.
|
Cornelius Schumacher writes about another 10 year anniversary, this time that of the establishment of the KDE e.V. as a legal entity to represent KDE:
|
Tomorrow (27th November) is the day on which the KDE e.V. was founded, ten years ago. The first entry of our official registration says "The articles of association are constituted on 26th November 1997". It also mentions the President of the Board as "Matthias Ettrich, Student" and the Vice President "Matthias Dalheimer, Computer Scientist". Stories tell that they had to drag in housemates and girlfriends to reach the minimum number of persons needed to create a "registered association", i.e. an e.V., according to the German regulations.
I'm pretty sure that none of them expected where we would be today, ten years later. The KDE community lives and prospers, the fourth generation of the KDE desktop is about to be released. The KDE e.V. stands firm behind the project providing representation and support where needed. We have 203 regular members, representing the core of the KDE community, and a number of supporting members, our patrons Mark Shuttleworth, Trolltech, Intel, Novell and Klarälvdalens Datakonsult, as well as the supporters basysKom, Sirius Corporation and Medas GmbH. They and all the donors which give us financial support make it possible for the e.V. to fulfil its mission, to support the KDE community to develop the Free Software Desktop.
So join in and celebrate this day as the tenth birthday of the KDE e.V.
Happy Birthday KDE e.V.!
|
|
Anne-Marie Mahfouf announces the KDE-Edu meeting, due to take place next weekend:
|
The KDE-Edu team will meet for the first time next weekend in Paris. Mandriva is hosting the meeting and KDE e.V. is sponsoring the event. 14 people will share ideas about one of the biggest challenges of the moment: Free Educational Software.
The aims of the meeting include debugging applications for the upcoming KDE 4.0 release: please issue bug reports for all programs in the kdeedu module at bugs.kde.org. We'll also be preparing the KDE 4.1 KDE-Edu roadmap and have various other items in the agenda.
|
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/optimise)
![[*]](/images/standard/other)
![[*]](/images/standard/security)