Re: Review Request 127462: Add support for XDG_*_HOME enviroment variables.

[Matthew Dawson]

> On March 24, 2016, 5:15 a.m., Jarosław Staniek wrote:
> > My thoughts mostly related to non-Plasma, non-XDG run environments.
> > 
> > KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part 
> > of XDG-compliant desktop. As such we can't say too much about the 
> > underlying OS. It may be XDG-compliant but athis can be a decission at 
> > various levels: by application developer or on deployment. Things can of 
> > course also change after the binary is compiled.
> > 
> > It's hard to see any benefit that apps 'pretend' being XDG-compliant by 
> > setting vartiables this way on, say, MS Windows or Mac. Qt applications on 
> > these systems do not traditionally alter the OS' paradigm, they are.. just 
> > apps, as native as possible/reasonable. Example: there are portable apps 
> > (on an USB stick) - I believe we can benefit if we help making them. These 
> > apps choose not to integrate too much with what's found on the system, 
> > often the user account is shared or temporary.
> > 
> > Setting the variable makes KConfig closer to specific groups of desktop, 
> > which is a a small step back. People may be interested in KConfig lib as a 
> > general purpose utility in their apps.
> > I'd compare setting the variable this way to setting Windows' USERPROFILE 
> > variable on Linux systems, just because it's standard under the former and 
> > under Wine. it does not hurt but leaves bad taste.
> > 
> > So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS 
> > for which we're building. But if the same binary should behave well in 
> > various environments, I am unsure about hardcoding the behaviour. Also I am 
> > not sure if this behaviour should be ON by default. I'd rather have it OFF 
> > if it's present at all.
> 
> Sandro Knauß wrote:
> Well I see it the other way around. Without support of XDG variables 
> replacement, we need to use env varaible that are available on all systems 
> f.ex. $HOME, so the only way to set the datalocaltion to write it hardcoded 
> in the config to $HOME/.local/share. This is really ony true for linux for 
> others OSes you want to have other diretories. So now we are able to use 
> XDG_DATA_HOME to be used in kconfig and it will be replaced for linux to 
> $HOME/.local/share, for windows to C:/Users//AppData/Local and so on.
> We use QStandardsPaths for replacing so if the replacement is not correct 
> for an OS this is a bug on Qt side, that should be fixed :D
> 
> And I can't see how this support can harm anyone - if the env is set this 
> is prefered and only if it is not set it is replaced. No dependecy is added 
> and applications are free to not use it at all. If you use XDG_*_HOME without 
> this patch you will return an empty string for it:
> 
> i[$e] = $XDG_DATA_HOME/bla
> 
> -> will return /bla
> 
> with the patch you will get:
> $HOME/.local/share/bla ( for linux)
> C:/Users//AppData/Local/bla ( for windows)
> [...]
> 
> Jarosław Staniek wrote:
> Before we discuss anything, let's narrow to non-Unix OSes (considering 
> Mac OS X as non-Unix):
> - Does these OSes use XDG_ to locate anything? I can't spot. 
> - Isn't it misleading to use the XDG_ variables to pass the locations 
> on these OSes? Don't we have a choice?
> 
> Digression: I am asking because one quality attribute of KF5 for could be 
> to behave or "think" like Qt would, without spreading a "Unix-y" / "XDG" feel 
> when not really necessary. Non-Unix OSes have own equivalents for many things 
> (e.g. xdg-open), at times these equivalents can be found inferior but we, not 
> being authors of the OSes, can just say "let them be such". We have enough of 
> layers and emulators, subsystems e.g. on Windows (see .NET or chrome-based 
> hybrid apps). Frameworks for developing native apps on these OSes shall not 
> attempt to fix these system facilities but just integrate. Users wanting XDG 
> experience have choice to use XDG-compliant systems...
> 
> Summing up, an #ifdef and update of documentation would be nice. My 2c...
> 
> David Faure wrote:
> Indeed a better name for these fake env vars could be QT_DATA_HOME, 
> QT_CONFIG_HOME and QT_CACHE_HOME. In fact I'm thinking more and more that 
> QStandardPaths should support these as real env vars on all OSes --- but 
> that's a separate discussion. For the purposes of this patch, we're faking 
> env vars when they are not set, for the convenience of the config files / 
> desktop files syntax. So these names would work just fine, and would simply 
> be the interface for config files to the QStandardPaths API.

+1 from me on this suggestion.  I'm good with this change if the names are 
changed and David's other points are addressed.


- Matthew


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

Re: Raising Qt requirement to Qt 5.4

[David Faure]

On Friday 25 March 2016 09:54:12 Ivan Čukić wrote:
> >> Is this documented in some wiki so we don't have to rely on people's 
> >> memories
> >> or someone digging up the corresponding email thread?
> >
> > Good point. Any suggestion on where to document this?
> 
> +1 since my gmail-search-foo was not up to the task - we have so many
> threads regarding compiler and Qt versions, it is borderline funny.
> 
> It could go alongside compiler reqs:
> 
> https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11

Thanks for the suggestion, I just added
https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements

Jan, can you drop the Qt 5.3 builds from 
http://ci-logs.kde.flaska.net/matrix.html ? Thanks.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 125570: Handle kabc deprecated classes in kabc->kcontact porting script

[David Faure]

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



The reviewboard upgrade must have messed up something, the current patch is 
just whitespace.
Please re-upload.

- David Faure


On Oct. 22, 2015, 1:30 p.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125570/
> ---
> 
> (Updated Oct. 22, 2015, 1:30 p.m.)
> 
> 
> Review request for KDE Frameworks, KDEPIM, Aleix Pol Gonzalez, and Laurent 
> Montel.
> 
> 
> Repository: kde-dev-scripts
> 
> 
> Description
> ---
> 
> A lot of KABC classes are deprecated in KF5. The porting script only replaces 
> kabc occurences to kcontacts, but overlooks if the class being used still 
> exists in kcontact or not. This leads to a lot of compile time #include<> 
> errors. I feel this should and can be avoided by modifying the script. Was 
> this overlooked on purpose or did we just miss it out ?
> 
> I've really no prior knowledge or experience of working with perl and I've 
> tried to handle the above mentioned scenario, by manually checking for 
> deprecated classnames and replacing them with a blank space or commenting 
> them out.
> 
> 
> Diffs
> -
> 
>   kf5/convert-kabc-to-kcontacts.pl 321fdf2c92745a3aece8e66085994458720f9dfd 
> 
> Diff: https://git.reviewboard.kde.org/r/125570/diff/
> 
> 
> Testing
> ---
> 
> Ran the script on the kopete codebase which uses deprecated classes like 
> addressbook, stdaddressbook, resource etc. 
> Works fine, but takes a bit of time to execute.
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

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

Re: Review Request 127462: Add support for XDG_*_HOME enviroment variables.

[David Faure]

> On March 24, 2016, 9:15 a.m., Jarosław Staniek wrote:
> > My thoughts mostly related to non-Plasma, non-XDG run environments.
> > 
> > KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part 
> > of XDG-compliant desktop. As such we can't say too much about the 
> > underlying OS. It may be XDG-compliant but athis can be a decission at 
> > various levels: by application developer or on deployment. Things can of 
> > course also change after the binary is compiled.
> > 
> > It's hard to see any benefit that apps 'pretend' being XDG-compliant by 
> > setting vartiables this way on, say, MS Windows or Mac. Qt applications on 
> > these systems do not traditionally alter the OS' paradigm, they are.. just 
> > apps, as native as possible/reasonable. Example: there are portable apps 
> > (on an USB stick) - I believe we can benefit if we help making them. These 
> > apps choose not to integrate too much with what's found on the system, 
> > often the user account is shared or temporary.
> > 
> > Setting the variable makes KConfig closer to specific groups of desktop, 
> > which is a a small step back. People may be interested in KConfig lib as a 
> > general purpose utility in their apps.
> > I'd compare setting the variable this way to setting Windows' USERPROFILE 
> > variable on Linux systems, just because it's standard under the former and 
> > under Wine. it does not hurt but leaves bad taste.
> > 
> > So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS 
> > for which we're building. But if the same binary should behave well in 
> > various environments, I am unsure about hardcoding the behaviour. Also I am 
> > not sure if this behaviour should be ON by default. I'd rather have it OFF 
> > if it's present at all.
> 
> Sandro Knauß wrote:
> Well I see it the other way around. Without support of XDG variables 
> replacement, we need to use env varaible that are available on all systems 
> f.ex. $HOME, so the only way to set the datalocaltion to write it hardcoded 
> in the config to $HOME/.local/share. This is really ony true for linux for 
> others OSes you want to have other diretories. So now we are able to use 
> XDG_DATA_HOME to be used in kconfig and it will be replaced for linux to 
> $HOME/.local/share, for windows to C:/Users//AppData/Local and so on.
> We use QStandardsPaths for replacing so if the replacement is not correct 
> for an OS this is a bug on Qt side, that should be fixed :D
> 
> And I can't see how this support can harm anyone - if the env is set this 
> is prefered and only if it is not set it is replaced. No dependecy is added 
> and applications are free to not use it at all. If you use XDG_*_HOME without 
> this patch you will return an empty string for it:
> 
> i[$e] = $XDG_DATA_HOME/bla
> 
> -> will return /bla
> 
> with the patch you will get:
> $HOME/.local/share/bla ( for linux)
> C:/Users//AppData/Local/bla ( for windows)
> [...]
> 
> Jarosław Staniek wrote:
> Before we discuss anything, let's narrow to non-Unix OSes (considering 
> Mac OS X as non-Unix):
> - Does these OSes use XDG_ to locate anything? I can't spot. 
> - Isn't it misleading to use the XDG_ variables to pass the locations 
> on these OSes? Don't we have a choice?
> 
> Digression: I am asking because one quality attribute of KF5 for could be 
> to behave or "think" like Qt would, without spreading a "Unix-y" / "XDG" feel 
> when not really necessary. Non-Unix OSes have own equivalents for many things 
> (e.g. xdg-open), at times these equivalents can be found inferior but we, not 
> being authors of the OSes, can just say "let them be such". We have enough of 
> layers and emulators, subsystems e.g. on Windows (see .NET or chrome-based 
> hybrid apps). Frameworks for developing native apps on these OSes shall not 
> attempt to fix these system facilities but just integrate. Users wanting XDG 
> experience have choice to use XDG-compliant systems...
> 
> Summing up, an #ifdef and update of documentation would be nice. My 2c...

Indeed a better name for these fake env vars could be QT_DATA_HOME, 
QT_CONFIG_HOME and QT_CACHE_HOME. In fact I'm thinking more and more that 
QStandardPaths should support these as real env vars on all OSes --- but that's 
a separate discussion. For the purposes of this patch, we're faking env vars 
when they are not set, for the convenience of the config files / desktop files 
syntax. So these names would work just fine, and would simply be the interface 
for config files to the QStandardPaths API.


- David


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


On March 22, 2016, 3:23 p.m., Sandro Knauß wrote:
> 
> ---

Re: Review Request 127486: Fix uninitialized int array in UnicodeGroupProber

[Dominik Haumann]

> On March 24, 2016, 11:29 p.m., Aleix Pol Gonzalez wrote:
> > src/probers/UnicodeGroupProber.cpp, line 80
> > 
> >
> > `(uint)` shouldn't be necessary, no? Otherwise:
> > `const uint weight_BOM(sqrt((double)aLen) + aLen / 10.0);`
> > 
> > Or even easier:
> > `const uint weight_BOM = aLen>>1 + aLen / 10;`

Right shift is not the same as sqrt :-)


- Dominik


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


On March 25, 2016, 4:53 p.m., Dominik Haumann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127486/
> ---
> 
> (Updated March 25, 2016, 4:53 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 357341
> https://bugs.kde.org/show_bug.cgi?id=357341
> 
> 
> Repository: kcodecs
> 
> 
> Description
> ---
> 
> When loading the file from bug https://bugs.kde.org/show_bug.cgi?id=360797 
> with kwrite one gets a segfault. Valgrind tells us 'count' is uninitialized 
> (see line 83).
> 
> This patch
> - moves variables to local scopes
> - initializes the variable count with 5 times 0.
> 
> The backtrace in bug https://bugs.kde.org/show_bug.cgi?id=357341 is fixed 
> this way. However, there is a second crash still happening, which still needs 
> investigation.
> 
> 
> Diffs
> -
> 
>   src/probers/UnicodeGroupProber.cpp 1d86f08 
> 
> Diff: https://git.reviewboard.kde.org/r/127486/diff/
> 
> 
> Testing
> ---
> 
> - unit tests still pass
> - The encoding prober does not crash at the location anymore - it crashes a 
> bit later (another issue)
> 
> 
> Thanks,
> 
> Dominik Haumann
> 
>

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

Re: Review Request 127486: Fix uninitialized int array in UnicodeGroupProber

[Dominik Haumann]

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

(Updated March 25, 2016, 4:53 p.m.)


Review request for KDE Frameworks.


Changes
---

Updated version with fixes.


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


Repository: kcodecs


Description
---

When loading the file from bug https://bugs.kde.org/show_bug.cgi?id=360797 with 
kwrite one gets a segfault. Valgrind tells us 'count' is uninitialized (see 
line 83).

This patch
- moves variables to local scopes
- initializes the variable count with 5 times 0.

The backtrace in bug https://bugs.kde.org/show_bug.cgi?id=357341 is fixed this 
way. However, there is a second crash still happening, which still needs 
investigation.


Diffs (updated)
-

  src/probers/UnicodeGroupProber.cpp 1d86f08 

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


Testing
---

- unit tests still pass
- The encoding prober does not crash at the location anymore - it crashes a bit 
later (another issue)


Thanks,

Dominik Haumann

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

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

[Dominik Haumann]

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

(Updated March 25, 2016, 9:43 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, kdewin, kwin, and Marco Martin.


Changes
---

Submitted with commit 906e6a1409389c5abc501f0172c5dff21fdc6edd by Dominik 
Haumann to branch master.


Repository: kcompletion


Description
---

In https://git.reviewboard.kde.org/r/127191/ the KCompletionBox WindowFlags 
were change from Qt::ToolTip to Qt::Window.

As consequence, the completion popup of the Kate command line gets a full 
window decoration, which is obviously wrong, see attached screenshot.

Changing the type to Qt::Popup shows the proper popup, but key presses are not 
forwarded, so typing is not possible, and additionally, on losing focus the 
popup keeps staying open.
Therefore, this patch reverts the type back to Qt::ToolTip.

Better fixes are of course welcome ;) Any ideas?


Diffs
-

  src/kcompletionbox.cpp 005aff8 

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


Testing
---

Works on Windows as expected.


File Attachments


Completion Popup
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/03/19/7be64cad-6d95-46b8-9caa-41b41a135ca1__kate2015.png


Thanks,

Dominik Haumann

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

Re: Raising Qt requirement to Qt 5.4

[Scarlett Clark]

CI versions has been raised as per this thread.
thanks,
Scarlett

On Fri, Mar 25, 2016 at 1:54 AM, Ivan Čukić  wrote:

> >> Is this documented in some wiki so we don't have to rely on people's
> memories
> >> or someone digging up the corresponding email thread?
> >
> > Good point. Any suggestion on where to document this?
>
> +1 since my gmail-search-foo was not up to the task - we have so many
> threads regarding compiler and Qt versions, it is borderline funny.
>
> It could go alongside compiler reqs:
>
>
> https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11
>
> Cheers,
> Ivan
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

[Martin Gräßlin]

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


Ship it!




Ship It!

- Martin Gräßlin


On March 20, 2016, 1:06 p.m., Dominik Haumann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127424/
> ---
> 
> (Updated March 20, 2016, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, kdewin, kwin, and Marco Martin.
> 
> 
> Repository: kcompletion
> 
> 
> Description
> ---
> 
> In https://git.reviewboard.kde.org/r/127191/ the KCompletionBox WindowFlags 
> were change from Qt::ToolTip to Qt::Window.
> 
> As consequence, the completion popup of the Kate command line gets a full 
> window decoration, which is obviously wrong, see attached screenshot.
> 
> Changing the type to Qt::Popup shows the proper popup, but key presses are 
> not forwarded, so typing is not possible, and additionally, on losing focus 
> the popup keeps staying open.
> Therefore, this patch reverts the type back to Qt::ToolTip.
> 
> Better fixes are of course welcome ;) Any ideas?
> 
> 
> Diffs
> -
> 
>   src/kcompletionbox.cpp 005aff8 
> 
> Diff: https://git.reviewboard.kde.org/r/127424/diff/
> 
> 
> Testing
> ---
> 
> Works on Windows as expected.
> 
> 
> File Attachments
> 
> 
> Completion Popup
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/03/19/7be64cad-6d95-46b8-9caa-41b41a135ca1__kate2015.png
> 
> 
> Thanks,
> 
> Dominik Haumann
> 
>

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

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

[Martin Gräßlin]

> On March 24, 2016, 8:45 p.m., Dominik Haumann wrote:
> > Given the feedback I got, I will submit tomorrow (Friday), independent on 
> > whether I have a ship-it or not.
> > The patch is tested both on Windows and Linux, and imo correct (the changes 
> > are rather trivial now).
> > 
> > If you have objections, please raise them by tomorrow, or better yet, do a 
> > review - thanks.
> > 
> > PS: I am totally aware that typically a ship-it is the way to get a patch 
> > accepted, but I have the feeling this patch is not getting much attention, 
> > despite me trying to get input for days.

I think you didn't get a ship-it as nobody is confident enough to say that it's 
correct on all platforms. I'm quite certain that on X11 the behavior is correct.


- Martin


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


On March 20, 2016, 1:06 p.m., Dominik Haumann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127424/
> ---
> 
> (Updated March 20, 2016, 1:06 p.m.)
> 
> 
> Review request for KDE Frameworks, kdewin, kwin, and Marco Martin.
> 
> 
> Repository: kcompletion
> 
> 
> Description
> ---
> 
> In https://git.reviewboard.kde.org/r/127191/ the KCompletionBox WindowFlags 
> were change from Qt::ToolTip to Qt::Window.
> 
> As consequence, the completion popup of the Kate command line gets a full 
> window decoration, which is obviously wrong, see attached screenshot.
> 
> Changing the type to Qt::Popup shows the proper popup, but key presses are 
> not forwarded, so typing is not possible, and additionally, on losing focus 
> the popup keeps staying open.
> Therefore, this patch reverts the type back to Qt::ToolTip.
> 
> Better fixes are of course welcome ;) Any ideas?
> 
> 
> Diffs
> -
> 
>   src/kcompletionbox.cpp 005aff8 
> 
> Diff: https://git.reviewboard.kde.org/r/127424/diff/
> 
> 
> Testing
> ---
> 
> Works on Windows as expected.
> 
> 
> File Attachments
> 
> 
> Completion Popup
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/03/19/7be64cad-6d95-46b8-9caa-41b41a135ca1__kate2015.png
> 
> 
> Thanks,
> 
> Dominik Haumann
> 
>

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

Re: Review Request 127470: kcodecs: Fix crash on invalid data

[Boris Egorov]

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

(Updated March 25, 2016, 1:28 p.m.)


Review request for KDE Frameworks.


Changes
---

Change bug to earlier one (aka original)


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


Repository: kcodecs


Description
---

Warning: I do not fully understand what I'm doing, but I believe some
crashes will disappear after this patch.

There are a few problems here.

First, there is a call to `isprint` macro which does some magic using
ctype_data table. If buffer passed to KEncodingProber contains some
negative values, it will lead to an index out of bounds of a table here:

#define ctype_test(c, t) ((ctype_data[(unsigned short)c] & t) != 0)

And it will trigger segfault.

Second, `UnicodeGroupProber::HandleData` have a few static variables,
which prevents triggering a bug. If this function executes successfully
at least ones, it will not call isprint anymore. This is a much trickier
issue, and I'm not sure how to fix it properly.


Diffs
-

  autotests/kencodingprobertest.h e4edb06 
  autotests/kencodingprobertest.cpp 937bc13 
  src/probers/ctype_test_p.h 0421f99 

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


Testing
---

Build and run tests - all passes.
Crash in #360797 is gone.


Thanks,

Boris Egorov

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

Re: Review Request 125570: Handle kabc deprecated classes in kabc->kcontact porting script

[R.Harish Navnit]

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



Well, this hasn't been resolved for a while now. A final ping before discard.

- R.Harish  Navnit


On Oct. 22, 2015, 7 p.m., R.Harish  Navnit wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125570/
> ---
> 
> (Updated Oct. 22, 2015, 7 p.m.)
> 
> 
> Review request for KDE Frameworks, KDEPIM, Aleix Pol Gonzalez, and Laurent 
> Montel.
> 
> 
> Repository: kde-dev-scripts
> 
> 
> Description
> ---
> 
> A lot of KABC classes are deprecated in KF5. The porting script only replaces 
> kabc occurences to kcontacts, but overlooks if the class being used still 
> exists in kcontact or not. This leads to a lot of compile time #include<> 
> errors. I feel this should and can be avoided by modifying the script. Was 
> this overlooked on purpose or did we just miss it out ?
> 
> I've really no prior knowledge or experience of working with perl and I've 
> tried to handle the above mentioned scenario, by manually checking for 
> deprecated classnames and replacing them with a blank space or commenting 
> them out.
> 
> 
> Diffs
> -
> 
>   kf5/convert-kabc-to-kcontacts.pl 321fdf2c92745a3aece8e66085994458720f9dfd 
> 
> Diff: https://git.reviewboard.kde.org/r/125570/diff/
> 
> 
> Testing
> ---
> 
> Ran the script on the kopete codebase which uses deprecated classes like 
> addressbook, stdaddressbook, resource etc. 
> Works fine, but takes a bit of time to execute.
> 
> 
> Thanks,
> 
> R.Harish  Navnit
> 
>

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

Re: Review Request 127462: Add support for XDG_*_HOME enviroment variables.

[Jarosław Staniek]

> On March 24, 2016, 10:15 a.m., Jarosław Staniek wrote:
> > My thoughts mostly related to non-Plasma, non-XDG run environments.
> > 
> > KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part 
> > of XDG-compliant desktop. As such we can't say too much about the 
> > underlying OS. It may be XDG-compliant but athis can be a decission at 
> > various levels: by application developer or on deployment. Things can of 
> > course also change after the binary is compiled.
> > 
> > It's hard to see any benefit that apps 'pretend' being XDG-compliant by 
> > setting vartiables this way on, say, MS Windows or Mac. Qt applications on 
> > these systems do not traditionally alter the OS' paradigm, they are.. just 
> > apps, as native as possible/reasonable. Example: there are portable apps 
> > (on an USB stick) - I believe we can benefit if we help making them. These 
> > apps choose not to integrate too much with what's found on the system, 
> > often the user account is shared or temporary.
> > 
> > Setting the variable makes KConfig closer to specific groups of desktop, 
> > which is a a small step back. People may be interested in KConfig lib as a 
> > general purpose utility in their apps.
> > I'd compare setting the variable this way to setting Windows' USERPROFILE 
> > variable on Linux systems, just because it's standard under the former and 
> > under Wine. it does not hurt but leaves bad taste.
> > 
> > So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS 
> > for which we're building. But if the same binary should behave well in 
> > various environments, I am unsure about hardcoding the behaviour. Also I am 
> > not sure if this behaviour should be ON by default. I'd rather have it OFF 
> > if it's present at all.
> 
> Sandro Knauß wrote:
> Well I see it the other way around. Without support of XDG variables 
> replacement, we need to use env varaible that are available on all systems 
> f.ex. $HOME, so the only way to set the datalocaltion to write it hardcoded 
> in the config to $HOME/.local/share. This is really ony true for linux for 
> others OSes you want to have other diretories. So now we are able to use 
> XDG_DATA_HOME to be used in kconfig and it will be replaced for linux to 
> $HOME/.local/share, for windows to C:/Users//AppData/Local and so on.
> We use QStandardsPaths for replacing so if the replacement is not correct 
> for an OS this is a bug on Qt side, that should be fixed :D
> 
> And I can't see how this support can harm anyone - if the env is set this 
> is prefered and only if it is not set it is replaced. No dependecy is added 
> and applications are free to not use it at all. If you use XDG_*_HOME without 
> this patch you will return an empty string for it:
> 
> i[$e] = $XDG_DATA_HOME/bla
> 
> -> will return /bla
> 
> with the patch you will get:
> $HOME/.local/share/bla ( for linux)
> C:/Users//AppData/Local/bla ( for windows)
> [...]

Before we discuss anything, let's narrow to non-Unix OSes (considering Mac OS X 
as non-Unix):
- Does these OSes use XDG_ to locate anything? I can't spot. 
- Isn't it misleading to use the XDG_ variables to pass the locations on 
these OSes? Don't we have a choice?

Digression: I am asking because one quality attribute of KF5 for could be to 
behave or "think" like Qt would, without spreading a "Unix-y" / "XDG" feel when 
not really necessary. Non-Unix OSes have own equivalents for many things (e.g. 
xdg-open), at times these equivalents can be found inferior but we, not being 
authors of the OSes, can just say "let them be such". We have enough of layers 
and emulators, subsystems e.g. on Windows (see .NET or chrome-based hybrid 
apps). Frameworks for developing native apps on these OSes shall not attempt to 
fix these system facilities but just integrate. Users wanting XDG experience 
have choice to use XDG-compliant systems...

Summing up, an #ifdef and update of documentation would be nice. My 2c...


- Jarosław


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


On March 22, 2016, 4:23 p.m., Sandro Knauß wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127462/
> ---
> 
> (Updated March 22, 2016, 4:23 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> According to freedesktop specification XDG_*_HOME env varaible should be
> replaced, if they are not setted with default values.
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> as qgetenv only calls getenv, so no pat

Re: Raising Qt requirement to Qt 5.4

[Ivan Čukić]

>> Is this documented in some wiki so we don't have to rely on people's memories
>> or someone digging up the corresponding email thread?
>
> Good point. Any suggestion on where to document this?

+1 since my gmail-search-foo was not up to the task - we have so many
threads regarding compiler and Qt versions, it is borderline funny.

It could go alongside compiler reqs:

https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11

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

Re: Raising Qt requirement to Qt 5.4

[Mark Gaiser]

On Fri, Mar 25, 2016 at 9:37 AM, David Faure  wrote:

> On Thursday 24 March 2016 23:14:36 Albert Astals Cid wrote:
> > El diumenge, 20 de març de 2016, a les 10:12:14 CET, David Faure va
> escriure:
> > > On Friday 18 March 2016 20:16:05 Ivan Čukić wrote:
> > > > Hi all,
> > > >
> > > > IIRC, the last time we talked about this we decided (I'll try to find
> > > > the e-mail thread when I get back home, IIRC the conclusion was by
> > > > dfaure) on KF5 always support the two last versions of Qt. This was
> > > > decided so that we do not need to have threads like these every time
> > > > we want to increase the Qt version.
> > >
> > > *Three* last versions.
> > >
> > > Which is why we can drop 5.3 now that 5.6 is out
> > >  => we support 5.4, 5.5 and 5.6.
> >
> > Is this documented in some wiki so we don't have to rely on people's
> memories
> > or someone digging up the corresponding email thread?
>
> Good point. Any suggestion on where to document this?
>
>
Having at least a note about that on the main frameworks API page [1] would
be nice to have.
But if that's "the" page to document this.. I don't know.

[1] http://api.kde.org/frameworks-api/frameworks5-apidocs/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Raising Qt requirement to Qt 5.4

[David Faure]

On Thursday 24 March 2016 23:14:36 Albert Astals Cid wrote:
> El diumenge, 20 de març de 2016, a les 10:12:14 CET, David Faure va escriure:
> > On Friday 18 March 2016 20:16:05 Ivan Čukić wrote:
> > > Hi all,
> > > 
> > > IIRC, the last time we talked about this we decided (I'll try to find
> > > the e-mail thread when I get back home, IIRC the conclusion was by
> > > dfaure) on KF5 always support the two last versions of Qt. This was
> > > decided so that we do not need to have threads like these every time
> > > we want to increase the Qt version.
> > 
> > *Three* last versions.
> > 
> > Which is why we can drop 5.3 now that 5.6 is out
> >  => we support 5.4, 5.5 and 5.6.
> 
> Is this documented in some wiki so we don't have to rely on people's memories 
> or someone digging up the corresponding email thread?

Good point. Any suggestion on where to document this?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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