From kwin Thu Mar 28 22:18:45 2013 From: =?utf-8?q?Thomas_L=C3=BCbking?= Date: Thu, 28 Mar 2013 22:18:45 +0000 To: kwin Subject: Re: Review Request 109778: Replacement for PlasmaCore Dialog Message-Id: <20130328221845.18103.55357 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=kwin&m=136450914316206 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============6062203197222835880==" --===============6062203197222835880== Content-Type: multipart/alternative; boundary="===============0086134550596757974==" --===============0086134550596757974== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > On March 28, 2013, 3:33 p.m., Thomas Lübking wrote: > > Given with esp. QML the shadows can already be part of the window - what makes this different from Plasma.Dialog other than the bypass windows hint? > > > > Ie. what's worth risking to dip into some sort of forked API for kwin only (which actually backrefs plasma, so RazorQt is not an argument ;-) > > > > As for the bypass requirement, my initial thought after Michail came up with that for the second time was to just add an abort() into events.cpp or maybe deny management and push out an error message instead. > > Martin Gräßlin wrote: > ah the shadows/translucency is not the reason I did this. That's more a lucky side effect. > > The things I did this for are not yet implemented. When playing with "Present Windows 2" I noticed the following issues with PlasmaCore Dialog: > * it honors panels - good for Plasma, bad for us > * it cannot be set to not have a background (we will need that if we want to have transitions from current window positions) > * using Qt.Popup to get mouse/keyboard breaks with multi screen. Only one of the window gets the events and clicking outside the dialog (other screen) closes it. > * API is difficult to use due to having to set BypassWindowManagerHints and Qt.Popup > > so what I want to do, is adding properties: > * grabMouse > * grabKeyboard > > grabMouse will create a fullscreen input window just like the effects and grabKeyboard uses our normal grab functionality. From events.cpp I would then multicast the events into all currently visible windows. I just don't think we could extend the Plasma API to fit those needs. > I just don't think we could extend the Plasma API to fit those needs. Well, Marco will have to answer that one ;-) I'd suspect sth. similar would be required for the dashboard and there's also the Homerun launcher (which also has a transparent background) Don't get me wrong, but i'd rather try to get this fixed "upstream" because otherwise we'll never end getting bug reports from script authors trying to invoke Plasma.* (-> abort()) or drifting/running after *cough* last minute changes *cough* for alignment ... - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109778/#review30006 ----------------------------------------------------------- On March 28, 2013, 3:17 p.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109778/ > ----------------------------------------------------------- > > (Updated March 28, 2013, 3:17 p.m.) > > > Review request for kwin and Marco Martin. > > > Description > ------- > > Use KWin.Window instead of Plasma.Dialog in DesktopChange OSD > > > Introduce a WindowDeclarativeItem > > This Item is exported as "Window" to declarative scripts. It can be used > to create an override-redirect window, similar to what Plasma.Dialog > provides, but better tailored towards the needs of KWin. > > The WindowDeclarativeItem wraps and controls a QGraphicsView and adds the > mainItem to its scene. The GraphicsView takes care of rendering a plasma > styled background (dialogs/background) with the required hacks to ensure > that KWin gets the correct translucent elements. Shadow is currently not > yet provided - this should be added in an internal way without the X > roundtrips. > > Remove QDeclarativeView from DeclarativeScript > > The view is never shown or used in any way except to create the > QDeclarativeEngine. So instead of using a view as a wrapper, let's create > a QDeclarativeEngine and a Component and create the script from the > Component. > > To have Plasma.Dialog working we also need to add the created script item > to a QGraphicsScene. > > > Diffs > ----- > > kwin/CMakeLists.txt f0795b4873ac58a06c737b200559fa76e3c9c11e > kwin/scripting/scripting.h db85e23663e475af155235cac6851ef0c5767dc9 > kwin/scripting/scripting.cpp e124827174317ab6adbfdb90cec796a02e7bd2b7 > kwin/scripting/windowdeclarativeitem.h PRE-CREATION > kwin/scripting/windowdeclarativeitem.cpp PRE-CREATION > kwin/scripts/desktopchangeosd/contents/ui/osd.qml af49d45a30fcc6082e181971c1965e35763cf406 > > Diff: http://git.reviewboard.kde.org/r/109778/diff/ > > > Testing > ------- > > > Thanks, > > Martin Gräßlin > > --===============0086134550596757974== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit
This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109778/

On March 28th, 2013, 3:33 p.m. UTC, Thomas Lübking wrote:

Given with esp. QML the shadows can already be part of the window - what makes this different from Plasma.Dialog other than the bypass windows hint?

Ie. what's worth risking to dip into some sort of forked API for kwin only (which actually backrefs plasma, so RazorQt is not an argument ;-)

As for the bypass requirement, my initial thought after Michail came up with that for the second time was to just add an abort() into events.cpp or maybe deny management and push out an error message instead.

On March 28th, 2013, 4:18 p.m. UTC, Martin Gräßlin wrote:

ah the shadows/translucency is not the reason I did this. That's more a lucky side effect.

The things I did this for are not yet implemented. When playing with "Present Windows 2" I noticed the following issues with PlasmaCore Dialog:
* it honors panels - good for Plasma, bad for us
* it cannot be set to not have a background (we will need that if we want to have transitions from current window positions)
* using Qt.Popup to get mouse/keyboard breaks with multi screen. Only one of the window gets the events and clicking outside the dialog (other screen) closes it.
* API is difficult to use due to having to set BypassWindowManagerHints and Qt.Popup

so what I want to do, is adding properties:
* grabMouse
* grabKeyboard

grabMouse will create a fullscreen input window just like the effects and grabKeyboard uses our normal grab functionality. From events.cpp I would then multicast the events into all currently visible windows. I just don't think we could extend the Plasma API to fit those needs.
> I just don't think we could extend the Plasma API to fit those needs.
Well, Marco will have to answer that one ;-)

I'd suspect sth. similar would be required for the dashboard and there's also the Homerun launcher (which also has a transparent background)

Don't get me wrong, but i'd rather try to get this fixed "upstream" because otherwise we'll never end getting bug reports from script authors trying to invoke Plasma.* (-> abort()) or drifting/running after *cough* last minute changes *cough* for alignment ...

- Thomas


On March 28th, 2013, 3:17 p.m. UTC, Martin Gräßlin wrote:

Review request for kwin and Marco Martin.
By Martin Gräßlin.

Updated March 28, 2013, 3:17 p.m.

Description 

Use KWin.Window instead of Plasma.Dialog in DesktopChange OSD


Introduce a WindowDeclarativeItem

This Item is exported as "Window" to declarative scripts. It can be used
to create an override-redirect window, similar to what Plasma.Dialog
provides, but better tailored towards the needs of KWin.

The WindowDeclarativeItem wraps and controls a QGraphicsView and adds the
mainItem to its scene. The GraphicsView takes care of rendering a plasma
styled background (dialogs/background) with the required hacks to ensure
that KWin gets the correct translucent elements. Shadow is currently not
yet provided - this should be added in an internal way without the X
roundtrips.

Remove QDeclarativeView from DeclarativeScript

The view is never shown or used in any way except to create the
QDeclarativeEngine. So instead of using a view as a wrapper, let's create
a QDeclarativeEngine and a Component and create the script from the
Component.

To have Plasma.Dialog working we also need to add the created script item
to a QGraphicsScene.

Diffs

  • kwin/CMakeLists.txt (f0795b4873ac58a06c737b200559fa76e3c9c11e)
  • kwin/scripting/scripting.h (db85e23663e475af155235cac6851ef0c5767dc9)
  • kwin/scripting/scripting.cpp (e124827174317ab6adbfdb90cec796a02e7bd2b7)
  • kwin/scripting/windowdeclarativeitem.h (PRE-CREATION)
  • kwin/scripting/windowdeclarativeitem.cpp (PRE-CREATION)
  • kwin/scripts/desktopchangeosd/contents/ui/osd.qml (af49d45a30fcc6082e181971c1965e35763cf406)

View Diff
--===============0086134550596757974==-- --===============6062203197222835880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============6062203197222835880==--