Plugins depending on the standardoutputview with no Ui

[Julian Bäume]

Am Mittwoch, 23. März 2011, 14:56:14 schrieb Andreas Pakulat:
> On 23.03.11 13:51:51, Julian Bäume wrote:
> > Am Mittwoch, 23. März 2011, 13:16:53 schrieb Dmitry Risenberg:
> > > 2011/3/23 Julian Bäume <julian at svg4all.de>:
> > > > No, the plugins just won’t load, when they need the GUI and you set
> > > > the NoUi flag.
> > > 
> > > The code itself is in kdevplatform (itemrepository.cpp), it does not
> > > need GUI, but it shows a messagebox in case of an error, which causes
> > > a crash when run from unit tests, so I think that checking for NoUi
> > > flag will fix it, won't it?
> > 
> > Ahh, now I understand. A runtime check for the flag in the plugins to
> > enable message boxes. IMHO and as I understand Andreas, all of this is a
> > hack. I think, it would be more desireable to remove GUI-related code
> > from the plugins, that don’t essentially need it. Warnings or error
> > messages could also be written to stdout or something, in case no GUI is
> > present. So error handling should not be done by the plugins themselves,
> > but somewhere else. In "GUI-mode" the program would show a message box
> > and in "test-mode" the test will fail (or even pass, if the error is
> > expected).
> 
> Thats no different than exposing the NoUi flag to plugins. A proper  fix
> would be splitting libraries and code into gui and non-gui parts and only
> gui parts would actually have code to handle errors. All the non-gui libs
> and plugins would merely have an error-return-code or some other way of
> transporting errors to their caller and the non-gui app would be
> responsible for handling those errors. So for example the vcs API would be
> extended to transport error-information from a vcs plugin back to the
> caller, the cvs plugin would be a no-ui plugin that just provides these
> error information. And in KDevelop there would be a cvs-gui plugin that
> executes these calls and shows the errors in an outputview.

Actually, that’s what I meant by 'the plugin should not handle the error'. The 
plugin should just "fail".

> But thats theory, there's no way this will become reality with the current
> codebase as its too big of a change (and there are too few tests to verify
> nothing breaks when doing it). This separation would've needed to happen 5
> years ago when we started the work on KDevelop4.

Yeah, I’m aware of that. I thought about ways to fix that, when this first 
occured to me a bit more than a year ago. But I gave up on this, because I 
realized, it was just too much work. After all, I’m (more or less) just a user 
of KDevPlatform.

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110323/133c0823/attachment.sig>