Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Set. 14, 2014, 3:27 p.m., Frank Reininghaus wrote:
> > src/core/kfileitem.h, line 262
> > 
> >
> > Since we probably do not want to make it possible that all users of 
> > this class can make items "hidden", I'm not sure if this should be part of 
> > KFileItem's public API.
> 
> David Faure wrote:
> I don't have an issue with that. Gives more possibilities to the app (or 
> file dialog) etc.
> 
> Bruno Nova wrote:
> So, should this be left public or not?
> 
> Bruno Nova wrote:
> I still need an answer here. :-)
> 
> Besides this issue, there is another thing that was suggested that was 
> not implemented: unit tests.
> I'll try to do this tomorrow, but I'll probably not be capable of doing 
> it.
> 
> Frank Reininghaus wrote:
> To be honest, I just don't see a valid use case for that - why would an 
> app or the file dialog want to make the dir lister consider a particular file 
> item hidden? If the app/file dialog wants to hide items from the user, there 
> are other (and easier) ways to do that, since they already use a 
> QSortFilterProxyModel or some other kind of filtering mechanism, right?
> 
> If anyone sees a good use case, then fair enough, but unless that is the 
> case, I don't think that one should make it public API (which is extremely 
> hard to change or remove in future versions!).

That's fine by me. And those other ways you mention are probably more reliable.
David, what say you?


- Bruno


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


On Dez. 4, 2014, 9:55 p.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Dez. 4, 2014, 9:55 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kcoredirlister_p.h dce7dbc 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Frank Reininghaus 


> On Sept. 14, 2014, 3:27 nachm., Frank Reininghaus wrote:
> > src/core/kfileitem.h, line 262
> > 
> >
> > Since we probably do not want to make it possible that all users of 
> > this class can make items "hidden", I'm not sure if this should be part of 
> > KFileItem's public API.
> 
> David Faure wrote:
> I don't have an issue with that. Gives more possibilities to the app (or 
> file dialog) etc.
> 
> Bruno Nova wrote:
> So, should this be left public or not?
> 
> Bruno Nova wrote:
> I still need an answer here. :-)
> 
> Besides this issue, there is another thing that was suggested that was 
> not implemented: unit tests.
> I'll try to do this tomorrow, but I'll probably not be capable of doing 
> it.

To be honest, I just don't see a valid use case for that - why would an app or 
the file dialog want to make the dir lister consider a particular file item 
hidden? If the app/file dialog wants to hide items from the user, there are 
other (and easier) ways to do that, since they already use a 
QSortFilterProxyModel or some other kind of filtering mechanism, right?

If anyone sees a good use case, then fair enough, but unless that is the case, 
I don't think that one should make it public API (which is extremely hard to 
change or remove in future versions!).


- Frank


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


On Dez. 4, 2014, 9:55 nachm., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Dez. 4, 2014, 9:55 nachm.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kcoredirlister_p.h dce7dbc 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 114933: KF5 Port of kdeui/kmessagewidgetdemo

2014-12-04 Thread Laurent Navet 


> On Aug. 12, 2014, 11:33 a.m., Aleix Pol Gonzalez wrote:
> > After some discussion with the SDK and Book groups in the sprint, I think 
> > we should move this into the kde:kwidgetsaddons repository, in an examples 
> > subdirectory.
> 
> Laurent Navet wrote:
> do you want me to move this from kdeexamples to kwidgetsaddons ?
> 
> Christoph Feck wrote:
> While it indeed makes sense to showcase the features of a framework 
> inside that framework, here I see the problem that the code currently depends 
> on other frameworks.
> 
> So either we showcase multiple frameworks, and have a separate examples 
> repository, or we showcase a single framework, and make sure the examples do 
> not drag in other frameworks.
> 
> Christoph Feck wrote:
> Has a decision been made to strip it down to Qt-only dependencies (and 
> KWidgetAddons of course :) for adding it to KWidgetAddons, or ship it in a 
> separate repository, where we can showcase it together with the other useful 
> KF5 features, such as translations, kconfig etc.?
> 
> Dominik Haumann wrote:
> As someone who worked on KMessageWidget quite a lot, I'd be in favour of 
> having this demo app in an examples directory, as I think it makes sense to 
> keep the code close together.

up !


- Laurent


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


On Aug. 12, 2014, 11:33 a.m., Laurent Navet wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114933/
> ---
> 
> (Updated Aug. 12, 2014, 11:33 a.m.)
> 
> 
> Review request for KDE Examples, KDE Frameworks and Sune Vuorela.
> 
> 
> Repository: kdeexamples
> 
> 
> Description
> ---
> 
> This is part of Google Code-IN Contest.
> As I'm no more student, I've waited for the end of the contest to work on it.
> 
> Comments appreciated,
> 
> 
> Diffs
> -
> 
>   kdeui/kmessagewidgetdemo/CMakeLists.txt 12ef4ac 
>   kdeui/kmessagewidgetdemo/main.cpp d3a5bf0 
>   kdeui/kmessagewidgetdemo/window.h d3a67c8 
>   kdeui/kmessagewidgetdemo/window.cpp 9786da6 
> 
> Diff: https://git.reviewboard.kde.org/r/114933/diff/
> 
> 
> Testing
> ---
> 
> Regression on KTextedit::setClickMessage(), as it don't exist in QTextEdit 
> I've commented the line.
> 
> 
> Thanks,
> 
> Laurent Navet
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Set. 14, 2014, 3:27 p.m., Frank Reininghaus wrote:
> > src/core/kfileitem.h, line 262
> > 
> >
> > Since we probably do not want to make it possible that all users of 
> > this class can make items "hidden", I'm not sure if this should be part of 
> > KFileItem's public API.
> 
> David Faure wrote:
> I don't have an issue with that. Gives more possibilities to the app (or 
> file dialog) etc.
> 
> Bruno Nova wrote:
> So, should this be left public or not?

I still need an answer here. :-)

Besides this issue, there is another thing that was suggested that was not 
implemented: unit tests.
I'll try to do this tomorrow, but I'll probably not be capable of doing it.


- Bruno


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


On Dez. 4, 2014, 9:55 p.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Dez. 4, 2014, 9:55 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kcoredirlister_p.h dce7dbc 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Nov. 8, 2014, 10:02 p.m., David Faure wrote:
> > src/core/kcoredirlister.cpp, line 1241
> > 
> >
> > After this line, try adding
> > 
> > if (!url.isLocalFile()) {
> > const QString localPath = dir->rootItem.localPath();
> > if (!localPath.isEmpty()) {
> > filesToHide = 
> > filesInDotHiddenForDir(QUrl::fromLocalFile(localPath));
> > }
> > }
> > 
> > This should take care of the case of desktop:/ URLs. Can you test?
> 
> Bruno Nova wrote:
> Thanks! I'll test it in a few days. I haven't had time to look into this 
> yet.
> 
> Bruno Nova wrote:
> I finally had the time to look at this again.
> I tested this, and `dir->rootItem.localPath()` does indeed work for the 
> `desktop:/` directory.
> However, from my tests, the root item/current directory (`.`) is not the 
> first item in the UDSEntryList being iterated. So, some files are not hidden.
> I need that rootItem before the loop. I'll see if I can do something 
> about it (without iterating twice or iterating back from `.` in the loop).
> 
> Bruno Nova wrote:
> @David, do you think iterating a second time over the UDSEntryList just 
> to find the ".hidden" file would have a noticeable impact on performance in 
> very large folders? And would it be acceptable?
> I just tried that, and it worked, even in `desktop:/`. I didn't notice 
> any noticeable slowdown when I opened */usr/bin*. I added that second loop 
> above the existing loop (this could then be placed in the 
> `filesInDotHiddenForDir()` method).
> With my limited knowledge of KDE, I don't see another way of getting a 
> KFileItem (of `.` or `.hidden`) from a UDSEntry before that loop (since 
> KFileItem's contructed from QUrl's are not "complete").
> 
> David Faure wrote:
> Hmm, then maybe use localPath on the first item instead, whichever it is, 
> and remove the filename, to go up to the parent directory?
> 
> Bruno Nova wrote:
> Why didn't I think of that? That seems to be the best solution!

I uploaded a new patch. Your solution seems to work perfectly!


- Bruno


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


On Dez. 4, 2014, 9:55 p.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Dez. 4, 2014, 9:55 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kcoredirlister_p.h dce7dbc 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Set. 14, 2014, 3:27 p.m., Frank Reininghaus wrote:
> > src/core/kcoredirlister.h, line 420
> > 
> >
> > I think that you should not make this part of the public API. AFAICS, 
> > you're not using it anywhere outside KCoreDirLister, right?
> 
> Bruno Nova wrote:
> I left this method (and others) public because I thought that, maybe in 
> the future, someone may want to use this method.
> But you're right, it's not used anywhere else and should probably be 
> private/protected.

I moved this method to KCoreDirListerCache, making it private.


> On Set. 14, 2014, 3:27 p.m., Frank Reininghaus wrote:
> > src/core/kcoredirlister.cpp, line 2799
> > 
> >
> > This will only work for local files. I'm not sure if we would want to 
> > support the ".hidden" mechanism also for other protocols, such as sftp or 
> > fish?
> > 
> > Moreover, I think that we might want to cache the contents of the 
> > .hidden file, to prevent that we read it, parse it and construct the QSet 
> > with the hidden files over and over again if a kioslave reports the 
> > UDSEntries in multiple batches.
> 
> David Faure wrote:
> Supporting .hidden for remote protocols would be much more complex (async 
> API).
> 
> Caching: it would have to include an mtime, to be able to detect changes. 
> But indeed caching the last one read would be good, because while having a 
> directory open, any change triggers an update job, which will re-read the 
> .hidden file. Or while at it, could be a LRU cache, Qt makes it simple:
> 
> struct CacheHiddenFile {
> QDateTime mtime;
> QSet listedFiles;
> }
> QCache 
> m_cacheHiddenFiles;
> 
> m_cacheHiddenFiles.setMaxCost(10);
> 
> This requires making the filesInDotHiddenForDir method not file-static as 
> I previously suggested, but rather a method of KCoreDirLister::Private, which 
> would also have the above member.
> 
> Bruno Nova wrote:
> Now that you mention remote protocols, I just found out that Nautilus 
> ".hidden" also doesn't support them.
> For example, ".hidden" is not interpreted when I access a computer 
> through SFTP in Nautilus. However, when I mount it externally using `sshfs`, 
> it works.
> Haven't checked Thunar.
> 
> As for the caching, I'll try to take a look at it, but I'll probably need 
> help (I have very little experience with KDE and Qt).
> 
> Bruno Nova wrote:
> Just found a case where the *.hidden* doesn't work.
> If a *.hidden* file is in *~/Desktop*, it works correctly when accessed 
> from that path, but it doesn't work when accessed from *desktop:/*.
> Is *desktop:/* interpreted as a network path, and `dir.toLocalFile()` 
> fails in that path?
> I tested in Project Neon in Virtualbox using Kwrite's open dialog, plus 
> LD_LIBRARY_PATH to use the patched library.
> 
> Bruno Nova wrote:
> David, for the caching, where should the struct and 
> filesInDotHiddenForDir be declared? KCoreDirLister::Private or 
> KCoreDirListerCache?
> filesInDotHiddenForDir is called in two methods of KCoreDirListerCache.
> 
> Also, you forgot the semi-colon after the struct declaration ;) (and, as 
> usual, the C++ compiler error message was not very informative).
> 
> David Faure wrote:
> desktop:/ is almost like a remote protocol, except that we can resolve 
> such urls to local files, using KFileItem::localPath(). So using this would 
> be a way to make it work for desktop:/ urls as well as file:/ urls.
> 
> Both classes are private (i.e. not part of the public API), so it doesn't 
> matter. So KCoreDirListerCache looks like the easiest solution.
> 
> Sorry about the missing semicolon :-)
> 
> Bruno Nova wrote:
> From my tests, KFileItem::localPath() does not work for "desktop:/" URLs 
> when the KFileItem is constructed from a QUrl, it just returns an empty 
> string. Worse, when the URL is "file:///" (root folder), localPath() also 
> returns an empty string (strange). And I've also seen it fail randomly in 
> other folders.
> 
> It would probably work if the KFileItem was constructed/retrieved from a 
> UDSEntry, but how can I do that in slotEntries() and slotUpdateResult() 
> before iterating over the UDSEntryList?

I uploaded a new patch that caches the ".hidden" file, as advised.
Please check if it's correct.


- Bruno


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


On Dez. 4, 2014, 9:55 p.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://gi

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 

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

(Updated Dez. 4, 2014, 9:55 p.m.)


Review request for KDE Frameworks and David Faure.


Changes
---

`desktop:/` should now be correctly handled, filesInDotHiddenForDir() made 
private and now caching the contents of the ".hidden" files.


Bugs: 64740 and 246260
https://bugs.kde.org/show_bug.cgi?id=64740
https://bugs.kde.org/show_bug.cgi?id=246260


Repository: kio


Description
---

This adds support for *.hidden* files to KDE.

When listing a directory, the files/folders listed in the *.hidden* file will 
be hidden, unless the user has chosen to show hidden files.

This patch was initially based on the patch provided by Mark in Bug #246260.


Diffs (updated)
-

  src/core/kcoredirlister.cpp a31d629 
  src/core/kcoredirlister_p.h dce7dbc 
  src/core/kfileitem.h bebc241 
  src/core/kfileitem.cpp 74dc069 

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


Testing
---

Built and tested the patch in Project Neon.
Dolphin was still using KDE4/Qt4 version of the library, so I only tested using 
the desktop folder widget, and "folder desktop".
It worked correctly when I pointed it to "~" and "~/Desktop" (I added ".hidden" 
there).
However, it didn't work when I pointed it to the "Desktop folder" (the default 
option, not the custom location "~/Desktop").
More testing is required.

The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 14.04, 
and it worked everywhere I tested (Dolphin, open/save dialogs, folder widget 
and detailed/tree view in Dolphin).
It wasn't an intensive test, though.


Thanks,

Bruno Nova

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

Re: Review Request 121356: Do not change the volume when playing a notification

2014-12-04 Thread David Edmundson 

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

Ship it!


Ship It!

- David Edmundson


On Dec. 4, 2014, 9:12 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121356/
> ---
> 
> (Updated Dec. 4, 2014, 9:12 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Playing a notification should be that, playing a notification.
> 
> Inspired by David's comment on https://git.reviewboard.kde.org/r/121278/
> 
> 
> Diffs
> -
> 
>   src/notifybysound.cpp 09a80dd 
> 
> Diff: https://git.reviewboard.kde.org/r/121356/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 121356: Do not change the volume when playing a notification

2014-12-04 Thread Jeremy Whiting 

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

Ship it!


Ship It!

- Jeremy Whiting


On Dec. 4, 2014, 2:12 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121356/
> ---
> 
> (Updated Dec. 4, 2014, 2:12 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Playing a notification should be that, playing a notification.
> 
> Inspired by David's comment on https://git.reviewboard.kde.org/r/121278/
> 
> 
> Diffs
> -
> 
>   src/notifybysound.cpp 09a80dd 
> 
> Diff: https://git.reviewboard.kde.org/r/121356/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Review Request 121356: Do not change the volume when playing a notification

2014-12-04 Thread Albert Astals Cid 

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

Review request for KDE Frameworks and David Edmundson.


Repository: knotifications


Description
---

Playing a notification should be that, playing a notification.

Inspired by David's comment on https://git.reviewboard.kde.org/r/121278/


Diffs
-

  src/notifybysound.cpp 09a80dd 

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


Testing
---


Thanks,

Albert Astals Cid

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Nov. 8, 2014, 10:02 p.m., David Faure wrote:
> > src/core/kcoredirlister.cpp, line 1241
> > 
> >
> > After this line, try adding
> > 
> > if (!url.isLocalFile()) {
> > const QString localPath = dir->rootItem.localPath();
> > if (!localPath.isEmpty()) {
> > filesToHide = 
> > filesInDotHiddenForDir(QUrl::fromLocalFile(localPath));
> > }
> > }
> > 
> > This should take care of the case of desktop:/ URLs. Can you test?
> 
> Bruno Nova wrote:
> Thanks! I'll test it in a few days. I haven't had time to look into this 
> yet.
> 
> Bruno Nova wrote:
> I finally had the time to look at this again.
> I tested this, and `dir->rootItem.localPath()` does indeed work for the 
> `desktop:/` directory.
> However, from my tests, the root item/current directory (`.`) is not the 
> first item in the UDSEntryList being iterated. So, some files are not hidden.
> I need that rootItem before the loop. I'll see if I can do something 
> about it (without iterating twice or iterating back from `.` in the loop).
> 
> Bruno Nova wrote:
> @David, do you think iterating a second time over the UDSEntryList just 
> to find the ".hidden" file would have a noticeable impact on performance in 
> very large folders? And would it be acceptable?
> I just tried that, and it worked, even in `desktop:/`. I didn't notice 
> any noticeable slowdown when I opened */usr/bin*. I added that second loop 
> above the existing loop (this could then be placed in the 
> `filesInDotHiddenForDir()` method).
> With my limited knowledge of KDE, I don't see another way of getting a 
> KFileItem (of `.` or `.hidden`) from a UDSEntry before that loop (since 
> KFileItem's contructed from QUrl's are not "complete").
> 
> David Faure wrote:
> Hmm, then maybe use localPath on the first item instead, whichever it is, 
> and remove the filename, to go up to the parent directory?

Why didn't I think of that? That seems to be the best solution!


- Bruno


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


On Set. 18, 2014, 10:06 a.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Set. 18, 2014, 10:06 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.h e6ba2ac 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread David Faure 


> On Nov. 8, 2014, 10:02 p.m., David Faure wrote:
> > src/core/kcoredirlister.cpp, line 1241
> > 
> >
> > After this line, try adding
> > 
> > if (!url.isLocalFile()) {
> > const QString localPath = dir->rootItem.localPath();
> > if (!localPath.isEmpty()) {
> > filesToHide = 
> > filesInDotHiddenForDir(QUrl::fromLocalFile(localPath));
> > }
> > }
> > 
> > This should take care of the case of desktop:/ URLs. Can you test?
> 
> Bruno Nova wrote:
> Thanks! I'll test it in a few days. I haven't had time to look into this 
> yet.
> 
> Bruno Nova wrote:
> I finally had the time to look at this again.
> I tested this, and `dir->rootItem.localPath()` does indeed work for the 
> `desktop:/` directory.
> However, from my tests, the root item/current directory (`.`) is not the 
> first item in the UDSEntryList being iterated. So, some files are not hidden.
> I need that rootItem before the loop. I'll see if I can do something 
> about it (without iterating twice or iterating back from `.` in the loop).
> 
> Bruno Nova wrote:
> @David, do you think iterating a second time over the UDSEntryList just 
> to find the ".hidden" file would have a noticeable impact on performance in 
> very large folders? And would it be acceptable?
> I just tried that, and it worked, even in `desktop:/`. I didn't notice 
> any noticeable slowdown when I opened */usr/bin*. I added that second loop 
> above the existing loop (this could then be placed in the 
> `filesInDotHiddenForDir()` method).
> With my limited knowledge of KDE, I don't see another way of getting a 
> KFileItem (of `.` or `.hidden`) from a UDSEntry before that loop (since 
> KFileItem's contructed from QUrl's are not "complete").

Hmm, then maybe use localPath on the first item instead, whichever it is, and 
remove the filename, to go up to the parent directory?


- David


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


On Sept. 18, 2014, 10:06 a.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Sept. 18, 2014, 10:06 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.h e6ba2ac 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Nov. 8, 2014, 10:02 p.m., David Faure wrote:
> > src/core/kcoredirlister.cpp, line 1241
> > 
> >
> > After this line, try adding
> > 
> > if (!url.isLocalFile()) {
> > const QString localPath = dir->rootItem.localPath();
> > if (!localPath.isEmpty()) {
> > filesToHide = 
> > filesInDotHiddenForDir(QUrl::fromLocalFile(localPath));
> > }
> > }
> > 
> > This should take care of the case of desktop:/ URLs. Can you test?
> 
> Bruno Nova wrote:
> Thanks! I'll test it in a few days. I haven't had time to look into this 
> yet.
> 
> Bruno Nova wrote:
> I finally had the time to look at this again.
> I tested this, and `dir->rootItem.localPath()` does indeed work for the 
> `desktop:/` directory.
> However, from my tests, the root item/current directory (`.`) is not the 
> first item in the UDSEntryList being iterated. So, some files are not hidden.
> I need that rootItem before the loop. I'll see if I can do something 
> about it (without iterating twice or iterating back from `.` in the loop).

@David, do you think iterating a second time over the UDSEntryList just to find 
the ".hidden" file would have a noticeable impact on performance in very large 
folders? And would it be acceptable?
I just tried that, and it worked, even in `desktop:/`. I didn't notice any 
noticeable slowdown when I opened */usr/bin*. I added that second loop above 
the existing loop (this could then be placed in the `filesInDotHiddenForDir()` 
method).
With my limited knowledge of KDE, I don't see another way of getting a 
KFileItem (of `.` or `.hidden`) from a UDSEntry before that loop (since 
KFileItem's contructed from QUrl's are not "complete").


- Bruno


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


On Set. 18, 2014, 10:06 a.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Set. 18, 2014, 10:06 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.h e6ba2ac 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

FYI: watch out for Q_GADGET with cmake2.8

2014-12-04 Thread Harald Sitter 
alohas

Qt has a magic macro Q_GADGET which according to a websearch falls
slightly short of magic. It apparently allows non-QObject classes to
grow a metaobject such that one can use properties/enums/invokables.

Now the problem with that is that Q_GADGET is not supported by the
cmake2.8 automoc code, but cmake3 supports it.
This means cmake2.8 won't run automatically run moc which means the
metaglue is not generated which means that a library built with cmake3
potentially has more symbols (the ones for metaobject) on an exported
class than the exactly same source built with cmake2.8. Not good.

A quick grep suggested that only libnm-qt was actually affected by this.
But for future reference I'd like to point out that to use Q_GADGET
one either needs to bump the cmake requirement to >=3 OR better yet
explicitly include the moc'd cpp which will force cmake to run moc on
the header and thus makes it work with cmake2.8

e.g. in foo.cpp at the end #include "moc_foo.cpp"

(also, FWIW, all cases of Q_GADGET I looked at didn't actually need
it... perhaps if you have a defunct Q_GADGET floating about in a
private lib or application you should remove it ;))

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

Re: Review Request 119607: Support for ".hidden" files

2014-12-04 Thread Bruno Nova 


> On Nov. 8, 2014, 10:02 p.m., David Faure wrote:
> > src/core/kcoredirlister.cpp, line 1241
> > 
> >
> > After this line, try adding
> > 
> > if (!url.isLocalFile()) {
> > const QString localPath = dir->rootItem.localPath();
> > if (!localPath.isEmpty()) {
> > filesToHide = 
> > filesInDotHiddenForDir(QUrl::fromLocalFile(localPath));
> > }
> > }
> > 
> > This should take care of the case of desktop:/ URLs. Can you test?
> 
> Bruno Nova wrote:
> Thanks! I'll test it in a few days. I haven't had time to look into this 
> yet.

I finally had the time to look at this again.
I tested this, and `dir->rootItem.localPath()` does indeed work for the 
`desktop:/` directory.
However, from my tests, the root item/current directory (`.`) is not the first 
item in the UDSEntryList being iterated. So, some files are not hidden.
I need that rootItem before the loop. I'll see if I can do something about it 
(without iterating twice or iterating back from `.` in the loop).


- Bruno


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


On Set. 18, 2014, 10:06 a.m., Bruno Nova wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> ---
> 
> (Updated Set. 18, 2014, 10:06 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
> https://bugs.kde.org/show_bug.cgi?id=64740
> https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will 
> be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -
> 
>   src/core/kcoredirlister.h e6ba2ac 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> ---
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested 
> using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added 
> ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the 
> default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 
> 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder 
> widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

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

Jenkins build is back to normal : kemoticons_stable_qt5 #4

2014-12-04 Thread KDE CI System 
See 

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

Jenkins build is back to normal : kemoticons_master_qt5 #82

2014-12-04 Thread KDE CI System 
See 

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

Build failed in Jenkins: kemoticons_stable_qt5 #3

2014-12-04 Thread KDE CI System 
See 

Changes:

[Daniel Vrátil] Add KEmoticonsIntegrationPlugin for KTextToHTML from KCoreAddons

--
[...truncated 26 lines...]
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ef27cc057c07550e9d9b5b503554a4c61d207ff3
 > git rev-list 7a8d7ffd3480c8b981bce2774cf5d968e2912e5b # timeout=10
 > git tag -a -f -m Jenkins Build #3 jenkins-kemoticons_stable_qt5-3 # 
 > timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kemoticons_stable_qt5] $ /bin/sh -xe /tmp/hudson732489907408611.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kemoticons - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 kdoctools - Branch master
 extra-cmake-modules - Branch master
 qt5 - Branch stable
 dogtail - Branch master
 kconfig - Branch master
 cmake - Branch master
 kservice - Branch master
 ki18n - Branch master
 kcrash - Branch master
 karchive - Branch master
 kcoreaddons - Branch master
 kdbusaddons - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.3") 
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Warning (dev) at 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/kdesupport/extra-cmake-modules/inst/share/ECM/modules/ECMGeneratePriFile.cmake:156
 (file):
  Policy CMP0053 is not set: Simplify variable reference and escape sequence
  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  For input:

'QT.@PRI_TARGET_BASENAME@.VERSION = @PROJECT_VERSION_STRING@
QT.@PRI_TARGET_BASENAME@.MAJOR_VERSION = @PROJECT_VERSION_MAJOR@
QT.@PRI_TARGET_BASENAME@.MINOR_VERSION = @PROJECT_VERSION_MINOR@
QT.@PRI_TARGET_BASENAME@.PATCH_VERSION = @PROJECT_VERSION_PATCH@
QT.@PRI_TARGET_BASENAME@.name = @PRI_TARGET_LIBNAME@
QT.@PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
QT.@PRI_TARGET_BASENAME@.includes = @PRI_TARGET_INCLUDES@
QT.@PRI_TARGET_BASENAME@.private_includes =
QT.@PRI_TARGET_BASENAME@.libs = @PRI_TARGET_LIBS@
QT.@PRI_TARGET_BASENAME@.depends = @PRI_TARGET_QTDEPS@
'

  the old evaluation rules produce:

'QT.KEmoticons.VERSION = 5.5.0
QT.KEmoticons.MAJOR_VERSION = 5
QT.KEmoticons.MINOR_VERSION = 5
QT.KEmoticons.PATCH_VERSION = 0
QT.KEmoticons.name = KF5Emoticons
QT.KEmoticons.defines = 
QT.KEmoticons.includes = 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/kemoticons/inst/include/KF5/KEmoticons
QT.KEmoticons.private_includes =
QT.KEmoticons.libs = 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/kemoticons/inst/lib64
QT.KEmoticons.depends = widgets KService
'

  but the new evaluation rules produce:

'QT.@PRI_TARGET_BASENAME@.VERSION = @PROJECT_VERSION_STRING@
QT.@PRI_TARGET_BASENAME@.MAJOR_VERSION = @PROJECT_VERSION_MAJOR@
QT.@PRI_TARGET_BASENAME@.MINOR_VERSION = @PROJECT_VERSION_MINOR@
QT.@PRI_TARGET_BASENAME@.PATCH_VERSION = @PROJECT_VERSION_PATCH@
QT.@PRI_TARGET_BASENAME@.name = @PRI_TARGET_LIBNAME@
QT.@PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
QT.@PRI_TARGET_BASENAME@.includes = @PRI_TARGET_INCLUDES@
QT.@PRI_TARGET_BASENAME@.private_includes =
QT.@PRI_TARGET_BASENAME@.libs = @PRI_TARGET_LIBS@
QT.@PRI_TARGET_BASENAME@.depends = @PRI_TARGET_QTDEPS@
'

  Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
  s

Build failed in Jenkins: kemoticons_master_qt5 #81

2014-12-04 Thread KDE CI System 
See 

Changes:

[Daniel Vrátil] Add KEmoticonsIntegrationPlugin for KTextToHTML from KCoreAddons

--
[...truncated 26 lines...]
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ef27cc057c07550e9d9b5b503554a4c61d207ff3
 > git rev-list 7a8d7ffd3480c8b981bce2774cf5d968e2912e5b # timeout=10
 > git tag -a -f -m Jenkins Build #81 jenkins-kemoticons_master_qt5-81 # 
 > timeout=10
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kemoticons_master_qt5] $ /bin/sh -xe /tmp/hudson2862946587990290980.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kemoticons - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 ki18n - Branch master
 kdoctools - Branch master
 cmake - Branch master
 qt5 - Branch stable
 dogtail - Branch master
 kconfig - Branch master
 kcrash - Branch master
 kservice - Branch master
 karchive - Branch master
 extra-cmake-modules - Branch master
 kdbusaddons - Branch master
 kcoreaddons - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.3") 
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Warning (dev) at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/share/ECM/modules/ECMGeneratePriFile.cmake:156
 (file):
  Policy CMP0053 is not set: Simplify variable reference and escape sequence
  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  For input:

'QT.@PRI_TARGET_BASENAME@.VERSION = @PROJECT_VERSION_STRING@
QT.@PRI_TARGET_BASENAME@.MAJOR_VERSION = @PROJECT_VERSION_MAJOR@
QT.@PRI_TARGET_BASENAME@.MINOR_VERSION = @PROJECT_VERSION_MINOR@
QT.@PRI_TARGET_BASENAME@.PATCH_VERSION = @PROJECT_VERSION_PATCH@
QT.@PRI_TARGET_BASENAME@.name = @PRI_TARGET_LIBNAME@
QT.@PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
QT.@PRI_TARGET_BASENAME@.includes = @PRI_TARGET_INCLUDES@
QT.@PRI_TARGET_BASENAME@.private_includes =
QT.@PRI_TARGET_BASENAME@.libs = @PRI_TARGET_LIBS@
QT.@PRI_TARGET_BASENAME@.depends = @PRI_TARGET_QTDEPS@
'

  the old evaluation rules produce:

'QT.KEmoticons.VERSION = 5.5.0
QT.KEmoticons.MAJOR_VERSION = 5
QT.KEmoticons.MINOR_VERSION = 5
QT.KEmoticons.PATCH_VERSION = 0
QT.KEmoticons.name = KF5Emoticons
QT.KEmoticons.defines = 
QT.KEmoticons.includes = 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kemoticons/inst/include/KF5/KEmoticons
QT.KEmoticons.private_includes =
QT.KEmoticons.libs = 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kemoticons/inst/lib64
QT.KEmoticons.depends = widgets KService
'

  but the new evaluation rules produce:

'QT.@PRI_TARGET_BASENAME@.VERSION = @PROJECT_VERSION_STRING@
QT.@PRI_TARGET_BASENAME@.MAJOR_VERSION = @PROJECT_VERSION_MAJOR@
QT.@PRI_TARGET_BASENAME@.MINOR_VERSION = @PROJECT_VERSION_MINOR@
QT.@PRI_TARGET_BASENAME@.PATCH_VERSION = @PROJECT_VERSION_PATCH@
QT.@PRI_TARGET_BASENAME@.name = @PRI_TARGET_LIBNAME@
QT.@PRI_TARGET_BASENAME@.defines = @PRI_TARGET_DEFINES@
QT.@PRI_TARGET_BASENAME@.includes = @PRI_TARGET_INCLUDES@
QT.@PRI_TARGET_BASENAME@.private_includes =
QT.@PRI_TARGET_BASENAME@.libs = @PRI_TARGET_LIBS@
QT.@PRI_TARGET_BASENAME@.depends = @PRI_TARGET_QTDEPS@
'

  Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
  src/core/CMakeLists

Re: Review Request 121118: KEmoticons: Add a KEmoticonsIntegrationPlugin for KTextToHTML from KCoreAddons

2014-12-04 Thread Daniel Vrátil 

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

(Updated Dec. 4, 2014, 10 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Albert Astals Cid and David Faure.


Repository: kemoticons


Description
---

This patch is related to /r/121094, which moves KTextToHTML conversion utility 
from KPimUtils to KCoreAddons. Since KCoreAddons can't depend on KEmoticons 
needed for smileys conversion, I created a plugin in KEmoticons that implements 
the interface from KCoreAddons. This is based on the FrameworkIntegrationPlugin.


Diffs
-

  CMakeLists.txt 1550bfe 
  autotests/CMakeLists.txt 29b7eb6 
  autotests/ktexttohtmlplugintest.cpp PRE-CREATION 
  src/CMakeLists.txt 7b10087 
  src/integrationplugin/CMakeLists.txt PRE-CREATION 
  src/integrationplugin/kemoticonsintegrationplugin.h PRE-CREATION 
  src/integrationplugin/kemoticonsintegrationplugin.cpp PRE-CREATION 
  src/integrationplugin/ktexttohtml.h PRE-CREATION 
  src/integrationplugin/ktexttohtml.cpp PRE-CREATION 

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


Testing
---


Thanks,

Daniel Vrátil

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

Re: Review Request 121303: detect kde4 home better in kde4 migration

2014-12-04 Thread David Faure 


> On Dec. 4, 2014, 8:42 a.m., David Faure wrote:
> > src/lib/util/kdelibs4migration.cpp, line 52
> > 
> >
> > These 3 lines could be removed then - if KDE4_DEFAULT_HOME doesn't 
> > exist, there isn't much point in pointing to it.
> > 
> > But ok it doesn't change anything in practice, kdeHomeFound() tests for 
> > exists anyway.
> 
> Xuetian Weng wrote:
> Emm. but the reason that KDE4_DEFAULT_HOME being introduced: 
> https://git.reviewboard.kde.org/r/120480/diff/ is that it would be better to 
> leave it non-empty. (in case user install some kde4 app later).

Ah, hmm, ok. Won't work if KDE4_DEFAULT_HOME isn't set, though.

But then it's hard to guess what kdehome should point to, if nothing exists yet.


- David


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


On Dec. 4, 2014, 9:07 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121303/
> ---
> 
> (Updated Dec. 4, 2014, 9:07 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Laurent Montel.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> some really old distribution might use ~/.kde for kde3 and ~/.kde4 for kde4, 
> and in some other case ~/.kde might be existed for random reason.
> 
> This change will change the check order to KDE4_DEFAULT_HOME (from cmake 
> option), .kde4, .kde. So distro can always specify their correct one as the 
> first one. And check ~/.kde4 before ~/.kde seems to be a saner option because 
> they must use "4" for a good reason.
> 
> 
> Diffs
> -
> 
>   src/lib/util/kdelibs4migration.cpp d8d564a 
> 
> Diff: https://git.reviewboard.kde.org/r/121303/diff/
> 
> 
> Testing
> ---
> 
> return ~/.kde4 first even ~/.kde exists.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 121303: detect kde4 home better in kde4 migration

2014-12-04 Thread Xuetian Weng 

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

(Updated Dec. 4, 2014, 9:07 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure and Laurent Montel.


Repository: kcoreaddons


Description
---

some really old distribution might use ~/.kde for kde3 and ~/.kde4 for kde4, 
and in some other case ~/.kde might be existed for random reason.

This change will change the check order to KDE4_DEFAULT_HOME (from cmake 
option), .kde4, .kde. So distro can always specify their correct one as the 
first one. And check ~/.kde4 before ~/.kde seems to be a saner option because 
they must use "4" for a good reason.


Diffs
-

  src/lib/util/kdelibs4migration.cpp d8d564a 

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


Testing
---

return ~/.kde4 first even ~/.kde exists.


Thanks,

Xuetian Weng

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

Re: Review Request 121303: detect kde4 home better in kde4 migration

2014-12-04 Thread Xuetian Weng 


> On Dec. 4, 2014, 8:42 a.m., David Faure wrote:
> > src/lib/util/kdelibs4migration.cpp, line 52
> > 
> >
> > These 3 lines could be removed then - if KDE4_DEFAULT_HOME doesn't 
> > exist, there isn't much point in pointing to it.
> > 
> > But ok it doesn't change anything in practice, kdeHomeFound() tests for 
> > exists anyway.

Emm. but the reason that KDE4_DEFAULT_HOME being introduced: 
https://git.reviewboard.kde.org/r/120480/diff/ is that it would be better to 
leave it non-empty. (in case user install some kde4 app later).


- Xuetian


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


On Dec. 4, 2014, 8:22 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121303/
> ---
> 
> (Updated Dec. 4, 2014, 8:22 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Laurent Montel.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> some really old distribution might use ~/.kde for kde3 and ~/.kde4 for kde4, 
> and in some other case ~/.kde might be existed for random reason.
> 
> This change will change the check order to KDE4_DEFAULT_HOME (from cmake 
> option), .kde4, .kde. So distro can always specify their correct one as the 
> first one. And check ~/.kde4 before ~/.kde seems to be a saner option because 
> they must use "4" for a good reason.
> 
> 
> Diffs
> -
> 
>   src/lib/util/kdelibs4migration.cpp d8d564a 
> 
> Diff: https://git.reviewboard.kde.org/r/121303/diff/
> 
> 
> Testing
> ---
> 
> return ~/.kde4 first even ~/.kde exists.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 121303: detect kde4 home better in kde4 migration

2014-12-04 Thread David Faure 

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

Ship it!



src/lib/util/kdelibs4migration.cpp


These 3 lines could be removed then - if KDE4_DEFAULT_HOME doesn't exist, 
there isn't much point in pointing to it.

But ok it doesn't change anything in practice, kdeHomeFound() tests for 
exists anyway.


- David Faure


On Dec. 4, 2014, 8:22 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121303/
> ---
> 
> (Updated Dec. 4, 2014, 8:22 a.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Laurent Montel.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> some really old distribution might use ~/.kde for kde3 and ~/.kde4 for kde4, 
> and in some other case ~/.kde might be existed for random reason.
> 
> This change will change the check order to KDE4_DEFAULT_HOME (from cmake 
> option), .kde4, .kde. So distro can always specify their correct one as the 
> first one. And check ~/.kde4 before ~/.kde seems to be a saner option because 
> they must use "4" for a good reason.
> 
> 
> Diffs
> -
> 
>   src/lib/util/kdelibs4migration.cpp d8d564a 
> 
> Diff: https://git.reviewboard.kde.org/r/121303/diff/
> 
> 
> Testing
> ---
> 
> return ~/.kde4 first even ~/.kde exists.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 121303: detect kde4 home better in kde4 migration

2014-12-04 Thread Xuetian Weng 

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

(Updated Dec. 4, 2014, 8:22 a.m.)


Review request for KDE Frameworks, David Faure and Laurent Montel.


Repository: kcoreaddons


Description
---

some really old distribution might use ~/.kde for kde3 and ~/.kde4 for kde4, 
and in some other case ~/.kde might be existed for random reason.

This change will change the check order to KDE4_DEFAULT_HOME (from cmake 
option), .kde4, .kde. So distro can always specify their correct one as the 
first one. And check ~/.kde4 before ~/.kde seems to be a saner option because 
they must use "4" for a good reason.


Diffs
-

  src/lib/util/kdelibs4migration.cpp d8d564a 

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


Testing
---

return ~/.kde4 first even ~/.kde exists.


Thanks,

Xuetian Weng

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