unfortunately redirection has to be done just for the sake of visual
pleasantry (so that the URL in the navigation bar matches the actual
address), if it was not for that then the whole redirect thing can be
avoided
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
after changes to multiple sub-projects (Katie, kdelibs, kde-workspace
and kde-extraapps) that finally happened, can write lots about it but I
will keep it short - by rewriting parts that were using js/qml (e.g. the
plasma applets) the desktop startup was reduced to half, also the legacy
tray thing shall be no more (anything that needs tray icon shall be a
plasma applet now) thus some applications and features will be dropped
aswell. see all repositories for the changes done
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
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>