frameworkintegration QFileDialog bug

[Jeremy Whiting]

Hey all,

We have a strange bug in frameworkintegration
https://bugs.kde.org/show_bug.cgi?id=334963 which really ought to get a
solution sooner than later. People using the latest and greatest packages
are hitting the issue https://bugs.kde.org/show_bug.cgi?id=344586 and more
will if it doesn't get fixed. I've done a bit of testing and it boils down
to this.

In KDEFileDialogHelper show we need to call m_dialog->show() whether the
dialog is modal or not. Currently we are only calling it if the dialog is
not modal.
Doing the above makes QDialog static methods somehow not interactive, I'm
still not sure why. https://paste.kde.org/pdv7wlxpd <-- here's a backtrace
of running the Qt 5 standarddialogs test and clicking on one of the file
dialog tests. Interestingly, a backtrace of standarddialogs working with
frameworkintegration as it is in git currently is exactly the same, and is
interactive. Somehow moving the m_dialog->show() out of the if makes the
exec() call not interactive anymore.

Anyone have any idea what's going on here?

thanks,
Jeremy

Re: Gitorious going offline

[Ben Cooksley]

On Tue, Mar 17, 2015 at 9:51 AM, Ivan Čukić  wrote:
>> And thanks for being on-top of this :).
>
> No problem. :)
>
> kdesrc-build/kf5-kdepim-build-include updated and pushed.

Our CI system has now been adjusted accordingly.

>
> --
> Cheerio,
> Ivan

Cheers,
Ben

Re: Review Request 122652: Use correct default value when UDS_ACCESS/UDS_FILE_TYPE is not set

[Luigi Toscano]

> On Feb. 25, 2015, 6:57 p.m., Mark Gaiser wrote:
> > I "think" this is OK, but just don't know.
> > 
> > Anyway, your diff is for kdelibs (KDE SC 4.xx). I don't know if that gets 
> > another release. Either way, KIO frameworks [1] is where this should be 
> > applied to when you get a ship it.
> > [1] http://quickgit.kde.org/?p=kio.git
> 
> Luigi Toscano wrote:
> kdelibs 4.14 still receives fixes and it's released with KDE Applications 
> (at least as long as we have kdelibs4-based applications). So, if it fixes a 
> bug, it can go in.
> Of course it should be forward-ported to KIO Framework if it is still 
> relevant there.
> 
> Stefan Brüns wrote:
> So shall I commit this (and https://git.reviewboard.kde.org/r/122653/ as 
> well)?
> 
> AFAIK next Applications release is due in short time.
> 
> Will of course forward port to KF5
> 
> Stefan Brüns wrote:
> I am still waiting for a ship it. Patch applies cleanly to KF5 kio ...

Sorry, but I'm not the one who can give a "Ship it" on this. As this is also a 
bug fix for the kio framework, I would add the kdeframeworks group and the kio 
maintainer (dfaure) to the review.


- Luigi


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


On Feb. 20, 2015, 10:28 p.m., Stefan Brüns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122652/
> ---
> 
> (Updated Feb. 20, 2015, 10:28 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 339193
> http://bugs.kde.org/show_bug.cgi?id=339193
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The default value for UDSEntry::numberValue(...) is 0, whereas KFileItem
> uses the special value KFileItem::Unknown == (mode_t) -1.
> 
> CCBUG: 339193
> 
> 
> Diffs
> -
> 
>   kio/kio/kfileitem.cpp f431d3608cfe646fb882365921e694af8ff8838f 
> 
> Diff: https://git.reviewboard.kde.org/r/122652/diff/
> 
> 
> Testing
> ---
> 
> dolphin remote:
> -> no lock icon on smb:, mtp:, ... links
> 
> 
> Thanks,
> 
> Stefan Brüns
> 
>

Re: Review Request 122652: Use correct default value when UDS_ACCESS/UDS_FILE_TYPE is not set

[Stefan Brüns]

> On Feb. 25, 2015, 5:57 p.m., Mark Gaiser wrote:
> > I "think" this is OK, but just don't know.
> > 
> > Anyway, your diff is for kdelibs (KDE SC 4.xx). I don't know if that gets 
> > another release. Either way, KIO frameworks [1] is where this should be 
> > applied to when you get a ship it.
> > [1] http://quickgit.kde.org/?p=kio.git
> 
> Luigi Toscano wrote:
> kdelibs 4.14 still receives fixes and it's released with KDE Applications 
> (at least as long as we have kdelibs4-based applications). So, if it fixes a 
> bug, it can go in.
> Of course it should be forward-ported to KIO Framework if it is still 
> relevant there.
> 
> Stefan Brüns wrote:
> So shall I commit this (and https://git.reviewboard.kde.org/r/122653/ as 
> well)?
> 
> AFAIK next Applications release is due in short time.
> 
> Will of course forward port to KF5

I am still waiting for a ship it. Patch applies cleanly to KF5 kio ...


- Stefan


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


On Feb. 20, 2015, 9:28 p.m., Stefan Brüns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122652/
> ---
> 
> (Updated Feb. 20, 2015, 9:28 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 339193
> http://bugs.kde.org/show_bug.cgi?id=339193
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> The default value for UDSEntry::numberValue(...) is 0, whereas KFileItem
> uses the special value KFileItem::Unknown == (mode_t) -1.
> 
> CCBUG: 339193
> 
> 
> Diffs
> -
> 
>   kio/kio/kfileitem.cpp f431d3608cfe646fb882365921e694af8ff8838f 
> 
> Diff: https://git.reviewboard.kde.org/r/122652/diff/
> 
> 
> Testing
> ---
> 
> dolphin remote:
> -> no lock icon on smb:, mtp:, ... links
> 
> 
> Thanks,
> 
> Stefan Brüns
> 
>

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Gregor Mi]

> On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
> > processui/keyboardshortcututil.cpp, line 46
> > 
> >
> > This looks to complicated. It should be much easier to do with the 
> > KGlobalAccel API:
> > * create a KActionCollection for component "kwin"
> > * add a QAction with the shortcut name you want
> > * ask KGlobalAccel to load the shortcut for it.
> 
> Gregor Mi wrote:
> Thanks for the hint but I am not sure of how to use the API in such a 
> way. I tried two things:
> 
> 1)
> org::kde::KGlobalAccel kglobalaccel("org.kde.kglobalaccel", 
> "/kglobalaccel", bus);
> 
> auto kwinActions = 
> kglobalaccel.allActionsForComponent(QStringList("kwin"));
> Q_FOREACH(auto aaa, kwinActions.value()) {
> //qDebug() << aaa; // ("kwin", "Kill Window", "KWin", "Kill 
> Window")
> }
> Then I wonder how to feed the QStringList to a KActionCollection.
> 
> 2)
> KActionCollection ac(nullptr, QString());
> ac.setComponentName("kwin");
> // ac.importGlobalShortcuts();
> Q_FOREACH(auto bbb, ac.actions()) {
> if (bbb->text() == "Kill Window") {
> qDebug() << bbb;
> }
> }
> But the ac.actions() list is empty.
> 
> Which of the two ways should be used?
> 
> Thomas Lübking wrote:
> tried this?
> ---
> KActionCollection ac(this, "kwin");
> ac.setConfigGlobal(true);
> QAction *act  = ac.action("Kill Window");
> 
> Gregor Mi wrote:
> I have no QObject* as parent. Can this be the cause?
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.action("Kill Window");
> qDebug() << ac.actions().count();
> qDebug() << killWindowAction;
> /*
> RESULT:
> 0
> QObject(0x0)
> */
> 
> Thomas Lübking wrote:
> You'd have "qApp", but I don't actually think so.
> 
> Martin Gräßlin wrote:
> try: ac.addAction instead of ac.action
> 
> For reference code look at e.g. 
> kwin/effects/desktopgrid/desktopgrid_config.cpp
> 
> Gregor Mi wrote:
> I tried this:
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGroup("default"); // needed?
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.addAction("Kill Window");
> killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << ac.actions().count();
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count();
> /*
> CONSOLE OUTPUT:
> 1
> 0
> */
> 
> Martin Gräßlin wrote:
> I think you need to register killWindowAction with KGlobalAccel in some 
> way so that it loads the configured shortcut.
> 
> Gregor Mi wrote:
> I found out how to prepare the QAction without KActionCollection.
> 
> auto killWindowAction  = new QAction(nullptr);
> killWindowAction->setProperty("componentName", "kwin"); // see impl of 
> KActionCollection
> killWindowAction->setObjectName("Kill Window"); // see impl of 
> KActionCollection
> // killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << killWindowAction->objectName(); // --> "Kill Window"
> // qDebug() << ac.actions().count(); // --> 1
> qDebug() << KGlobalAccel::self()->isComponentActive("kwin"); // --> true
> qDebug() << KGlobalAccel::self()->allActionsForComponent({ "kwin" 
> }).count(); // (deprecated) --> 152
> qDebug() << KGlobalAccel::self()->hasShortcut(killWindowAction); // --> 
> false
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count(); // 
> --> 0
> qDebug() << 
> KGlobalAccel::self()->defaultShortcut(killWindowAction).count(); // --> 0
> delete killWindowAction;
> 
> Open issues:
> 1. Is it necessary to specify the shortcut context ("default") somewhere?
> 2. How to tell KGlobalAccel to load the shortcuts for the given action.
> 
> Gregor Mi wrote:
> Issue 1.: *not* necessary, see 
> kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
> 
> Martin Gräßlin wrote:
> concerning 2: see 
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
> 
> shortcut context is (I think) not needed.
> 
> Gregor Mi wrote:
> I read the API documentation about setShortcut and frankly I do not fully 
> understand it. It seems counter-intuitive to me to call that method in order 
> to *load* the shortcut.
> 
> Martin Gräßlin wrote:
> yes the API is weird. But it's really like it: if one doesn't pass 
> NoAutloading the shortcut gets loaded.
> 
> Gregor Mi wrote:
> yes, you are right, it is really working like this:
> 
> KActionCollection ac(nullptr, "kwin");
> auto killWindowAction  = ac.addAction("Kill Window");
> //kil

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Thomas Lübking]

> On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
> > processui/keyboardshortcututil.cpp, line 46
> > 
> >
> > This looks to complicated. It should be much easier to do with the 
> > KGlobalAccel API:
> > * create a KActionCollection for component "kwin"
> > * add a QAction with the shortcut name you want
> > * ask KGlobalAccel to load the shortcut for it.
> 
> Gregor Mi wrote:
> Thanks for the hint but I am not sure of how to use the API in such a 
> way. I tried two things:
> 
> 1)
> org::kde::KGlobalAccel kglobalaccel("org.kde.kglobalaccel", 
> "/kglobalaccel", bus);
> 
> auto kwinActions = 
> kglobalaccel.allActionsForComponent(QStringList("kwin"));
> Q_FOREACH(auto aaa, kwinActions.value()) {
> //qDebug() << aaa; // ("kwin", "Kill Window", "KWin", "Kill 
> Window")
> }
> Then I wonder how to feed the QStringList to a KActionCollection.
> 
> 2)
> KActionCollection ac(nullptr, QString());
> ac.setComponentName("kwin");
> // ac.importGlobalShortcuts();
> Q_FOREACH(auto bbb, ac.actions()) {
> if (bbb->text() == "Kill Window") {
> qDebug() << bbb;
> }
> }
> But the ac.actions() list is empty.
> 
> Which of the two ways should be used?
> 
> Thomas Lübking wrote:
> tried this?
> ---
> KActionCollection ac(this, "kwin");
> ac.setConfigGlobal(true);
> QAction *act  = ac.action("Kill Window");
> 
> Gregor Mi wrote:
> I have no QObject* as parent. Can this be the cause?
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.action("Kill Window");
> qDebug() << ac.actions().count();
> qDebug() << killWindowAction;
> /*
> RESULT:
> 0
> QObject(0x0)
> */
> 
> Thomas Lübking wrote:
> You'd have "qApp", but I don't actually think so.
> 
> Martin Gräßlin wrote:
> try: ac.addAction instead of ac.action
> 
> For reference code look at e.g. 
> kwin/effects/desktopgrid/desktopgrid_config.cpp
> 
> Gregor Mi wrote:
> I tried this:
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGroup("default"); // needed?
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.addAction("Kill Window");
> killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << ac.actions().count();
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count();
> /*
> CONSOLE OUTPUT:
> 1
> 0
> */
> 
> Martin Gräßlin wrote:
> I think you need to register killWindowAction with KGlobalAccel in some 
> way so that it loads the configured shortcut.
> 
> Gregor Mi wrote:
> I found out how to prepare the QAction without KActionCollection.
> 
> auto killWindowAction  = new QAction(nullptr);
> killWindowAction->setProperty("componentName", "kwin"); // see impl of 
> KActionCollection
> killWindowAction->setObjectName("Kill Window"); // see impl of 
> KActionCollection
> // killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << killWindowAction->objectName(); // --> "Kill Window"
> // qDebug() << ac.actions().count(); // --> 1
> qDebug() << KGlobalAccel::self()->isComponentActive("kwin"); // --> true
> qDebug() << KGlobalAccel::self()->allActionsForComponent({ "kwin" 
> }).count(); // (deprecated) --> 152
> qDebug() << KGlobalAccel::self()->hasShortcut(killWindowAction); // --> 
> false
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count(); // 
> --> 0
> qDebug() << 
> KGlobalAccel::self()->defaultShortcut(killWindowAction).count(); // --> 0
> delete killWindowAction;
> 
> Open issues:
> 1. Is it necessary to specify the shortcut context ("default") somewhere?
> 2. How to tell KGlobalAccel to load the shortcuts for the given action.
> 
> Gregor Mi wrote:
> Issue 1.: *not* necessary, see 
> kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
> 
> Martin Gräßlin wrote:
> concerning 2: see 
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
> 
> shortcut context is (I think) not needed.
> 
> Gregor Mi wrote:
> I read the API documentation about setShortcut and frankly I do not fully 
> understand it. It seems counter-intuitive to me to call that method in order 
> to *load* the shortcut.
> 
> Martin Gräßlin wrote:
> yes the API is weird. But it's really like it: if one doesn't pass 
> NoAutloading the shortcut gets loaded.
> 
> Gregor Mi wrote:
> yes, you are right, it is really working like this:
> 
> KActionCollection ac(nullptr, "kwin");
> auto killWindowAction  = ac.addAction("Kill Window");
> //kil

Re: Gitorious going offline

[Ivan Čukić]

> And thanks for being on-top of this :).

No problem. :)

kdesrc-build/kf5-kdepim-build-include updated and pushed.

-- 
Cheerio,
Ivan

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Gregor Mi]

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



processui/keyboardshortcututil.cpp


requires https://git.reviewboard.kde.org/r/122981/ to be submitted


- Gregor Mi


On March 13, 2015, 10:08 p.m., Gregor Mi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122249/
> ---
> 
> (Updated March 13, 2015, 10:08 p.m.)
> 
> 
> Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> Current situation:
> The "End Process..." button has a tooltip which says "To target a specific 
> window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is 
> hardcoded.
> 
> New:
> Replace the "End Process..." button with a drop-down button and a action 
> named "Kill a specific window..."
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 5352e70f6f37daae76c1b3e2c1c9f149d235e3cd 
>   processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 
>   processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
>   processui/keyboardshortcututil.h PRE-CREATION 
>   processui/keyboardshortcututil.cpp PRE-CREATION 
>   processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c 
>   tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 
>   tests/keyboardshortcututiltest.h PRE-CREATION 
>   tests/keyboardshortcututiltest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/122249/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> New End Process button with drop down arrow
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png
> Drop down shows Kill Window
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Gregor Mi]

> On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
> > processui/keyboardshortcututil.cpp, line 46
> > 
> >
> > This looks to complicated. It should be much easier to do with the 
> > KGlobalAccel API:
> > * create a KActionCollection for component "kwin"
> > * add a QAction with the shortcut name you want
> > * ask KGlobalAccel to load the shortcut for it.
> 
> Gregor Mi wrote:
> Thanks for the hint but I am not sure of how to use the API in such a 
> way. I tried two things:
> 
> 1)
> org::kde::KGlobalAccel kglobalaccel("org.kde.kglobalaccel", 
> "/kglobalaccel", bus);
> 
> auto kwinActions = 
> kglobalaccel.allActionsForComponent(QStringList("kwin"));
> Q_FOREACH(auto aaa, kwinActions.value()) {
> //qDebug() << aaa; // ("kwin", "Kill Window", "KWin", "Kill 
> Window")
> }
> Then I wonder how to feed the QStringList to a KActionCollection.
> 
> 2)
> KActionCollection ac(nullptr, QString());
> ac.setComponentName("kwin");
> // ac.importGlobalShortcuts();
> Q_FOREACH(auto bbb, ac.actions()) {
> if (bbb->text() == "Kill Window") {
> qDebug() << bbb;
> }
> }
> But the ac.actions() list is empty.
> 
> Which of the two ways should be used?
> 
> Thomas Lübking wrote:
> tried this?
> ---
> KActionCollection ac(this, "kwin");
> ac.setConfigGlobal(true);
> QAction *act  = ac.action("Kill Window");
> 
> Gregor Mi wrote:
> I have no QObject* as parent. Can this be the cause?
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.action("Kill Window");
> qDebug() << ac.actions().count();
> qDebug() << killWindowAction;
> /*
> RESULT:
> 0
> QObject(0x0)
> */
> 
> Thomas Lübking wrote:
> You'd have "qApp", but I don't actually think so.
> 
> Martin Gräßlin wrote:
> try: ac.addAction instead of ac.action
> 
> For reference code look at e.g. 
> kwin/effects/desktopgrid/desktopgrid_config.cpp
> 
> Gregor Mi wrote:
> I tried this:
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGroup("default"); // needed?
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.addAction("Kill Window");
> killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << ac.actions().count();
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count();
> /*
> CONSOLE OUTPUT:
> 1
> 0
> */
> 
> Martin Gräßlin wrote:
> I think you need to register killWindowAction with KGlobalAccel in some 
> way so that it loads the configured shortcut.
> 
> Gregor Mi wrote:
> I found out how to prepare the QAction without KActionCollection.
> 
> auto killWindowAction  = new QAction(nullptr);
> killWindowAction->setProperty("componentName", "kwin"); // see impl of 
> KActionCollection
> killWindowAction->setObjectName("Kill Window"); // see impl of 
> KActionCollection
> // killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << killWindowAction->objectName(); // --> "Kill Window"
> // qDebug() << ac.actions().count(); // --> 1
> qDebug() << KGlobalAccel::self()->isComponentActive("kwin"); // --> true
> qDebug() << KGlobalAccel::self()->allActionsForComponent({ "kwin" 
> }).count(); // (deprecated) --> 152
> qDebug() << KGlobalAccel::self()->hasShortcut(killWindowAction); // --> 
> false
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count(); // 
> --> 0
> qDebug() << 
> KGlobalAccel::self()->defaultShortcut(killWindowAction).count(); // --> 0
> delete killWindowAction;
> 
> Open issues:
> 1. Is it necessary to specify the shortcut context ("default") somewhere?
> 2. How to tell KGlobalAccel to load the shortcuts for the given action.
> 
> Gregor Mi wrote:
> Issue 1.: *not* necessary, see 
> kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
> 
> Martin Gräßlin wrote:
> concerning 2: see 
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
> 
> shortcut context is (I think) not needed.
> 
> Gregor Mi wrote:
> I read the API documentation about setShortcut and frankly I do not fully 
> understand it. It seems counter-intuitive to me to call that method in order 
> to *load* the shortcut.
> 
> Martin Gräßlin wrote:
> yes the API is weird. But it's really like it: if one doesn't pass 
> NoAutloading the shortcut gets loaded.
> 
> Gregor Mi wrote:
> yes, you are right, it is really working like this:
> 
> KActionCollection ac(nullptr, "kwin");
> auto killWindowAction  = ac.addAction("Kill Window");
> //kil

Re: Gitorious going offline

[Stephen Kelly]

On 03/16/2015 05:28 PM, Ivan Čukić wrote:
> From www.gitorious.org
>> System notice: Gitorious is being acquired by GitLab and
>> gitorious.org will shut down end of May. Please import your
>> repositories to
> We still have a few projects on there. One notable being Grantlee (at
> least, my kdesrc-build looks for it over there).
>
> I guess this should be dealt with sooner than later. :)
>

And thanks for being on-top of this :).

Re: Gitorious going offline

[Stephen Kelly]

On 03/16/2015 05:28 PM, Ivan Čukić wrote:
> From www.gitorious.org
>> System notice: Gitorious is being acquired by GitLab and
>> gitorious.org will shut down end of May. Please import your
>> repositories to
> We still have a few projects on there. One notable being Grantlee (at
> least, my kdesrc-build looks for it over there).
>
> I guess this should be dealt with sooner than later. :)
>

I've pushed Grantlee to github:

 https://github.com/steveire/grantlee

Please update your scripts.

Thanks,

Steve.

Re: Gitorious going offline

[Ivan Čukić]

> If by *we* you mean KDE, no we don't have anything there

Not meant to be a yet-another-what-is-a-kde-project type of thread.

Just a heads-up of what is happening with the host that more than a
few people from KDE are using for KDE-related things.

Heads-up mail on KCD because I have *not* received an e-mail from
gitorious about this, so others might not be aware of the changes.

Cheerio,
Ivan

-- 
KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76

Re: Gitorious going offline

[Albert Astals Cid]

El Dilluns, 16 de març de 2015, a les 17:28:43, Ivan Čukić va escriure:
> From www.gitorious.org
> 
> > System notice: Gitorious is being acquired by GitLab and
> > gitorious.org will shut down end of May. Please import your
> > repositories to
> 
> We still have a few projects on there. One notable being Grantlee (at
> least, my kdesrc-build looks for it over there).
> 
> I guess this should be dealt with sooner than later. :)

If by *we* you mean KDE, no we don't have anything there, the manifesto is 
quite clear that to be a KDE project you have to be in KDE infrastructure, 
which gitorious is not.

But yes, there's a few things that would be nice saving like grantlee or 
krazy, but it's up to those projects to decide if they want to be hosted in 
KDE repos or in github or where.

Cheers,
  Albert

Re: GCompris in kdereview

[Bruno Coudoin]

Le 14/03/2015 16:08, Albert Astals Cid a écrit :
> El Dissabte, 14 de març de 2015, a les 15:32:55, Bruno Coudoin va escriure:
>> Le 17/01/2015 00:00, Albert Astals Cid a écrit :
>>> El Dilluns, 12 de gener de 2015, a les 23:58:26, Bruno Coudoin va 
> escriure:
 Hi,

 We just made our first official release of GCompris. We now have the
 need to maintain a stable and a master version. This is not possible to
 do so in playground so it is time for us to go forward and move to
 extragear. To this end, we have just moved to kdereview.

 I have no idea what the review is looking at so I prepared nothing. If
 there something I can do let me know.
>>> Several people pointed you at
>>> https://techbase.kde.org/Policies/Application_Lifecycle which contains a
>>> paragraph tha says "there are some rules to follow before you are allowed
>>> to move to either location:"
>>>
>>> We can be lax about some of them, but you should explain why you don't
>>> want to follow them.
>> Hi,
>>
>> I am sorry for my late answer, I completely forgot about it.
>>
>> I copy here the KDE requirements with the answer:
>>
>> - There should be user documentation in docbook format. If you need
>> help, you can ask for help to the KDE Documentation team:
>> kde-doc-engl...@kde.org.
>>
>> We have 2 types of user documentation:
>>
>> * inline, each activity has its own documentation easily accessible from
>> the help menu in GCompris. This is used by children and teacher or
>> parent to discover what to do in this activity. It is translated through
>> po files. This proved to be adapted to GCompris use case and I believe
>> we should keep it this way.
>>
>> * online manual (http://gcompris.net/wiki/Manual) which is orientated
>> towards sys admins and advanced school usage (creating profiles,
>> accessing children logs, ...). This should be moved to docbook. I added
>> a task in our tracker for that:
>> http://gcompris.net/wiki/Qt_Quick_Migration_status#Core
>>
>>
>> - There should be developers documentation in the form of apidox for
>> libraries you can check this at ebn
>>
>> This is something we have not yet investigated but as GCompris matures
>> it will be more and more needed. The target here is to help activities
>> developers. I added this need in our task tracker
>> http://gcompris.net/wiki/Qt_Quick_Migration_status#Core
>>
>>
>> - There should be no krazy code checker issues reported. Again, you
>> can check that at ebn. There is also a tutorial on using Krazy available
>> here on TechBase.
>>
>> We did work on that and fixed all the issues on the devel branch. By the
>> way, EBN must be changed to run krazy with '--check-set qt5' and not
>> kde4 as it is today.
>>
>>
>> - If possible, there should have been a basic usability review of your
>> application. Usability people are hard to get, so this is not crucial.
>>
>> We would be pleased to get help on that. This is a very important point
>> for us that we take seriously. So far, as the application has been
>> released on Android we had the chance to get some user feedback that we
>> took in account.
>>
>>
>> - You should have checked for basic problems with a profiler. I hope
>> we will get a tutorial on how to do this soon
>>
>> I have already used valgrind on C++ projects but not tested what it
>> brings to a QML project. We take performance seriously to avoid
>> excluding schools with limited hardware to run GCompris.
>>
>> - Your application should be completely translatable.
>>
>> The translation process is in place and works as expected. We still have
>> datasets for some activities that should be moved to the po system.
>>
>>> As a side note, you don't ship a .desktop file, which basically makes your
>>> app invisible to desktop menus/launchers.
>> True, it would be easy to pick the Gtk+ ones but I am not sure how to
>> make them translatable.
> So you can go to google, ask him "kde translate desktop files" that will 
> point 
> you to 
> https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems
> and specially
> https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Translating_.desktop_Files
Hi,

Thanks for your pointers. I pushed a desktop and an appdata file on the
devel branch.

Bruno.

Gitorious going offline

[Ivan Čukić]

>From www.gitorious.org
> System notice: Gitorious is being acquired by GitLab and
> gitorious.org will shut down end of May. Please import your
> repositories to

We still have a few projects on there. One notable being Grantlee (at
least, my kdesrc-build looks for it over there).

I guess this should be dealt with sooner than later. :)

-- 
Cheerio,
Ivan

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Thomas Lübking]

> On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
> > processui/keyboardshortcututil.cpp, line 46
> > 
> >
> > This looks to complicated. It should be much easier to do with the 
> > KGlobalAccel API:
> > * create a KActionCollection for component "kwin"
> > * add a QAction with the shortcut name you want
> > * ask KGlobalAccel to load the shortcut for it.
> 
> Gregor Mi wrote:
> Thanks for the hint but I am not sure of how to use the API in such a 
> way. I tried two things:
> 
> 1)
> org::kde::KGlobalAccel kglobalaccel("org.kde.kglobalaccel", 
> "/kglobalaccel", bus);
> 
> auto kwinActions = 
> kglobalaccel.allActionsForComponent(QStringList("kwin"));
> Q_FOREACH(auto aaa, kwinActions.value()) {
> //qDebug() << aaa; // ("kwin", "Kill Window", "KWin", "Kill 
> Window")
> }
> Then I wonder how to feed the QStringList to a KActionCollection.
> 
> 2)
> KActionCollection ac(nullptr, QString());
> ac.setComponentName("kwin");
> // ac.importGlobalShortcuts();
> Q_FOREACH(auto bbb, ac.actions()) {
> if (bbb->text() == "Kill Window") {
> qDebug() << bbb;
> }
> }
> But the ac.actions() list is empty.
> 
> Which of the two ways should be used?
> 
> Thomas Lübking wrote:
> tried this?
> ---
> KActionCollection ac(this, "kwin");
> ac.setConfigGlobal(true);
> QAction *act  = ac.action("Kill Window");
> 
> Gregor Mi wrote:
> I have no QObject* as parent. Can this be the cause?
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.action("Kill Window");
> qDebug() << ac.actions().count();
> qDebug() << killWindowAction;
> /*
> RESULT:
> 0
> QObject(0x0)
> */
> 
> Thomas Lübking wrote:
> You'd have "qApp", but I don't actually think so.
> 
> Martin Gräßlin wrote:
> try: ac.addAction instead of ac.action
> 
> For reference code look at e.g. 
> kwin/effects/desktopgrid/desktopgrid_config.cpp
> 
> Gregor Mi wrote:
> I tried this:
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGroup("default"); // needed?
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.addAction("Kill Window");
> killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << ac.actions().count();
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count();
> /*
> CONSOLE OUTPUT:
> 1
> 0
> */
> 
> Martin Gräßlin wrote:
> I think you need to register killWindowAction with KGlobalAccel in some 
> way so that it loads the configured shortcut.
> 
> Gregor Mi wrote:
> I found out how to prepare the QAction without KActionCollection.
> 
> auto killWindowAction  = new QAction(nullptr);
> killWindowAction->setProperty("componentName", "kwin"); // see impl of 
> KActionCollection
> killWindowAction->setObjectName("Kill Window"); // see impl of 
> KActionCollection
> // killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << killWindowAction->objectName(); // --> "Kill Window"
> // qDebug() << ac.actions().count(); // --> 1
> qDebug() << KGlobalAccel::self()->isComponentActive("kwin"); // --> true
> qDebug() << KGlobalAccel::self()->allActionsForComponent({ "kwin" 
> }).count(); // (deprecated) --> 152
> qDebug() << KGlobalAccel::self()->hasShortcut(killWindowAction); // --> 
> false
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count(); // 
> --> 0
> qDebug() << 
> KGlobalAccel::self()->defaultShortcut(killWindowAction).count(); // --> 0
> delete killWindowAction;
> 
> Open issues:
> 1. Is it necessary to specify the shortcut context ("default") somewhere?
> 2. How to tell KGlobalAccel to load the shortcuts for the given action.
> 
> Gregor Mi wrote:
> Issue 1.: *not* necessary, see 
> kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
> 
> Martin Gräßlin wrote:
> concerning 2: see 
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
> 
> shortcut context is (I think) not needed.
> 
> Gregor Mi wrote:
> I read the API documentation about setShortcut and frankly I do not fully 
> understand it. It seems counter-intuitive to me to call that method in order 
> to *load* the shortcut.
> 
> Martin Gräßlin wrote:
> yes the API is weird. But it's really like it: if one doesn't pass 
> NoAutloading the shortcut gets loaded.
> 
> Gregor Mi wrote:
> yes, you are right, it is really working like this:
> 
> KActionCollection ac(nullptr, "kwin");
> auto killWindowAction  = ac.addAction("Kill Window");
> //kil

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

[Martin Gräßlin]

> On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
> > processui/keyboardshortcututil.cpp, line 46
> > 
> >
> > This looks to complicated. It should be much easier to do with the 
> > KGlobalAccel API:
> > * create a KActionCollection for component "kwin"
> > * add a QAction with the shortcut name you want
> > * ask KGlobalAccel to load the shortcut for it.
> 
> Gregor Mi wrote:
> Thanks for the hint but I am not sure of how to use the API in such a 
> way. I tried two things:
> 
> 1)
> org::kde::KGlobalAccel kglobalaccel("org.kde.kglobalaccel", 
> "/kglobalaccel", bus);
> 
> auto kwinActions = 
> kglobalaccel.allActionsForComponent(QStringList("kwin"));
> Q_FOREACH(auto aaa, kwinActions.value()) {
> //qDebug() << aaa; // ("kwin", "Kill Window", "KWin", "Kill 
> Window")
> }
> Then I wonder how to feed the QStringList to a KActionCollection.
> 
> 2)
> KActionCollection ac(nullptr, QString());
> ac.setComponentName("kwin");
> // ac.importGlobalShortcuts();
> Q_FOREACH(auto bbb, ac.actions()) {
> if (bbb->text() == "Kill Window") {
> qDebug() << bbb;
> }
> }
> But the ac.actions() list is empty.
> 
> Which of the two ways should be used?
> 
> Thomas Lübking wrote:
> tried this?
> ---
> KActionCollection ac(this, "kwin");
> ac.setConfigGlobal(true);
> QAction *act  = ac.action("Kill Window");
> 
> Gregor Mi wrote:
> I have no QObject* as parent. Can this be the cause?
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.action("Kill Window");
> qDebug() << ac.actions().count();
> qDebug() << killWindowAction;
> /*
> RESULT:
> 0
> QObject(0x0)
> */
> 
> Thomas Lübking wrote:
> You'd have "qApp", but I don't actually think so.
> 
> Martin Gräßlin wrote:
> try: ac.addAction instead of ac.action
> 
> For reference code look at e.g. 
> kwin/effects/desktopgrid/desktopgrid_config.cpp
> 
> Gregor Mi wrote:
> I tried this:
> 
> KActionCollection ac(nullptr, "kwin");
> ac.setConfigGroup("default"); // needed?
> ac.setConfigGlobal(true);
> auto killWindowAction  = ac.addAction("Kill Window");
> killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << ac.actions().count();
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count();
> /*
> CONSOLE OUTPUT:
> 1
> 0
> */
> 
> Martin Gräßlin wrote:
> I think you need to register killWindowAction with KGlobalAccel in some 
> way so that it loads the configured shortcut.
> 
> Gregor Mi wrote:
> I found out how to prepare the QAction without KActionCollection.
> 
> auto killWindowAction  = new QAction(nullptr);
> killWindowAction->setProperty("componentName", "kwin"); // see impl of 
> KActionCollection
> killWindowAction->setObjectName("Kill Window"); // see impl of 
> KActionCollection
> // killWindowAction->setProperty("isConfigurationAction", true); // neded?
> qDebug() << killWindowAction->objectName(); // --> "Kill Window"
> // qDebug() << ac.actions().count(); // --> 1
> qDebug() << KGlobalAccel::self()->isComponentActive("kwin"); // --> true
> qDebug() << KGlobalAccel::self()->allActionsForComponent({ "kwin" 
> }).count(); // (deprecated) --> 152
> qDebug() << KGlobalAccel::self()->hasShortcut(killWindowAction); // --> 
> false
> qDebug() << KGlobalAccel::self()->shortcut(killWindowAction).count(); // 
> --> 0
> qDebug() << 
> KGlobalAccel::self()->defaultShortcut(killWindowAction).count(); // --> 0
> delete killWindowAction;
> 
> Open issues:
> 1. Is it necessary to specify the shortcut context ("default") somewhere?
> 2. How to tell KGlobalAccel to load the shortcuts for the given action.
> 
> Gregor Mi wrote:
> Issue 1.: *not* necessary, see 
> kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
> 
> Martin Gräßlin wrote:
> concerning 2: see 
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
> 
> shortcut context is (I think) not needed.
> 
> Gregor Mi wrote:
> I read the API documentation about setShortcut and frankly I do not fully 
> understand it. It seems counter-intuitive to me to call that method in order 
> to *load* the shortcut.
> 
> Martin Gräßlin wrote:
> yes the API is weird. But it's really like it: if one doesn't pass 
> NoAutloading the shortcut gets loaded.
> 
> Gregor Mi wrote:
> yes, you are right, it is really working like this:
> 
> KActionCollection ac(nullptr, "kwin");
> auto killWindowAction  = ac.addAction("Kill Window");
> //kil