Re: Review Request 119505: Instance our onw QFileDialog instead of using getExistingDirectoryUrl

2014-08-02 Thread Àlex Fiestas 

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

(Updated ago. 3, 2014, 12:47 a.m.)


Review request for KDE Frameworks.


Repository: kio


Description
---

getExistingDirectoryUrl only works for local files so we have to implement it 
on our own for now.

As for Qt, QFileDialog::getExistingDirectoryUrl calls QUrl.toLocalFile, if we 
remove that, further down the code path _qt_get_directory is called which 
checks that the file exists but since Qt is not able to talk all our kios (for 
example smb) it will return false.
So at the moment we are forced to implement it ourselves.


Diffs (updated)
-

  src/widgets/kurlrequester.cpp f2837ad 

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


Testing
---


Thanks,

Àlex Fiestas

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

Re: Minimum translation percentage for frameworks release

2014-08-02 Thread Albert Astals Cid 
El Divendres, 1 d'agost de 2014, a les 14:08:54, Alexander Potashev va 
escriure:
> 2014-08-01 13:07 GMT+04:00 Māris Nartišs :
> > As a head of another inactive, barely passing current criteria language
> > team, I would also vote for partially translated strings over no
> > translation at all. If the user doesn't like partially translated
> > dialogs, he can always join the translation team and help to improve the
> > situation.
> > 
> > 
> > The head of Latvian team,
> > Māris Nartišs.
> > 
> > 2014-07-31 22:51 GMT+03:00 Karl Ove Hufthammer :
> >> to. den 31. 07. 2014 klokka 21.14 (+0200) skreiv Vít Pelčák:
> >> > I'm siding with Albert.
> >> > 
> >> > As I translate to Czech language, we basically reached level, when you
> >> > see unstranslated messages only rarely.
> >> > That means, whenever I see untranslated message, I can understand its
> >> > point and am able to fix it.
> >> 
> >> FWIW, I too agree with Albert’s proposal.
> >> 
> >> I work on a language where the KDE translations (of at least some
> >> applications and libraries) are far from complete.
> >> Still, I prefer to see partial translations instead of no translations.
> >> 
> >> This also make it easy to see which strings it is most important to
> >> translate (the ‘high-visibility’ ones, shown in the main application
> >> window and dialogues – rare error message and descriptions of rarely
> >> used preferences dialogues should IMHO not be prioritised when one has
> >> limited manpower for translating).
> 
> Hi Māris and all the others,
> 
> Looks like we reached a consensus. (Those who are only subscribed to
> kde-frameworks-devel, please see in the KDE-i18n-doc mailing list more
> replies for shipping all translations without filtering.)
> 
> Sorry, I totally missed the point about motivation for newcomers in
> translation teams, even though I joined our translation team for the
> same reason as Vít did and around the same 5-6 years ago :)

Good then, no minimal translation percentage for frameworks, easy to implement 
;)

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

Re: Review Request 119512: Fix saving/loading of file dialog sizes

2014-08-02 Thread Ben Cooksley 


On July 28, 2014, 10:17 a.m., Lukáš Tinkl wrote:
> > If the only issue is the open ::exec() TODO, you might "trick" it by 
> > calling ::winId(), then restore the size and ultimately ::exec()
> > 
> > Otherwise you could open an own nested eventloop instead of relying on the 
> > dialogs exec, but that'd be less elegant.
> > 
> > In either case I don't see why bringing your own config re/storage.
> 
> Lukáš Tinkl wrote:
> The trick with winId() unfortunately doesn't work, the dialog gets 
> restored to the default size, not the saved one... :/ Any other ideas?
> 
> Thomas Lübking wrote:
> I'm not gonna say "impossible", but the reason could then not be the 
> absence of a windowHandle()
> Eventually sth. alters the window size post the restore.
> 
> Have you checked for presence of a m_dialog->windowHandle() after calling 
> m_dialog->winId() and m_dialog->size() after calling 
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize")); and before calling m_dialog->exec() ?
> 
> Martin Klapetek wrote:
> KWindowConfig::restoreWindowSize is broken for some reason.
> 
> I did some investigation and basically what happens is this:
>  - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry 
> call
>  - geometry is set to the QWindow, but no to its QWidgets (no idea why)
>  - when event loop hits next loop, widgets are checked if their size >= 
> their min size
>  - because they didn't receive the updated geometry, this^ is not true
>  - the widgets get resized to their min size
>  - the window has a wrong geometry
> 
> I don't know why the widgets don't receive the event however, my 
> knowledge in this is lacking.
> 
> Lukáš Tinkl wrote:
> So how do we proceed with this one? Having tiny filedialogs is annoying 
> as hell...
> 
> Thomas Lübking wrote:
> Fix KWindowConfig::restoreWindowSize, I'd say.
> I assume calling
> 
> + window->create();
> 
> before "window->resize(width, height);" in 
> frameworks/kconfig/src/gui/kwindowconfig.cpp:81 should be be sufficient?
> (This should ensure d->platformWindow->setGeometry(QRect(position(), 
> newSize)); is called in QWindow::resize())
> 
> Lukáš Tinkl wrote:
> Nope, it didn't work unfortunately :/
> 
> Thomas Lübking wrote:
> You must still ensure that there's a QWindow before the Dialog::exec() 
> call, ie. calling ::winId() is still required in addition on this particular 
> case.
> 
> Lukáš Tinkl wrote:
> Done that, didn't help
> 
> Thomas Lübking wrote:
> What's your testcase on this?
> 
> QFileDialog *dlg = new QFileDialog;
> dlg->setFileMode(QFileDialog::Directory);
> dlg->setOption(QFileDialog::ShowDirsOnly);
> dlg->exec();
> 
> gets me a ::windowHandle() before, but *does* get me one after.
> 
> If I then call
> KSharedConfig::Ptr conf = KSharedConfig::openConfig();
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize"));
> 
> and from there 
> window->create();
> right after the
> 
> if (!window) {
>return;
> }
> 
> check, I'm "sorry" to say, but the dialog size now _is_ restored for me.
> 
> 
> --
> What rather seems a problem is that the size does not get stored when eg. 
> closing the dialog via the titlebar "close" button.
> I've to say cancel or ok.
> 
> Lukáš Tinkl wrote:
> Yup, it works with a plain Q(File)Dialog, what doesn't work here is the 
> wrapper due to the abstraction layer in QPA imo
> 
> Thomas Lübking wrote:
> Humm? QFileDialog of course invokes the platformtheme if 
> XDG_CURRENT_DESKTOP is set to KDE.
> 
> 1. I could trace the invocation (strace/qDebug())
> 2. I get a "better" filedialog as compared to an unset (or different, the 
> Gtk+ thing sucks ;-) environment
> 
> With mentioned changes it /does/ work here using 
> /usr/lib/qt/plugins/platformthemes/KDEPlatformTheme.so, ie. this wrapper.
> 
> I'll add two RRs for it.
> 
> Lukáš Tinkl wrote:
> Great, thanks
> 
> Thomas Lübking wrote:
> In case you wonder: I could not create a new request in the past 5h, RB 
> does not respond on the link.
> I'll link them here as soon as RB woke up.

Please report any faults in KDE infrastructure to Sysadmin through our usual 
channels - I have restarted Reviewboard, which will hopefully resolve the issue.


- Ben


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


On July 28, 2014, 10:21 a.m., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119512/
>

Re: Review Request 119577: Allow translations to have context again.

2014-08-02 Thread Matthew Dawson 


> On Aug. 2, 2014, 1:37 p.m., Lukáš Tinkl wrote:
> > Translations might be broken due to 
> > https://bugreports.qt-project.org/browse/QTBUG-40444 , otherwise thanks for 
> > the fix!

Ok, I'll leave this to be picked up in 5.2 then, to avoid breaking the 
translations this cycle.  That should avoid the most breakage.  I'll commit 
after August 7th, so as not to change the translations already done for 5.1.


- Matthew


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


On Aug. 2, 2014, 1:07 p.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119577/
> ---
> 
> (Updated Aug. 2, 2014, 1:07 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Bugs: 337979
> https://bugs.kde.org/show_bug.cgi?id=337979
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Allow translations to have context again.
> 
> Switch to using QT_TRANSLATE_NOOP3 so that context information can be
> given for actions, allowing the translators to do better translations.
> 
> BUG: 337979
> FIXED-IN: 5.1.0
> 
> I don't know if it is worthwhile to get this in for 5.1.0, or wait for 5.2.  
> Would it help the translators to get it in now?  If not, I'll get it in for 
> 5.2 (and update the FIXED-IN tag).
> 
> Also, is there an easy way to test translations?  It compiles, and the test 
> suite does run, but I don't have any translations so I don't know if it 
> actually works.  Any pointers to documentation would be great.
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp eb50888a263e9662bdac6c3e046d653577c003e4 
> 
> Diff: https://git.reviewboard.kde.org/r/119577/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test suite passes.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Re: Review Request 119577: Allow translations to have context again.

2014-08-02 Thread Lukáš Tinkl 

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

Ship it!


Translations might be broken due to 
https://bugreports.qt-project.org/browse/QTBUG-40444 , otherwise thanks for the 
fix!

- Lukáš Tinkl


On Srp. 2, 2014, 7:07 odp., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119577/
> ---
> 
> (Updated Srp. 2, 2014, 7:07 odp.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Bugs: 337979
> https://bugs.kde.org/show_bug.cgi?id=337979
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Allow translations to have context again.
> 
> Switch to using QT_TRANSLATE_NOOP3 so that context information can be
> given for actions, allowing the translators to do better translations.
> 
> BUG: 337979
> FIXED-IN: 5.1.0
> 
> I don't know if it is worthwhile to get this in for 5.1.0, or wait for 5.2.  
> Would it help the translators to get it in now?  If not, I'll get it in for 
> 5.2 (and update the FIXED-IN tag).
> 
> Also, is there an easy way to test translations?  It compiles, and the test 
> suite does run, but I don't have any translations so I don't know if it 
> actually works.  Any pointers to documentation would be great.
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp eb50888a263e9662bdac6c3e046d653577c003e4 
> 
> Diff: https://git.reviewboard.kde.org/r/119577/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test suite passes.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Review Request 119577: Allow translations to have context again.

2014-08-02 Thread Matthew Dawson 

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

Review request for KDE Frameworks and Matthew Dawson.


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


Repository: kconfig


Description
---

Allow translations to have context again.

Switch to using QT_TRANSLATE_NOOP3 so that context information can be
given for actions, allowing the translators to do better translations.

BUG: 337979
FIXED-IN: 5.1.0

I don't know if it is worthwhile to get this in for 5.1.0, or wait for 5.2.  
Would it help the translators to get it in now?  If not, I'll get it in for 5.2 
(and update the FIXED-IN tag).

Also, is there an easy way to test translations?  It compiles, and the test 
suite does run, but I don't have any translations so I don't know if it 
actually works.  Any pointers to documentation would be great.


Diffs
-

  src/gui/kstandardshortcut.cpp eb50888a263e9662bdac6c3e046d653577c003e4 

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


Testing
---

Compiles, test suite passes.


Thanks,

Matthew Dawson

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

Re: Review Request 119512: Fix saving/loading of file dialog sizes

2014-08-02 Thread Thomas Lübking 


On Juli 28, 2014, 10:17 vorm., Lukáš Tinkl wrote:
> > If the only issue is the open ::exec() TODO, you might "trick" it by 
> > calling ::winId(), then restore the size and ultimately ::exec()
> > 
> > Otherwise you could open an own nested eventloop instead of relying on the 
> > dialogs exec, but that'd be less elegant.
> > 
> > In either case I don't see why bringing your own config re/storage.
> 
> Lukáš Tinkl wrote:
> The trick with winId() unfortunately doesn't work, the dialog gets 
> restored to the default size, not the saved one... :/ Any other ideas?
> 
> Thomas Lübking wrote:
> I'm not gonna say "impossible", but the reason could then not be the 
> absence of a windowHandle()
> Eventually sth. alters the window size post the restore.
> 
> Have you checked for presence of a m_dialog->windowHandle() after calling 
> m_dialog->winId() and m_dialog->size() after calling 
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize")); and before calling m_dialog->exec() ?
> 
> Martin Klapetek wrote:
> KWindowConfig::restoreWindowSize is broken for some reason.
> 
> I did some investigation and basically what happens is this:
>  - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry 
> call
>  - geometry is set to the QWindow, but no to its QWidgets (no idea why)
>  - when event loop hits next loop, widgets are checked if their size >= 
> their min size
>  - because they didn't receive the updated geometry, this^ is not true
>  - the widgets get resized to their min size
>  - the window has a wrong geometry
> 
> I don't know why the widgets don't receive the event however, my 
> knowledge in this is lacking.
> 
> Lukáš Tinkl wrote:
> So how do we proceed with this one? Having tiny filedialogs is annoying 
> as hell...
> 
> Thomas Lübking wrote:
> Fix KWindowConfig::restoreWindowSize, I'd say.
> I assume calling
> 
> + window->create();
> 
> before "window->resize(width, height);" in 
> frameworks/kconfig/src/gui/kwindowconfig.cpp:81 should be be sufficient?
> (This should ensure d->platformWindow->setGeometry(QRect(position(), 
> newSize)); is called in QWindow::resize())
> 
> Lukáš Tinkl wrote:
> Nope, it didn't work unfortunately :/
> 
> Thomas Lübking wrote:
> You must still ensure that there's a QWindow before the Dialog::exec() 
> call, ie. calling ::winId() is still required in addition on this particular 
> case.
> 
> Lukáš Tinkl wrote:
> Done that, didn't help
> 
> Thomas Lübking wrote:
> What's your testcase on this?
> 
> QFileDialog *dlg = new QFileDialog;
> dlg->setFileMode(QFileDialog::Directory);
> dlg->setOption(QFileDialog::ShowDirsOnly);
> dlg->exec();
> 
> gets me a ::windowHandle() before, but *does* get me one after.
> 
> If I then call
> KSharedConfig::Ptr conf = KSharedConfig::openConfig();
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize"));
> 
> and from there 
> window->create();
> right after the
> 
> if (!window) {
>return;
> }
> 
> check, I'm "sorry" to say, but the dialog size now _is_ restored for me.
> 
> 
> --
> What rather seems a problem is that the size does not get stored when eg. 
> closing the dialog via the titlebar "close" button.
> I've to say cancel or ok.
> 
> Lukáš Tinkl wrote:
> Yup, it works with a plain Q(File)Dialog, what doesn't work here is the 
> wrapper due to the abstraction layer in QPA imo
> 
> Thomas Lübking wrote:
> Humm? QFileDialog of course invokes the platformtheme if 
> XDG_CURRENT_DESKTOP is set to KDE.
> 
> 1. I could trace the invocation (strace/qDebug())
> 2. I get a "better" filedialog as compared to an unset (or different, the 
> Gtk+ thing sucks ;-) environment
> 
> With mentioned changes it /does/ work here using 
> /usr/lib/qt/plugins/platformthemes/KDEPlatformTheme.so, ie. this wrapper.
> 
> I'll add two RRs for it.
> 
> Lukáš Tinkl wrote:
> Great, thanks

In case you wonder: I could not create a new request in the past 5h, RB does 
not respond on the link.
I'll link them here as soon as RB woke up.


- Thomas


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


On Juli 28, 2014, 10:21 vorm., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119512/
> ---
> 
> (Updated Juli 28, 2014, 10:21 vorm.)
> 
> 
> Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, and Martin 
> Klapetek.
> 
> 
> Repos

KDE Frameworks 5.1.0 release

2014-08-02 Thread David Faure 
I just tagged and packed 5.1.0.

Main changes:
* KTextEditor: Major refactorings and improvements of the vi-mode
* KAuth: Now based on PolkitQt5-1
* New migration agent for KWallet
* Windows compilation fixes

* Internationalization fixes
* New install dir for kxmlgui files
* A number of bugfixes

k-f-d: anything to add?

If changelogs in announcements are useful, then we should start using 
ChangeLog lines in commits like Qt does, it would save me time digging into my 
email archive and trying to summarize series of commits...

-- 
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: Web Shortcuts KCM

2014-08-02 Thread Kevin Ottens 
On Saturday 02 August 2014 11:50:17 David Faure wrote:
> Then let's go more "bare bones" in frameworks that can't afford the
> KConfigWidgets dependency, but let's provide the more convenient and more
> usable "out of the box" solution in frameworks that can provide it, such as
> KIO?

Well, if you see no problem in growing your dependency on KConfigWidgets sure. 
You're maintaining KIO after all.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



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: Review Request 119512: Fix saving/loading of file dialog sizes

2014-08-02 Thread Lukáš Tinkl 


On Čec. 28, 2014, 12:17 odp., Lukáš Tinkl wrote:
> > If the only issue is the open ::exec() TODO, you might "trick" it by 
> > calling ::winId(), then restore the size and ultimately ::exec()
> > 
> > Otherwise you could open an own nested eventloop instead of relying on the 
> > dialogs exec, but that'd be less elegant.
> > 
> > In either case I don't see why bringing your own config re/storage.
> 
> Lukáš Tinkl wrote:
> The trick with winId() unfortunately doesn't work, the dialog gets 
> restored to the default size, not the saved one... :/ Any other ideas?
> 
> Thomas Lübking wrote:
> I'm not gonna say "impossible", but the reason could then not be the 
> absence of a windowHandle()
> Eventually sth. alters the window size post the restore.
> 
> Have you checked for presence of a m_dialog->windowHandle() after calling 
> m_dialog->winId() and m_dialog->size() after calling 
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize")); and before calling m_dialog->exec() ?
> 
> Martin Klapetek wrote:
> KWindowConfig::restoreWindowSize is broken for some reason.
> 
> I did some investigation and basically what happens is this:
>  - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry 
> call
>  - geometry is set to the QWindow, but no to its QWidgets (no idea why)
>  - when event loop hits next loop, widgets are checked if their size >= 
> their min size
>  - because they didn't receive the updated geometry, this^ is not true
>  - the widgets get resized to their min size
>  - the window has a wrong geometry
> 
> I don't know why the widgets don't receive the event however, my 
> knowledge in this is lacking.
> 
> Lukáš Tinkl wrote:
> So how do we proceed with this one? Having tiny filedialogs is annoying 
> as hell...
> 
> Thomas Lübking wrote:
> Fix KWindowConfig::restoreWindowSize, I'd say.
> I assume calling
> 
> + window->create();
> 
> before "window->resize(width, height);" in 
> frameworks/kconfig/src/gui/kwindowconfig.cpp:81 should be be sufficient?
> (This should ensure d->platformWindow->setGeometry(QRect(position(), 
> newSize)); is called in QWindow::resize())
> 
> Lukáš Tinkl wrote:
> Nope, it didn't work unfortunately :/
> 
> Thomas Lübking wrote:
> You must still ensure that there's a QWindow before the Dialog::exec() 
> call, ie. calling ::winId() is still required in addition on this particular 
> case.
> 
> Lukáš Tinkl wrote:
> Done that, didn't help
> 
> Thomas Lübking wrote:
> What's your testcase on this?
> 
> QFileDialog *dlg = new QFileDialog;
> dlg->setFileMode(QFileDialog::Directory);
> dlg->setOption(QFileDialog::ShowDirsOnly);
> dlg->exec();
> 
> gets me a ::windowHandle() before, but *does* get me one after.
> 
> If I then call
> KSharedConfig::Ptr conf = KSharedConfig::openConfig();
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize"));
> 
> and from there 
> window->create();
> right after the
> 
> if (!window) {
>return;
> }
> 
> check, I'm "sorry" to say, but the dialog size now _is_ restored for me.
> 
> 
> --
> What rather seems a problem is that the size does not get stored when eg. 
> closing the dialog via the titlebar "close" button.
> I've to say cancel or ok.
> 
> Lukáš Tinkl wrote:
> Yup, it works with a plain Q(File)Dialog, what doesn't work here is the 
> wrapper due to the abstraction layer in QPA imo
> 
> Thomas Lübking wrote:
> Humm? QFileDialog of course invokes the platformtheme if 
> XDG_CURRENT_DESKTOP is set to KDE.
> 
> 1. I could trace the invocation (strace/qDebug())
> 2. I get a "better" filedialog as compared to an unset (or different, the 
> Gtk+ thing sucks ;-) environment
> 
> With mentioned changes it /does/ work here using 
> /usr/lib/qt/plugins/platformthemes/KDEPlatformTheme.so, ie. this wrapper.
> 
> I'll add two RRs for it.

Great, thanks


- Lukáš


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


On Čec. 28, 2014, 12:21 odp., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119512/
> ---
> 
> (Updated Čec. 28, 2014, 12:21 odp.)
> 
> 
> Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, and Martin 
> Klapetek.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> This patch tries to fix saving/restoring file dialog sizes. Using 
> KWindowConfig::restoreWindowSize() doesn't work

Re: Review Request 119512: Fix saving/loading of file dialog sizes

2014-08-02 Thread Thomas Lübking 


On Juli 28, 2014, 10:17 vorm., Lukáš Tinkl wrote:
> > If the only issue is the open ::exec() TODO, you might "trick" it by 
> > calling ::winId(), then restore the size and ultimately ::exec()
> > 
> > Otherwise you could open an own nested eventloop instead of relying on the 
> > dialogs exec, but that'd be less elegant.
> > 
> > In either case I don't see why bringing your own config re/storage.
> 
> Lukáš Tinkl wrote:
> The trick with winId() unfortunately doesn't work, the dialog gets 
> restored to the default size, not the saved one... :/ Any other ideas?
> 
> Thomas Lübking wrote:
> I'm not gonna say "impossible", but the reason could then not be the 
> absence of a windowHandle()
> Eventually sth. alters the window size post the restore.
> 
> Have you checked for presence of a m_dialog->windowHandle() after calling 
> m_dialog->winId() and m_dialog->size() after calling 
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize")); and before calling m_dialog->exec() ?
> 
> Martin Klapetek wrote:
> KWindowConfig::restoreWindowSize is broken for some reason.
> 
> I did some investigation and basically what happens is this:
>  - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry 
> call
>  - geometry is set to the QWindow, but no to its QWidgets (no idea why)
>  - when event loop hits next loop, widgets are checked if their size >= 
> their min size
>  - because they didn't receive the updated geometry, this^ is not true
>  - the widgets get resized to their min size
>  - the window has a wrong geometry
> 
> I don't know why the widgets don't receive the event however, my 
> knowledge in this is lacking.
> 
> Lukáš Tinkl wrote:
> So how do we proceed with this one? Having tiny filedialogs is annoying 
> as hell...
> 
> Thomas Lübking wrote:
> Fix KWindowConfig::restoreWindowSize, I'd say.
> I assume calling
> 
> + window->create();
> 
> before "window->resize(width, height);" in 
> frameworks/kconfig/src/gui/kwindowconfig.cpp:81 should be be sufficient?
> (This should ensure d->platformWindow->setGeometry(QRect(position(), 
> newSize)); is called in QWindow::resize())
> 
> Lukáš Tinkl wrote:
> Nope, it didn't work unfortunately :/
> 
> Thomas Lübking wrote:
> You must still ensure that there's a QWindow before the Dialog::exec() 
> call, ie. calling ::winId() is still required in addition on this particular 
> case.
> 
> Lukáš Tinkl wrote:
> Done that, didn't help
> 
> Thomas Lübking wrote:
> What's your testcase on this?
> 
> QFileDialog *dlg = new QFileDialog;
> dlg->setFileMode(QFileDialog::Directory);
> dlg->setOption(QFileDialog::ShowDirsOnly);
> dlg->exec();
> 
> gets me a ::windowHandle() before, but *does* get me one after.
> 
> If I then call
> KSharedConfig::Ptr conf = KSharedConfig::openConfig();
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize"));
> 
> and from there 
> window->create();
> right after the
> 
> if (!window) {
>return;
> }
> 
> check, I'm "sorry" to say, but the dialog size now _is_ restored for me.
> 
> 
> --
> What rather seems a problem is that the size does not get stored when eg. 
> closing the dialog via the titlebar "close" button.
> I've to say cancel or ok.
> 
> Lukáš Tinkl wrote:
> Yup, it works with a plain Q(File)Dialog, what doesn't work here is the 
> wrapper due to the abstraction layer in QPA imo

Humm? QFileDialog of course invokes the platformtheme if XDG_CURRENT_DESKTOP is 
set to KDE.

1. I could trace the invocation (strace/qDebug())
2. I get a "better" filedialog as compared to an unset (or different, the Gtk+ 
thing sucks ;-) environment

With mentioned changes it /does/ work here using 
/usr/lib/qt/plugins/platformthemes/KDEPlatformTheme.so, ie. this wrapper.

I'll add two RRs for it.


- Thomas


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


On Juli 28, 2014, 10:21 vorm., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119512/
> ---
> 
> (Updated Juli 28, 2014, 10:21 vorm.)
> 
> 
> Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, and Martin 
> Klapetek.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> This patch tries to fix saving/restoring file dialog sizes. Using 
> KWindowConfig::restoreWindowSize() doesn't work here with the modal exec() 
> methods. Instead, the patch uses the same method as KDirSelec

Re: Web Shortcuts KCM

2014-08-02 Thread David Faure 
On Wednesday 16 July 2014 21:12:25 Kevin Krammer wrote:
> On Wednesday, 2014-07-16, 10:33:43, David Faure wrote:
> > On Tuesday 15 July 2014 15:16:20 Kevin Ottens wrote:
> > >  (ie at most a
> > > 
> > > widget would be enough for the app related settings, we should talk to
> > > the
> > > underlying platform for the other ones).
> > 
> > I don't want users to have to configure their search engines in 10 KDE
> > apps
> > one after the other by hand.
> > A centralized configuration is much more convenient.
> 
> Hmm, what if KDE applications outside a KDE workspace are seen as separate
> entities by users of those other workspaces?

Then they will not have configurable web-shortcuts, or if we really want that, 
we need a widget for doing so, but not if it means making things more 
difficult for the "regular KDE workspace user". I.e. the app-specific 
configuration should sit on top of the global configuration,
so that KDE-worskpace users can set things globally and standalone-app users 
can set things from within the app.

This is the "solution that makes everyone happy" by making things over-
configurable.

The alternative, web shortcuts not being configurable unless you use a KDE 
workspace, is IMHO valid too.

But worsening the experience for our primary target audience in order to 
possibly improve the experience of our secondary target audience is IMHO a bad 
move.

-- 
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: Web Shortcuts KCM

2014-08-02 Thread David Faure 
On Friday 18 July 2014 00:37:02 Kevin Ottens wrote:
> On Thursday 17 July 2014 10:37:45 David Faure wrote:
> > On Wednesday 16 July 2014 22:05:21 Kevin Ottens wrote:
> > > On Wednesday 16 July 2014 10:33:43 David Faure wrote:
> > > > On Tuesday 15 July 2014 15:16:20 Kevin Ottens wrote:
> > > > >  (ie at most a
> > > > > 
> > > > > widget would be enough for the app related settings, we should talk
> > > > > to
> > > > > the
> > > > > underlying platform for the other ones).
> > > > 
> > > > I don't want users to have to configure their search engines in 10 KDE
> > > > apps
> > > > one after the other by hand.
> > > > A centralized configuration is much more convenient.
> > > 
> > > Maybe I was unclear, but I didn't mean to imply that for something like
> > > the
> > > web shortcuts having a centralized configuration was wrong. I think that
> > > shipping a KCM is wrong. But I'm fine with a widget which provide mean
> > > to
> > > save in a centralized configuration.
> > 
> > OK, then what is the difference with making that widget inherit from
> > KCModule so that it's also available in systemsettings - as long as the
> > applications also show that KCModule directly in the application, like
> > konqueror does when you use "Configure Konqueror" ?
> 
> In the general case, as a potential pattern (I'm not thinking KIO only) it'd
> mean bringing a dependency on KConfigWidgets.
> In the case of KIO it's less of a concern since the dependency is already
> there. But it means bringing dependencies on the auth system and
> KCMModuleProxy, on the buttons, on about data, on KConfigDialogManager. To
> me it shouts forcing all that on user code even when not needed.

Then let's go more "bare bones" in frameworks that can't afford the 
KConfigWidgets dependency, but let's provide the more convenient and more 
usable "out of the box" solution in frameworks that can provide it, such as 
KIO?

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

Jenkins build is back to normal : krunner_master_qt5 #91

2014-08-02 Thread KDE CI System 
See 

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

Re: Review Request 119564: Add define to re-enable Qt functionality we depend on.

2014-08-02 Thread Alex Merry 

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


I would rather change the code. The Qt behaviour was changed for a reason, to 
prevent accidental use of dangerous behaviour, and I'm not too keen on undoing 
that move for all software that uses KDECompilerSettings.

- Alex Merry


On Aug. 1, 2014, 4:06 p.m., Axel Rasmussen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119564/
> ---
> 
> (Updated Aug. 1, 2014, 4:06 p.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Bugs: 337472
> http://bugs.kde.org/show_bug.cgi?id=337472
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Upstream Qt commit e112c2e altered the way QExplicitlySharedDataPointer 
> behaves by default, such that it no longer uses a `static_cast` to cast 
> compatible pointers. A nontrivial amount of KDE code (I encountered the build 
> error in KService, although there are other users) depends on this 
> functionality, so this commit adds a define to the build system which 
> re-enables the code in Qt.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake fdc930e 
> 
> Diff: https://git.reviewboard.kde.org/r/119564/diff/
> 
> 
> Testing
> ---
> 
> I applied this patch, attempted to build KService, and the build succeeded, 
> rather than exhibiting the compile errors found in the log provided on the 
> bug report.
> 
> 
> Thanks,
> 
> Axel Rasmussen
> 
>

___
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 : kwallet_master_qt5 #150

2014-08-02 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 : kded_master_qt5 #73

2014-08-02 Thread KDE CI System 
See 

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

KF5 ThreadWeaver Examples?

2014-08-02 Thread Brian Duffy 
Hi,

I'm interested in toying around with ThreadWeaver in my Qt5 application. I
installed ThreadWeaver on my Fedora box from the repo on COPR. I can't find
any example code. I'm not sure where else to look. Any suggestions?

Thanks

Brian

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

Re: Review Request 119510: Fix untranslated menu entries

2014-08-02 Thread Lukáš Tinkl 

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

(Updated Aug. 2, 2014, 8:55 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Repository: kservice


Description
---

This patch fixes QLocale usage in kbuildsycoca by not setting the default C 
locale when creating the sycoca database (leftover from a KLocale port?). 
Otherwise this results in menu entries being in English only (in effect 
KDesktopFile, KService and other classes returning the original strings instead 
of the uset-visible translated messages)


Diffs
-

  src/kbuildsycoca/kbuildsycoca.cpp 2f8405c 
  src/services/kservice.cpp c2b5ccf 

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


Testing
---

Current Plasma 5 workspace/desktop


File Attachments


translated systemsettings
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/6989a707-ab72-46f0-8d3d-c61edd969e43__systemsettings.png


Thanks,

Lukáš Tinkl

___
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 : kservice_master_qt5 #173

2014-08-02 Thread KDE CI System 
See 

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

Re: Review Request 119510: Fix untranslated menu entries

2014-08-02 Thread David Faure 

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

Ship it!


Ship It!

- David Faure


On July 28, 2014, 2:28 p.m., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119510/
> ---
> 
> (Updated July 28, 2014, 2:28 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> This patch fixes QLocale usage in kbuildsycoca by not setting the default C 
> locale when creating the sycoca database (leftover from a KLocale port?). 
> Otherwise this results in menu entries being in English only (in effect 
> KDesktopFile, KService and other classes returning the original strings 
> instead of the uset-visible translated messages)
> 
> 
> Diffs
> -
> 
>   src/kbuildsycoca/kbuildsycoca.cpp 2f8405c 
>   src/services/kservice.cpp c2b5ccf 
> 
> Diff: https://git.reviewboard.kde.org/r/119510/diff/
> 
> 
> Testing
> ---
> 
> Current Plasma 5 workspace/desktop
> 
> 
> File Attachments
> 
> 
> translated systemsettings
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/6989a707-ab72-46f0-8d3d-c61edd969e43__systemsettings.png
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

___
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 : kio_master_qt5 #312

2014-08-02 Thread KDE CI System 
See 

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

Re: Review Request 119512: Fix saving/loading of file dialog sizes

2014-08-02 Thread Lukáš Tinkl 


On Čec. 28, 2014, 12:17 odp., Lukáš Tinkl wrote:
> > If the only issue is the open ::exec() TODO, you might "trick" it by 
> > calling ::winId(), then restore the size and ultimately ::exec()
> > 
> > Otherwise you could open an own nested eventloop instead of relying on the 
> > dialogs exec, but that'd be less elegant.
> > 
> > In either case I don't see why bringing your own config re/storage.
> 
> Lukáš Tinkl wrote:
> The trick with winId() unfortunately doesn't work, the dialog gets 
> restored to the default size, not the saved one... :/ Any other ideas?
> 
> Thomas Lübking wrote:
> I'm not gonna say "impossible", but the reason could then not be the 
> absence of a windowHandle()
> Eventually sth. alters the window size post the restore.
> 
> Have you checked for presence of a m_dialog->windowHandle() after calling 
> m_dialog->winId() and m_dialog->size() after calling 
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize")); and before calling m_dialog->exec() ?
> 
> Martin Klapetek wrote:
> KWindowConfig::restoreWindowSize is broken for some reason.
> 
> I did some investigation and basically what happens is this:
>  - KWindowConfig::restoreWindowSize resutls in QXcbWindow::setGeometry 
> call
>  - geometry is set to the QWindow, but no to its QWidgets (no idea why)
>  - when event loop hits next loop, widgets are checked if their size >= 
> their min size
>  - because they didn't receive the updated geometry, this^ is not true
>  - the widgets get resized to their min size
>  - the window has a wrong geometry
> 
> I don't know why the widgets don't receive the event however, my 
> knowledge in this is lacking.
> 
> Lukáš Tinkl wrote:
> So how do we proceed with this one? Having tiny filedialogs is annoying 
> as hell...
> 
> Thomas Lübking wrote:
> Fix KWindowConfig::restoreWindowSize, I'd say.
> I assume calling
> 
> + window->create();
> 
> before "window->resize(width, height);" in 
> frameworks/kconfig/src/gui/kwindowconfig.cpp:81 should be be sufficient?
> (This should ensure d->platformWindow->setGeometry(QRect(position(), 
> newSize)); is called in QWindow::resize())
> 
> Lukáš Tinkl wrote:
> Nope, it didn't work unfortunately :/
> 
> Thomas Lübking wrote:
> You must still ensure that there's a QWindow before the Dialog::exec() 
> call, ie. calling ::winId() is still required in addition on this particular 
> case.
> 
> Lukáš Tinkl wrote:
> Done that, didn't help
> 
> Thomas Lübking wrote:
> What's your testcase on this?
> 
> QFileDialog *dlg = new QFileDialog;
> dlg->setFileMode(QFileDialog::Directory);
> dlg->setOption(QFileDialog::ShowDirsOnly);
> dlg->exec();
> 
> gets me a ::windowHandle() before, but *does* get me one after.
> 
> If I then call
> KSharedConfig::Ptr conf = KSharedConfig::openConfig();
> KWindowConfig::restoreWindowSize(m_dialog->windowHandle(), 
> conf->group("FileDialogSize"));
> 
> and from there 
> window->create();
> right after the
> 
> if (!window) {
>return;
> }
> 
> check, I'm "sorry" to say, but the dialog size now _is_ restored for me.
> 
> 
> --
> What rather seems a problem is that the size does not get stored when eg. 
> closing the dialog via the titlebar "close" button.
> I've to say cancel or ok.

Yup, it works with a plain Q(File)Dialog, what doesn't work here is the wrapper 
due to the abstraction layer in QPA imo


- Lukáš


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


On Čec. 28, 2014, 12:21 odp., Lukáš Tinkl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119512/
> ---
> 
> (Updated Čec. 28, 2014, 12:21 odp.)
> 
> 
> Review request for KDE Frameworks, kdelibs, Aleix Pol Gonzalez, and Martin 
> Klapetek.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> This patch tries to fix saving/restoring file dialog sizes. Using 
> KWindowConfig::restoreWindowSize() doesn't work here with the modal exec() 
> methods. Instead, the patch uses the same method as KDirSelectDialog. 
> 
> 
> Diffs
> -
> 
>   src/platformtheme/kdeplatformfiledialoghelper.h 406a4f1 
>   src/platformtheme/kdeplatformfiledialoghelper.cpp 520b6f5 
>   src/platformtheme/kdirselectdialog.cpp 9a4082a 
>   src/platformtheme/kdirselectdialog_p.h 5a8e758 
> 
> Diff: https://git.reviewboard.kde.org/r/119512/diff/
> 
> 
> Testing
> ---
> 
> Current Plasma 5, working fine :)
> 
> 
> Thanks,
> 
> Lukáš Tinkl
> 
>

__

Jenkins build became unstable: kwindowsystem_master_qt5 » All,LINBUILDER #86

2014-08-02 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: kwallet_master_qt5 #149

2014-08-02 Thread KDE CI System 
See 

Changes:

[scripty] Upgrade ECM and KF5 version requirements for 5.1.0 release.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[kwallet_master_qt5] $ /bin/sh -xe /tmp/hudson1226171927511343105.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kwallet
   2e00df7..9b2c676  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 2e00df7 Fix error message to give user a hint about encrypting 
errors
Removing build/
Removing dotdata/
Removing local-inst/
Success build forhudson.tasks.Shell@401246b3
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/kwallet
Fetching upstream changes from git://anongit.kde.org/kwallet
 > git --version
 > git fetch --tags --progress git://anongit.kde.org/kwallet 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/refs/heads/jenkins^{commit}
 > git rev-parse refs/heads/jenkins^{commit}
Checking out Revision 9b2c676703a88f858cefe82300d6fee64170e72a 
(refs/heads/jenkins)
 > git config core.sparsecheckout
 > git checkout -f 9b2c676703a88f858cefe82300d6fee64170e72a
 > git rev-list c155132d47b9a544109d749dba8111b73c793ef4
 > git tag -a -f -m Jenkins Build #149 jenkins-kwallet_master_qt5-149
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kwallet_master_qt5] $ /bin/sh -xe /tmp/hudson1186265776776244204.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kwallet - Branch master
== Build Dependencies:
 polkit-qt-1 - Branch master
 kdoctools - Branch master
 kcrash - Branch master
 kwidgetsaddons - Branch master
 kitemviews - Branch master
 kauth - Branch master
 kservice - Branch master
 dogtail - Branch master
 kdbusaddons - Branch master
 kguiaddons - Branch master
 kconfig - Branch master
 ki18n - Branch master
 kiconthemes - Branch master
 cmake - Branch master
 knotifications - Branch master
 kcodecs - Branch master
 kwindowsystem - Branch master
 qt5 - Branch stable
 kcoreaddons - Branch master
 kconfigwidgets - Branch master
 phonon - Branch master
 extra-cmake-modules - Branch master
 karchive - 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
-- 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
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- 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 Error at src/runtime/kwalletd/CMakeLists.txt:7 (find_package):
  Could not find a configuration file for package "KF5DBusAddons" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdbusaddons/inst/lib64/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake,
 version: 5.0.0



-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kwallet.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/list

Build failed in Jenkins: kservice_master_qt5 #172

2014-08-02 Thread KDE CI System 
See 

Changes:

[scripty] Upgrade ECM and KF5 version requirements for 5.1.0 release.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[kservice_master_qt5] $ /bin/sh -xe /tmp/hudson6434115114697300728.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kservice
   803fcc2..cdead69  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 803fcc2 Upgrade KF5 version.
Removing build/
Removing dotdata/
Removing local-inst/
Success build forhudson.tasks.Shell@310c2eab
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/kservice
Fetching upstream changes from git://anongit.kde.org/kservice
 > git --version
 > git fetch --tags --progress git://anongit.kde.org/kservice 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/refs/heads/jenkins^{commit}
 > git rev-parse refs/heads/jenkins^{commit}
Checking out Revision cdead692ff34a864abc0611e2c6cf39bcbd5d062 
(refs/heads/jenkins)
 > git config core.sparsecheckout
 > git checkout -f cdead692ff34a864abc0611e2c6cf39bcbd5d062
 > git rev-list 803fcc2f375e986361e81a24b33f0212ee56503c
 > git tag -a -f -m Jenkins Build #172 jenkins-kservice_master_qt5-172
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kservice_master_qt5] $ /bin/sh -xe /tmp/hudson5507212911345715064.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kservice - Branch master
== Build Dependencies:
 kwindowsystem - Branch master
 cmake - Branch master
 ki18n - Branch master
 kdbusaddons - Branch master
 kcrash - Branch master
 kdoctools - Branch master
 extra-cmake-modules - Branch master
 qt5 - Branch stable
 karchive - Branch master
 kcoreaddons - Branch master
 kconfig - Branch master
 dogtail - 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
-- 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
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:37 (find_package):
  Could not find a configuration file for package "KF5DBusAddons" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdbusaddons/inst/lib64/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake,
 version: 5.0.0



-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kservice.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: krunner_master_qt5 #90

2014-08-02 Thread KDE CI System 
See 

Changes:

[scripty] Upgrade ECM and KF5 version requirements for 5.1.0 release.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[krunner_master_qt5] $ /bin/sh -xe /tmp/hudson4098697398239001877.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/krunner
   8f4d451..42839ea  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 8f4d451 Upgrade KF5 version.
Removing build/
Removing dotdata/
Removing local-inst/
Success build forhudson.tasks.Shell@6d34493d
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/krunner
Fetching upstream changes from git://anongit.kde.org/krunner
 > git --version
 > git fetch --tags --progress git://anongit.kde.org/krunner 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/refs/heads/jenkins^{commit}
 > git rev-parse refs/heads/jenkins^{commit}
Checking out Revision 42839ea611b41adc71eb196ae684bc3bcbac02ef 
(refs/heads/jenkins)
 > git config core.sparsecheckout
 > git checkout -f 42839ea611b41adc71eb196ae684bc3bcbac02ef
 > git rev-list 8f4d4512b77c096a56558146055c5ce03bc130f0
 > git tag -a -f -m Jenkins Build #90 jenkins-krunner_master_qt5-90
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[krunner_master_qt5] $ /bin/sh -xe /tmp/hudson329621896618760370.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: krunner - Branch master
== Build Dependencies:
 sonnet - Branch master
 kitemviews - Branch master
 polkit-qt-1 - Branch master
 kdoctools - Branch master
 kwallet - Branch master
 phonon - Branch master
 kcrash - Branch master
 kwidgetsaddons - Branch master
 kdeclarative - Branch master
 kjobwidgets - Branch master
 kauth - Branch master
 kservice - Branch master
 ki18n - Branch master
 dogtail - Branch master
 kidletime - Branch master
 kdbusaddons - Branch master
 kguiaddons - Branch master
 kconfig - Branch master
 kactivities - Branch master
 kiconthemes - Branch master
 cmake - Branch master
 kunitconversion - Branch master
 solid - Branch master
 kbookmarks - Branch master
 knotifications - Branch master
 kwindowsystem - Branch master
 qt5 - Branch stable
 kcodecs - Branch master
 ktextwidgets - Branch master
 karchive - Branch master
 kparts - Branch master
 kross - Branch master
 kglobalaccel - Branch master
 kconfigwidgets - Branch master
 attica - Branch master
 plasma-framework - Branch master
 kxmlgui - Branch master
 kdnssd - Branch master
 threadweaver - Branch master
 kitemmodels - Branch master
 kjs - Branch master
 extra-cmake-modules - Branch master
 kcoreaddons - Branch master
 kcompletion - Branch master
 kio - Branch master
 ktexteditor - 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
-- 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
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
CMake Error at CMakeLists.txt:37 (find_package):
  Could not find a configuration file for package "KF5Plasma" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/plasma-framework/inst/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake,
 version: 5.0.0



-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project krunner.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit tes

Build failed in Jenkins: kio_master_qt5 #311

2014-08-02 Thread KDE CI System 
See 

Changes:

[scripty] Upgrade ECM and KF5 version requirements for 5.1.0 release.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[kio_master_qt5] $ /bin/sh -xe /tmp/hudson8692799190370058783.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

>From git://anongit.kde.org/kio
   8162893..72d2bc7  master -> origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 8162893 Drop unnecessary isEmpty() check.
Removing build/
Removing dotdata/
Removing local-inst/
Success build forhudson.tasks.Shell@de160b
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/kio
Fetching upstream changes from git://anongit.kde.org/kio
 > git --version
 > git fetch --tags --progress git://anongit.kde.org/kio 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/refs/heads/jenkins^{commit}
 > git rev-parse refs/heads/jenkins^{commit}
Checking out Revision 72d2bc7b5115c5ac2f413408c8284c6165e86c84 
(refs/heads/jenkins)
 > git config core.sparsecheckout
 > git checkout -f 72d2bc7b5115c5ac2f413408c8284c6165e86c84
 > git rev-list 59e3686b0475126bfb9988bf90d410b4964297a7
 > git tag -a -f -m Jenkins Build #311 jenkins-kio_master_qt5-311
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kio_master_qt5] $ /bin/sh -xe /tmp/hudson8263927436335688973.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kio - Branch master
== Build Dependencies:
 kjobwidgets - Branch master
 kdbusaddons - Branch master
 sonnet - Branch master
 kauth - Branch master
 polkit-qt-1 - Branch master
 kwidgetsaddons - Branch master
 kcrash - Branch master
 kcodecs - Branch master
 kitemviews - Branch master
 cmake - Branch master
 kiconthemes - Branch master
 kservice - Branch master
 knotifications - Branch master
 kconfigwidgets - Branch master
 ki18n - Branch master
 dogtail - Branch master
 solid - Branch master
 kguiaddons - Branch master
 qt5 - Branch stable
 ktextwidgets - Branch master
 kconfig - Branch master
 kxmlgui - Branch master
 kcompletion - Branch master
 kwallet - Branch master
 kbookmarks - Branch master
 kwindowsystem - Branch master
 kcoreaddons - Branch master
 kglobalaccel - Branch master
 attica - Branch master
 kdoctools - Branch master
 phonon - Branch master
 karchive - Branch master
 extra-cmake-modules - 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
-- 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
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
CMake Error at CMakeLists.txt:37 (find_package):
  Could not find a configuration file for package "KF5DBusAddons" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdbusaddons/inst/lib64/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake,
 version: 5.0.0

/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdbusaddons/inst/lib64/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake,
 version: 5.0.0



-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kio.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-dev

Build failed in Jenkins: kded_master_qt5 #72

2014-08-02 Thread KDE CI System 
See 

Changes:

[scripty] Upgrade ECM and KF5 version requirements for 5.1.0 release.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace 

Running Prebuild steps
[kded_master_qt5] $ /bin/sh -xe /tmp/hudson6709134226463637570.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

Cloning into '.'...
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 82d29c5 Upgrade ECM and KF5 version requirements for 5.1.0 
release.
Success build forhudson.tasks.Shell@42d685ed
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git://anongit.kde.org/kded
Fetching upstream changes from git://anongit.kde.org/kded
 > git --version
 > git fetch --tags --progress git://anongit.kde.org/kded 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/refs/heads/jenkins^{commit}
 > git rev-parse refs/heads/jenkins^{commit}
Checking out Revision 82d29c52dbf72cc8725b6f28322d2e5f185a6b99 
(refs/heads/jenkins)
 > git config core.sparsecheckout
 > git checkout -f 82d29c52dbf72cc8725b6f28322d2e5f185a6b99
 > git rev-list 6f7a73098be7364cc2e7c50db3a658a745ee7002
 > git tag -a -f -m Jenkins Build #72 jenkins-kded_master_qt5-72
Run condition [File exists] enabling prebuild for step [Publish JUnit test 
result report]
Run condition [File exists] enabling prebuild for step [Publish Cppcheck 
results]
[kded_master_qt5] $ /bin/sh -xe /tmp/hudson786703117340004434.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: kded - Branch master
== Build Dependencies:
 kjobwidgets - Branch master
 kdbusaddons - Branch master
 sonnet - Branch master
 kauth - Branch master
 cmake - Branch master
 kwidgetsaddons - Branch master
 kcrash - Branch master
 phonon - Branch master
 kitemviews - Branch master
 dogtail - Branch master
 kservice - Branch master
 ki18n - Branch master
 kconfigwidgets - Branch master
 knotifications - Branch master
 kconfig - Branch master
 kguiaddons - Branch master
 qt5 - Branch stable
 ktextwidgets - Branch master
 solid - Branch master
 kxmlgui - Branch master
 karchive - Branch master
 kwallet - Branch master
 kcodecs - Branch master
 polkit-qt-1 - Branch master
 kbookmarks - Branch master
 kwindowsystem - Branch master
 kcoreaddons - Branch master
 kiconthemes - Branch master
 kio - Branch master
 kglobalaccel - Branch master
 attica - Branch master
 kdoctools - Branch master
 kcompletion - Branch master
 kinit - Branch master
 extra-cmake-modules - 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
-- 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
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
CMake Error at CMakeLists.txt:20 (find_package):
  Could not find a configuration file for package "KF5DBusAddons" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdbusaddons/inst/lib64/cmake/KF5DBusAddons/KF5DBusAddonsConfig.cmake,
 version: 5.0.0



-- Configuring incomplete, errors occurred!
See also 
"
Configure step exited with non-zero code, assuming failure to configure for 
project kded.
Build step 'Execute shell' marked build as failure
[File exists] check if file exists [build/JUnitTestResults.xml]
Run condition [File exists] preventing perform for step [Publish JUnit test 
result report]
[File exists] check if file exists [build/cppcheck.xml]
Run condition [File exists] preventing perform for step [Publish Cppcheck 
results]
[WARNINGS] Skipping publisher since build result is FAILURE
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel