[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: list of usability-related aKademy discussion
From:       Luciano Montanaro <mikelima () cirulla ! net>
Date:       2004-08-03 15:18:42
Message-ID: 200408031718.42981.mikelima () cirulla ! net
[Download RAW message or body]

El Domingo 01 Agosto 2004 04:23, Enrico Ros escribió:
> On Monday 26 July 2004 08:09, Aaron J. Seigo wrote:
> > hi all...
> >
> > i'm starting to organize my aKademy schedule. the purpose of this email it
> > three-fold:
> >
> > 	1. to get an idea who else will be there to discuss these things with
> > 	2. to let everyone here know what i plan to work on
> 
> Here are my 2 cents on a topic that interests me:
> 
> > 4. kdesktop
> > 	a) icon layout and handling. needs a rewrite, and Qt4 forces that anyways
> 
> Great, there are so many levels of inheritance.. some functions are called 
> multiple times, it's fullt repainted when you touch an item.. qt4 are 
> welcome!
> 
> > 	b) something like karamba ought to be IN kdesktop if there at all
> 
> Here comes a cool thing.
> Karamba integration will be great, but (this might sound inpopular) we have to 
> use fast c++ rendering code with asm optimized KImageEffect composting to get 
> a decent performance so no python, but a good and fast kde plugin api.

Well, as long as there is an API to program "desktoplets", the language to use 
for each gadget is not really important. Python seems to work quite well with its
Qt bindings, even if I have never used personally. 

> 
> (AFAIK karamba does come composting with the desktop pixmap on its own designs 
> and places resulting pixmaps in windows kept below others.) The kdesktop I'd 
> like to work on is composed by a single widget where composting takes place.
> 

I'm not sure how Karamba does its compositing, but what you describe 
seems plausible.
However, Qt4 can handle transparency much better, so, if the application managing
the desktop background exports methods to register plugins, there would no need 
for much else. 

> The user will edit the desktop appearance (in small preview win? in 
> full-screen mode?) by selecting a plugin and drawing a rectangle (or 'layer') 
> on the container.

I'd go with full-screen mode, myself. In fact, the functionality we want is 
quite similar to that of "stick-to-bottom" windows. Maybe the desktop gadgets
could have a common popup menu to hide/show the title-bar/resize handle.

> There will be 1 plugin for the iconview (so the area of icons can be limited 
> to the rectangle).

As long as more than one plugin can be added to the desktop, I agree. Maybe the
default desktop should have just that plugin enabled by default.

> Another plugin is the simple background loader (like the background we have 
> now, but with that architecture an user will place a photo he likes in a 
> rectangle located somewhere over another big background).

I was thinking more along the lines that this would be handled by the "core" 
Desktop manager. Everything else is layered over this. However, this is a 
technical detail, it does not much matter here, on the usability list. 

> Another can be an OpenGL analyzer to be connected to amarok/juk/konqueror 
> sidebar player.
> Another rectangle (ops, plugin) can be.. you name it (well, I can add notes, 
> calendars, a dashboard shared with everyone in the local lan, a space for 
> integrating kdetv videos)
> Of course there will be a loader for karamba themes that will create a fake 
> 'plugin' for every installed karamba theme.
> Maybe the kicker too will be a plugin for desktop (well, the user will believe 
> that, in fact there will be a DCOP wrapper that moves/shows kicker).
> 
> Mix that with a few good layouts preset and the simple one for default 
> (maximized background, bottom kicker, iconview in the background minus the 
> kicker area).
> 
> We should code a good interface for plugins and a smart composter/renderer 
> that caches static contents and updates dynamic areas only when needed. Then 
> we have to provide multiple backends for rendering sucha s a software 
> renderer (a composter that uses KImageEffect) a X11 Composite/Damage renderer 
> (hopefully accelerated).

Qt4 should be able to handle this and/or the Composite/Damage extensions, 
depending on how the thing should be implemented.

> 
> I hope you'll take that proposal into account.
> Note: I know that will require lot of work but we can get it working.. (is not 
> impossible, we can do it).

Sure, it's mostly just lot of small things...

Luciano
> 
> Bye,

-- 
Any sufficiently advanced technology is indistinguishable from a yo-yo
                                                                 - Enoch Root
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]