Merging a 2nd style (non xml) for KConfigXT?

[Tomaz Canabrava]

Hello All,

This is my 2nd attempt on this, but hear me out. I'm using for ~5 years 
a configuration schema that is really different from KConfigXT XML 
syntax because I sincerely don't like to hand code XML specially when 
it's intermixed with C++ within the *same* file, and I feel that all the 
different possible ways to configure KConfigXT is broken by design. What 
I'm proposing here is *not* to replace KConfigXT xml schema, I conceive 
that it's a lost cause on my side. I lost.


What I'm proposing is to add my chema as a *variant* for a smaller, 
stricter, easier to write and to read, syntax.  it will *not* cover all 
the cases from KConfigXT (no way to define multiple configuration files, 
no way to define static vs non static initialization). but it will cover 
a smaller, to medium configuration complexity.


it already offers some things that KConfigXT Lacks. too. See this small 
example:


-- file somesmallpreferences.conf

#include 

#include 

namespace Prefs {

SomePreferences {

    Gui{

        QColor bgColor = QColor(233,233,233);

    }

    User {

        QString name = QStringLiteral("Adamastor");

    }

}

}

-

This will generate two new files, `somesmallpreferences.h / cpp with the 
following  classes: SomePreferences, Gui, User.


this generates a property with signal and slots for everything that is 
considered to be a variable, the constructor of SomePreferences loads 
everything, the destructor of SomePreferences saves everything.


Things that KConfigXT XML lacks:

* Access to the default value of a setting (KConfigXT allows me to 
define one, but I can't use it on a if in the codebase, there's no way 
to query it back)


* Multi paradigm configuration targets (I can deploy for QSettings or 
KConfig)


* Compartimentalized acessors: bgColor() exists inside of the Gui class, 
not on SomePreferences, so it's easier to organize.


For a real example, check `invent.kde.org/sdk/codevis` as this is what 
I'm using there.


I want to merge this on KConfigXT to be able to drop my github based 
project, and to see if more projects could adopt such a scheme.


Best,

Tomaz

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Update, now it works on windows and FreeBSD.
<3

On Tue, 22 Aug 2023 at 21:21 Tomaz Canabrava  wrote:

> Update, it now builds on qt6 and qt5.
> Struggling a bit with craft for windows.
>
>
> On Fri, 18 Aug 2023 at 21:22 Ben Cooksley  wrote:
>
>> On Sat, Aug 19, 2023 at 3:37 AM Tomaz Canabrava 
>> wrote:
>>
>>> (some help / I need to set the default branch to master, from main,
>>> because the tooling doesn't accept the later, I don't think I have the
>>> permission to do that).
>>>
>>
>> That has been done now.
>>
>> Cheers,
>> Ben
>>
>>
>>>
>>> On Fri, Aug 18, 2023 at 5:10 PM Tomaz Canabrava 
>>> wrote:
>>>
>>>> Small update that the CI is now fully passing.
>>>>
>>>> On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava 
>>>> wrote:
>>>>
>>>>> Carl, Sysadmins:
>>>>>
>>>>> The current error on the KDE ci is this:
>>>>>
>>>>> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You
>>>>> can change this by defining CT_CLANG_HEADERS_DIR
>>>>> CMake Error at CMakeLists.txt:87 (message):
>>>>> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
>>>>> -- Configuring incomplete, errors occurred!
>>>>>
>>>>> (to which I understand that carl said there's an error with Clang6.
>>>>> This is not an error - it basically says that we are unable to find
>>>>> `stddef.h` on the  path `
>>>>> ${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>>>>>
>>>>> This is needed for the tool to run properly, but not compile, so I
>>>>> removed the FATAL from the message.
>>>>>
>>>>> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan 
>>>>>> wrote:
>>>>>>
>>>>>>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>>>>>>> > Hello Fellow KDE Devs,
>>>>>>> >
>>>>>>> > I'm here, formally asking for a review of the Codevis project, to
>>>>>>> move
>>>>>>> > forward and make it a part of kdesdk.
>>>>>>>
>>>>>>> Very cool project, I was amazed by the presentation of it from
>>>>>>> tarcisio at
>>>>>>> Akademy.
>>>>>>>
>>>>>>> > Currently we are using parts of KWdigetsAddons as a submodule
>>>>>>> > Most things that are related to buildsystems will be moved to
>>>>>>> craft /
>>>>>>> > kdesrc-build as soon as possible, right now we rely in conan for
>>>>>>> windows
>>>>>>> > and mac, plus a hand-written build script that downloads and
>>>>>>> builds llvm
>>>>>>> > for those platforms.
>>>>>>> >
>>>>>>> > Things that I know that are out of KDE Accordance:
>>>>>>> > - Translation System (uses Qt's tr() system)
>>>>>>>
>>>>>>> This isn't an issue and we have other KDE projects using the tr()
>>>>>>> system. But
>>>>>>> if you want to port to ki18n, it's best to do it now since you don't
>>>>>>> seems to
>>>>>>> have any translations yet.
>>>>>>>
>>>>>>> > - Settings System (it uses my own configuration parser that
>>>>>>> resembles QML)
>>>>>>>
>>>>>>> Yeah probably best to use kconfigxt or make your configuration
>>>>>>> parser part of
>>>>>>> kconfigxt next gen ;)
>>>>>>>
>>>>>>> > - Folder naming specification (follows the lakosian naming
>>>>>>> specification)
>>>>>>>
>>>>>>> I don't think we have any folder (and file) naming specification in
>>>>>>> kde, or at
>>>>>>> least if we have one, it varies a lot between projects.
>>>>>>>
>>>>>>> > - CI used is based on Gitlab, but fails on KDE
>>>>>>>
>>>>>>> When trying to build it on my laptop it failed, due to the
>>>>>>> requirement of
>>>>>>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>>>>>>
>>>>>>
>>>>>> Carl,
>>>>>>
>>>>>> There’s no requirement for clang16 (I build with 15, tarcisio builds
>>>>>> with 14, the previous ci had 13, I believe)
>>>>>>
>>>>>> Mind if you share the build logs?
>>>>>>
>>>>>> Best
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> > The current repository of Codevis is:
>>>>>>> > https://invent.kde.org/tcanabrava/codevis
>>>>>>> >
>>>>>>> > The KDE developers on this project are me, tarcisio fischer (that
>>>>>>> presented
>>>>>>> > Codevis on Akademy), and Richard Dale.
>>>>>>> >
>>>>>>> > Best regards,
>>>>>>> > Tomaz
>>>>>>>
>>>>>>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Update, it now builds on qt6 and qt5.
Struggling a bit with craft for windows.


On Fri, 18 Aug 2023 at 21:22 Ben Cooksley  wrote:

> On Sat, Aug 19, 2023 at 3:37 AM Tomaz Canabrava 
> wrote:
>
>> (some help / I need to set the default branch to master, from main,
>> because the tooling doesn't accept the later, I don't think I have the
>> permission to do that).
>>
>
> That has been done now.
>
> Cheers,
> Ben
>
>
>>
>> On Fri, Aug 18, 2023 at 5:10 PM Tomaz Canabrava 
>> wrote:
>>
>>> Small update that the CI is now fully passing.
>>>
>>> On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava 
>>> wrote:
>>>
>>>> Carl, Sysadmins:
>>>>
>>>> The current error on the KDE ci is this:
>>>>
>>>> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You
>>>> can change this by defining CT_CLANG_HEADERS_DIR
>>>> CMake Error at CMakeLists.txt:87 (message):
>>>> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
>>>> -- Configuring incomplete, errors occurred!
>>>>
>>>> (to which I understand that carl said there's an error with Clang6.
>>>> This is not an error - it basically says that we are unable to find
>>>> `stddef.h` on the  path `
>>>> ${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>>>>
>>>> This is needed for the tool to run properly, but not compile, so I
>>>> removed the FATAL from the message.
>>>>
>>>> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan 
>>>>> wrote:
>>>>>
>>>>>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>>>>>> > Hello Fellow KDE Devs,
>>>>>> >
>>>>>> > I'm here, formally asking for a review of the Codevis project, to
>>>>>> move
>>>>>> > forward and make it a part of kdesdk.
>>>>>>
>>>>>> Very cool project, I was amazed by the presentation of it from
>>>>>> tarcisio at
>>>>>> Akademy.
>>>>>>
>>>>>> > Currently we are using parts of KWdigetsAddons as a submodule
>>>>>> > Most things that are related to buildsystems will be moved to craft
>>>>>> /
>>>>>> > kdesrc-build as soon as possible, right now we rely in conan for
>>>>>> windows
>>>>>> > and mac, plus a hand-written build script that downloads and builds
>>>>>> llvm
>>>>>> > for those platforms.
>>>>>> >
>>>>>> > Things that I know that are out of KDE Accordance:
>>>>>> > - Translation System (uses Qt's tr() system)
>>>>>>
>>>>>> This isn't an issue and we have other KDE projects using the tr()
>>>>>> system. But
>>>>>> if you want to port to ki18n, it's best to do it now since you don't
>>>>>> seems to
>>>>>> have any translations yet.
>>>>>>
>>>>>> > - Settings System (it uses my own configuration parser that
>>>>>> resembles QML)
>>>>>>
>>>>>> Yeah probably best to use kconfigxt or make your configuration parser
>>>>>> part of
>>>>>> kconfigxt next gen ;)
>>>>>>
>>>>>> > - Folder naming specification (follows the lakosian naming
>>>>>> specification)
>>>>>>
>>>>>> I don't think we have any folder (and file) naming specification in
>>>>>> kde, or at
>>>>>> least if we have one, it varies a lot between projects.
>>>>>>
>>>>>> > - CI used is based on Gitlab, but fails on KDE
>>>>>>
>>>>>> When trying to build it on my laptop it failed, due to the
>>>>>> requirement of
>>>>>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>>>>>
>>>>>
>>>>> Carl,
>>>>>
>>>>> There’s no requirement for clang16 (I build with 15, tarcisio builds
>>>>> with 14, the previous ci had 13, I believe)
>>>>>
>>>>> Mind if you share the build logs?
>>>>>
>>>>> Best
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> > The current repository of Codevis is:
>>>>>> > https://invent.kde.org/tcanabrava/codevis
>>>>>> >
>>>>>> > The KDE developers on this project are me, tarcisio fischer (that
>>>>>> presented
>>>>>> > Codevis on Akademy), and Richard Dale.
>>>>>> >
>>>>>> > Best regards,
>>>>>> > Tomaz
>>>>>>
>>>>>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

(some help / I need to set the default branch to master, from main, because
the tooling doesn't accept the later, I don't think I have the permission
to do that).

On Fri, Aug 18, 2023 at 5:10 PM Tomaz Canabrava  wrote:

> Small update that the CI is now fully passing.
>
> On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava 
> wrote:
>
>> Carl, Sysadmins:
>>
>> The current error on the KDE ci is this:
>>
>> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You
>> can change this by defining CT_CLANG_HEADERS_DIR
>> CMake Error at CMakeLists.txt:87 (message):
>> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
>> -- Configuring incomplete, errors occurred!
>>
>> (to which I understand that carl said there's an error with Clang6. This
>> is not an error - it basically says that we are unable to find `stddef.h`
>> on the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>>
>> This is needed for the tool to run properly, but not compile, so I
>> removed the FATAL from the message.
>>
>> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
>> wrote:
>>
>>>
>>>
>>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>>>
>>>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>>>> > Hello Fellow KDE Devs,
>>>> >
>>>> > I'm here, formally asking for a review of the Codevis project, to move
>>>> > forward and make it a part of kdesdk.
>>>>
>>>> Very cool project, I was amazed by the presentation of it from tarcisio
>>>> at
>>>> Akademy.
>>>>
>>>> > Currently we are using parts of KWdigetsAddons as a submodule
>>>> > Most things that are related to buildsystems will be moved to craft /
>>>> > kdesrc-build as soon as possible, right now we rely in conan for
>>>> windows
>>>> > and mac, plus a hand-written build script that downloads and builds
>>>> llvm
>>>> > for those platforms.
>>>> >
>>>> > Things that I know that are out of KDE Accordance:
>>>> > - Translation System (uses Qt's tr() system)
>>>>
>>>> This isn't an issue and we have other KDE projects using the tr()
>>>> system. But
>>>> if you want to port to ki18n, it's best to do it now since you don't
>>>> seems to
>>>> have any translations yet.
>>>>
>>>> > - Settings System (it uses my own configuration parser that resembles
>>>> QML)
>>>>
>>>> Yeah probably best to use kconfigxt or make your configuration parser
>>>> part of
>>>> kconfigxt next gen ;)
>>>>
>>>> > - Folder naming specification (follows the lakosian naming
>>>> specification)
>>>>
>>>> I don't think we have any folder (and file) naming specification in
>>>> kde, or at
>>>> least if we have one, it varies a lot between projects.
>>>>
>>>> > - CI used is based on Gitlab, but fails on KDE
>>>>
>>>> When trying to build it on my laptop it failed, due to the requirement
>>>> of
>>>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>>>
>>>
>>> Carl,
>>>
>>> There’s no requirement for clang16 (I build with 15, tarcisio builds
>>> with 14, the previous ci had 13, I believe)
>>>
>>> Mind if you share the build logs?
>>>
>>> Best
>>>
>>>
>>>
>>>
>>>>
>>>> > The current repository of Codevis is:
>>>> > https://invent.kde.org/tcanabrava/codevis
>>>> >
>>>> > The KDE developers on this project are me, tarcisio fischer (that
>>>> presented
>>>> > Codevis on Akademy), and Richard Dale.
>>>> >
>>>> > Best regards,
>>>> > Tomaz
>>>>
>>>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Small update that the CI is now fully passing.

On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava  wrote:

> Carl, Sysadmins:
>
> The current error on the KDE ci is this:
>
> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You can
> change this by defining CT_CLANG_HEADERS_DIR
> CMake Error at CMakeLists.txt:87 (message):
> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
> -- Configuring incomplete, errors occurred!
>
> (to which I understand that carl said there's an error with Clang6. This
> is not an error - it basically says that we are unable to find `stddef.h`
> on the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>
> This is needed for the tool to run properly, but not compile, so I removed
> the FATAL from the message.
>
> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
> wrote:
>
>>
>>
>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>>
>>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>>> > Hello Fellow KDE Devs,
>>> >
>>> > I'm here, formally asking for a review of the Codevis project, to move
>>> > forward and make it a part of kdesdk.
>>>
>>> Very cool project, I was amazed by the presentation of it from tarcisio
>>> at
>>> Akademy.
>>>
>>> > Currently we are using parts of KWdigetsAddons as a submodule
>>> > Most things that are related to buildsystems will be moved to craft /
>>> > kdesrc-build as soon as possible, right now we rely in conan for
>>> windows
>>> > and mac, plus a hand-written build script that downloads and builds
>>> llvm
>>> > for those platforms.
>>> >
>>> > Things that I know that are out of KDE Accordance:
>>> > - Translation System (uses Qt's tr() system)
>>>
>>> This isn't an issue and we have other KDE projects using the tr()
>>> system. But
>>> if you want to port to ki18n, it's best to do it now since you don't
>>> seems to
>>> have any translations yet.
>>>
>>> > - Settings System (it uses my own configuration parser that resembles
>>> QML)
>>>
>>> Yeah probably best to use kconfigxt or make your configuration parser
>>> part of
>>> kconfigxt next gen ;)
>>>
>>> > - Folder naming specification (follows the lakosian naming
>>> specification)
>>>
>>> I don't think we have any folder (and file) naming specification in kde,
>>> or at
>>> least if we have one, it varies a lot between projects.
>>>
>>> > - CI used is based on Gitlab, but fails on KDE
>>>
>>> When trying to build it on my laptop it failed, due to the requirement
>>> of
>>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>>
>>
>> Carl,
>>
>> There’s no requirement for clang16 (I build with 15, tarcisio builds with
>> 14, the previous ci had 13, I believe)
>>
>> Mind if you share the build logs?
>>
>> Best
>>
>>
>>
>>
>>>
>>> > The current repository of Codevis is:
>>> > https://invent.kde.org/tcanabrava/codevis
>>> >
>>> > The KDE developers on this project are me, tarcisio fischer (that
>>> presented
>>> > Codevis on Akademy), and Richard Dale.
>>> >
>>> > Best regards,
>>> > Tomaz
>>>
>>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Carl, Sysadmins:

The current error on the KDE ci is this:

Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You can
change this by defining CT_CLANG_HEADERS_DIR
CMake Error at CMakeLists.txt:87 (message):
Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
-- Configuring incomplete, errors occurred!

(to which I understand that carl said there's an error with Clang6. This is
not an error - it basically says that we are unable to find `stddef.h` on
the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`

This is needed for the tool to run properly, but not compile, so I removed
the FATAL from the message.

On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava  wrote:

>
>
> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>
>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>> > Hello Fellow KDE Devs,
>> >
>> > I'm here, formally asking for a review of the Codevis project, to move
>> > forward and make it a part of kdesdk.
>>
>> Very cool project, I was amazed by the presentation of it from tarcisio
>> at
>> Akademy.
>>
>> > Currently we are using parts of KWdigetsAddons as a submodule
>> > Most things that are related to buildsystems will be moved to craft /
>> > kdesrc-build as soon as possible, right now we rely in conan for windows
>> > and mac, plus a hand-written build script that downloads and builds llvm
>> > for those platforms.
>> >
>> > Things that I know that are out of KDE Accordance:
>> > - Translation System (uses Qt's tr() system)
>>
>> This isn't an issue and we have other KDE projects using the tr() system.
>> But
>> if you want to port to ki18n, it's best to do it now since you don't
>> seems to
>> have any translations yet.
>>
>> > - Settings System (it uses my own configuration parser that resembles
>> QML)
>>
>> Yeah probably best to use kconfigxt or make your configuration parser
>> part of
>> kconfigxt next gen ;)
>>
>> > - Folder naming specification (follows the lakosian naming
>> specification)
>>
>> I don't think we have any folder (and file) naming specification in kde,
>> or at
>> least if we have one, it varies a lot between projects.
>>
>> > - CI used is based on Gitlab, but fails on KDE
>>
>> When trying to build it on my laptop it failed, due to the requirement of
>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>
>
> Carl,
>
> There’s no requirement for clang16 (I build with 15, tarcisio builds with
> 14, the previous ci had 13, I believe)
>
> Mind if you share the build logs?
>
> Best
>
>
>
>
>>
>> > The current repository of Codevis is:
>> > https://invent.kde.org/tcanabrava/codevis
>> >
>> > The KDE developers on this project are me, tarcisio fischer (that
>> presented
>> > Codevis on Akademy), and Richard Dale.
>> >
>> > Best regards,
>> > Tomaz
>>
>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:

> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
> > Hello Fellow KDE Devs,
> >
> > I'm here, formally asking for a review of the Codevis project, to move
> > forward and make it a part of kdesdk.
>
> Very cool project, I was amazed by the presentation of it from tarcisio at
> Akademy.
>
> > Currently we are using parts of KWdigetsAddons as a submodule
> > Most things that are related to buildsystems will be moved to craft /
> > kdesrc-build as soon as possible, right now we rely in conan for windows
> > and mac, plus a hand-written build script that downloads and builds llvm
> > for those platforms.
> >
> > Things that I know that are out of KDE Accordance:
> > - Translation System (uses Qt's tr() system)
>
> This isn't an issue and we have other KDE projects using the tr() system.
> But
> if you want to port to ki18n, it's best to do it now since you don't seems
> to
> have any translations yet.
>
> > - Settings System (it uses my own configuration parser that resembles
> QML)
>
> Yeah probably best to use kconfigxt or make your configuration parser part
> of
> kconfigxt next gen ;)
>
> > - Folder naming specification (follows the lakosian naming specification)
>
> I don't think we have any folder (and file) naming specification in kde,
> or at
> least if we have one, it varies a lot between projects.
>
> > - CI used is based on Gitlab, but fails on KDE
>
> When trying to build it on my laptop it failed, due to the requirement of
> clang 16. This might also be an issue with the kde ci on tumbleweed.


Carl,

There’s no requirement for clang16 (I build with 15, tarcisio builds with
14, the previous ci had 13, I believe)

Mind if you share the build logs?

Best




>
> > The current repository of Codevis is:
> > https://invent.kde.org/tcanabrava/codevis
> >
> > The KDE developers on this project are me, tarcisio fischer (that
> presented
> > Codevis on Akademy), and Richard Dale.
> >
> > Best regards,
> > Tomaz
>
>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Ben,

Thanks so much for all the hints, I'm adapting the CI now.

Best,
Tomaz


On Thu, Aug 17, 2023 at 11:46 AM Ben Cooksley  wrote:

> On Thu, Aug 17, 2023 at 9:20 PM Tomaz Canabrava 
> wrote:
>
>> (Another thing to add, it is currently on Qt5 but we plan to move it to
>> Qt6 as soon as possible, and as soon as we have a working CI on windows,
>> mac and linux on KDE infrastructure)
>>
>>
>> On Thu, Aug 17, 2023 at 11:18 AM Tomaz Canabrava 
>> wrote:
>>
>>> Hello Fellow KDE Devs,
>>>
>>> I'm here, formally asking for a review of the Codevis project, to move
>>> forward and make it a part of kdesdk.
>>>
>>> Currently we are using parts of KWdigetsAddons as a submodule
>>> Most things that are related to buildsystems will be moved to craft /
>>> kdesrc-build as soon as possible, right now we rely in conan for windows
>>> and mac, plus a hand-written build script that downloads and builds llvm
>>> for those platforms.
>>>
>>> Things that I know that are out of KDE Accordance:
>>> - Translation System (uses Qt's tr() system)
>>> - Settings System (it uses my own configuration parser that resembles
>>> QML)
>>> - Folder naming specification (follows the lakosian naming specification)
>>> - CI used is based on Gitlab, but fails on KDE
>>>
>>
> For your CI items here:
>
> On Linux, we don't provide non-Docker workers, and Docker-in-Docker is not
> permitted for security reasons (as it essentially means you are root on the
> runner).
> You'll need to adjust the job to give Gitlab the name of the image you
> need to run under - usage of the provided images at
> invent.kde.org/sysadmin/ci-images is preferred.
>
> Due to the ageing out of CentOS 7 we're currently in the process of
> migrating towards SLES15 based images for our Appimage builds.
>
> For Windows, we also don't provide non-Docker workers, and we only allow
> the use of blessed images we provide (in invent.kde.org/sysadmin/ci-images
> ).
> It looks like you are doing quite a bit of stand up work in your custom
> build script though, so please consider whether one of the images we
> already provide is suitable for your purposes in terms of dependencies
> provided (I believe LLVM may already be available in the -qt515 and -qt65
> images)
>
> Assuming your project is a regular CMake project though you might want to
> consider starting by adding the regular KDE CI jobs to the project though
> and seeing how they go (see the templates at
> invent.kde.org/sysadmin/ci-utilities)
>
>
>>> The current repository of Codevis is:
>>> https://invent.kde.org/tcanabrava/codevis
>>>
>>> The KDE developers on this project are me, tarcisio fischer (that
>>> presented Codevis on Akademy), and Richard Dale.
>>>
>>> Best regards,
>>> Tomaz
>>>
>>
> Cheers,
> Ben
>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

(Another thing to add, it is currently on Qt5 but we plan to move it to Qt6
as soon as possible, and as soon as we have a working CI on windows, mac
and linux on KDE infrastructure)


On Thu, Aug 17, 2023 at 11:18 AM Tomaz Canabrava  wrote:

> Hello Fellow KDE Devs,
>
> I'm here, formally asking for a review of the Codevis project, to move
> forward and make it a part of kdesdk.
>
> Currently we are using parts of KWdigetsAddons as a submodule
> Most things that are related to buildsystems will be moved to craft /
> kdesrc-build as soon as possible, right now we rely in conan for windows
> and mac, plus a hand-written build script that downloads and builds llvm
> for those platforms.
>
> Things that I know that are out of KDE Accordance:
> - Translation System (uses Qt's tr() system)
> - Settings System (it uses my own configuration parser that resembles QML)
> - Folder naming specification (follows the lakosian naming specification)
> - CI used is based on Gitlab, but fails on KDE
>
> The current repository of Codevis is:
> https://invent.kde.org/tcanabrava/codevis
>
> The KDE developers on this project are me, tarcisio fischer (that
> presented Codevis on Akademy), and Richard Dale.
>
> Best regards,
> Tomaz
>

Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Hello Fellow KDE Devs,

I'm here, formally asking for a review of the Codevis project, to move
forward and make it a part of kdesdk.

Currently we are using parts of KWdigetsAddons as a submodule
Most things that are related to buildsystems will be moved to craft /
kdesrc-build as soon as possible, right now we rely in conan for windows
and mac, plus a hand-written build script that downloads and builds llvm
for those platforms.

Things that I know that are out of KDE Accordance:
- Translation System (uses Qt's tr() system)
- Settings System (it uses my own configuration parser that resembles QML)
- Folder naming specification (follows the lakosian naming specification)
- CI used is based on Gitlab, but fails on KDE

The current repository of Codevis is:
https://invent.kde.org/tcanabrava/codevis

The KDE developers on this project are me, tarcisio fischer (that presented
Codevis on Akademy), and Richard Dale.

Best regards,
Tomaz

Re: Eloquens now on KDEREVIEW)

[Tomaz Canabrava]

Hello All,

All discussion was resolved by Felipe in the past few weeks,
I Assume this is done, and should be moved out of KDE Review?

Best.


On Tue, Jun 28, 2022 at 4:54 PM Felipe Kinoshita  wrote:

> friendly ping! :)
>
> On Wed, Jun 22, 2022 at 5:44 PM Felipe Kinoshita 
> wrote:
> >
> > > Ah! I would suggest moving the conversion into the Controller then. As
> > > far as kcfg, your Config object and your Settings.qml are concerned
> > > they can be proper bools, it's only in the Controller that you have
> > > the presentation requirement that bools must be 0/1. This saves you
> > > the two-way conversion, in the Controller you only need to convert
> > > bool=>int and the rest of the app can treat them as proper bools.
> >
> > Indeed, this makes much more sense.
> >
> > Fixed it now!
> >
> > Thanks,
> > Felipe
> >
> > On Wed, Jun 22, 2022 at 10:10 AM Harald Sitter  wrote:
> > >
> > > On Wed, Jun 22, 2022 at 12:07 AM Felipe Kinoshita 
> wrote:
> > > >
> > > > > Could you elaborate why your config.kcfg uses Ints for everything
> when
> > > > > you clearly want booleans (e.g. `Config.code == 1 ? true : false`)
> > > >
> > > > The API expects ones and zeros for its params, I chose to convert
> them to
> > > > booleans to make the API call easier to write and change.
> > >
> > > Ah! I would suggest moving the conversion into the Controller then. As
> > > far as kcfg, your Config object and your Settings.qml are concerned
> > > they can be proper bools, it's only in the Controller that you have
> > > the presentation requirement that bools must be 0/1. This saves you
> > > the two-way conversion, in the Controller you only need to convert
> > > bool=>int and the rest of the app can treat them as proper bools.
> > >
> > > HS
>

Re: State of server-side retrace of KDE crashes?

[Tomaz Canabrava]

Arch already has this, via debuginfod.



On Wed, 16 Feb 2022 at 09:04 Kevin Kofler  wrote:

> Lyubomir Parvanov wrote:
> > There were some talks about adding a server-side retrace service for KDE,
> > what's the latest status quo? I really believe that KDE would be way more
> > stable if this was existing...
>
> I do not think server-side retrace is feasible without split debuginfo
> packages. If you need to rebuild the package to get debugging information,
> as is currently the case on Arch, you have no way to ensure that the
> rebuild
> will use the exact same addresses as the version that produced the
> backtrace.
>
> Arch needs to provide split debuginfo like basically all other major
> distributions. There is no way around it.
>
> Kevin Kofler
>
>

Re: kconfig_compiler question: reusing the enum of a previous config entry

[Tomaz Canabrava]

The enums are always saved as int on the config, this is not a bug, but per
design.


On Sun, 21 Mar 2021 at 11:37 Albert Astals Cid  wrote:

> El dissabte, 20 de març de 2021, a les 17:02:19 CET, David Hurka va
> escriure:
> > Hi all,
> >
> > I am working on
> https://invent.kde.org/graphics/okular/-/merge_requests/366,
> > where I am trying to get two config entries that use the same enum.
> >
> > The entry EnumColorMode defines an enum with values like “Normal” = 0
> and
> > “InvertLuma” = 6.
> >
> > I can reuse the enum in these two ways:
> >
> > 1. Write .
> > This is documented as “It is also possible to [use] enums external to
> the
> > generated class”, just that the enum is not actually external.
> >
> > 2. Write  in all entries, and the first
> time
> > define it as usual.
> > This creates a global enum and then treats it as external enum.
> >
> > Both ways work, but don’t use the KConfigSkeleton::ItemEnum as I defined
> it.
> > This means, instead of “InvertLuma”, it will write “6” to the config
> file.
> >
> > Is there a proper way to reuse the enum of a previous config entry?
>
> Looking at KConfigXmlParser::readChoicesFromEntry and
> KConfigXmlParser::readGroupElements I don't think it's currently possible
> to reuse the choices from one entry to the other.
>
> Cheers,
>   Albert
>
> >
> > Cheers, David
> >
> >
> >
>
>
>
>
>

Plasma Firewall on KDE Review

[Tomaz Canabrava]

People, I have send this e-mail to kde devel months ago, and forgot to send
here.

I would like to move Plasma Firewall to kdereview, Plasma Firewall is a
Multi - Backend Firewall KCM that currently supports UFW and FirewallD,
with a FreeBSD backend on the way.

the current repository is on https://invent.kde.org/network/plasma-firewall

The one thing I know is missing are the unittests, that I'm working on.

Please review the code and test.

Best,

Tomaz

Moving Konsole to Gitlab

[Tomaz Canabrava]

People,

I'v talked to Kurt and Nate this week about my current frustrations with
Phabricator, last week I got a few important patches messed up in the way
that only phab can do for you. And we agreed that a move to Gitlab is
desired, I talke to ben about it and he made me aware that this can impact
KDE release schedule.

So, here I'm, I don't know what can happen if a kde-core app moves to
gitlab now, I know that most of the apps there are from extragear. Maybe
it's time to shift more projects to it.

I'm adding Albert as cc since I belive that he knows this more than I do.

Best,
Tomaz

Re: CI system maintainability

[Tomaz Canabrava]

On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame  wrote:
>
> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto:
> > I'd argue we're loosing more with the current state of PIM than we'd loose
> > with mandatory reviews.
>
> Perhaps, instead of an all-or-nothing approach, why not a minimal set of
> "requirements" that would require a review? Yes, it requires more discipline
> from those involved, but at least it will help people getting "ingrained" with
> the concept without being a wall.
>
> Examples:
>
> - No review: typo fixes, compile errors, version bumps (internal)
> - Review: build system adjustments (perhaps CC some people knowledgeable in
> this case), non-trivial changes like patches
> - "Deprecation" removals (as in the casus belli here) - review if touching
> more than a handful of files / multiple repos
>
> (list made by someone who has a passing knowledge of C++, so feel free to rip
> me to shreds)
>
> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps direct
> mailing to the user (as I suggested earlier) in case of continuous failures
> will also help.
>
> If this thing works, one can gradually ramp up the requirements of things that
> go through review when the "muscle memory" is formed.

The problem is that a git comit is a git commit, there's no way that a
typo will be treated differently then another commit.
I strongly advocate for "reviews always", but since I was outvoted a
few times on this I would at least say "can we at least have reviews
for non project members" ?


> --
> Luca Beltrame
> GPG key ID: A29D259B

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Tue, Mar 12, 2019 at 9:34 AM Martin Koller  wrote:
>
> On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote:
> > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
> > >
> > > Hi,
> > >
> > > since some time has already passed and there was no conclusion, I'll try 
> > > once again
> > > to announce liquidshell.
> > >
> > > I have made adjustments to the README which now says:
> > >
> > > liquidshell is a basic Desktop Shell implemented using QtWidgets.
> > >
> > > Main Features:
> > > - Wallpaper per virtual desktop
> > > - No animations, low memory and CPU footprint
> > > - Instant startup
> > > - No use of activities
> >
> > How apps that deal with activities will work on? they will just
> > silently ignore activities?
>
> Since I do not use activities, I have no idea.
> But since liquidshell does not even offer anything related to activities,
> why would an application face an issue with that in the first place ?

Because I could use plasma and activities and then install liquidshell
to test, to discover that I'm unable to launch the application in the
state that I left.
I, as user, being unable to reach an already configured application
state, would consider that Liquidshell has a bug related to the
loading of applications.

> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
>
>

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Sun, Mar 10, 2019 at 1:25 PM Martin Koller  wrote:
>
> Hi,
>
> since some time has already passed and there was no conclusion, I'll try once 
> again
> to announce liquidshell.
>
> I have made adjustments to the README which now says:
>
> liquidshell is a basic Desktop Shell implemented using QtWidgets.
>
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, low memory and CPU footprint
> - Instant startup
> - No use of activities

How apps that deal with activities will work on? they will just
silently ignore activities?

> - QtWidgets based, therefore follows widget style from systemsettings
> - Icons are used from your globally defined icon theme from systemsettings
> - Colors are used from your globally defined color theme from systemsettings
> - Can additionally be styled with css by passing the commandline option 
> -stylesheet filename.css
>   (see included example stylesheet.css)
> - uses existing KDE Frameworks dialogs for most configurations, e.g. 
> StartMenu, Virtual Desktops, Bluetooth, Network
> - Just one bottom DesktopPanel, containing:
>   StartMenu (allowing drag of entries into konqueror/dolphin to configure 
> QuickLaunch or AppMenu entries)
>   QuickLaunch (showing icons for .desktop files from a configurable folder)
>   AppMenu (showing .desktop files in a menu from a configurable folder, 
> defaults to users desktop folder)
>   Pager (for switching virtual desktops)
>   WindowList (Popup showing all open windows on all desktops)
>   TaskBar (showing windows on the current desktop, allowing drag of an entry 
> onto the Pager to move to a different desktop)
>   LockLogout
>   SysLoad widget including CPU, Memory, Swap and Network bars, live updated 
> tooltip
>   SysTray with integrated Network-, Notifications-, Device Notifier-, 
> Bluetooth-, Battery- display.
>   It also features PackageKit software updates integration.
>   The DeviceList also shows devices connected and paired with KDEConnect.
>   Display of StatusNotifier items from other applications (no legacy 
> embedded icons yet).
>   Notifications kept in a history list for some minutes, including 
> timestamp and text selectable per mouse
>   (very handy for copy/paste of TAC numbers from online banking received 
> via SMS and transferred to KDE
>via kdeconnect)
>   Clock widget (with calendar popup, tooltip for selected cities)
>
> I think the final place should be extragear.
>
> openSuse's OBS has already packages for some distributions
>
> Screenshots:
> http://members.aon.at/m.koller/liquidshell_20190310_light.png
> http://members.aon.at/m.koller/liquidshell_20190310_dark.png
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
>
>

Re: Symmy in kde-review

[Tomaz Canabrava]

On Sun, Dec 3, 2017 at 11:14 PM, Albert Astals Cid  wrote:

> El dijous, 23 de novembre de 2017, a les 10:34:41 CET, Elvis Angelaccio va
> escriure:
> > Hi,
> > symmy has been moved to kde-review for the usual review process.
> >
> > It's a tiny frontend for the symmetric encryption functionality of GPG.
> It
> > doesn't handle signing or public/private keys, as we already have kgpg or
> > kleopatra for that.
>

How hard would be to make that functionality to kgpg (simple encryption
without public / private keys) instead of yet - another tool to handle file
encryption?

>
> > Symmy can be useful if you have to send some sensitive file to someone,
> of
> > if you want to store it on some proprietary cloud service.
> >
> > It comes with a CLI application and plugins for GUI integration with
> > Dolphin/Plasma.
>
> I built symmy and did:
>  * cd builddir
>  * symmy Makefile
>  * wrote a password
>
> Now what? Where is my encrypted file?
>
> Also i'd say that the i18n from symmy/plugin won't load the symmy catalog?
> you
> probably want to use the i18nd variants?
>
> And you also KLocalizedString::setApplicationDomain in your main.cpp?
>
> Cheers,
>   Albert
>
> >
> > I'd like to move it to either extragear-utils or kde-utils, if everything
> > looks good.
> >
> > Thanks,
> > Elvis
>
>
>

Re: Latte : make_unique for gcc <=4.8

[Tomaz Canabrava]

On Sun, Nov 5, 2017 at 4:12 PM, Michail Vourlakos 
wrote:

> Hello everyone,
>
> during the review phase in Latte we removed the following code in case it
> would conflict in some cases:
>
> #if __GLIBCXX__ <= 20150623
> namespace std {
> template
> unique_ptr make_unique(Args &&... args)
> {
> return std::unique_ptr(new T(std::forward(args)...));
> }
> }
> #endif
>
>
> this was needed for gcc versions that even though they are C++14
> compatible they dont offer make_unique function. By removing that code we
> broke compatibility with openSUSE Leap that uses gcc 4.8.5 ... so in order
> to build latte packages a made a patch to readd that code.
>
> Do you know any better way to handle this?
>

I would say "just drop it altogether" because 4.8.5 is too old and broken
(it's a 2013 release, after all. four years have passed and for programming
this is an eternity) - require a newer compiler.


> regards,
> [michail]
>
>
> BTW: for every e-mail I send I need moderator approval is that a standard
> procedure or I can register somewhere to avoid this?
>

yes, you can: https://mail.kde.org/mailman/listinfo/kde-core-devel

Re: Latte Dock into extragear...

[Tomaz Canabrava]

Awesome,

On Thu, Nov 2, 2017 at 8:39 PM, Michail Vourlakos 
wrote:

> Just to update...
>
> Latte from now on can be found at extragear after succeeding at its review
> phase...
> as mentioned also at: https://phabricator.kde.org/T7115
>

Downloading and installing to test.
<3


> regards,
> [michail]
>

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Mon, Nov 6, 2017 at 1:30 PM, Alexander Potashev 
wrote:

> 2017-11-06 14:16 GMT+03:00 Kevin Funk :
> > You're free to work on whatever you like to of course, but to me this
> sounds
> > like wasted effort. Your good incentives would be better spent with
> joining up
> > with others aiming for the same (LxQt for instance).
>
> Hi,
>
> I had a bad impression of LxQt because:
>  1. it didn't work for me out of the box,
>

For many people kde applications don't work out of the box too.

 2. it consists of many components, it's hard to figure out which of
> them are optional,
>

Also true for kde applications.

 3. it has poor infrastructure compared to KDE, e.g. their i18n server
> hadn't been working for about a year.
>

I cant comment on that - but the project seems to be alive as there was a
new release just last month with a lot of changes, also they use kf5
libraries where needed.


> Thus liquidshell looks better to me than lxqt; joining an inferior
> project is not a good idea.
>

please refrain from using words like 'inferior' for a project as it's not
helpful.
Currently the whole code for liquidshell is done for one person, and we (as
in the KDE Sc) suffer for a lot of good projects and ideas that as soon as
the original developers get tired the project stalls,
like Macaw Movie, Spectacle, Baloo and quite a few others - so I'm really
afraid of a one-man-project that's basically what other many projects
already do.

About liquidshell, I tried but it didn't even compile on my machine (some
issue with Solid)




>
> --
> Alexander Potashev
>

Re: liquidshell in kdereview

[Tomaz Canabrava]

On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller  wrote:

> On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote:
> > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> > > Hi all,
> > >
> > > I'd like to announce an application I've implemented over the last few
> weeks - liquidshell
> > >
> > > liquidshell is a replacement for plasmashell
> > >
>
> >
> > Hi Martin,
> > I'm a bit confused, who is liquidshell for?
>
> Whoever does not like plasmashell, for whatever reason.
> My reasons are mentioned in the README or the announcement mail.
> Free software is about choice, no ?
>

It is, of course. Then, it's also about non-fragmentation, and you know,
human resources are spare.
I know it's your time and your project and I will never tell you what to
do,
but considering that there's lxqt which  exists basically for the same
'whatever reasons', why not help them instead of creating yet another
desktop shell?


> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
>
>
>

Re: AtCore on KDE Review

[Tomaz Canabrava]

On Thu, Jul 6, 2017 at 2:03 PM, Luigi Toscano 
wrote:

> Lays Rodrigues ha scritto:
> > Hi guys of kde-core.
> >
> > Any new review of AtCore? =D
>
> I think that there were questions open on your side. Did you address the
> two
> issues, namely:
>
> > On Fri, Jun 23, 2017 at 11:19 PM, Lays Rodrigues  wrote:
>
> > -> aacid
> >
> > "Partially, i personally still think it'd be better if you move the
> > PrinterState AXIS and MeasuramentUnits enums inside AtCore (or make
> them C++11
> > "enum class").
> >
> > Also note how PrinterState AXIS MeasuramentUnits is not consistent
> naming
> > "
> >
> > For that, I think this is the diff: https://phabricator.kde.org/
> D6363
> > 
>
> This seems to be merged; Albert, does it address your concern?
>
>
> >
> > -> Luigui
> > "In addition to Albert's comment, I noticed now (still going through
> the
> > backlog after vacation) that atcore use tr() for messages, but there
> is no
> > Messages.sh file to extract the strings (which should be called
> atcore_qt,
> > check the similar files in step or marble or in tier1 frameworks)."​
>
> I don't think that this has been addressed
>

It was not, and it's my fault.
I was looking on marble sources but I didn't understood how the Messages.sh
works,
I'm reading and will update that as soon as I can.


>
> --
> Luigi
>

Re: Replacement of notes.kde.org

[Tomaz Canabrava]

On Sun, Jan 1, 2017 at 10:59 AM, Tomaz Canabrava <tcanabr...@kde.org> wrote:

> Ben, Sysadmins.
>
> On Thu, Dec 29, 2016 at 5:08 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>
>> Hi all,
>>
>> Sysadmin is currently in the process of testing and evaluating
>> Collabora Online (CODE) as a replacement for notes.kde.org. We've
>> enabled this on share.kde.org.
>>
>> It would be appreciated if people please test it out - anyone who is a
>> Developer, member of the e.V, or Visual Design Group should be able to
>> login on share.kde.org. Please send your feedback to this thread.
>>
>
> I just tried to login and didn't found out how to trigger a new document,
> for me it looks like just the basic Nextcloud installation, without access
> to anything but Files and Gallery.
>

~ups~
I just found where the new document is. Maybe  we should change for
something not hidden in the `+` button?


> Tomaz
>
>
>>
>> We've already figured out a process for exporting all data from
>> notes.kde.org, and will look to do this once initial testing is
>> finished - ideally this would happen a day or two after New Years.
>>
>> Thanks,
>> Ben
>>
>
>

Re: Replacement of notes.kde.org

[Tomaz Canabrava]

Ben, Sysadmins.

On Thu, Dec 29, 2016 at 5:08 AM, Ben Cooksley  wrote:

> Hi all,
>
> Sysadmin is currently in the process of testing and evaluating
> Collabora Online (CODE) as a replacement for notes.kde.org. We've
> enabled this on share.kde.org.
>
> It would be appreciated if people please test it out - anyone who is a
> Developer, member of the e.V, or Visual Design Group should be able to
> login on share.kde.org. Please send your feedback to this thread.
>

I just tried to login and didn't found out how to trigger a new document,
for me it looks like just the basic Nextcloud installation, without access
to anything but Files and Gallery.

Tomaz


>
> We've already figured out a process for exporting all data from
> notes.kde.org, and will look to do this once initial testing is
> finished - ideally this would happen a day or two after New Years.
>
> Thanks,
> Ben
>

Re: Please cleanup your scratch and clone repositories

[Tomaz Canabrava]

Done.

On Sun, Nov 27, 2016 at 9:39 AM, Ben Cooksley  wrote:

> On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley  wrote:
> > Hi all,
>
> Hi all,
>
> >
> > To help Sysadmin assess how these types of repositories would be used
> > under Phabricator, it would be appreciated if everyone could please
> > cleanup the scratch and clone repositories they're no longer using and
> > have no need to keep.
> >
> > You can get a list of repositories you have by visiting
> > https://cgit.kde.org/ or by running the below command and filtering
> > appropriately using your favourite tools.
> >
> > ssh g...@git.kde.org info
> >
> > Once you've determined the repositories to remove, they can be removed
> > by running the following two commands:
> >
> > ssh g...@git.kde.org D unlock scratch/username/reponame
> > ssh g...@git.kde.org D rm scratch/username/reponame
> >
> > Please note that the trailing .git should not be included, otherwise
> > the system will not accept your request. You can substitute
> > scratch/... for clones/... as appropriate here.
> >
> > Thanks in advance for removing unused repos!
>
> We've had good progress so far in cleaning up unused repositories -
> i'd estimate good 50 or so repositories have been cleaned up.
> For those who haven't yet checked their personal clones and scratch
> repositories it would be appreciated if you could do so.
>
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
>
> Thanks,
> Ben Cooksley
>

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Tomaz Canabrava]

tcanabra:/data/ $ git clone
kde:diagram   [13:41:14]
Cloning into 'diagram'...
fatal: remote error: access denied or repository not exported: /diagram


Is this  expected?

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Tomaz Canabrava]

On Thu, Feb 12, 2015 at 1:52 PM, Tomaz Canabrava tcanabr...@kde.org wrote:

 tcanabra:/data/ $ git clone
 kde:diagram   [13:41:14]

ugh - just realized I forgot a 'k'

 Cloning into 'diagram'...
 fatal: remote error: access denied or repository not exported: /diagram


 Is this  expected?

Re: SFLPhone-KDE is now Ring-KDE and is moving to kdereview

[Tomaz Canabrava]

On Mon, Jan 19, 2015 at 8:20 PM, Elv1313 . elv1...@gmail.com wrote:

 Ok,

 I pushed some changes to:

 * clean the BookmarkModel d-pointer issues
 * rename Contact d to d_ptr
 * Remove the legacyhistorybackend as import from 2 years old version
 isn't important anymore
 * Fix the cmakelist duplicated line

 Missing d-pointers:
 * The ringtone model, a new version is in a github branch, I have yet
 to review and merge it
 * SecurityEvaluationModel is currently being rewriten, fixing it now
 is pointless, the new version wont be ready before this review expire

 All other classes without d-pointer are interfaces or proxy models,
 they don't need d-pointers.

 Regards,
 Emmanuel Lepage

 On 14 January 2015 at 18:22, Elv1313 . elv1...@gmail.com wrote:
  Hello Albert,
 
  Thanks for your comments.
 
  * src/abstractitembackend.h is twice in libringclient_LIB_HDRS
 
  I will fix that, thanks, maybe we should add a Krazy2 check for that.
  I know Laurent Model has posted one on planetkde.org for the code
  a while back, I haven’t used it yet.
 
  * You have some d-pointers in some of your classes but not on others,
 why is
  that?
 
  Umm, I was under the impression I had fixed that in the commit before
 posting
  this email. Krazy2 doesn't seem to analyze LibRingClient yet, even if I
  checked it on projects.kde.org. Maybe it does really take more than 5
 days?
  Anyhow, I will fix more of them. Some classes are really just templates
 aliases
  + QObject inheritance, so those obviously don't need d-pointers. Other
 simply
  have no private members, I am not sure if I should add d-pointer to
 those just
  in case, maybe I should.
 
  * There's a catch regarding translations. You are using
  $XGETTEXT_QT in your Messages.sh. That creates a .po file that only
 works for
  clients that access those translations via kdelibs4 i18n() (or maybe
 other
  gettext wrappers) but not (i think) via kf5 ki18n() or plain Qt tr().
 For Qt5
  we have $EXTRACT_TR_STRINGS that creates a proper .tr file to use with
 Qt5 (no
  idea if it works with Qt4, maybe it does). This is a bit weird too
 because
  your branch has both Qt4 and Qt5 support in the same branch but our
  translation system is build around the expectation that there will be
 separate
  branches and thus they will have different Messages.sh catering for
 each qt4
  and qt5. At this stage I'm not sure what's the best thing for you guys
 to do
  :/ Are you mainly targetting qt4 or qt5 for clients to use?
 
  The problem is that we are doing a very major release right now and the
 kf5 port
  is not ready yet, so it wont make the cut for our deadlines. There is 2
 or 3
  other projects trying to release a fully decentralized and secure
 communication
  playform right now. We think we still are the closest to that, so we
 hurry up.
  I prefer to spend my time on security details than KF5 port for the next
 month,
  so we will miss the spring distribution cycle for KF5. After the 2.0
 release,
  getting rid of the Qt4 support will be something I will do. I don't care
 about
  Qt4 at this point, but the KDE ui is still using KDE4 and I also wait
 for KDEPim
  kf5 support to mature before doing the switch. The others clients, such
 as GTK
  and OS X, use Qt5 and some patches are starting to be Qt5 only, but I
 don't
  want to drop Qt4 until about mid-March. I guess translation support that
 works
  on KDE4 is better than nothing for now. The new OSX and Gnome client
 don't have
  any translations yet anyway, so the fact that the few tr() in
 libringclient are
  not translated don't have an impact on them yet.


May I ask why to create a Gtk and OSX native clients if Qt can work pretty
well on an Gnome enviroment and also on OSX?
not arguing, just a silly doubt. :)


 
  As you saw, it also cause the CMakeLists.txt to be ugly and bloated and
 I also
  have to keep the deprecated/qt4support flag on. I also can't use the
 abstract
  proxy model and other classes that made their way into QtCore, nor
 switch to
  the much easier to lint connect() syntax. There is quite a few //TODO
 qt5 in
  the code. This is a (temporary) very bad situation...
 
  Regards,
  Emmanuel

Re: Talks @Akademy

[Tomaz Canabrava]

Jos,

a few months ago you asked if I could do a talk about creating quilver
pens, still up for that? :)

Tomaz

On Tue, May 20, 2014 at 5:25 AM, Jos Poortvliet jospoortvl...@gmail.com wrote:
 Hi all,

 I notice it is still possible to send in proposals for Akademy 2014. While we
 are past the deadline (last Sunday) I suggest you use this opportunity to
 sneak your stuff in while you still can ;-)

 Remember, we're largely looking for two kinds of sessions: in depth
 technology/training sessions and short sharing sessions where you tell your
 fellow KDE hackers about what you and/or your team have been up to. The
 former are multi-track, the latter are during a single track so you talk to
 the entire attendance of Akademy. It can therefor make sense to split your
 talk up in a technical part and a generic 10 minutes for the sharing session
 where you can tease the technical part and invite people to join there.

 https://conf.kde.org/en/Akademy2014/cfp/session/new

 Hugs,
 Jos



 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe 

Re: kde review kartesio

[Tomaz Canabrava]

Quite Unlikely ...

It's a Solver, to fit curves into points, That's  very used in any
theorical research,  engeniering, math, phisics, etc.






2013/5/10 Anne-Marie Mahfouf annemarie.mahf...@free.fr

 Hi,

 I am wondering what is the user base for this application as it seems
 quite specialized (I did not build it yet though). Can you tell us more
 about the potential target? Another question that comes to mind is: can't
 it be a feature of an existing KDE Edu apps?

 Best regards,

 Anne-Marie

 - Mail original -
  De: LucaTringali tringalinv...@libero.it
  À: kde-core-devel@kde.org
  Envoyé: Jeudi 9 Mai 2013 18:06:16
  Objet: kde review kartesio
 
 
 
  Hello,
 
  I have been working on Kartesio, a program for calculating best fit
  curves with experimental points. I think it is ready to be moved in
  the KDE Edu main repo now, so I'm asking your approval.
 
  I followed the guidelines (
  http://techbase.kde.org/Policies/Application_Lifecycle ) and
  Kartesio is actually in KDE review:
 
  https://projects.kde.org/projects/kdereview/kartesio
 
  For any question, ask me.
 
 
 
 
  Luca Tringali
 

Re: kde review kartesio

[Tomaz Canabrava]

Annma, I find that proposal *very* good.

I'm a bit distant of KDE programming - I know - because my day job is
making me work 12h+ creating scientific tools.
( actually - one of the tools that I created here was a... Solver, to fit
curves on points... )

Tomaz


2013/5/10 David Edmundson da...@davidedmundson.co.uk

 The app sounds awesome.

 From the application life cycle page you linked:
  When you have made one of more releases and want to continue to develop
 it, the term 'playground' does no longer apply to you. That is the right
 time to move out of here

 There are no releases on download.kde.org under unstable. Have you
 made these releases elsewhere? If so can you provide a link.

 Thanks

 David Edmundson

Re: Compiler version

[Tomaz Canabrava]

On Thu, Jun 28, 2012 at 1:09 PM, Rolf Eike Beer
k...@opensource.sf-tec.de wrote:
 Am Donnerstag, 28. Juni 2012, 10:20:42 schrieb Thiago Macieira:
 On quinta-feira, 28 de junho de 2012 10.14.03, Ivan Cukic wrote:
  Well, nullptr is a compile time check, right (like explicit override)? So,
  you  compile your code with a compiler that supports it, making your code
  safe in that aspect, while someone could still compile the code with an
  older compiler.

 Qt 5 has Q_NULLPTR that expands to nullptr on C++11 and 0 otherwise.

 Is there any chance that these macros will find their way into Qt4? I don't
 mean that they should be used by Qt itself everywhere (or at all), but
 providing them would allow an easy forward-compatible way of introducing this
 stuff. That may not really help for KDE (or we need to require 4.8.3 or need 
 to
 ship them ourself) but for other stuff out there this would be an improvement
 that you basically get for free.

 Eike

That'd be hard, since there's no Qt 4.9 planned, but a simple macro
that won't break stuff can be made on KDE api to define Q_NULLPTR (
implications? ) when it's doesn't exists.
Thiago, on C++ 0 and (void*) 0 are the same thing? I know that on C
they aren't, and I didn't found the information easily on the web.

Tomaz

Re: Review Request: Fix KCategorizedView race

[Tomaz Canabrava]

On Thu, Dec 8, 2011 at 2:33 AM, Thomas Lübking thomas.luebk...@web.dewrote:

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

 On December 6th, 2011, 6:39 p.m., *Commit Hook* wrote:

 This review has been submitted with commit 
 08325ba32b72326030004cc28430431193d82fc2 by Thomas Lübking to branch KDE/4.7.

  On December 8th, 2011, 2:40 a.m., *Christoph Feck* wrote:

 This commit causes systemsettings to go into endless recursion, see 
 http://privatepaste.com/0e43ad214c

 zemo on #plasma confirmed that reverting it fixes the regression.

  *g* - gonna check tonight, have solution tomorrow. thomas angry. |


What about jaime patch?


 - Thomas

 On December 5th, 2011, 2:21 p.m., Thomas Lübking wrote:
   Review request for kdelibs, Rafael Fernández López and Jaime Torres
 Amate.
 By Thomas Lübking.

 *Updated Dec. 5, 2011, 2:21 p.m.*
 Description

 Also see https://git.reviewboard.kde.org/r/103313/


 QListView::updateGeometries() has it's own opinion on whether the scrollbars 
 should be visible (valid range) or not
 and triggers a (sometimes additionally timered) resize through 
 ::layoutChildren()http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/itemviews/qlistview.cpp#line1499
 (the comment above the main block isn't all accurate, layoutChldren is called 
 regardless of the policy)

 As a result QListView and KCategorizedView occasionally started a race on the 
 scrollbar visibility, effectively blocking the UI
 So we prevent QListView from having an own opinion on the scrollbar 
 visibility by
 fixing it before calling the baseclass QListView::updateGeometries() and 
 restoring the policy afterwards

   Testing

 Yes, resizing the kcmshell4 kwincompositing, all effects KPluginSelector 
 with large scrollbar sizes (bespin/position indicator/32px; oxygen was often 
 sufficient with the default size) after commit 
 e91e5fed6b1aad365e12e919f430c3e8147552d3 (see 
 https://git.reviewboard.kde.org/r/103165/ ) was a reliable way to trigger the 
 issue for me.
 It also showed that resize/updateGeometries occured in pairs (ie 4calls 
 forming  a block), what's never happened again with the patch.

   *Bugs: * 213068 http://bugs.kde.org/show_bug.cgi?id=213068, 
 287847http://bugs.kde.org/show_bug.cgi?id=287847
 Diffs

- kdeui/itemviews/kcategorizedview.cpp (46a1cde)
- kutils/kpluginselector.cpp (ca0691d)

 View Diff http://git.reviewboard.kde.org/r/103335/diff/

Re: teacher needed for Ada Lovelace Day tutorial

[Tomaz Canabrava]

Must be a woman - teacher?
what about annma?

On Tue, Sep 27, 2011 at 3:00 PM, Lydia Pintscher ly...@kde.org wrote:
 Heya folks :)

 Ada Lovelace Day is on 7th of October and I and a few other people
 would love to have a programming tutorial on IRC on that day. It'd be
 a for women and their friends event, meaning men are welcome if
 they're nice but the main focus are women). The goal of the tutorial
 would be writing a first small KDE application or fixing a bug. If we
 have teachers for both we could also do two tutorials.
 I'm looking for a teacher for this. I and others will help with
 promotion. Any takers?


 Cheers
 Lydia

 --
 Lydia Pintscher
 KDE Community Working Group member
 http://kde.org - http://about.me/lydia.pintscher

Re: Nepomuk and MySQL - Why?

[Tomaz Canabrava]

On Sun, Aug 21, 2011 at 1:09 PM, Thiago Macieira thi...@kde.org wrote:
 On Sunday, 21 de August de 2011 17:28:36 Mark wrote:
  A bit about MongoDB.
 
  Irrelevant until someone writes a QtSql backend for it.

 which is not possible since the entire NoSQL principle doesn't fit SQL.
 Perhaps a QtNoSQL implementation ^_-

 That doesn't work. Akonadi is implemented entirely on top of SQL and QtSql.

 If MongoDB can't do SQL, it can't be a DB backend  for Akonadi and thus the
 discussion is irrelevant.

Nope, MongoDB can't do SQL. Mongo doesn't have a 'Language
Specification', it needs methods to add / remove items, and it's very
weird to do updates. It's easyer to create simple adds, very complex
to do complex queries.


 --
 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: smallish project needed

[Tomaz Canabrava]

juk should be a lightweigth music player, while amarok should be an
all-featured media player. I say should because juk is in a stage
where it's not lightweigth, for the code there needs much love. that
said, juk is part of KDE software, while Amarok does not follow the
KDE rules to be part of the official package. ( same release dates for
instance )

On Fri, Aug 12, 2011 at 9:57 AM, Mark mark...@gmail.com wrote:
 On Wed, Aug 10, 2011 at 12:08 AM, Lydia Pintscher
 lydia.pintsc...@gmail.com wrote:
 On Tue, Aug 9, 2011 at 03:15, Michael Pyne mp...@kde.org wrote:
 On Monday, August 08, 2011 18:44:40 Tomaz Canabrava wrote:
 Juk is an easy target, and in need of love.

 Honestly I was going to recommend the same thing.

 I don't agree that it's (all) easy (although there is certainly a lot of 
 low-
 hanging fruit), but it does have the advantage that I'm at least available 
 by
 email to help guide/mentor.

 In addition I will be completing school very soon, which hopefully should 
 add
 some time per day (although that may be offset by the new job I will be
 rotating to soon which will probably involve a longer commute).

 Either way, JuK could use some love, there's still someone mostly-active who
 can show interested parties around the codebase and I should have piped in 
 on
 one of these requests awhile ago (but I've always assumed someone else has
 need the help more ;( )

 Thanks guys. I've suggested him to take a look at JuK.


 Cheers
 Lydia

 --
 Lydia Pintscher
 KDE Community Working Group member
 http://kde.org - http://about.me/lydia.pintscher


 Hi all,

 Just wondering, but why is there Amorok and JuK? Surely Amarok can do
 everything JuK can right?
 JuK even looks a bit like Amarok.
 No pun intended!

 Thanx,
 Mark

Re: smallish project needed

[Tomaz Canabrava]

On Fri, Aug 12, 2011 at 10:26 AM, Mark mark...@gmail.com wrote:
 On Fri, Aug 12, 2011 at 3:10 PM, Tomaz Canabrava tcanabr...@kde.org wrote:
 juk should be a lightweigth music player, while amarok should be an
 all-featured media player. I say should because juk is in a stage
 where it's not lightweigth, for the code there needs much love. that
 said, juk is part of KDE software, while Amarok does not follow the
 KDE rules to be part of the official package. ( same release dates for
 instance )

 On Fri, Aug 12, 2011 at 9:57 AM, Mark mark...@gmail.com wrote:
 On Wed, Aug 10, 2011 at 12:08 AM, Lydia Pintscher
 lydia.pintsc...@gmail.com wrote:
 On Tue, Aug 9, 2011 at 03:15, Michael Pyne mp...@kde.org wrote:
 On Monday, August 08, 2011 18:44:40 Tomaz Canabrava wrote:
 Juk is an easy target, and in need of love.

 Honestly I was going to recommend the same thing.

 I don't agree that it's (all) easy (although there is certainly a lot of 
 low-
 hanging fruit), but it does have the advantage that I'm at least 
 available by
 email to help guide/mentor.

 In addition I will be completing school very soon, which hopefully should 
 add
 some time per day (although that may be offset by the new job I will be
 rotating to soon which will probably involve a longer commute).

 Either way, JuK could use some love, there's still someone mostly-active 
 who
 can show interested parties around the codebase and I should have piped 
 in on
 one of these requests awhile ago (but I've always assumed someone else has
 need the help more ;( )

 Thanks guys. I've suggested him to take a look at JuK.


 Cheers
 Lydia

 --
 Lydia Pintscher
 KDE Community Working Group member
 http://kde.org - http://about.me/lydia.pintscher


 Hi all,

 Just wondering, but why is there Amorok and JuK? Surely Amarok can do
 everything JuK can right?
 JuK even looks a bit like Amarok.
 No pun intended!

 Thanx,
 Mark



 Ah oke. Just some idea i have now.. Right now someone is working on a
 Phonon QML thing. Wouldn't it be best for JuK to be (mostly) rewritten
 using the phonon QML thing? I mean, KDE 5 seems to be going towards
 QML, Dolphin seems to go in that direction and Dragon 3 is already
 using QML : http://apachelog.wordpress.com/2011/08/07/dragon-player-3/

 Just some random thought..

 And how do i even need to see YuK? As a foobar alternative for KDE?

Dolphin is going in the QML direction?
Yes, I think a Juk rewritten in QML could be a good thing.

 Thanx,
 Mark