because the process is connected to shortly after started but it may finish
before the connection is made and attempting to connect to it will result
in a crash
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
is used by the panel view to force-activated applet windows but since it is
done on mouse press the window should become active anyway (unless there is
something like focus stealing prevention getting in the way)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
also active and queued threads remain unchanged by the method, events
processing continues too (at a certain interval)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
this is only for popup applets, normal (Plasma::Applet-based) applets paint
everything and as such should handle status
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
editing the domain does not make sense, showing domain can be done via
comment (the complete URL is shown via comment by the KIO curl slave for
example)
note the change to KIO::AuthInfo, this invalidates stored data
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if the password store is open and KIO::SlaveBase::openPasswordDialog() is
called then the password from the cache is not valid
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because streaming a map of QVariants is not exactly optimal, members remain
undocumented but refer to KPasswordDialog flags and such anyway
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because KParts::ReadWritePart::closeUrl() is not called from the
KParts::ReadWritePart destructor (and even if it is bad stuff may happen)
for most rw parts (exception being okular which does its own query, maybe
some other parts too) saving was not actually done (e.g. for ark). now the
part will be queried to close, if the upload job fails (e.g. because of
insufficient access) the application/part will not close (intentionally)
tho and no error is reported via message box which is something that needs
to be looked into
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
any program launched with temporary file (as per the spec) argument
(because it does not support %u or %U) should not be responsible for
deleting the file, klauncher already handles that thus the option is
redundant. I don't know how other implemenatations (of program launchers)
do it but I cannot say I care either
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
it was done by kioexec which KRun was using but now everything that uses
KIO::NetAccess::download() benefits from better MIME type detection (e.g.
inkscape used to fail to detect the image format because the temporary file
was lacking extension)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
assuming 0 means success and anything else failure, unifdef for example
exits with exit code 1 if the output is different tho so there are
exceptions to it
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
