D13238: [tests] Add pointer constraints test

2018-06-08 Thread Roman Gilg
romangg abandoned this revision.
romangg added a comment.


  I decided to add the test to KWin instead with: D13439 

  
  Thanks to Vlad for review comments. I incorporated them in the new patch for 
KWin.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D13238

To: romangg, #plasma, #frameworks
Cc: zzag, kde-frameworks-devel, ragreen, Pitel, schernikov, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
eliasp, sebas, apol, mart, hein


D12820: Add KWayland virtual desktop protocol

2018-06-08 Thread David Edmundson
davidedmundson added inline comments.

INLINE COMMENTS

> plasma-virtual-desktop.xml:56
> +
> +
> +

Code comment:

This interface doesn't have a destructor.

The server can invalidate it on it's end, but ultimately up to the client to 
destroy the reference which they can't do.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D12820

To: mart, #kwin, #plasma, graesslin, hein
Cc: davidedmundson, zzag, bshah, romangg, kde-frameworks-devel, michaelh, 
ngraham, bruns


D12820: Add KWayland virtual desktop protocol

2018-06-08 Thread David Edmundson
davidedmundson added a comment.


  Don't feel the need to change the code unless you and whoever else agree.
  I'm not forcing anything, just commenting on my preference.
  
  But yeah, that would be my proposal.
  
  It'd mean reverting work here, but porting the existing plasma pager/effects 
would go back to being a lot easier.
  I don't even know how I'd go about porting it with this.
  
  > Would there be some protocol to reorder desktops or would be just a detail 
internal in kwin?
  
  I think you'd need to communicate the same order with all clients. 
  That could be just replacing 
virtual_desktop_added/virtual_desktop_removed/done  with 
set_virtual_desktops(wl_array);or something else.
  
  > whith this, would still be possible to allow maybe in the future desktops 
per-output whicj Martin was talking about?
  
  WRT positioning, probably. You'd need new API, but you wouldn't have 
redundant API.
  WRT which one is active, this code wouldn't cover that as-is.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D12820

To: mart, #kwin, #plasma, graesslin, hein
Cc: davidedmundson, zzag, bshah, romangg, kde-frameworks-devel, michaelh, 
ngraham, bruns


D12820: Add KWayland virtual desktop protocol

2018-06-08 Thread Marco Martin
mart added a comment.


  In D12820#275739 , @davidedmundson 
wrote:
  
  > In the current (even on X state) I can represent 4 virtual desktops in 1 
2x2 grid on the pager so it fits best, yet 4x1 along the edges of the cube, and 
it wouldn't be unfeasible to display them 1x4 in an activity manager style 
switcher.
  >
  > What I think would work best is a shared ordered-list, but the visual 
representation of that ordered list is entirely up to the view.
  >
  > Kwin still needs to turn that into a grid in some places for keyboard nav 
and the slide effect, but that's just the case of a single int config value.
  
  
  so...
  Remove all layout position and siblings, and just pay attention 
  plasmaVirtualDesktops() on server, and
  desktops() on the client always have the same order.
  Would there be some protocol to reorder desktops or would be just a detail 
internal in kwin?
  
  wether they are on a line, on a cube, on a 3 rows grid, then would just be a 
config value setting shared between kwin and the pager, not passing trough 
wayland in any way.
  
  whith this, would still be possible to allow maybe in the future desktops 
per-output whicj Martin was talking about?

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D12820

To: mart, #kwin, #plasma, graesslin, hein
Cc: davidedmundson, zzag, bshah, romangg, kde-frameworks-devel, michaelh, 
ngraham, bruns


D13406: In cmake macro file use CMAKE_CURRENT_LIST_DIR consequently instead of mixed use with KF5I18n_DIR

2018-06-08 Thread Christophe Giboudeaux
cgiboudeaux added a comment.


  In D13406#275765 , @cgiboudeaux 
wrote:
  
  > In D13406#275755 , @habacker 
wrote:
  >
  > > Fixed autotests
  >
  >
  > Still -1, the code is now more complicated just for a cosmetic change in a 
build system file. Are you trying to fix anything ?
  
  
  s/not/now

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D13406

To: habacker, ilic
Cc: cgiboudeaux, kde-frameworks-devel, michaelh, ngraham, bruns


D13406: In cmake macro file use CMAKE_CURRENT_LIST_DIR consequently instead of mixed use with KF5I18n_DIR

2018-06-08 Thread Christophe Giboudeaux
cgiboudeaux added a comment.


  In D13406#275755 , @habacker wrote:
  
  > Fixed autotests
  
  
  Still -1, the code is not more complicated just for a cosmetic change in a 
build system file. Are you trying to fix anything ?

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D13406

To: habacker, ilic
Cc: cgiboudeaux, kde-frameworks-devel, michaelh, ngraham, bruns


D13406: In cmake macro file use CMAKE_CURRENT_LIST_DIR consequently instead of mixed use with KF5I18n_DIR

2018-06-08 Thread Ralf Habacker
habacker updated this revision to Diff 35821.
habacker added a comment.


  Fixed autotests

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13406?vs=35756=35821

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13406

AFFECTED FILES
  CMakeLists.txt
  cmake/KF5I18NMacros.cmake.in

To: habacker, ilic
Cc: cgiboudeaux, kde-frameworks-devel, michaelh, ngraham, bruns


D13406: In cmake macro file use CMAKE_CURRENT_LIST_DIR consequently instead of mixed use with KF5I18n_DIR

2018-06-08 Thread Ralf Habacker
habacker added a comment.


  In D13406#275375 , @cgiboudeaux 
wrote:
  
  > -1, this change would break the autotests.
  
  
  Hmmh, https://cmake.org/cmake/help/v3.0/variable/CMAKE_CURRENT_LIST_DIR.html 
mentions  "... that As CMake processes the listfiles in your project this 
variable will always be set to the directory where the listfile which is 
currently being processed (CMAKE_CURRENT_LIST_FILE) is located." so it should 
work. Adding `message(" ${CMAKE_CURRENT_LIST_DIR"}` to KF5I18nMacros.cmake 
returns `++ /autotests/cmake`, which looks correct. 
  The failure happens on running `make test`, which inside runs `make install` 
in the build dir of the configured ki18_install autotests (located in 
`/autotests/ki18n_install`), where `-P 
${CMAKE_CURRENT_LIST_DIR}/build-tsfiles.cmake` is expanded to  `-P 
/cmake/build-pofiles.cmake` - Seems to be a cmake bug

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D13406

To: habacker, ilic
Cc: cgiboudeaux, kde-frameworks-devel, michaelh, ngraham, bruns


D12820: Add KWayland virtual desktop protocol

2018-06-08 Thread David Edmundson
davidedmundson added a comment.


  General rule of thumb for any data storage for me is to never have a possible 
corruptable state. 
  The current protocol which has the position specified inside the Virtual 
Desktop object itself, so you can have two in the same place and you can't swap 
the position of two in an atomic move.  
  This sibling part makes that worse.
  
  > I would prefer to not have any layout in the protocol. Setting a layout 
makes it impossible to have different virtual desktop per output.
  
  Completely agree, but for completely different reasons.
  
  Layout is not a property of the virtual desktop itself but a property of the 
relevant view.
  
  In the current (even on X state) I can represent 4 virtual desktops in 1 2x2 
grid on the pager so it fits best, yet 4x1 along the edges of the cube, and it 
wouldn't be unfeasible to display them 1x4 in an activity manager style 
switcher.
  
  What I think would work best is a shared ordered-list, but the visual 
representation of that ordered list is entirely up to the view.
  
  Kwin still needs to turn that into a grid in some places for keyboard nav and 
the slide effect, but that's just the case of a single int config value.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D12820

To: mart, #kwin, #plasma, graesslin, hein
Cc: davidedmundson, zzag, bshah, romangg, kde-frameworks-devel, michaelh, 
ngraham, bruns