[Panel-devel] KDE4

[Aaron J. Seigo]

i'm starting a new thread for this because i'm hoping it will be long ;)

On Monday 20 June 2005 12:03, Matt Broadstone wrote:
> So where are we at now in terms of finishing up for 3.5?

i've got one more feature to complete on my list (the auto-removal-of-buttons 
code) and there are 2 other features that i'm aware of that are pending, both 
of which are bending the feature freeze a bit, but that's ok since our 
feature freeze is more of "get the hell out of 3.5" thing rather than a hard 
freeze.

we really need to pound on the 3.5 code .. i've got a couple of pending 
commits that fix various issues. what's interesting is that most of the 
issues i've been solving are quite old but are being revealed as we improve 
the code base and expose more of the functionality and people actually start 
using it and paying attention due to the constant rate of work. a great 
example of this is how applets wouldn't get their backgrounds properly 
re-jigged when you turn off applet handles and use a transparent kicker. 
well, nobody noticed until i added the easy to get at "Lock panel" item in 
the context menu. now that people are using that, one of the first things 
noticed was that this was broken. i've got a fix for it on disk.

anyways...

> 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:

- 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?
		- 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)

- 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.

this is also where Zack will need to come in, to start us off on the right 
foot for compositing and what not. Hans for task management concepts, such as 
how do bring kompose into this, if at all? alternatives/additions to the 
taskbar button interactions? Georges A. K. is going to have to start thinking 
of the systray ... etc, etc, etc

we also need to use this time to agregate all of our dreams/hopes/desires for 
plasma into a feature plan. 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'm not going to put any agressive timelines on this as i want to get it right 
and am unsure as to how much time we will actually end up needing. i will be 
poking and prodding as we go, though, to keep things moving.

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

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- 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/20050620/46b19959/attachment.pgp