Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

[Anthony Fieroni]

> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
> 

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

[Anthony Fieroni]

> On Ноев. 16, 2016, 8 след обяд, Anthony Fieroni wrote:
> > Ping, i'm still using it without issues, it isn't good enough?
> 
> Anthony Fieroni wrote:
> Ping?

Any problems with to go in ?


- Anthony


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


On Ноев. 13, 2016, 7:17 преди обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127216/
> ---
> 
> (Updated Ноев. 13, 2016, 7:17 преди обяд)
> 
> 
> Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek.
> 
> 
> Bugs: 356523
> https://bugs.kde.org/show_bug.cgi?id=356523
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Store position of widget before hide it
> 
> 
> Diffs
> -
> 
>   src/kstatusnotifieritem.cpp 3eb39b2 
>   src/kstatusnotifieritemprivate_p.h 8fdfd4c 
> 
> Diff: https://git.reviewboard.kde.org/r/127216/diff/
> 
> 
> Testing
> ---
> 
> Tested on pixel ratio = 1 with Amarok, Kmail, Akregator, Kalarm, Ktimer
> Close with 'X' - restore in correct pos
> Hide by click at icon in systray - restore correct pos
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129281: [Konsole] Render text at primary font's baseline

[Christoph Feck]

> On Nov. 9, 2016, 1:22 p.m., Martin Tobias Holmedahl Sandsmark wrote:
> > looks good to me, but I think hindenburg should ack it (might want to add 
> > him to reviewers)
> 
> Christoph Feck wrote:
> Pretty sure "konsole" reviewers group includes the maintainer, but I 
> would actually prefer feedback from someone using non-Western characters in 
> Konsole.

Ping? Should I just commit it to 16.12 branch so that people can give feedback?


- Christoph


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


On Nov. 6, 2016, 9:40 p.m., Christoph Feck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129281/
> ---
> 
> (Updated Nov. 6, 2016, 9:40 p.m.)
> 
> 
> Review request for KDE Frameworks and Konsole.
> 
> 
> Bugs: 371687
> http://bugs.kde.org/show_bug.cgi?id=371687
> 
> 
> Repository: konsole
> 
> 
> Description
> ---
> 
> When Konsole draws a line of text, it first computes the rectangle of the 
> line that the text covers (taking into account cells width and height), then 
> passes this rectangle to the drawText(QRect, flags, text) call.
> 
> Qt detects if the selected font does not offer all characters in the text, 
> and substitutes individual characters with a different font. Due to designer 
> choices, the same font point size does not lead to same pixel height (or 
> ascent size) in all fonts, so the substituted characters might be larger than 
> the characters from the primary font.
> 
> Using a rectangle causes Qt to position glyphs relative to the bounding box 
> of the text, instead of anchored to the baseline.
> 
> This patch uses a pixel position instead of a rectangle to draw the text, 
> taking into account only the baseline of the primary font.
> 
> I have added all "frameworks" developers to increase possible test coverage.
> 
> 
> Diffs
> -
> 
>   src/TerminalDisplay.cpp 39a8b84 
> 
> Diff: https://git.reviewboard.kde.org/r/129281/diff/
> 
> 
> Testing
> ---
> 
> On my system, lines with substituted Unicode characters are no longer shifted 
> away from the baseline, and therefore do not appear cropped.
> 
> Further testing is needed, as there are many (equivalent, similar, or 
> different) bug reports about font rendering on different systems, see 
> https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED_status=CONFIRMED=font=konsole
> 
> 
> Thanks,
> 
> Christoph Feck
> 
>

[Differential] [Updated] D3386: Generate an instance with KSharedConfig::Ptr for singleton and arg

[ltoscano (Luigi Toscano)]

ltoscano set the repository for this revision to R237 KConfig.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D3386

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #frameworks, dfaure, mdawson
Cc: aacid, apol

[Differential] [Commented On] D3386: Generate an instance with KSharedConfig::Ptr for singleton and arg

[ltoscano (Luigi Toscano)]

ltoscano added a comment.


  Created and added the KConfig repository.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D3386

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #frameworks, dfaure, mdawson
Cc: ltoscano, aacid, apol

[Differential] [Updated] D3544: Small optimization

[ltoscano (Luigi Toscano)]

ltoscano set the repository for this revision to R235 Attica.

REPOSITORY
  R235 Attica

REVISION DETAIL
  https://phabricator.kde.org/D3544

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #frameworks, leinir, whiting
Cc: ltoscano, aacid

[Differential] [Commented On] D3544: Small optimization

[ltoscano (Luigi Toscano)]

ltoscano added a comment.


  Not all projects are defined here. Please ping the community admin if you 
want to send a patch for a repository which is not tracked here. 
  Btw, this seems to be attica, I'm going to enable it.

REVISION DETAIL
  https://phabricator.kde.org/D3544

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #frameworks, leinir, whiting
Cc: ltoscano, aacid

[Differential] [Commented On] D3386: Generate an instance with KSharedConfig::Ptr for singleton and arg

[aacid (Albert Astals Cid)]

aacid added a comment.


  Is this another patch that doesn't say to which repository it applies? Or am 
i just too stupid to find it in phabricator?

REVISION DETAIL
  https://phabricator.kde.org/D3386

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #frameworks, dfaure, mdawson
Cc: aacid, apol

[Differential] [Commented On] D3544: Small optimization

[aacid (Albert Astals Cid)]

aacid added a comment.


  Can we please stop having patches on phabricator that don't reference the 
repository they are supposed to be applied to?

REVISION DETAIL
  https://phabricator.kde.org/D3544

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #frameworks, leinir, whiting
Cc: aacid

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[shumski (Hrvoje Senjan)]

shumski added inline comments.

INLINE COMMENTS

> kossebau wrote in KDEInstallDirs.cmake:534
> Fear I am still missing what you mean. So let's go explicitely, here is what 
> I understand to happen:
> 
> There are six different cases when using this macro and on the first 
> invocation of cmake, from the combinations of installing to a different 
> prefix or the same prefix as Qt (2 variants) versus 
> KDE_INSTALL_USE_QT_SYS_PATHS being not set/defined, set to ON, set to OFF (3 
> variants).
> 
> In these 3 cases plugins, QCH & Co. will be all installed to Qt system dirs 
> and thus automatically picked up by Qt, without the need for further env var 
> settings:
> 
> - -DKDE_INSTALL_USE_QT_SYS_PATHS=ON, different prefix
> - -DKDE_INSTALL_USE_QT_SYS_PATHS=ON, same prefix
> - KDE_INSTALL_USE_QT_SYS_PATHS not passed as argument, same prefix (so
> 
> In the three other cases plugins, QCH & Co will be installed in dirs and need 
> further env var settings, for Qt (and Qt Assistant) to also pick up the stuff.
> 
> Where do we see things differently? And just to make sure, you have seen the 
> right lines at the link I passed before, how 
> _default_KDE_INSTALL_USE_QT_SYS_PATHS is set to ON if the same prefix is used?

Hm, i guess i haven't checked KDEInstallDirs in a while. Somehow i remember 
KDE_INSTALL_USE_QT_SYS_PATHS was only activated by default if 
CMAKE_INSTALL_PREFIX was /usr.

Ok, so the non-recognition part should not happen that often -> I'm assuming 
qch files are looked up as QLibraryInfo::DocumentationPath (so, 
QT_INSTALL_DOCS)  + *qch.

So with your path, they will not be found (yeah with different prefix they 
aren0t still found, but with qch/ subdir user needs one additional envar for 
KF5 qch's - imagine you need to export QT_PLUGIN_PATH for Qt plugins, and one 
more path for KF5 plugins).
I don't see a reason to append qch subdir to installation location -> as if 
you're intentionally hiding those files ;-)

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau added inline comments.

INLINE COMMENTS

> shumski wrote in KDEInstallDirs.cmake:534
> It is :) But with this latest revision it is not when that var is off =) I'm 
> saying that for both cases it should happen.

Fear I am still missing what you mean. So let's go explicitely, here is what I 
understand to happen:

There are six different cases when using this macro and on the first invocation 
of cmake, from the combinations of installing to a different prefix or the same 
prefix as Qt (2 variants) versus KDE_INSTALL_USE_QT_SYS_PATHS being not 
set/defined, set to ON, set to OFF (3 variants).

In these 3 cases plugins, QCH & Co. will be all installed to Qt system dirs and 
thus automatically picked up by Qt, without the need for further env var 
settings:

- -DKDE_INSTALL_USE_QT_SYS_PATHS=ON, different prefix
- -DKDE_INSTALL_USE_QT_SYS_PATHS=ON, same prefix
- KDE_INSTALL_USE_QT_SYS_PATHS not passed as argument, same prefix (so

In the three other cases plugins, QCH & Co will be installed in dirs and need 
further env var settings, for Qt (and Qt Assistant) to also pick up the stuff.

Where do we see things differently? And just to make sure, you have seen the 
right lines at the link I passed before, how 
_default_KDE_INSTALL_USE_QT_SYS_PATHS is set to ON if the same prefix is used?

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[shumski (Hrvoje Senjan)]

shumski added inline comments.

INLINE COMMENTS

> kossebau wrote in KDEInstallDirs.cmake:534
> But isn't this free recognition happening via KDE_INSTALL_USE_QT_SYS_PATHS as 
> well?
> At least this is how I understand 
> https://cgit.kde.org/extra-cmake-modules.git/tree/kde-modules/KDEInstallDirs.cmake#n442
>  to work.
> This is also what I rely on, as I agree that it should also happen when 
> installing to the same prefix :)

It is :) But with this latest revision it is not when that var is off =) I'm 
saying that for both cases it should happen.

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau added inline comments.

INLINE COMMENTS

> shumski wrote in KDEInstallDirs.cmake:534
> Right. But if you install a framework to same prefix as Qt, you get free 
> recognition of plugins, qml imports, etc... This is valid for both /usr and 
> custom prefix installs.
> I guess what i want to say is that there is IMHO no reason this should also 
> not work for QCH docs.

But isn't this free recognition happening via KDE_INSTALL_USE_QT_SYS_PATHS as 
well?
At least this is how I understand 
https://cgit.kde.org/extra-cmake-modules.git/tree/kde-modules/KDEInstallDirs.cmake#n442
 to work.
This is also what I rely on, as I agree that it should also happen when 
installing to the same prefix :)

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau added inline comments.

INLINE COMMENTS

> shumski wrote in KDEInstallDirs.cmake:534
> I mean, addition of qch subdir is 'your' invention here.
> If Frameworks were to use only qmake build-system, i'm sure qch files would 
> end up in QT_INSTALL_DOCS directory.
> I.e. for KDE_INSTALL_USE_QT_SYS_PATHS=ON the paths are Qt's, so are with 
> KDE_INSTALL_USE_QT_SYS_PATHS=OFF, just that for the latter case they are read 
> from sources, opposed to querying qmake.

But that is the same for the current QTPLUGINDIR, QTQUICKIMPORTSDIR, & QMLDIR, 
no? They also only get set to the Qt system paths if 
KDE_INSTALL_USE_QT_SYS_PATHS=ON, otherwise get set to something based on 
general LIBDIR.
(I would have liked to put the setting of QTQCHDIR next to these other ones, 
but at that time DATAROOTDIR is not yet defined, so had to create a separate 
if-else)
And especially if installing multiple versions of the same dir (e.g. for 
different projects or as developer of the lib), it will be needed to optionally 
not install into the Qt system path, but point all the tools via ENV variables 
or other ways to the matching plugins or documentation.

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau added inline comments.

INLINE COMMENTS

> shumski wrote in KDEInstallDirs.cmake:534
> I think e.g. QMLDIR, PLUGINDIR, ECM_MKSPECS_INSTALL_DIR, etc. are vanilla 
> Qt's. QCH files are thus installed straight into QT_INSTALL_DOCS dir AFAICS 
> ...

Not sure what you mean, please point out the issue you see here with more 
details :)

The plan here is:
if KDE_INSTALL_USE_QT_SYS_PATHS is set, install QCH files to QT_INSTALL_DOCS, 
if not, some "normal" dir (there is no standard dir for QCH in general 
currently, everybody installs their 3rd-party QCH files somewhere).
See thread 
http://lists.qt-project.org/pipermail/development/2016-November/027856.html and 
especially the latest 
http://lists.qt-project.org/pipermail/development/2016-November/028001.html
Feedback is very welcome.

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[shumski (Hrvoje Senjan)]

shumski added inline comments.

INLINE COMMENTS

> kossebau wrote in KDEInstallDirs.cmake:534
> Not sure what you mean, please point out the issue you see here with more 
> details :)
> 
> The plan here is:
> if KDE_INSTALL_USE_QT_SYS_PATHS is set, install QCH files to QT_INSTALL_DOCS, 
> if not, some "normal" dir (there is no standard dir for QCH in general 
> currently, everybody installs their 3rd-party QCH files somewhere).
> See thread 
> http://lists.qt-project.org/pipermail/development/2016-November/027856.html 
> and especially the latest 
> http://lists.qt-project.org/pipermail/development/2016-November/028001.html
> Feedback is very welcome.

I mean, addition of qch subdir is 'your' invention here.
If Frameworks were to use only qmake build-system, i'm sure qch files would end 
up in QT_INSTALL_DOCS directory.
I.e. for KDE_INSTALL_USE_QT_SYS_PATHS=ON the paths are Qt's, so are with 
KDE_INSTALL_USE_QT_SYS_PATHS=OFF, just that for the latter case they are read 
from sources, opposed to querying qmake.

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Updated, 1,080 lines] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau updated this revision to Diff 8639.
kossebau added a comment.


  adapt also documentation to doc/QCH

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2854?vs=8635=8639

BRANCH
  addApiDox

REVISION DETAIL
  https://phabricator.kde.org/D2854

AFFECTED FILES
  kde-modules/KDEInstallDirs.cmake
  modules/ECMAddQCH.cmake
  modules/ECMDoxygenQCH.config.in
  modules/ECMDoxygenQCHLayout.xml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[shumski (Hrvoje Senjan)]

shumski added inline comments.

INLINE COMMENTS

> KDEInstallDirs.cmake:534
> +else()
> +_define_relative(QTQCHDIR DATAROOTDIR "doc/QCH"
> +"documentation bundles in QCH format for Qt-extending libraries")

I think e.g. QMLDIR, PLUGINDIR, ECM_MKSPECS_INSTALL_DIR, etc. are vanilla Qt's. 
QCH files are thus installed straight into QT_INSTALL_DOCS dir AFAICS ...

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Updated, 1,080 lines] D2854: New: ECMAddQCH, for generating qch & doxygen tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau updated this revision to Diff 8635.
kossebau added a comment.


  Use rather subfolder doc/QCH for installing QCH files

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2854?vs=8586=8635

BRANCH
  addApiDox

REVISION DETAIL
  https://phabricator.kde.org/D2854

AFFECTED FILES
  kde-modules/KDEInstallDirs.cmake
  modules/ECMAddQCH.cmake
  modules/ECMDoxygenQCH.config.in
  modules/ECMDoxygenQCHLayout.xml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop

[Differential] [Commented On] D3530: Import plasma-workspace kioslaves

[aacid (Albert Astals Cid)]

aacid added a comment.


  In https://phabricator.kde.org/D3530#66090, @mart wrote:
  
  > In https://phabricator.kde.org/D3530#65734, @aacid wrote:
  >
  > > > Dolphin in other environments currently gives a big error until you 
install plasma-workspace, which defeats the point of the split.
  > >
  > > Maybe Dolphin needs to be patched not to assume remote:/ will always be 
available?
  >
  >
  > tough remote is a functionality that makes sense regardless in which 
desktop you're in
  
  
  Agreed, and we should encourage packagers to provide that dependency, but on 
the source code level I think it makes sense to gracefully detect that one of 
your runtime dependencies is missing

REVISION DETAIL
  https://phabricator.kde.org/D3530

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: elvisangelaccio, #frameworks, #plasma, dfaure
Cc: mart, aacid, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas

[Differential] [Commented On] D3530: Import plasma-workspace kioslaves

[mart (Marco Martin)]

mart added a comment.


  In https://phabricator.kde.org/D3530#65734, @aacid wrote:
  
  > > Dolphin in other environments currently gives a big error until you 
install plasma-workspace, which defeats the point of the split.
  >
  > Maybe Dolphin needs to be patched not to assume remote:/ will always be 
available?
  
  
  tough remote is a functionality that makes sense regardless in which desktop 
you're in

REVISION DETAIL
  https://phabricator.kde.org/D3530

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: elvisangelaccio, #frameworks, #plasma, dfaure
Cc: mart, aacid, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas

Review Request 129590: KAuth: Make D-Bus dependency optional.

[Gleb Popov]

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

Review request for KDE Frameworks and kdewin.


Repository: kauth


Description
---

This adds an `ENABLE_DBUS` CMake option defaulting to `ON`, which can be used 
to make KAuth not depend on DBus. This is useful for some apps that are running 
on Windows.

https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg34246.html


Diffs
-

  CMakeLists.txt b8b7ba7 
  autotests/CMakeLists.txt b53d760 
  src/CMakeLists.txt 1b6930d 

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


Testing
---


Thanks,

Gleb Popov

[Differential] [Updated] D3386: Generate an instance with KSharedConfig::Ptr for singleton and arg

[Martin Gräßlin]

graesslin added reviewers: dfaure, mdawson.

REVISION DETAIL
  https://phabricator.kde.org/D3386

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #frameworks, dfaure, mdawson
Cc: apol