[Panel-devel] the path to KDE4

[Ryan Nickell]

On Tue, 2005-05-24 at 01:20 -0600, Aaron J. Seigo wrote:
> 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.
So, what I'm invisioning is that when the freeze occurs, the SK devs
will switch focus to the kde 4.0 effort.  This means integrating as much
as the functionality of SK as we can into kdesktop/kicker 4.0. 
> 
> 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.
By "drawers" do you mean something that can have some specified
animation to expand out from an off screen area into the desktop to
become viewable?  
The Borealis SK theme sounds like this:
http://kdelook.org/content/show.php?content=13876
> 		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
This is where the "floating widgets" fit in as well, correct?  Or will
they be considered just another applet?
> 		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
Is the goal to support _just_ KJSEmbed initially or to support other
languages in parallel(i.e. Python, Ruby, etc.)?
> 		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.
Yes we do.
> 
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel

Along with the KJSEmbed bindings mentioned earlier, are we adopting the
Dashboard format of making, for lack of a better term, themes?  HTML and
CSS in combination with the bindings? 

-Ryan