Re: kio man + khelpcenter

[Martin Koller]

On Sonntag, 26. September 2021 21:53:12 CEST you wrote:
> Martin Koller ha scritto:
> > Hi,
> > 
> > a recent update (openSuse TW, kio-extras5 Version: 21.08.1) had the effect 
> > that whenever I want to view a man page
> > via Alt-F2 (Krunner) and e.g. "#ls", now khelpcenter is opened, instead 
> > konqueror, which I had before.
> > What defines which application is started an how can I change this back to 
> > konqueror ?
> > 
> 
> It was discussed in this thread:
> 
> https://mail.kde.org/pipermail/kde-frameworks-devel/2021-September/119021.html

I see that this issue was fixed 8 month ago for konqueror. Great, I can
now again enter "#ls" in konqi and see the man page inside konqueror.

However: using krunner and "#ls" still opens KDE Help Center, instead of
konqueror.

Where can I configure that this opens the man page in konqi, as it was before ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

Re: Aw: Re: kcm_bluetooth changed ?

[Martin Koller]

On Sonntag, 13. Februar 2022 19:27:22 CET alexander.loh...@gmx.de wrote:
> Hello,
>  
> Usually the KCMs are opened by starting kcmshell or systemsettings with the 
> module names as arguments,
> meaning we resolve the location of the KCMs internally and don't require 
> changes for consumers. kcmshell also checks if the plugin id
> would match if the "kcm_" prefix is to the module name prepended, 
> consequently "kcmshell5 bluetooth" works in both Plasma 5.23 and 5.24.
>  
> > If KDE/plamsa is such a moving target where  can not rely on compatibility 
> > even between minor versions, that is really not fun
>  
> Looking at liquidshell, there are multiple  cases where the available KCMs 
> are checked at runtime to be compatible with old Plasma versions. While 
> having to do this is not ideal, it is not anything new.
> Luckily most of the changes to port the KCMs to the new metadata approach 
> have already landed.
> The KWin KCMs remain though, when porting those I will make sure to create a 
> accompanying MR in liquidshell.

thanks!

> PS: You can check if the KPluginMetaData object is valid, instead of checking 
> if the name is not empty :).

ok. I took the code I was told works ...

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

Re: kcm_bluetooth changed ?

[Martin Koller]

On Sonntag, 13. Februar 2022 14:15:09 CET Fusion Future wrote:
> On 2022/2/13 20:20, Martin Koller wrote:
> > I already tried this but it did not solve the issue.
> 
> This code snippet works on my system. Please have a try.
> 
> ```cpp
> dialog = new KCMultiDialog();
> 
> KPluginMetaData 
> module(QPluginLoader("plasma/kcms/systemsettings/kcm_bluetooth"));
> if (!module.name().isEmpty())
>  dialog->addModule(module);
> 
> dialog->show();
> ```

Yes, that works, thanks!

But still I wonder if such a change is something like breaking ABI 
compatibility.
If KDE/plamsa is such a moving target where I can not rely on compatibility even
between minor versions, that is really not fun.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

Re: kcm_bluetooth changed ?

[Martin Koller]

On Sonntag, 13. Februar 2022 04:59:51 CET Fusion Future wrote:
> On 2022/2/13 05:46, Martin Koller wrote:
> > What has changed and how would I now use the new KCM in a KCMultiDialog ?
> 
> It can be changed to "kcm_bluetooth". Please see [1] to see if that helps.
> 
> [1] https://invent.kde.org/plasma/bluedevil/-/merge_requests/49
> 

I already tried this but it did not solve the issue.

I also use kcm_kwin_virtualdesktops this way, and looking at the difference
I see that I have the file
/usr/share/kservices5/kcm_kwin_virtualdesktops.desktop
but I do not have such a desktop file for bluetooth or kcm_bluetooth.
What I do have is a file called
/usr/share/kservices5/plasma-applet-org.kde.plasma.bluetooth.desktop
However this does e.g. not contain a X-KDE-Library entry (which 
kcm_kwin_virtualdesktops has).
And when I change my code to use "plasma-applet-org.kde.plasma.bluetooth" then 
the result is
a page with an error text (see attached).

So I'm not sure what did change between the previous version and the current.
-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

kcm_bluetooth changed ?

[Martin Koller]

Hi,

in liquidshell I start the bluetooth KCM via:
dialog = new KCMultiDialog(this);
KCModuleInfo module("bluetooth");
if ( module.service() )
  dialog->addModule("bluetooth");

this worked until the latest update to 5.24.0
(working means: the KCM content appeared inside the dialog. Now the dialog
is empty and no bluetooth content can be seen)

What has changed and how would I now use the new KCM in a KCMultiDialog ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

kipi-plugins question

[Martin Koller]

Hi,

when using the KIPI mechanism in my application,
I get log messages like:
kipi.library: This should only be invoked if the host application supports 
KIPI::Features ( HostSupportsMetadataProcessing ). If host application do 
support that, then this function should have been overridden in the KIPI host 
interface.

Note that my host application does not support HostSupportsMetadataProcessing.

What I understand is that KIPI::Interface::createMetadataProcessor() should 
only be called by a plugin
if interface->hasFeature(KIPI::HostSupportsMetadataProcessing)

but e.g. in yandexfotki/yfwindow.cpp (and others) there is no call to 
hasFeature()
and the method is just called without the check. (at least it checks if the 
value returned is nullptr,
but in rajce/rajcesession.cpp it is not checked and might actually crash)

I assume this are bugs in the plugins, and the idea of the Interface class was 
to actually
must use a call to hasFeature(), right ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

duplicate notifications ?

[Martin Koller]

Hi,

in liquidshell I'm using a NotificationServer implementation which
listens on new notifications via dbus "org.freedesktop.Notifications".

Some recent KF5 or kmail(?) changes however led now to duplicate notifications.
E.g. In the Notify slot I receive the following notification when I send an 
email:

app "KDE Mail" summary "E-Mail Successfully Sent" body "Your E-Mail has been 
sent successfully." timeout -1 replaceId 0 hints QMap(("desktop-entry", 
QVariant(QString, "org.kde.akonadi_maildispatcher_agent"))("urgency", 
QVariant(int, 0))("x-kde-appname", QVariant(QString, 
"akonadi_maildispatcher_agent"))("x-kde-eventId", QVariant(QString, 
"emailsent"))) actions ()

app "KDE Mail" summary "E-Mail Successfully Sent" body "Your E-Mail has been 
sent successfully." timeout -1 replaceId 1 hints QMap(("desktop-entry", 
QVariant(QString, "org.kde.akonadi_maildispatcher_agent"))("urgency", 
QVariant(int, 0))("x-kde-appname", QVariant(QString, 
"akonadi_maildispatcher_agent"))("x-kde-eventId", QVariant(QString, 
"emailsent"))) actions ()

you can see both are the same with the exception that the second has "replaceId 
1"
telling me to replace the first one I got (the second comes immediately after 
the first).

So the question is: why do I now always get these duplicate notifications ?
This is surely a bug, but where ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

changing icon sizes no longer emits signal

[Martin Koller]

Hi,

in liquidshell I'm using

  connect(KIconLoader::global(), ::iconLoaderSettingsChanged, this, 
::adjustIconSize);

to be informed whenever the icon sizes get changed in systemsettings.
I don't know since when but at least in version

Operating System: openSUSE Tumbleweed 20200419
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.1

I no longer receive this signal.
Does it have to do with the changed UI for changing the icon sizes
or something else ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at

D24672: GIT_SILENT Run uncrustify-kf5 on the whole tree

[Martin Koller]

mkoller requested changes to this revision.
mkoller added a comment.
This revision now requires changes to proceed.


  why ?
  I don't like lots of these changes.

REPOSITORY
  R374 KolourPaint

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

To: ahmadsamir, kde-frameworks-devel, mkoller
Cc: ognarb, kde-frameworks-devel

D7820: man ioslave: spurious numbers included in clang(1) man page

[Martin Koller]

mkoller requested changes to this revision.
mkoller added a comment.
This revision now requires changes to proceed.


  I think this was solved with bugfix to Bug Nr 335169 with commit 
87d8ab4371149c84794f4e93d1f590f7bac5f327 

  
  you should abandon this patch

REPOSITORY
  R320 KIO Extras

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

To: marten, #plasma, kfm-devel, mkoller
Cc: ltoscano, kde-frameworks-devel, plasma-devel, aprcela, fprice, LeGast00n, 
sbergeron, jraleigh, fbampaloukas, alexde, GB_2, feverfew, ragreen, Pitel, 
meven, michaelh, spoorun, navarromorales, ZrenBot, firef, ngraham, andrebarros, 
bruns, himcesjf, emmanuelp, lesliezhai, ali-mohamed, mikesomov, jensreuterberg, 
abetts, sebas, apol, mart

D9033: man ioslave: asserts trying to display pam(8)

[Martin Koller]

mkoller accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R320 KIO Extras

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

To: marten, #plasma, kfm-devel, mkoller
Cc: ltoscano, kde-frameworks-devel, apol, plasma-devel, aprcela, fprice, 
LeGast00n, sbergeron, jraleigh, gennad, fbampaloukas, alexde, GB_2, feverfew, 
ragreen, Pitel, meven, michaelh, spoorun, navarromorales, ZrenBot, firef, 
ngraham, andrebarros, bruns, skadinna, himcesjf, emmanuelp, lesliezhai, 
ali-mohamed, mikesomov, jensreuterberg, abetts, sebas, mart

D17741: avoid blocking kio_http_cache_cleaner and ensure exit with session

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:a3fce6e0b7f2: avoid blocking kio_http_cache_cleaner and 
ensure exit with session (authored by mkoller).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D17741?vs=48084=48924#toc

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17741?vs=48084=48924

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

AFFECTED FILES
  src/ioslaves/http/http_cache_cleaner.cpp

To: mkoller, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17741: avoid blocking kio_http_cache_cleaner and ensure exit with session

[Martin Koller]

mkoller updated this revision to Diff 48084.
mkoller added a comment.


  David is right, processEvents() seems not be needed at all - removed it.
  
  Actually while testing, I found some other bugs - mainly read/write of the 
scoreboard and the info from the slaves
  where one side wrote qint64 but the other interpreted it as a QDateTime or 
the file size was expected to be 64bit in
  one code part, but on another code part it was assumed to be 32bit...

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17741?vs=48025=48084

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

AFFECTED FILES
  http_cache_cleaner.cpp

To: mkoller, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17741: avoid blocking kio_http_cache_cleaner and ensure exit with session

[Martin Koller]

mkoller edited the summary of this revision.

REPOSITORY
  R241 KIO

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

To: mkoller, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17741: avoid blocking kio_http_cache_cleaner and ensure exit with session

[Martin Koller]

mkoller created this revision.
mkoller added a reviewer: dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
mkoller requested review of this revision.

REVISION SUMMARY
  Currently when logging out, kio_http_cache_cleaner stays alive and blocks in 
  QCoreApplication::processEvents(QEventLoop::WaitForMoreEvents);
  forever.
  
  This patch avoids this blocking and ensures that the main loop will exit when 
the session bus is no longer connected.

TEST PLAN
  logging in, check CPU load of kio_http_cache_cleaner, log out, check if 
kio_http_cache_cleaner still runs.

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  http_cache_cleaner.cpp

To: mkoller, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

mkoller added a comment.


  I was talking about the code I changed, which uses QUrl, which can not parse 
the @SSL syntax.
  I tried.

REPOSITORY
  R241 KIO

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

To: mkoller, dfaure, #frameworks
Cc: bruns, ngraham, kde-frameworks-devel, michaelh

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:1c7b47cb677b: allow non-local file:// redirect to a 
Windows WebDav URL (authored by mkoller).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D15859?vs=42626=43070#toc

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D15859?vs=42626=43070

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

AFFECTED FILES
  src/ioslaves/file/file.cpp
  src/ioslaves/file/file.h
  src/ioslaves/file/file_unix.cpp
  src/ioslaves/file/file_win.cpp

To: mkoller, dfaure, #frameworks
Cc: bruns, ngraham, kde-frameworks-devel, michaelh

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

mkoller added a comment.


  file://some.server:80/DavWWWRoot/pwa/some/path/to/a/document clearly works 
since it's standard URL syntax.
  file://some.server@80/DavWWWRoot/pwa/some/path/to/a/document does not, since 
it's not a valid URL syntax.
  
  443 is not enabled, so I can't test it, but given the fact that
  file://some.server@SSL/DavWWWRoot/pwa/some/path/to/a/document
  is also not a valid URL syntax, I know it will not work.
  
  And since https://www.webdavsystem.com/server/access/windows
  only talks about UNC path syntax, I even have no clue if this weird syntax 
will ever end up that way in a file:// URL.
  
  I have no idea how my colleagues did produce the file:// URL - for sure not 
manually.
  I just see that I received mails with a file:// URL, not with a UNC syntax

REPOSITORY
  R241 KIO

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

To: mkoller, dfaure, #frameworks
Cc: bruns, ngraham, kde-frameworks-devel, michaelh

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

mkoller added a comment.


  ping

REPOSITORY
  R241 KIO

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

To: mkoller, dfaure, #frameworks
Cc: bruns, ngraham, kde-frameworks-devel, michaelh

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

mkoller updated this revision to Diff 42626.
mkoller added a comment.


  M$ -> windows
  
  About SSL: I have no idea how an SSL url from a sharepoint server would look 
like, since it seems the setup we use does not use ssl.
  The mentioned webdavsystem.com link just describes how it would look like as 
a win-UNC path, but since I receive urls in mail which are not in the unc 
syntax, I'm not sure if they will contain this @ssl token or not

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D15859?vs=42603=42626

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

AFFECTED FILES
  file.cpp
  file.h
  file_unix.cpp
  file_win.cpp

To: mkoller, dfaure, #frameworks
Cc: bruns, ngraham, kde-frameworks-devel, michaelh

D15859: allow non-local file:// redirect to a M$-WebDav URL

[Martin Koller]

mkoller created this revision.
mkoller added a reviewer: dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
mkoller requested review of this revision.

REVISION SUMMARY
  In our mainly windows company environment, I often receive links in emails 
like this
  file://some.server/DavWWWRoot/pwa/some/path/to/a/document
  
  The files are served by a Sharepoint server, and M$ introduced the special 
"DavWWWRoot" prefix to notify
  then WebDav shall be used.
  
  See https://www.webdavsystem.com/server/access/windows
  
  With this patch I can now nicely click such an URL and get the same as 
colleagues using win get

TEST PLAN
  Using kioclient5 exec URL and clicking such an URL in kmail

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  file.cpp
  file.h
  file_unix.cpp
  file_win.cpp

To: mkoller, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D8519: do not make the context menu a Window

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:f2f65dee2962: do not make the context menu a Window 
(authored by mkoller).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8519?vs=21431=23999

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8519: do not make the context menu a Window

[Martin Koller]

mkoller added a comment.


  Ping!
  Anything wrong with this 2 liner patch ?

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D9249: forward socket error string to KTcpSocket

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:84f290a2659d: forward socket error string to KTcpSocket 
(authored by mkoller).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9249?vs=23638=23648

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

AFFECTED FILES
  src/core/ktcpsocket.cpp

To: mkoller, dfaure
Cc: #frameworks

D8519: do not make the context menu a Window

[Martin Koller]

mkoller retitled this revision from "do not make the context menu a Window; do 
not force raise a window" to "do not make the context menu a Window".
mkoller edited the summary of this revision.

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D9249: forward socket error string to KTcpSocket

[Martin Koller]

mkoller created this revision.
mkoller added a reviewer: dfaure.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  KTcpSocket is a QIODevice, internally using a Qt socket - however it does not 
set the error string of itself when the internal socket signals some error 
condition.
  
  The original problem I had with this was the PIM maildispatcher -  in the 
lack of any error string - just showing an error number when notifying the 
user. But a "Failed to transport message. 3" does not really say much to the 
user.
  
  Now at least I get "Failed to transport message. Host not found"

TEST PLAN
  using maildispatcher sending mail to an unknown host

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/core/ktcpsocket.cpp

To: mkoller, dfaure
Cc: #frameworks

D9182: return nullptr -> return {} for QFlags

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R287:7f2c44add4aa: Use brace-initializer instead of nullptr in 
returning 0-QFlags (authored by mkoller).

REPOSITORY
  R287 KImageFormats

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9182?vs=23458=23528

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

AFFECTED FILES
  src/imageformats/eps.cpp
  src/imageformats/exr.cpp
  src/imageformats/kra.cpp
  src/imageformats/ora.cpp
  src/imageformats/pcx.cpp
  src/imageformats/pic.cpp
  src/imageformats/psd.cpp
  src/imageformats/ras.cpp
  src/imageformats/rgb.cpp
  src/imageformats/tga.cpp
  src/imageformats/xcf.cpp

To: mkoller, kfunk, kossebau
Cc: #frameworks

D9182: return nullptr -> return {} for QFlags

[Martin Koller]

mkoller created this revision.
mkoller added reviewers: kfunk, kossebau.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  Change the irritating nullptr return value to {} for the 
QImageIOPlugin::Capabilities QFlags

REPOSITORY
  R287 KImageFormats

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

AFFECTED FILES
  src/imageformats/eps.cpp
  src/imageformats/exr.cpp
  src/imageformats/kra.cpp
  src/imageformats/ora.cpp
  src/imageformats/pcx.cpp
  src/imageformats/pic.cpp
  src/imageformats/psd.cpp
  src/imageformats/ras.cpp
  src/imageformats/rgb.cpp
  src/imageformats/tga.cpp
  src/imageformats/xcf.cpp

To: mkoller, kfunk, kossebau
Cc: #frameworks

D3987: Use nullptr in all Frameworks (just diff in KIO shown here)

[Martin Koller]

mkoller added a comment.


  I just found out that this change introduced wrong replacements.
  The changes in frameworks/kimageformats/src/imageformats like the following 
are incorrect, since the return type is not a pointer but an enum flags type, 
so it should still be 0, not nullptr.
  
  @@ -337,10 +337,10 @@ QImageIOPlugin::Capabilities 
EPSPlugin::capabilities(QIODevice *device, const QB
  
return Capabilities(CanRead | CanWrite);
}
if (!format.isEmpty()) {
  
  - return 0;
  
  +return nullptr;
  
}
if (!device->isOpen()) {
  
  - return 0;
  
  +return nullptr;
  
}
 
Capabilities cap;

REPOSITORY
  R280 Prison

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

To: kfunk, #frameworks, dfaure, kossebau
Cc: mkoller, skelly, kossebau, dfaure, graesslin

D8519: do not make the context menu a Window; do not force raise a window

[Martin Koller]

mkoller updated this revision to Diff 21431.
mkoller added a comment.


  In https://phabricator.kde.org/D8519#160813, @davidedmundson wrote:
  
  > > The removal of the force activation is done since according to kwin 
maintainer it is wrong and must be done by the SysTray itself.
  >
  > But according the the status notifier item maintainer (defacto me), we 
cannot do this. It will break too many things.
  
  
  I thought this will be the case ...
  And I still think my previous patch makes it even better than it is now (I 
don't understand why the current code raises the window only when it's already 
shown
  but not otherwise)
  So since you are the maintainer, what is your stance on this ?

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8519?vs=21427=21431

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8519: do not make the context menu a Window; do not force raise a window

[Martin Koller]

mkoller created this revision.
mkoller added reviewers: davidedmundson, graesslin.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  The setParent() call in this patch was changing the window flags from Popup 
to Window, which leads to show the popup with a window frame when activated via 
a SysTray DBus call.
  I don't know why setParent() is done here in the first place (could not find 
the change in git history).
  If setParent() should still be done, at least the window flag must be set 
back to Popup.
  
  The removal of the force activation is done since according to kwin 
maintainer it is wrong and must be done by the SysTray itself.

REPOSITORY
  R289 KNotifications

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller abandoned this revision.

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8401: fix URL detection with double urls like "http://www.foo.bar"

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:095a75eeb212: fix URL detection with double urls like 
http://www.foo.barhttp://foo.bar/; (authored by mkoller).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8401?vs=21067=21193

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

AFFECTED FILES
  autotests/ktexttohtmltest.cpp
  src/lib/text/ktexttohtml.cpp

To: mkoller, mlaurent
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> graesslin wrote in kstatusnotifieritem.cpp:653
> It only works on X11 because KWin has a bug. KWin allows the force (which is 
> in X11 Terms a "from tool" request) without checking who sends it. I will 
> look into hardening this in KWin. Then the existing code won't work anymore.

"without checking who sends it"

Who shall be allowed to do so ?

As said, the original problem is that a click in SysTray does not raise it,
but as I understand it, the KStatusNotifierItem is owned by the application 
which receives the "Activate" trigger sent via DBus, so it would be the 
application which would raise itself. Am I right ?

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> graesslin wrote in kstatusnotifieritem.cpp:653
> The correct approach would be sni telling the host to activate the window. 
> The host could then communicate with the X11 window manager/Wayland 
> compositor through a special interface that the window should be activated.
> 
> Yes, such an interface does not yet exist. But we need it for Wayland anyway. 
> An app requesting to get activated just does not exist in a Wayland world. 
> The action is performed on the host, so the host is the only one who has 
> enough rights to activate another window.

I'm a bit confused now.
The patch solves my issue for X11 as it does some lines below already, but you 
say that this is wrong for Wayland but a solution for wayland does not exist 
right now.
I don't use Wayland, I'm on X11 and on X11 the solution works.
Why can't we simply add this 2 lines until there will be "the correct way" for 
wayland as you suggest ?
Since you say the current code is wrong anyway, it needs some adaption anyway.
So until then, the current code plus my fix improves the situation for all X11 
users, and for Wayland you can change the code when all APIs are in place.

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> graesslin wrote in kstatusnotifieritem.cpp:653
> The other code is also not correct and should be removed.

Do you mind telling me the correct approach ?

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> graesslin wrote in kstatusnotifieritem.cpp:653
> Please read the documentation of this API call. It is not meant for 
> applications to use this!
> 
> Please also note that this won't work on Wayland at all.
> 
> The proper way is to ask the systray to raise the window, which then talks to 
> the window manager / wayland compositor to activate it.
> 
> Activating from client side is nothing else than focus stealing. If that code 
> worked it means KWin's focus stealing prevention is buggy.

This code change will work as good as the other part of this file in wayland, 
since just about 30 lines below my change you find exactly the same 2 lines of 
code.
Check the "else" branch in case the window is already mapped.

So why is the existing code correct but my change not ?

"The proper way is to ask the systray to raise the window, ..."
In my case, I AM the systray (I implement my own systray) and what I do when 
the Status Notifier Item is clicked, I just call the DBus interface class 
method Activate(pos.x(), pos.y());
What's wrong with this approach ?
Do you say it's the SysTray which should call these 2 lines I added ?
I think the SysTray should not even know that the client application shows a 
window when the status notifier item was clicked. It just asks for the 
"Activate" action - whatever the client does with that.

"If that code worked it means KWin's focus stealing prevention is buggy."
Then it's buggy since it works. (my setting is "Low")

REPOSITORY
  R289 KNotifications

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

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8416: really raising window when shown from systray

[Martin Koller]

mkoller created this revision.
mkoller added reviewers: davidedmundson, graesslin.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  I have akregator running and an icon is shown in the systray.
  When the main window is currently not shown (only the systray icon) and I 
click on the systray icon, the main window
  is restored but not brought to the foreground, so it opens just behind the 
other windows I have open, which is not what I expect.
  
  This patch makes sure to raise the window.

REPOSITORY
  R289 KNotifications

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: mkoller, davidedmundson, graesslin
Cc: #frameworks

D8401: fix URL detection with double urls like "http://www.foo.bar"

[Martin Koller]

mkoller created this revision.
mkoller added a reviewer: mlaurent.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  This fixes URL detection for cases where one url with enclosing brackets 
follows one without,
  which is mentioned in the KDE bug report  #346132 (and I myself get such 
mails from company M$ mail clients)

TEST PLAN
  autotest

REPOSITORY
  R244 KCoreAddons

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

AFFECTED FILES
  autotests/ktexttohtmltest.cpp
  src/lib/text/ktexttohtml.cpp

To: mkoller, mlaurent
Cc: #frameworks

KCModuleContainer

[Martin Koller]

Hi,

I'm trying to use KCModuleContainer to show 3 kcm modules, however this class 
constantly crashes
when switching tabs.
checking the sourcecode, I see the reason:
void KCModuleContainer::tabSwitched(int index)
...
setAboutData(mod->aboutData());


but since the base class KCModule always deletes the previous set KAboutData 
(which is owned by the loaded modules)
the problem is clear.

This leads me to the general question: Is this class used at all, since
https://lxr.kde.org/ident?v=kf5-qt5&_i=KCModuleContainer
shows no users.

And another interesting thing is that the header file is installed here 
(openSuse 42.2, KF5 5.38.0) twice:

/usr/include/KF5/KDELibs4Support/KDE/KCModuleContainer
/usr/include/KF5/KCMUtils/KCModuleContainer

Is this class meant to be no longer used ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

D6941: fix plasmashell unsetting QSG_RENDER_LOOP

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R296:886dd7aaa33d: fix plasmashell unsetting QSG_RENDER_LOOP 
(authored by mkoller).

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6941?vs=17258=17276

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

AFFECTED FILES
  src/quickaddons/qtquicksettings.cpp

To: mkoller, davidedmundson
Cc: #frameworks

D6941: fix plasmashell unsetting QSG_RENDER_LOOP

[Martin Koller]

mkoller created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  being hit by the problem of plasmashell using way too much CPU even when 
doing "nothing", I found
  the description of the QSG_RENDER_LOOP env variable to be settable to basic, 
which solves the problem.
  However, even though I set the var in ~/.config/plasma-workspace/env/KDE5.sh 
plasmashell (and only this process)
  always ends up having the var set to an EMPTY string (I check this via 
/proc/PIC/environ).
  
  I don't know from where RendererSettings is initialized, but I assume that 
the QString inside it is
  not null but empty, so isNull() == false but isEmpty() == true
  
  With this patch, QSG_RENDER_LOOP=basic is now correct in plasmashell's env 
after a login.

REPOSITORY
  R296 KDeclarative

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

AFFECTED FILES
  src/quickaddons/qtquicksettings.cpp

To: mkoller, davidedmundson
Cc: #frameworks

D5774: speed up detail treeview display by avoiding too many column resizes

[Martin Koller]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:10e53ca3b2a7: speed up detail treeview display by 
avoiding too many column resizes (authored by mkoller).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D5774?vs=14300=14461#toc

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5774?vs=14300=14461

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

AFFECTED FILES
  src/filewidgets/kdiroperatordetailview.cpp
  src/filewidgets/kdiroperatordetailview_p.h

To: mkoller, dfaure
Cc: #frameworks

D5774: speed up detail treeview display by avoiding too many column resizes

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> dfaure wrote in kdiroperatordetailview.cpp:156
> Is there any risk that this connect is done multiple times?

To be honest, I don't know. I'll add Qt::UniqueConnection just to be safe

REPOSITORY
  R241 KIO

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

To: mkoller, dfaure
Cc: #frameworks

D5774: speed up detail treeview display by avoiding too many column resizes

[Martin Koller]

mkoller created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  This patch basically delays the connect to the layoutChanged model signal 
until it emits its completed() signal.
  Therefore the many calls for the expensive expandNameColumn() method are 
avoided.
  
  This fixes bug https://bugs.kde.org/show_bug.cgi?id=346403
  (how to define this bug to be related in phabricator I don't know)

TEST PLAN
  kdialog --getsavefilename /tmp
  where my /tmp is not really large (~570 files)

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/filewidgets/kdiroperatordetailview.cpp
  src/filewidgets/kdiroperatordetailview_p.h

To: mkoller, dfaure
Cc: #frameworks

Re: KConfigDialogManager and QButtonGroup

[Martin Koller]

On Samstag, 6. Mai 2017 13:48:00 CEST David Faure wrote:
> On samedi 6 mai 2017 11:41:41 CEST Martin Koller wrote:
> > On Samstag, 6. Mai 2017 11:20:06 CEST David Faure wrote:
> > > On lundi 1 mai 2017 20:31:28 CEST Martin Koller wrote:
> > > > from Qt4 days, where the groupBox
> > > > did also manage the buttons, whereby now you need a QButtonGroup class.
> > > 
> > > That's a Qt3-Qt4 change, not a Qt4-Qt5 change ;)
> > 
> > Now you see how long I already work with Qt ;-)
> 
> I started with Qt 1.4 :-)

You won :-)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: KConfigDialogManager and QButtonGroup

[Martin Koller]

On Dienstag, 2. Mai 2017 11:30:04 CEST Albert Astals Cid wrote:
> El dilluns, 1 de maig de 2017, a les 20:31:28 CEST, Martin Koller va escriure:
> > Hi,
> > 
> > trying to fix https://bugs.kde.org/show_bug.cgi?id=378930
> > 
> > I see that the mboxresource has a configuration dialog which uses
> > KConfigDialogManager to handle the settings, but it has a QGroupBox widget
> > holding QRadioButtons, which represent one setting (e.g. one of 2 possible
> > compaction methods).
> > 
> > In the .ui file, the QGroupBox(!) has the name kcfg_CompactFrequency
> > but I assume the bug lies in the fact that this stems from Qt4 days, where
> > the groupBox did also manage the buttons, whereby now you need a
> > QButtonGroup class.
> > 
> > Am I correct and if so, what needs to be changed that KConfigDialogManager
> > works again with this radio buttons ?
> > Is KConfigDialogManager designed so that it can work with a QButtonGroup and
> > a set of radio buttons ?
> 
> Yes, see 
> https://cgit.kde.org/kconfigwidgets.git/tree/src/kconfigdialogmanager.cpp#n202

Debugging into this, I see that it does not work here since the QGroupBox
contains 2 radio buttons and one spinbox, but the kconfigdialogmanager.cpp
checks for ... wait

https://cgit.kde.org/kconfigwidgets.git/commit/src/kconfigdialogmanager.cpp?id=7db9744511373f74c28c0f40545677c9bd1b3b07

seems to solve the problem already


-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: KConfigDialogManager and QButtonGroup

[Martin Koller]

On Samstag, 6. Mai 2017 11:20:06 CEST David Faure wrote:
> On lundi 1 mai 2017 20:31:28 CEST Martin Koller wrote:
> > from Qt4 days, where the groupBox
> > did also manage the buttons, whereby now you need a QButtonGroup class.
> 
> That's a Qt3-Qt4 change, not a Qt4-Qt5 change ;)

Now you see how long I already work with Qt ;-)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

KWallet::openWallet and 0-WinId ?

[Martin Koller]

Hi,

the Wallet::openWallet() documentation says for the WinId argument:
"The window id to associate any dialogs with. You can pass 0 if you don't have 
a window the password dialog should associate with."

However passing 0 gives a runtime warning
qDebug() << "Pass a valid window to KWallet::Wallet::openWallet().";

So what is correct ?

openWallet() is used by a lot PIM resources and all these show the warning when 
akonaditray is not registered
on the DBUS (which means winId is passed as 0)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

KConfigDialogManager and QButtonGroup

[Martin Koller]

Hi,

trying to fix https://bugs.kde.org/show_bug.cgi?id=378930

I see that the mboxresource has a configuration dialog which uses 
KConfigDialogManager
to handle the settings, but it has a QGroupBox widget holding QRadioButtons,
which represent one setting (e.g. one of 2 possible compaction methods).

In the .ui file, the QGroupBox(!) has the name kcfg_CompactFrequency
but I assume the bug lies in the fact that this stems from Qt4 days, where the 
groupBox
did also manage the buttons, whereby now you need a QButtonGroup class.

Am I correct and if so, what needs to be changed that KConfigDialogManager
works again with this radio buttons ?
Is KConfigDialogManager designed so that it can work with a QButtonGroup and a 
set of radio buttons ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

KDirWatch issue

[Martin Koller]

Hi,

just wondering if I'm doing something wrong or there really is a bug in 
KDirWatch
(I'm on openSuse Leap 42.2, KF5 5.33.0)

From the docs I understand that when I call 

KDirWatch::stopDirScan(dir);
... create files in the dir ...
KDirWatch::restartDirScan(dir)

it should not emit the dirty signal when I run this, right ?

Well, it does.
I've attached a small test.

When I modify the code and use stopScan() ... create ... startScan()
I still receive the dirty signal with the path to the file I created.

Only way it works without signal is
removeDir(dir) ... create ... addDir(dir)

Is this how it's supposed to work ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.atcmake_minimum_required(VERSION 3.5)

project(dirwatch)

find_package(ECM 5.19 REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})

include(KDEInstallDirs)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(KDECMakeSettings)

find_package(KF5CoreAddons)


add_executable(dirwatch main.cxx)

target_link_libraries(dirwatch KF5::CoreAddons)
#include 
#include 
#include 
#include 

#include 

QString watchedDir;
KDirWatch *watch = 0;

class Object : public QObject
{
  Q_OBJECT

  public slots:
void createFile()
{
  watch->stopDirScan(watchedDir);
  //watch->stopScan();
  //watch->removeDir(watchedDir);

  QFile f(watchedDir + "/watched");
  f.open(QIODevice::WriteOnly);
  f.write("123");
  f.close();

  watch->restartDirScan(watchedDir);
  //watch->startScan();
  //watch->addDir(watchedDir);
}

void dirChanged(const QString )
{
  qDebug() << "dir changed" << dir;
}
};

int main(int argc, char **argv)
{
  QCoreApplication app(argc, argv);

  watchedDir = QFile::decodeName(argv[1]);

  watch = new KDirWatch;
  watch->addDir(watchedDir);

  Object o;
  o.connect(watch, ::dirty, , ::dirChanged);

  QTimer::singleShot(2000, , SLOT(createFile()));

  return app.exec();
}

#include "main.moc"

Re: Qt5 version of qimageblitz

[Martin Koller]

On Sunday 06 March 2016 12:35:32 Albert Astals Cid wrote:
> El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure:
> > On 6 March 2016 at 01:26, Martin Koller <kol...@aon.at> wrote:
> > > Who is in charge of the old SVN repos ?
> > > Who is in charge of qimageblitz ?
> > 
> > I asked around on IRC and it seems QIB is "community maintained" and
> > as such doesn't have a maintainer.
> > 
> > You should just be able to file a sysadmin ticket to get it migrated
> > from SVN to Git.
> 
> It was my understanding that qimageblitz is actually not something we want to 
> port to Qt5 and we should just try to use Qt's own stuff for this.

AFAIK Qt does not provide the features of qimageblitz, e.g. emboss etc.

> If qimageblitz gets ported to Qt5 it should basically be a Tier 0 frameworks 
> so CC'ing the frameworks devel list.

It WAS already ported to Qt5. I did not do any porting, I just created a patch 
which allows
to co-install the Qt4 and the Qt5 built version.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: What to do with KScanDialog

[Martin Koller]

On Saturday 31 August 2013 23:11:57 Kåre Särs wrote:
 I would vote to move it to kde4support and deprecate it. I can volunteer to 
 port kolourpaint to libksane if needed. 

Hi all,

I'm the current maintainer of kolourpaint.
I have no problem with using anything else than what's currently available.
I'd be happy when Kåre would do the migration - he knows best how to use 
libksane.
Thanks

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel