Review Request 126039: When configfile is loaded from resource, do not issue file not found error

[Andrew McCann]

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

Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

When configfile is loaded from resource, do not issue file not found error.

Encountered this problem while attempting to make KDevelop work on OSX as an 
app bundle.

Concretely, the logic error here is that the file actually is loaded and is 
aborting early. 

If the file were actually not found, the following code block that tests for 
validity will error anyway.


Diffs
-

  src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 

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


Testing
---

Verify that loading configfile from qt5's resource system ex 
":/kconfig/test.knsrc" now works and didn't before.


Thanks,

Andrew McCann

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

Review Request 126038: Add protocol info to KIO plugin metadata

[Andrew McCann]

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

Review request for KDE Frameworks.


Repository: kio


Description
---

Add protocol info to KIO plugin metadata.  This is necessary to get KDevelop to 
work on OSX in an app bundle.

This continues work done by Christoph Cullmann in 
https://git.reviewboard.kde.org/r/125830/

Followed the same pattern as the aforementioned diff.

protocol.json files were generated using the protocoltojson utility.


Diffs
-

  src/ioslaves/file/file.cpp 381e4885bf0e78ceb4b06f1f1657ad4068923a84 
  src/ioslaves/file/file.json PRE-CREATION 
  src/ioslaves/ftp/ftp.cpp 2179179e966d97ce24784292ef67812fa1d3361d 
  src/ioslaves/ftp/ftp.json PRE-CREATION 
  src/ioslaves/help/ghelp.json PRE-CREATION 
  src/ioslaves/help/help.json PRE-CREATION 
  src/ioslaves/help/main.cpp 9939196b4fc4aefd52c2c13717609181429fe891 
  src/ioslaves/help/main_ghelp.cpp 59c85587af5edf767261a6b3ca66e6f37efecd29 
  src/ioslaves/trash/kio_trash.cpp 81cc0361d22606f54d31e6ce743cd5fe818a4701 
  src/ioslaves/trash/kio_trash_win.cpp 9dd857f3dd9aebaef9e8d9e5adfc30adb0c1ae6b 
  src/ioslaves/trash/trash.json PRE-CREATION 

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


Testing
---

With this patch applied, my development version of kdevelop on OSX was able to 
find:
(logging statements were added by me, but not in this diff)

```
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/file.so"
   protocol contains  "file"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/ftp.so"
   protocol contains  "ftp"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/ghelp.so"
   protocol contains  "ghelp"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/help.so"
   protocol contains  "help"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/http.so"
   protocol contains  "http"
   protocol contains  "https"
   protocol contains  "webdav"
   protocol contains  "webdavs"
}
{ Found Plugin path  
"/Users/mccann/src/kde_playground/kdevelop_bundle_dest/Applications/kdevelop.app/Contents/PlugIns/kf5/kio/trash.so"
   protocol contains  "trash"
}
```


Thanks,

Andrew McCann

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

Re: Frameworks API documentation broken

[Alex Merry]

On 2015-11-11 14:15, Allen Winter wrote:

On Wednesday, November 11, 2015 08:13:17 AM Allen Winter wrote:

On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote:
> Hi all,
>
> I just wanted to raise awareness of the fact that the Frameworks API
> documentation on api.kde.org is completely broken. Currently one only gets
> error 404 when clicking on the framework links and also in the search I cannot
> find e.g. the frameworks variant of KAboutData.
>
I see the dox generation script is failing almost immediately.
I'll investigate.


The kgenframeworksapidox python program from kapidox is hitting an
exception in breeze-icons.
I forwarded the Traceback to Alex.


It couldn't cope with breeze-icons' metainfo.yaml not specifying any 
library names. I've made it more robust against metainfo.yaml oddities 
now.


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

[kapidox] src: Make kgenframeworksapidox more robust.

[Alex Merry]

Git commit 13a58615d0d49709345cc4dca8eef41b991dd2a2 by Alex Merry.
Committed on 11/11/2015 at 23:51.
Pushed by alexmerry into branch 'master'.

Make kgenframeworksapidox more robust.

It should be harder to break it with unusual or broken metainfo.yaml
files now.

CCMAIL: allen.d.win...@gmail.com
CCMAIL: kde-frameworks-devel@kde.org

M  +1-1src/kapidox/data/templates/fwinfo.html
M  +21   -11   src/kgenframeworksapidox

http://commits.kde.org/kapidox/13a58615d0d49709345cc4dca8eef41b991dd2a2

diff --git a/src/kapidox/data/templates/fwinfo.html 
b/src/kapidox/data/templates/fwinfo.html
index 8e6dfdf..a8f263d 100644
--- a/src/kapidox/data/templates/fwinfo.html
+++ b/src/kapidox/data/templates/fwinfo.html
@@ -37,7 +37,7 @@
   IRC channel: {{ fwinfo.irc|default("#kde-devel") }} on Freenode
   https://mail.kde.org/mailman/listinfo/{{ 
fwinfo.mailinglist|default("kde-frameworks-devel") }}">Mailing list
 
-{% if fwinfo.libraries|count != 0 %}
+{% if fwinfo.libraries is iterable and fwinfo.libraries|count != 0 %}
 Use with https://techbase.kde.org/Development/Tutorials/CMake";>CMake
   find_package({{ fwinfo.cmakename }})
 target_link_libraries(yourapp{% for lib in fwinfo.libraries %} {{ lib.cmake 
}}{% endfor %})
diff --git a/src/kgenframeworksapidox b/src/kgenframeworksapidox
index 47d0f07..714fc77 100755
--- a/src/kgenframeworksapidox
+++ b/src/kgenframeworksapidox
@@ -102,14 +102,13 @@ def process_toplevel_html_file(outputfile, doxdatadir, 
tiers, title,
 # Extend framework info
 fw['href'] = fw['outputdir'] + '/html/index.html'
 
-# Fix broken frameworks lacking platform definitions
-if fw['platforms'] is None:
-logging.warning('{} framework lacks platform 
definitions'.format(fw['fancyname']))
+try:
+platform_lst = [x['name'] for x in fw['platforms'] if 
x['name'] not in (PLATFORM_ALL, PLATFORM_UNKNOWN)]
+available_platforms.update(set(platform_lst))
+except (KeyError, TypeError):
+logging.warning('{} framework lacks valid platform 
definitions'.format(fw['fancyname']))
 fw['platforms'] = [dict(name=PLATFORM_UNKNOWN)]
 
-platform_lst = [x['name'] for x in fw['platforms'] if x['name'] 
not in (PLATFORM_ALL, PLATFORM_UNKNOWN)]
-available_platforms.update(set(platform_lst))
-
 lst.append(fw)
 
 lst.sort(key=lambda x: x['fancyname'].lower())
@@ -222,16 +221,27 @@ def create_fw_info(frameworksdir, modulename, 
maintainers):
 outputdir = modulename
 
 # FIXME: option in yaml file to disable docs
-metainfo = yaml.load(open(yaml_file))
-tier = metainfo["tier"]
+try:
+metainfo = yaml.load(open(yaml_file))
+except:
+logging.warning('Could not load metainfo.yaml for {}, skipping 
it'.format(modulename))
+return None
+
+if metainfo is None:
+logging.warning('Empty metainfo.yaml for {}, skipping 
it'.format(modulename))
+return None
+
+tier = metainfo.get("tier")
 if tier is None:
-logging.warning('Could not find tier for {}'.format(framework))
+logging.warning('Could not find tier for {}, skipping 
it'.format(modulename))
 return None
 elif tier < 1 or tier > 4:
-logging.warning('Invalid tier {} for {}'.format(tier, framework))
+logging.warning('Invalid tier {} for {}, skipping it'.format(tier, 
modulename))
 return None
 
-if isinstance(metainfo['maintainer'],list):
+if 'maintainer' not in metainfo:
+fw_maintainers = []
+elif isinstance(metainfo['maintainer'],list):
 fw_maintainers = map(lambda x: maintainers.get(x, None),
  metainfo['maintainer'])
 else:
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[René J . V . Bertin]

On Wednesday November 11 2015 20:37:36 Petroules Jake wrote:

> What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so 
> we could have a little more fine grained control. Maybe a user WANTS to write 
> to locations in the local domain instead of the user domain (and in some 
> cases, you DO -- like Applications).

I'm not sure if writing to /Applications is the best use case example. We'd be 
talking about some sort of application manager I suppose, and wouldn't that be 
the kind of application that's so specific that you'd prefer to avoid 
"precooked" functions to determine destination paths? (On OS X you'd probably 
want to make the destination a setting, even.)

Anyway, if and when you start thinking about that kind of modification, maybe 
we could re-open the discussion about a way to get QSP to return XDG-compliant 
locations?

R.

PS Jake: your emails make no distinction between quoted text and your replies 
in plain-text representation.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[Petroules Jake]

On Nov 11, 2015, at 12:21 PM, David Faure mailto:fa...@kde.org>> 
wrote:

On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote:
Feel free to do whatever you like for test mode but do not change the existing 
writable paths.

Jake, I would like to understand why you say that. As the QSP author and 
maintainer,
I am 100% sure that the value of writableLocation(x) should be under $HOME.

Spot the wrong value in this list of results:

Writable locations:

AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/Library/Application Support/qtpaths
AppLocalDataLocation = $HOME/Library/Application Support/qtpaths
ApplicationsLocation = /Applications
CacheLocation = $HOME/Library/Caches/qtpaths
ConfigLocation = $HOME/Library/Preferences
DataLocation = $HOME/Library/Application Support/qtpaths
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts
GenericCacheLocation = $HOME/Library/Caches
GenericConfigLocation = $HOME/Library/Preferences
GenericDataLocation = $HOME/Library/Application Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

This is a bug, it was never intended for writableLocation to return a 
system-wide path.

I can imagine that there is actually no use case for users writing into an
ApplicationsLocation under $HOME on OSX (KDE code excluded).
But in that case making the value more consistent with the other ones can't 
possibly hurt.

Yes, I can agree with that -- it's completely useless to anyone, but 
consistent. Also, I was mistaken -- writableDirectory does indeed return 
$HOME/Applications now with my patch as everything is routed through the same 
mechanism (using NSUserDomainMask).

What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so we 
could have a little more fine grained control. Maybe a user WANTS to write to 
locations in the local domain instead of the user domain (and in some cases, 
you DO -- like Applications).


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


--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company, Inc.

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[David Faure]

On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote:
> Feel free to do whatever you like for test mode but do not change the 
> existing writable paths.

Jake, I would like to understand why you say that. As the QSP author and 
maintainer,
I am 100% sure that the value of writableLocation(x) should be under $HOME.

Spot the wrong value in this list of results:

Writable locations:

AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/Library/Application Support/qtpaths
AppLocalDataLocation = $HOME/Library/Application Support/qtpaths
ApplicationsLocation = /Applications
CacheLocation = $HOME/Library/Caches/qtpaths
ConfigLocation = $HOME/Library/Preferences
DataLocation = $HOME/Library/Application Support/qtpaths
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts
GenericCacheLocation = $HOME/Library/Caches
GenericConfigLocation = $HOME/Library/Preferences
GenericDataLocation = $HOME/Library/Application Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

This is a bug, it was never intended for writableLocation to return a 
system-wide path.

I can imagine that there is actually no use case for users writing into an
ApplicationsLocation under $HOME on OSX (KDE code excluded).
But in that case making the value more consistent with the other ones can't 
possibly hurt.

-- 
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 125951: [calendar] Move the plugins handling to a separate class

[Martin Klapetek]

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

(Updated Nov. 11, 2015, 8:54 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Restructured things a bit
* it now ensures that the applet config is not actually loading the plugins, it 
operates only on the metadata
* the list of enabled plugins is now stored per applet in 
plasmoid.configuration.enabledCalendarPlugins (this is the applet code though 
so that's another patch)

Enabling and disabling the plugins now work correctly including adding/removing 
the events from the calendar.


Repository: plasma-framework


Description
---

This is also made a QML singleton that will be used for the applet
config view where it will add the plugin configs once we add that
possibility.

The same instance is then set to the DaysModel from QML.

(this depends on https://git.reviewboard.kde.org/r/125817/ which awaits ship it)


Diffs (updated)
-

  src/declarativeimports/calendar/qml/MonthView.qml 
f698934f850ef3a917b9611c9f9a40c369b23f6c 
  src/declarativeimports/calendar/eventpluginsmanager.cpp PRE-CREATION 
  src/declarativeimports/calendar/daysmodel.h 
a5bdac98627f7efa76bd4afd239469b53e06690b 
  src/declarativeimports/calendar/CMakeLists.txt 
40ead911ad5208cae5dbe5333d227f9f8a0d9154 
  src/declarativeimports/calendar/calendarplugin.cpp 
bafe80cf7520a08312abfd1dbd6d4648a6710175 
  src/declarativeimports/calendar/eventpluginsmanager.h PRE-CREATION 
  src/declarativeimports/calendar/daysmodel.cpp 
2d059a8e8636565adbe52811e602fff37a5eb157 

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


Testing
---

Calendar events are still correctly displayed


Thanks,

Martin Klapetek

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

Re: Review Request 125936: Update KProtocolManager after configuration change.

[Andreas Cord-Landwehr]

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

(Updated Nov. 11, 2015, 7:30 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit fd93de164f46d4e81f8bfdc4625b61bbd318ea1e by Andreas 
Cord-Landwehr to branch master.


Repository: kio


Description
---

Fixes missing update of Settings->Cache KCM that happens if opening
KCM, changing values (e.g., "No Cache"), closing Cache KCM, opening Cache
KCM again.

Reason is that storing and loading of UI values is performed
asymmetrically in two different KSharedConfig objects. Now force second
KSharedData to sync once settings are saved.


Diffs
-

  src/kcms/kio/cache.cpp 8f2f4e8 

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


Testing
---

manual testing


Thanks,

Andreas Cord-Landwehr

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[Petroules Jake]

On Nov 11, 2015, at 8:20 AM, René J.V. Bertin 
mailto:rjvber...@gmail.com>> wrote:

On Wednesday November 11 2015 16:03:31 Petroules Jake wrote:

I don't understand, what do you mean with "there is only one location"?

I mean the API returns a single value, not a list. However, READable locations 
will return a list containing both $HOME/Applications and /Applications

Ah. I hadn't even considered returning a list, just returning 
$HOME/Applications - at least when not running with elevated privileges.

As to what users expect: has there been a poll or other evaluation of whether 
people actually have an expectation about what the writable 
ApplicationsLocation should be? It seems that given the nature of the location 
on OS X, there is more reason not to use the writable variant than there is to 
use it. It seems rather evident that applications ported from the Freedesktop 
universe shouldn't use ApplicationsLocation to install or search for .desktop 
files, for instance.

.desktop files are not used on OS X.

One could maybe even argue that the only relevant location would be 
ApplicationLocation (without the 's'), which would translate to the parent of 
the running application's app bundle (which would be /Applications for 
applications installed via the App Store). As I said, app bundles are supposed 
to be relocatable, and /Applications is just where Apple decided to put them by 
default.

5.7 I think. https://codereview.qt-project.org/#/c/122044/

Time enough to incorporate a patch for 5.5.1+ and 5.6 , or do you prefer to 
wait until someone messes up /System/Library/Fonts by accident like I did with 
/Applications? ;)

On 10.11 you can't - SIP will block writes to /System. ;)

Feel free to do whatever you like for test mode but do not change the existing 
writable paths.

R

--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company, Inc.

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[René J . V . Bertin]

On Wednesday November 11 2015 19:07:17 David Faure wrote:

> Yes, and the value returned by writableLocation() is supposed to be 
> user-specific
> (something under $HOME) rather than system-wide.

Agreed.

> 
> So /Applications should be in QSP::standardLocations(ApplicationsLocation)
> but QSP::writableLocation(ApplicationsLocation) should return something under
> $HOME, like on XDG unixes (where it's ~/.local/share/applications).

Ah, so apparently it really should be ".../share/applications" when QSP is in 
XDG-compliant mode.
Back to the drawing board :)

Anyway, here's the list of all locations, standard and writable, regular and 
testing, native and XDG-compliant.
I'd appreciate extra pairs of eyes to check for inconsistencies or errors.


Standard locations:

AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/Library/Application 
Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/
AppLocalDataLocation = $HOME/Library/Application 
Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/
ApplicationsLocation = /Applications
CacheLocation = $HOME/Library/Caches/qtpaths:/Library/Caches/qtpaths
ConfigLocation = $HOME/Library/Preferences
DataLocation = $HOME/Library/Application Support/qtpaths:/Library/Application 
Support/qtpaths:/opt/local/libexec/qt5/bin/
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts
GenericCacheLocation = $HOME/Library/Caches:/Library/Caches
GenericConfigLocation = $HOME/Library/Preferences
GenericDataLocation = $HOME/Library/Application Support:/Library/Application 
Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

Standard locations, testing mode:

AppConfigLocation = $HOME/.qttest/Preferences/qtpaths
AppDataLocation = $HOME/.qttest/Application 
Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/
AppLocalDataLocation = $HOME/.qttest/Application 
Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/
ApplicationsLocation = /Applications
CacheLocation = $HOME/.qttest/Cache/qtpaths:/Library/Caches/qtpaths
ConfigLocation = $HOME/.qttest/Preferences
DataLocation = $HOME/.qttest/Application Support/qtpaths:/Library/Application 
Support/qtpaths:/opt/local/libexec/qt5/bin/
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts
GenericCacheLocation = $HOME/.qttest/Cache:/Library/Caches
GenericConfigLocation = $HOME/.qttest/Preferences
GenericDataLocation = $HOME/.qttest/Application Support:/Library/Application 
Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

Writable locations:

AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/Library/Application Support/qtpaths
AppLocalDataLocation = $HOME/Library/Application Support/qtpaths
ApplicationsLocation = /Applications
CacheLocation = $HOME/Library/Caches/qtpaths
ConfigLocation = $HOME/Library/Preferences
DataLocation = $HOME/Library/Application Support/qtpaths
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts
GenericCacheLocation = $HOME/Library/Caches
GenericConfigLocation = $HOME/Library/Preferences
GenericDataLocation = $HOME/Library/Application Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

Writable locations, testing mode:

AppConfigLocation = $HOME/.qttest/Preferences/qtpaths
AppDataLocation = $HOME/.qttest/Application Support/qtpaths
AppLocalDataLocation = $HOME/.qttest/Application Support/qtpaths
ApplicationsLocation = /Applications
CacheLocation = $HOME/.qttest/Cache/qtpaths
ConfigLocation = $HOME/.qttest/Preferences
DataLocation = $HOME/.qttest/Application Support/qtpaths
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts
GenericCacheLocation = $HOME/.qttest/Cache
GenericConfigLocation = $HOME/.qttest/Preferences
GenericDataLocation = $HOME/.qttest/Application Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR

Standard locations, XDG/Freedesktop compliant mode:

AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/.local/share/qtpaths:/Library/Applica

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[David Faure]

On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote:
> I mean the API returns a single value, not a list. 

Yes, and the value returned by writableLocation() is supposed to be 
user-specific
(something under $HOME) rather than system-wide.

So /Applications should be in QSP::standardLocations(ApplicationsLocation)
but QSP::writableLocation(ApplicationsLocation) should return something under
$HOME, like on XDG unixes (where it's ~/.local/share/applications).

-- 
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: [Development] QStandardPaths::writableLocation() on OSX in test mode

[Petroules Jake]

On Nov 11, 2015, at 7:13 AM, René J.V. Bertin 
mailto:rjvber...@gmail.com>> wrote:

On Wednesday November 11 2015 15:52:33 David Faure wrote:

Cross-posting on Qt's development ML because it seems more than relevant there. 
To put things in context: this discussion on kde-frameworks-devel was started 
because an autotest from KService deleted a good chunk from my /Applications 
directory before I killed it (it'd have deleted the whole folder if I'd been 
running an SSD).

*writableLocation* returns /Applications ? How is that possible?

Yes. It cannot be otherwise as you've probably seen making the patch below, but 
I can understand the choice. OTOH, app bundles can be anywhere on OS X (as long 
as you use LaunchServices), so it'd be just as fine to set the writable 
location to $HOME/Applications. You might consider that for your patch.

No, there is only one location so it must remain /Applications as expected by 
anyone on the OS X platform.

Another thing that occurs to me: ApplicationsLocation doesn't hold the actual 
applications on Linux. Are QstandardPaths locations allowed to have different 
interpretations (and implications) like that, across platforms?

Please test this patch before I submit it to gerrit:


diff --git a/src/corelib/io/qstandardpaths_mac.mm 
b/src/corelib/io/qstandardpaths_mac.mm
index d6126ce..8e030ae 100644
--- a/src/corelib/io/qstandardpaths_mac.mm
+++ b/src/corelib/io/qstandardpaths_mac.mm
@@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation 
type)
if (type == AppConfigLocation)
appendOrganizationAndApp(path);
return path;
+case ApplicationsLocation:
+path = qttestDir + QLatin1String("/Applications");
+return path;
default:
break;
}

That looks like what I would certainly have come up with. Will test it, but as 
I just posted, we'll probably want to verify certain other locations as well. 
And you'll probably want to include my fix to the FontsLocation which omitted 
/Library/Fonts and considered /System/Library/Fonts to be writable ...

--- a/qtbase/src/corelib/io/qstandardpaths_mac.mm
+++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm
@@ -178,6 +178,8 @@
case GenericCacheLocation:
case CacheLocation:
case RuntimeLocation:
+case FontsLocation:
+// the font location that is writable for all users is ~/Library/Fonts
return macLocation(type, kUserDomain);
default:
return macLocation(type, kOnAppropriateDisk);
@@ -218,6 +220,12 @@
dirs.append(bundlePath + resourcesPath);
}
}
+if (type == FontsLocation) {
+// /Library/Fonts
+dirs.append(macLocation(type,kLocalDomain));
+// /System/Library/Fonts
+dirs.append(macLocation(type,kSystemDomain));
+}
const QString localDir = writableLocation(type);
dirs.prepend(localDir);
return dirs;

That won't apply, I refactored QSP recently in dev branch to drop the 
dependency on deprecated Carbon APIs. That font dirs problem should be fixed 
already, however.

I'll be reporting this to Qt, of course.
That seems premature, due to you having your own patch on top of QSP.

My own patch does nothing when XDG mode isn't activated (and that particular 
aspect works, as does the activation stuff). And of course I'd submit a patch 
that doesn't include any XDG modifications.

R.
___
Development mailing list
developm...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company, Inc.

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

Re: Frameworks API documentation broken

[Allen Winter]

On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote:
> Hi all,
> 
> I just wanted to raise awareness of the fact that the Frameworks API 
> documentation on api.kde.org is completely broken. Currently one only gets 
> error 404 when clicking on the framework links and also in the search I 
> cannot 
> find e.g. the frameworks variant of KAboutData.
> 
I see the dox generation script is failing almost immediately.
I'll investigate.

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[Petroules Jake]

On Nov 11, 2015, at 7:53 AM, René J.V. Bertin 
mailto:rjvber...@gmail.com>> wrote:

On Wednesday November 11 2015 15:32:20 Petroules Jake wrote:

No, there is only one location so it must remain /Applications as expected by 
anyone on the OS X platform.

I don't understand, what do you mean with "there is only one location"?

I mean the API returns a single value, not a list. However, READable locations 
will return a list containing both $HOME/Applications and /Applications

It is also expected that regular users do not have write permissions in 
/Applications or similar system locations, so some compromise must be found 
IMHO.

That won't apply, I refactored QSP recently in dev branch to drop the 
dependency on deprecated Carbon APIs. That font dirs problem should be fixed 
already, however.

It still applies in 5.5.0 . In what version is that refactored code expected to 
land? The next 5.5 release already?

5.7 I think. https://codereview.qt-project.org/#/c/122044/

R.

--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company, Inc.

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

Re: KService autotests and tests on OS X

[René J . V . Bertin]

On Wednesday November 11 2015 15:49:23 David Faure wrote:

> Do you also install desktop files for apps in there? Why not. That's not the 
> issue anyway.

I have only been installing frameworks until now, so the answer is "I don't 
know". If .desktop files are installed to ApplicationsLocation by default, I'd 
expect them to show up in /Applications if I don't modify QSP ...

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[René J . V . Bertin]

On Wednesday November 11 2015 16:03:31 Petroules Jake wrote:

>I don't understand, what do you mean with "there is only one location"?
>
>I mean the API returns a single value, not a list. However, READable locations 
>will return a list containing both $HOME/Applications and /Applications

Ah. I hadn't even considered returning a list, just returning 
$HOME/Applications - at least when not running with elevated privileges.

As to what users expect: has there been a poll or other evaluation of whether 
people actually have an expectation about what the writable 
ApplicationsLocation should be? It seems that given the nature of the location 
on OS X, there is more reason not to use the writable variant than there is to 
use it. It seems rather evident that applications ported from the Freedesktop 
universe shouldn't use ApplicationsLocation to install or search for .desktop 
files, for instance.
One could maybe even argue that the only relevant location would be 
ApplicationLocation (without the 's'), which would translate to the parent of 
the running application's app bundle (which would be /Applications for 
applications installed via the App Store). As I said, app bundles are supposed 
to be relocatable, and /Applications is just where Apple decided to put them by 
default.

>5.7 I think. https://codereview.qt-project.org/#/c/122044/

Time enough to incorporate a patch for 5.5.1+ and 5.6 , or do you prefer to 
wait until someone messes up /System/Library/Fonts by accident like I did with 
/Applications? ;)

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

Re: KService autotests and tests on OS X

[René J . V . Bertin]

On Wednesday November 11 2015 15:49:23 David Faure wrote:

>> Related question: is there interplay between QSP::ApplicationsLocation and 
>> the CMake BUNDLE_INSTALL_DIR variable? Following MacPorts convention I'm 
>> installing pure Qt5 app bundles into /Applications/MacPorts/Qt5, KDE4 app 
>> bundles go into /Applications/MacPorts/KDE4 and KF5 one go into 
>> /Applications/MacPorts/KF5 .
>
>They both point to /Applications, that's about all the interplay there is.

Do you think anything will break if they do not point to the same location?

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

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

[René J . V . Bertin]

On Wednesday November 11 2015 15:32:20 Petroules Jake wrote:

>No, there is only one location so it must remain /Applications as expected by 
>anyone on the OS X platform.

I don't understand, what do you mean with "there is only one location"?

It is also expected that regular users do not have write permissions in 
/Applications or similar system locations, so some compromise must be found 
IMHO.

>That won't apply, I refactored QSP recently in dev branch to drop the 
>dependency on deprecated Carbon APIs. That font dirs problem should be fixed 
>already, however.

It still applies in 5.5.0 . In what version is that refactored code expected to 
land? The next 5.5 release already?

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

Re: QStandardPaths::writableLocation() on OSX in test mode

[René J . V . Bertin]

On Wednesday November 11 2015 15:52:33 David Faure wrote:

Cross-posting on Qt's development ML because it seems more than relevant there. 
To put things in context: this discussion on kde-frameworks-devel was started 
because an autotest from KService deleted a good chunk from my /Applications 
directory before I killed it (it'd have deleted the whole folder if I'd been 
running an SSD).

> *writableLocation* returns /Applications ? How is that possible?

Yes. It cannot be otherwise as you've probably seen making the patch below, but 
I can understand the choice. OTOH, app bundles can be anywhere on OS X (as long 
as you use LaunchServices), so it'd be just as fine to set the writable 
location to $HOME/Applications. You might consider that for your patch.

Another thing that occurs to me: ApplicationsLocation doesn't hold the actual 
applications on Linux. Are QstandardPaths locations allowed to have different 
interpretations (and implications) like that, across platforms?

> Please test this patch before I submit it to gerrit:
> 
> 
> diff --git a/src/corelib/io/qstandardpaths_mac.mm 
> b/src/corelib/io/qstandardpaths_mac.mm
> index d6126ce..8e030ae 100644
> --- a/src/corelib/io/qstandardpaths_mac.mm
> +++ b/src/corelib/io/qstandardpaths_mac.mm
> @@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation 
> type)
>  if (type == AppConfigLocation)
>  appendOrganizationAndApp(path);
>  return path;
> +case ApplicationsLocation:
> +path = qttestDir + QLatin1String("/Applications");
> +return path;
>  default:
>  break;
>  }

That looks like what I would certainly have come up with. Will test it, but as 
I just posted, we'll probably want to verify certain other locations as well. 
And you'll probably want to include my fix to the FontsLocation which omitted 
/Library/Fonts and considered /System/Library/Fonts to be writable ...

--- a/qtbase/src/corelib/io/qstandardpaths_mac.mm
+++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm
@@ -178,6 +178,8 @@
 case GenericCacheLocation:
 case CacheLocation:
 case RuntimeLocation:
+case FontsLocation:
+// the font location that is writable for all users is ~/Library/Fonts
 return macLocation(type, kUserDomain);
 default:
 return macLocation(type, kOnAppropriateDisk);
@@ -218,6 +220,12 @@
 dirs.append(bundlePath + resourcesPath);
 }
 }
+if (type == FontsLocation) {
+// /Library/Fonts
+dirs.append(macLocation(type,kLocalDomain));
+// /System/Library/Fonts
+dirs.append(macLocation(type,kSystemDomain));
+}
 const QString localDir = writableLocation(type);
 dirs.prepend(localDir);
 return dirs;

> > I'll be reporting this to Qt, of course.
> That seems premature, due to you having your own patch on top of QSP.

My own patch does nothing when XDG mode isn't activated (and that particular 
aspect works, as does the activation stuff). And of course I'd submit a patch 
that doesn't include any XDG modifications.

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

Re: KService autotests and tests on OS X

[René J . V . Bertin]

I'll make and upload a list of all QSP locations on OS X, native and in XDG 
mode, regular and in test mode, for verification purposes. The results of that 
can go into a bug report and code review for QSP (and my own QSP patch).


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

QStandardPaths::writableLocation() on OSX in test mode

[David Faure]

On Wednesday 11 November 2015 15:45:49 René J.V. Bertin wrote:
> On Wednesday November 11 2015 14:49:57 David Faure wrote:
> 
> > qstandardpaths_mac.mm says
> > QString QStandardPaths::writableLocation(StandardLocation type)
> > {
> > if (isTestModeEnabled()) {
> > const QString qttestDir = QDir::homePath() + 
> > QLatin1String("/.qttest");
> > QString path;
> > switch (type) {
> > case GenericDataLocation:
> > case AppDataLocation:
> > case AppLocalDataLocation:
> > path = qttestDir + QLatin1String("/Application Support");
> > if (type != GenericDataLocation)
> > appendOrganizationAndApp(path);
> > return path;
> 
> That's not ApplicationsLocation. That one only appears in translateLocation 
> and doesn't get any specific treatment otherwise.

Ah my bad, read too fast. Whoops.

Please test this patch before I submit it to gerrit:


diff --git a/src/corelib/io/qstandardpaths_mac.mm 
b/src/corelib/io/qstandardpaths_mac.mm
index d6126ce..8e030ae 100644
--- a/src/corelib/io/qstandardpaths_mac.mm
+++ b/src/corelib/io/qstandardpaths_mac.mm
@@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation 
type)
 if (type == AppConfigLocation)
 appendOrganizationAndApp(path);
 return path;
+case ApplicationsLocation:
+path = qttestDir + QLatin1String("/Applications");
+return path;
 default:
 break;
 }

-- 
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: KService autotests and tests on OS X

[David Faure]

On Wednesday 11 November 2015 15:42:37 René J.V. Bertin wrote:
> 
> I had to patch qtpaths to test this easily without digging through source 
> code: it indeed returns just /Applications .

*writableLocation* returns /Applications ? How is that possible? 

Are you 100% sure you're talking about QSP::writableLocation, and not 
QSP::standardLocations?

> And of course I'll be re-checking my QSP patch

Yes, you should do that, because see the code I posted in the other email, 
upstream QSP cannot possibly return
"/Applications" from QSP::writableLocation().

> I'll be reporting this to Qt, of course.

That seems premature, due to you having your own patch on top of QSP.

> Related question: is there interplay between QSP::ApplicationsLocation and 
> the CMake BUNDLE_INSTALL_DIR variable? Following MacPorts convention I'm 
> installing pure Qt5 app bundles into /Applications/MacPorts/Qt5, KDE4 app 
> bundles go into /Applications/MacPorts/KDE4 and KF5 one go into 
> /Applications/MacPorts/KF5 .

They both point to /Applications, that's about all the interplay there is.

> Or maybe I should ask what QSP::ApplicationsLocation is used for. I guess 
> KService uses it to search for .desktop and/or .service files or their 
> equivalent.

Yes - only .desktop files.

.service is for DBus, and goes elsewhere.

> Nothing like that has yet been installed into /Applications, but my service 
> files appear to end up in /opt/local/share/kservices5, does that sound about 
> right?

Yes, desktop files for plugins typically go there.
Do you also install desktop files for apps in there? Why not. That's not the 
issue anyway.

-- 
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: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

[René J . V . Bertin]

On Wednesday November 11 2015 14:49:57 David Faure wrote:

> qstandardpaths_mac.mm says
> QString QStandardPaths::writableLocation(StandardLocation type)
> {
> if (isTestModeEnabled()) {
> const QString qttestDir = QDir::homePath() + 
> QLatin1String("/.qttest");
> QString path;
> switch (type) {
> case GenericDataLocation:
> case AppDataLocation:
> case AppLocalDataLocation:
> path = qttestDir + QLatin1String("/Application Support");
> if (type != GenericDataLocation)
> appendOrganizationAndApp(path);
> return path;

That's not ApplicationsLocation. That one only appears in translateLocation and 
doesn't get any specific treatment otherwise.

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

Re: KService autotests and tests on OS X

[René J . V . Bertin]

On Wednesday November 11 2015 14:47:03 David Faure wrote:

> > 2) I discovered, some time after having attempted to run these, that a 
> > large number of the app bundles under /Applications HAD GONE MISSING.
> 
> Oops!?!

That's a diluted version of my own reaction, yesterday at about 23h ...

> kmimeassociationstest does
>   QStandardPaths::enableTestMode(true);
>   then calls 
> QStandardPaths::writableLocation(QStandardPaths::ApplicationsLocation)
>   and deletes all of it.

Yeah, I found that after searching ApplicationsLocation ... *after* restoring 
my /Applications directory.

> On a Linux system that's ~/.qttest/share/applications
> What does this return on OSX?

I had to patch qtpaths to test this easily without digging through source code: 
it indeed returns just /Applications .
I'll be reporting this to Qt, of course.

And of course I'll be re-checking my QSP patch, because it should probably make 
QSP::ApplicationsLocation return share/applications like on Linux, or at least 
whatever Qt is configured to use for the app bundles it installs.

Related question: is there interplay between QSP::ApplicationsLocation and the 
CMake BUNDLE_INSTALL_DIR variable? Following MacPorts convention I'm installing 
pure Qt5 app bundles into /Applications/MacPorts/Qt5, KDE4 app bundles go into 
/Applications/MacPorts/KDE4 and KF5 one go into /Applications/MacPorts/KF5 .

Or maybe I should ask what QSP::ApplicationsLocation is used for. I guess 
KService uses it to search for .desktop and/or .service files or their 
equivalent. Nothing like that has yet been installed into /Applications, but my 
service files appear to end up in /opt/local/share/kservices5, does that sound 
about right?

> It does the same with GenericConfigLocation and CacheLocation, btw.

As far as I can see those follow XDG specs with my QSP patch, and respect 
testMode even with the native QSP.

> AFAICS QSP also uses ~/.qttest on OSX, that's where this should all have 
> happened,
> not in a global dir.

Clearly not for all locations, I'll have to check which other ones are affected.

> ksycocatest.cpp also does some recursive deletion of dirs, but they are more
> specific, like 
> QStandardPaths::writableLocation(QStandardPaths::GenericDataLocation) + 
> "/kservices5",
> so that can't be it.

No, that one's well-behaved too.

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

Re: Frameworks API documentation broken

[Allen Winter]

On Wednesday, November 11, 2015 08:13:17 AM Allen Winter wrote:
> On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote:
> > Hi all,
> > 
> > I just wanted to raise awareness of the fact that the Frameworks API 
> > documentation on api.kde.org is completely broken. Currently one only gets 
> > error 404 when clicking on the framework links and also in the search I 
> > cannot 
> > find e.g. the frameworks variant of KAboutData.
> > 
> I see the dox generation script is failing almost immediately.
> I'll investigate.
> 
The kgenframeworksapidox python program from kapidox is hitting an exception in 
breeze-icons.
I forwarded the Traceback to Alex.

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

Re: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

[David Faure]

On Wednesday 11 November 2015 13:44:01 René J. V. Bertin wrote:
> Alex Merry wrote:
> 
> > The autotests are supposed to use a special magic test directory for
> > configuration and preferences (see
> > http://doc.qt.io/qt-5/qstandardpaths.html#setTestModeEnabled). So they
> > shouldn't be writing anywhere outside that. If they are, it's a bug
> > (either in the autotests or in Qt).
> 
> David suggested for this particular issue that it might have been the result 
> of 
> an indirect request to the running workspace (which evidently doesn't have 
> QSP 
> nor would it know of an activated testing mode).
> 
> But you're right, my other issue that cost me a big part of the contents of 
> my 
> Mac's /Applications directory is due to the fact that 
> QStandardPaths::ApplicationsLocation doesn't support TestMode on OS X . 

It does, at least in writableLocation() which is the one where testmode matters:

qstandardpaths_mac.mm says
QString QStandardPaths::writableLocation(StandardLocation type)
{
if (isTestModeEnabled()) {
const QString qttestDir = QDir::homePath() + QLatin1String("/.qttest");
QString path;
switch (type) {
case GenericDataLocation:
case AppDataLocation:
case AppLocalDataLocation:
path = qttestDir + QLatin1String("/Application Support");
if (type != GenericDataLocation)
appendOrganizationAndApp(path);
return path;


-- 
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: KService autotests and tests on OS X

[David Faure]

On Wednesday 11 November 2015 00:24:45 René J.V. Bertin wrote:
> Hi,
> 
> Are the autotests and tests of the KService framework supposed to run on OS 
> X? I tried them, and
> 
> 1) most simply hang after printing an error about a missing application menu 
> (I no longer have the exact message)

menus/applications.menu is a file that is expected to be found under one of the 
paths returned by `qtpaths --paths ConfigLocation`.

> 2) I discovered, some time after having attempted to run these, that a large 
> number of the app bundles under /Applications HAD GONE MISSING.

Oops!?!

kmimeassociationstest does
  QStandardPaths::enableTestMode(true);
  then calls 
QStandardPaths::writableLocation(QStandardPaths::ApplicationsLocation)
  and deletes all of it.
On a Linux system that's ~/.qttest/share/applications
What does this return on OSX?

It does the same with GenericConfigLocation and CacheLocation, btw.

AFAICS QSP also uses ~/.qttest on OSX, that's where this should all have 
happened,
not in a global dir.

ksycocatest.cpp also does some recursive deletion of dirs, but they are more
specific, like 
QStandardPaths::writableLocation(QStandardPaths::GenericDataLocation) + 
"/kservices5",
so that can't be it.

-- 
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

Review Request 126028: Add support for desktopFileName to NETWinInfo

[Martin Gräßlin]

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

Review request for KDE Frameworks, kwin and David Faure.


Repository: kwindowsystem


Description
---

Implementation for the new hint _NET_WM_DESKTOP_FILE, see [1].
Till it's fully standardized going with a KDE prefix, so it's
_KDE_NET_WM_DESKTOP_FILE. Once it's specified the atom name can
be exchanged.

[1] https://mail.gnome.org/archives/wm-spec-list/2015-November/msg0.html


Diffs
-

  autotests/netwininfotestclient.cpp 59a3980ff589fc3de9e479905c191bcbf1747644 
  src/netwm_def.h 0938e2b28f6b0d425a16748b52a5b8e4704d8af6 
  src/platforms/xcb/atoms_p.h b5a6e7efc98ff8033c0854041428a7d4b52ffc93 
  src/platforms/xcb/netwm.h 220340bf0e96d2a186b72e118b601471529aeabf 
  src/platforms/xcb/netwm.cpp 2335c297bb627065ca9b7e691290bfbdc64bccc3 
  src/platforms/xcb/netwm_p.h e0645bbfd2c2061d9201fe34160c6201d89f4a89 

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


Testing
---

tested with a modified kcmshell5 and a modified desktop file.


Thanks,

Martin Gräßlin

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

Re: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

[René J . V . Bertin]

Alex Merry wrote:

> The autotests are supposed to use a special magic test directory for
> configuration and preferences (see
> http://doc.qt.io/qt-5/qstandardpaths.html#setTestModeEnabled). So they
> shouldn't be writing anywhere outside that. If they are, it's a bug
> (either in the autotests or in Qt).

David suggested for this particular issue that it might have been the result of 
an indirect request to the running workspace (which evidently doesn't have QSP 
nor would it know of an activated testing mode).

But you're right, my other issue that cost me a big part of the contents of my 
Mac's /Applications directory is due to the fact that 
QStandardPaths::ApplicationsLocation doesn't support TestMode on OS X . 

R.

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

Re: kpackage: reasons not to use ecm_mark_nongui_executable?

[René J . V . Bertin]

Aleix Pol wrote:

> That's what the macro does, nothing more:
> set_target_properties(${_target}
>PROPERTIES
>WIN32_EXECUTABLE FALSE
>MACOSX_BUNDLE FALSE
>  )
> 

Right ... I guess I could have checked that myself, the answer is clear from 
the 
code. Just setting MACOSX_BUNDLE to false doesn't change anything in the 
libraries or runtimes that are linked in (as I guess WIN32_EXECUTABLE->FALSE) 
does. So the resulting executable shouldn't be any less GUI-capable unless the 
project's cmake code checks for the MACOSX_BUNDLE setting.

NB: I experimented with a modification of KDE4's NOGUI property, letting it 
control the GUIEnabled argument of the KApplication or KCoreApplication 
ctor.That works as expected, except that not all applications declared NOGUI 
are 
well-behaved (some at least try to get keystrokes for instance, which arguably 
requires a connection to the system's GUI runtime).

R.

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

Re: Review Request 125936: Update KProtocolManager after configuration change.

[David Faure]

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

Ship it!


OK, that explains it. I was assuming this process would be doing something with 
KIO, but indeed, if it doesn't create any jobs it has no scheduler to receive 
the signal. Patch is correct then, sorry for taking a long time to realize that 
;)

- David Faure


On Nov. 4, 2015, 6:28 a.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125936/
> ---
> 
> (Updated Nov. 4, 2015, 6:28 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Fixes missing update of Settings->Cache KCM that happens if opening
> KCM, changing values (e.g., "No Cache"), closing Cache KCM, opening Cache
> KCM again.
> 
> Reason is that storing and loading of UI values is performed
> asymmetrically in two different KSharedConfig objects. Now force second
> KSharedData to sync once settings are saved.
> 
> 
> Diffs
> -
> 
>   src/kcms/kio/cache.cpp 8f2f4e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125936/diff/
> 
> 
> Testing
> ---
> 
> manual testing
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

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

Re: Review Request 125936: Update KProtocolManager after configuration change.

[Andreas Cord-Landwehr]

> On Nov. 6, 2015, 8:02 a.m., David Faure wrote:
> > src/kcms/kio/cache.cpp, line 91
> > 
> >
> > Isn't this done by the call to updateRunningIOSlaves just below, which 
> > sends the DBus signal "reparseSlaveConfiguration" to all processes with a 
> > KIO scheduler, which, in SchedulerPrivate::slotReparseSlaveConfiguration, 
> > calls KProtocolManager::reparseConfiguration?
> > 
> > Please check why this doesn't happen in your testcase.
> > I can think of a few possibilities:
> > - there's no KIO scheduler in this process
> > - you need this reparsed before going back to the event loop (but from 
> > your description it doesn't seem so)
> > - there's a bug in the emitting or the handling of that dbus signal 
> > (which is why I'm asking, if there is, we might as well find it and fix it).
> 
> Andreas Cord-Landwehr wrote:
> Thanks for the infos. Regarding the even-loop I agree that this cannot be 
> the problem.
> I just tested for the KIO scheduler. With the open KCM dialog I get:
> 
> cordlandwehr@weatherwax:~$ qdbus "org.kde.KIO.Scheduler"
> Service 'org.kde.KIO.Scheduler' does not exist.
> 
> So, I would deduce that no scheduler exists, or do I miss anything?
> 
> David Faure wrote:
> You're confusing dbus service names and dbus interface names.
> You need to call `qdbus  
> /KIO/Scheduler`
> 
> The KIO scheduler is a class in each process that uses KIO, it's not a 
> desktop-wide daemon.

I see. So, the next try:

qdbus org.kde.internal.KSettingsWidget_kcm_kio /KIO/Scheduler
Error: org.freedesktop.DBus.Error.UnknownObject
No such object path '/KIO/Scheduler'

Although I could not find a specific setting of the KCM servicename, I checked 
that this is the right servicename by checking that it is only registered when 
the KCM is open.


- Andreas


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


On Nov. 4, 2015, 6:28 a.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125936/
> ---
> 
> (Updated Nov. 4, 2015, 6:28 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Fixes missing update of Settings->Cache KCM that happens if opening
> KCM, changing values (e.g., "No Cache"), closing Cache KCM, opening Cache
> KCM again.
> 
> Reason is that storing and loading of UI values is performed
> asymmetrically in two different KSharedConfig objects. Now force second
> KSharedData to sync once settings are saved.
> 
> 
> Diffs
> -
> 
>   src/kcms/kio/cache.cpp 8f2f4e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125936/diff/
> 
> 
> Testing
> ---
> 
> manual testing
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

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

Re: Review Request 125936: Update KProtocolManager after configuration change.

[David Faure]

> On Nov. 6, 2015, 8:02 a.m., David Faure wrote:
> > src/kcms/kio/cache.cpp, line 91
> > 
> >
> > Isn't this done by the call to updateRunningIOSlaves just below, which 
> > sends the DBus signal "reparseSlaveConfiguration" to all processes with a 
> > KIO scheduler, which, in SchedulerPrivate::slotReparseSlaveConfiguration, 
> > calls KProtocolManager::reparseConfiguration?
> > 
> > Please check why this doesn't happen in your testcase.
> > I can think of a few possibilities:
> > - there's no KIO scheduler in this process
> > - you need this reparsed before going back to the event loop (but from 
> > your description it doesn't seem so)
> > - there's a bug in the emitting or the handling of that dbus signal 
> > (which is why I'm asking, if there is, we might as well find it and fix it).
> 
> Andreas Cord-Landwehr wrote:
> Thanks for the infos. Regarding the even-loop I agree that this cannot be 
> the problem.
> I just tested for the KIO scheduler. With the open KCM dialog I get:
> 
> cordlandwehr@weatherwax:~$ qdbus "org.kde.KIO.Scheduler"
> Service 'org.kde.KIO.Scheduler' does not exist.
> 
> So, I would deduce that no scheduler exists, or do I miss anything?

You're confusing dbus service names and dbus interface names.
You need to call `qdbus  
/KIO/Scheduler`

The KIO scheduler is a class in each process that uses KIO, it's not a 
desktop-wide daemon.


- David


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


On Nov. 4, 2015, 6:28 a.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125936/
> ---
> 
> (Updated Nov. 4, 2015, 6:28 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Fixes missing update of Settings->Cache KCM that happens if opening
> KCM, changing values (e.g., "No Cache"), closing Cache KCM, opening Cache
> KCM again.
> 
> Reason is that storing and loading of UI values is performed
> asymmetrically in two different KSharedConfig objects. Now force second
> KSharedData to sync once settings are saved.
> 
> 
> Diffs
> -
> 
>   src/kcms/kio/cache.cpp 8f2f4e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125936/diff/
> 
> 
> Testing
> ---
> 
> manual testing
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

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

Re: Private Qml pugin for Baloo

[Pinak Ahuja]

The code is already in Baloo, under the namespace
org.kde.baloo.experimental. It is being used only by KInfoCenter right now.
The idea is that it'll not be used in anything critical until the API is
stabilized. I don't see the need for API changes in the foreseeable future.

So maybe we can move it under the main namespace in some time and after
that start using it in stuff like applets, KRunner etc?

--
Thanks
Pinak Ahuja

On 8 November 2015 at 16:20, David Faure  wrote:

> On Wednesday 19 August 2015 16:03:34 Pinak Ahuja wrote:
> > I am planning to add a baloo-monitor model to baloo's Qml plugin. The
> > problem is that we cannot guarantee API stability right now. Is
> exporting a
> > new plugin under the namespace org.kde.baloo.experimental acceptable or
> is
> > there some other way to go about it?
>
> Seems nobody replied to this.
>
> This kind of thing won't annoy packagers (because it's all interpreted
> stuff),
> but still, it will annoy users. Do you really want users to get a broken
> plasma
> applet (I assume this is where the QML plugin is going to be used?) after
> upgrading KF5 because you would then have changed the API, and they
> don't have a newer release of whatever-uses-that-API ?
>
> --
> 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

Frameworks API documentation broken

[Martin Graesslin]

Hi all,

I just wanted to raise awareness of the fact that the Frameworks API 
documentation on api.kde.org is completely broken. Currently one only gets 
error 404 when clicking on the framework links and also in the search I cannot 
find e.g. the frameworks variant of KAboutData.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Martin Graesslin]

On Wednesday, November 11, 2015 10:22:13 AM CET Jan Kundrát wrote:
> On Tuesday, 10 November 2015 08:34:02 CET, Martin Graesslin wrote:
> > Yes, most tests don't require a WM. Especially the Net* tests
> > simulate being a
> > window manager. Only the KWindow* tests need a window manager.
> 
> Interesting; it was a Heisenbug, apparently. I cannot reproduce it anymore,
> but I've added code which at least prints out a warning if the Xvfb and/or
> openbox dies for some reason.
> 
> > Well for me there is not much to do. I don't get them failing
> > on my system, so
> > I have no clue what I should fix to make them work again.
> 
> I believe that the CI system and the tests together should be designed to
> provide enough diagnostic information. If you as a developer say "I cannot
> reproduce it on my system, therefore I cannot help you", what can I do as a
> CI administrator to improve the situation? Should we perhaps reduce the
> number of CI-specific scripting to make the deployments closer to what the
> developers run? Would you like pre-built VM images?

Well I did what the CI system does. I started Xvfb with exactly the same 
command as in the build output and also used openbox on that Xvfb and run the 
unit test on the Xvfb. So I think I reproduced the setup. I really tried hard 
to get to the broken state and tried also a few different setups which all did 
not result in a broken test. It takes a long time till I give up on trying to 
reproduce a test, in this case it has happened. (I also must point out that I 
think there is something somewhere horribly broken if we need to adjust our 
tests because Qt changed - currently I need to adjust the tests for each 
release, I'm rather pissed by the "ABI stability" Qt provides).

I wouldn't know what further information the tests could provide to debug it. 
I could tell if I were able to reproduce them and see what goes wrong. At the 
moment all I have is "wm might have crashed" which is nothing the tests can 
check for.

In the long run I want to spend some time in getting our "Xvfb + openbox" 
setup replaced by kwin_wayland on the virtual backend. It would mean KWin gets 
automatically more testing (that's the selfish part) and we have a known base 
for our tests and don't depend on openbox.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build and test failures with Qt 5.6 and Qt 5.3

[Jan Kundrát]

On Tuesday, 10 November 2015 08:34:02 CET, Martin Graesslin wrote:
Yes, most tests don't require a WM. Especially the Net* tests 
simulate being a 
window manager. Only the KWindow* tests need a window manager.


Interesting; it was a Heisenbug, apparently. I cannot reproduce it anymore, 
but I've added code which at least prints out a warning if the Xvfb and/or 
openbox dies for some reason.


Well for me there is not much to do. I don't get them failing 
on my system, so 
I have no clue what I should fix to make them work again.


I believe that the CI system and the tests together should be designed to 
provide enough diagnostic information. If you as a developer say "I cannot 
reproduce it on my system, therefore I cannot help you", what can I do as a 
CI administrator to improve the situation? Should we perhaps reduce the 
number of CI-specific scripting to make the deployments closer to what the 
developers run? Would you like pre-built VM images?


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel