overhaul of some kcm appearance

[Aaron J. Seigo]

On Tuesday 17 March 2009, Lubos Lunak wrote:
>  We have just a different approach and I don't think one or another is
> clearly better technically. I mean, I'm really unhappy about the fact that
> the window manager now pulls in a full-blown HTML rendering engine just

let's say, for arguments sake, that this becomes a real-world problem such 
that applications that have no need for html rendering end up with a user 
impacting performance penalty due to this. what would we do then?

libplasma has one interface to webkit: Plasma::WebView. the usage of webkit is 
internal to this class, which doesn't itself actually subclass anything in 
webkit. so assuming that the linker pulls in webkit when libplasma is loaded 
and that's an issue, i'll bet we could do a manually dynload trick in 
libplasma to negate that issue.

> because the Plasma people decided to roll their own look&feel and now
> others have to be adjusted so that Plasma does not stand out like a sore
> thumb,

kwin did not look integrated with _anything_, even in kde3 days. the extent of 
integration with $ANYTHING was that the window switcher and most window 
decorations used the sytem colours. this is still a possibility with Plasma 
desktop themes (Aya, for instance), so there's no loss there. the benefit is 
that now kwin components that, to the user, look like they should belong 
together (e.g. window switcher, window effect titles, panels, etc.. all bits 
of the desktop workspace) actually do look like they belong together.

if you're interested, i can explain why the desktop shell should be able to 
look unique and the benefits that confers. i don't want to bore you though if 
you don't particularly have use for that conversation :)

in any case, it was not the "silly stupid light hearted decision without any 
purpose" your statement above makes it sound like. rather quite the opposite.

> [*] For a sane definition of "Plasma app" - "an app that links libplasma"
> must be the most lame and useless definition there could be, and if there
> isn't a better one, I guess the move of libplasma to kdelibs missed one
> important detail.

applications that link to libplasma fall into one of two categories:

* applications that are part of one of the KDE workspaces (there is basically 
just the one production one right now, but we're working on ones for other 
physical form factors); this is for visual and functional continuity

* applications that do "widgets on canvas" type things and don't want to 
invent everything from scratch

we have examples of both applications that have production releases, and which 
both use the plasma in kdelibs now. so no steps were missed.

> [**] Incidentally, I've been recently thinking more about trying to
> popularize KWin usage outside of KDE. I wonder how most people will view
> something that pulls in 50+MB of libraries though :-/.

this is only an issue as long as people, particularly us, make it an issue. if 
you're looking at how to market it, you concentrate on the positives (e.g. the 
quality window management, the advanced window management features, 
compositing, etc) and address the possible negatives (e.g. 50 mb of libs), if 
at all, through simple explanatory comments such as "those libs allow kwin 
people to concentrate on the core issues, such as compositing, which is in 
part why it's such a great window manager. they can concentrate only on the 
window management bits, and not things like configuration systems, 
customization dialogs, etc.."

that's how we managed to eventually silence the "the kwin people are wasting 
time by duplicating compiz", btw: simply explain why the negative (time 
replicating work apparently done elsewhere) actually is necessary for a 
positive (we needed quality window management above all else, something that 
integrated nicely and which can fall back gracefully to hardware that doesn't 
support compositing).

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090319/2a4efefc/attachment.sig>