Plugins depending on the standardoutputview with no Ui

[Andreas Pakulat]

On 23.03.11 16:27:01, Aleix Pol wrote:
> On Wed, Mar 23, 2011 at 11:42 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 23.03.11 11:18:18, Julian Bäume wrote:
> > > Am Mittwoch, 23. März 2011, 09:45:22 schrieb Andreas Pakulat:
> > > > PS: The KDevPlatform codebase has not been written with non-gui apps in
> > > > mind, hence you can always run into code-paths where suddenly ui is
> > > > needed. As the no-ui mode usually is used without KApplication or at
> > > > least without X11 connection, that means your app will crash at that
> > > > point.
> > >
> > > What’s the use for KDevelop::Core::NoUi then?
> >
> > To get kdevplatform loaded into an app that uses KApplication without X11
> > connection (or QCoreApplication+KComponentData as the tests do). That
> > however is a hack and you've to be rather careful what you do with the
> > kdevplatform libs as not all code-paths have been tested or examined for
> > necessity of this flag to disable certain things. In particular when errors
> > occur the code may still try to show message-boxes or what-not to the user.
> >
> > That flag is simply a hack to satisfy the needs of things like duchainify
> > and other similar tools that don't want a GUI app, but the more its being
> > used the more you increase the potential to run into cases as with the
> > original post in this thread.
> >
> > To really support non-gui apps the kdevplatform code needs to be split
> > into gui and non-gui libs. And similarly some of the plugins would need to
> > be split into two. Then non-gui apps can really make sure that no gui-code
> > is being run when they only use the non-gui parts of kdevplatform+plugins.
> 
> We still can have the application running just fine if we use KApplication,

Its not about KApplication or not, its about requiring an X11 connection
(or the equivalent on other platforms).

> I don't think such a redesign is needed. The shell knows if there's Ui or
> not, in plugins, we just have to believe if they say they use Ui or not.

That does not change the fact that it works purely by luck. Yes the
shell nowadays has a way to know this, but this was added 'later on' and
nobody inspected all the existing codepaths to verify wether they need
an exception for no-ui. This is just being added every time someone runs
into a crash in a non-gui app.

As for the plugins, there are actually plugins with gui-dependencies
that are marked no-ui, c++ comes to mind. Yes it usually/mostly works
because the current non-gui apps don't exercise the code-paths
triggering QWidget-related code.

Thats what a redesign would change, you could see and check for sure
wether a plugin uses GUI or not and you'd be sure that an app won't
crash because suddenly a QWidget is being created somewhere.

Anyway, thats unrealistic (I actually had started at some point, but
already gave up sorting out the mess in interfaces/) to happen, so
you'll have to work with what you can get.

Andreas