UI-less kdevplatform

Aleix aleixpol at gmail.com
Sat Aug 9 23:44:34 UTC 2008


Ok, so i decided to split up the patch between the ::addProject thing (I'll
send another mail) and the uiless thing that here it is more or less the
same as the uiless2 but without some stupid bug and the ::addProject thing.

Thanks,
Aleix

On Fri, Aug 8, 2008 at 11:20 AM, Andreas Pakulat <apaku at gmx.de> wrote:

> 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.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080810/0626eb5b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uiless2.2_kdevplatform.patch
Type: text/x-patch
Size: 9120 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080810/0626eb5b/attachment.patch>


More information about the KDevelop-devel mailing list