|
The beginnings of screen hotplug detection in Plasma, KRunner gets history support. Fifteen Pieces puzzle becomes the first Plasma applet in the game category. A block of bugfixing in KDevelop, with various other developments in areas such as a threaded debugger. Support for inequality constraints in Step, continued progress in the port of KEduca to KDE 4. Work on printing in okular. Work on Solid-based network management through NetworkManager. Various work towards Amarok 2. Milestones reached in the BitTorrent plugin for KGet. Subsystem rewrites (SSL, SFTP) in KFTP. OpenDocument format loading and saving work in KChart. Colour work in Krita, with Krita becoming one of the first applications to be able to paint in HDR. New Oxygen-themed sound effects, Oxygen icons are optimised for small sizes. New colour schemes added for KDE 4.0. Ruby language bindings based on the Smoke2 framework. Experiments in KBugBuster and on a Plasma "applet designer" application.
|
Continuing the theme of recent weeks, Marco Martin introduces TastyMenu, yet another menu alternative for KDE 4:
|
How it started
TastyMenu dates back around June 2006, when I saw a thread on the kde-usability mailing list about how a "Start" menu should be presented and there was some hype around the just-announced SLAB menu that Novell developed for GNOME (Kickoff was born some months later).
So I started to try out the various alternatives that existed at that time (and not only for KDE) in order to build up a personal idea on how a "Start" menu should look. I was never satisfied with any of the options available, so I started to implement my own.
Rationale
First of all: do we still need a "Start" menu on today's desktops? I think so, or at least I have still not seen a viable alternative: the only radical different approach on today's operating systems is the combination Finder + Dock in Mac OSX, but I think that launching an app via the Finder requires too many clicks and putting all the most used applications in the dock takes too much room.
What's wrong in the traditional menu? The amount of applications installed in a modern Linux distribution can become enormous, and displaying them in a popup menu can end up with an intimidating list that covers up nearly the whole screen, so I have made something that, although still very big, takes only a fixed amount of screen space, no matter how many applications are installed. The application list is presented as a normal list view - the widget that I think is more adept at displaying a large amount of information.
Some other features are:
- Ability to search through the installed applicaions
- A list of bookmarked applications, but the list of all the other applications is still in the main window and not buried in submenus or other windows
- Keeps track of recently-installed applications
- The usual logout/fast user switching buttons
Plans for the future
At the moment TastyMenu is only available under KDE3, but I think someday I will start a port to KDE 4: real life can be a harsh mistress, so I can't promise when :)
I think there is still room for a menu like TastyMenu in KDE 4, because the choice is good, you know :)
This will be for those who want a more classical approach, because I think it will remain a classic Application-centric interface, aimed to launch applications with the smallest number of mouse clicks as possible.
Most notable differences will probably be a better integration with Strigi and a simplified user interface.
|
|
Lukas Appelhans discusses the recent implementation of BitTorrent support within KGet:
|
I'm currently writing a BitTorrent plugin for KGet and KDE 4.1. KGet had another BitTorrent plugin based on libtorrent, but this early version was never been really finished and used widely.
The new plugin is based on the new libbtcore (aka. libktorrent) and makes an old plan come to fruition (as mentioned in an earlier Digest). So now we have a torrent plugin, which has no KDE-external dependencies.
Currently the plugin is in a very basic state, it downloads the files, but gives no output or configuration options.
At the moment, I am in very good contact with Joris Guisson, the author of libbtcore (and of KTorrent). Over the next few days, I will have a look at the Transfer-Details and other user-visible interface elements, to ensure that they are functional with the new plugin.
In the future, we want to have support for speed limits and other nice features of libbtcore, which are all very easy to implement. Another planned feature for KGet is to have a single "transfer", which downloads from multiple sources, such as BitTorrent, HTTP, FTP, etc. - all at the same time. These multiple-source downloads are the basis of the Metalink concept.
In the last days, there wasn't only bugfixing at KGet-Development. We now have a very nice Details view, called "Expandable Details":
It is currently disabled by default. We need and want your feedback: talk to us at our mailing list, or on IRC at irc.freenode.net, channel #kget!
|
|
Tim Beaulen expands on his concept and plans for a Plasma applet creation application:
|
For some time earlier this year, I started development on a GStreamer Phonon backend. Trolltech took over development of that backend, and so I have been looking for something else to do. A few ideas were spinning around in my head.
I settled for a Plasma applet designer.
While I was working on the GStreamer backend I was also creating a debugging tool (the graphical programming idea - visual pipelines). Since I want to do something in the line of graphical programming and the same ideas can be reused in the Plasma applet designer to create Phonon pipelines to do sound effects (for example), and to visually design "programs", the choice was easy.
This is a lot. Too much for me alone. That's why I started with gathering documentation and by trying to create a roadmap with clearly defined tasks and milestones. It's the only way to get somewhere. Start from the bottom up and implement tiny feature after tiny feature. And hopefully other people get interested so that the pace of development will increase.
I believe that it should be easy for anyone to create Plasma applets without coding knowledge. Anyone should be able to drag and drop some elements and easily link them toghether to create beautiful applets.
What I want to do is create an application that lets a user create an applet in a couple of minutes that displays, for example, a train/bus/airplane timetable. Drag and drop a list, a picture, a URL download engine and a text parsing module - maybe, via WebKit "editing" possibilites, it would be possible to download a webpage, select some text on the page and the parsing is done automatically without the user needing to look through the HTML or XML code to find patterns, etc. - and link them together. Apply some SVG graphics (theming) and voila, it is functionally complete. Not a line of code needed. Of course, scripting elements would be available to create complex applets. This way the complete control remains. And hopefully with direct visual feedback and debugging.
Naturally, this project is very complex. Complex problems can't be solved by taking them head on. Just starting coding is a waste of time. One of the first things I learned was to split complex problems into manageable sub problems. And this is the current focus of development.
The first milestone is to have as much information gathered as possible and start outlining a roadmap. In the near future (somewhere in the first half of 2008) something very basic, Designer-like (or why not use designer directly and make Plasma applets use .ui files?) should be available. Maybe the program could also be turned into a full application prototyping program.
My goal is to create an application which will bring every new core technology of Qt4 and KDE 4 together in one single app and enable the user to create wonderful things with it. Bah... a stupid marketing line :)
I can't provide screenshots at the moment as all I have are two files: a README and a TODO list :)
Hmmm, as always, the above description is huge.
The finished product will not be ready in the immediate future!
|
|
This past weekend was host to the KDE-Edu meeting at the Mandriva offices in Paris, France. 14 contributors met over two days, and many of them blogged about their experiences and outcomes.
|
Andreas Pakulat has closed 87 bugs this week, many of those in KDevelop 3. Andreas even talks a tiny bit about this momentous acheivement - it is really short, and so is definitely worth a read!
|
It has come to my attention that the way the Digest is advertised each week at KDE Dot News (the place where most people find the Digest) can be a little confusing and not as accessible as it could be - some people consequently thought that the Digest consisted only of the weekly roundup paragraph displayed on the Dot! Of course, it would never be my intention to hide my hours of work from anyone!
I have made the Dot blurb more clear, starting with this issue. To my "new" readers: welcome! You can make up for lost time by browsing the full content of previous Digests, or take a few steps back in time using the arrows surrounding the title at the top of this page! (and never miss an issue with the KDE Commit-Digest RSS feed!)
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)