Re: Review Request 124220: kwindowsystem: Add a plugin infrastructure for platform specific implementations

2015-07-01 Thread Martin Gräßlin 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124220/
---

(Updated July 2, 2015, 8:19 a.m.)


Review request for KDE Frameworks.


Changes
---

incorporated suggested changes.


Repository: kwindowsystem


Description
---

A plugin interface is added which allows a platform specific plugin
to implement an interface. If the plugin does not implement the
interface, it will fall back to the default implementation. Also
if no plugin can be resolved it will fall back to the default
implementation.

This replaces the existing compile time and runtime selection. In
order to make this work the KWindowInfoPrivate is changed from a
templated approach to using pure virtuals just like the other private
implementations in this library.

As the platform specific parts are no longer compiled in we cannot
"just" delegate the KWindowSystem::icon with NETWinInfo overload
to the xcb implementation. In order to solve this problem the required
method is added to the private interface with a default implementation
which does not return anything. If we are not on platform xcb and
KWindowSystem is compiled with X11 support the plugin for xcb is loaded
and the call gets delegated to the xcb implementation. This allows e.g.
KWin to still read icons for Xwayland clients.


Diffs (updated)
-

  src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
  src/config-kwindowsystem.h.cmake fa0eec115870be27a17ec7b398e40f0c7506f11b 
  src/kwindoweffects.cpp fd88e20e1728506f135bcd5ecda3c05754839717 
  src/kwindoweffects_dummy.cpp 3e24cecb5c7d25883c179b622abdb5ab06587c33 
  src/kwindoweffects_dummy_p.h PRE-CREATION 
  src/kwindoweffects_p.h 7c740da952f279a2c5fe689daa5a06c131fa9c9d 
  src/kwindowinfo.cpp f29828581cdaecb7613c3f62cff72aa1fc33c266 
  src/kwindowinfo_dummy_p.h PRE-CREATION 
  src/kwindowinfo_p.h 6727dd1715a13e5bd7793275620c5fa682318f1c 
  src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
  src/kwindowsystem_dummy_p.h PRE-CREATION 
  src/kwindowsystem_p.h 0b5f3e8aeb7b70234c61c59979abd840f349b154 
  src/kwindowsystemplugininterface.cpp PRE-CREATION 
  src/kwindowsystemplugininterface_p.h PRE-CREATION 
  src/platforms/wayland/CMakeLists.txt PRE-CREATION 
  src/platforms/wayland/plugin.h PRE-CREATION 
  src/platforms/wayland/plugin.cpp PRE-CREATION 
  src/platforms/wayland/wayland.json PRE-CREATION 
  src/platforms/xcb/CMakeLists.txt PRE-CREATION 
  src/platforms/xcb/kwindoweffects.cpp  
  src/platforms/xcb/kwindoweffects_x11.h PRE-CREATION 
  src/platforms/xcb/kwindowinfo.cpp  
  src/platforms/xcb/kwindowinfo_p_x11.h  
  src/platforms/xcb/kwindowsystem.cpp  
  src/platforms/xcb/kwindowsystem_p_x11.h  
  src/platforms/xcb/plugin.h PRE-CREATION 
  src/platforms/xcb/plugin.cpp PRE-CREATION 
  src/platforms/xcb/xcb.json PRE-CREATION 
  src/pluginwrapper.cpp PRE-CREATION 
  src/pluginwrapper_p.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/124220/diff/


Testing
---

* unit tests still pass (X11)
* kwin_wayland still shows icons for Xwayland clients


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124226: Delete old highlighter

2015-07-01 Thread Lasse Liehu 


> On heinä 1, 2015, 10:35 ip, Aleix Pol Gonzalez wrote:
> > src/widgets/ktextedit.cpp, line 662
> > 
> >
> > no need for the if, you can just call `delete decorator->highlighter();`
> > 
> > Also this is weird, deleting a returned attribute is not common, maybe 
> > KTextDecorator should delete it?

Ok, will remove the if.

I agree that the API would be cleaner if SpellCheckDecorator had ownership of 
the highlighter set to it. But should that be changed and would that 
potentially break applications? Or did you mean to delete the default 
highlighter in KTextDecorator's constructor after it has been created in 
SpellCheckDecorator's constructor?

Actually the first fix to this bug in Lokalize was 
http://commits.kde.org/sonnet/5ed61b10f8f733a505bf04ce82f41d5616a21f25, which 
removed initialization of the default highlighter in SpellCheckDecorator's 
constructor. That was then reverted in 
http://commits.kde.org/sonnet/20bb0e90ad72bb3c2d8a009c50680eeb07c6d9c7. Sounds 
like that removal broke something.


- Lasse


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124226/#review81973
---


On heinä 1, 2015, 7:02 ip, Lasse Liehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124226/
> ---
> 
> (Updated heinä 1, 2015, 7:02 ip)
> 
> 
> Review request for KDE Frameworks and Laurent Montel.
> 
> 
> Repository: ktextwidgets
> 
> 
> Description
> ---
> 
> According to SpellCheckDecorator::setHighlighter's documentation, the old 
> automatically created default highlighter must be manually deleted.
> 
> This fixes bug 343459 in Lokalize.
> 
> 
> Diffs
> -
> 
>   src/widgets/ktextedit.cpp e4bd41d 
> 
> Diff: https://git.reviewboard.kde.org/r/124226/diff/
> 
> 
> Testing
> ---
> 
> Tested that it works in Lokalize. Also ran tests.
> 
> 
> Thanks,
> 
> Lasse Liehu
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124226: Delete old highlighter

2015-07-01 Thread Aleix Pol Gonzalez 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124226/#review81973
---



src/widgets/ktextedit.cpp (line 662)


no need for the if, you can just call `delete decorator->highlighter();`

Also this is weird, deleting a returned attribute is not common, maybe 
KTextDecorator should delete it?


- Aleix Pol Gonzalez


On July 1, 2015, 9:02 p.m., Lasse Liehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124226/
> ---
> 
> (Updated July 1, 2015, 9:02 p.m.)
> 
> 
> Review request for KDE Frameworks and Laurent Montel.
> 
> 
> Repository: ktextwidgets
> 
> 
> Description
> ---
> 
> According to SpellCheckDecorator::setHighlighter's documentation, the old 
> automatically created default highlighter must be manually deleted.
> 
> This fixes bug 343459 in Lokalize.
> 
> 
> Diffs
> -
> 
>   src/widgets/ktextedit.cpp e4bd41d 
> 
> Diff: https://git.reviewboard.kde.org/r/124226/diff/
> 
> 
> Testing
> ---
> 
> Tested that it works in Lokalize. Also ran tests.
> 
> 
> Thanks,
> 
> Lasse Liehu
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 123890: Don't show "KDE Frameworks version" in the About KDE dialog

2015-07-01 Thread Albert Astals Cid 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123890/
---

(Updated July 1, 2015, 8:56 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 343f3eb249e1370bd2d78114379207a540017a5a by Albert Astals 
Cid to branch master.


Repository: kxmlgui


Description
---

Doesn't make sense, if you want to know which frameworks version you're using 
you can use the application dialog version, this is about kde, and as such it's 
about the community, the frameworks version there matters nothing


Diffs
-

  src/kaboutkdedialog_p.cpp 1c3539b 

Diff: https://git.reviewboard.kde.org/r/123890/diff/


Testing
---


Thanks,

Albert Astals Cid

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 124226: Delete old highlighter

2015-07-01 Thread Lasse Liehu 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124226/
---

Review request for KDE Frameworks and Laurent Montel.


Repository: ktextwidgets


Description
---

According to SpellCheckDecorator::setHighlighter's documentation, the old 
automatically created default highlighter must be manually deleted.

This fixes bug 343459 in Lokalize.


Diffs
-

  src/widgets/ktextedit.cpp e4bd41d 

Diff: https://git.reviewboard.kde.org/r/124226/diff/


Testing
---

Tested that it works in Lokalize. Also ran tests.


Thanks,

Lasse Liehu

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QPA plugin like functionality in frameworks?

2015-07-01 Thread Milian Wolff 
On Tuesday 30 June 2015 20:33:09 Albert Astals Cid wrote:
> El Dijous, 25 de juny de 2015, a les 08:46:07, Martin Gräßlin va escriure:
> > On Wednesday 24 June 2015 23:20:21 Aleix Pol wrote:
> > > On Wed, Jun 24, 2015 at 9:51 AM, Martin Gräßlin 
> 
> wrote:
> > > > On Tuesday 23 June 2015 19:35:48 Aleix Pol wrote:
> > > >> On Tue, Jun 23, 2015 at 9:42 AM, Martin Gräßlin 
> > 
> > wrote:
> > > >> > Hi framework-developers and packagers,
> > > >> > 
> > > >> > with two frameworks I'm currently in the need to have something
> > > >> > like
> > > >> > QPA.
> > > >> > I
> > > >> > want to make it possible to provide windowing-system specific
> > > >> > plugins
> > > >> > for
> > > >> > frameworks using a private API. The need arises first of all in
> > > >> > kwindowsystem to support wayland [1]. To implement it we need a
> > > >> > dependency to KWayland, which is currently part of kde-workspace
> > > >> > and
> > > >> > not
> > > >> > yet up to the quality and stability levels needed to make it a
> > > >> > framework.
> > > >> > The second framework where I need such functionality is
> > > >> > kglobalaccel
> > > >> > where kwin needs to take over a large part of the functionality of
> > > >> > the
> > > >> > runtime to make it work on wayland at all.
> > > >> > 
> > > >> > I see the following possibilities to solve the problem:
> > > >> > 1.Make it a private API without any ABI guarantee
> > > >> > 2. Make it a public stable API with ABI guarantee
> > > >> > 3. Make it a private API with so-version changes whenever the ABI
> > > >> > changes
> > > >> > 
> > > >> > Option 1 is closest to what Qt's QPA does, but I think this would
> > > >> > be
> > > >> > a
> > > >> > nightmare for packagers.
> > > >> > 
> > > >> > Option 2 could result in a nightmare for developers especially in
> > > >> > the
> > > >> > plugin infrastructure itself. With releases every month that could
> > > >> > quickly end in classes like KWindowSystemPrivate32 and result in an
> > > >> > unmanageable runtime check system.
> > > >> > 
> > > >> > Personally I think Option 3 is the cleanest solution. Would this be
> > > >> > acceptable for everyone? If yes are there any suggestions for where
> > > >> > to
> > > >> > install headers to, for naming the libraries, etc?
> > > >> > 
> > > >> > Looking forward for your input,
> > > >> > 
> > > >> > Cheers
> > > >> > Martin
> > > >> > 
> > > >> > [1] And obviously also other windowing systems if
> > > >> > distributions/OSes
> > > >> > want
> > > >> > to add support for it.
> > > >> > ___
> > > >> > Kde-frameworks-devel mailing list
> > > >> > Kde-frameworks-devel@kde.org
> > > >> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> > > >> 
> > > >> Hi Martin,
> > > >> We already have something similar with frameworksintegration, maybe
> > > >> it
> > > >> would make sense to integrate what you need there?
> > > > 
> > > > Frameworksintegration doesn't really help as it's still part of
> > > > frameworks
> > > > and thus cannot depend on workspace libraries like kwayland. Also it's
> > > > absolutely no solution for the problem of kglobalaccel (that feature
> > > > must(!) be provided by kwin, there is no other way).
> > > > 
> > > >> The biggest problem I see is that you want it in kde-workspace and
> > > >> it's really complex to use a changing library within 2 different
> > > >> release cycles. It will make things break on one side or another.
> > > >> 
> > > >> What you can do is a stable plugin API and then provide the Wayland
> > > >> plugins from Plasma releases. X11 and others can remain within
> > > >> frameworks.
> > > > 
> > > > That's option 2 from above. As said above I fear that this will be
> > > > problematic due to the very short release cycle of frameworks and will
> > > > create many subclasses just to keep it ABI stable. Of course it's
> > > > doable,
> > > > but well...
> > > 
> > > Well, these aren't completely new abstractions I guess, they're just
> > > not  public interfaces yet. If you start with wayland and X11 backends
> > > (and ideally win/mac too), it should be a solid-enough interface
> > > already so it doesn't need to change on the very next iteration.
> > 
> > This assumes the API is done and is no longer extended. That's not the
> > case, the API got extended at a constant pace over the last few months.
> > Each addition to the API will need an addition to the "private" API in
> > measure of adding a new virtual method.
> 
> There's ways to workaround the virtual method BIC issue, first lame one that
> comes to mind is using meta object system instead of the C++ virtual stuff
> if it's not a hot path, afaik our Binary Compatibility page list a few
> others (virtual_hook).

Another way to achieve the same was implemented by Christoph Cullmann in the 
KatePart/Kate/KTextEditor based on KF5. Essentially, the interfaces are non-
virtual and delegate calls to some actual implementation via 
QMetaObject::invokeMetho

Re: Review Request 124186: [runtime] Install headers and library for the private part

2015-07-01 Thread Aleix Pol Gonzalez 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124186/#review81945
---

Ship it!



src/runtime/CMakeLists.txt (line 26)


No need to call target_include_directories twice.


Makes sense to me, I wonder whether we can make it actual public API, I guess 
we'll see if it's needed in the future anyway.

- Aleix Pol Gonzalez


On June 26, 2015, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124186/
> ---
> 
> (Updated June 26, 2015, 1:51 p.m.)
> 
> 
> Review request for KDE Frameworks and Martin Klapetek.
> 
> 
> Repository: kglobalaccel
> 
> 
> Description
> ---
> 
> We need to make the library and plugin interface available to support
> more platforms. On a Plasma Wayland session it's required that KWin
> becomes KGlobalAccel. KWin is the only process which can filter key
> events and for security reasons KWin will not delegate them to other
> applications.
> 
> This means KWin needs to create KGlobalAccelD before KWin or any other
> process tries to register a global shortcuts triggering kglobalaccel5
> to be started.
> 
> In addition KWin needs to provide it's own plugin which it can interact
> with.
> 
> 
> Diffs
> -
> 
>   src/runtime/CMakeLists.txt 248762f98a6d5b24d4298976bdd1b5a1b4cf1a2c 
> 
> Diff: https://git.reviewboard.kde.org/r/124186/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124220: kwindowsystem: Add a plugin infrastructure for platform specific implementations

2015-07-01 Thread Aleix Pol Gonzalez 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124220/#review81943
---



src/platforms/wayland/CMakeLists.txt (line 15)


KF5 plugins: ${PLUGIN_INSTALL_DIR}/kf5/org.kde.kwindowsystem.platforms/



src/pluginwrapper.cpp (line 44)


kf5/



src/pluginwrapper.cpp (line 65)


`(*it).toString` -> `it->toString`


- Aleix Pol Gonzalez


On July 1, 2015, 9:39 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124220/
> ---
> 
> (Updated July 1, 2015, 9:39 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> A plugin interface is added which allows a platform specific plugin
> to implement an interface. If the plugin does not implement the
> interface, it will fall back to the default implementation. Also
> if no plugin can be resolved it will fall back to the default
> implementation.
> 
> This replaces the existing compile time and runtime selection. In
> order to make this work the KWindowInfoPrivate is changed from a
> templated approach to using pure virtuals just like the other private
> implementations in this library.
> 
> As the platform specific parts are no longer compiled in we cannot
> "just" delegate the KWindowSystem::icon with NETWinInfo overload
> to the xcb implementation. In order to solve this problem the required
> method is added to the private interface with a default implementation
> which does not return anything. If we are not on platform xcb and
> KWindowSystem is compiled with X11 support the plugin for xcb is loaded
> and the call gets delegated to the xcb implementation. This allows e.g.
> KWin to still read icons for Xwayland clients.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
>   src/config-kwindowsystem.h.cmake fa0eec115870be27a17ec7b398e40f0c7506f11b 
>   src/kwindoweffects.cpp fd88e20e1728506f135bcd5ecda3c05754839717 
>   src/kwindoweffects_dummy.cpp 3e24cecb5c7d25883c179b622abdb5ab06587c33 
>   src/kwindoweffects_dummy_p.h PRE-CREATION 
>   src/kwindoweffects_p.h 7c740da952f279a2c5fe689daa5a06c131fa9c9d 
>   src/kwindowinfo.cpp f29828581cdaecb7613c3f62cff72aa1fc33c266 
>   src/kwindowinfo_dummy_p.h PRE-CREATION 
>   src/kwindowinfo_p.h 6727dd1715a13e5bd7793275620c5fa682318f1c 
>   src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
>   src/kwindowsystem_dummy_p.h PRE-CREATION 
>   src/kwindowsystem_p.h 0b5f3e8aeb7b70234c61c59979abd840f349b154 
>   src/kwindowsystemplugininterface.cpp PRE-CREATION 
>   src/kwindowsystemplugininterface_p.h PRE-CREATION 
>   src/platforms/wayland/CMakeLists.txt PRE-CREATION 
>   src/platforms/wayland/plugin.h PRE-CREATION 
>   src/platforms/wayland/plugin.cpp PRE-CREATION 
>   src/platforms/wayland/wayland.json PRE-CREATION 
>   src/platforms/xcb/CMakeLists.txt PRE-CREATION 
>   src/platforms/xcb/kwindoweffects.cpp  
>   src/platforms/xcb/kwindoweffects_x11.h PRE-CREATION 
>   src/platforms/xcb/kwindowinfo.cpp  
>   src/platforms/xcb/kwindowinfo_p_x11.h  
>   src/platforms/xcb/kwindowsystem.cpp  
>   src/platforms/xcb/kwindowsystem_p_x11.h  
>   src/platforms/xcb/plugin.h PRE-CREATION 
>   src/platforms/xcb/plugin.cpp PRE-CREATION 
>   src/platforms/xcb/xcb.json PRE-CREATION 
>   src/pluginwrapper.cpp PRE-CREATION 
>   src/pluginwrapper_p.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124220/diff/
> 
> 
> Testing
> ---
> 
> * unit tests still pass (X11)
> * kwin_wayland still shows icons for Xwayland clients
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124212: kwindowsystem: Change source file layout

2015-07-01 Thread Martin Gräßlin 


> On June 30, 2015, 4:59 p.m., Aleix Pol Gonzalez wrote:
> > In general, I like it.
> > 
> > Maybe now that we're putting the files in separate directories, we can drop 
> > the _mac postfixes?
> 
> Martin Gräßlin wrote:
> I like the idea, but that won't be possible for all cases. E.g. with 
> kkeyserver_foo it's still needed as they also get installed. Also with the 
> private headers it might be tricky (I have another patch on top of that one 
> to change to a plugin architecture and e.g. kwindowsystem_p_x11.h needs to 
> include kwindowsystem_p.h). I'll have a look on it in my on top of this patch 
> for the plugins what can be done.
> 
> Aleix Pol Gonzalez wrote:
> Right. Still, it would be ideal to rename the files only once, so it's 
> easier to read the file's history.
> 
> Martin Gräßlin wrote:
> Ah that was a misunderstanding. Of course in the first commit. I just 
> wanted to check in the commit on top of it how much it makes sense.
> 
> I have it prepared now. At least the .cpp files could be renamed. For the 
> .h files I don't see a solution, if you have ideas please let me know.
> 
> Aleix Pol Gonzalez wrote:
> Maybe we can always include the plugin files using the platform? such as 
> `#include "mac/fu.h`
> 
> Aleix Pol Gonzalez wrote:
> Or even just call it `fu_p.h`, there should be just the one per platform 
> and now they'll be namespaced by the directories.

but the problem is that e.g. fu_p.h needs to include the fu_p.h from the root 
directory. So I fear it doesn't work as we would either recursively includ our 
the wrong file gets included in other parts.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124212/#review81902
---


On July 1, 2015, 8:20 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124212/
> ---
> 
> (Updated July 1, 2015, 8:20 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> In the src directory we introduce a platforms directory with a specific
> * osx
> * wayland
> * windows
> * xcb
> 
> sub directory. The platform specific source and header files are moved
> into those directories.
> 
> This is a preparation step to move the platform specific behavior into
> plugins which get loaded at runtime. Such a change is required to
> support more platforms in future for which kwindowsystem cannot provide
> support directly. An example is proper Wayland support on the Plasma
> platform. It needs to provide its own implementationn which has to
> differ from the generic Wayland implementation.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt dda0af259b292ee5e526bb9166811fc1b376f388 
>   src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
>   src/fixx11h.h  
>   src/kkeyserver_mac.h  
>   src/kkeyserver_mac.cpp  
>   src/kkeyserver_win.h  
>   src/kkeyserver_win.cpp  
>   src/kkeyserver_x11.h  
>   src/kkeyserver_x11.cpp  
>   src/kmanagerselection.h  
>   src/kselectionowner.h  
>   src/kselectionowner.cpp  
>   src/kselectionwatcher.h  
>   src/kselectionwatcher.cpp  
>   src/kwindoweffects_x11.cpp  
>   src/kwindowinfo_mac.cpp  
>   src/kwindowinfo_mac_p.h  
>   src/kwindowinfo_p_x11.h  
>   src/kwindowinfo_win.cpp  
>   src/kwindowinfo_x11.cpp  
>   src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
>   src/kwindowsystem_mac.cpp  
>   src/kwindowsystem_p_wayland.h  
>   src/kwindowsystem_p_x11.h  
>   src/kwindowsystem_wayland.cpp  
>   src/kwindowsystem_win.cpp  
>   src/kwindowsystem_x11.cpp  
>   src/kxerrorhandler.cpp  
>   src/kxerrorhandler_p.h  
>   src/kxmessages.h  
>   src/kxmessages.cpp  
>   src/kxutils.cpp  
>   src/kxutils_p.h  
>   src/netwm.h  
>   src/netwm.cpp  
>   src/netwm_p.h  
>   src/platforms/CMakeLists.txt PRE-CREATION 
>   src/platforms/osx/CMakeLists.txt PRE-CREATION 
>   src/platforms/wayland/CMakeLists.txt PRE-CREATION 
>   src/platforms/windows/CMakeLists.txt PRE-CREATION 
>   src/platforms/xcb/CMakeLists.txt PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124212/diff/
> 
> 
> Testing
> ---
> 
> compiles, installs and autotest pass on platform Linux/xcb
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124212: kwindowsystem: Change source file layout

2015-07-01 Thread Aleix Pol Gonzalez 


> On June 30, 2015, 4:59 p.m., Aleix Pol Gonzalez wrote:
> > In general, I like it.
> > 
> > Maybe now that we're putting the files in separate directories, we can drop 
> > the _mac postfixes?
> 
> Martin Gräßlin wrote:
> I like the idea, but that won't be possible for all cases. E.g. with 
> kkeyserver_foo it's still needed as they also get installed. Also with the 
> private headers it might be tricky (I have another patch on top of that one 
> to change to a plugin architecture and e.g. kwindowsystem_p_x11.h needs to 
> include kwindowsystem_p.h). I'll have a look on it in my on top of this patch 
> for the plugins what can be done.
> 
> Aleix Pol Gonzalez wrote:
> Right. Still, it would be ideal to rename the files only once, so it's 
> easier to read the file's history.
> 
> Martin Gräßlin wrote:
> Ah that was a misunderstanding. Of course in the first commit. I just 
> wanted to check in the commit on top of it how much it makes sense.
> 
> I have it prepared now. At least the .cpp files could be renamed. For the 
> .h files I don't see a solution, if you have ideas please let me know.
> 
> Aleix Pol Gonzalez wrote:
> Maybe we can always include the plugin files using the platform? such as 
> `#include "mac/fu.h`

Or even just call it `fu_p.h`, there should be just the one per platform and 
now they'll be namespaced by the directories.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124212/#review81902
---


On July 1, 2015, 8:20 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124212/
> ---
> 
> (Updated July 1, 2015, 8:20 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> In the src directory we introduce a platforms directory with a specific
> * osx
> * wayland
> * windows
> * xcb
> 
> sub directory. The platform specific source and header files are moved
> into those directories.
> 
> This is a preparation step to move the platform specific behavior into
> plugins which get loaded at runtime. Such a change is required to
> support more platforms in future for which kwindowsystem cannot provide
> support directly. An example is proper Wayland support on the Plasma
> platform. It needs to provide its own implementationn which has to
> differ from the generic Wayland implementation.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt dda0af259b292ee5e526bb9166811fc1b376f388 
>   src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
>   src/fixx11h.h  
>   src/kkeyserver_mac.h  
>   src/kkeyserver_mac.cpp  
>   src/kkeyserver_win.h  
>   src/kkeyserver_win.cpp  
>   src/kkeyserver_x11.h  
>   src/kkeyserver_x11.cpp  
>   src/kmanagerselection.h  
>   src/kselectionowner.h  
>   src/kselectionowner.cpp  
>   src/kselectionwatcher.h  
>   src/kselectionwatcher.cpp  
>   src/kwindoweffects_x11.cpp  
>   src/kwindowinfo_mac.cpp  
>   src/kwindowinfo_mac_p.h  
>   src/kwindowinfo_p_x11.h  
>   src/kwindowinfo_win.cpp  
>   src/kwindowinfo_x11.cpp  
>   src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
>   src/kwindowsystem_mac.cpp  
>   src/kwindowsystem_p_wayland.h  
>   src/kwindowsystem_p_x11.h  
>   src/kwindowsystem_wayland.cpp  
>   src/kwindowsystem_win.cpp  
>   src/kwindowsystem_x11.cpp  
>   src/kxerrorhandler.cpp  
>   src/kxerrorhandler_p.h  
>   src/kxmessages.h  
>   src/kxmessages.cpp  
>   src/kxutils.cpp  
>   src/kxutils_p.h  
>   src/netwm.h  
>   src/netwm.cpp  
>   src/netwm_p.h  
>   src/platforms/CMakeLists.txt PRE-CREATION 
>   src/platforms/osx/CMakeLists.txt PRE-CREATION 
>   src/platforms/wayland/CMakeLists.txt PRE-CREATION 
>   src/platforms/windows/CMakeLists.txt PRE-CREATION 
>   src/platforms/xcb/CMakeLists.txt PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124212/diff/
> 
> 
> Testing
> ---
> 
> compiles, installs and autotest pass on platform Linux/xcb
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124212: kwindowsystem: Change source file layout

2015-07-01 Thread Aleix Pol Gonzalez 


> On June 30, 2015, 4:59 p.m., Aleix Pol Gonzalez wrote:
> > In general, I like it.
> > 
> > Maybe now that we're putting the files in separate directories, we can drop 
> > the _mac postfixes?
> 
> Martin Gräßlin wrote:
> I like the idea, but that won't be possible for all cases. E.g. with 
> kkeyserver_foo it's still needed as they also get installed. Also with the 
> private headers it might be tricky (I have another patch on top of that one 
> to change to a plugin architecture and e.g. kwindowsystem_p_x11.h needs to 
> include kwindowsystem_p.h). I'll have a look on it in my on top of this patch 
> for the plugins what can be done.
> 
> Aleix Pol Gonzalez wrote:
> Right. Still, it would be ideal to rename the files only once, so it's 
> easier to read the file's history.
> 
> Martin Gräßlin wrote:
> Ah that was a misunderstanding. Of course in the first commit. I just 
> wanted to check in the commit on top of it how much it makes sense.
> 
> I have it prepared now. At least the .cpp files could be renamed. For the 
> .h files I don't see a solution, if you have ideas please let me know.

Maybe we can always include the plugin files using the platform? such as 
`#include "mac/fu.h`


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124212/#review81902
---


On July 1, 2015, 8:20 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124212/
> ---
> 
> (Updated July 1, 2015, 8:20 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> In the src directory we introduce a platforms directory with a specific
> * osx
> * wayland
> * windows
> * xcb
> 
> sub directory. The platform specific source and header files are moved
> into those directories.
> 
> This is a preparation step to move the platform specific behavior into
> plugins which get loaded at runtime. Such a change is required to
> support more platforms in future for which kwindowsystem cannot provide
> support directly. An example is proper Wayland support on the Plasma
> platform. It needs to provide its own implementationn which has to
> differ from the generic Wayland implementation.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt dda0af259b292ee5e526bb9166811fc1b376f388 
>   src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
>   src/fixx11h.h  
>   src/kkeyserver_mac.h  
>   src/kkeyserver_mac.cpp  
>   src/kkeyserver_win.h  
>   src/kkeyserver_win.cpp  
>   src/kkeyserver_x11.h  
>   src/kkeyserver_x11.cpp  
>   src/kmanagerselection.h  
>   src/kselectionowner.h  
>   src/kselectionowner.cpp  
>   src/kselectionwatcher.h  
>   src/kselectionwatcher.cpp  
>   src/kwindoweffects_x11.cpp  
>   src/kwindowinfo_mac.cpp  
>   src/kwindowinfo_mac_p.h  
>   src/kwindowinfo_p_x11.h  
>   src/kwindowinfo_win.cpp  
>   src/kwindowinfo_x11.cpp  
>   src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
>   src/kwindowsystem_mac.cpp  
>   src/kwindowsystem_p_wayland.h  
>   src/kwindowsystem_p_x11.h  
>   src/kwindowsystem_wayland.cpp  
>   src/kwindowsystem_win.cpp  
>   src/kwindowsystem_x11.cpp  
>   src/kxerrorhandler.cpp  
>   src/kxerrorhandler_p.h  
>   src/kxmessages.h  
>   src/kxmessages.cpp  
>   src/kxutils.cpp  
>   src/kxutils_p.h  
>   src/netwm.h  
>   src/netwm.cpp  
>   src/netwm_p.h  
>   src/platforms/CMakeLists.txt PRE-CREATION 
>   src/platforms/osx/CMakeLists.txt PRE-CREATION 
>   src/platforms/wayland/CMakeLists.txt PRE-CREATION 
>   src/platforms/windows/CMakeLists.txt PRE-CREATION 
>   src/platforms/xcb/CMakeLists.txt PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124212/diff/
> 
> 
> Testing
> ---
> 
> compiles, installs and autotest pass on platform Linux/xcb
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 124222: kidletime: Introduce plugin infrastructure for platform specific parts

2015-07-01 Thread Martin Gräßlin 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124222/
---

Review request for KDE Frameworks.


Repository: kidletime


Description
---

Instead of having the platform specific implementations hard compiled
in, they are split out into plugins which can get loaded at runtime
depending on the platform we are in.


Diffs
-

  src/CMakeLists.txt 23e5e2914e3a8991d14b664d80ac0d4b60545b40 
  src/abstractsystempoller.h 00202d00b19fbbbd7443e07e411bdedecca230ee 
  src/kidletime.cpp fc4ce77454db52d1bbaf9831c378f22548a237a7 
  src/macpoller.h aab6a3acc16d5fb2b9a3156a142125a15d7e610f 
  src/macpoller.cpp  
  src/org.freedesktop.ScreenSaver.xml  
  src/plugins/CMakeLists.txt PRE-CREATION 
  src/plugins/osx/CMakeLists.txt PRE-CREATION 
  src/plugins/osx/osx.json PRE-CREATION 
  src/plugins/windows/CMakeLists.txt PRE-CREATION 
  src/plugins/windows/windows.json PRE-CREATION 
  src/plugins/xscreensaver/CMakeLists.txt PRE-CREATION 
  src/plugins/xscreensaver/xcb.json PRE-CREATION 
  src/plugins/xsync/CMakeLists.txt PRE-CREATION 
  src/plugins/xsync/fixx11h.h PRE-CREATION 
  src/plugins/xsync/xcb.json PRE-CREATION 
  src/widgetbasedpoller.h fac0a724d32fb79a3c9b7829cba3b17f03bfff32 
  src/windowspoller.h 502ed6dd6c6eaae1b35a14dce66812ebec30677e 
  src/windowspoller.cpp  
  src/xscreensaverbasedpoller.h 363ec521faa39e5b996c9e6767171f72005d11ca 
  src/xscreensaverbasedpoller.cpp  
  src/xsyncbasedpoller.h 8f67cbed38519e15cf5a96b5086da348ec8fabd5 
  src/xsyncbasedpoller.cpp  

Diff: https://git.reviewboard.kde.org/r/124222/diff/


Testing
---

Tried the example app on X11: it correctly loads the xsync plugin. If I modify 
it to be not available it correctly loads the xscreensaver plugin. In both 
cases the interaction is correct.

With --platform wayland no plugin gets loaded (as expected) and the 
functionality is pretty much broken.

Osx and Windows are obviously neither compile nor runtime tested. But I 
adjusted the code to my best knowledge.


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124128: KDirWatch: Only establish a connection to FAM if requested

2015-07-01 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124128/#review81935
---

Ship it!


Ship It!

- David Faure


On June 30, 2015, 2:50 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124128/
> ---
> 
> (Updated June 30, 2015, 2:50 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> KDirWatch by default initializes a connection to both inotify and FAM,
> even if we aren't going to be using either. This is unnecessary and the
> FAM backend has caused it to block for a while on running FAMOpen.
> 
> 
> Diffs
> -
> 
>   src/lib/io/kdirwatch.cpp 246be82 
> 
> Diff: https://git.reviewboard.kde.org/r/124128/diff/
> 
> 
> Testing
> ---
> 
> Unit tests pass
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124186: [runtime] Install headers and library for the private part

2015-07-01 Thread Martin Klapetek 


> On July 1, 2015, 9:50 a.m., Martin Gräßlin wrote:
> > any further opinions on the installation of the "private" headers? 
> > Otherwise I'm going to push tomorrow.

Looks good to me


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124186/#review81927
---


On June 26, 2015, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124186/
> ---
> 
> (Updated June 26, 2015, 1:51 p.m.)
> 
> 
> Review request for KDE Frameworks and Martin Klapetek.
> 
> 
> Repository: kglobalaccel
> 
> 
> Description
> ---
> 
> We need to make the library and plugin interface available to support
> more platforms. On a Plasma Wayland session it's required that KWin
> becomes KGlobalAccel. KWin is the only process which can filter key
> events and for security reasons KWin will not delegate them to other
> applications.
> 
> This means KWin needs to create KGlobalAccelD before KWin or any other
> process tries to register a global shortcuts triggering kglobalaccel5
> to be started.
> 
> In addition KWin needs to provide it's own plugin which it can interact
> with.
> 
> 
> Diffs
> -
> 
>   src/runtime/CMakeLists.txt 248762f98a6d5b24d4298976bdd1b5a1b4cf1a2c 
> 
> Diff: https://git.reviewboard.kde.org/r/124186/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124213: Add standard shortcut for "new tab" action

2015-07-01 Thread Simon Persson 


> On June 30, 2015, 12:07 p.m., Kai Uwe Broulik wrote:
> > +1 for Ctrl+T but not sure about Ctrl+Shift+N, never seen that used for 
> > that purpose, just "incognito mode", or "new window" in applications like 
> > Konsole.

You can see that ctrl+. (period) is the current default in 
kstandardshortcut.cpp. There are still many applications that are not getting 
the default for next/prev tab from KStandardShortcut. Just try switching the 
global setting and go around different applications and see where the new 
shortcuts work... 

I have also never encountered ctrl+shift+N for this action... makes me wonder 
why Qt uses it on KDE (check the documentation on QKeySequence). Actually, 
since this is about standard shortcuts that are likely to be used in many 
applications the risk of assignment conflicts need to be considered. If ctrl+T 
is the only commonly used shortcut then I would think that it's better to only 
provide one default and leave ctrl+shift+N available.


- Simon


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124213/#review81896
---


On June 30, 2015, 9:13 a.m., Simon Persson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124213/
> ---
> 
> (Updated June 30, 2015, 9:13 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> QKeySequence already has AddTab as a standard shortcut, but it was missing in 
> KStandardShortcut. Main problem with this is that users could not configure 
> the shortcut globally. This is of course only a first step, applications 
> would have to be updated to use this also.
> Since QKeySequence uses Ctrl+Shift+N and Ctrl+T for this action when running 
> on KDE, this patch just goes with that as the chosen default.
> Also fixes documentation error for tabNext and tabPrev that I happened to 
> notice.
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.h 5bb07fb 
>   src/gui/kstandardshortcut.cpp 8400737 
> 
> Diff: https://git.reviewboard.kde.org/r/124213/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test suite ok.
> 
> 
> Thanks,
> 
> Simon Persson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 15 - Failure!

2015-07-01 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/15/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 01 Jul 2015 08:24:49 +
Build duration: 9.4 sec

CHANGE SET
Revision b01f782c5916b29a41cf26bfa132b761e0b45065 by scripty: (SVN_SILENT made 
messages (after extraction))
  change: edit src/mimetypes/kde5.xml
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124155: Add KStatusNotifierItem::action(const QString &) to retrieve an action by name

2015-07-01 Thread Martin Klapetek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124155/
---

(Updated July 1, 2015, 8:05 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit f8d29aa9108fa74c1a3666c1774779eb100325a9 by Martin 
Klapetek to branch master.


Bugs: 349513
https://bugs.kde.org/show_bug.cgi?id=349513


Repository: knotifications


Description
---

Apparently this got removed while porting; the code allows to set custom action 
by name and remove too, no reason why it shouldn't allow retrieving it by the 
name.


Diffs
-

  src/kstatusnotifieritem.h 04102d1 
  src/kstatusnotifieritem.cpp 4fd2fda 

Diff: https://git.reviewboard.kde.org/r/124155/diff/


Testing
---


Thanks,

Martin Klapetek

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124186: [runtime] Install headers and library for the private part

2015-07-01 Thread Martin Gräßlin 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124186/#review81927
---


any further opinions on the installation of the "private" headers? Otherwise 
I'm going to push tomorrow.

- Martin Gräßlin


On June 26, 2015, 1:51 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124186/
> ---
> 
> (Updated June 26, 2015, 1:51 p.m.)
> 
> 
> Review request for KDE Frameworks and Martin Klapetek.
> 
> 
> Repository: kglobalaccel
> 
> 
> Description
> ---
> 
> We need to make the library and plugin interface available to support
> more platforms. On a Plasma Wayland session it's required that KWin
> becomes KGlobalAccel. KWin is the only process which can filter key
> events and for security reasons KWin will not delegate them to other
> applications.
> 
> This means KWin needs to create KGlobalAccelD before KWin or any other
> process tries to register a global shortcuts triggering kglobalaccel5
> to be started.
> 
> In addition KWin needs to provide it's own plugin which it can interact
> with.
> 
> 
> Diffs
> -
> 
>   src/runtime/CMakeLists.txt 248762f98a6d5b24d4298976bdd1b5a1b4cf1a2c 
> 
> Diff: https://git.reviewboard.kde.org/r/124186/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 124208: Fallback for componentFriendlyForAction name resolving

2015-07-01 Thread Martin Gräßlin 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124208/
---

(Updated July 1, 2015, 7:49 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Harald Sitter.


Changes
---

Submitted with commit e2cfe1752c5d35779c030dd4c909d172876489ba by Martin 
Gräßlin to branch master.


Repository: kglobalaccel


Description
---

Currently the name is resolved from an undocumented dynamic property
which gets set by KActionCollection (xmlgui). If one uses KGlobalAccel
without using KActionCollection one would have to know the name of
the private property.

To provide a better name the method performs the same fallbacks as
KActionCollection. If the property is not set, it uses either the
application display name or the application name.


Diffs
-

  src/kglobalaccel.cpp 6838bbcfd91d690c067b12db133b6abca5f24203 

Diff: https://git.reviewboard.kde.org/r/124208/diff/


Testing
---

KWin's component now reported properly as "KWin". (KWin is the testcase as it 
doesn't use xmlgui.)


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 124220: kwindowsystem: Add a plugin infrastructure for platform specific implementations

2015-07-01 Thread Martin Gräßlin 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124220/
---

Review request for KDE Frameworks.


Repository: kwindowsystem


Description
---

A plugin interface is added which allows a platform specific plugin
to implement an interface. If the plugin does not implement the
interface, it will fall back to the default implementation. Also
if no plugin can be resolved it will fall back to the default
implementation.

This replaces the existing compile time and runtime selection. In
order to make this work the KWindowInfoPrivate is changed from a
templated approach to using pure virtuals just like the other private
implementations in this library.

As the platform specific parts are no longer compiled in we cannot
"just" delegate the KWindowSystem::icon with NETWinInfo overload
to the xcb implementation. In order to solve this problem the required
method is added to the private interface with a default implementation
which does not return anything. If we are not on platform xcb and
KWindowSystem is compiled with X11 support the plugin for xcb is loaded
and the call gets delegated to the xcb implementation. This allows e.g.
KWin to still read icons for Xwayland clients.


Diffs
-

  src/CMakeLists.txt ff2ce392ecd7969eb94543528c7a670ea0fcd870 
  src/config-kwindowsystem.h.cmake fa0eec115870be27a17ec7b398e40f0c7506f11b 
  src/kwindoweffects.cpp fd88e20e1728506f135bcd5ecda3c05754839717 
  src/kwindoweffects_dummy.cpp 3e24cecb5c7d25883c179b622abdb5ab06587c33 
  src/kwindoweffects_dummy_p.h PRE-CREATION 
  src/kwindoweffects_p.h 7c740da952f279a2c5fe689daa5a06c131fa9c9d 
  src/kwindowinfo.cpp f29828581cdaecb7613c3f62cff72aa1fc33c266 
  src/kwindowinfo_dummy_p.h PRE-CREATION 
  src/kwindowinfo_p.h 6727dd1715a13e5bd7793275620c5fa682318f1c 
  src/kwindowsystem.cpp 789132e1b4883dd54218d29af9710dedfe6218e1 
  src/kwindowsystem_dummy_p.h PRE-CREATION 
  src/kwindowsystem_p.h 0b5f3e8aeb7b70234c61c59979abd840f349b154 
  src/kwindowsystemplugininterface.cpp PRE-CREATION 
  src/kwindowsystemplugininterface_p.h PRE-CREATION 
  src/platforms/wayland/CMakeLists.txt PRE-CREATION 
  src/platforms/wayland/plugin.h PRE-CREATION 
  src/platforms/wayland/plugin.cpp PRE-CREATION 
  src/platforms/wayland/wayland.json PRE-CREATION 
  src/platforms/xcb/CMakeLists.txt PRE-CREATION 
  src/platforms/xcb/kwindoweffects.cpp  
  src/platforms/xcb/kwindoweffects_x11.h PRE-CREATION 
  src/platforms/xcb/kwindowinfo.cpp  
  src/platforms/xcb/kwindowinfo_p_x11.h  
  src/platforms/xcb/kwindowsystem.cpp  
  src/platforms/xcb/kwindowsystem_p_x11.h  
  src/platforms/xcb/plugin.h PRE-CREATION 
  src/platforms/xcb/plugin.cpp PRE-CREATION 
  src/platforms/xcb/xcb.json PRE-CREATION 
  src/pluginwrapper.cpp PRE-CREATION 
  src/pluginwrapper_p.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/124220/diff/


Testing
---

* unit tests still pass (X11)
* kwin_wayland still shows icons for Xwayland clients


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel