|
Work on engine configurability, data management, a packaging system for Plasmoids and themes, and new refinements in desktop icon interaction in Plasma. The Oxygen window decoration and widget are both moved into kdebase. Further work in the Icon Cache, Kopete Messenger update, KRDC and Context Help Summer of Code projects. Improved highscore handling and network management across kdegames. New keyboard engine becomes live in KTouch, whilst the Step physics simulation package receives support for annotations. Support for many new text styling options in KOffice. Further work towards Amarok 2.0, including work on the context view and the display of lyrics. More recent and precise elevation data added to Marble. KColorScheme colour roles are added to aid usability. User documentation is started for Dolphin. More work in Strigi and NEPOMUK. Work on vector selections and a smoothing algorithm for drawing implemented in Krita. Many improvements in the KMix sound management utility. Digikam begins to be ported to KDE 4. Large scale reorganisation in the kdegraphics module: KColorEdit, KIconEdit, KPovModeller, Kuickshow and Ligature move to extragear/graphics, whilst Kooka and kmrml are removed completely.
|
Riccardo Iaconelli produces a new video, Icon Interactions in Plasma:
|
I’m really glad to announce that finally I finished implementing the icon interactions for Plasma. I initially got inspired by one of the David’s mockups (a result of the internal Appeal project of last year): he was showing it to me to see if I could implement something similar: he knew I was already working on icons for Plasma.
What he showed me was essentially this Flash animation that shows the concept live, and the design PDF that actually explains in detail what the animation does.
I immediately loved his idea, and I told him that I would immediately begin to implement it. This morning, I proudly showed the results of my work to Nuno, and he refined the look of those Plasma icons.
So, this is basically how it looks right now. The icon in the top-left corner actually represents one of those "quick actions" you can read about in the PDF and look at in both the animation and in the screencast.
|
|
Rafael Fernández López records an update with the progress since last week on KListView:
|
I finally committed today KListView into kdebase/apps/dolphin. It still requires a little speed optimisation work on the setSelection() and mouseReleaseEvent() methods. There are a few problems when you change the sorting role on the fly, as well as if items are added/deleted externally. If you experience strange issues, just press F5 key to make it update everything.
That said, here is a screencast of the latest work on KListView, with sorting by Files/Folders and by Size.
I am going to continue my work on Dolphin too, to make the rest of sortings work, as right now, the only sortings implemented are by Name and by Size.
|
|
Loïc Corbasson, a Summer of Code student, introduces his project, Theming in KOrganiser:
|
Today KOrganizer's theming interface, CalendarDecoration, is not widely used. Plugins using the interface have to be written in C++, and the functionality remains simple.
My goals during Summer of Code would be:- to allow for more features (background images, image/quote of the week/month, etc)
- to write some example plugins (national calendars, "This day in history" links, ...)
- to make it easier to write simple decorations for KOrganizer using a portable and easy-to-use format, which may be extended in the future (like the KDE themes).
Looking for a way to distinguish customisations on calendars, I found that paper-based calendars use two types of customizations:- not combinable decorations, like color themes, backgrounds, etc.; these are making the overall look of the calendar;
- combinable decorations: quote of the day, day number in the year, moon phases, etc.; these are restricted to an area of the calendar, e.g. the top of the day columns in the weekly calendars.
KOrganizer currently looks like this:
An interface for the second item is already implemented: CalendarDecoration. During SoC, I will develop a few additional plugins for it, as well as an interface and plugins for the first item, the CalendarTheme part.
I think the best way to extend/create the needed interfaces is to make each feature specific to a particular view. Pictures of the day are would be too small in a month view, and showing the picture of the month in the week or day views doesn't seem very useful to me either. Different views allow for different customizations, the first criteria being of course available space, which is for example very narrow for a day, and larger for a month. This makes the whole more featureful and entertaining too: imagine if all your calendars, from the year planner to the daily agenda all looked the same! How sad and boring! :)
Decorations should also be able to be more than text, so I plan to implement at least support for images. This could use either widgets directly (current solution), a HTML widget for richer text (Qt or KHTML depending on the features we want to make available), or KParts. KParts would of course be the most generic, but would have to create few overhead. An HTML widget seems a good point to start to me. Cornelius also thought about using moon phases from KMoon (a KDE panel applet); maybe some general KPart mechanism could be used to achieve this, but it's not high-priority. With some decorations (here, Wikipedia's Picture of the day as well as the days since beginning and till end of the year), KOrganizer may look like this:
Notes- Some co-ordination with the calendar printing plugin may also be useful to allow the user to either print the calendar as it is on the screen, or to print the background image on apart from the calendar entries (e.g. at the top, like in many paper-based monthly calendars), using a specific background color for the whole sheet of paper, and using a different color theme. But this is not high-priority either.
- I think the most convenient way of storing themes would be an XML file, or something more or less à la CSS, packed together with the background images in a zipped archive. (This will be implemented after experimenting with hard-coded themes of course)
- Using a portable format would allow to make use of KNewStuff et cetera.
- Building on something already there being generally easier than starting from scratch, I will probably start by extending CalendarDecoration, which will allow me to better know the codebase.
As most of you probably already know, the Summer of Code has already started. I'd like to collect as much ideas as I can before implementing - feel free to suggest improvements or alternatives!
I hope I made clear what I planned to do, and why - if your pet feature isn't planned, complain! :)
|
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)