overhaul of some kcm appearance
Aaron J. Seigo
aseigo at kde.org
Thu Mar 19 18:19:58 GMT 2009
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
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
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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel