silent_arg was used to fake startup notification for non-compliant
applications, that shall not be the case anymore - when applications do not
claim startup notification support or it is simply disabled for specific
use case (as is done by ark for its service actions) then there shall be no
startup notification, silent or otherwise
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KFileItem::isRegularFile() is a simple mode (member) check while
KFileItem::mostLocalUrl() does some dirty work
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
browser shall be determinted by the preferred service for "text/html",
"application/xhtml+xml" or any other MIME type for it (that includes
scheme handlers)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the idea for QImage/QPixmap-optimized widget occurred to me while
writing kimageviewer (see the kde-playground repo), unlike the widget I
wrote for kimageviewer this one supports drag-n-drop tho and is drop-in
replacement for QLabel when showing only a pixmap is required. the
widget also shows a small image while dragging ala ksnapshot
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
optional feature that requires "-tray" command line argument and replaces
what the `ksystraycmd` program was doing. requires "X-KDE-SysTray" entry
in the desktop file as indicator that the application supports "-tray"
argument, unlike `ksystraycmd` does not spawn extra process and even
session management will work properly for it (the argument is manually
added to the restart command)
the feature is very much tide to KMainWindow (and derived classes) but the
overhead is next to none when the "-tray" argument is not specified (the
status notifier is not created in such case) however if created an
expensive tooltip update is done whenever a window changes (may have to
look into optimizing it but then again - most of the code does nothing
unless the "-tray" argument is specified)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using properties defined in the spec (see
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html)
what KService::DBusUnique (or X-DBUS-ServiceName and X-DBUS-StartupType)
was used for can be implemented but the difference is now standard
properties can be filled (with values that are correct) and (ab)used for
the same purpose, bonus points?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
just another way to do what ASN does, the KService::DBusWait mode was
not used too. with this change however all of the process setup code is
moved to a seperate class and the responsibility of KLauncher about ASN
is reduced (ASN now works better for process that fork but if application
claims ASN support and does not send ASN finish then the timeout will be
reached)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
see the following commit in kde-workspace repo:
f1f6ae7a3ec35e289df1f45cd47e71bd3c696fbe
on a side note the default for StartupNotify should probably be false as it
is unknown if the application actually supports startup notification is one
of the reasons why currently KLauncher does more than merely set an
environment variable and assume applications know what to do with it
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
generally KRun does not start processes as detached process and as soon as
the process is launched and KRun::finished() is emitted KRun is deleted,
that however means that when the program that used KRun to launch
something exits the launched program will be terminated. while in most
cases that is not an issue (for services that have valid path for example)
for `kde-open` it is because its lifetime is short and the command to
execute is obtained via KProtocolInfo::exec() (QString, not KService)
so, to launch the scheme handlers as detached process (because the
programs that handle such may not fork) KRun has to use KToolInvocation
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
with the rewrite (see f452e2e50b),
KDateTime is just glue-code for compatibility now. the exception is
KDateTime::isNightTime() (written by me) which is used only in one place
(kde-workspace/plasma/dataengines/weather/ions/wetter.com/ion_wettercom.cpp)
and can be moved there
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
no interface to enable it and with KPasswdStore in place it is simply
redundant (other than the auto-login macros maybe)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
much like the old (and now gone) KLocale::prettyFormatDuration() except
with miliseconds precision instead of days
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using QLocale in KLocale and separating the date, time and numbers
conversion from translation KLocale actually gets extended locale
support from QLocale (which uses CLDR data v43 currently). translation
remains unaffected. for comparison here is the result of two function
calls the result of which should explain the whole change:
KLocale::allLanguagesList().size() = 669
KLocale::installedLanguages().size() = 68
the first number is locales Katie supports, the second being the
number of languages Katana is translated into
KSwitchLanguageDialog needs a rewrite but that is on the TODO
also copyrighting KCatalog to me because I rewrote it, for reference:
881b47b8ea
KCalendarSystem gets the middle finger - batteries not included for date
and time. extra calendar systems can, but are unlikely to be, supported
in the future
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KDateTime shall be used only for storing date and time while KLocale
shall be used to display such, not even going to test what KDateTime
does because it is basically a few methods on top of QDateTime now.
and because QDateTime knows not much about calendar systems while
KLocale supports several it makes sense for KDateTime to not be used for
displaying date and time thus the TODOs for KLocale are simply removed
note that KLocale still uses its own parser and formatter which means
that the change affects only KDateTime and its uses, not KLocale
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
UNIX being UNIX the leading dot meaning a file/directory is hidden is not
going anywhere, the private KFileItem hidden member is always set to
KFileItemPrivate::Auto too
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KFileItem::mimeTypePtr() is lesser version of
KFileItem::determineMimeType() and if KFileItem::determineMimeType() did
not return valid KMimeType::Ptr then neither will KFileItem::mimeTypePtr()
but calling KFileItem::::mimeTypePtr() after KFileItem::determineMimeType()
is redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the signal is actually not used, see the following commit in kde-workspace:
45bbcd5e5e963d029974e09fd66edc454e7e9dc4
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
way too much private and mutable KFileItem members, not used a lot so the
performance impact is next to none
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
first thing first - KFileMetaInfo does not support non-local files and
KFileItem is ment to be wrapper for both local and (most importantly)
remote (including virtual KIO) files. KIO::UDSEntry does not carry metadata
either so having a metadata getter and setter in KFileItem is simply
redundant, both are not tested and used only by plasma folderview applet
(see kde-workspace/plasma/applets/folderview/tooltipwidget.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
when it comes to KFileMetaInfo its bottleneck is determening what plugin to
use for the given URL/path - determening MIME type, matching globs, etc.
and it still is quite fast to the point where the flags are simply
redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
