Version Error while building KDE frameworks and Qt5

[Bhavesh Patidar]

Hello Everyone.
For building Elisa from kdesrc-build, I am building the dependencies from
here:
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Install_the_dependencies


But this is installing version 5.9.5 for Qt and version 5.44 for all kde
frameworks. Elisa requires versions 5.10.0 and 5.45 respectively. How can I
install these versions? I would be really grateful if someone can help me
out since I have spent a lot of time building the dependencies but its
resulting in errors while building elisa.




-- 
Regards
Bhavesh

D13238: [tests] Add pointer constraints test

[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

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Sat, Jun 9, 2018 at 9:06 AM, Scott Harvey  wrote:
> Did anyone check how much space has been freed up in the Bugzilla database?

The closure of bugs doesn't archive them from the database.
Once entered into the system they're in there permanently.

Cheers,
Ben


> On Jun 8, 2018, 3:39 PM -0500, Nate Graham , wrote:
>
> This work is done; all the bugs and feature requests in the plasma4
> product have been closed. Hope all of your inboxes survived the onslaught!
>
> Nate
>
>
>
> On 02/21/2018 07:21 AM, Nate Graham wrote:
>
> I have also cleaned up the bug triaging page:
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
>
> It's still a bit long, so any further editing to condense it a bit would
> be welcome.
>
> Nate
>
>
>
> On 02/21/2018 07:16 AM, Nate Graham wrote:
>
>
>
> On 02/21/2018 06:26 AM, Nate Graham wrote:
>
>
>
> On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:
>
> On Wed, Feb 21, 2018 at 9:34 AM, pointedstick
>  wrote:
> I have editbugs power on bugs.kde.org, but cannot edit the
> Importance field
> or mark a bug as CLOSED on bugstest.kde.org. I appear to have the
> new normal
> permissions.
>
>
> Thanks for confirming my testing Nate.
>
> I've now gone ahead and rolled this out on bugs.kde.org.
> Everyone who had editbugs rights already (all 3,221 of us) have been
> made members of the new (fully empowered) contributors group.
>
> If someone would like to announce this via a blog post please feel
> free to do so as I likely won't have time in the next few days to do
> so.
>
>
> Fantastic! I'll do that.
>
>
> Done:
> https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/
>
>
> Nate
>
>
>

Re: Closing old Plasma 4 bugs

[Nate Graham]

This work is done; all the bugs and feature requests in the plasma4 
product have been closed. Hope all of your inboxes survived the onslaught!


Nate



On 02/21/2018 07:21 AM, Nate Graham wrote:
I have also cleaned up the bug triaging page: 
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging


It's still a bit long, so any further editing to condense it a bit would 
be welcome.


Nate



On 02/21/2018 07:16 AM, Nate Graham wrote:



On 02/21/2018 06:26 AM, Nate Graham wrote:




On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:

On Wed, Feb 21, 2018 at 9:34 AM, pointedstick 
 wrote:
I have editbugs power on bugs.kde.org, but cannot edit the 
Importance field
or mark a bug as CLOSED on bugstest.kde.org. I appear to have the 
new normal

permissions.


Thanks for confirming my testing Nate.

I've now gone ahead and rolled this out on bugs.kde.org.
Everyone who had editbugs rights already (all 3,221 of us) have been
made members of the new (fully empowered) contributors group.

If someone would like to announce this via a blog post please feel
free to do so as I likely won't have time in the next few days to do
so.


Fantastic! I'll do that.


Done: 
https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/ 



Nate

D12820: Add KWayland virtual desktop protocol

[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

[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

[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

[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

[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

[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

[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

[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