UI-less kdevplatform
Andreas Pakulat
apaku at gmx.de
Fri Aug 8 09:20:36 UTC 2008
On 08.08.08 09:55:18, Manuel Breugelmans wrote:
> On Thursday 07 August 2008 19:16:44 Andreas Pakulat wrote:
> > On 07.08.08 18:58:04, Alexander Dymo wrote:
> > > On Thursday 07 August 2008 18:23:46 Aleix wrote:
> > > > But anyway my idea was to leverage the more possible the shell when
> > > > working without UI.
> > > >
> > > > > I think the easiest way would be to just run the application without
> > > > > showing
> > > > > the mainwindow.
> > > >
> > > > Shouldn't this be the last chance?
> > >
> > > Maybe not. Let me elaborate. UiController doesn't give any guarantees for
> > > plugins (and shell) that the mainwindow exists.
> > > For example, IUiController::activeMainWindow() can return 0 and that's
> > > documented.
> > > So what we need to do is to keep using UiController that we have and
> > > simply do not create mainwindow. I haven't looked deep enough into the
> > > code to understand what can break but ideally nothing should break under
> > > this situation. So maybe your flag needs to be used in
> > > UiControllerPrivate constructor to avoid creating default main window?
> > >
> > > Other than that, UiController itself is quite cheap (it just initializes
> > > area and mainwindow). Area is cheap as well, so if we don't create
> > > mainwindow, we'll have fast enough cmdline shell.
> >
> > There's also the problem of dialogs, there are quite some plugins which
> > use dialogs. IMHO we should extend this, if we really go for a non-ui
> > mode, and provide a new property on plugins that says "I'm not using ui"
> > or "I'm using ui" and then if the shell is created without ui the
> > plugin-controller can make sure no ui-plugin is loaded.
> >
> > So language plugins and eventually also project builders would fall into
> > the no-ui-category and could be used, while everything else wouldn't.
>
> Uhm that's kind of the same thing as the original suggestion. You are adding
> edge case stuff to the 99.9% case (which is bad).
>
> If you really want a special shell the obvious route is to implement it,
> without touching the general one. Try to reuse as much as possible with
> #include "../shell/xcontroller.h" and implement the special ones, ie a
> pluginController and uiController. In this new plugin controller _you_ specify
> which ui-less plugins should be loaded, not the other way around. This
> requires all code to adhere strictly to the interfaces though ...
I'd still need the information in the .desktop files of the plugins
because I can't know all ui-less plugins that might exist when writing
that plugincontroller. Note that this "ui-less shell" part is not about
the specific problem that Aleix wants to solve, its something we might
want to do so we can run tests for example with the complete
infrastructure but without showing a mainwindow. Or have a
<your-language-here> script that does something with ui-less
kdevelop/quanta/whatever. So this is actually making our shell more
flexible.
Andreas
--
Reply hazy, ask again later.
More information about the KDevelop-devel
mailing list