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

List:       kwin
Subject:    Re: Re: RFC: Removing of decorations
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2012-03-14 20:03:11
Message-ID: op.wa6fblvx9bmiid () localhost ! localdomain
[Download RAW message or body]

Am 14.03.2012, 20:11 Uhr, schrieb Martin Gräßlin <mgraesslin@kde.org>:


> For 4.10 I would like to see a new modern style for thin clients being
> implemented. I'll talk to Nuno.

Ideally we'd have a theme engine / deco API that will allow users to add  
<random clone of legacy decoration between win 3.11, platinum, win95, OS/2  
and QNX here> from kde-look.org

I do have (API stable) additions to the current deco API in mind, but  
unfortunately that does not really work with QML in terms of "thin client"
While the syntax would actually be between great and ideal, there seems to  
be no public "QmlParser", so either we'd write one or fall back to  
QDomDocument (xml) or even an ini format (both have their drawbacks)

Reason is that we basically want *some sort of* QList<QGraphicsItem*> for  
the compositor, but we don't want a QGraphicsView, since the compositor  
provides the canvas & renderer and we rather don't want a double buffering  
view for every decoration (and esp. not with compositing)

Also i'm not sure how fast
for (int i = 0; i < 8; ++i) {
    p.begin(&items[i]->pixmap());
    m_declarativeView->render(&p, items[i]->rect(), ...);
    p.end();
}

would turn out to be (except for when there's a offscreen buffer, so that  
changes are only rendered once) :-\


Cheers,
Thomas

PS:
let's first see how crashy event handling of heap objects in QML turns out  
to be in comparism to QGraphicsWidget ;-P
(and whether we actually fixed it at last...)
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

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