- User Since
- Mar 5 2015, 12:44 PM (111 w, 2 d)
Tue, Apr 18
Mon, Apr 17
Sun, Apr 16
Would it help if QSaveFile had an API to set more restrictive permissions on the temp file?
Sat, Apr 15
OK then ;)
Isn't this missing a "set_package_properties .. TYPE OPTIONAL" so that the user is told about the optional deps they're missing?
Not sure if that works for KF5 components.
Seems consistent with the code further down, but I'm really puzzled because this code was the same in kdelibs4... Anyone with konqueror4 to test this? Otherwise I can do that in the office, 10 days from now.
Feel free to push after that last fix.
Fri, Apr 14
Mon, Apr 10
Sun, Apr 9
heaptrack shows that this actually makes things worse (same number of allocations, but on top of that it leads to more pre-allocated data in QString (note that the destination is empty, at least in parseAtom/parseToken - I just changed to '=' instead of "+=" to make that clearer).
Sat, Apr 8
If it's dead, it's dead.
Fri, Apr 7
Good point, I added a destructor to KIOD now, please try again ;)
Thu, Apr 6
Thanks. I don't agree that it was a small optimization, because regenerating a header file means recompiling all the files that include it, every single time. It's the job of a build system to make sure this doesn't happen, to save developer time ;)
Yes, that should be it. And for good practice, rather than hardcoding kded5 or kiod5 in the calling code, create a dbus .service file to autostart it (two purposes: making it independent from whoever is hosting the service, and starting kiod if it's not already running). See kio/src/kpasswdserver for an example.
Wed, Apr 5
5.33 is tagged since last saturday, you can push without waiting. It's always summer in master, for KF5.
Mon, Apr 3
Sun, Apr 2
Sat, Apr 1
Fri, Mar 31
Thu, Mar 30
Wed, Mar 29
Looks OK. It would be good to port this away from kdelibs4support though, to avoid propagating that dependency on users of the lib -- making it impossible to remove later.
At least it should be removed as a public dependency (in the target_link_libraries line and from KioArchiveConfig.cmake.in).
I don't know anything about this code, but if it's dead, it's dead.
Tue, Mar 28
Heh, of course. Simple fix ;) Thanks !
Yeah KF5Konq is a bug, it shouldn't be named that way.
Mon, Mar 27
The idea sounds OK to me.
So bin isn't in %PATH%, but found relatively to the app being run?
Yep it means parsing a file, but that file is exactly 2 lines long and this is only done when asking about trash:/ so I think it's fine.
Well I would accept a compromise, where dbus-started services get installed in bin on Unix as well.
Which means still only two install vars and dirs: bin and libexec. With consistency between Unix and Windows about whether a given executable gets installed into bin or libexec.
Sun, Mar 26
Ah, networkmanager-qt itself uses KDEFrameworkCompilerSettings so it gets -DQT_NO_SIGNALS_SLOTS_KEYWORDS, i.e. signals isn't defined.
But indeed this is an installed public header, so the fix is necessary for apps that don't use these settings.
The person who wrote this API doc was aiming for something slightly simpler (one less method to call), but my original design was for everyone to call setXMLFile, and it would make things a bit weird at the kxmlguiwindow level.
I'd rather we fix kfmclient.cpp to add the missing dash, but OK, if we care for command-line compatibility with KDE4 era then we should use ParseAsLongOptions.... everywhere...
If "findable by dbus services" is the only argument for polluting bin with libexec binaries on Windows, then it doesn't apply to *everything* in libexec, only to a handful of executables.
Seems right. The alternative is to make it work.
Not sure which solution is better.
Sat, Mar 25
Looks good to me. Just some minor things I noticed.
Fri, Mar 24
Mar 23 2017
Ah yes OK, the extraction on Linux is indeed not done in those Qt patches either. Nevermind ;)
The comment about ctime is still true ;-)
Feel like implementing it for Linux, too? ;-)
Mar 22 2017
Not right now, see kxmlgui/src/kshortcutseditoritem.cpp:54
m_actionNameInTable = i18nc([...] KLocalizedString::removeAcceleratorMarker(m_action->text()));
which is returned further down as DisplayRole for the Name column.
But you could easily add support for a custom property here ("descriptiveText") and document that, it would certainly be useful for all those actions whose text only makes sense in the context of the submenu they're in.
Oh, yeah, that sounds backwards.
createGUI(part) takes care of loading ui_standards.rc, see the bit of code I pointed to in my last comment.
This looks like ui_standards.rc isn't loaded.
Does this code call createGUI(part) anywhere? Do you get into KParts::MainWindow::createShellGUI(), and does it end up calling setXMLFile(KXMLGUIClient::standardsXmlFileLocation()); in kparts/src/mainwindow.cpp:168 ?