kuiserver future (to gui or not to gui)

[Ricard Marxer]

On Thursday 22 February 2007 10:47, David Faure wrote:
> On Thursday 22 February 2007, Rafael Fernández López wrote:
> > Hi all,
> >
> > I know plasma is being formed these days. Now that I will give some love
> > to kuiserver (and some other things) because I have free time again I
> > would like to know if my "future idea" for kuiserver is somehow good or
> > not.
> >
> > For better integration into the desktop, David suggested me to use a
> > QTimer for controlling when progresses dialog is shown or not. It can
> > work, for now. I think it could be interesting having the "kuiserver" as
> > a non-gui application, that is just running with a dbus interface.
> > Applications will communicate with this interface, that will store the
> > state of the different jobs (like right now, but with no KMainWindow).
> >
> > This way, we could write in the future a plasma plugin (plasmoid) that
> > makes calls and receives signals to/from the kuiserver itself. I think
> > this way we can integrate this even better into the desktop.
>
> Why should that be separated? The UI server is whatever UI is best for
> progress information. If/when plasma exists, kuiserver itself could become
> a plasma plugin, I don't see the need for an extra level of indirection and
> communication (app -> kuiserver -> plasmoid). Just let kuiserver be the
> plasmoid itself.

I see two reasons for this separation:

- in order to have several different job viewers running at the same time 
(e.g. a progress bar view, a timeline view or a view dedicated only to 
certain kind of jobs)

- to make publishing jobs independent of the GUI.  This way jobs without GUI 
can still publish jobs  (e.g formating a disk or compiling something)

Although I agree that maybe these cases are not worth the trouble.

ricard