Re: VDG application design sprint?

[Andy B]

I am very interested! Count me in!

Thank you,

Andy


On January 23, 2023 at 7:17:25 PM, Nate Graham (n...@kde.org) wrote:

Very interested!

Ever since the GNOME folks created Libadwaita, I feel like their
3rd-party app ecosystem has really taken off, and it seems like
something they put a lot of planning and foresight into making happen.
In KDE land we have a lot of 1st-party apps but not as much on the
3rd-party side, and I'd like for us to have an equally compelling story
there. I think the design, HIG, and UX perspectives--both user and
developer--are key to making this happen, and a VDG sprint would be the
perfect place to discuss those topics.

Nate



On 1/23/23 16:43, Nicolas Fella wrote:
> Hi,
>
> I think it would make sense for us to have a VDG sprint of sorts in the
> near-ish future. This would allow to discuss some larger design topics
> and set a vision for the longer-term future. I believe this is important
> for us to be able to work together effectively.
>
> I'd suggest to focus on application design topics, like layout,
> structure, and arrangement of apps, and less on things like Plasma and
> styles/themes. I'd also suggest to approach this more from a design/UX
> PoV and don't let us be driven by implementation details. But these are
> just my suggestions that are subject to debate.
>
> Time/place/modality is all to be discussed, I'm mainly writing this to
> gauge interest, so if you are interested let me know.
>
> Cheers
>
> Nicolas
>

Re: VDG application design sprint?

[Nate Graham]

Very interested!

Ever since the GNOME folks created Libadwaita, I feel like their 
3rd-party app ecosystem has really taken off, and it seems like 
something they put a lot of planning and foresight into making happen. 
In KDE land we have a lot of 1st-party apps but not as much on the 
3rd-party side, and I'd like for us to have an equally compelling story 
there. I think the design, HIG, and UX perspectives--both user and 
developer--are key to making this happen, and a VDG sprint would be the 
perfect place to discuss those topics.


Nate



On 1/23/23 16:43, Nicolas Fella wrote:

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.

Cheers

Nicolas

VDG application design sprint?

[Nicolas Fella]

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.

Cheers

Nicolas

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 19.01.23 um 13:44 schrieb Nicolas Fella:

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.


Hi,

as an update to this:

We are currently progressing nicely with this, but are not done yet.

Some amount of instability/breakage is expected, so *I do not recommend*
to try and use frameworks master until things have settled down a bit.

Doing so prematurely would only cause extra work for everyone involved.

I will announce once things have settled enough to start working on more
things.

Cheers

Nicolas

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 19.01.23 um 13:44 schrieb Nicolas Fella:

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.


Hi,

as an update to this:

We are currently progressing nicely with this, but are not done yet.

Some amount of instability/breakage is expected, so *I do not recommend*
to try and use frameworks master until things have settled down a bit.

Doing so prematurely would only cause extra work for everyone involved.

I will announce once things have settled enough to start working on more
things.

Cheers

Nicolas

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 19.01.23 um 13:44 schrieb Nicolas Fella:

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.


Hi,

as an update to this:

We are currently progressing nicely with this, but are not done yet.

Some amount of instability/breakage is expected, so *I do not recommend*
to try and use frameworks master until things have settled down a bit.

Doing so prematurely would only cause extra work for everyone involved.

I will announce once things have settled enough to start working on more
things.

Cheers

Nicolas

Re: kquickcharts

[Nicolas Fella]

I'd recommend you don't try to build frameworks master for the moment.
Things are still in flux and some breakage is expected.

I'll announce once things have settled down a bit

Am 23.01.23 um 17:06 schrieb Jonathan Riddell:

*What might need doing for me to compile kquickcharts master branch? *
*https://build.neon.kde.org/job/jammy_unstable_kf6_kquickcharts_bin_amd64/25/console
15:51:32* [ 29%] Building CXX object 
src/CMakeFiles/QuickChartsStatic.dir/datasource/ModelHistorySource.cpp.o
*15:51:35* In file included from /usr/include/c++/11/bits/stl_algobase.h:71,
*15:51:35*   from /usr/include/c++/11/array:40,
*15:51:35*   from /usr/include/c++/11/tuple:39,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qtypeinfo.h:9,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qglobal.h:1397,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qcontainertools_impl.h:14,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qhash.h:8,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qabstractitemmodel.h:8,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/QAbstractItemModel:1,
*15:51:35*   from 
/workspace/build/src/datasource/ModelSource.h:11,
*15:51:35*   from 
/workspace/build/src/datasource/ModelHistorySource.h:11,
*15:51:35*   from 
/workspace/build/src/datasource/ModelHistorySource.cpp:8:
*15:51:35* /usr/include/c++/11/bits/predefined_ops.h: In instantiation of ‘constexpr bool 
__gnu_cxx::__ops::_Iter_less_iter::operator()(_Iterator1, _Iterator2) const [with 
_Iterator1 = QList::const_iterator; _Iterator2 = 
QList::const_iterator]’:
*15:51:35* /usr/include/c++/11/bits/stl_algo.h:5624:12:   required from ‘constexpr 
_ForwardIterator std::__min_element(_ForwardIterator, _ForwardIterator, _Compare) 
[with _ForwardIterator = QList::const_iterator; _Compare = 
__gnu_cxx::__ops::_Iter_less_iter]’
*15:51:35* /usr/include/c++/11/bits/stl_algo.h:5648:43:   required from ‘constexpr 
_FIter std::min_element(_FIter, _FIter) [with _FIter = 
QList::const_iterator]’
*15:51:35* /workspace/build/src/datasource/ModelHistorySource.cpp:53:29:   
required from here
*15:51:35* /usr/include/c++/11/bits/predefined_ops.h:45:23: error: no match for 
‘operator<’ (operand types are ‘const QVariant’ and ‘const QVariant’)
*15:51:35* 45 |   { return *__it1 < *__it2; }
*15:51:35*|~~~^~~~

kquickcharts

[Jonathan Riddell]

*What might need doing for me to compile kquickcharts master branch?*




*https://build.neon.kde.org/job/jammy_unstable_kf6_kquickcharts_bin_amd64/25/console
15:51:32*
[ 29%] Building CXX object
src/CMakeFiles/QuickChartsStatic.dir/datasource/ModelHistorySource.cpp.o*15:51:35*
In file included from
/usr/include/c++/11/bits/stl_algobase.h:71,*15:51:35*
from /usr/include/c++/11/array:40,*15:51:35*  from
/usr/include/c++/11/tuple:39,*15:51:35*  from
/usr/include/x86_64-linux-gnu/qt6/QtCore/qtypeinfo.h:9,*15:51:35*
from
/usr/include/x86_64-linux-gnu/qt6/QtCore/qglobal.h:1397,*15:51:35*
 from
/usr/include/x86_64-linux-gnu/qt6/QtCore/qcontainertools_impl.h:14,*15:51:35*
 from
/usr/include/x86_64-linux-gnu/qt6/QtCore/qhash.h:8,*15:51:35*
from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qabstractitemmodel.h:8,*15:51:35*
 from
/usr/include/x86_64-linux-gnu/qt6/QtCore/QAbstractItemModel:1,*15:51:35*
 from
/workspace/build/src/datasource/ModelSource.h:11,*15:51:35*
  from /workspace/build/src/datasource/ModelHistorySource.h:11,*15:51:35*
 from
/workspace/build/src/datasource/ModelHistorySource.cpp:8:*15:51:35*
/usr/include/c++/11/bits/predefined_ops.h: In instantiation of
‘constexpr bool
__gnu_cxx::__ops::_Iter_less_iter::operator()(_Iterator1, _Iterator2)
const [with _Iterator1 = QList::const_iterator; _Iterator2 =
QList::const_iterator]’:*15:51:35*
/usr/include/c++/11/bits/stl_algo.h:5624:12:   required from
‘constexpr _ForwardIterator std::__min_element(_ForwardIterator,
_ForwardIterator, _Compare) [with _ForwardIterator =
QList::const_iterator; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]’*15:51:35*
/usr/include/c++/11/bits/stl_algo.h:5648:43:   required from
‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter =
QList::const_iterator]’*15:51:35*
/workspace/build/src/datasource/ModelHistorySource.cpp:53:29:
required from here*15:51:35*
/usr/include/c++/11/bits/predefined_ops.h:45:23: error: no match for
‘operator<’ (operand types are ‘const QVariant’ and ‘const
QVariant’)*15:51:35*45 |   { return *__it1 < *__it2;
}*15:51:35*   |~~~^~~~

kitemmodels kf6 build failure

[Jonathan Riddell]

Building kitemmodels I get this failure, where might it have gone?

*15:27:15* [ 86%] Building CXX object
src/qml/CMakeFiles/itemmodelsplugin.dir/plugin.cpp.o*15:27:15* In file
included from /workspace/build/src/qml/plugin.cpp:17:*15:27:15*
/workspace/build/src/qml/kconcatenaterowsproxymodel_qml.h:11:10: fatal
error: KConcatenateRowsProxyModel: No such file or directory*15:27:15*
   11 | #include *15:27:15*   |
  ^~~~