[Panel-devel] the path to KDE4

[Aaron J. Seigo]

hola....

seems most of us are here. now's as good a time to start as ever, i suppose =)

by the end of June, i plan on leaving KDE3 development of kicker behind, save 
for bugfixes. we've already added a number of nice things for 3.5 and even 
managed to simplify a few things in the meantime =) it's nothing 
groundbreaking, but it's certainly a visible set of improvements. this means 
that kicker will got into feature freeze for 3.5 far sooner than 3.5 does, 
but that's ok IMHO.

i've put some prelim thoughts up from an art perspective here:

	http://aseigo.bddf.ca/cms/1267

i don't mention superkaramba (SK) explictly there, as that was drafted before 
that whole idea was floated. i will be using the new KDE artist website to 
recruit graphic design ideas and tallent. in fact, i've already got a 
discussion board set up there for the artists which i will be announcing once 
the KDE artists web site is announced.

for the KDE4 development my plan of attack is something like this:

	0. Qt4 port. do the minimum to get it compiling and working.

	1. libkicker
		1.1 pull in the KPanel* classes from libkdeui and make them not suck.
		1.2 get the classes ready for binary compatiblity (d pointers, etc)
			1.2.1 augment KConfigXT to do versioning and d-pointers

	2. redesign how the panels work
		2.1 get rid of containerarea and containerarealayout. they both suck.
		2.2 augment buttons for nicer look and feel
			2.2.1 get rid of the background tiles, replace with something nicer
			2.2.3
		2.3 add extenders, which are like drawers for things to be in, but don't 
think "drawers" when you think of them because i don't want them to look like 
drawers. imagine a cool animated extension that morphs out of the panel to 
house extended UI's: if you click on the PIM applet it could zoom out an 
extender showing a summary of today's events. of if you look up things in the 
dictionary applet it could show the results in an extender.
		2.4 make hiding and placement rules suck a lot less harder
		2.5 theming must not be based on a single pixmap tile, but should be dynamic 
and reflect the underlying content (e.g. be able to have a "K Menu" area that 
looks one way; be able to sport nice extenders; mouse over effects; etc, etc)

	3. desktop integration
		3.1 get rid of all the transparency support in kicker
		3.2 write a rootwindow widget that using kicker facilities including
			3.2.1 buttons (these will replace icons)
			3.2.2 applets
		3.3 implement panel/desktop coordination again
			3.3.1 transparency
			3.3.2 minicli facelift and integration with recently used apps
			3.3.3 coordination between items on the root window and the panels

	4. the great applet rework
		4.1 revisit KPanelApplet and revise extensively, with a mind towards SK
		4.2 harmonize the SK library and KPanelApplet
		4.3 create KJSEmbed bindings
		4.4 port the old applets
			4.4.1 create a compatibility container for old applets?
		4.5 create a "hover layer" for applets, allowing them to thus be above 
windows, below windows or in panels

	5. applet porting
		5.1 bring styleclock into the fold
		5.2 port and spiffy up the taskbar and pager, keep them as C++
		5.3 decide which applets live, which ones die and which become KJS/SK 
plugins

	6. get really creative.

this last step is where we can start experimenting with what's possible given 
the new capabilities. i'm interested in task-based and project-based panel 
interfaces, for instance. but we've got a ways to go before then.

and the SK people have a roadmap to make as well.

-- 
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/20050524/65520ba0/attachment.pgp