[Panel-devel] kde4 kicker patches

Barış Metin baris at uludag.org.tr
Mon Jul 11 04:30:10 CEST 2005


On Monday 11 July 2005 04:12, Aaron J. Seigo wrote:
> i haven't really looked at the patches, but that's ok =) at this point, if
> it builds, commit.
>
> once things are building then the next step will be to remove usage of ALL
> Q3* classes so we have a legacy free source tree. if you wish to start in
> on that, please feel free to do so at any point. we don't have to wait for
> EVERYthing to build.
>
> hopefully we won't get in each other's way. it may be a decent idea,
> however, to just send a msg to the list here when you start hacking on a
> certain area so that others know to avoid it until they see the commit(s).
>
> with that in place, then we can start restructuring libkicker .. but that's
> a week or two away at this point =)

Thanks for your comments. I've commited the patches.

By the way, I tried to make a TODO for KDE4 and Plasma porting based on your 
mail KDE4 and comments on the list (attached).

Is my understanding true? If so, should we put the file somewhere in the kde4 
branch?

regards,
-- 
Barış Metin
-------------- next part --------------

A list the work need to be done in kicker for KDE4 porting and brand
new Plasma framework.


Abbreviations:

- Not started yet
? Not determined if/how we'll do
/ In progress
+ Accomplished


Work:

/ Port kicker to KDE4/Qt4
  / get kicker/libkicker building (minimal port)
  / get applets & extensions building
  / move KPanel* classes from kdelibs/kdeui to libkicker
  - Qt4-ize kicker (remove remaining Qt4* classes)

- Create libplasma (the library for applets)
  - decide what to offer to applets
    ? split libkicker or evolve to libplasma
    - merge/create libsuperkaramba
    - wrappers for common needs (like an html widget)
  - harmonize with superkaramba's library
  - decide and implement graphics framework
  - create bindings for libplasma
  - revisit KPanel* classes
    - tie the KConfigXT settings into these classes
    - move hiding/etc code from ContainerExtension to KPanelExtension
    - rethink placement code
    - allow for Extentions to communicate the form factor to contained items
    - allow applets to adapt to various form factors with as little code as possible

- Extend kicker to become the plasma manager
  - make plugin, etc. management classes ready for plasma
  - revisit Container* classes
  - removal of cruft

- Implement desktop widgets
  - subclass KPanelExtension
  - start working on a layout and positioning scheme
    - decide on the requirements 
      (must be easy, must allow autopositioning/growing of applets, etc.)

- Implement new Plasma elements
  - revisit kickertip to make it better
  - agree on a list and overall architecture of the required elements
    - extenders
    - new buttons
    - new applet management UI (handles on panels, $SOMETHING on the destop)
    ? interoperability of applets over the network

? Build an applet creator/studio for packaging JS/Ruby/Python applets

- Provide a development framework
  - test suite
  - documentation standards
    - diagrams of plasma structure
    - API documents for libplasma
    - applet development tutorial
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050711/88b171da/attachment.pgp


More information about the Panel-devel mailing list