Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?

[Martin Graesslin]

On Sunday, December 11, 2016 8:14:26 PM CET Michail Vourlakos wrote:
> On 11/12/2016 11:23 πμ, Martin Graesslin wrote:
> > On Sunday, December 11, 2016 10:11:14 AM CET Michail Vourlakos wrote:
> >> On 09/12/2016 06:30 μμ, Martin Graesslin wrote:
> >>> https://cgit.kde.org/plasma-framework.git/tree/src/plasmaquick/dialog.cp
> >>> p
> >>> 
> >>> the property in question is outputOnly. But it looks like that's only
> >>> using an input shape which might (?) not help you.
> >> 
> >> I ll' have a look Martin, thanks a lot again...
> >> 
> >>>> If I set :
> >>>> 
> >>>> KWindowSystem::setType(m_dockWindow->winId(), NET::Dock);
> >>>> 
> >>>> my dock is always on top and I can never lower it below normal
> >>>> windows..
> >>> 
> >>> Well yes, that's the idea of a Dock. Of course it's on top of all
> >>> windows. If you don't want that, don't use a dock.
> >>> 
> >>> On X11 KWin supports windows can cover through having a dock set to keep
> >>> below. But that won't work on Wayland and thus I heavily recommend
> >>> against it.
> >> 
> >> I want a Dock that lowers itself (becomes "Keep Below") based on
> >> criteria for example
> >> only when the Active window or a Maximimzed one is covering the dock.
> > 
> > This needs support from the window manager. You cannot do that from the
> > window side, I'm sorry. The stacking order supported by window managers
> > is explained in
> > https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#STACKI
> > NGORDER
> I added  a state in my code which can be used in wayland in which the
> various visibility states
> are not lowering the dock but instead they create an intelligent
> slide-out of the contents and
> then masking the window in order to give this space to underneath
> windows. So this is something
> like an intelligent auto-hide based on active windows or fullscreen windows.

Sounds good. On Wayland it should be way easier for us to support this case. 
At least we support changing types, etc. Which is not allowed on X11.

> I thought that libtaskmanager is accessing KWayland in order to track the
> active window and the windows geometries,

Yes, you can use either libtaskmanager or KWayland directly.

> isnt this possible to be used also from my code? the dock window is
> going to be always a dock type
> this way...
> 
> 
> 
> KWin is great but for my dock case has some limitations which are
> breaking a bit the experience:
> 1. plasma's auto-hide mode doesnt work good with my dock because when it
> is auto hidden it doesnt update its contents.

That's either a Qt or a OpenGL limitation. At least on X11 the window is still 
there, and still visible, just not rendered by KWin.

It's quite likely that Qt doesn't really understand what's going on and 
doesn't render because it thinks it's not visible.

> It is out of screen

it's not out of screen. It's just not rendered.

> thus the various animations for adding/removing
> tasks etc are playing when the dock is shown
> again.
> 2. pop ups in window type Dock are not calculated correctly in my dock
> case. KWin takes into account that because
> a window is a Dock all its space is used and shown always and thus show
> the various pop-ups from
> the plasmoids far away from the element that triggered them. My dock
> uses masking for its window and thus
> an element that triggers a pop-up can be far away from the edge of the
> window

That's not KWin either. That's Plasma. Plasma positions it's windows itself, 
KWin honors the position hints Plasma uses. If a Plasma window is misplaced, 
it's Plasma's fault. (You see I love blaming other projects :-P ) On Wayland 
we even go a step further and don't do any sanity checking on the positions 
Plasma provides. Normally windows on Wayland are always placed by the window 
manager, except for Plasma.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?

[Martin Graesslin]

On Sunday, December 11, 2016 10:11:14 AM CET Michail Vourlakos wrote:
> On 09/12/2016 06:30 μμ, Martin Graesslin wrote:
> > https://cgit.kde.org/plasma-framework.git/tree/src/plasmaquick/dialog.cpp
> > 
> > the property in question is outputOnly. But it looks like that's only
> > using an input shape which might (?) not help you.
> 
> I ll' have a look Martin, thanks a lot again...
> 
> >> If I set :
> >> 
> >> KWindowSystem::setType(m_dockWindow->winId(), NET::Dock);
> >> 
> >> my dock is always on top and I can never lower it below normal
> >> windows..
> > 
> > Well yes, that's the idea of a Dock. Of course it's on top of all
> > windows. If you don't want that, don't use a dock.
> > 
> > On X11 KWin supports windows can cover through having a dock set to keep
> > below. But that won't work on Wayland and thus I heavily recommend
> > against it.
> 
> I want a Dock that lowers itself (becomes "Keep Below") based on
> criteria for example
> only when the Active window or a Maximimzed one is covering the dock.

This needs support from the window manager. You cannot do that from the window 
side, I'm sorry. The stacking order supported by window managers is explained 
in 
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER

> I
> found
> a workaround for this that in X works great but I dont think it will help in
> wayland.. In X I am setting my dock as Qt::Tool and then I am changing its
> state

You cannot do that! Changing the window type is not supported at runtime. If 
you set it before you just made it no dock at all.

> to "Keep Below" and "Keep Above" when it is needed... In my c++ part I
> have made an
> abstraction in order to support X and wayland differently...
> 
> So Martin, In wayland isnt possible for a window to set itself to "Keep
> Below"?

No, on Wayland a window cannot set itself to keep below. For Plasma windows we 
do that in a more semantic way, e.g. a window says it's a Panel with windows 
can cover.

Cheers
Martin



signature.asc
Description: This is a digitally signed message part.

Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?

[Martin Graesslin]

On Thursday, December 8, 2016 8:53:00 PM CET you wrote:
> > The problem here is clearly that your window is still accepting focus. If
> > it doesn't accept focus KWin will skip it. So verify with xprop and
> > xwininfo that the window is really excluding focus.
> 
> Where do I look Martin? I am sending my outputs...
> How do I really exclude focus except setting?

Checking from KWin code: a window is included in window switching if it is
a normal or dialog window and wantsInput. WantsInput is a check for whether 
the window supports the TakeFocusProtocol.

In your case: it's a normal window (_NET_WM_WINDOW_TYPE(ATOM) = 
_KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL)

and it supports the take focus protocol (WM_PROTOCOLS(ATOM): protocols  
WM_DELETE_WINDOW, WM_TAKE_FOCUS)

Thus KWin includes it in the switcher.

In the case of the XCB Qt plugin the ordering of the calls is important. You 
need to set such flags before the window is created. Calls to KWindowSystem can 
destroy it again.

If you want to check how it's done: look at the Plasma::Dialog class which 
supports a no input mode for the OSD.

> 
>  > m_dockWindow->setFlags(Qt::WindowDoesNotAcceptFocus |
> 
> Qt::FramelessWindowHint);
> 
> Is there a way if I set my dock with:
>  > KWindowSystem::setType(m_dockWindow->winId(), NET::Dock);
> 
> to be able to lower it afterwards?

What do you mean with "lower it"?

Cheers
Martin

> 
> 
> Thanks a lot
> 
> regards,
> michail
> 
> 
> --
> 
> xwininfo: Window id: 0x6a00030 "Plasma"
> 
>Absolute upper-left X:  0
>Absolute upper-left Y:  901
>Relative upper-left X:  0
>Relative upper-left Y:  0
>Width: 1680
>Height: 149
>Depth: 32
>Visual: 0x72
>Visual Class: TrueColor
>Border width: 0
>Class: InputOutput
>Colormap: 0x6a0002f (not installed)
>Bit Gravity State: NorthWestGravity
>Window Gravity State: NorthWestGravity
>Backing Store State: NotUseful
>Save Under State: no
>Map State: IsViewable
>Override Redirect State: no
>Corners:  +0+901  -0+901  -0-0  +0-0
>-geometry 1680x149+0-0
> 
> ---
> xprop:
> _KDE_NET_WM_ACTIVITIES(STRING) = "----"
> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE,
> _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE,
> _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ,
> _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP,
> _NET_WM_ACTION_CLOSE
> WM_STATE(WM_STATE):
>  window state: Normal
>  icon window: 0x0
> _NET_WM_USER_TIME(CARDINAL) = 56530163
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP,
> _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
> _NET_WM_DESKTOP(CARDINAL) = 4294967295
> _NET_WM_ICON(CARDINAL) =Icon (16 x 16):
> 
> XdndAware(ATOM) = BITMAP
> WM_NAME(STRING) =
> _NET_WM_NAME(UTF8_STRING) = "Plasma"
> _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 55504946
> _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
> _NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE,
> _NET_WM_WINDOW_TYPE_NORMAL
> _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
> WM_CLIENT_LEADER(WINDOW): window id # 0x6ad
> WM_HINTS(WM_HINTS):
>  Client accepts input or input focus: False
>  Initial state is Normal State.
> _NET_WM_PID(CARDINAL) = 28689
> _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 49105
> WM_CLASS(STRING) = "plasmashell", "plasmashell"
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS,
> _NET_WM_PING, _NET_WM_SYNC_REQUEST
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>  user specified location: 0, 901
>  user specified size: 1680 by 149
>  window gravity: Static
> 
> 



signature.asc
Description: This is a digitally signed message part.

Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?

[Martin Graesslin]

On Thursday, December 8, 2016 7:17:31 PM CET Michail Vourlakos wrote:
> Hello everyone,
> 
> in NowDock I have managed to subclass a QuickWindow in order to provide
> masking and various visibility states for the dock.
> 
> In all the visibility states I am setting for this subclassed window:
> 
> m_dockWindow->setFlags(Qt::FramelessWindowHint|Qt::WindowDoesNotAcceptFocus)
> ; KWindowSystem::setState(m_dockWindow->winId(), NET::SkipTaskbar |
> NET::SkipPager);
> 
> 
> but even though the above code enables me to make my dock ontop or
> onbottom when I need it, it doesnt hide my dock from the "present
> windows effect" and from the "Alt+Tab". I tried to use:
> 
> KWindowSystem::setType(m_dockWindow->winId(), NET::Dock);
> 
> m_dockWindow->setFlags(m_dockWindow->flags() ^ (Qt::WindowStaysOnTopHint));
> 
> 
> but it didnt help, the dock is still shown in the window effects

There is no way for a window to hint that it should be excluded from 
switchers. Only inside KWin there is a windows-specific rule to exclude windows 
from switchers.

The problem here is clearly that your window is still accepting focus. If it 
doesn't accept focus KWin will skip it. So verify with xprop and xwininfo that 
the window is really excluding focus.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Touchpad Gestures - Experimental

[Martin Graesslin]

Hi Jens,

I'm extremely sorry, there must have been a huge misunderstanding.

Most of the gestures you came up with are not at all supported. We only get 
the following touchpad gestures reported:

* multi-finger pinch/rotate gesture
* multi-finger swipe gesture

The supported gestures are documented at https://wayland.freedesktop.org/
libinput/doc/1.5.0/gestures.html

Anything else is reported as a (mouse) pointer movement/press/release. It's 
not at all reported as touchpad event.

Also there is no palm events. If you rest your palm on the touchpad the 
underlying technology detects it and goes "let's ignore that".

I'm very sorry, but overall this looks like a lot has to be removed from the 
draft document again.

I don't really understand why the supported options where not verified with me 
before starting to design the document.

I'm very, very sorry that you created such a great document, which now can 
only be partially used.

Martin

On Thursday, November 24, 2016 3:19:28 PM CET Jens Reuterberg wrote:
> Sry for long wait, there was some misunderstandings concerning touchpad
> gestures based on past work and was set right today that no matter on what
> level we where at, we should pass it onward.
> 
> So these are all based on the normal assumptions and understanding of how
> designing something which we don't know the technical limitations of will
> work.
> 
> This it is the design of a pattern, a language (since otherwise its just
> another desktop cube or burning closing of windows) - so if one isn't
> possible, chances are we are back to square one. For example, most of these
> have to do with Windows and Workspaces (giving a quick nod to apps in Pinch-
> to-zoom and Rotate) which is intentional. Also note that Windows and
> Workspaces use four fingers to control things, which is also intentional
> (with the exception of the Pinch manouver which is really tricky to do with
> four fingers in the little available testing I could do). The actions
> SHOULD mimic each other so that each one isn't one more complex detail
> unrelated to everything else that the user have to learn.
> 
> While "Four fingers reserved for WM/DE" is a good guide some care have to be
> taken since cramming four fingers onto a touchpad can be tricky. The
> question is if it is technically possible. If not, should "three fingers
> reserved for WM/DE" replace it? This is impossible to tell now of course.
> 
> This is a link to the draft of the design document:
> https://notes.kde.org/p/touchpadgestures
> 
> The document is split into
> 1) Design Notes (information about the idea of the design)
> 2) Possible Actions (list of Actions mostly focusing of course (see above)
> on the WM/DE)
> 3) Possible Gestures (a list of gestures ranging from unused now, to
> probably impossible technically)
> 4) Suggested Combinations (suggested to be implemented as standards)
> 5) Notes and planning (some notes on planning for the future and the
> problems we will run into design wise)
> 6) (For reference) Touch Screen notes (early notes of a talk between me and
> Aleix about touchscreens where the initial idea of "reserve N finger actions
> to DE/WM came from)
> 
> Finally - these are of course all experimental and tentative design.
> Anything else would be practically impossible.



signature.asc
Description: This is a digitally signed message part.

Stepping down as KGlobalAccel maintainer

[Martin Graesslin]

Hi frameworks developers,

I decided to step down as the maintainer of KGlobalAccel. I haven't done any 
work on KGlobalAccel this year and bug reports just linger. A big problem for 
me maintaining KGlobalAccel is that most work is needed in the X11 
implementation. As I no longer use X11 and cannot simulate it under Wayland I 
don't think I'm in any position to further maintain KGlobalAccel. Also this is 
something I don't expect to change in future. I don't see myself switching 
into an X11 session just to investigate a bug in KGlobalAccel.

I hope that we find an interested developer to take over the maintainership. 
Best would be someone with X11 knowledge.

Best Regards
Martin Gräßlin

Re: macro_bool_to_01 macro in plasma-workspace/ConfigureChecks.cmake

[Martin Graesslin]

On Friday, October 28, 2016 11:24:35 AM CEST René J.V. Bertin wrote:
> Hi,
> 
> Where exactly is plasma-workspace's build system supposed to find the
> macro_bool_to_01 macro? Apparently it's been obsolete for quite some time
> and it doesn't seem to be provided by any of the listed dependencies (= I
> get a not-found error).

I wouldn't exclude the possibility that this is old and dead/non-functional 
code. I just did a git grep for every of the CMake variables se through the 
macro_bool_to_01 and only found:

dataengines/mouse/CMakeLists.txt:if (X11_Xfixes_FOUND)
dataengines/mouse/CMakeLists.txt:if (X11_Xfixes_FOUND)
dataengines/mouse/CMakeLists.txt:   
target_link_libraries(plasma_engine_mouse ${X11_Xfixes_LIB})

and that code while having it in the CMakeLists being used uses in the code
#ifdef HAVE_XFIXES

(which is wrong, should be #if HAVE_XFIXES)

So overall looks rather dead to me.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: breakout: what Qt version will 5.9 require? 5.6 still or 5.7?

[Martin Graesslin]

On Thursday, October 20, 2016 7:07:29 AM CEST Sebastian Kügler wrote:
> On Monday, October 17, 2016 6:06:41 PM UTC Jonathan Riddell wrote:
> > no discussion on this on during the meeting, do we need 5.7, are
> > distros happy with 5.7?
> 
> We discussed it in the other thread, the conclusion is that we'd like to
> depend on 5.7 in Plasma 5.9.
> 
> The question whether that works for distros remains. If we don't hear the
> opposite, we assume it does. :)

I just asked on the distro mailing list:
https://mail.kde.org/pipermail/distributions/2016-October/000137.html

If we don't hear anything negative I'd say we start raising the requirement on 
Nov 1st. I'm happy to do so in KWin by starting requiring QtVirtualKeyboard 
;-)

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Martin Graesslin]

On Monday, October 17, 2016 5:59:05 PM CEST Jonathan Riddell wrote:
>  biggest pain point from bugzilla is mostly still
> multiscreen. I'm not sure we have a solid plan of what /should/ happen
> in each situation.
>  panel gets added to screen 1 and 2, you disconnect screen
> 2. How many panels do you have on screen 1

Adding something we see regularly in KWin: windows should store their position 
in relation to the screen they are on. E.g. you have window A on screen 1, 
then you add and move it to screen 2, unplug screen 2, kwin will put it on 
screen 1 and it's not where it was last on screen 1.

Other issues we regularly get reported is windows not opening on the screen 
the user expects them to open. Mostly a problem, because on X11 almost every 
application provides a positioning hint which kwin honors.

Both issues are unfixable with X11. And even on Wayland we kind of would need 
to know what the user wants. Which  is hardly possible.

With my window manager hat on, I'm nowadays convinced that there are two/three 
different usage strategies:
1: static setup with two screens. System should ideally have virtual desktop 
per screen, window management super important
2: notebook with docking station: like 1, but dynamic
3a: notebook with external extended projector: no window should ever go to the 
external screen except the ones added there
3b: static system with an external (off) TV: only used for kodi/vlc. No window 
should ever go there

Of course this is all highly dynamic. A system like 2 might turn into 3a at 
any time.

Taking the panel question from above: it depends on the usage pattern we are 
in. In 1 and 2 it should only be one panel, in 3a it should be 2, in 3b I have 
no idea.

And of course the question related to window management also depends on the 
usage strategy.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Plasma 5.8 Errata

[Martin Graesslin]

On Tuesday, September 13, 2016 12:43:21 PM CEST Thomas Pfeiffer wrote:
> On 13.09.2016 12:22, Martin Graesslin wrote:
> > Sorry, but I have seen enough bug reports set to critical and priority
> > very
> > high by the user. As long as users can modify that we will have stupidly
> > set up bug reports.
> 
> Wait, ordinary users can change the priority field??? That makes literally
> _no_ sense at all (for any project).
> Shouldn't we just get the access rights fixed, then? It's a no-brainer to
> me.
> >> For such a process to work well, it would make sense to triage all bugs,
> >> set the priority field and then filter for e.g. VHI. Or the alternative
> >> would be to just change the severity field if you disagree with the
> >> reporter.> 
> > Yes that is the "ideal world". Reality is: you triage the bug, adjust the
> > field and user changes back. (Including when I move the component). Or it
> > triggers a discussion of "why did you set it back to normal, that is
> > critical". And then you waste your time explaining.
> 
> Users being able to change the priority field is just a bug in our access
> rights setup.
> Triggering discussions, oh well, that is just unavoidable in an open
> project, and publicly saying
> "Nope, we won't change that" is better communication than just silently
> ignoring people.
> 
> > This process is broken beyond repair as long as users are able to change
> > these settings. Sorry that I sound so negative, but I have a huge amount
> > of open bugs and a huge experience. Bugzilla is in that regard - at least
> > in our setup - a total failure for projects with large amount of bug
> > reports like KWin and Plasma.
> > 
> > In that regard our bugzilla instance is unable to help us prioritize any
> > bugs or to manage them properly.
> 
> Indeed. I wasn't aware that users were allowed to change the priority field.
> I will file a sysadmin ticket to fix this.

The problem is not the priority field. The problem is the process. This is all 
extremely frustrating if you have a large number of bugs. Having a priority 
field is nice, nobody uses it and it won't save bugzilla. The process is 
broken.

We have no chance to properly triage bugs because users can change the 
components. We have discussions whenever we change the severity, we will have 
discussions if we would use priorities. This is derailing, time consuming and 
just a sign of a broken process. Over the last 365 days 547 bugs and 42 
feature requests were reported against kwin (plasmashell is at 2495 new bugs + 
158 feature requests). Those bugs (in case of kwin) were handled by two 
persons. Do you think we care about priorities? We are glad enough if we don't 
get drowned in the amount of bugs we get in. From these 500 new bugs perhaps 
50 are valid and actual bugs which need fixing. Everything else is duplicates, 
driver issues, user support, misconfiguration, misunderstanding of features, 
etc. etc. The process is broken beyond repair.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

Re: Plasma 5.8 Errata

[Martin Graesslin]

On Tuesday, September 13, 2016 12:09:26 PM CEST Thomas Pfeiffer wrote:
> On 13.09.2016 07:52, Martin Graesslin wrote:
> > On Monday, September 12, 2016 12:55:22 PM CEST Jonathan Riddell wrote:
> >> I've copied over the 5.7 Errata page for 5.8
> >> 
> >> Do we still have issues with Intel GPUs?
> >> 
> >> Are there still freezes with Qt 5.6?
> >> 
> >> Are the bugs marked critical still critical?
> > 
> > I looked through them and none of them is IMHO critical. The state was in
> > all cases selected by users and as we know: just because a user things
> > something is critical doesn't make it critical ;-)
> > 
> >  From the list I would suggest to not look at it for the next release. It
> >  just> 
> > doesn't make any sense as long as users can mark bugs as critical.
> > 
> > Cheers
> > Martin
> 
> That's why there is both criticality (set by the user) and priority (set by
> the team).

Sorry, but I have seen enough bug reports set to critical and priority very 
high by the user. As long as users can modify that we will have stupidly set 
up bug reports.

> 
> For such a process to work well, it would make sense to triage all bugs, set
> the priority field and then filter for e.g. VHI. Or the alternative would
> be to just change the severity field if you disagree with the reporter.

Yes that is the "ideal world". Reality is: you triage the bug, adjust the field 
and user changes back. (Including when I move the component). Or it triggers a 
discussion of "why did you set it back to normal, that is critical". And then 
you waste your time explaining.

This process is broken beyond repair as long as users are able to change these 
settings. Sorry that I sound so negative, but I have a huge amount of open 
bugs and a huge experience. Bugzilla is in that regard - at least in our setup 
- a total failure for projects with large amount of bug reports like KWin and 
Plasma.

In that regard our bugzilla instance is unable to help us prioritize any bugs 
or to manage them properly.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

Re: Plasma 5.8 Errata

[Martin Graesslin]

On Monday, September 12, 2016 12:55:22 PM CEST Jonathan Riddell wrote:
> I've copied over the 5.7 Errata page for 5.8
> 
> Do we still have issues with Intel GPUs?
> 
> Are there still freezes with Qt 5.6?
> 
> Are the bugs marked critical still critical?

I looked through them and none of them is IMHO critical. The state was in all 
cases selected by users and as we know: just because a user things something 
is critical doesn't make it critical ;-)

From the list I would suggest to not look at it for the next release. It just 
doesn't make any sense as long as users can mark bugs as critical.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: On-screen keyboard on plasma

[Martin Graesslin]

On Tuesday, September 13, 2016 1:41:36 AM CEST Aleix Pol wrote:
> Hello,
> Recently a convertible appeared on my hands. I was looking into seeing
> how it works with Plasma.
> Then I eventually wanted to type something.
> 
> I'm not sure if having a keyboard is just unsupported or I'm missing
> something. Can I have some pointers?

You need:
* Qt 5.7
* QtVirtualKeyboard module installed
* Wayland session

With that combination you can have the virtual keyboard to show for Qt 
(Wayland) applications. The keyboard shows automatically if there is no 
hardware alpha-numeric keyboard attached (idea here is that with a convertible 
we disable the keyboard when switching to tablet mode). Otherwise there is a 
SNI in the hidden section where you can enable it.

Further plans:
* Make it work on lockscreen
* Ensure keyboard doesn't cover windows
* Add maliit support for GTK and X applications
* bring it to X11 (only makes sense with maliit)

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

Re: Animate plasma tooltip windows?

[Martin Graesslin]

On Monday, September 12, 2016 2:21:16 AM CEST Michail Vourlakos wrote:
> Hello everyone,
> 
> 
> I am using in one of my plasmoids the following,
> 
>  PlasmaCore.Dialog{
>  id: windowsPreviewDlg
>  type: PlasmaCore.Dialog.Tooltip
>  location: plasmoid.location
> 
> ...
> 
> }
> 
> 
> because I can not use the ToolTipArea, I need hovering very much for the
> whole element... The above code works but unfortunately it does not
> animate the window when I change its visualParent even though it has
> been set as Tooltip. I tried using
> 
> Behavior on x and y but it didnt help...

Please never try to animate by adjusting x/y of a window. On X11 that creates 
lag and on Wayland it just doesn't work.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

[RFC] Modifier only shortcuts on X11

[Martin Graesslin]

Hi Plasma devs,

I just created an RFC-phab request: https://phabricator.kde.org/D2425

This implements modifier-only global shortcuts on X11 reusing KWin's internal 
architecture written for Wayland.

What I want to know is whether it's worth something to follow up. We know that 
this is a feature wanted by many, so I want to explain why we don't have it 
yet and what this change does differently.

The main problem with modifier as shortcut is that it doesn't work with 
kglobalaccel. KGlobalAccel does a passive grab on the shortcuts. That is it 
will be notified when e.g. Alt+Tab is pressed. Other clients are then not 
informed about Alt+Tab being pressed. If we would do that for modifiers we 
would steal them and break everything.

Thus the normal architecture in kglobalaccel just cannot support modifier only 
shortcuts. What we would need is to listen to all key events once a modifier is 
pressed to detect when it's released. Which doesn't work as soon as another 
client grabs the keyboard (e.g. alt to open in-app menu) and again 
kglobalaccel cannot grab them.

Overall there are just many situations where it might happen that we don't 
detect properly that the modifier got pressed/released. That's also why I 
always was against us supporting ksuperkey by default.

What does my suggested change differently?

The suggested change uses XInput2.2 to listen to all Raw key events. That is 
KWin gets all raw keys reported, even when another client grabs the keyboard. 
This is just like on Wayland with libinput: kwin gets all key events.

On Wayland KWin sends all key events through Xkb to get the transformation 
into key codes and modifiers. Based on that KWin can detect when a modifier is 
pressed/released without anything else interfering.

And that is what the change does: all raw key events are sent through Xkb, so 
all the existing infrastructure gets reused.

This turns KWin into a key logger, makes it wake up on every key event. The 
change will need some more work and I want to know from you whether it's worth 
the effort and whether that's something we want to ship by default in 5.8.

I think this implementation will allow us to get the modifier-only shortcut 
work as expected.

Why in KWin and not in KGlobalAccel?
The X11 implementation could also be done in KGlobalAccel. On Wayland it needs 
to be in KWin and it's in a place inside KWin before the key event gets 
filtered through kglobalaccel. We would need to duplicate the logic.

Credits!
Credits go to Kai for complaining about screenedges on X11 stealing mouse 
clicks while I was fixing a bug in the XInput2 polling code which made me 
realize that we can raw events for way more than just mouse position tracking.

So what do you think?
Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Plasma desktop window uses RGBA

[Martin Graesslin]

On Tuesday, August 9, 2016 11:16:33 AM CEST Martin Graesslin wrote:
> Hi all,
> 
> I just noticed that Plasma's desktop window uses an RGBA format. This is not
> only completely pointless as it's the bottom most window, it's also
> destroying all optimizations in KWin. KWin always has to go into the
> blending code path, which means rendering from bottom to top instead of
> rendering from top to bottom. And also KWin always has to clear the color
> buffer before rendering the Plasma desktop window.
> 
> Anyone an idea how we can change this?

Forcing in KWin with: D2382

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.

Plasma desktop window uses RGBA

[Martin Graesslin]

Hi all,

I just noticed that Plasma's desktop window uses an RGBA format. This is not 
only completely pointless as it's the bottom most window, it's also destroying 
all optimizations in KWin. KWin always has to go into the blending code path, 
which means rendering from bottom to top instead of rendering from top to 
bottom. And also KWin always has to clear the color buffer before rendering 
the Plasma desktop window.

Anyone an idea how we can change this?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Failing unittests

[Martin Graesslin]

On Saturday, August 6, 2016 8:12:06 PM CEST David Faure wrote:
> Today is KF 5.25 tagging day, but the CI isn't green...
> kwayland: testWaylandFullscreenShell fails

Sorry about that. It's caused by a newer weston version [1] which got 
installed on Friday on build.kde.org. I just pushed a fix which QSKIPs if the 
old interface is not announced.

Cheers
Martin

[1] The Weston specific fullscreen shell extension got moved to Wayland 
Protocols and renamed to the conventions there.



signature.asc
Description: This is a digitally signed message part.

Re: From Grub to Shutdown project update

[Martin Graesslin]

On Monday, August 1, 2016 10:49:16 AM CEST Harald Sitter wrote:
> On Mon, Aug 1, 2016 at 8:35 AM, Martin Graesslin <mgraess...@kde.org> wrote:
> > On Monday, July 25, 2016 12:24:56 PM CEST Jens Reuterberg wrote:
> >> KSPLASH
> >> Ksplash is removed in favour for two clear effects, one is the "fade to
> >> desktop" already present in Kwin, the other is an effect where SDDM fades
> >> in a very specific way. (the SDDM interface fades leaving only the
> >> chosen logged in users avatar fading slightly slower (can be seen in the
> >> thumbnail gif named "SDDMfade")
> >> Essentially SDDM fades, and then directly as part of it visually, a fade
> >> to
> >> desktop.
> > 
> > Removing KSplash directly breaks the login effect (I assume that's what is
> > meant with "fade to desktop"). It gets activated by the ksplash window
> > closing and then fades out the ksplash window.
> > 
> > I don't see how this can be done in a Wayland world. (Neither do I see how
> > this can be done in a X11 world). To explain: When switching from SDDM to
> > KWin/Wayland, KWin takes over the display, SDDM is no longer able to
> > render to it.
> 
> Deceit and trickery! ;)
> 
> I think the important bit is that visually it needs to look like SDDM
> is doing the lifting, whether or not it actually does is
> inconsequential to the visual result.
> 
> 3 ways this can be done:
> 
> 1) Fading to black: SDDM fades to black before starting the session.
> The first thing the session does is paint black, launches something
> that sits on top of everything else (a ksplash, if you will ;)), this
> something continues to be black until it fades to desktop. This
> obviously doesn't work on HDD so let's ignore this option because it
> is stupid.
> 
> The other 2 options imply an interaction between the DM and something
> in the session.
> 
> 2) Now you see me... now you don't: The last thing SDDM does is take a
> "screenshot" of itself. It puts that into some file with a very unique
> and predictable path. A something in the session (again, a ksplash, if
> you will) picks up the file and draws it on screen and then does some
> animation (which will natrually be limited). Obvious concern here is
> that this won't be able to properly reflect resolution switches since
> all that can be done in the session is image manipulation at this
> point. On the plus side it should be fairly cheap to implement and
> might be a good first step.
> 
> 3) Meta-meta-meta-programming: Our SDDM theme is QML, KSplash is QML.
> Before session start the theme either serializes its dataset into some
> file with a predictable path, a something in the session now loads the
> dataset AND SDDM's actual QML files and entirely replicates the state
> the UI was in on the SDDM. A variation of this, which might well be
> harder to do, is fully fixing up the QML files. Namely the theme
> itself dumps its own QML but instead of Label { text: variable } it
> uses it's state i.e. Label { text: "Kitten" }. By rendering the theme
> QML in the session we can accurately handle whatever happens during
> session startup, it is for all intents and purposes like a shared code
> base for SDMD and KSplash at that point. Whether or not this actually
> has use over option 2 I can't say, it certainly sounds cooler in my
> mind ;)

On X11 the option 2 could be simplified: sddm renders it's last screenshot into 
the root window, when ksplash starts it grabs the content from the root window 
and uses that as the background. But the same problem as you already wrote: 
it's problematic with multi-screen and resolution changes. Also this approach 
only works if there is no compositor running (which is true at the early 
startup phase).

> 
> Seeing as I know nothing about wayland I am not sure if this can be
> done better there.

It's pretty much the same on Wayland. The startup in KWin is to render a black 
screen to perform the initial mode setting. That could also be a different 
image.

From that time on the compositor is running which always renders a black 
background and the windows on top of it.

> 
> (Also random note: SDDM's UI is run as an own process 'sddm-greeter',
> I suppose one could actually have that "jump" outputs? I.e. one minute
> it's on sddm's X, the next it is on the session X)

That can only work if it's still the same X. If a new X is started for the 
user session it won't work, neither for switching to Wayland.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: From Grub to Shutdown project update

[Martin Graesslin]

On Monday, July 25, 2016 12:24:56 PM CEST Jens Reuterberg wrote: 
> KSPLASH
> Ksplash is removed in favour for two clear effects, one is the "fade to
> desktop" already present in Kwin, the other is an effect where SDDM fades in
> a very specific way. (the SDDM interface fades leaving only the chosen
> logged in users avatar fading slightly slower (can be seen in the thumbnail
> gif named "SDDMfade")
> Essentially SDDM fades, and then directly as part of it visually, a fade to
> desktop.

Removing KSplash directly breaks the login effect (I assume that's what is 
meant with "fade to desktop"). It gets activated by the ksplash window closing 
and then fades out the ksplash window.

I don't see how this can be done in a Wayland world. (Neither do I see how 
this can be done in a X11 world). To explain: When switching from SDDM to 
KWin/Wayland, KWin takes over the display, SDDM is no longer able to render to 
it.

May suggestion thus is to keep KSplash and just change the design.

> Critical Notes #1: if this handoff between SDDM and Ksplash is impossible
> for technical reason or will stutter another plan must be drawn up. The
> goal here is speed - if speed can be improved by having the animation
> SOLELY in SDDM and ignoring Ksplash then that is better.
> For this reason we need technical input and help testing.
> Critical Notes #2: The SDDM theme can switch wallpaper, the wallpaper being
> the LAST thing seen in combination with the logged in users avatar - its
> relevant that the this work if the user switch wallpaper so that the
> wallpaper is the last seen instead of "stock blue".

See above: I don't think it's technically possible. Starting KSplash does not 
create a delay, it's a fast application.

> LOCK SCREEN
> https://share.kde.org/index.php/s/0WRG8Us8qElwgDP
> Thumbnail Animation: https://share.kde.org/index.php/s/DR1HV3d9HRHRigJ
> 
> The locks screen has to share the basic concept of the SDDM screen as it is
> in practice, from the users perspective, almost the same thing.
> Thats why it inherits the stock-blue background (editable from the
> lockscreen settings).
> When the lockscreen is actvated it displays a swift fade-to-black from
> desktop and an even quicker fade-FROM-black to lockscreen. The goal is to
> make a swift switch and make it feel more like a secure door slamming than
> a slow fade. If that feels too complex this late in the release cycle a
> temporary solution is just a direct switch, ignoring all animations.

I can take care of adjusting the default background to the blue. Note that for 
technical reasons it might cause a black frame to be rendered first.

> SHUTDOWN/LOCK/ETC
> https://share.kde.org/index.php/s/YojnHEhf6qUmHLu
> 
> When a user press shutdown, lock and logout the desktop fades, darkens, and
> an overlay black at 70% opacity pops up the logout options are displayed
> with the one the user selected preselected and in the center, from there
> the user can use mouse or arrows to move to another option, like go from
> the shutdown to reboot. The selected option is fully opaque and white
> (#ff) and the not selected options are at 60% opacity and light grey
> (#eff0f1)

Do I understand correctly that you do no longer want the fade to the center? 
And that you don't want to blur the background at all? I think that needs 
real-world testing before removing the blur.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.8 and openSUSE 42.2

[Martin Graesslin]

On Thursday, July 28, 2016 10:11:56 AM CEST Jonathan Riddell wrote:
> On Tue, Jul 26, 2016 at 03:56:21PM +0200, Antonio Larrosa wrote:
> > This mean bringing forward some kde release dates and postponing some
> > opensuse pre-releases to make everything fit tightly.
> > 
> > 2016-09-01: openSUSE 42.2 Beta 1 (this would include the last Plasma
> > release available at that time, 5.7.4 or 5.7.5)
> > 2016-09-08: Plasma 5.8 Repo Freeze (last day of Akademy, maybe that
> > could be moved to freeze the repo just before QtCon?)
> > 2016-09-15: Plasma 5.7.95 LTS (aka 5.8.0 Beta)
> 
> So Repo freeze a week earlier (during Akademy) then beta and
> everything else following two weeks earlier.
> 
> > So, my question is, would you agree with that? Anybody sees any problem
> > if both projects agree to those changes to their respective schedules?
> 
> It takes us back to a 3 month release scheule rather than 3.5 months
> which feels a bit too short for some people.  I don't know if people
> were expecting to use that extra time for features or not.
> 
> There's also the issue that if we move for one distro we'll end up
> with accusations of favouratism and requests for moving for other
> distros.  But then maybe we do like openSUSE :)

Nah, I don't think that's a problem. It's a special situation due to 5.8 being 
the first LTS. We won't move the schedule for the non-LTS releases as there is 
the LTS one now. Also for the next LTS one could say that distros should just 
stick to the previous one.

So I consider this as a one-time thing.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: "Software not found" Runner

[Martin Graesslin]

On Tuesday, July 26, 2016 2:17:32 PM CEST Aleix Pol wrote:
> On Tue, Jul 26, 2016 at 1:10 PM, Marco Martin  wrote:
> > On Tuesday 26 July 2016 13:01:10 Aleix Pol wrote:
> >> Hi,
> >> Last week I put together this runner, thought it might be useful, so
> >> if you type in krunner an application but it's not installed, it will
> >> offer to open Discover to install it (any software center in fact).
> >> 
> >> Do we want to push this for the next plasma release?
> >> If so, do we want it enabled by default?
> >> 
> >> You can look and test here:
> >> https://quickgit.kde.org/?p=scratch%2Fapol%2Fappstreamrunner.git
> > 
> > looks like a good idea.
> > maybe kdeplasma-addons?
> > i would be fine with having it enabled by default
> 
> I guess it would make sense in plasma-workspace if we want to enable
> it in kickoff.

Given the dependency to only appstream I would say that's plasma-workspace 
material. Especially as I think software management should be a core feature 
of a desktop environment ;-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible for a plasmoid to overlap the panel?

[Martin Graesslin]

On Thursday, July 21, 2016 11:25:21 AM CEST Michail Vοurlakos wrote:
> Στις Πέμπτη, 21 Ιουλίου 2016 7:31:20 Π.Μ. EEST Martin Graesslin έγραψε:
> > On Wednesday, July 20, 2016 8:53:03 PM CEST Marco Martin wrote:
> > > On Wednesday 20 July 2016 21:15:33 Michail Vοurlakos wrote:
> > > > Hello,
> > > > 
> > > > I am trying to implement a plasmoid task manager that behaves
> > > > like the Mac or the Plank one..
> > > > the code can be found here:
> > > > https://github.com/psifidotos/plasmaqmldock[1]
> > > > it is in a very early stage but the animation is there and showing
> > > > and hiding windows also...
> > > 
> > > I tought about an use case like that in the past...
> > > 
> > > you would need to have a very big panel, mostly completely transparent
> > > (so
> > > it means you couldn't use always visible mode, and you depend from
> > > having
> > > composite)
> > > but for 3rd party things may be ok-ish.
> > > 
> > > what the panel on our side would need to do, is not to draw its
> > > background
> > > in that case, basically just respect the background hints, just like
> > > applets do. I am thinking to add that never the less in 5.8, wouldn't
> > > change for the default one, but could be a little fun quirky possibility
> > > for kdelook stuff
> > 
> > Not drawing the background won't be enough: we also need to look at the
> > window manager story, which gets interesting for panels:
> > * background need to be input shaped
> > * strut must not be set on the whole window
> > 
> > Whether KWin would support that - I do not know. I could assume it would
> > still adjust the windows to the size of the panel.
> > 
> > Cheers
> > Martin
> 
> Do you think that if instead of not drawing the background of the panel, we
> were drawing a completely transparent background but disable blurring and
> shadows for It, the same problems arise?

yes that's all just visuals. If KWin starts to snap windows against it, it 
uses the geometry. Shadow, blurring etc. are ignored.

> 
> I use it currently in the panel, and actually it is almost doing its job...
> If you wanna give it a go, it is in:
> https://github.com/psifidotos/plasmaqmldock[1]
> 
> And this is a screenshot for the panel that has NowDock plasmoid in it,
> I loaded a full transparent desktop theme and disabled the blur effect.
> http://imgur.com/KuiKcQD[2]

Give it a try: move a window towards the dock. At some point it will start to 
snap against it.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

New repository plasma-tests

[Martin Graesslin]

Hi fellow plasma-developers,

we have a new repository called plasma-tests. This holds the test 
orchestration from plasma-workspace/shell/tests.

The tests got moved there as they were always timing out on plasma-workspace 
repository due to missing dependencies. In the new plasma-tests repository 
they are passing. Also plasma-workspace is now succeeding.

Please use this! We now have everything in place to run tests for plasmoids. 
If you have a bugfix, create a test case for it. If you do a new feature, 
create a test case for it. There is no excuse and also that there is no test 
yet is no excuse!

Also as plasma-workspace is now finally green: a failure in plasma-workspace 
needs to become a stop-the-show-thing now. Let's introduce the frameworks 
policy of no commits except for fixing the breakage.

Thanks all for helping making Plasma well tested!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible for a plasmoid to overlap the panel?

[Martin Graesslin]

On Thursday, July 21, 2016 12:03:26 AM CEST Michail Vοurlakos wrote:
> > > > it means you couldn't use always visible mode, and you depend from
> > > > having
> > > > composite)
> > > 
> > > - "Always visible" in that case I dont think is a necessity... But
> > > playing
> > > around with these docks, an option for panel to be just "Below Active"
> > > do
> > > you think that it would be very difficult to add in Plasma?
> > 
> > what is "beyond active"?
> 
> "Beyond Active" - The panel is hidden only when overlaps with the active
> window
> e.g. if you have an inactive window that does overlap with the panel, the
> panel is shown, but if that window becomes active then the panel is hidden
> behind it

That would have to go into KWin and would require adding a new layer to have 
the active window be raised above the DockLayer.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible for a plasmoid to overlap the panel?

[Martin Graesslin]

On Wednesday, July 20, 2016 8:53:03 PM CEST Marco Martin wrote:
> On Wednesday 20 July 2016 21:15:33 Michail Vοurlakos wrote:
> > Hello,
> > 
> > I am trying to implement a plasmoid task manager that behaves
> > like the Mac or the Plank one..
> > the code can be found here: https://github.com/psifidotos/plasmaqmldock[1]
> > it is in a very early stage but the animation is there and showing
> > and hiding windows also...
> 
> I tought about an use case like that in the past...
> 
> you would need to have a very big panel, mostly completely transparent (so
> it means you couldn't use always visible mode, and you depend from having
> composite)
> but for 3rd party things may be ok-ish.
> 
> what the panel on our side would need to do, is not to draw its background
> in that case, basically just respect the background hints, just like
> applets do. I am thinking to add that never the less in 5.8, wouldn't
> change for the default one, but could be a little fun quirky possibility
> for kdelook stuff

Not drawing the background won't be enough: we also need to look at the window 
manager story, which gets interesting for panels:
* background need to be input shaped
* strut must not be set on the whole window

Whether KWin would support that - I do not know. I could assume it would still 
adjust the windows to the size of the panel.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Martin Graesslin]

On Friday, July 15, 2016 10:22:32 AM CEST Elvis Angelaccio wrote:
> 2016-07-14 1:11 GMT+02:00 Albert Astals Cid :
> > El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> > 
> > escriure:
> >> Hi,
> >> thanks for raising this topic!
> >> 
> >> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
> >> > Hi everyone,
> >> > I'm addressing both the Plasma team and kde-devel because this issue
> >> > affects Plasma as well as many applications, and Valentin as the
> >> > current
> >> > maintainer of KWallet as well as KSecretService, a potential
> >> > replacement
> >> > for it.
> >> > 
> >> > KWallet plays a central role in Plasma and many KDE applications as the
> >> > central password storage. However, it being very old and not having
> >> > been
> >> > actively developed for a long time, it has lots of problems, including:
> >> > 
> >> > - It has weak security, as it does not restrict applications accessing
> >> > it
> >> > by default, and even when it does, it does so simply based on
> >> > application
> >> > name which allows any malicious process to impersonate an allowed one
> >> > - The initial setup has huge usability problems, as it forces users to
> >> > make
> >> > a choice on a very advanced technical level (encryption methods, no
> >> > less!),
> >> > and the option it suggests (GPG) is a nightmare to set up for ordinary
> >> > users - It does support unlocking via PAM, but does not tell users what
> >> > they need to do to make that work, which results in most users having
> >> > to
> >> > enter the KWallet password at each system start, which many find very
> >> > annoying (we get lots of negative feedback for that)
> >> > - It works only with KDE Frameworks-based applications
> >> > - One cannot easily write a QML GUI for it, making it unsuitable for
> >> > mobile
> >> > 
> >> > Valentin has been working on KSecretService for quite a while, which is
> >> > based on the freedesktop Secrets API [1] that is also supported in
> >> > GNOME
> >> > Keyring, and would solve many (and ideally all) of the above problems.
> >> > However, Valentin told me he does not have the time to work on
> >> > KSecretService any more.
> >> > 
> >> > This means we have to find a solution to these problems. The options I
> >> > see
> >> > currently are
> >> > - Improve KWallet (unlikely to fix all the problems without massive
> >> > changes
> >> > in it, though)
> >> > - Find someone to finish and maintain KSecretService
> >> > - Build a wrapper around one of the other existing keyring technologies
> >> > - Each application (and each Plasma component that stores passwords)
> >> > implements its own encrypted password storage
> >> > 
> >> > 
> >> > - We make encrypted password storage optional and non-default (easiest
> >> > solution, but not exactly in line with KDE's vision)
> >> 
> >> I disagree on this point. Even if KWallet were free of usability
> >> issues, it would still provide a false sense of security. The user
> >> thinks that his/her passwords are safe, while in fact they are not.
> > 
> > How exactly the passwords are not safe?
> 
> The default behavior is to keep wallets "open" once they have been
> decrypted. If a wallet is open, any process can trivially retrieve
> clear-text passwords from it using the KWallet API. I wanted to back my
> claim with some code, so I created a small PoC in [1]. All an attacker has
> to do is to guess the name of a wallet (and only if the default
> 'kdewallet' name is not used!).
> 
> I could also mention that KWallet accepts an empty master password,
> which alone is already bad enough.

yeah, once the wallet is open it's as secure as a simple plain-text file on an 
encrypted home. If the home is not encrypted kwallet does offer an advantage 
over a simple plain-text file.

If we assume that "if it runs, it's trusted" then everything is fine as well. I 
can see ways how this can be secure with containerized apps and e.g. dedicated 
privs the user has to acknowledge to have it read wallets. E.g. that a 
containerized app has to ask for password for application foo. This could 
offer a user a good and informed decision on whether to grant it or not.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] WindowMetadata framework fundamentals

[Martin Graesslin]

On Thursday, July 14, 2016 1:52:26 PM CEST Sebastian Kügler wrote:
> On Thursday, July 14, 2016 1:41:54 PM CEST Martin Graesslin wrote:
> > > > - currently open document
> > > 
> > > Don't most applications expose that in their window title, anyway?
> > 
> > Some do, some don't. Some put it at the start of their title, some at the
> > end.  Some add some character that the data is changed, some don't. Some
> > put the file name in brackets, some the complete path. Some have a config
> > option to control that.
> > 
> > What comes out of it is that the outside applications have no way to
> > gather
> > what the data is.
> 
> That struck me as well. The title field is actually just an example
> (probably a useful one), but of course we can expose more useful
> information, such as the path to the currently opened document, through
> this mechanism.
> 
> What information would be useful here?
> 
> - Title
> - Status
> - Document

- url
- mime/type 



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] WindowMetadata framework fundamentals

[Martin Graesslin]

On Wednesday, July 13, 2016 5:10:25 PM CEST Thomas Pfeiffer wrote:
> Hi sebas,
> 
> On 13.07.2016 02:18, Sebastian Kügler wrote:
> > During the Plasma sprint in March, we've been fleshing out plans to create
> > a mechanisms for apps to be represented by the shell.
> > 
> > The goals it to achieve a richer integration between apps and the
> > workspace. The idea is that windows can announce a richer set of metadata
> > that can be used to enhance the window's representation in the
> > workspace/shell. Think of
> > 
> > - task switchers with more meaningful thumbnails of better quality
> 
> Exciting times :)
> 
> > - server-side decoration actions to "remote-control" the app
> > - user-visible features similar to the mpris-controls in the task bar
> 
> So does that mean that parts (or all) of the DWD ideas will be implemented
> using WindowMetadata?

Yes that was always the idea. WindowMetadata is the framework which powers 
DWD.

> 
> > - currently open document
> 
> Don't most applications expose that in their window title, anyway?

Some do, some don't. Some put it at the start of their title, some at the end. 
Some add some character that the data is changed, some don't. Some put the file 
name in brackets, some the complete path. Some have a config option to control 
that.

What comes out of it is that the outside applications have no way to gather 
what the data is.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: versioned dependencies on breeze

[Martin Graesslin]

On Wednesday, July 13, 2016 11:53:22 PM CEST Antonio Rojas wrote:
> Martin Graesslin wrote:
> > Well if KWin depends on Breeze you cannot parallel build KWin and Breeze.
> > That should be obvious.
> 
> It could be theoretically possible to build Kwin and Breeze 5.7.1 in
> parallel against 5.7.0 packages if the dependencies were not versioned
> (actually parallel build was just an example - our main issue is that this
> makes it harder to build packages in a clean chroot)
> 
> > It does not make sense to have KWin depend on a Breeze of the previous
> > version. Neither plasma-integration. Thus I even think that from a
> > technical point of view that would be wrong.
> 
> Not sure if it makes sense or not, just pointing out that this makes things
> harder for packagers.
> 
> It just seems strange to me that the dependency on Breeze (which is used to
> set the default style and doesn't actually use any API) is versioned, while
> for instance the dependency on libKWorkspace in plasma-desktop or
> powerdevil, which should be much more sensitive to API changes, is not
> versioned.
> 
> Perhaps a compromise could be to depend on the latest major version of the
> modules (since it seems unlikely that a bug fix release would break things)

If you think it's important: patches welcome. I'm not going to spend time on 
it, sorry. The whole point of the change was to document the actual 
dependencies because that was feedback we got from distros. Now distros are 
again not happy. /me is not thrilled.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: versioned dependencies on breeze

[Martin Graesslin]

On Tuesday, July 12, 2016 6:39:25 PM CEST Antonio Rojas wrote:
> In Plasma 5.7 both kwin and plasma-integration added strict versioned
> dependencies on Breeze:
> 
> find_package(Breeze ${PROJECT_VERSION} CONFIG)
> 
> Can this please be changed to depend on the actual minimum version required?
> There is no other versioned dependency between Plasma modules and it is
> quite inconvenient for packaging (as eg. it prevents parallel building)

Well if KWin depends on Breeze you cannot parallel build KWin and Breeze. That 
should be obvious.

The reason for the added dependency is that distributions complained about 
Plasma not properly specifying the dependencies it has. Thus I introduced them 
in a way that it doesn't require manual effort to keep them up to date. If I 
have to switch to minimum version it's starting to get manual effort with the 
risk of weird errors we have not expected yet.

It does not make sense to have KWin depend on a Breeze of the previous 
version. Neither plasma-integration. Thus I even think that from a technical 
point of view that would be wrong.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

[Martin Graesslin]

On Monday, July 11, 2016 10:31:14 PM CEST Thomas Pfeiffer wrote:
> So this is the input I've taken from this thread so far:
> 
> File manager: Dolphin
> Music player: VLC (I've taken form the thread that people feel Cantata's
> benefits over VLC do not outweigh its downsides)

As a matter of fact I have been using Cantata instead of VLC since it was 
proposed here. I thought I need to give a better testing on it when saying 
it's not optimal.

I hereby withdraw my previous comments :-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Long term support release for Plasma?

[Martin Graesslin]

On Monday, July 11, 2016 9:55:20 PM CEST Nicolas Lécureuil wrote:
> This is really a good news.
> thank you.
> 
> Maybe a nonsense question, but is there a KF5 release planned as LTS to
> go with plasma 5.8 ?

not at all a nonsense question. It's something we have to discuss with the 
frameworks developers.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Martin Graesslin]

On Thursday, July 7, 2016 12:36:26 PM CEST Thomas Pfeiffer wrote:
> Hi everyone,
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
> 
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
> 
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one
> - The initial setup has huge usability problems, as it forces users to make
> a choice on a very advanced technical level (encryption methods, no less!),
> and the option it suggests (GPG) is a nightmare to set up for ordinary
> users - It does support unlocking via PAM, but does not tell users what
> they need to do to make that work, which results in most users having to
> enter the KWallet password at each system start, which many find very
> annoying (we get lots of negative feedback for that)
> - It works only with KDE Frameworks-based applications
> - One cannot easily write a QML GUI for it, making it unsuitable for mobile

Adding some more:
- kwallet dialog allows keyloggers on X11 (in defence of KWallet, I only know 
of pinentry which handles this properly at the cost of severely degraded user 
experience)
- kwallet does not protect against ptrace (I didn't add the protection, due to 
the keylogger rendering it point less)
- kwallet dialog windows sometimes are placed at the bottom of the stack due 
to focus stealing prevention (this happens for example with akonadi/other 
daemons)
- kwallet shows total giberish like "kded requested to open the wallet"
- if one doesn't unlock the wallet fast enough applications start asking for 
the password. So getting a coffee while desktop starts results in thousands of 
password windows.

> 
> Valentin has been working on KSecretService for quite a while, which is
> based on the freedesktop Secrets API [1] that is also supported in GNOME
> Keyring, and would solve many (and ideally all) of the above problems.
> However, Valentin told me he does not have the time to work on
> KSecretService any more.
> 
> This means we have to find a solution to these problems. The options I see
> currently are
> - Improve KWallet (unlikely to fix all the problems without massive changes
> in it, though)
> - Find someone to finish and maintain KSecretService

how much work is still needed?

> - Build a wrapper around one of the other existing keyring technologies
> - Each application (and each Plasma component that stores passwords)
> implements its own encrypted password storage
> - We make encrypted password storage optional and non-default (easiest
> solution, but not exactly in line with KDE's vision)

For Plasma I would like to see unlocking the wallet integrated into the 
desktop shell in some way. That would fix problems like the incorrect stacking 
order and we can easily protect against keyloggers, etc. Especially on Wayland 
I would like KWin having more control of entering passwords (KWin should know 
that a password is entered and make it impossible to steal focus then).

Cheers
Martin

Now going to use the secure pinentry, by clicking send

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Customizing KDE

[Martin Graesslin]

On Wednesday, June 29, 2016 3:19:40 PM CEST Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I'd like to setup some defaults for all users (at package level),
> including some customizations:
> 
> 1. Setup default theme
> 2. Setup default wallpaper
> 3. Set custom menu icon (application launcher?)
> 4. Set default menu style to "Application Menu"
> 5. Remove section "Places" from "Computer" tab, or even remove
> "Computer" tab completely in Application Launcher
> 6. Remove "New Session" feature (from all the places: menu, screen
> locker, etc)
> 7. Place some applications as "Favorites" by default
> 8. Remove "device notifier" and some other applets
> 
> 
> Any idea how to do (any of) that? Preferably without patching existing
> programs (but if no other option - this will also do).

I'm not an expert in that area, so I cannot really help. But as nobody else 
replied so far, I better answer with my half knowledge ;-)

Did you consider asking on the new distributions mailing list at https://
mail.kde.org/mailman/listinfo/distributions. If you are not yet subscribed you 
should ;-) It's also meant as a way to exchange knowledge and their are 
distributions doing that. Almost every distribution exchanges e.g. the 
wallpaper, so the knowledge is there.

Concerning points 3-5, 7: Eike, is that possible at all? If yes could you 
please tell Marek?

Concerning point 6: I suggest to use KIOSK for that. See https://
userbase.kde.org/KDE_System_Administration/Kiosk/Introduction

Point 8 might also be doable with KIOSK, but not 100 % sure. I assume your 
idea is not to hide the device notifier but make it impossible to mount devices 
as a user, right?

> 
> I've tried using scripts:
> https://userbase.kde.org/KDE_System_Administration/PlasmaTwoDesktopScripting
> but failed. For example I see no way to remove
> entries/applets/plasmoids. Also debugging is quite painful, because I
> have no idea where to looks for logs (like what entry was loaded, what
> was ignored at all etc), I can only guess looking at the result. And
> frequently wondering why my script wasn't launched at all...

Concerning testing of the script: did you try to run the snippets from the 
Plasma-Scripting console? That way you at least get instant feedback.

Cheers,
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

[Martin Graesslin]

On Tuesday, July 5, 2016 3:51:45 PM CEST R.Harish Navnit wrote:
> On Tue, Jul 5, 2016 at 11:36 AM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > On Monday, July 4, 2016 10:52:12 PM CEST Thomas Pfeiffer wrote:
> > > On 04.07.2016 18:37, Martin Gräßlin wrote:
> > > > Am 2016-07-04 14:43, schrieb Thomas Pfeiffer:
> > > >> Hi everyone,
> > > >> every now and then, distributions approach us asking which
> > > >> applications they should ship by default with Plasma, or they
> > > >> complain
> > > >> about us not providing such information.
> > > >> Although the Plasma team of course does not have to provide such
> > > >> information, it may still be helpful also for us because we can try
> > > >> to
> > > >> make sure that these applications work well in Plasma.
> > > >> Choosing such applications is not an easy task, but to get things
> > > >> started, a group of people who were stranded in Bielefeld waiting for
> > > >> their trains after a meeting sat together to come up with an initial
> > > >> suggestion. Here is the result:
> > > >> 
> > > >> File manager: Dolphin
> > > >> Music player: Cantata
> > > > 
> > > > I think Cantata is unsuited as it requires an mpd running. Given that
> > > > it's
> > > > out of scope for simple usage.
> > > 
> > > Have you set up Cantata lately? Yes, it requires mpd, but it sets one up
> > > all by itself if you don't have one.
> > > You tell it where your library is and it does the rest, not more
> > > complicated than any other music player.
> > > We would not have included it in this list if it required setting up mpd
> > > manually.
> > 
> > ok, but that's then something which needs to be pointed out to
> > distributions that they set up the packaging correctly.
> > 
> > > >> Document viewer: Okular
> > > > 
> > > > Here we need to be careful given that there is no release based on Qt
> > > > 5
> > > > (note that some distros ship with it but master has a terrible and
> > > > annoying warning in your face dialog about that) and Qt 4 is EOL.
> > > > Given
> > > > that viewing pdfs is something which has been exploited in the past
> > > > and
> > > > is network attackable in worst case, I think it's not a good choice.
> > > > As
> > > > long as there is no Qt5-maintained release I would say it needs to be
> > > > evince or none.
> > > 
> > > This is a difficult issue, then. Is there any way we can help Albert
> > > with
> > > finishing the Qt5 port? Not
> > > having a well-integrated PDF reader is not a good situation to be in. Of
> > > course the same is true
> > > for the other areas where we don't recommend anything, but it feels like
> > > Okular would be the
> > > easiest to get to a point where it could be recommended.
> > 
> > I don't know if there is a way to help with the port. After having seen
> > the
> > in-your-face warning I had a feeling that running the dev build is
> > discouraged by the Okular developers. That makes it difficult to help as
> > not even bug reports are wanted (given the in-your-face dialog). But we
> > two already discussed that in private.
> > 
> > > >> Software center: Discover
> > > >> Communication: Konversation, KDE Telepathy (cautiously, because while
> > > >> it works well at the moment, it is also looking for a maintainer)
> > > >> Password storage: KWalletmanager, kwallet-pam
> > > > 
> > > > While KWalletmanager gives a good integration in some KDE applications
> > > > it's
> > > > nothing I would recommend as a wallet manager. It is not well
> > > > integrated
> > > > into Plasma, it is not secure, it has a terrible first run experience
> > > > with recommending to use a GPG key and then telling you that you don't
> > > > have one and does not have any concept of synchronization. In the area
> > > > of
> > > > password storage there are way better solutions available in the FLOSS
> > > > world
> > > 
> > > I agree, KWalletmanager as it is now is _not_ a good password manager.
> > > The
> > > reason why we
> > > integrated it in that list is that things like Plasma-NM only work
> > > autom

Re: Live image for Plasma 5.7 release

[Martin Graesslin]

On Monday, June 27, 2016 2:12:32 PM CEST Martin Graesslin wrote:
> Hi distributions,
> 
> for the Plasma 5.7 release on July, 5th, I would like to have live images
> for the release announcement.
> 
> If your distribution is able to create a live image with the released tars
> before the release, we could include a link to it in the release
> announcement. This would allow our (and your) users to easily test the
> latest release. The image should show Plasma as we release it, so ideally
> with upstream branding.
> 
> If multiple distributions are able to provide such an image, we would of
> course include all.
> 
If you have the image ready please add a link to the Plasma 5.7 in 

https://community.kde.org/Plasma/Live_Images

My suggestion would be simple bullet point list ordered alphabetically.

Thanks a lot for your efforts!

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

[Martin Graesslin]

On Monday, July 4, 2016 10:52:12 PM CEST Thomas Pfeiffer wrote:
> On 04.07.2016 18:37, Martin Gräßlin wrote:
> > Am 2016-07-04 14:43, schrieb Thomas Pfeiffer:
> >> Hi everyone,
> >> every now and then, distributions approach us asking which
> >> applications they should ship by default with Plasma, or they complain
> >> about us not providing such information.
> >> Although the Plasma team of course does not have to provide such
> >> information, it may still be helpful also for us because we can try to
> >> make sure that these applications work well in Plasma.
> >> Choosing such applications is not an easy task, but to get things
> >> started, a group of people who were stranded in Bielefeld waiting for
> >> their trains after a meeting sat together to come up with an initial
> >> suggestion. Here is the result:
> >> 
> >> File manager: Dolphin
> >> Music player: Cantata
> > 
> > I think Cantata is unsuited as it requires an mpd running. Given that it's
> > out of scope for simple usage.
> 
> Have you set up Cantata lately? Yes, it requires mpd, but it sets one up all
> by itself if you don't have one.
> You tell it where your library is and it does the rest, not more complicated
> than any other music player.
> We would not have included it in this list if it required setting up mpd
> manually.

ok, but that's then something which needs to be pointed out to distributions 
that they set up the packaging correctly.

> >> Document viewer: Okular
> > 
> > Here we need to be careful given that there is no release based on Qt 5
> > (note that some distros ship with it but master has a terrible and
> > annoying warning in your face dialog about that) and Qt 4 is EOL. Given
> > that viewing pdfs is something which has been exploited in the past and
> > is network attackable in worst case, I think it's not a good choice. As
> > long as there is no Qt5-maintained release I would say it needs to be
> > evince or none.
> 
> This is a difficult issue, then. Is there any way we can help Albert with
> finishing the Qt5 port? Not
> having a well-integrated PDF reader is not a good situation to be in. Of
> course the same is true
> for the other areas where we don't recommend anything, but it feels like
> Okular would be the
> easiest to get to a point where it could be recommended.

I don't know if there is a way to help with the port. After having seen the 
in-your-face warning I had a feeling that running the dev build is discouraged 
by the Okular developers. That makes it difficult to help as not even bug 
reports are wanted (given the in-your-face dialog). But we two already 
discussed that in private.

> 
> >> Software center: Discover
> >> Communication: Konversation, KDE Telepathy (cautiously, because while
> >> it works well at the moment, it is also looking for a maintainer)
> >> Password storage: KWalletmanager, kwallet-pam
> > 
> > While KWalletmanager gives a good integration in some KDE applications
> > it's
> > nothing I would recommend as a wallet manager. It is not well integrated
> > into Plasma, it is not secure, it has a terrible first run experience
> > with recommending to use a GPG key and then telling you that you don't
> > have one and does not have any concept of synchronization. In the area of
> > password storage there are way better solutions available in the FLOSS
> > world
> 
> I agree, KWalletmanager as it is now is _not_ a good password manager. The
> reason why we
> integrated it in that list is that things like Plasma-NM only work
> automatically with KWallet, so
> there is not really a way around that, and KWalletManager is the only
> practical to see or remove
> passwords stored in KWallet.
> The situation with KWallet is a huge problem for Plasma, which has to be
> solved. KSecretService would have been the solution, but unfortunately
> Valentin has no more time to
> work on it.
> There are various solutions for this problem, but we have to take one, and
> we do need some
> form of keyring to store things like wifi keys in an encrypted store.
> 
> I will open a separate thread for this issue, as it's too big to be
> discussed within this thread.

sounds like a good idea to start a new thread about that.

> 
> >> Hardware support: Skanlite, Print manager
> >> Utilities/system tools: KCalc, KDE Connect, Konsole, KSysguard, Kate,
> >> Kamoso (if a distro wants to ship a webcam app at all)
> >> Office suite: We do not recommend one at the moment
> >> Pim suite: We do not recommend one at the moment.
> >> Browser: We do not recommend one at the moment
> > 
> > for browser I would turn the recommendation the other way: let's
> > explicitly
> > recommend to not use any of the Qt browsers.
> 
> I've heard people using e.g. QupZilla as their daily browser and not being
> unhappy with it. I don't think it's at a state where I'd explicitly
> recommend it, but it's not so bad that I'd recommend _against_ it.

And from a security perspective?

Cheers
Martin

signature.asc
Description: This is 

Re: Which applications does the Plasma team recommend to use with Plasma?

[Martin Graesslin]

On Monday, July 4, 2016 11:06:05 PM CEST Aleix Pol wrote:
> On Mon, Jul 4, 2016 at 6:37 PM, Martin Gräßlin  wrote:
> > Am 2016-07-04 14:43, schrieb Thomas Pfeiffer:
> >> Hi everyone,
> >> every now and then, distributions approach us asking which
> >> applications they should ship by default with Plasma, or they complain
> >> about us not providing such information.
> >> Although the Plasma team of course does not have to provide such
> >> information, it may still be helpful also for us because we can try to
> >> make sure that these applications work well in Plasma.
> >> Choosing such applications is not an easy task, but to get things
> >> started, a group of people who were stranded in Bielefeld waiting for
> >> their trains after a meeting sat together to come up with an initial
> >> suggestion. Here is the result:
> >> 
> >> File manager: Dolphin
> >> Music player: Cantata
> > 
> > I think Cantata is unsuited as it requires an mpd running. Given that it's
> > out of scope for simple usage.
> > 
> >> Video player: VLC
> >> Document viewer: Okular
> > 
> > Here we need to be careful given that there is no release based on Qt 5
> > (note that some distros ship with it but master has a terrible and
> > annoying
> > warning in your face dialog about that) and Qt 4 is EOL. Given that
> > viewing
> > pdfs is something which has been exploited in the past and is network
> > attackable in worst case, I think it's not a good choice. As long as there
> > is no Qt5-maintained release I would say it needs to be evince or none.
> 
> That's absurd, if anything we can say it's none and set it as a
> priority to have Okular ported.

Why is that absurd? Currently KDE does not have a pdf viewer which is 
suitable. There is a Qt 4 version - that's no-no, and there's a Qt 5 version 
with a big fat in your face warning - that's no-no-no-no.

evince does a good job and I'm using it regularly.

> 
> >> Software center: Discover
> >> Communication: Konversation, KDE Telepathy (cautiously, because while
> >> it works well at the moment, it is also looking for a maintainer)
> >> Password storage: KWalletmanager, kwallet-pam
> > 
> > While KWalletmanager gives a good integration in some KDE applications
> > it's
> > nothing I would recommend as a wallet manager. It is not well integrated
> > into Plasma, it is not secure, it has a terrible first run experience with
> > recommending to use a GPG key and then telling you that you don't have one
> > and does not have any concept of synchronization. In the area of password
> > storage there are way better solutions available in the FLOSS world
> > 
> >> Hardware support: Skanlite, Print manager
> >> Utilities/system tools: KCalc, KDE Connect, Konsole, KSysguard, Kate,
> >> Kamoso (if a distro wants to ship a webcam app at all)
> >> Office suite: We do not recommend one at the moment
> >> Pim suite: We do not recommend one at the moment.
> >> Browser: We do not recommend one at the moment
> > 
> > for browser I would turn the recommendation the other way: let's
> > explicitly
> > recommend to not use any of the Qt browsers.
> 
> That's just negative speech, not something we want to be responsible
> for. I'm sure KDE could have a good web browser.

KDE might be able to have a good web browser. Currently we don't. If we 
explicitly recommend software we need to be honest first of all with ourselves. 
Just because there is a tool which does job foo, doesn't mean it's a good 
tool. 

> 
> >> If an applicaiton does not show up in this list, this does of course
> >> not mean we don't like the application or the team behind it, it just
> >> means that we _currently_ don't feel confident to recommend it to
> >> users.
> >> 
> >> This is our initial proposal, now we'd like to get the input from the
> >> rest of the Plasma team!
> > 
> > Thanks for starting that thread, very important
> 
> Let's remember that communicating is important.
> Team building is important.
> Community building is important.

Being honest to ourselves is important. Yes I see that a "this software is not 
good enough" can be discouraging for the developers and work against community 
building. But having good recommendations which we can actually recommend to 
our users is more important. We shouldn't be afraid of saying that a software 
is not good enough for a recommendation. If we recommend bad software this 
also directly reflects on us and our community.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Long term support release for Plasma?

[Martin Graesslin]

On Wednesday, June 29, 2016 8:35:26 PM CEST Bernhard Rosenkraenzer wrote:
> On 2016-06-27 14:28, Martin Graesslin wrote:
> > Hi distributions,
> > 
> > in Plasma we are considering to add a long term support release. For
> > this idea
> > we want to get some feedback from your side to know how we should set
> > this up.
> 
>  From an OpenMandriva perspective:
> > We would like to know from you:
> > * is that something which is useful to you?
> 
> We're not too interested in another 5.7.x release when 5.8 is out,
> usually another .x doesn't break things too badly.
> 
> However:
> > * how often should we do an LTS release?
> 
> For us it would be useful to make an end-of-line release LTS. 5.(last
> before 6 is released), then 6.(last before 7) etc. being LTS would help
> us with people who are scared of more significant UI changes. We still
> have a few people who long for the "good old days" of KDE 3.x.
> We probably won't treat LTS releases that aren't end-of-line differently
> from "normal" releases.

That's something completely different to what we had in mind and I don't think 
that's possible. E.g. currently with 5.x we had 4.11 a long term support 
release for quite some time. But right now it's no longer supported and cannot 
be supported because Qt 4 is already EOL. Even if users want it, I think it's 
a disservice for all users to provide them unmaintained software. If Qt 
doesn't provide support any more, we cannot provide support for software 
depending on it either.

I don't expect that this will be different once Qt 6 comes out. So I don't 
expect it to be possible to provide support for Plasma 5 for the life time of 
Plasma 6.

Not to mention of all the problems which start to exist once you upgrade the 
system without touching everything. Recently I was contacted by an NVIDIA dev 
about a problem their latest beta driver exposes in KWin 4.11. A problem which 
would require a large restructuring of the source code which exists in the 5.x 
branch. It's something you don't want in a LTS release. But it shows the big 
problem: you cannot move the stack underneath without touching everything. 
Things like adjustments to newer systemd (hello things moving around from udev 
to somewhere else), adjustments to newer compilers (hello gcc6), adjustments 
for obscure things like XServer no longer running as root (caused problems in 
Qt 4). These are all examples for showing that you cannot just hibernate part 
of the stack.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: porting the QtCurve kwin theme

[Martin Graesslin]

On Saturday, July 2, 2016 9:14:34 PM CEST you wrote:
> On Saturday July 02 2016 20:13:49 René J.V. Bertin wrote:
> >That at least sounds like something I could start looking at.  I just hope
> >there isn't too much in the code that will make QtCurve hard if not
> >impossible to port without sacrificing its individuality.
> FWIW, the kwin4 plugin doesnt link to QtWidgets at all:

because there was no QtWidgets library back in the days. But it uses QWidget 
and is completely based on it, e.g. void setMainWidget(QWidget*);

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: porting the QtCurve kwin theme

[Martin Graesslin]

On Saturday, July 2, 2016 3:17:49 PM CEST René J. V. Bertin wrote:
> Hi,
> 
> Rather than example minimal from-scratch KDecoration2 examples, is/are there
> examples showing how to write a sort of minimal KDecoration2->legacy
> wrapper/proxy (and then work from there modernising the code)?

One cannot have a wrapper/proxy. KDecoration was modelled around QWidget with 
KCommonDecoration using QPushButtons for the buttons. KDecoration2 doesn't 
depend on QWidgets any more and all it has is a QPainter based API for 
rendering and QEvents for input interaction. Wrapping the old decoration is 
not possible due to the QWidget dependency, KWin would not be able to render 
it.

How to port the code really depends on how the legacy decoration plugin is 
based. A code base which heavily depends on QWidget is difficult to port. A 
code 
base which has the rendering abstracted and uses KCommonDecoration is easier 
to port.

> 
> I presume that's not unlike how Oxygen was adapted?

Oxygen was KCommonDecoration based and had the rendering quite well abstracted 
due to the fact that it's shared with the widget style.

My suggestion for a port is to separate the drawing logic to have it free from 
QWidgets and then integrate it into a KDecoration2 code base.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.7 video

[Martin Graesslin]

On Saturday, July 2, 2016 4:41:14 AM CEST Łukasz Sawicki wrote:
> Hi,
> 
> Here is a Plasma 5.7 video lets call it rc for now ;) Since we still
> have a couple of days to final release feel free to post your
> opinions, comments etc about it,  so I can still improve some things
> if there will be such a need.
> 
> https://youtu.be/i0TvgEjik00

Great video!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Long term support release for Plasma?

[Martin Graesslin]

Hi distributions,

in Plasma we are considering to add a long term support release. For this idea 
we want to get some feedback from your side to know how we should set this up.

Here is an example (I mean it!) for how this could look like:
* 5.8 first LTS release based on Qt 5.6 (which is also an LTS) for X11
* every fourth release will be another LTS release, so with the 3 month cycle 
there is one LTS per year - 5.8, 5.12, 5.16
* Support is for five release cycles, so with 5.13 the 5.8 LTS goes EOL, with 
5.17 the 5.12 release goes EOL
* bug fix release continue in the Fibonacci schedule till the EOL release

We would like to know from you:
* is that something which is useful to you?
* how often should we do an LTS release?
* how often should we do bug fix releases for an LTS?
* how long should a LTS be supported?

Related to that: 
* what to do with frameworks?
* Would you freeze the frameworks version or continue to backport newer 
framework versions to your distribution?
* Would you want an LTS branch for frameworks as well?
* What would you expect that to look like?

Looking forward to your input on this rather important topic.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Live image for Plasma 5.7 release

[Martin Graesslin]

Hi distributions,

for the Plasma 5.7 release on July, 5th, I would like to have live images for 
the release announcement.

If your distribution is able to create a live image with the released tars 
before the release, we could include a link to it in the release announcement. 
This would allow our (and your) users to easily test the latest release. The 
image should show Plasma as we release it, so ideally with upstream branding.

If multiple distributions are able to provide such an image, we would of 
course include all.

The tarballs will be created on June, 30th.

What do you think? Anybody interested?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KCM/colord-kde and it's KF5 release

[Martin Graesslin]

On Monday, June 20, 2016 9:13:28 PM CEST Alessandro Longo wrote:
> Hi, I hope this is the right ml to talk about KCMs.
> I tried to install latest stable release (0.3) of colord-kde[1] to
> manage icc color profiles, but the KCM isn't loaded in SystemSettings. I
> can launch it with `kcmshell4 kcm_colord` but not with `kcmshell5
> kcm_colord`. So I tried to compile it from git[1] and it works, it's
> shown in SystemSettings correctly.
> But since it has to be installed in offices, I'd prefer to use a package
> by the distro. Would it be possible to release maybe a 0.3.1 to support
> current SystemSettings and make distributions update their colord-kde
> package? I hope this is the right way to fix the issue.

The project is not part of Plasma and effectively dead. It hasn't been touched 
since more than a year, doesn't have CI setup, etc. etc.

Before it can be released again it needs to be brought back from the dead and 
made sure that it actually works.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: porting the QtCurve kwin theme

[Martin Graesslin]

On Thursday, June 16, 2016 11:15:22 PM CEST René J.V. Bertin wrote:
> Hi,
> 
> It was pointed out to me by an OpenSuse maintainer that the QtCurve Qt5
> implementation doesn't contain a (functional) window theme.
> 
> I'm not exactly the most likely candidate to address this as I don't
> currently have a system running a Plasma5 desktop, but I do now have KWin5
> installed in my parallel prefix, from where it can replace the system's
> KWin4 . How complicated is it to port a KDE4 kwin style/decoration to KF5,
> I presume that means using KDecoration2? Is there a guidebook somewhere
> online?

Yes, a port to KDecoration2 is required. No, there is no guidebook for that. 
The required effort is difficult to estimate as it depends on the actual 
implementation. Whether it uses KCommonDecoration or KDecoration.

Don't try to start the KWin 5 instance to test it, use kdecoration-viewer:

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

How are wallpaper configuration views loaded?

[Martin Graesslin]

Hi Plasma devs,

as you might have seen I'm working on integrating Plasma Wallpaper plugins int 
screenlocker.

I'm currently stuck on the configuration. I do not understand how the 
config.qml 
files in the packages are populated with the kcfg values. I see they have 
properties defined which match the keys from their config.xml file, but I'm 
missing where the "magic" happens.

Any pointers are appreciated :-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Translation of click events to touch events in kwin.

[Martin Graesslin]

On Wednesday, June 8, 2016 9:58:28 PM CEST Bhavisha Dhruve wrote:
> I now properly understood the actual idea, and how I will have to use
> FakeInput interface, to sum up there will be QtQuick component, which will
> be used by Plasma mobile emulator to embed KWin inside emulator window.

yep

> 
> > Option 1 might be easier right now as we already have everything for that
> > in
> > place.
> 
> I really have no idea on which of the two solution you proposed will be
> good choice, so can you please explain one which you think will be best in
> details?
> 
> > If the whole thing sounds somewhat sane to you I can explain in more
> > detail
> > how that could work.

Ok, I'm now trying to outline how such a QtQuick component needs to be 
implemented.

Basically the QQuickItem needs to create an anonymous Wayland server. The key 
for that is in the KWayland repository and there is already an example 
provided in src/tools/testserver

So the important things are:
* create a KWayland::Server::Display which is setup to use ConnectClientsOnly
* it uses createClient on an anonymous socketpair
* it needs to create at least the following interfaces:
 ** shm
 ** compositor
 ** seat (with at least touch)
 ** shell
 ** output which has a size mapped to the size of the QQuickItem
* it starts kwin_wayland with WAYLAND_SOCKET passed to the socket pair

I think that's already quite a list, so I stop here for the moment. This 
should be sufficient to get a nested kwin_wayland started. How to get it to 
render and how to get input in is then something we need to look into once we 
reached that stage (might also mean that I need to experiment a little bit 
with the code ;-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Translation of click events to touch events in kwin.

[Martin Graesslin]

On Wednesday, June 8, 2016 2:43:50 PM CEST Martin Graesslin wrote:
> On Wednesday, June 8, 2016 2:04:45 PM CEST Bhavisha Dhruve wrote:
> > Hello,
> > 
> > One part of my GSoC project (Plasma mobile emulator) is to translate click
> > events into touch events, for that I've already implemented touch event
> > support in FakeInput interface both kwayland and kwin side as stated in my
> > GSoC proposal.
> > 
> > However I am not getting part of how and where I can translate click
> > events
> > into touch events in KWin? Can someone help me on this?
> 
> As you have the fake input protocol, why would you need to translate the
> clicks at all in KWin. The translation should be done by whatever
> application uses the fake input protocol to inject touch events.

I just discussed a little bit with Bhushan about how the emulator should work. 
I think it doesn't make sense to have kwin_wayland as the "toplevel" window, 
we rather need to make KWin a child of the emulator window to have things like 
useful controls around the window. Think of e.g. the control in VirtualBox. 
That was kind of what I had in mind when I suggested to use the fake input 
protocol. The emulator window can listen for mouse events and then send them 
as touch events to the fake input protocol.

Now on how to embed KWin into another application. It's not as difficult as it 
sounds and I had a neat idea in my head for some time: a declarative plugin 
which would allow embedding KWin. This could then look something like:
KWin {
id: kwin
socketName: "kwin-emulator-wayland-0"
anchors.fill: parent
Component.onCompleted: kwin.start()
}

Technically the QtQuickItem needs to forward input events (which could just be 
done through fake input) and render what the nested KWin provides. I see two 
possible solutions for that:
1. another Wayland compositor
2. base it on https://phabricator.kde.org/D1231

Option 1 might be easier right now as we already have everything for that in 
place.

If the whole thing sounds somewhat sane to you I can explain in more detail 
how that could work.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Translation of click events to touch events in kwin.

[Martin Graesslin]

On Wednesday, June 8, 2016 2:04:45 PM CEST Bhavisha Dhruve wrote:
> Hello,
> 
> One part of my GSoC project (Plasma mobile emulator) is to translate click
> events into touch events, for that I've already implemented touch event
> support in FakeInput interface both kwayland and kwin side as stated in my
> GSoC proposal.
> 
> However I am not getting part of how and where I can translate click events
> into touch events in KWin? Can someone help me on this?

As you have the fake input protocol, why would you need to translate the 
clicks at all in KWin. The translation should be done by whatever application 
uses the fake input protocol to inject touch events.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

No team meeting today

[Martin Graesslin]

Hi all,

we decided to cancel this weeks Monday meeting as most are at a sprint or just 
don't have time today. Which would result in me being the only one with a 
webcam around which doesn't make sense for a video meeting.

See you at next weeks meeting

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: translation threshold for Plasma 5

[Martin Graesslin]

On Thursday, June 2, 2016 8:56:42 PM CEST Burkhard Lück wrote:
> Hi,
> 
> I am updating the translation-howto and want to add the info for a
> translation threshold for shipping with plasma 5.
> 
> I found some mails on kde-i18n-...@kde.org but no definite percentage.
> 
> Is there a translation threshold for Plasma 5?

It's something we never (at least I cannot remember) discussed. So I would say 
the same threshold as used to by for KDE SC.

Thanks for looking into this.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma depending on Qt 5.6.1 shortly

[Martin Graesslin]

On Monday, May 23, 2016 1:47:23 PM CEST Luca Beltrame wrote:
> In data lunedì 23 maggio 2016 13:40:34 CEST, Sebastian Kügler ha scritto:
> > Of course no guarantees.
> 
> Let me rephrase a bit as I guess it wasn't that clear in the beginning: did
> the Qt Project say anything about the 5.6.1 {expected, tentative} schedule?

The important list seems to be: https://bugreports.qt.io/browse/QTBUG-53563?
filter=17596

> 
> > I'd say the chance that 5.6.1 is not out by the time we release 5.7 is
> > pretty slim (their bug tracker seems to be pretty empty in terms of
> > showstoppers, and it was already planned for half-May).
> 
> I'm worried mainly due to the amount of patches (mainly from already-fixed
> issues in their Gerrit) distributions (I know about openSUSE's case, but I
> bet others may have similar issues, too) may have to carry to bring Qt 5.6
> in unless this release is out.

Fully understood, we are in the same boat. Maybe we need to create some 
pressure to get them release it, especially due to the 5.6.0 f***k up on their 
side. And I think you distros are in a better situation to complain than we 
are. You can easily explain the pain you have because of that major f***k up 
which is still not yet fixed in a stable release.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

On Monday, May 23, 2016 10:35:05 AM CEST René J.V. Bertin wrote:
> On Monday May 23 2016 07:59:14 Martin Graesslin wrote:
> >I'm against any patches to plasma-desktop to make it compile on other
> >platforms. There should not be any need to have anything from
> >plasma-desktop on non Plasma platforms. If there is indeed a KCM which
> >makes sense to have on other platforms then it was incorrectly positioned
> >and needs to be moved out
> I agree (but am not going to hold my breath). I actually think that even for
> Plasma desktops it would make sense to move the KCMs out of there, at least
> the ones that are not directly related to what makes the desktop or how it
> works.

So far we haven't seen any KCM which would not be desktop specific. The things 
you listed are workarounds for apparently issues with the OSX QPT plugin. 
Needs to be fixed there, not worked around.

> >work a valid use case. In my opinion KDE applications should follow the
> >native style on OSX.
> 
> I really cannot get my head around that kind of attitude from people working
> on a "Freedesktop" environment. Users of OS X (or MS Windows) are
> apparently not entitled to gaining a little more freedom where and when
> they can? That's really not what I'd expect from members of what's supposed
> to be a community, and doesn't at all motivate me to contribute more on
> other aspects.

I only expressed my opinion. Of course I'm not taking away any freedoms. Of 
course you can according to the license use our software on OSX. Whether we 
consider that as a good idea is from the freedom perspective irrelevant. So 
please don't say we restrict freedom - that's clearly not the case.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Problem running Plasma with Wayland in Arch Linux

[Martin Graesslin]

On Monday, May 16, 2016 6:09:40 AM CEST Alfonso Hernandez wrote:
> in the construction of Astian OS for desktop we have encountered an error
> executing the command startplasmacompositor send the screenshot.

you are trying to run startplasmacompositor from a nested session. This is not 
supported. Startplasmacompositor is for running a native session.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

On Saturday, May 21, 2016 8:18:15 PM CEST René J.V. Bertin wrote:
> Hi,
> 
> We've talked about doing something about the various components in
> plasma-desktop that would make sense outside of full-blown Plasma sessions.
> 
> I've been keeping that in mind, and the other day my Linux install (which I
> maintain in a parallel prefix using the same packaging scripts as I use on
> OS X) made me realise that plasma-desktop also provides components that
> would be useful for those providing KF5 as an optional "suite" for use with
> a completely different desktop environment that still runs under X11.
> 
> Either way, I've come up with a couple of patches (the
> patch-disable-unwanted* at
> https://github.com/RJVB/macstrop/tree/master/kf5/kf5-plasma-desktop/files)
> which represent an initial approach at evaluating what builds and what
> makes sense on a ~Plasma desktop, X11 or OS X (or MS Windows, presumably).

I'm against any patches to plasma-desktop to make it compile on other 
platforms. There should not be any need to have anything from plasma-desktop 
on non Plasma platforms. If there is indeed a KCM which makes sense to have on 
other platforms then it was incorrectly positioned and needs to be moved out 
of plasma-desktop. Applications should not depend on the desktop. If an 
application cannot be configured without a KCM provided by plasma-desktop than 
we have a clear bug and that needs fixing.

Please note that I don't consider shipping KCMs to make your own QPT plugin 
work a valid use case. In my opinion KDE applications should follow the native 
style on OSX. With that the need for KCMs from plasma-desktop should be non-
existent.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

On Saturday, May 21, 2016 10:03:21 PM CEST René J.  V. Bertin wrote:
> > The following are unneccessary because we don't provide/have to provide
> > that feature outside a full Plasma session: * Autostart
> > * Global shortcuts
> 
> Through kglobalacceld? That is part of a framework that's supposed to work
> on all major platforms, and as far as it has ever been functional there I
> don't see why it wouldn't be possible to configure it.

Speaking with KGlobalaccel maintainer hat: Applications are expected to 
provide a configuration interface to set the global shortcuts. This is provided 
by standard component through KShortcutsEditor in KXmlGui.

If an application sets a global shortcut without providing a way to configure 
it, this would clearly be an application bug. As the number of applications 
outside the desktop using KGlobalAccel can be counted on one hand (I'm aware 
of Yakuake and Amarok), we can manually check whether they do it.

The module in plasma-desktop is for those components which don't have a direct 
UI to configure: KWin, Plasma, KSMServer, the kded modules. All things from the 
platform specific desktop.

There is in my opinion no need to provide such a component on other platforms/
desktop. KGlobalAcceld should integrate with the native configuration tool on 
other platforms.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: status of kde/plasma kiosk framework in kf5

[Martin Graesslin]

On Wednesday, May 18, 2016 10:50:36 PM CEST Mag. Weissel Thomas wrote:
> first of all... thank you all so much for your engagement..  i can't say
> it in other words than.. you rock!

As a Plasma dev just following the work going in, I need to agree: they rock! 
I'm really impressed with which vigor our Plasma devs hunt down each and every 
of the usages of KAuthorized and fix the hell out of it. Good job!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: DWD HIG Draft

[Martin Graesslin]

On Wednesday, May 18, 2016 4:21:20 PM CEST Ken Vermette wrote:
> Update;
> 
> After feedback we made some moderately heavy changes to teh DWD
> requirements, namely removing/changing 'priority groups' in favour of
> 'layouts'.
> 
> Instead of the application firing off widgets with a "spray & pray" manner
> via priority groups, we're using layouts. With layouts the application sets
> a primary layout, and can switch to contextual layouts later. The primary
> layout has to be accepted as-is otherwise DWDs will be disabled for that
> window.
> 
> Layouts can specify the order and size policies of widgets, but only for
> the area inside the canvas - an application can't try to scramble
> user-defined buttons. Applications can swap layouts if there's a contextual
> need, but the DWD can reject them if there's an issue, telling the app to
> provide traditional controls.
> 
> We will specify how things should be laid out by applications in HIGs later
> (basically, it's what the required layout was before), but this will let
> applications use discretion if something would be awkward. More information
> on this can be found under 'Widget Placement" in the doc.
> 
> Document link:
> https://docs.google.com/document/d/1mYzHjcuDitWmk99syjC0xzQPPmyUrpL_29_s3-2Y
> l_g/edit?usp=sharing
> 
> This upcoming weekend is a long weekend here, so I'll have time to put this
> on the wiki and make a blog post. If anyone wants me to hold off for more
> feedback please let me know.

Maybe give sebas a chance to read over it. I try to remember to mention it in 
the meeting on Monday.

Cheers
Martin

> 
> Cheers;
>  - Ken
> 
> On Tue, May 17, 2016 at 10:49 AM, Ken Vermette  wrote:
> > Howdy!
> > 
> > We have our first serious formal proposal for the DWD HIGs and the
> > functionality we are looking for; here's a link to the publicly editable
> > Google doc:
> > 
> > 
> > https://docs.google.com/document/d/1mYzHjcuDitWmk99syjC0xzQPPmyUrpL_29_s3-> 
> > > 2Yl_g/edit?usp=sharing
> > 
> > I'd like to invite anyone with a stake in this to make edits/suggestions.
> > Once we have any rapid-fire editing done I'll pretty it up and put it on
> > the wiki; if editing wrecks the formatting in the doc that's fine. It
> > contains a general overview of functionality, the first four widgets we're
> > looking to implement, and a list of widgets which I'll be writing out once
> > we're satisfied with the current documentation and direction.
> > 
> > It may also be good to fill in technical or implementation details in the
> > doc so anyone reading the wiki can be on the same page. If anyone has any
> > concerns about anything please bring them up so we can hammer it out.
> > 
> >  - Ken



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.6.4

[Martin Graesslin]

On Sunday, May 15, 2016 11:14:42 AM CEST Nicolas Lécureuil wrote:
> Le 2016-05-10 21:06, Jonathan Riddell a écrit :
> > Plasma 5.6.4 is now released
> > https://www.kde.org/announcements/plasma-5.6.4.php
> > 
> > More translations and useful bug fixes, highlights:
> > 
> > Make sure kcrash is initialized for discover.
> > Build Breeze Plymouth and Breeze Grub tars from correct branch
> > [digital-clock] Fix display of seconds with certain locales.
> 
> Hi,
> 
> 
> But Kwayland is a plasma or a framework ? because we have it at the 2
> places now but seems that since KF 5.22.0 it is a framework.

KWayland moved from Plasma to frameworks with KF 5.22. You can just replace 
the Plasma one with the one from frameworks. They are fully ABI compatible, 
only the version number changed.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KWin in docker container for Plasma Mobile Emulator

[Martin Graesslin]

On Wednesday, May 11, 2016 9:27:58 PM CEST Bhavisha Dhruve wrote:
> On Wed, May 11, 2016 at 6:00 PM, Martin Graesslin <mgraess...@kde.org>
> 
> wrote:
> > Please enable all debug output for all kwin categories and used libraries
> > (e.g. kwayland, kwindowsystem, etc.) and run kwin again. Then please
> > provide
> > the debug output to us. That should tell us more.
> 
> Here is the output:
> 
> No backend specified through command line argument, trying auto resolution
> error: XDG_RUNTIME_DIR not set in the environment

That's your error: XDG_RUNTIME_DIR is not set. Without that specified the 
Wayland socket cannot be created and cannot be found by clients.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request for KWayland for inclusion in frameworks

[Martin Graesslin]

Hi David,

did you forget to update the version number of KWayland to 5.22 or is 
something still missing in KWayland?

Cheers
Martin

On Sunday, April 17, 2016 10:42:08 AM CEST David Faure wrote:
> Hi Martin,
> 
> Very nice run down of the check list!
> 
> I approve the move of kwayland to frameworks, please proceed
> (preferrably earlier than in two weeks, since that would be close to release
> date).
> 
> Cheers,
> David.
> 
> On Friday 15 April 2016 10:08:57 Martin Graesslin wrote:
> > Hi frameworks-developers,
> > 
> > based on the thread "KWayland as framework" [1] I want to start the review
> > process for including KWayland into frameworks.
> > 
> > To make it easier I'm giving an overview:
> > Policies [2]:
> > * Tier 1/integration - dependencies on Qt::Gui (5.4) and Wayland (1.7)
> > * directory structure
> > 
> >  ** name of toplevel directory: kwayland
> >  ** README.md: check
> >  ** COPYING.LIB: check
> >  ** metadata.yaml: check
> >  ** docs subdirectory: no additional documentation
> >  ** src with dedicated subdirectories: check, there is src/client and src/
> > 
> > server
> > 
> >  ** examples subdirectory: no dedicated examples
> >  ** autotests subdirectory: check
> >  ** tests subdirectory: check
> >  ** cmake subdirectory: not needed
> > 
> > * automatic unit test: the current line coverage for client library is 86
> > %, the line coverage for server library is 80 %
> > * binary compatibility: KWayland has been ABI stable since it got added to
> > Plasma
> > * documentation: yes, the API is documented
> > * localization: not needed, no user visible strings
> > 
> > * buildsystem:
> >   ** KF5WaylandConfig.cmake is generated
> >   ** KF5WaylandConfigVersion.cmake is generated
> >   ** no other cmake files are installed
> >   ** library names are camel case: KF5WaylandServer and KF5WaylandClient
> >   ** dependencies to other frameworks: it's tier 1, doesn't apply
> > 
> > * commits are reviewed: yes, but KWayland is already using phabricator
> > * CI failures are treated as stop the line events: I like my view green
> > ;-)
> > 
> > * compiler requirements:
> >   ** gcc 4.5: I don't know, the minimum gcc version my distribution offers
> >   is
> > 
> > 4.7
> > 
> >   ** clang 3.1: I don't know, the minimum clang version my distribution
> >   offers> 
> > is 3.5
> > 
> >  **  VS2012: doesn't apply, it's Linux only [5]
> >  ** constraints for other C++11 features: it compiles on build.kde.org, so
> > 
> > should be fine
> > 
> > Guidelines [3]:
> > * Policies: see above
> > * translations: doesn't apply
> > * split repository: yes, all commits were extracted when creating the
> > project * astyle: the code follows the kdelibs coding style from the
> > start, didn't run astyle again
> > * Dependencies on deprecated API: none
> > * module in frameworks: not yet, currently still in Plasma [4]
> > * kde-build-metadata: not yet, currently still in Plasma [4]
> > * CI Jobs: currently still for Plasma [4]:
> > https://build.kde.org/job/kwayland %20master%20kf5-qt5/
> > * bugs.kde.org project: currently still in Plasma [4]
> > * reviewboard: yes
> > * README.md: yes
> > 
> > If you have any further questions regarding the move, please ask. If I
> > don't get any blocking feedback in the next two weeks, I'm going to
> > request the move and hope to get it into next frameworks release if that
> > works with David ;-)
> > 
> > Thanks,
> > Martin
> > 
> > [1]
> > https://mail.kde.org/pipermail/kde-frameworks-devel/2016-March/032116.htm
> > l [2] https://community.kde.org/Frameworks/Policies
> > [3] https://community.kde.org/Frameworks/CreationGuidelines
> > [4] I'll do those tasks if we get the green light for move to frameworks,
> > otherwise it'll stay in Plasma
> > [5] some code uses linux includes, to support other Unix-systems porting
> > is
> > needed



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Feedback on xdg-shell v5

[Martin Graesslin]

On Thursday, April 28, 2016 2:08:07 PM CEST Pekka Paalanen wrote:
> > > The biggest problem for me is the request set_window_geometry. I think I
> > > mentioned it already before on the wayland list. Basically I have no
> > > idea how to implement that in KWin. We have only one geometry for a
> > > window and that's mapped to the size of the surface/x11 pixmap. This
> > > geometry is used all over the place, for positioning, for resizing and
> > > for rendering. I cannot add support for this without either breaking
> > > code or having to introduce a new internal API. That's lots of work
> > > with high potential for breakage :-(
> Have you looked at what you need to do to support windows that are
> built from non-overlapping sub-surfaces, like what Jonas describes below?
> 
> I suspect you might end up having to do that major internal API work
> anyway by the sounds of it. A window may be a collection of surfaces,
> not just one.

Yes that's clearly a problem. I'm not happy with sub-surfaces allowing to 
overlap the parent. It's one of the many things where I think that sub-surface 
protocol is overdone and too complex.

So when implementing sub-surfaces in KWin I ignored this aspect. And will look 
into it when I first see a client doing that (pragmatic approach: don't 
implement something for a theoretical aspect)

> 
> How do you do the window geometry with server-side decorations? Why is
> using only a part of client surface so different from using a
> combination of client and server-only surfaces?

yes it sounds similar on first look and yes for server-side decorations we have 
such an architecture in place. We know the position where the actual window 
content starts and it's size. The geometry is in that case the combination of 
content and decoration. But this case is rather the opposite around. We don't 
add to the content size, we reduce. Also it doesn't help much even if it were 
similar. All the checks if (isDecorated) just won't hit for it.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Feedback on xdg-shell v5

[Martin Graesslin]

On Thursday, April 28, 2016 5:36:58 PM CEST Jonas Ådahl wrote:
> On Thu, Apr 28, 2016 at 10:36:14AM +0200, Martin Graesslin wrote:
> > Hi Wayland and Plasma,
> > 
> > I finished the implementation of xdg-shell in KWayland [1] and KWin [2].
> > Overall it was more straight forward than I would have expected.
> > Especially
> > the changes to KWin were surprisingly minor (with one huge exception).
> > 
> > Now some questions/remarks:
> > * What's a server supposed to do in use_unstable_version?
> 
> If a client requests the wrong version, the compositor should send an
> error, effectively disconnecting the client.
> 
> Note that this request is gone in v6 and is replaced by the same
> unstable-protocol-version semantics used in wayland-protocols.

Ok, that's what I though it is. I was just very unsure as killing the client 
is nothing I would consider "negotiate version" :-P

> 
> > * Why is the ping on the shell and not on the surface? I would have
> > expected to ping the surface. At least that's how I would want to do it
> > from KWin.
> Because you don't ping a surface, you ping the client. It's the client
> that may be inresponsive, and if the client is in responsive, it's safe
> to assume all its surfaces are as well.

Sorry, but I doubt this will work in practice. I have experienced many freezes 
with QtWayland applications and in all cases it would respond to the ping. 
Consider:
* Thread 1: dead-locked waiting for a frame callback
* Thread 2: Wayland connection getting ping, thread alive, will send pong

I fear that the concept of pinging clients doesn't work in a world where 
connections are in a thread.

Anyway if it's about whether the client is responsive, I suggest to make it a 
dedicated protocol. It's not really something which belongs to xdg-shell, it's 
a more general concept.

> 
> > * Would it be possible to split the states and geometry? I find it weird
> > that I have to send a configure request with a size of 0/0 when informing
> > a surface that it's active.
> 
> Possible - yes, worth it? I don't know. It's clearly specified that
> 0 means "let the client come up with it". If you think there is a clear
> benefit, you're welcome to send a patch targeting v6.

Yes, I think it might be worth it. I don't want that the client starts to 
think it can pick a different size when it becomes active.

> 
> > The biggest problem for me is the request set_window_geometry. I think I
> > mentioned it already before on the wayland list. Basically I have no idea
> > how to implement that in KWin. We have only one geometry for a window and
> > that's mapped to the size of the surface/x11 pixmap. This geometry is
> > used all over the place, for positioning, for resizing and for rendering.
> > I cannot add support for this without either breaking code or having to
> > introduce a new internal API. That's lots of work with high potential for
> > breakage :-(
> > 
> > From the description it seems to be only relevant for shadows. Could we
> > make shadows an optional part in xdg-shell? That the server can announce
> > that it supports shadows in the surface?
> 
> It's not only about shadow. Let me explain a scenario where a window
> geometry is needed, even when there is a mode where no shadow is drawn
> by the client.
> 
> Consider we have the following window:
> 
> 
> +---+
> 
> |   A window  X |
> 
> +---+
> 
> | /\|
> |
> |/  \   |
> |   
> |   /\  |
> |  
> |  /  \ |
> | 
> | /\|
> 
> +---+
> 
> It can be split into two logical rectangles/areas: the window title, and
> the main content. This window may be consisting of two separate
> non-overlapping surfaces, for example one GLES surface, and one SHM
> surface. Only one of these surfaces will be the "window", while the
> other will be a subsurface.
> 
> xdg_surface.set_window_geometry would here be used to describe, in
> relation to whatever surface was gets to act as "window", what the
> window geometry would be.

sorry, I didn't get the example at all.
> 
> > Also I'm not quite sure about that, but it looks to me like QtWayland
> > thinks that the set_window_geometry is the geometry of the
> > client-side-decoration, while on 

Feedback on xdg-shell v5

[Martin Graesslin]

Hi Wayland and Plasma,

I finished the implementation of xdg-shell in KWayland [1] and KWin [2]. 
Overall it was more straight forward than I would have expected. Especially 
the changes to KWin were surprisingly minor (with one huge exception).

Now some questions/remarks:
* What's a server supposed to do in use_unstable_version?
* Why is the ping on the shell and not on the surface? I would have expected 
to ping the surface. At least that's how I would want to do it from KWin.
* Would it be possible to split the states and geometry? I find it weird that I 
have to send a configure request with a size of 0/0 when informing a surface 
that it's active.

The biggest problem for me is the request set_window_geometry. I think I 
mentioned it already before on the wayland list. Basically I have no idea how 
to implement that in KWin. We have only one geometry for a window and that's 
mapped to the size of the surface/x11 pixmap. This geometry is used all over 
the place, for positioning, for resizing and for rendering. I cannot add 
support for this without either breaking code or having to introduce a new 
internal API. That's lots of work with high potential for breakage :-(

From the description it seems to be only relevant for shadows. Could we make 
shadows an optional part in xdg-shell? That the server can announce that it 
supports shadows in the surface?

Also I'm not quite sure about that, but it looks to me like QtWayland thinks 
that the set_window_geometry is the geometry of the client-side-decoration, 
while on GTK it looked to me like being the size of the shadow. Either I did 
not understand that correctly, or our toolkits are not compatible.

At the moment I haven't implemented this request yet in KWayland as I would 
not be able to use it in KWin anyway.

As a note: if it's just about shadow for us in Plasma that's a rather useless 
request. We already have a Wayland shadow implementation which allows us to 
have the shadow outside the surface.

Cheers
Martin

[1] https://phabricator.kde.org/D1506
[2] https://phabricator.kde.org/D1507

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request for KWayland for inclusion in frameworks

[Martin Graesslin]

Hi frameworks-developers,

based on the thread "KWayland as framework" [1] I want to start the review 
process for including KWayland into frameworks.

To make it easier I'm giving an overview:
Policies [2]:
* Tier 1/integration - dependencies on Qt::Gui (5.4) and Wayland (1.7)
* directory structure
 ** name of toplevel directory: kwayland
 ** README.md: check
 ** COPYING.LIB: check
 ** metadata.yaml: check
 ** docs subdirectory: no additional documentation
 ** src with dedicated subdirectories: check, there is src/client and src/
server
 ** examples subdirectory: no dedicated examples
 ** autotests subdirectory: check
 ** tests subdirectory: check
 ** cmake subdirectory: not needed
* automatic unit test: the current line coverage for client library is 86 %, 
the line coverage for server library is 80 %
* binary compatibility: KWayland has been ABI stable since it got added to 
Plasma
* documentation: yes, the API is documented
* localization: not needed, no user visible strings
* buildsystem:
  ** KF5WaylandConfig.cmake is generated
  ** KF5WaylandConfigVersion.cmake is generated
  ** no other cmake files are installed
  ** library names are camel case: KF5WaylandServer and KF5WaylandClient
  ** dependencies to other frameworks: it's tier 1, doesn't apply
* commits are reviewed: yes, but KWayland is already using phabricator
* CI failures are treated as stop the line events: I like my view green ;-)
* compiler requirements:
  ** gcc 4.5: I don't know, the minimum gcc version my distribution offers is 
4.7
  ** clang 3.1: I don't know, the minimum clang version my distribution offers 
is 3.5
 **  VS2012: doesn't apply, it's Linux only [5]
 ** constraints for other C++11 features: it compiles on build.kde.org, so 
should be fine

Guidelines [3]:
* Policies: see above
* translations: doesn't apply
* split repository: yes, all commits were extracted when creating the project
* astyle: the code follows the kdelibs coding style from the start, didn't run 
astyle again
* Dependencies on deprecated API: none
* module in frameworks: not yet, currently still in Plasma [4]
* kde-build-metadata: not yet, currently still in Plasma [4]
* CI Jobs: currently still for Plasma [4]: https://build.kde.org/job/kwayland
%20master%20kf5-qt5/
* bugs.kde.org project: currently still in Plasma [4]
* reviewboard: yes
* README.md: yes

If you have any further questions regarding the move, please ask. If I don't 
get any blocking feedback in the next two weeks, I'm going to request the move 
and hope to get it into next frameworks release if that works with David ;-)

Thanks,
Martin

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2016-March/032116.html
[2] https://community.kde.org/Frameworks/Policies
[3] https://community.kde.org/Frameworks/CreationGuidelines
[4] I'll do those tasks if we get the green light for move to frameworks, 
otherwise it'll stay in Plasma
[5] some code uses linux includes, to support other Unix-systems porting is 
needed

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

RFC: A Wayland virtual framebuffer server for our tests

[Martin Graesslin]

Hi Plasmates,

this week I spent some thoughts on how we can do something like Xvfb with 
Wayland. The reasoning is simple: we need to run our test cases also on 
Wayland and not just on X11. Currently something like this doesn't really 
exist so we might need to write it. I have a few ideas how it could be done 
and want to get a discussion started on that.

== Option 1: "Kvfb" based on KWayland ==

A very minimalistic wayland compositor gets written with KWayland which 
"renders". The server would be comparable minimal to Xvfb, that is it doesn't 
have a window manager, it could only map surfaces, there is no policy how to 
pass input events, etc.

Pro: once KWayland is in frameworks we can use that easily in all frameworks 
and applications.

Con: without the policies of a window manager also pretty useless for anything 
more complex than showing a window. Xvfb without a window manager is also 
useless.

== Option 2: Make KWin's test framework available as a library ==

KWin's internal test framework is pretty neat. It starts a new KWin instance 
in each run, can create Wayland and X11 windows. Has full introspection on 
those windows, can fake input events, etc. etc.

This would need to be wrapped in a nice library so that it doesn't expose the 
changing KWin internals. It could allow to e.g. verify in plasmashell that a 
Panel is created on the compositor with the window type Panel, that the struts 
are set properly. It could be used to verify the actual positions of the 
opened windows when clicking panels. And in addition one could do reference 
screenshots.

As a nice side effect it would not only test the tested code, but also KWin.

Pro: very powerful

Con: in process and requires KWin's QPA plugin. No chance to run the tests on 
X11, we are not able to catch problems in Qt's xcb and wayland plugins. Cannot 
be used in Frameworks/Applications.

== Option 3: A virtual framebuffer server based on KWin ==

This is a combination of Option 1 and Option 2: we build a dedicated test 
server on top of KWin's test framework and provide a library to interact with 
it. The test server is a dedicated process, such we don't have the in-process 
problem of Option 2. The tests could use the normal QPA plugin - in fact could 
even be run twice: once on Wayland and once on X11.

To make use of the full power of KWin we would need a library to interact with 
the test server. E.g. we need to be able to fake input events, we need to be 
able to fake screen changes and we want the introspection on the created 
windows. The library part and the test server could communicate through DBus. 
Thus we would have a kind of debug dbus interface in the server exposing all 
the windows with all their properties. On the server side that's not really a 
complex task as we have most things anyway exposed as properties.

Pros: very powerful, allows both X11 and Wayland for testing

Con: most complex architecture to implement. Cannot be used in Frameworks/
Applications.

---

So what do you think? What do you need for testing from the test windowing 
system? Which option should we go for?

I'm not telling you my personal opinion on what's best, don't want to influence 
you.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Martin Graesslin]

On Saturday, April 9, 2016 3:48:33 PM CEST Alexander Potashev wrote:
> Martin,
> 
> Please find my comments below.
> 
> 2016-04-08 8:55 GMT+03:00 Martin Graesslin <mgraess...@kde.org>:
> > On Thursday, April 7, 2016 11:28:17 PM CEST Alexander Potashev wrote:
> >> What if
> >> 
> >>  1. I don't use a desktop environment, but I need a way to setup
> >> 
> >> localization for KDE applications?
> > 
> > Ever heard of setting the LC_LANG env variables? Yes, nowadays KDE
> > applications use the standard Linux way for localization and not a custom
> > thing where one needs a special configuration module.
> 
> Localization section in System Settings also includes spellchecker KCM
> that writes to ~/.config/KDE/Sonnet.conf. There is no other place to
> configure spellchecker for KF5-based applications.

ah well, then just like in the Baloo/Dolphin case the applications using 
Sonnet need to include the KCM in their configuration.

If using a framework requires a workspace component being installed, something 
is seriously broken in our workflows. We have worked a lot on making our apps 
not depend on Plasma, let's not accept a status where that doesn't work.

> 
> >>  2. I have GNOME installed, but can't figure out how to use its tools?
> >> 
> >> The way out from this situation is that I install systemsettings5 and
> >> use it to configure localization while in a GNOME shell session.
> > 
> > Report a bug against GNOME then, if their software is unusable.
> 
> GNOME software might be OK, but I don't want to spend time on learning it.
> 
> Everyone should be free to use systemsettings5. What you suggest is
> not freedom [1].

You have all the rights to use systemsettings in GNOME. I don't care, nobody 
cares. But that doesn't mean that we have to provide appdata to make it 
installable in GNOME Software (apt install systemsettings still works after 
all). There's nothing in the GPL saying so. Sorry, but we are not here to 
serve everybodys "right of choice". We are not restricting anybodys freedom 
here, not violating the GPL or working against our vision. A good read in that 
regard is this weeks blog post about the right of choice in libinput: http://
who-t.blogspot.de/2016/04/why-libinput-doesnt-have-lot-of-config.html

It's a good read on why one shouldn't make everything in the world 
configurable. Adding appdata for something that shouldn't have it, is in the 
same category: it means we need to maintain it. That's a burden on our 
shoulders.

> 
> >> > Erm no. I just did a search for Akonadi in systemsettings and it
> >> > returns
> >> > nothing. Even if it were in systemsettings it would be wrong. That
> >> > needs
> >> > to be offered from the applications.
> >> 
> >> Please search for "PIM Accounts and Resources" in systemsettings.
> > 
> > doesn't exist on my system.
> 
> OK, I might have an old version of KDE PIM.
> 
> >> >>  - Baloo,
> >> > 
> >> > Use the DEs search tool
> >> 
> >> What if I want to use Dolphin? It only integrates with Baloo, thus I'm
> >> forced to use it. Editing baloorc is not very user-friendly.
> > 
> > Then dolphin needs to make the baloo configuration accessible. Expecting
> > users to know that they need to install systemsettings is no solution.
> 
> Reported against Dolphin: https://bugs.kde.org/show_bug.cgi?id=361557
> 
> >> >>  - systemd
> >> > 
> >> > There is no such thing as a systemd kcm in systemsettings
> >> 
> >> Please see https://quickgit.kde.org/?p=systemd-kcm.git
> >> You can install it and find it in systemsettings root menu.
> > 
> > 3rd party modules are not a reason for us to do things.
> 
> OK, then it's a problem in Systemd KCM.
> Reported: https://bugs.kde.org/show_bug.cgi?id=361558
> 
> >> Is your vision that writing third-party KCMs should be forbidden? (By
> >> "third-party" I mean those that are not released as part of Plasma.)
> > 
> > Everybody is free to write 3rd party KCMs to integrate with Plasma. But
> > it's no reason to make Plasma applications available to non-Plasma users.
> > 
> > To make it clear: we care here about the Plasma workflows and a good
> > integration of Plasma inside Plasma. You are free to use Plasma tools
> > outside Plasma, but that is not what we aim for. If you want to use
> > systemsettings outside of Plasma: do so! But that doesn't mean that we
> > want to expose systemsettings to non-Plasma users. Just like we don't
> > want GNOME's settings tool exposed to Pl

Re: Questions on Plasma i18n strings, offset=39

[Martin Graesslin]

On Friday, April 8, 2016 11:37:27 AM CEST Sebastian Kügler wrote:
> On Friday, April 08, 2016 02:06:07 AM David Edmundson wrote:
> > ​I'm taking tasks 50-59.
> > 
> > if a few people grab another block of 10, we'll be done in no time.
> 
> I'm on 60-69.
> 
> Should these fixes go into the stable branch or just master?

depends, if it introduces new translations it should be master only

Cheers
Martin



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: metadata.yaml for Plasma projects?

[Martin Graesslin]

On Friday, April 8, 2016 3:09:13 AM CEST Matthias Klumpp wrote:
> 2016-04-07 13:55 GMT+02:00 Martin Graesslin <mgraess...@kde.org>:
> > On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote:
> >> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin <mgraess...@kde.org>
> > 
> > wrote:
> >> > Hi Plasmates,
> >> > 
> >> > an idea for better documentation is to introduce some metadata similar
> >> > like
> >> > what frameworks have. This could be useful for potential devs who want
> >> > to
> >> > contribute, but also for distributions as in that way:
> >> > * we can specify whether it's experimental, released, obsoleted, etc.
> >> > * what other Plasma projects it depends on
> >> > * who is maintaining it and where to reach us
> >> > 
> >> > Below I have an example how this could look like (in the case of KWin).
> >> > 
> >> > What do you think?
> >> > 
> >> > Cheers
> >> > Martin
> >> > 
> >> > # The maintainer of the project
> >> > maintainer: graesslin
> >> 
> >> I'd suggest offering an appstream appdata file instead of this.
> > 
> > We have projects for which appstream doesn't make sense. Example is KWin,
> > kdecoration, kscreenlocker, kwayland, etc. etc. In fact I think we have
> > more projects in Plasma which do not need an appdata file than projects
> > which actually benefit from it.
> 
> That's actually not true - AppStream is a generic metadata format, and
> instead of writing an appdata file, you can just as well write a
> generic metainfo file to add metadata (and a unique ID!) to any
> software component.
> Just omit the type= attribute in the  root tag, or set it
> to "generic". Those components won't show up in software centers, but
> the metadata will still be available in distributions via more
> advanced tools.
> 
> So, your metadata file ideally only contains stuff that isn't in the
> metainfo XML already - or you add your own, non-standard tag to the
> metainfo file.

is there a high level visual editor for such appstream metadata? I'm not going 
to write XML and don't want to get my fellow developers to have to write xml. 
It's the path to outdated metadata if we need to write xml.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Martin Graesslin]

On Thursday, April 7, 2016 11:28:17 PM CEST Alexander Potashev wrote:
> Martin,
> 
> Thanks for your reply. Please see my comments below.
> 
> 2016-04-07 17:24 GMT+03:00 Martin Graesslin <mgraess...@kde.org>:
> > On Thursday, April 7, 2016 4:37:14 PM CEST Alexander Potashev wrote:
> >> 2016-04-07 16:14 GMT+03:00 Martin Graesslin <mgraess...@kde.org>:
> >> > system settings is a workspace configuration tool. I don't see how that
> >> > is
> >> > useful to anyone not using Plasma
> >> 
> >> Martin,
> >> 
> >> One can use System Settings to start KCMs that are not related to Plasma:
> >>  - Localization,
> > 
> > you should use your desktops configuration tool instead. No need to use a
> > Plasma one.
> 
> What if
>  1. I don't use a desktop environment, but I need a way to setup
> localization for KDE applications?

Ever heard of setting the LC_LANG env variables? Yes, nowadays KDE 
applications use the standard Linux way for localization and not a custom 
thing where one needs a special configuration module.

>  2. I have GNOME installed, but can't figure out how to use its tools?
> The way out from this situation is that I install systemsettings5 and
> use it to configure localization while in a GNOME shell session.

Report a bug against GNOME then, if their software is unusable.

> 
> >>  - Akonadi,
> > 
> > Erm no. I just did a search for Akonadi in systemsettings and it returns
> > nothing. Even if it were in systemsettings it would be wrong. That needs
> > to be offered from the applications.
> 
> Please search for "PIM Accounts and Resources" in systemsettings.

doesn't exist on my system.

> 
> >>  - Baloo,
> > 
> > Use the DEs search tool
> 
> What if I want to use Dolphin? It only integrates with Baloo, thus I'm
> forced to use it. Editing baloorc is not very user-friendly.

Then dolphin needs to make the baloo configuration accessible. Expecting users 
to know that they need to install systemsettings is no solution.

> 
> >>  - systemd
> > 
> > There is no such thing as a systemd kcm in systemsettings
> 
> Please see https://quickgit.kde.org/?p=systemd-kcm.git
> You can install it and find it in systemsettings root menu.

3rd party modules are not a reason for us to do things.

> 
> >> and many more.
> > 
> > and for them there is kcmshell5.
> > 
> > If there is anything in systemsettings which makes sense outside of
> > Plasma, it means it's wrong in systemsettings or lacking a proper way to
> > configure from the application.
> 
> So the workflow in this case would be to
>  1. Run "kcmshell5 --list" to see the list of available KCM,
>  2. Run e.g. "kcmshell5 kcm_baloofile".
> Did I get you right?

If that's something which is useful for Dolphin and needed from Dolphin, 
Dolphin should have a configure desktop search which does that.

> 
> Then how do I search KCMs by keywords? kcmshell5 does not seem to
> provide this functionality. Am I supposed to run "grep PIM
> /usr/share/kservices5/kcm*.desktop" to perform such a search?

Use the launcher of your DE to run them? What do I care. Exposing 
systemsettings is not the solution to that problem.

> 
> 
> Is your vision that writing third-party KCMs should be forbidden? (By
> "third-party" I mean those that are not released as part of Plasma.)

Everybody is free to write 3rd party KCMs to integrate with Plasma. But it's 
no reason to make Plasma applications available to non-Plasma users.

To make it clear: we care here about the Plasma workflows and a good 
integration of Plasma inside Plasma. You are free to use Plasma tools outside 
Plasma, but that is not what we aim for. If you want to use systemsettings 
outside of Plasma: do so! But that doesn't mean that we want to expose 
systemsettings to non-Plasma users. Just like we don't want GNOME's settings 
tool exposed to Plasma users.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Martin Graesslin]

On Thursday, April 7, 2016 4:37:14 PM CEST Alexander Potashev wrote:
> 2016-04-07 16:14 GMT+03:00 Martin Graesslin <mgraess...@kde.org>:
> > system settings is a workspace configuration tool. I don't see how that is
> > useful to anyone not using Plasma
> 
> Martin,
> 
> One can use System Settings to start KCMs that are not related to Plasma:
>  - Localization,

you should use your desktops configuration tool instead. No need to use a 
Plasma one.

>  - Akonadi,

Erm no. I just did a search for Akonadi in systemsettings and it returns 
nothing. Even if it were in systemsettings it would be wrong. That needs to be 
offered from the applications.

>  - Baloo,

Use the DEs search tool

>  - systemd

There is no such thing as a systemd kcm in systemsettings

> and many more.

and for them there is kcmshell5.

If there is anything in systemsettings which makes sense outside of Plasma, it 
means it's wrong in systemsettings or lacking a proper way to configure from 
the application.

Cheers
Martin



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Martin Graesslin]

On Thursday, April 7, 2016 2:08:07 PM CEST Jonathan Riddell wrote:
> Martin's thread on metadata got me wondering about if we should have
> appstream files in Plasma.  It would be nice to have plasma-desktop in
> software installers for people who run another desktop and want to
> install it.  There's also applications like

> system settings (which has
> dozens of plugins),

system settings is a workspace configuration tool. I don't see how that is 
useful to anyone not using Plasma 

> khotkeys

khotkeys is already on the death bed - see my thread for that. Also it relies 
on Plasma tools like kded, kcmshell/systemsettings, etc.

> and kinfocenter which may or may not be
> useful for appstream.

KInfocenter when opened presents me:
* a huge plasma logo
* the plasma version

I don't see how that's useful for anybody not using Plasma.

Personally I don't think that it makes sense to list the Plasma tools in 
appdata.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: metadata.yaml for Plasma projects?

[Martin Graesslin]

On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote:
> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > Hi Plasmates,
> > 
> > an idea for better documentation is to introduce some metadata similar
> > like
> > what frameworks have. This could be useful for potential devs who want to
> > contribute, but also for distributions as in that way:
> > * we can specify whether it's experimental, released, obsoleted, etc.
> > * what other Plasma projects it depends on
> > * who is maintaining it and where to reach us
> > 
> > Below I have an example how this could look like (in the case of KWin).
> > 
> > What do you think?
> > 
> > Cheers
> > Martin
> > 
> > # The maintainer of the project
> > maintainer: graesslin
> 
> I'd suggest offering an appstream appdata file instead of this.

We have projects for which appstream doesn't make sense. Example is KWin, 
kdecoration, kscreenlocker, kwayland, etc. etc. In fact I think we have more 
projects in Plasma which do not need an appdata file than projects which 
actually benefit from it.

> 
> > # A short description of the project
> > description: X11 Window Manager and Wayland Compositor
> 
> Same
> 
> > # tier 1: depends only on Qt and KDE frameworks
> > # tier 2: depends only on Qt, KDE frameworks and tier 1 Plasma projects
> > # tier 3: depends on Qt, KDE frameworks, tier 1, 2 and 3 Plasma projects
> > tier: 3
> 
> Why?

Because distros gave us the feedback that they have a hard time figuring out 
the dependency chain in Plasma. By introducing this information they know 
better how the build sequence will look like.

> 
> > # Whether the project is obsoleted, if true means it's not included in
> > future # releases any more
> > obsoleted: false
> > # Whether this is an experimental project
> > experimental: false
> > # Whether it's included in releases
> > release: true
> > # The git clone url
> > git: git://anongit.kde.org/kwin
> 
> Isn't that what .git/config will be saying?
> Or "git remote show origin".

Only if you cloned it. But there are also released tars

> 
> > # some code review information on phabricator
> > 
> > phabricator:
> > # url to the diffusion
> > diffusion: https://phabricator.kde.org/diffusion/KWIN/
> > # the review group
> > reviewer: plasma
> > # the project it belongs to
> > project: plasma
> 
> That should be part of .arcconfig.

yes, but the random developer looking at our code has no idea that there are 
hidden files and without knowing anything about arc and phabricator, the random 
dev doesn't know that that's the review tool.

Maybe the naming should be better to highlight that more, e.g:
codereview:
 coderepo: https://phabricator.kde.org/diffusion/KWIN/
phabricator: #linktothephabtoolijustcannotrememberthe name

> 
> > irc:
> > network: chat.freenode.net
> > channel: "#kwin"
> > 
> > mailinglist: k...@kde.org
> > 
> > bugs:
> > url: https://bugs.kde.org
> > product: kwin
> > 
> > dependencies:
> > - KWayland
> > - KDecoration
> > - KScreenLocker
> 
> That's in kde-build-metadata.

No it's not. kde-build-metadata encodes it for the current master and current 
stable branch. It does not encode it for Plasma 5.5.0 release. By putting it 
into git we have it.

Btw. I took that part from frameworks metadata description on our wiki.

> 
> Having duplicated human-read-only information is always bad and will
> only lead us to outdated information.

Yes there is the danger of outdated information. On the other hand it seems to 
work for frameworks.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: metadata.yaml for Plasma projects?

[Martin Graesslin]

On Thursday, April 7, 2016 12:01:22 PM CEST Marco Martin wrote:
> On Thursday 07 April 2016 11:41:25 Martin Graesslin wrote:
> > Hi Plasmates,
> > 
> > an idea for better documentation is to introduce some metadata similar
> > like
> > what frameworks have. This could be useful for potential devs who want to
> > contribute, but also for distributions as in that way:
> > * we can specify whether it's experimental, released, obsoleted, etc.
> > * what other Plasma projects it depends on
> > * who is maintaining it and where to reach us
> > 
> > Below I have an example how this could look like (in the case of KWin).
> > 
> > What do you think?
> 
> +1
> 
> one thing tough, projects like plasma-workspace or plasma-desktop are
> actually a collecion of "stuff" could they be furter broken with metadata
> files in subdirectories?

That could be something like:
subproject:
- metadata: klipper/metadata.yaml
- metadata: shell/metadata.yaml

Cheers
Martin 


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

metadata.yaml for Plasma projects?

[Martin Graesslin]

Hi Plasmates,

an idea for better documentation is to introduce some metadata similar like 
what frameworks have. This could be useful for potential devs who want to 
contribute, but also for distributions as in that way:
* we can specify whether it's experimental, released, obsoleted, etc.
* what other Plasma projects it depends on
* who is maintaining it and where to reach us

Below I have an example how this could look like (in the case of KWin).

What do you think?

Cheers
Martin

# The maintainer of the project
maintainer: graesslin
# A short description of the project
description: X11 Window Manager and Wayland Compositor
# tier 1: depends only on Qt and KDE frameworks
# tier 2: depends only on Qt, KDE frameworks and tier 1 Plasma projects
# tier 3: depends on Qt, KDE frameworks, tier 1, 2 and 3 Plasma projects
tier: 3
# Whether the project is obsoleted, if true means it's not included in future 
# releases any more
obsoleted: false
# Whether this is an experimental project
experimental: false
# Whether it's included in releases
release: true
# The git clone url
git: git://anongit.kde.org/kwin
# some code review information on phabricator
phabricator:
# url to the diffusion
diffusion: https://phabricator.kde.org/diffusion/KWIN/
# the review group
reviewer: plasma
# the project it belongs to
project: plasma
irc:
network: chat.freenode.net
channel: "#kwin"
mailinglist: k...@kde.org
bugs:
url: https://bugs.kde.org
product: kwin
dependencies:
- KWayland
- KDecoration
- KScreenLocker


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Enabling users to report issues with Plasma widgets

[Martin Graesslin]

On Monday, April 4, 2016 7:06:40 PM CEST Friedrich W. H. Kossebau wrote:
> Hi,
> 
> challenge:
> 1. take your favourite Plasma widget
> 2. find a bug or idea for an improvement with it
> 3. report it to the maintainer of the widget
> 
> 1. & 2. are easy.
> But 3. is not easy at all.
> 
> Question:
> Are endusers supposed to report issues with Plasma widgets and get in
> contact with its developers, designers, translators?
> 
> If "of course, yes" then they need to be enabled & encouraged to do so.
> At least every XMLGUI-based QWidget app has "Help">"Report Bug...". IMHO
> there should be something similar for Widgets. And something like "About"
> info as well, to know who to talk to or where the widget is from and the
> version.
> 
> Right now an enduser has no single clue in the UI where to go to with any
> widget issues. As a widget developer I experience that as a big burden,
> because it prevents feedback from the average enduser. Which sucks.
> 
> Please comment on this. Once I know your ideas about that, I would consider
> pushing this further to the VDG, so they can draft a nice UX for that, one
> without bloating the UI but still being discoverable and useable.

Speaking now with the experience from KWin (which has a dedicated info page 
per effect):
* cannot remember that I ever got contacted directly by a user due to the 
about information
* bug reports hardly reference an effect plugin directly. Users cannot and 
should not know where the bug is, whether it's in the plugin or in the 
infrastructure
* our devs don't care about it. I don't know in how many reviews I pointed out 
that I'm not the author of the newly added effect

So with the experience of the 40 plugins in KWin I think the possible gains 
presented here do not justify the addition of code and UI elements.

The only real argument I see is honor those who deserve honor. If we want to 
show in 3rd party plasmoids that they are 3rd party, we need them. But not for 
bugs, translators, designers.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Sunsetting khotkeys?

[Martin Graesslin]

On Thursday, March 31, 2016 5:15:26 PM CEST Ivan Čukić wrote:
> > Input macro recorders/editors have fairly large userbase on competing
> > systems (e.g. enthusiast gamers on Windows, who easily outnumber
> 
> +1
> 
> When I read Martin's post, I expected 'kwin will do it', not 'we don't need
> it'.

I have no idea what "input macro recorders/editors" are supposed to be. Thus I 
don't know whether KWin can/should/whatever support that.

Also I don't think that Plasma is a system for gamers. Sorry to put it like 
that, we are really bad in that area and suck on X11 for it and also on 
Wayland. That's not what I'm optimizing KWin for (and if you read my blog 
posts I do think that gaming is nothing which belongs into a desktop 
environment, it should be outside).

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Sunsetting khotkeys?

[Martin Graesslin]

Hi,

I want to propose to not release KHotKeys with Plasma 5.7 anymore.

The reasons are:
* it's unmaintained (e.g. Ben sent us a mail about failing build)
* it never got properly ported to Qt5 (xcb port partially missing)
* many features need to be moved to KWin in order to support it in Wayland
* UI is extremely complicated

Of course there are useful features in KHotKeys and removing them will not be 
something some of our users will appreciate. Thus we need to make sure we 
transit properly.

* starting applications on global shortcuts can be provided directly by 
KGlobalAccel
* invoking DBus commands directly can be provided by KGlobalAccel
* setting a global shortcut for an application can be done in KMenuEdit
* sending fake input or a dbus command is nothing different to starting an 
application
* window actions can nowadays be done with KWin scripts

Required actions will be:
* add support to start applications in KGlobalAccel
* migrate the existing KHotKey shortcuts to KGlobalAccel without the user 
noticing
* migrate the dbus command/fake input to shell scripts with a desktop file and 
register them in KGlobalAccel
* generate kwin scripts from the window actions

An idea can also be to improve the global shortcuts configuration module to 
make it easier to set global shortcuts from there.

What do you think?

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Workspace - Improperly exporting targets

[Martin Graesslin]

On Tuesday, March 29, 2016 10:13:02 AM CEST Ben Cooksley wrote:
> Hi Plasma Devs,
> 
> It would appear Plasma Workspace is improperly exporting it's targets,
> leading to build failures. This particularly affects Apper, which is
> unable to build on the CI system as a result. Please ensure when
> exporting targets / finding libraries that the full path to the
> library is given, not a short name.
> 
> Please see
> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compile
> r=gcc/consoleFull for more details.

Well it looks like Apper is doing it wrong. It links kworkspace5 instead of 
PW::KWorkspace

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Considering a Qt 5.6 dependency for plasma-workspace

[Martin Graesslin]

On Thursday, March 24, 2016 5:31:21 PM CET Aleix Pol wrote:
> Hi,
> I'd like to suggest a Qt 5.6 dependency for plasma-workspace master
> (and maybe other repositories too).
> 
> My personal interest is mostly because of the patch that drops KScreen
> dependency in plasmashell [1], but I still think it makes sense on
> other areas and it's unlikely that plasma 5.7 is going to ever be run
> under Qt 5.5 anyway (in fact, Plasma 5.6 won't be run under Qt 5.5
> either on most distributions, interestingly).

As long as there is no Qt 5.6 bug fix release which doesn't block kded on 
startup I suggest that we don't depend on Qt 5.6. We currently know it's 
broken and completely unusable for us.

Let's wait for the bug fix release and then depend on 5.6.1.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Common purpose for the Plasma team, and VDG

[Martin Graesslin]

On Monday, November 9, 2015 11:38:42 PM CET kainz.a wrote:
> Yes different communication systems are one of the main problem. Different
> tasks are the second problem. When I read the VDG forum threads or the
> Telegram thread there was discussion about some stuff but less than 5% are
> bugfixing and for me reviewboard is for bugfixing, or I use it for this
> kind of stuff.

Just in case that this does not result in a misunderstanding on how we use the 
tools: reviewboard is for all changes. We especially use it for new features 
and not just for bug fixes.  Most often the review process for new code is way 
more important than for bug fixes (which might be obvious or trivial).

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Freeze kde-workspace repo for good

[Martin Graesslin]

On Friday, September 4, 2015 10:31:59 AM CEST Martin Klapetek wrote:
> +1, although I don't think it would prevent people from creating
> patches...or would RB refuse a patch against those blocked
> branches?

probably not, but it makes working with those easy: repo frozen, sorry cannot 
be pushed. Please recreate against the repos in kde/workspace module.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: I've got kwin_wayland + plasmashell (wayland) running in a container (bugs included)

[Martin Graesslin]

On Tuesday, March 15, 2016 3:21:58 PM CET Sebastian Kügler wrote:
> Hi Sebastian,
> 
> On Monday, March 14, 2016 05:36:28 PM Sebastian Grüner wrote:
> > hey all,
> > 
> > I've been fiddling around wit lxc on a smartphone the other week, did
> > some reading and thought I'd try out some ideas with kwin_wayland.
> > This is one of your proposals for this years GSOC projects at KDE [1],
> > and I know my approach is different from what is explained there.
> > Nevertheless I'd like to share my initial hack with you, in case anyone
> > wants to pursue this further.
> > Long story short: I copied random bits and pieces of the web and got
> > kwin_wayland and plasmashell (via startplasmacompositor) running in a
> > containerized environment with native hardware acceleration, no llvmpipe
> > needed :-). (I used systemd-nspawn, docker and lxc should work as well,
> > haven't tried this though).
> > 
> > Here is what I've done:
> > Get a rootfs of your favorite distro:
> > - I use Opensuse Tumbleweed since I am familiar with this. (KDE
> > Frameworks 5.20, Plasma 5.5.95)
> > - I set up Debian unstable as well, which worked, but this uses old KDE
> > packages (debootstrap)
> > - I tried Ubuntu Xenial (debootstrap), weston works with native hw, but
> > kwin_wayland won't start up.
> 
> [...]
> 
> > There is probably a lot of stuff that could be improved upon, but I got
> > plasmashell in a container up and running!
> > If the container hangs/crashes you can terminate it from a different tty
> > with machinectl [3].
> > 
> > I hope you like this. :-)
> 
> I do!
> 
> What I'm wondering is how hard would it be to run such a container on a very
> bare Mer system? Mer has great support in hardware, but a downside is that
> we'd have to do almost all the packaging of our stack twice, that adds huge
> overhead, both in building, build infrastructure and in testing. Now if we
> could create images from a Mer hardware adaption with Neon or Debian
> builds, we could get great hardware support for mobile devices while having
> to do the packaging only once.
> 
> Have you thought about this? Am I ignoring major roadblocks?

sorry I don't think that gives us much. The question is whether KWin can 
access the device hardware. If it can it means we have a DRM enabled driver. 
If yes KWin will work just fine without the need for a container. If it doesn't 
(which is where Mer comes in the game) it doesn't help us as we need the 
Android stack inside the container (KWin would need to use hwcomposer). That's 
a completely different problem and probably not solved by passing the dri 
device into the container.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: I've got kwin_wayland + plasmashell (wayland) running in a container (bugs included)

[Martin Graesslin]

Hi Sebastian,

that's pretty cool! Thanks for sharing. 

Cheers
Martin

P.S.: Personally I'm a little bit shocked to see how easy it is to expose the 
GPU as that makes escaping the container pretty easy.

On Monday, March 14, 2016 5:36:28 PM CET Sebastian Grüner wrote:
> hey all,
> 
> I've been fiddling around wit lxc on a smartphone the other week, did
> some reading and thought I'd try out some ideas with kwin_wayland.
> This is one of your proposals for this years GSOC projects at KDE [1],
> and I know my approach is different from what is explained there.
> Nevertheless I'd like to share my initial hack with you, in case anyone
> wants to pursue this further.
> Long story short: I copied random bits and pieces of the web and got
> kwin_wayland and plasmashell (via startplasmacompositor) running in a
> containerized environment with native hardware acceleration, no llvmpipe
> needed :-). (I used systemd-nspawn, docker and lxc should work as well,
> haven't tried this though).
> 
> Here is what I've done:
> Get a rootfs of your favorite distro:
> - I use Opensuse Tumbleweed since I am familiar with this. (KDE
> Frameworks 5.20, Plasma 5.5.95)
> - I set up Debian unstable as well, which worked, but this uses old KDE
> packages (debootstrap)
> - I tried Ubuntu Xenial (debootstrap), weston works with native hw, but
> kwin_wayland won't start up.
> 
> Systemd comes with a minimal container tool, systemd-nspawn [2], which
> is described as similar to a chroot and quite easy to use. With this one
> can just switch into the rootfs:
> 
> sudo systemd-nspawn -D $ROOTFSDIRECTORY/
> 
> systemd-nspawn has quite a lot of command line switches, you can set
> environment variables and bind-mount specific directories for example.
> So why not just bind-mount the device-node of my graphics-card?
> here we go:
> 
> xhost +local:
> 
> sudo systemd-nspawn --setenv=DISPLAY=:0 \
> --setenv=XAUTHORITY=~/.Xauthority \
> --setenv=XDG_RUNTIME_DIR=/run/user/1000 \
> --bind-ro=$HOME/.Xauthority:/root/.Xauthority \
> --bind=/run/user/1000/:/run/user/1000 \
> --bind=/tmp/.X11-unix \
> --bind=/dev/shm:/dev/shm \
> --bind=/dev/dri/card0:/dev/dri/card0 \
> -D suse/ kwin_wayland --libinput --xwayland --drm --windowed "konsole
> --platform wayland"
> 
> Initially I tried weston: to do this just change the command at the very
> end. If you change the command to startplasmacompositor the Plasma
> desktop starts up. In order to make Plasma useable and avoid loops for
> kscreen, powerdevil you need Dbus, so I just did bind mount my
> bus-socket with
> 
> --bind=/run/dbus/system_bus_socket:/run/dbus/system_bus_socket
> 
> It should be somehow possible to run the dbus-daemon from within the
> container.
> 
> There is probably a lot of stuff that could be improved upon, but I got
> plasmashell in a container up and running!
> If the container hangs/crashes you can terminate it from a different tty
> with machinectl [3].
> 
> I hope you like this. :-)
> 
> Sebastian
> 
> [1]
> https://community.kde.org/GSoC/2016/Ideas#Project:_Running_KWin.2FWayland_in
> _a_Docker_container [2]
> https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html [3]
> https://www.freedesktop.org/software/systemd/man/machinectl.html
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Moving Breeze lookandfeel to breeze repository

[Martin Graesslin]

On Wednesday, March 2, 2016 1:01:27 PM CET Aleix Pol wrote:
> On Wed, Mar 2, 2016 at 10:14 AM, Marco Martin  wrote:
> > On Wednesday 02 March 2016 02:06:52 Aleix Pol wrote:
> >> It would also solve my little issue with xdg-app, although if you know
> >> of another way to fix this, I'll be happy to know as well.
> > 
> > I clearly see the rationale,
> > I'm just a bit worried that quite important things are in there, like the
> > lockscreen or the sddm ui.
> > 
> > besides we has to guarantee the same maintainership level, breeze would
> > have to become an hard dependency of plasma-workspace, otherwise we could
> > ship a workspace without lockscreen or sddm.. whoops
> 
> What do you mean exactly with "hard dependency"? How do you enforce it?

I would go with:
* Installing a CMakeConfig in Breeze and
* find_package(Breeze REQUIRED)

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Moving Breeze lookandfeel to breeze repository

[Martin Graesslin]

On Wednesday, March 2, 2016 2:06:52 AM CET Aleix Pol wrote:
> Hi,
> More specifically:
> plasma-workspace/lookandfeel/
> 
> My Context:
> I was looking into why applications are trying to load oxygen icons
> instead of breeze on xdg-apps. The reason is that it was falling back
> because breeze couldn't be found. AFAIU, this is offered by
> $PREFIX/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/defaults.
> 
> Now here's my reasoning: We already have similar stuff in the breeze
> directory (QStyle, Window Decorations), having the Plasma Workspace
> integration also makes sense.
> Furthermore, it's what we do for breeze-dark nowadays. In fact,
> "share/plasma/look-and-feel/org.kde.breeze.desktop" comes from
> plasma-workspace and
> "share/plasma/look-and-feel/org.kde.breezedark.desktop" comes from the
> breeze repository. And the same file for oxygen, comes from the oxygen
> repository.

I think we still need some look-n-feel package in plasma-workspace. Some 
fallback for the case that breeze is not installed. Comparable KWin ships one 
window decoration as a fallback for breeze not being installed.

Cheers
Martin

> 
> It would also solve my little issue with xdg-app, although if you know
> of another way to fix this, I'll be happy to know as well.
> 
> Aleix
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Put notifications in sidepanel like widget explorer

[Martin Graesslin]

On Monday, February 22, 2016 9:05:06 PM CET Marco Martin wrote:
> On Monday 22 February 2016 18:39:02 Thomas Pfeiffer wrote:
> > > changes, so when the default systray will be changed to the new
> > > implementation in 5.7 it will look as near ar possible to the current
> > > one,
> > > with any UI changes for 5.8)
> > 
> > Why is that? To prevent the introduction of bugs?
> 
> yes, that's what unfortunately too many years of experience told me.

Yeah, that's also why I am very careful to implement all features from KWin on 
X11 in KWin on Wayland. No regressions to not have people burn the technology, 
because we removed feature foo.

> 
> the first time you introduce something with a new technology, it will
> introduce regressions no matter what. People are in general resistent to UI
> changes as well.
> technology changes + regressions + a different, unfamiliar ui is the sure
> recipe to make users hate the whole thing and have the next neponadi (and
> boy plasma had to work hard to get out of that after KDE 4.0, and we are
> still on the recovery phase)



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma grub theme unified design

[Martin Graesslin]

On Thursday, February 18, 2016 2:53:48 PM CET kainz.a wrote:
> 2016-02-18 14:29 GMT+01:00 Marco Martin :
> > On Thursday 18 February 2016 14:20:18 kainz.a wrote:
> > > Hi,
> > > 
> > > the VDG is working on an unified design from the boot to the shut down.
> > > therefore we workon a grub2, plymouth, sddm, ksplah theme. we have a
> > > wiki
> > > page https://community.kde.org/KDE_Visual_Design_Group/Unified_Login
> > 
> > which
> > 
> > > will be updated when we have access again.
> > > 
> > > grub theme is finished and ready for testers
> > > https://share.kde.org/index.php/s/Pyee8QqZPe0aTMT here is an movie how
> > 
> > it
> > 
> > > look like https://share.kde.org/index.php/s/XaqpgyiTbzua3oT
> > > 
> > > all our stuff is stored at
> > 
> > https://share.kde.org/index.php/s/aRhTTNLFiRMFbVn
> > 
> > > - grub is ready for testers
> > > - plymounth harald is working on it
> > > - sddm theme mockup is finished dev's are welcome
> > > - ksplash mockup is there I will have a look if I can make it myself
> > 
> > is logout screen/lockscreen included as well? they share design with
> > sddm/ksplash
> > 
> > > if someone know how to make an sddm theme or an ksplash theme. you are
> > 
> > more
> > 
> > > than welcome. My goal is to have everything ready for the plasma 5.6
> > > release. If I don't catch the goal, ...
> > 
> > ksplash probably fast to do..
> > sddm (of which i never touched a theme) it's probably a bit more hairy and
> > likely to fail, so i'm not too sure is a good idea  for 5.6, is one of
> > those
> > things that should be done at the beginning of a cycle
> 
> In understand you. The thing is when you look in the plasma 5.5 SDDM theme
> it look quite bad cause of the breeze plasma theme change and nobody solve
> this issue and there were oxygen icons (for the avatars).
> 
> Plasma 5.4 SDDM theme
> http://i1-news.softpedia-static.com/images/news2/Kubuntu-15-04-Alpha-2-Is-th
> e-Most-Exciting-Release-in-a-Long-Time-Screenshot-Tour-470968-11.jpg
> 
> Plasma 5.5 SDDM theme
> http://images.derstandard.at/2015/12/09/plasma.png

The second screenshot is showing my name so I assume I did that one which 
means it's from a Wayland session. It's the lock screen and not SDDM.

I don't want to exclude the possibility that I have my system and especially 
my Wayland session misconfigured. And as everybody here knows: I'm not the one 
to notice such visual inconsistencies.

So please first clarify whether there is really a bug that oxygen icons get 
picked up and remind me to never do screenshots again ;-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: repo freeze on Thursday

[Martin Graesslin]

On Monday, February 15, 2016 11:46:11 AM CET Jonathan Riddell wrote:
> The Plasma 5.6 repo freeze is on Thursday.  We can't add new git
> repositories to make tars after Thursday.  Does anyone have any git
> repositories that need added to this release which were not in 5.5?

new repo: https://phabricator.kde.org/diffusion/PLASMAINTEGRATION/

git clone git://anongit.kde.org/plasma-integration

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Solid/PowerManagement deprecation

[Martin Graesslin]

On Wednesday, February 10, 2016 3:55:51 PM CET Aleix Pol wrote:
> Hi,
> I've been looking in the last days what applications and uses make our
> software stick to KDELibs4Support.
> 
> My impression is that the big missing thing is Solid/PowerManagement.
> 
> Is anyone looking into the issue?

I replaced the usage in kscreenlocker (suspend/hibernate) with new written 
code which does nice async dbus. From the start I considered that this code 
could become the base for a new lib, so it has the right licence, etc. Commit 
is at:

http://commits.kde.org/kscreenlocker/a04768901ac13985dd673bbb45f2bf98d9a52903

But overall I don't know what is really needed from a PowerManagement API.

> Should we look into un-deprecating it?

given the very sync-dbus state of the API, I would not recommend to.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] Plasma mobile components -> Plasma controls

[Martin Graesslin]

On Monday, February 8, 2016 1:21:01 PM CET Marco Martin wrote:
> Hi all,
> 
> It's almost time to make the plasma mobile components a framework/repository
> by itself, and with that I'm wondering of "plasma mobile components" it's
> even the proper name after all.
> 
> Following the Qt naming conventions i was going for "Plasma Controls" where
> "Plasma" is there purely for branding, but not as "dependency" (at least can
> be disabled at build time) and that is not reall "mobile" specific. There
> are things that aren't really "mobile" , like colors and listviews.. one
> could use pieces of them in desktop apps and plasmoids as well, as long as
> doesn't use the really mobile specific parts.
> 
> so a name should be:
> * Exprime that it's something "extra", it's not the "buttons and textboxes"
> of QQC1/2
> * Exprime that is ours (would go for Plasma instead of KDE for the usual KDE
> is people)
> * I wouldn't stress too much on it being "mobile"
> 
> Opinions? comments?

Plasma is the brand for the "Desktop Shell". Why use Plasma as the name for 
the components, then? Isn't that going to be confusing for devs. Like the 
assumption that you need Plasma or it's only for Plasma? Kind of introducing 
the same problems as we used to have with the generic KDE name?

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] Plasma mobile components -> Plasma controls

[Martin Graesslin]

On Monday, February 8, 2016 4:07:35 PM CET Marco Martin wrote:
> On Monday 08 February 2016, Martin Graesslin wrote:
> > Plasma is the brand for the "Desktop Shell". Why use Plasma as the name
> > for
> > the components, then? Isn't that going to be confusing for devs. Like the
> > assumption that you need Plasma or it's only for Plasma? Kind of
> > introducing the same problems as we used to have with the generic KDE
> > name?
> 
> perhaps...
> what i was thinking about is that we have this work tightly coupled together
> the HIG work.
> That's pretty much the pack of things that google calls "Material design"
> (blackberry had cascades, microsoft could have metro but fucked up, apple
> doesn't seem to have a name)
> 
> "Breeze Design" wouldn't go i think, because is more just a theme, we
> probably need an hip name for the components, and general design/hig of
> applications.
> 
> We could call it something high brow like "Flow" or some bs like that

maybe something for the VDG to come up with a good name, otherwise I vote for 
"Bikeshed Controls" :-P

But yeah, if it goes into a tier 1 framework it makes sense to do a generic 
"hip" name.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: plasma logo as start menu icon and ksplash logo

[Martin Graesslin]

On Wednesday, February 3, 2016 4:59:18 PM CET Marco Martin wrote:
> Hi all,
> This is just an idea: since our branding of the desktop offer as "Plasma"
> seems to start to work, but still needs work, one of the first points that
> come to mind speaking about branding is the logo.
> 
> What I'm proposing is to change the K logo on start menus and ksplash (and
> any other place where it makes sense, being plymouth, sddm, various docs
> and websites around..) with the Plasma logo, to make more marketable as a
> stand alone product what our desktop offer is
> Either the current Plasma logo or whatever new shiny logo the VDG comes up
> with if they feel the current one isn't up to scratch.
> I had doubts about this in the past as the K logo is the trademarked one,
> but I'm starting to get convinced the time has come ;)
> 
> Opinions? Comments?

I feel the same. I had concerns about it in the past but now I'm supportive to 
the idea.

So +1

Cheers
Martin



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Evolving Appdash

[Martin Graesslin]

On Thursday, December 17, 2015 1:01:44 PM CET Martin Graesslin wrote:
> On Thursday, December 17, 2015 12:52:35 PM CET Marco Martin wrote:
> > On Wednesday 16 December 2015, Martin Klapetek wrote:
> > > > Also the appdash is almost unusable without a blur effect (which for
> > > > example
> > > > happens with GLES, XRender and QPainter backends).
> > > 
> > > How about generating blurred wallpaper at some point, storing it
> > > and then using that as background? Blurrin a 20MPx (5472x3648)
> > > image here with gaussian blur in gimp takes about 5 seconds,
> > > 1920x1280 then takes less than 3 seconds. I'm not sure how well
> > 
> > I would really dislike that look...
> > as the pasted irc conversation, a new effect that blurs a downsampled
> > entire screen would be better i think ( and fast enough)
> 
> I'll investigate after the Christmas break how to expose a downsampling blur
> in the effects infrastructure. Ideally this can be achieved with zero costs
> in the rendering.

Resulted in https://git.reviewboard.kde.org/r/126906/

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE Development VirtualBox

[Martin Graesslin]

On Wednesday, January 27, 2016 5:09:29 PM CET James Augustus Zuccon wrote:
> Hi guys,
> 
> Had a look around, but couldn't find much about this.
> 
> Is there a VirtualBox Image available for KDE Development specifically
> (with most of the common libraries and their corresponding includes
> installed)?

To my knowledge there is no such image.

> 
> If not, is it worth us creating one to save new developers from having to
> setup a build environment?

Not sure whether this makes much sense. Let me explain why:

* VMs are odd, we have problems with the GPU
* the build needs to be setup nevertheless, e.g. git needs to be configured
* the image will be constantly out of date needing a rebuild of the software

What I think is better is having something based on an up-to-date unstable 
packages. So that the base is already there and it's easy to just hack on one 
thing. Oh and good documentation might even be more important.

> 
> Any thoughts as to what the best Distro to base this on might be?

All of them and none of them. Everybody has his pet distro and if the image is 
not that one it won't be used ;-)

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Window thumbnail discussion

[Martin Graesslin]

On Thursday, January 21, 2016 12:06:48 PM CET Martin Gräßlin wrote:
> I plan to write something down in the wiki next week, which should be a
> better starting point for discussions then.

Created a wiki page: https://community.kde.org/KWin/Window_Metadata

Please feel free to extend/fix as needed :-)

Cheers
Martin

The content I added is:

=Window Metadata=
==Rational==

Window Thumbnails as scaled down window content are hardly useable. Windows of 
same application are hardly distinguishable from each other which eliminates 
all advantages from thumbnails in first place.

In addition on Wayland it is difficult to get access to live-updating window 
thumbnails in the desktop shell. While the compositor has access to the window 
content, other applications do not. This would require a custom protocol to 
pass the window content from the compositor to the desktop shell. A protocol 
would be required which would be fairly close to being an own Wayland server.

This document describes how to put the application more in control of the 
window thumbnail which will be rendered.

== General Architecture ==

The protocol will be implemented using DBus to be windowing system agnostic. 
The window manager registers a DBus service "org.kde.kwin.windowmetadata1" and 
the object path "/org/kde/kwin/WindowMetadata1". On this interface there is a 
call "register" which allows an application to call it and to indicate that it 
supports the protocol.

The window manager is able to map windows to the DBus peer through the PID. On 
both X11 and Wayland the window manager has access to the PID. In case of 
Wayland this is only possible for the window manager, thus the DBus service 
must be bound on the window manager.

When a thumbnail is required the window manager informs the application for 
which window and in which size a thumbnail is needed. In addition it passes a 
filedescriptor of a pipe to the application. The application renders the 
thumbnail and writes the rendering result into the pipe and closes the pipe 
once the rendering is
finished. The application can render a thumbnail of different size if this of 
more use. To support that a small binary protocol on the pipe is required. It 
needs to describe:
 * size (width/height)
 * stride
 * image format
 * byte count
 * binary data

Obviously the server side needs to sanity check the values.

The protocol is not meant to have life-updating previews. There is a DBus call 
for the application to indicate that it has new data available, but it's the 
responsibility of the server to initiate the process. By that the server can 
control the updates to a sensible amount.

== Passing thumbnail to Desktop Shell ==

Internal implementation detail, to be defined.

== Window Actions ==

An additional idea is to allow the application to specify additional actions 
through the DBus interface. E.g. a "reload" action in a browser. This is 
intended to be implemented in a future release.

== Implementation ==

The implementation will be provided through a tier1 framework. It will be 
windowing system agnostic and only depends on DBus. For the application it 
will be as simple as just rendering to a QImage (through QPainter) or using a 
special QtQuick import.

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Proposal: integrity checks for packages and cryptographic signing

[Martin Graesslin]

Hi all,

happy new year! I had a too long Christmas break and spent quite some thinking 
about how to improve the security situation on Plasma/Wayland and I think I 
found a solution to address one of the problems.

tldr: we need to sign installed packages and verify the integrity when loading 
the package.

== Attack scenario ==
A browser has a vulnerability allowing drive-by downloads to $HOME. This 
allows an attacker to store KPackages (e.g. Plasmoids) which will get loaded 
by the application using the malicious data. What are the threats of this:

1. Declarative/QML kwin scripts: a declarative kwin script is able to take 
over rendering of the system and intercept all input events. This is 
comparable to running an X Server.

2. A Plasmoid is able to render a window thumbnail to a frame buffer object 
and store/send it somewhere. This is a violation of secure screenshots. Also 
as Plasma dialogs can place themselves it allows to take over the system in 
similar ways as on X11.

3. A look'n'feel package can install a key logger into the lock screen.

== What I want to solve? ==

I do not want to prevent the attack vectors outlined above as that's a futile 
exercise. Thus I want to return to "if it runs it's trusted" in a reliable 
way. If a user downloads a plasmoid it's trusted, but a drive-by download is 
not trusted. Thus we need to establish "trust".

== How to get there? ==

My proposal is that while packages get installed the sha-sum of each file gets 
calculated and written into a shasums file. The shasums file gets 
cryptographically signed and both the shasums file and the signature get 
installed as well.

On loading a package we traverse the package install location, generate the 
sha-sum of each found file, check that it exists in the shasums file, verify 
it's correct. In addition we check that the signature is valid and that all 
files listed in shasums were found. If any of the checks failed we abort 
loading the package.

== What will this solve? ==

By verifying the signature we know that the shasums file was not modified. By 
checking the shasum file of each file we know that those were not modified. By 
checking that no file was added or removed, we ensure that the integrity 
matches also in that way.

Overall this gives us an integrity check for the package. We know it wasn't 
tampered with since it got installed.

For the attack scenario this means: A drive-by download cannot just install a 
package or overwrite files. This would break the integrity check and the 
manipulated package would not be loaded. Similar it would not be able to 
install a malicious package as it's not able to sign it.

== What that means for developer setups? ==

Generating the shasum and signing the packages must become part of the general 
package installing. Rolling this out must not affect our own dev setup. Thus 
also plasmoidviewer should not require a valid signature as that's just not 
dev friendly.

In addition we must make it as easy as possible to allow developers to install 
their own private cert file and integrate the signing key into kdesrc-build/
cmake, so that just running kdesrc-build signs all packages with the private 
key. Our signature validation infrastructure must make it possible to have 
additional certificates installed in a global (not user) location. This should 
work for common dev setups installing to e.g. /opt as well. E.g. it should 
honor my /opt/kf5/etc/ location.

Overall: for devs it must not be disruptive! And that's possible.

== What this means for distributions? ==

That's where I fear opposition to the plan. We must integrate distributions 
early enough. Here I think key is that we don't sign our own packages, but let 
distributions sign them. That way distributions still have control over it, 
can change packages, add own, etc. The setup for developers should make that 
possible. Also a possibility is that we sign the distros certificate with our 
root certificate - but that's an implementation detail.

== What this means for 3rd party developers? ==

We need to setup a signing infrastructure.

== How to roll it out? ==

The last point makes it obvious: this will take time. We cannot just go there 
and enable it in next plasma release as that would break 3rd party developed 
packages.

Thus I suggest the following steps:
1. change the install command to generate the shasums
2. implement generic infrastructure in KPackage to validate the shasums/
signature
3. start to use it in KWin/Wayland for all scripted elements (security risk 
really high)
4. start setup CA infrastructure
5. start signing 3rd party plasmoids
6. start validating packages, but allow to still load not-signed packages
7. on Wayland switch over

The last point I think should not happen in 2016. So we have about a year to 
get everybody on board.

== This whole thing is futile, because... ==

because there are so many other ways to take over control over the system? 
That's true, let's fix them and 

Re: Draft split for qpt plugin from frameworkintegration

[Martin Graesslin]

On Thursday, December 17, 2015 5:48:47 PM CET Martin Graesslin wrote:
> On Thursday, December 17, 2015 4:32:48 PM CET Aleix Pol wrote:
> > On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin <mgraess...@kde.org>
> 
> wrote:
> > > Hi all,
> > > 
> > > following up on [1] I have prepared a split of frameworkintegration to
> > > move
> > > the QPT plugin into a dedicated repository. You can find it in [2].
> > > Please
> > > have a look at the split repo to verify that it looks fine. If
> > > everything
> > > is OK, I'll request a new repo from sysadmins.
> > > 
> > > Some general notes
> > > * new repo name: plasma-integration
> > > * new plugin name: PlasmaDesktopPlatformTheme
> > > * new src folder name: src/plasma-desktop-platformtheme
> > > 
> > > Explaining the name changes:
> > > The plugin is renamed to not conflict on install with the existing
> > > plugin
> > > from frameworkintegration and also incorporating future changes Marco
> > > pointed out: we need a different QPT plugin for mobile.
> > > 
> > > How to remove the plugin from frameworkintegration:
> > > After the split we cannot remove it from frameworkintegration yet as
> > > that
> > > would break setups on the next framework release. Given that I plan to
> > > only
> > > phase it out: Introduce a cmake option to build and install it, which
> > > defaults to true till at least Plasma 5.6 is released. Afterward
> > > swapping
> > > the default to false, with a big fat warning and keeping it like that
> > > for
> > > at least half a year. Then remove it. We don't provide any guarantees
> > > for
> > > it, so we can remove it, but I want to keep the impact small.
> > > 
> > > Cheers
> > > Martin
> > > 
> > > [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> > > 029234.html
> > > [2] kde:scratch/graesslin/platform-integration
> > > (https://quickgit.kde.org/?
> > > p=scratch%2Fgraesslin%2Fplasma-integration.git )
> > 
> > I have my doubts that we want a different QPT for desktop and mobile.
> > If we want to provide any convergence we need to strive to have the
> > same on both platforms.
> 
> Good point! Marco is right: we need different presets whether it's desktop
> or mobile. You're right that different plugins would result in making
> switching impossible. Sounds like the plugin would have to learn to switch
> at runtime.
> 
> Given that feedback I'm considering to not rename the directory.

pushed a new variant without the rename of the source folder and the plugin 
renamed to KDEPlasmaPlatformTheme.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel