Projects/Plasma/Tasks: Difference between revisions

    From KDE TechBase
    (more junior jobs)
    Line 19: Line 19:
    * pull in options from kdesktop/minicli.cpp and merge into shell and app runners
    * pull in options from kdesktop/minicli.cpp and merge into shell and app runners
    * implement use of strigi in search runner
    * implement use of strigi in search runner
    * determine how to order runner plugins for searching order
    * determine how to order runner plugins for searching; categorization?
    * javascript bindings to runner.h
    * javascript bindings to runner.h
    * listen to async match updates (Interface:updateMatches())
    * listen to async match updates (Interface:updateMatches())
    Line 25: Line 25:
    * add a nice text label to the top somewhere that says that this is the run dialog
    * add a nice text label to the top somewhere that says that this is the run dialog
    * provide a "close" button or clickable-label near the bottom of the interface
    * provide a "close" button or clickable-label near the bottom of the interface
    * complete SessionRunner: connect QActions up, etc
    * move Runner plugins code out of Interface::loadPlugins and into Runner so other apps can easily access them


    === Plasma ===
    === Plasma ===

    Revision as of 07:32, 28 February 2007

    Tasks

    If you want to claim a task, please put your name (or nickname, both is better) in brackets near the task you wish to claim. Please add it when you start working on it, and if you stop, please remove it, so we can know "who is working on what" and what tasks still needs to be started.

    And, of course, this will avoid duplication of work. Thanks a lot! =)

    Note
    This is a roughly sorted list of tasks that popped out during the meeting. We probably need to categorize it better, like seeing which task is blocker for which other, setting priority, split between "research" and "coding" and things like that. Still sounds like a premature thing though.


    Deal with the last bits of KDesktop

    • Move the autostart functionality from KDesktop to ksmserver. (Stephan Kulow, coolo)
    • Merge the functionalities of ~/.kde/Autostart with ~/.kde/share/autostart (Stephan Kulow, coolo)

    KRunner

    • Complete runner classes in KRunner (Aaron, fonz2591 - Riccardo Iaconelli, ruphy)
    • Integrate ksysguard's process table into KRunner (Riccardo Iaconelli, ruphy - Esben Hanse, esben)
    • abstract out the svg background part of Interface and have it subclass QDialog; then make screensaver/lock dialogs subclass that and therefore look a bit more sexy and consistent
    • options slide drawer animation
    • install D-Bus autoactivation service
    • pull in options from kdesktop/minicli.cpp and merge into shell and app runners
    • implement use of strigi in search runner
    • determine how to order runner plugins for searching; categorization?
    • javascript bindings to runner.h
    • listen to async match updates (Interface:updateMatches())
    • runners, runners and more runners! e.g. a calculator, a kalkhi plugin...?
    • add a nice text label to the top somewhere that says that this is the run dialog
    • provide a "close" button or clickable-label near the bottom of the interface
    • complete SessionRunner: connect QActions up, etc
    • move Runner plugins code out of Interface::loadPlugins and into Runner so other apps can easily access them

    Plasma

    This is what we are focussing on implementing right now:

    • Desktop layer:
      • Use a widget able to have background painting.
      • Implement the zooming of objects.
      • Implement the grouping of objects in collections (with special containers).

    And after that, see what can be done for performances:

    • Engine base classes and command line test utilities. (Aaron J. Seigo, aseigo)
    • See if QGV works well for our needs. We will use it until the end of march, then we will see how it worked. We will evaluate alternatives then (if not enough satisfied). (Aaron J. Seigo, aseigo, others welcome!@)
    • Create widgets aware of zooming. First we need to discuss what can be done for each of these elements. Needed widgets are:

    Before actually coding them we should first define the speed compromises we want/can have for all of them. We will probably discuss it in the next meeting, and what we want for each of those widgets will be written in their specific pages. Then we can start to actually code it. If you have ideas, please write it in the specific page.

    We also have:

    • Implement Zack's physical equations for animations

    Nice to have:

    • Implement python bindings of Plasma