[Panel-devel] KDE4

[Ryan Nickell]

On Mon, 2005-06-20 at 14:14 -0600, Aaron J. Seigo wrote:
> 
> > What's the specific schedule for kde4 porting?
> 
> on the 27th we will begin the port. this means that everyone will need to grab 
> the kde4 branches of kdelibs and kdebase. we should coordinate the efforts 
> somewhat so we aren't banging into each other. here are the steps:

So next monday we all need to get the kde4 branch and start building.
>From there we'll all start on the same page.  kdelibs and kdebase are
all that are needed for a kde install to run barebones?

> 
> - get libkicker building (minimal port)
> 	|_ get kicker/kicker building (minimal port)
> 	|_ Qt4-ize libkicker (not Qt3* classes remaining)
> 		|_ add d-ptrs and documentation to all classes, remove all inlined methods
> 	|_ port applets
> 	|_ port extentions
> 
> once that is done then we can start morphing kicker into the base for plasma:
> 
> - creating libplasma (the library for applets)
> 	- what do we want to offer applets?
> 		- does libkicker split into two, or does it become libplasma?

We also need to get a libsk(or libsuperkaramba) ready as well.

> 		- wrappers for common needs like an html widget
> 	- harmonize with superkaramba's library
> 	- make it easy to creating bindings for
> 	- bring in the KPanel* classes into libkicker
> 		- tie the KConfigXT settings into these classes
> 		- move hiding/etc code from ContainerExtension into KPanelExtension
> 		- rethink placement code
> 		- allow for Extensions to communicate the form factor to contained items
> 		- allow applets to adapt to various form factors with as little code as 
> possible
> 
> - extending kicker to become the plasma manager
> 	- our current plugin, etc management classes are not ready for plasma.
> 	- the Container* classes need a good revisit
> 	- removal of cruft.
> 
> - desktop widget
> 	- subclass KPanelExtension for this
> 	- start working on a layout and positioning scheme
> 		- must be easy to use
> 		- must allow for autopositioning/growing of applets
> 		- SuperKaramba people need to be invovled here as this will be their primary 
> playground area
> 
> - new Plasma elements
> 	- revisit kickertip: it works but how can we make it better?
> 	- extenders
> 	- new buttons
> 	- new applet management UI (handles on panels, $SOMETHING on the desktop)

ZUI as well?

> 
> - devel framework	
> 	- we ought to have a test suite to test at LEAST the non-GUI code
> 	- documentation standards
> 		- diagrams of plasma structure for us and those who replace us
> 		- API docu for libplasma
> 		- applet development guide
> 
> this will keep us busy for the next several months. from here we can start 
> building next gen applets. while creating libplasma i'd like to pick the 
> most-required applets from today's kicker and one or two of the most 
> popular/beatuful superkaramba applets and use them as consumers of the new 
> library, so we aren't designing a library without any practical, real-world 
> consumers.

Liquid Weather is probably the most downloaded/used SuperKaramba theme
out there, and Matt is awesome about working with us on SuperKaramba
developments.

> one of my current goals is to create a way for an 
> applet to *easily* tap into another user's desktop and coordinate with it, 
> allowing for connected applets over the network. this will become one of the 
> killer features of Plasma.

I must have missed this mention somewhere, but it sounds really cool!

> i'd like to hear from the others at this point what they would like to tackle 
> and start working on.

-Ryan