assert in kservicetypefactory.cpp

[Boudewijn Rempt]

On Tue, 18 Aug 2015, David Faure wrote:

> On Tuesday 18 August 2015 10:45:00 Boudewijn Rempt wrote:
>> if (!bus->isServiceRegistered(KDED_SERVICE_NAME)) { evaluates to false
>
> I'm confused by the possible double negation. Do you mean isServiceRegistered returns true?

Er, I mean that the execution doesn't get into this if block.

> So it does see kded5 running on the current DBus session, right?

Yes.

> Oh. I think you found a real bug :-)
> Does this patch help?
>
> diff --git a/src/sycoca/ksycoca.cpp b/src/sycoca/ksycoca.cpp
> index 7c4c3da..c203484 100644
> --- a/src/sycoca/ksycoca.cpp
> +++ b/src/sycoca/ksycoca.cpp
> @@ -468,6 +468,7 @@ bool KSycocaPrivate::checkDatabase(BehaviorsIfNotFound ifNotFound)
>             }
>         } else {
>             //qCDebug(SYCOCA) << "kded5 found";
> +            kdedRunning = true;
>             if (QStandardPaths::isTestModeEnabled()) {
>                 QDBusInterface sycoca(KDED_SERVICE_NAME, KBUILDSYCOCA_PATH);
>                 const QDBusReply<bool> testMode = sycoca.call(QLatin1String("isTestModeEnabled"));
>
> The unittests have to work without kded, so they didn't catch this. Anyway I'm killing that kded
> dependency as soon as I find the time.

Hm, doesn't look like it...

>
>> I might be better off porting away from kio since I cannot ship something
>> that needs a running daemon or background process :-(
>
> Well if you cannot even accept a secondary process then indeed KIO won't be an option for you.
> But why such a strict requirement? This is no problem on Windows; is this about Android or iOS then?
>

As I've been telling people since the Desktop Summit in Berlin, it's a
huge problem on Windows and OSX.

Not so much if you're writing software that gets deployed by system
administrators inside companies, but if you make software for a mass
public, you cannot start secondary processes, like kded or a dbus daemon,
you cannot do IPC, you cannot rely on a separate application that creates
a configuration cache, you cannot rely on the install location being
stable...

If you're making an application for the masses, on Windows, you can have
only one exe that ideally contains all resources, or finds all resources
relative to itself, otherwise you're in for a deluge of bug reports.
On OSX, running anything as part of the installation procedure is
possible, but frowned upon, people want an app bundle in a dmg, and
that's it.

On Windows, if you start daemons, you get the problem that they will
stick around after the application closes, no matter what you, which
means people who try your application cannot uninstall it. Besides,
people who aren't tech savvy but think they are will check what's up 
the task manager and when they see daemons, they'll report bugs. They'll
install software like sandboxie or configure their "malware protection
services" so tightly that even local ipc through dbus will trigger
warnings. Which will trigger bug reports.

On OSX, dbus has always been a big problem, too. You just cannot ask
people to perform manual setup steps, which has always been needed. On
Windows, we've had a host of complaints about the 'black window'
the installer would show briefly to run kbuildsycoca4, when we still
needed that...

Bah, too verbose. To sum up:

A windows or osx application for the masses must:
* not have any pre or post install procedures
* not start any process except the application itself
* avoid ipc as much as possible
* find all resources and plugins relative to itself
* be portable (moving it around should not be a problem)

Boudewijn