[Panel-devel] the path to KDE4

[Aaron J. Seigo]

On Tuesday 24 May 2005 04:49, Ryan Nickell wrote:
> 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.

sounds good ...

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

not really...  something that expands out of the _panel_ and which are 
"attached" to a button or applet on the panel. basically a way to "bubble 
out" an area the panel to allow for more UI .. think of the dictionary applet 
and the results window fusing, for example.

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

yes, and yes =) applets will, hopefully, be universal: they will be able to be 
placed on the desktop, floating or on a panel. of course, applets will also 
be able to say "i can't be put on a panel" if that form factor simply doesn't 
work for them, but i'd like to discourage that if possible.

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

i'm first and formost interested in KJSEmbed because of performance, 
sandboxing, tagging along with the AJAX/Dashboard/etc wave and helping 
promote KJSEmbed in KDE ...

other language bindings will likely be up to others, for instance the SK 
people. having language bindings that reflect the user community would 
probably be good.

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

yes, i'd like to support this format.

-- 
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/20050525/d9812636/attachment.pgp