D28765: KSettings::Dialog: add support for KPluginInfos without a KService

[Wolfgang Bauer]

wbauer added a comment.


  This caused a crash in openSUSE:
  https://bugs.kde.org/show_bug.cgi?id=421566

REPOSITORY
  R295 KCMUtils

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

To: dfaure, pino, broulik, mart, davidedmundson, ngraham, svuorela
Cc: wbauer, kossebau, svuorela, cblack, kde-frameworks-devel, LeGast00n, 
michaelh, ngraham, bruns

D27654: [kio] Fix running konsole on Wayland

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:07ab04bfe774: Fix running konsole on Wayland (authored by 
wbauer).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27654?vs=76387=76607

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

AFFECTED FILES
  src/core/desktopexecparser.cpp

To: wbauer, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27654: [kio] Fix running konsole on Wayland

[Wolfgang Bauer]

wbauer added a comment.


  In D27654#617946 , @dfaure wrote:
  
  > Wait, you're actually passing the icon of the command being executed now 
(while the old code would end up using the stuff from konsole.desktop I 
think)
  
  
  AFAICT passing the icon of the command being executed is what is wanted here.
  I.e. the konsole window should use the icon of the application menu entry it 
is being started from.
  And the original code (with %i) actually does the same, I verified that with 
additional debug output.
  
  It's true that passing -qwindowicon (or --icon for that matter) doesn't have 
any visible effect in Plasma, not even on X11 (maybe kwin5 overrides the window 
icon?).
  It does work on other desktops hower, also running several konsole instances 
with different window icons.
  
  The intention of this patch was/is to not change the existing behavor for 
whatever it's worth, only fix the problem at hand.

REPOSITORY
  R241 KIO

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

To: wbauer, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27654: [kio] Fix running konsole on Wayland

[Wolfgang Bauer]

wbauer updated this revision to Diff 76387.
wbauer added a comment.


  Use `KShell::quoteArg()` in case the icon name contains spaces or other 
special chars.
  No idea if that's possible/allowed, but better be safe than sorry I suppose.

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27654?vs=76375=76387

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

AFFECTED FILES
  src/core/desktopexecparser.cpp

To: wbauer, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27654: [kio] Fix running konsole on Wayland

[Wolfgang Bauer]

wbauer edited the test plan for this revision.

REPOSITORY
  R241 KIO

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

To: wbauer, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27654: [kio] Fix running konsole on Wayland

[Wolfgang Bauer]

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

REVISION SUMMARY
  %i expands to "--icon someicon", but Qt recognizes this option only on 
X11/xcb.
  So konsole failed to start on Wayland.
  
  To fix this problem, pass "-qwindowicon" instead, which is supported on all 
platforms.
  
  See 
https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Exec_key_of_.desktop_files
 for details.
  
  BUG: 408497
  FIXED-IN: 5.68.0

TEST PLAN
  Create a menu entry in kmenueditor that calls a command line application 
(say, "top"), with "Run in Terminal" (on the "Advanced" tab) enabled.
  Try to start it from the application menu.
  
  konsole starts successfully on Wayland now too, with or without an icon set.
  Still works on X11/xcb as well.

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/core/desktopexecparser.cpp

To: wbauer, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27589: Try to apply the colorscheme of the current theme to QIcons

[Wolfgang Bauer]

wbauer added a comment.


  Confirmed. I tried out the patch now, and that problem is gone.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  qiconcolor (branched from master)

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

To: davidre, #plasma, cblack
Cc: wbauer, cblack, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D27589: Try to apply the colorscheme of the current theme to QIcons

[Wolfgang Bauer]

wbauer added a comment.


  Sounds like it would fix https://bugs.kde.org/show_bug.cgi?id=417780 ?

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  qiconcolor (branched from master)

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

To: davidre, #plasma, cblack
Cc: wbauer, cblack, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D11880: Add firewall-config and firewall-applet icons

[Wolfgang Bauer]

wbauer added a comment.


  In D11880#331450 , @ngraham wrote:
  
  > However, there seems to be a problem for the breeze dark versions:
  >  F6283726: Screenshot_20180924_215524.png 

  >
  > Shouldn't the wall be light-colored? Does it work for you when actually 
deployed and in use with breeze dark?
  
  
  
  
  In D11880#331724 , @ngraham wrote:
  
  > Never mind, it's a Cuttlefish issue. Everything looks good to me.
  
  
  Actually it's not. We got a bug report about exactly that in openSUSE:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1157921
  
  Creating the symlink firewall-applet-shields_up -> firewall-applet fixes it, 
so it's probably a bug in the icon loader when doing the fallback...

REPOSITORY
  R266 Breeze Icons

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

To: ndavis, #vdg, #breeze, ngraham
Cc: wbauer, dfaure, bruns, abetts, alex-l, svenmauch, kde-frameworks-devel, 
ngraham, LeGast00n, cblack, GB_2, michaelh

D27433: Check activeModule before using it

[Wolfgang Bauer]

wbauer closed this revision.
wbauer added a comment.


  Committed with 
https://commits.kde.org/kcmutils/ea7120ed901bf6161bb483ab73211a6491daac8f

REPOSITORY
  R295 KCMUtils

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

To: wbauer, #frameworks, davidedmundson, ervin
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27433: Check activeModule before using it

[Wolfgang Bauer]

wbauer edited the summary of this revision.

REPOSITORY
  R295 KCMUtils

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

To: wbauer, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D26519: Show button respecting what is declared by KCModule

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> kcmultidialog.cpp:184
>  
> +auto buttons = activeModule->buttons();
> +

`activeModule` can be a nullptr here, as this is outside/after the `if 
(activeModule)`.
This causes the kontact crash.

Possible fix: D27433 

REPOSITORY
  R295 KCMUtils

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

To: bport, ervin, meven, crossi, davidedmundson
Cc: wbauer, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27433: Check activeModule before using it

[Wolfgang Bauer]

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

REVISION SUMMARY
  `activeModule` can be a nullptr here, as this is outside/after the `if 
(activeModule)`.
  This causes kontact to crash when opening it's settings.
  
  BUG: 417396
  FIXED-IN: 5.68.0

TEST PLAN
  Start kontact and select "Configure Kontact" in ist "Settings" menu. It 
doesn't crash anymore.

REPOSITORY
  R295 KCMUtils

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

AFFECTED FILES
  src/kcmultidialog.cpp

To: wbauer, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D26519: Show button respecting what is declared by KCModule

[Wolfgang Bauer]

wbauer added a comment.


  This change causes kontact to crash when opening its settings:
  https://bugs.kde.org/show_bug.cgi?id=417396

REPOSITORY
  R295 KCMUtils

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

To: bport, ervin, meven, crossi, davidedmundson
Cc: wbauer, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

Re: When will akonadi work with Gmail?

[Wolfgang Bauer]

See https://bugs.kde.org/show_bug.cgi?id=404990 .

In short, it's not a bug in kmail or akonadi, but rather a "political" problem 
because Google themselves blocked access.

Doesn't mean it shouldn't get fixed from the KDE side though, rather the 
opposite.
But me personally don't really know what the remaining problems are.

Maybe somebody else here can step up and finally help to solve it?

Kind Regards,
Wolfgang

D24314: Improve KFloppy icon

[Wolfgang Bauer]

wbauer accepted this revision.
wbauer added a comment.


  Thanks!

REPOSITORY
  R266 Breeze Icons

BRANCH
  better-kfloppy-icon (branched from master)

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

To: ngraham, #vdg, ndavis, wbauer
Cc: wbauer, ndavis, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D22258: Improve plugin caching

[Wolfgang Bauer]

wbauer added a comment.


  In D22258#539682 , @davidedmundson 
wrote:
  
  > I don't know the situation well enough to know whether it's valid that it's 
invalid or not. Let's follow that up in your bug report.
  
  
  The problem apparently is that the mentioned plugins have their metadata in a 
.desktop file, but the code here creates the KFileMetaData from the .so file 
(so the metadata is empty).
  See the bug report for more details.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: apol, #plasma, davidedmundson, mart
Cc: wbauer, davidedmundson, mart, broulik, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, ngraham, bruns

D22258: Improve plugin caching

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> davidedmundson wrote in pluginloader.cpp:860
> Changed.
> Though that won't stop the warning from appearing.

True. Maybe it would be better to downgrade it to qCDebug()?
(until the existing invalid metadata is fixed at least)

REPOSITORY
  R242 Plasma Framework (Library)

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

To: apol, #plasma, davidedmundson, mart
Cc: wbauer, davidedmundson, mart, broulik, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, ngraham, bruns

D22258: Improve plugin caching

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> pluginloader.cpp:860
> +if (!metadata.isValid()) {
> +qWarning() << "invalid metadata" << pluginPath;
> +return;

Shouldn't this use categorized logging as well?

It causes *lots* of warnings from plasmashell, see 
https://bugs.kde.org/show_bug.cgi?id=412464

REPOSITORY
  R242 Plasma Framework (Library)

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

To: apol, #plasma, davidedmundson, mart
Cc: wbauer, davidedmundson, mart, broulik, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, ngraham, bruns

D22525: kioclient: Don't convert `:x:y` to `?line=x=y` for URLs starting with remote schemes.

[Wolfgang Bauer]

wbauer added a comment.


  What about the stable 5.16 branch?
  It has only be committed to master so far AFAICS, so the fix would only end 
up in Plasma 5.17 which is still 3 months away...

REPOSITORY
  R126 KDE CLI Utilities

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

To: arrowd, #frameworks, dfaure
Cc: wbauer, kwrite-devel, dfaure, cfeck, plasma-devel, #frameworks, LeGast00n, 
jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21952: [ftp] Fix wrong access time in Ftp::ftpCopyGet()

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:f9c2dfb6e8df: [ftp] Fix wrong access time in 
Ftp::ftpCopyGet() (authored by wbauer).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21952?vs=60195=61105

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

AFFECTED FILES
  src/ioslaves/ftp/ftp.cpp

To: wbauer, #frameworks, dfaure
Cc: dfaure, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

D21952: [ftp] Fix wrong access time in Ftp::ftpCopyGet()

[Wolfgang Bauer]

wbauer added a subscriber: dfaure.

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks
Cc: dfaure, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:5e791ef216c2: [copyjob] Only set modification time if the 
kio-slave provided it (authored by wbauer).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21955?vs=60227=60242

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

AFFECTED FILES
  src/core/copyjob.cpp

To: wbauer, #frameworks, bruns, dfaure, ngraham
Cc: ngraham, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

wbauer updated this revision to Diff 60227.
wbauer edited the summary of this revision.
wbauer added a comment.


  Check already when setting info.mtime in 
CopyJobPrivate::addCopyInfoFromUDSEntry().

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21955?vs=60202=60227

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

AFFECTED FILES
  src/core/copyjob.cpp

To: wbauer, #frameworks, bruns, dfaure, ngraham
Cc: ngraham, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

wbauer marked an inline comment as done.
wbauer added inline comments.

INLINE COMMENTS

> wbauer wrote in copyjob.cpp:1709
> I don't think mtime would be null or invalid in this case, but I'll check.

Nope.
I added this debug line:

  qDebug() << "mtime=" << (*it).mtime << "null:" << (*it).mtime.isNull() << 
"valid:" << (*it).mtime.isValid();

The output in the "broken" case, i.e. when it was set to -1:

  mtime= QDateTime(1969-12-31 23:59:59.000 UTC Qt::UTC) null: false valid: true

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks, bruns, dfaure, ngraham
Cc: ngraham, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> dfaure wrote in copyjob.cpp:1709
> Wouldn't mtime.isNull() or mtime.isValid() be simpler?

I don't think mtime would be null or invalid in this case, but I'll check.

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks, bruns, dfaure, ngraham
Cc: ngraham, kde-frameworks-devel, #dolphin, LeGast00n, michaelh, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

wbauer edited the summary of this revision.

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks
Cc: kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

wbauer edited the test plan for this revision.

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks
Cc: kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

D21955: [copyjob] Only set modification time if the kio-slave provided it

[Wolfgang Bauer]

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

REVISION SUMMARY
  If the slave didn't pass a modification time (e.g. the http slave doesn't), 
it is set to -1 in line#672:
  
info.mtime = QDateTime::fromMSecsSinceEpoch(1000 * 
entry.numberValue(KIO::UDSEntry::UDS_MODIFICATION_TIME, -1), Qt::UTC);
  
  This results in setting a wrong modification time for the destination file in 
`copyNextFile()` later on.
  
  To fix this, only set the modfication time if it is not -1.
  
  The Qt4 version had the same check, but this got lost in the port to Qt5.
  
  BUG: 374420

TEST PLAN
  Run `kioclient5 copy "http://kde.org; /tmp/file` and check the times with 
`stat`.
  
  Before:
  $ kioclient5 copy "http://kde.org; /tmp/file
  $ LANG=C stat /tmp/file
  
File: /tmp/file
Size: 19655   Blocks: 40 IO Block: 4096   regular file
  
  Device: 39h/57d Inode: 91809   Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/   wolfi)   Gid: (  100/   users)
  Access: 2019-06-21 11:08:08.0 +0200
  Modify: 1970-01-01 00:59:59.0 +0100
  Change: 2019-06-21 11:08:08.288032833 +0200
   Birth: -
  
  (note the "Modify" time)
  
  With this patch:
  $kioclient5 copy "http://kde.org; /tmp/file
  $ LANG=C stat /tmp/file
  
File: /tmp/file
Size: 19655   Blocks: 40 IO Block: 4096   regular file
  
  Device: 39h/57d Inode: 91946   Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/   wolfi)   Gid: (  100/   users)
  Access: 2019-06-21 11:28:20.369808804 +0200
  Modify: 2019-06-21 11:28:20.397808804 +0200
  Change: 2019-06-21 11:28:20.397808804 +0200
   Birth: -

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/core/copyjob.cpp

To: wbauer, #frameworks
Cc: kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

D21952: [ftp] Fix wrong access time in Ftp::ftpCopyGet()

[Wolfgang Bauer]

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

REVISION SUMMARY
  `sPartInfo` refers to the .part file which might not exist in the first 
place, resulting in a wrong/invalid access time.
  To avoid this, take the access time from the actual destination file instead.
  
  CCBUG: 374420

TEST PLAN
  Run `kioclient5 copy "ftp://upload.kde.org/README; /tmp/file` and check the 
times with `stat`.
  
  Before:
  $ kioclient5 copy "ftp://upload.kde.org/README; /tmp/file
  $ LANG=C stat /tmp/file
  
File: /tmp/file
Size: 594 Blocks: 8  IO Block: 4096   regular file
  
  Device: 39h/57d Inode: 91811   Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/   wolfi)   Gid: (  100/   users)
  Access: 1970-01-01 00:00:00.0 +0100
  Modify: 2013-04-27 00:00:00.0 +0200
  Change: 2019-06-21 11:09:38.980032795 +0200
   Birth: -
  
  (note the "Access" time)
  
  With this patch:
  $ kioclient5 copy "ftp://upload.kde.org/README; /tmp/file
  $ LANG=C stat /tmp/file
  
File: /tmp/file
Size: 594 Blocks: 8  IO Block: 4096   regular file
  
  Device: 39h/57d Inode: 91947   Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/   wolfi)   Gid: (  100/   users)
  Access: 2019-06-21 11:28:49.0 +0200
  Modify: 2013-04-27 00:00:00.0 +0200
  Change: 2019-06-21 11:28:49.529808792 +0200
   Birth: -

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/ioslaves/ftp/ftp.cpp

To: wbauer, #frameworks
Cc: kde-frameworks-devel, #dolphin, LeGast00n, michaelh, ngraham, bruns

Re: Maintenance status of KMid?

[Wolfgang Bauer]

Am Donnerstag, 30. Mai 2019, 00:02:08 schrieb Shinjo Park:
> I'd llike to ask whether KMid is maintained or not:
It uses drumstick as backend AFAIK, and I think the drumstick maintainer 
talked about porting kmid to Qt5 somewhere.

Can't find it currently though...

Anyway, maybe ask at
http://drumstick.sourceforge.net/
(the "Drumstick Karaoke" link actually points to kmid2 sources)

Kind Regards,
Wolfgang

Re: Debugging laptop screen not being locked on machine suspension

[Wolfgang Bauer]

I don't know if that could be the problem here, but screenlocking after resume 
doesn't work if a context menu is open when you close the lid/suspend the 
system.
And apparently that's unfixable on X11...

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

Kind Regards,
Wolfgang

Re: KDiff3 1.8 release.

[Wolfgang Bauer]

The latest change 
(https://cgit.kde.org/kdiff3.git/commit/?id=638bd5a02893dde4a1927abd0c8a611b3b3ab6a1)
  
unfortunately breaks the build here:

/usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld: 
CMakeFiles/kdiff3part.dir/pdiff.cpp.o: in function 
`debugLineCheck(Diff3LineList&, int, e_SrcSelector)':
/home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:82: undefined 
reference to `kdeMain()'
/usr/lib/gcc/i586-suse-linux/8/../../../../i586-suse-linux/bin/ld: 
/home/abuild/rpmbuild/BUILD/kdiff3-1.7.95git/src/pdiff.cpp:96: undefined 
reference to `kdeMain()'
...
and so on.

Kind Regards,
Wolfgang

D19581: Fix build with cmake < 3.7

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R216:a08e2ebd589f: Fix build with cmake  3.7 (authored by 
wbauer).

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19581?vs=53332=53336

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

AFFECTED FILES
  data/CMakeLists.txt

To: wbauer, vkrause
Cc: kwrite-devel, kde-frameworks-devel, cullmann, gennad, bmortimer, domson, 
michaelh, genethomas, ngraham, bruns, demsking, vkrause, sars, dhaumann

D19581: Fix build with cmake < 3.7

[Wolfgang Bauer]

wbauer created this revision.
wbauer added a project: Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
wbauer requested review of this revision.

REVISION SUMMARY
  VERSION_GREATER_EQUAL requires cmake 3.7 or higher, but the minimum version 
supported by KDE Frameworks is 3.5.
  So use NOT VERSION_LESS instead, which is logically equivalent and also
  works with older cmake versions.

TEST PLAN
  Builds fine with cmake 3.5.2 now.
  Before, I got this cmake error:
  
CMake Error at data/CMakeLists.txt:69 (if):
  if given arguments:

"3.5.2" "VERSION_GREATER_EQUAL" "3.13.0"

  Unknown arguments specified
  
  Still builds fine with newer cmake versions, tested with 3.10.2 and 3.13.4.

REPOSITORY
  R216 Syntax Highlighting

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

AFFECTED FILES
  data/CMakeLists.txt

To: wbauer
Cc: kwrite-devel, kde-frameworks-devel, cullmann, gennad, bmortimer, domson, 
michaelh, genethomas, ngraham, bruns, demsking, vkrause, sars, dhaumann

D18479: Fix NTFS hidden check for symlinks to NTFS mountpoints

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:01a7e0e757d3: Fix NTFS hidden check for symlinks to NTFS 
mountpoints (authored by wbauer).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18479?vs=50132=53061

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

AFFECTED FILES
  src/ioslaves/file/file_unix.cpp

To: wbauer, #frameworks, #dolphin, ngraham
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18479: Fix NTFS hidden check for symlinks to NTFS mountpoints

[Wolfgang Bauer]

wbauer added a comment.


  Ping?

REPOSITORY
  R241 KIO

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

To: wbauer, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18941: Fix build with cmake 3.5

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R286:1632a6972279: Fix build with cmake 3.5 (authored by 
wbauer).

REPOSITORY
  R286 KFileMetaData

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18941?vs=51466=51475

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

AFFECTED FILES
  src/extractors/CMakeLists.txt

To: wbauer, #build_system, cgiboudeaux, bruns
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

D18941: Fix build with cmake 3.5

[Wolfgang Bauer]

wbauer edited the summary of this revision.

REPOSITORY
  R286 KFileMetaData

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

To: wbauer
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

D18941: Fix build with cmake 3.5

[Wolfgang Bauer]

wbauer edited the test plan for this revision.

REPOSITORY
  R286 KFileMetaData

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

To: wbauer
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

D18941: Fix build with cmake 3.5

[Wolfgang Bauer]

wbauer created this revision.
wbauer added a project: Frameworks.
Herald added subscribers: Baloo, kde-frameworks-devel.
Herald added a project: Baloo.
wbauer requested review of this revision.

REVISION SUMMARY
  VERSION_GREATER_EQUAL requires cmake 3.7 or higher.
  So use NOT VERSION_LESS instead, which is logically the same and also works 
with older cmake versions.

TEST PLAN
  Builds fine with cmake 3.5.2 now.
  Before, I got this cmake error:
  
CMake Error at src/extractors/CMakeLists.txt:39 (if):
  if given arguments:

"0.25" "VERSION_GREATER_EQUAL" "0.26"

  Unknown arguments specified

REPOSITORY
  R286 KFileMetaData

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

AFFECTED FILES
  src/extractors/CMakeLists.txt

To: wbauer
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

D18479: Fix NTFS hidden check for symlinks to NTFS mountpoints

[Wolfgang Bauer]

wbauer added a comment.


  In D18479#398655 , @wbauer wrote:
  
  > The existing check did work fine for me back in D13782 
 also for symlinks for some reason.
  >  Maybe this broke because of some change in the kernel or glibc? :-/
  
  
  I assume the symlink had the type of the target back then (on my systems at 
least), and that has been fixed meanwhile...

REPOSITORY
  R241 KIO

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

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

D18479: Fix NTFS hidden check for symlinks to NTFS mountpoints

[Wolfgang Bauer]

wbauer added a comment.


  The existing check did work fine for me back in D13782 
 also for symlinks for some reason.
  Maybe this broke because of some change in the kernel or glibc? :-/

REPOSITORY
  R241 KIO

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

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

D18479: Fix NTFS hidden check for symlinks to NTFS mountpoints

[Wolfgang Bauer]

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

REVISION SUMMARY
  A symlink to the mountpoint of an NTFS partition can have the type DT_LNK.
  So extend the check to cover that case as well.
  
  BUG: 402738

TEST PLAN
  Create a symlink to an NTFS mountpoint.
  Open dolphin and browse to the folder containing the symlink.
  
  It is not hidden anymore.

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/ioslaves/file/file_unix.cpp

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

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R282:88f3093c5237: [proxysetting] Fix build with NM 1.4 
(authored by wbauer).

REPOSITORY
  R282 NetworkManagerQt

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17529?vs=47446=47454

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

AFFECTED FILES
  src/settings/proxysetting.h

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer edited the summary of this revision.

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer requested review of this revision.

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer updated this revision to Diff 47446.
wbauer edited the summary of this revision.
wbauer added a comment.


  Don't define the enum, rather use the numbers directly

REPOSITORY
  R282 NetworkManagerQt

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17529?vs=47426=47446

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

AFFECTED FILES
  src/settings/proxysetting.h

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer added a comment.


  In D17529#375909 , @jgrulich wrote:
  
  > So maybe go with the easiest approach and just instead of defines use 0 and 
1?
  
  
  Fine with me.
  
  Should I make that conditional depending on the NM version maybe, or just 
unconditionally use the constants?

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer added a comment.


  Hm, maybe I should add `extern "C"` though?
  This is inside `G_BEGIN_DECLS`/`G_END_DECLS` in nm-setting-proxy.h, which are 
defined as `extern "C" {` and `}` (according to the docs).

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer added a comment.


  In D17529#375882 , @wbauer wrote:
  
  > I don't think that really is a problem here though, as it is defined in 
libnm/nm-setting-proxy.h (in NM 1.6+) which is included by this file (via 
NetworkManager.h that's included by setting.h).
  >  I.e. the enum will still be there when building against NM 1.6.0+ 
(otherwise the build would fail in the first place anyway, as it is used just a 
few lines below).
  
  
  Sorry, I somehow read "API incompatible"...
  
  TBH, I'm not sure about ABI either. But as this is outside of any class, it 
shouldn't be a problem? (as mentioned, it would be defined by another include 
file anyway when building against  NM 1.6.0+)

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer added a comment.


  In D17529#375867 , @jgrulich wrote:
  
  > I think the easiest solution here is just to set 0 and 1 to the enum 
values, instead of NM defines.
  
  
  Sure, that would work as well.
  
  But IMHO the version check would make it easier to remove this "hack" when 
the minimum NM version would be raised at some point in the future.
  
  Whatever you prefer though.
  
  > I'm not sure if adding/removing enum is ABI compatible change, because the 
enum will disapper once you build it against NM 1.6.0+.
  
  Hm, I see what you mean.
  
  I don't think that really is a problem here though, as it is defined in 
libnm/nm-setting-proxy.h (in NM 1.6+) which is included by this file (via 
NetworkManager.h that's included by setting.h).
  I.e. the enum will still be there when building against NM 1.6.0+ (otherwise 
the build would fail in the first place anyway, as it is used just a few lines 
below).

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

wbauer added a reviewer: jgrulich.

REPOSITORY
  R282 NetworkManagerQt

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

To: wbauer, jgrulich
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17529: [proxysetting] Fix build with NM 1.4

[Wolfgang Bauer]

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

REVISION SUMMARY
  The `NMSettingProxyMethod` enum only exists since NetworkManager 1.6.
  So define it appropriately when building with a lower version (i.e. 1.4.x).

TEST PLAN
  Builds fine now with NM 1.4.x, before there were compiler errors:
  
In file included from 
/home/abuild/rpmbuild/BUILD/networkmanager-qt-VERSIONgit.20181211T113515~4332597/src/settings/proxysetting.cpp:21:0:

/home/abuild/rpmbuild/BUILD/networkmanager-qt-VERSIONgit.20181211T113515~4332597/src/settings/proxysetting.h:43:16:
 error: 'NM_SETTING_PROXY_METHOD_NONE' was not declared in this scope
 None = NM_SETTING_PROXY_METHOD_NONE,
^

/home/abuild/rpmbuild/BUILD/networkmanager-qt-VERSIONgit.20181211T113515~4332597/src/settings/proxysetting.h:44:16:
 error: 'NM_SETTING_PROXY_METHOD_AUTO' was not declared in this scope
 Auto = NM_SETTING_PROXY_METHOD_AUTO
^
  
  Still compiles with newer versions, tested with 1.6.0, 1.10.6, and 1.14.4.

REPOSITORY
  R282 NetworkManagerQt

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

AFFECTED FILES
  src/settings/proxysetting.h

To: wbauer
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

RE: Increasing KF5 cmake requirement to 3.6?

[Wolfgang Bauer]

> -Original Message-
> I'm going to suggest it to increase it to 3.6, it would still most
probably be a lie
> since i don't think any of use uses such an old (2 years version) either

We currently do still build the latest KDE Frameworks, Plasma, and
Applications on/for openSUSE Leap 42.3 (plus latest Qt5) with cmake 3.5.2.
 
Only problem so far: discover started to use a new feature of cmake 3.6 in
the latest (bugfix) version, namely the IMPORTED_TARGET option to
pkg_checkmodule(), so the flatpak and fwupd backends are not built anymore
with cmake 3.5.2. (cmake says "No package 'IMPORTED_TARGET' found")
https://cgit.kde.org/discover.git/commit/?h=Plasma/5.14=d9ccf1d41fc3265ae
e9e01eebbc090b163fefe07
https://cgit.kde.org/discover.git/commit/?h=Plasma/5.14=2fe3d58fc652fc995
7f063cbbd0722dc1cf45730
(we couldn't build the fwupd backend anyway though because fwupd is too old)

Kind Regards,
Wolfgang

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

[Wolfgang Bauer]

wbauer added a comment.


  In D16692#355070 , @ngraham wrote:
  
  > The point is, there is no reason to reference distos (which are downstream 
from us) when we fix issues here. It does not matter that many or even most 
reports came from Neon. All rolling release distros have Frameworks 5.51, so it 
certainly was not just Neon users experiencing the issue.
  
  
  IIANM, the crash should be fixed by this commit in kcrash:
  
https://cgit.kde.org/kcrash.git/commit/?id=6dbd0edec10f65ff00341ccca94a052bbd55a876
  ( see also 
https://mail.kde.org/pipermail/release-team/2018-October/011106.html )
  
  Maybe that is not included yet in KDE Neon for some reason?
  IIRC this needed a respin on release day: 
https://mail.kde.org/pipermail/release-team/2018-October/011108.html

REPOSITORY
  R224 KDE Connect

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

To: eduisters, #kde_connect, #frameworks, albertvaka
Cc: wbauer, ngraham, fvogt, sredman, apol, jriddell, nicolasfella, albertvaka, 
kdeconnect, shivanshukantprasad, skymoore, wistak, dvalencia, rmenezes, julioc, 
Leptopoda, timothyc, jdvr, yannux, Danial0_0, johnq, Pitel, adeen-s, 
SemperPeritus, daniel.z.tg, jeanv, seebauer, bugzy, MayeulC, menasshock, tctara

D15096: [PreviewJob] Send enabled thumbnail plugins to the thumbnail slave

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> previewjob.cpp:641
>  job->addMetaData(QStringLiteral("plugin"), 
> currentItem.plugin->library());
> +//job->addMetaData(QStringLiteral("enabledPlugins"), 
> enabledPlugins.join(QLatin1Char(',')));
>  if (sequenceIndex) {

That line is commented out. Is this intentional?
I don't see how this will change anything... ;-/

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, fvogt, kossebau
Cc: wbauer, kde-frameworks-devel, michaelh, ngraham, bruns

Re: Kdiff3 in kdereview

[Wolfgang Bauer]

Am Freitag, 14. September 2018, 16:36:10 schrieb Michael Reeves:
> Can some do a clean install and see if right clicking on a file brings up
> the kdiff3 context menu?

You mean right-clicking on a file in dolphin?

Seems to work fine here with latest git master, the kdiff3 menu does show up, 
and seems to work as expected.

That's openSUSE 42.3 with latest KF5 and Qt5 (not a clean install though).

Kind Regards,
Wolfgang

Re: Port Kppp to Qt5

[Wolfgang Bauer]

I had a look at it a couple of months ago, when we were about to give up all 
applications not ported to KF5.

It still uses Qt3 stuff, which wasn't possible to port to Qt4 (or Qt5 
therefore) easily, so I gave up then.

But if you do want to do it, I'll try to help.

Kind Regards,
Wolfgang

D13782: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> file_unix.cpp:567
> +if (ep->d_type == DT_DIR || ep->d_type == DT_UNKNOWN) {
> +const QString fullFilePath = 
> QDir::cleanPath(QDir().absoluteFilePath(filename));
> +auto mountPoint = 
> KMountPoint::currentMountPoints().findByPath(fullFilePath);

This still doesn't handle symlinks.
E.g. if you create a symlink to the NTFS partition's mount point/root dir on 
your desktop, it will still be hidden.

As mentioned, `const QString fullFilePath = QDir(filename).canonicalPath();` 
instead should fix that (and still handle `.` and `..`).

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, yurikoles, bruns
Cc: ngraham, oysteins, wbauer, kde-frameworks-devel, michaelh, bruns

D13808: Fix KMainWindow saving incorrect widget settings

[Wolfgang Bauer]

wbauer added a comment.


  In D13808#299791 , @ngraham wrote:
  
  > In the Bugzilla ticket, it was mentioned that KMail (and only KMail)  still 
suffers from the issue even with this patch, so it might be a KMail-specific 
issue.
  
  
  For reference: https://bugs.kde.org/show_bug.cgi?id=396339

REPOSITORY
  R263 KXmlGui

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

To: maxrd2, #kde_applications, dfaure, elvisangelaccio, broulik, cfeck
Cc: anthonyfieroni, marten, asturmlechner, wbauer, aacid, ngraham, 
kde-frameworks-devel, michaelh, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added a comment.


  In D13782#297639 , @wbauer wrote:
  
  > Using QDir::canonicalPath() (instead of QDir::cleanPath() ) would fix all 3 
cases:
  >
  >   const QString fullFilePath = QDir(path + QLatin1Char('/') + 
filename).canonicalPath();
  >
  
  
  Or rather, as the current directory is set to `path` in line#507, this would 
actually suffice:
  
const QString fullFilePath = QDir(filename).canonicalPath();

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, yurikoles, bruns
Cc: ngraham, oysteins, wbauer, kde-frameworks-devel, michaelh, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added a comment.


  In D13782#297547 , @wbauer wrote:
  
  > With additional debug output I do see the '.' entry in the root dir still 
marked as hidden (as mentioned in the test plan), and also the '..' entry in 
(first-level) subdirs is hidden.
  
  
  I also found another problem though: symlinks to the mountpoint/NTFS root dir 
are (still) hidden as well (also if they are on different partitions).
  
  Using QDir::canonicalPath() (instead of QDir::cleanPath() ) would fix all 3 
cases:
  
const QString fullFilePath = QDir(path + QLatin1Char('/') + 
filename).canonicalPath();
  
  (that one isn't static...)

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, yurikoles, bruns
Cc: ngraham, oysteins, wbauer, kde-frameworks-devel, michaelh, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added a subscriber: ngraham.
wbauer added a comment.


  In D13782#296381 , @ngraham wrote:
  
  > @wbauer, does this work for you now?
  
  
  Yes, it does work as expected now here in all cases I tested, and I didn't 
notice problems.
  
  With additional debug output I do see the '.' entry in the root dir still 
marked as hidden (as mentioned in the test plan), and also the '..' entry in 
(first-level) subdirs is hidden.
  This could be fixed e.g. by using QDir::cleanPath(), i.e.:
  
const QString fullFilePath = QDir::cleanPath(path + QLatin1Char('/') + 
filename);
  
  But I'm not sure that is really necessary as those entries are not displayed 
at all anyway (even with hidden files enabled).

INLINE COMMENTS

> file_unix.cpp:575
> +if (ntfsHidden) {
> +entry.insert(KIO::UDSEntry::UDS_HIDDEN, 1);
> +}

This is entry.fastInsert(...) now as of KIO 5.48.0, see 
https://cgit.kde.org/kio.git/commit/?id=7048d259529fd37134e9bc1bc8d3edc3d4ac8ef4
Maybe the patch should be rebased...

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, yurikoles, bruns
Cc: ngraham, oysteins, wbauer, kde-frameworks-devel, michaelh, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> file_unix.cpp:566
> +// Bug 392913: NTFS root volume is always "hidden", 
> ignore this
> +if (ep->d_type == DT_DIR) {
> +const QString fullFilePath = path + QLatin1Char('/') 
> + filename;

Changing this to 'if (ep->d_type == DT_DIR || ep->d_type == DT_UNKNOWN) {' 
makes it work in both mentioned cases (internal harddisk mounted on boot via 
fstab, and external USB stick mounted via dolphin/solid) for me.

And hidden directories on the filesystem still are hidden.

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, ngraham, yurikoles, bruns
Cc: wbauer, kde-frameworks-devel, michaelh, ngraham, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added a comment.


  In D13782#287336 , @wbauer wrote:
  
  > I tried the patch and it doesn't make a difference here, the mountpoint of 
my NTFS partition is still hidden.
  >  (it's on an internal drive and mounted to /windows/C via fstab in case it 
matters)
  >
  > Additional debug output showed that ep->d_type is not DT_DIR but 0 (which 
would be DT_UNKNOWN IIANM?) in my case.
  
  
  It does seem to matter.
  I just created an NTFS partition on an USB stick, mounted it via dolphin (to 
/run/media/...) and in this case ep->d_type is indeed DT_DIR, the patch works 
as intended in this case.
  
  So maybe you should check for DT_UNKNOWN as well...

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, ngraham, yurikoles, bruns
Cc: wbauer, kde-frameworks-devel, michaelh, ngraham, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Wolfgang Bauer]

wbauer added a comment.


  I tried the patch and it doesn't make a difference here, the mountpoint of my 
NTFS partition is still hidden.
  (it's on an internal drive and mounted to /windows/C via fstab in case it 
matters)
  
  Additional debug output showed that ep->d_type is not DT_DIR but 0 (which 
would be DT_UNKNOWN IIANM?) in my case.

REPOSITORY
  R241 KIO

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

To: broulik, dfaure, ngraham, yurikoles, bruns
Cc: wbauer, kde-frameworks-devel, michaelh, ngraham, bruns

D13808: Fix KMainWindow saving incorrect widget settings

[Wolfgang Bauer]

wbauer added a comment.


  In D13808#286965 , @maxrd2 wrote:
  
  > Relative Qt Bug is here: https://bugreports.qt.io/browse/QTBUG-69277
  >  Seems it's not their bug.
  
  
  Hm.
  Interestingly, Qt Creator has similar problems with Qt 5.11.1 that are also 
fixed by reverting that commit in Qt:
  http://bugzilla.opensuse.org/show_bug.cgi?id=1099752
  (and Qt Creator also doesn't use kxmlgui AFAIK... ;-) )
  
  And the second last comment in https://codereview.qt-project.org/#/c/227398/ 
says:
  
  > This change somehow breaks QMainWindow::saveState() when it's called from 
the destructor: toolbars are not shown on the next start.
  
  Anyway, that's not really related to this review, or whether the proposed 
change makes sense...

REPOSITORY
  R263 KXmlGui

BRANCH
  fix-window-state-save

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

To: maxrd2, #kde_applications, dfaure, elvisangelaccio, broulik, cfeck
Cc: wbauer, aacid, ngraham, kde-frameworks-devel, michaelh, bruns

D13808: Fix KMainWindow saving incorrect widget settings

[Wolfgang Bauer]

wbauer added a comment.


  I just like to note that VirtualBox has the same problem with Qt 5.11.1, that 
the toolbar and the status bar disappear on next start if you close the window:
  http://bugzilla.opensuse.org/show_bug.cgi?id=1099589
  So it does not only affect applications using KMainWindow...

REPOSITORY
  R263 KXmlGui

BRANCH
  fix-window-state-save

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

To: maxrd2, #kde_applications, dfaure, elvisangelaccio, broulik, cfeck
Cc: wbauer, aacid, ngraham, kde-frameworks-devel, michaelh, bruns

Re: kdiff3 status

[Wolfgang Bauer]

Am Freitag, 23. Februar 2018, 17:03:37 CET schrieben Sie:
> Fixed now thanks.

Thank you.

I can confirm that with latest master it is indeed being built here (without 
libkde4-devel or "patching" it), and it does work fine as well... ;-)

Kind Regards,
Wolfgang

Re: kdiff3 status

[Wolfgang Bauer]

Am Dienstag, 20. Februar 2018, 01:47:26 schrieben Sie:
> I'll take a look thanks. Is it given error out out or just not building?

I should have been more detailed in the first place, sorry.

It is not being built at all. From the build log:
-- kabstractfileitemactionplugin.h found... NO
--=> kdiff3fileitemactionplugin (KDiff3 contextmenu plugin for 
Konqueror/Dolphin, KDE>4.6) will not be built.)
-- No automatic fallback provided current configuration is not supported for 
plugin...

As I found out meanwhile, the problem is the check in CMakeLists.txt.
The file kabstractfileitemactionplugin.h is not found, unless I install 
libkde4-devel as well
(which of course shouldn't be necessary).

If I add an unconditional "add_subdirectory(kdiff3fileitemactionplugin)" 
instead,
it is being built and builds successfully.

Kind Regards,
Wolfgang

Re: kdiff3 status

[Wolfgang Bauer]

Am Samstag, 17. Februar 2018, 05:03:52 schrieb Wolfgang Bauer:
> While it builds fine in general, I couldn't get the kfileitemaction plugin
> to build, so that it shows up in dolphin's context menu e.g.

I think I found the reason meanwhile:
if I additionally install the *KDE4* development files (package libkde4-devel 
in openSUSE) it is being built.

That's a bug I think though.

Kind Regards,
Wolfgang

Re: kdiff3 status

[Wolfgang Bauer]

I haven't looked at the code at all, I'll leave that up to others.

But one thing:
While it builds fine in general, I couldn't get the kfileitemaction plugin to 
build, so that it shows up in dolphin's context menu e.g.

OTOH, the version from git://anongit.kde.org/scratch/thomasfischer/kdiff3.git 
(kf5 branch) works fine in this regard.

Maybe you should add this commit?
https://cgit.kde.org/scratch/thomasfischer/kdiff3.git/commit/?h=kf5=08f309ef1154232e356515ace4846c932c570940
(untested though, i.e. I'm not sure that this alone will help)

Thanks.

Kind Regards,
Wolfgang

D9675: Don't show context menu menu if right-clicking outside

[Wolfgang Bauer]

wbauer added a comment.


  In D9675#207283 , @wbauer wrote:
  
  > I suppose that would fix https://bugs.kde.org/show_bug.cgi?id=373653 ?
  
  
  Just tried it myself, and it does fix it.

REPOSITORY
  R263 KXmlGui

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

To: broulik, #frameworks
Cc: wbauer, michaelh

D9675: Don't show context menu menu if right-clicking outside

[Wolfgang Bauer]

wbauer added a comment.


  I suppose that would fix https://bugs.kde.org/show_bug.cgi?id=373653 ?

REPOSITORY
  R263 KXmlGui

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

To: broulik, #frameworks
Cc: wbauer, michaelh

D10495: Workaround to restore KF5 programs from system tray

[Wolfgang Bauer]

wbauer added a subscriber: KWin.
wbauer added a comment.


  Indeed.
  One thing that started this is https://bugs.kde.org/show_bug.cgi?id=389663
  
  I do think this should be fixed on the lower level if possible.
  
  Adding KWin as subscriber as well to hopefully get most people that have more 
insight.

REPOSITORY
  R289 KNotifications

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

To: stikonas, wbauer, #plasma, davidedmundson, volkov
Cc: #kwin, plasma-devel, kde-frameworks-devel, #frameworks, michaelh, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:78443e0f0373: Fall back to language name for translations 
lookup if locale name fails (authored by wbauer).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9793?vs=25536=25566

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

AFFECTED FILES
  modules/ECMQmLoader.cpp.in
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, #frameworks, aacid
Cc: aacid, safaalfulaij, #build_system

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer updated this revision to Diff 25536.
wbauer edited the summary of this revision.
wbauer edited the test plan for this revision.
wbauer added a comment.


  Leave bcp47Name() in for compatibility, add const.

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9793?vs=25091=25536

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

AFFECTED FILES
  modules/ECMQmLoader.cpp.in
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, #frameworks
Cc: aacid, safaalfulaij, #build_system

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer marked an inline comment as done.

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, #frameworks
Cc: aacid, safaalfulaij, #build_system

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer added a comment.


  In https://phabricator.kde.org/D9793#189595, @safaalfulaij wrote:
  
  > > Why is this an issue?
  > >  There's no difference really in loading ar/LC_MESSAGES/xxx.qm and 
LC_MESSAGES/xxx_ar.qm (or something like that), i.e. you would have the same 
problem if all translations would be in the same folder.
  >
  > Well, we were to simplify this to one call of loadTranslation, but yes, not 
a big deal.
  
  
  No.
  
  The issue is that not every locale has a separate translation, so you need 
fallbacks. (e.g. de_AT -> de)
  But it could have one, so just using the general language in any case would 
be wrong too as you couldn't have different translations for the same general 
language. (think of British English vs. American English e.g., there is a 
separate en_GB translation for KDE Frameworks)
  That's unrelated to whether the translations are in separate folders or all 
in one though, the latter wouldn't change anything IMHO.
  
  >> The only relevant things I can see is that it replaces all occurences of 
'-' with '_' (which is necessary only because it gets the languages from 
QLocale::uiLanguages()), and that it doesn't cut off at the first '_', but 
creates entries cut off at every one. (i.e. "de_XX_YY" would yield "de_XX_YY", 
"de_XX" and "de" to try, IIUIC, while the current patch would only try 
"de_XX_YY" and "de")
  >> 
  >> I could do something similar, i.e. lookup translations in a while loop and 
cut off at the right-most '_' if a lookup fails until it succeeds.
  > 
  > Well, that would be great for an ideal world. We can live for now and check 
the locales that KDE is currently translated to, and just adapt to them.
  
  It only makes a difference if the locale/language is actually set to 
something like "ll_XX_YY" (i.e. more than one '_') though, and only if there 
actually is a "ll_XX" translation.
  
  But I will probably have a look at implementing that tomorrow...
  
  > Maybe later, I like full concept implementations, but yes, not needed.
  
  This is a bugfix for existing code though, not a new implementation. ;-)
  
  But it shouldn't be hard to add (even later), just call 
QLocale::uiLanguages() instead of QLocale::system() and loop over all strings 
in the list you get (after replacing '-' with '_').
  The rest of the code is still needed (unchanged) and would be inside that 
loop.

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, #frameworks
Cc: safaalfulaij, #build_system

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer added a comment.


  In https://phabricator.kde.org/D9793#189494, @safaalfulaij wrote:
  
  > I went through Qt code, as Qt applications are opened with my language 
correctly where KF ones (those with QM) don't.
  
  
  I tested with your ar_BH locale meanwhile, and it is fixed too, i.e. 
LANGUAGE="ar_BH" didn't work either, and both LANG="ar_BH.UTF-8"/LANGUAGE="" 
and  LANGUAGE="ar_BH" do work now.
  
  > The whole issue is that we have each locale's translations in a separate 
folder (`ar/LC_MESSAGES`, `en/LC_MESSAGES`, `de/LC_MESSAGES`, etc.)
  
  Why is this an issue?
  There's no difference really in loading ar/LC_MESSAGES/xxx.qm and 
LC_MESSAGES/xxx_ar.qm (or something like that), i.e. you would have the same 
problem if all translations would be in the same folder.
  
  > Qt uses internally `find_translation` 

 which goes through a list of guesses to find the correct language, according 
to the LANGUAGE preferences and the locale itself.
  >  Maybe we can borrow that code and utilize it, that would be much better.
  
  The only relevant differences I can see is that it replaces all occurences of 
'-' with '_' (which is necessary only because it gets the languages from 
QLocale::uiLanguages()), and that it doesn't cut off at the first '_', but 
creates entries cut off at every one. (i.e. "de_XX_YY" would yield "de_XX_YY", 
"de_XX" and "de" to try, IIUIC)
  
  I could do something similar, i.e. lookup translations in a while loop and 
cut off at the right-most '_' if a lookup fails until it succeeds.
  
  The current code does get the locale/language from Qt anyway. (it calls 
QLocale::system(), which does respect LANG and LANGUAGE )
  
  It probably would also be a good idea to get a list of languages via 
QLocale::uiLanguages() instead like that find_translation() function does (that 
would also support things like LANGUAGE="de:ar"). But that's unrelated to this 
fix IMHO.

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, #frameworks
Cc: safaalfulaij, #build_system

Re: Problem in loading QM translations with LANGUAGE="" envar

[Wolfgang Bauer]

Am Wed, 10 Jan 2018 20:09:35 +0100, Albert Astals Cid  schrieb:


> Why not use ar_BH as LANGUAGE?
That probably won't help, see my previous reply here (that got delayed by 
moderation for some reason even though I am subscribed, so you may not have 
read it yet),
 or https://phabricator.kde.org/D9793

Kind Regards,
Wolfgang

Re: Problem in loading QM translations with LANGUAGE="" envar

[Wolfgang Bauer]

Hi,

I noticed a similar problem here.
My LANG is set to "de_AT.UTF-8", and if LANGUAGE is not set, parts of KDE 
applications are untranslated (i.e. those frameworks translations that come 
from .qm files are missing).

Sure, setting LANGUAGE to "de" will fix that, but it's not necessarily set on 
other desktops, and even in Plasma it will not be set on a fresh user account 
(only if you explicitly configure the language in systemsettings5).
Also, the problem will also occur if LANGUAGE is set to "de_AT" or similar.

I investigated the issue and proposed a fix here though:
https://phabricator.kde.org/D9793

Note that if you'd want to try it, you'd need to recompile all affected 
frameworks with the patched extra-cmake-modules.

Kind Regards,
Wolfgang

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer added a comment.


  I don't think bcp47Name makes any sense here.
  According to the Qt documentation, this "Returns the dash-separated language, 
script and country (and possibly other BCP47 fields) of this locale as a 
string" (and "Unlike the uiLanguages() the returned value of the bcp47Name() 
represents the locale name of the QLocale data but not the language the 
user-interface should be in").
  
  I will gladly leave it in if preferred though, and add my change afterwards 
if that fails as well.

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, #frameworks
Cc: #build_system

D9793: Fall back to language name for translations lookup if locale name fails

[Wolfgang Bauer]

wbauer created this revision.
wbauer added a reviewer: Frameworks.
wbauer added a project: Frameworks.
Restricted Application added a project: Build System.
Restricted Application added a subscriber: Build System.
wbauer requested review of this revision.

REVISION SUMMARY
  For locales like de_AT, the current code only looks in share/locale/de_AT/ 
and share/locale/de-AT/ for translation catalogs, but not in share/locale/de/ 
where they most likely are.
  That's because bcp47Name() returns "de-AT" for de_AT (though in the case of 
de_DE e.g. it does return "de").
  
  This patch instead tries to fall back to the general language by taking the 
part of the locale name before the first '_'.

TEST PLAN
  Rebuilt kwidgetsaddons with this change.
  Unset $LANGUAGE (if set) and set $LANG=de_AT.UTF-8 (or set $LANGUAGE=de_AT in 
the first place)
  Ran systemsettings5 and enter some module.
  
  Without this patch the Help/Default/Reset/Apply buttons are untranslated 
because the kwidgetsaddons translations are not loaded (according to strace or 
added debug output they are only looked up in share/locale/de_AT/ and 
share/locale/de-AT/, they are in share/locale/de/ on my system).
  With this patch the buttons are translated, the translations are now loaded 
from share/locale/de/ (after trying share/locale/de_AT/ and failing).
  
  Also ran "kdesu xxx". "Password:", "Remember password", "Cancel" were 
untranslated in the password dialog before, they are translated to german now.
  
  Tests that passed before still pass.
  The new/modified test passes now too, it fails with the original code.

REPOSITORY
  R240 Extra CMake Modules

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

AFFECTED FILES
  modules/ECMQmLoader.cpp.in
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, #frameworks
Cc: #build_system

D8545: kio: fix handling of KCookieAdvice::AcceptForSession

[Wolfgang Bauer]

wbauer added a comment.


  Has this been forgotten?
  It should be committed by somebody, I think...
  
  FYI, we do have this patch in openSUSE for a while.
  https://bugzilla.opensuse.org/show_bug.cgi?id=1049975
  
  Also there is:
  https://bugs.kde.org/show_bug.cgi?id=374931

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

To: schwab, dfaure
Cc: wbauer, #frameworks

D7487: Make KCMultiDialog scrollable

[Wolfgang Bauer]

wbauer added a comment.


  The referenced bug number seems to be wrong.

REPOSITORY
  R295 KCMUtils

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

To: valeriymalov, #frameworks
Cc: wbauer, broulik

D7341: [KDesktopPropsPlugin] Create destination directory if it doesn't exist

[Wolfgang Bauer]

wbauer closed this revision.
wbauer added a comment.


  Committed with 
https://phabricator.kde.org/R241:a0fc624d50bbd7942834913ece52d26849ba7243
  
  (forgot to mention this review in the commit message, sorry)

REPOSITORY
  R241 KIO

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

To: wbauer, dfaure
Cc: #frameworks

D7341: [KDesktopPropsPlugin] Create destination directory if it doesn't exist

[Wolfgang Bauer]

wbauer added a commit: R241:a0fc624d50bb: [KDesktopPropsPlugin] Create 
destination directory if it doesn't exist.

REPOSITORY
  R241 KIO

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

To: wbauer, dfaure
Cc: #frameworks

D7341: [KDesktopPropsPlugin] Create destination directory if it doesn't exist

[Wolfgang Bauer]

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

REVISION SUMMARY
  If the directory doesn't exist, applying the changes will fail with "Could 
not save properties. You do not have sufficient access to write to xxx".

TEST PLAN
  Open the file associations dialog, select some file type and choose an 
associated application that has its .desktop file in a subfolder of 
/usr/share/applications/ (e.g. on openSUSE, all KDE4 applications install it to 
/usr/share/applications/kde4/). Make sure that the corresponding folder 
~/.local/share/applications/kde4/ doesn't exist.
  Click on "Edit...", change something on the "Program" tab (e.g. the command 
to execute), and click on "OK".
  
  The directory ~/.local/share/applications/kde4/ is created now and the 
changes are saved correctly.
  Before you got an error dialog and the changes were lost.

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/widgets/kpropertiesdialog.cpp

To: wbauer, dfaure
Cc: #frameworks

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:899519f0be03: Make ECMPoQmToolsTest actually fail if a 
translation is wrong (authored by wbauer).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6701?vs=16705=17422

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

AFFECTED FILES
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, skelly, apol
Cc: apol, #frameworks, #build_system

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Wolfgang Bauer]

wbauer added inline comments.

INLINE COMMENTS

> apol wrote in check.cmake.in:79
> It should also change the other `set(fail)` calls.
> 
> Or am I missing something?

The other `set(fail)` calls *are* at the top-level and not inside a function.
So, no, it doesn't make sense there.

The function only goes from line#69 to #84.

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, skelly
Cc: apol, #frameworks, #build_system

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Wolfgang Bauer]

wbauer updated this revision to Diff 16705.
wbauer added a comment.


  New diff with full context.

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6701?vs=16701=16705

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

AFFECTED FILES
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, skelly
Cc: #frameworks, #build_system

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Wolfgang Bauer]

wbauer added a comment.


  From the cmake documentation:
  
  > set( ... [PARENT_SCOPE])
  > 
  > Set the given  in the current function or directory scope.
  > 
  > If the ``PARENT_SCOPE`` option is given the variable will be set in
  >  the scope above the current scope.  Each new directory or function
  >  creates a new scope.  This command will set the value of a variable
  >  into the parent directory or calling function (whichever is applicable
  >  to the case at hand).

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, skelly
Cc: #frameworks, #build_system

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Wolfgang Bauer]

wbauer created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  Currently the test still passes even if one of the check_translations() calls 
fail.
  The reason is that check_translations() is a function which has its own 
scope, so if it sets "failed" the upper level doesn't see it.
  
  Use the PARENT_SCOPE option when setting the variable to properly propagate 
the value to the upper level.

TEST PLAN
  Make a change so that the test is expected to fail, e.g. modify an expected 
output in tests/ECMPoQmToolsTest/check.cmake.in.
  
  make test now will correctly mark the test as failed, before the test still 
passed.

REPOSITORY
  R240 Extra CMake Modules

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

AFFECTED FILES
  tests/ECMPoQmToolsTest/check.cmake.in

To: wbauer, skelly
Cc: #frameworks, #build_system

D6606: Support SVG too

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R313:ed5c039f2d19: Support SVG too (authored by wbauer).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D6606?vs=16448=16505#toc

REPOSITORY
  R313 KHtml

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6606?vs=16448=16505

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

AFFECTED FILES
  src/imload/decoders/qimageioloader.cpp

To: wbauer, dfaure
Cc: #frameworks

D6606: Support SVG too

[Wolfgang Bauer]

wbauer edited the summary of this revision.

REPOSITORY
  R313 KHtml

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

To: wbauer, dfaure
Cc: #frameworks

Re: Need HTML/CSS help for Konqueror's about page

[Wolfgang Bauer]

Am Montag, 10. Juli 2017, 11:11:39 schrieb David Faure:
> I'm porting the Konqueror about page from KHTML to WebEngine,

I suppose the reason is to fix the icons?

The problem in that case is that khtml doesn't support SVG, a quick fix would 
be this:
https://build.opensuse.org/package/view_file/home:wolfi323:test/khtml/add-SVG-support.patch?expand=1

I am about to submit this on phabricator...

But of course, porting to WebEngine would solve it too.

Kind Regards,
Wolfgang

D5502: Fix relativePath calculation in KDesktopFile::locateLocal()

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R237:3ad00c4e56eb: Fix relativePath calculation in 
KDesktopFile::locateLocal() (authored by wbauer).

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5502?vs=13778=13798

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

AFFECTED FILES
  autotests/kdesktopfiletest.cpp
  autotests/kdesktopfiletest.h
  src/core/kdesktopfile.cpp

To: wbauer, #frameworks, mdawson
Cc: mdawson, #frameworks

D5502: Fix relativePath calculation in KDesktopFile::locateLocal()

[Wolfgang Bauer]

wbauer updated this revision to Diff 13778.
wbauer added a comment.


  added more test cases as suggested

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5502?vs=13693=13778

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

AFFECTED FILES
  autotests/kdesktopfiletest.cpp
  autotests/kdesktopfiletest.h
  src/core/kdesktopfile.cpp

To: wbauer, #frameworks, mdawson
Cc: mdawson, #frameworks