Review of output view interface

Hi,

I took some time and reviewed the output view interface.

General Questions and comments:

- Why are we still using K3Process? What's wrong with
QProcess that makes it 
impossible for us to use it instead? At this point in time,
I couldn't care 
less about what other breakages switching away from
K3Process will cause. If 
QProcess fits our needs (and I don't see how it wouldn't) we
need to make the 
switch.

- Outputviews should only be a display mechanism. We need to
come up with 
something different to use to run external processes and
capture the output.

IOutputView:

- Remove the reference to a new tab in the API docs for the
queueCommand 
function. The view doesn't necessarily have to be created
within a tab. Tabs 
are an implementation detail of the view plugin.

- Remove queueCommand. See above.

- The documentation is a bit parse. Function parameters
should be documented.

-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.05.07 20:41:32, Matt Rogers wrote:
> I took some time and reviewed the output view
interface.

Thanks for doing that.

> General Questions and comments:
> 
> - Why are we still using K3Process?

See my recent mails on the commit list, last time I tested
a
QProcess/Qt4 application wasn't debuggable in KDevelop3.4. I
just
retried and now it works (wether QProcess/Qt4 changed or
KProcess/KDE3
or it was something else earlier I don't know). I just asked
whats
better to use on k-c-d, because at some point K3Process
might be deleted
and brought back as KProcess derived from QProcess.
Currently the only
real reason I see to use KProcess then is to be able to add
command and
arguments using the << operator.

Unless I see a mail stating otherwise I'm going to port to
QProcess
(including proclinemaker) tomorrow evening.

> - Outputviews should only be a display mechanism. We
need to come up with 
> something different to use to run external processes
and capture the output.
>
> IOutputView:
> 
> - Remove the reference to a new tab in the API docs for
the queueCommand 
> function. The view doesn't necessarily have to be
created within a tab. Tabs 
> are an implementation detail of the view plugin.
> 
> - Remove queueCommand. See above.

I'll see if I can come up with an interface or class for
that tomorrow.
Now its really too late ;)

In that case I guess IOutputView would just allow to create
a view using
a model, a title and possibly and id. Right? Or do you want
to have a
model for all outputviews together?

Andreas

-- 
You will be surprised by a loud noise.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 27 May 2007 21:00, Andreas Pakulat wrote:
> On 27.05.07 20:41:32, Matt Rogers wrote:
> > I took some time and reviewed the output view
interface.
>
> Thanks for doing that.
>
> > General Questions and comments:
> >
> > - Why are we still using K3Process?
>
> See my recent mails on the commit list, last time I
tested a
> QProcess/Qt4 application wasn't debuggable in
KDevelop3.4. I just
> retried and now it works (wether QProcess/Qt4 changed
or KProcess/KDE3
> or it was something else earlier I don't know). I just
asked whats
> better to use on k-c-d, because at some point K3Process
might be deleted
> and brought back as KProcess derived from QProcess.
Currently the only
> real reason I see to use KProcess then is to be able to
add command and
> arguments using the << operator.
>
> Unless I see a mail stating otherwise I'm going to port
to QProcess
> (including proclinemaker) tomorrow evening.
>

Awesome. I'm glad it's working now. No objections from me on
porting to 
QProcess.  I have other questions about proclinemaker, see
below.

> > - Outputviews should only be a display mechanism.
We need to come up with
> > something different to use to run external
processes and capture the
> > output.
> >
> > IOutputView:
> >
> > - Remove the reference to a new tab in the API
docs for the queueCommand
> > function. The view doesn't necessarily have to be
created within a tab.
> > Tabs are an implementation detail of the view
plugin.
> >
> > - Remove queueCommand. See above.
>
> I'll see if I can come up with an interface or class
for that tomorrow.
> Now its really too late ;)
>
> In that case I guess IOutputView would just allow to
create a view using
> a model, a title and possibly and id. Right? Or do you
want to have a
> model for all outputviews together?
>

Right, a model, a title, and possibly and id is all that I
would see us 
needing. 

My idea for the output view functionality was that a plugin
would provide a 
model that contains the data for the view to display. We
would have another 
interface that would provide the process execution
functionality and the 
ability to capture the output. ATM, I think we should
capture stdout and 
stderr separately, but I'm not totally convinced that's the
way to go. Then 
the plugin responsible for providing the model to the view
would also do some 
filtering on it, if needed before passing it to the view.
Maybe we have the 
ability to provide a custom view too. 

I'm a bit confused about ProcLineMaker. What exactly does it
do, and will we 
need it once we refactor the output view stuff a bit?
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.05.07 21:18:00, Matt Rogers wrote:
> On Sunday 27 May 2007 21:00, Andreas Pakulat wrote:
> > On 27.05.07 20:41:32, Matt Rogers wrote:
> > > - Outputviews should only be a display
mechanism. We need to come up with
> > > something different to use to run external
processes and capture the
> > > output.
> > >
> > > IOutputView:
> > >
> > > - Remove the reference to a new tab in the
API docs for the queueCommand
> > > function. The view doesn't necessarily have
to be created within a tab.
> > > Tabs are an implementation detail of the view
plugin.
> > >
> > > - Remove queueCommand. See above.
> >
> > I'll see if I can come up with an interface or
class for that tomorrow.
> > Now its really too late ;)
> >
> > In that case I guess IOutputView would just allow
to create a view using
> > a model, a title and possibly and id. Right? Or do
you want to have a
> > model for all outputviews together?
> >
> 
> Right, a model, a title, and possibly and id is all
that I would see us 
> needing. 
> 
> My idea for the output view functionality was that a
plugin would provide a 
> model that contains the data for the view to display.
We would have another 
> interface that would provide the process execution
functionality and the 
> ability to capture the output. ATM, I think we should
capture stdout and 
> stderr separately, but I'm not totally convinced that's
the way to go. Then 
> the plugin responsible for providing the model to the
view would also do some 
> filtering on it, if needed before passing it to the
view. Maybe we have the 
> ability to provide a custom view too. 

Well, I had another thought or two just before sleeping
yesterday. Not
everything is "finished" here, but how about a
special model class that
has an additional method or slot for activating an item (or
provide a
selectionmodel for that??) so the plugin can give iouputview
a model and
the view can connect the activated signal to the slot of the
model. That
way we don't need a custom view for just providing some
extra
functionality (doing something when highlighted lines are
clicked) that
is re-created by each plugin. I'm just not sure wether we
should
subclass QAbstractItemModel or QStandardItemModel for our
custom model.
We can of course also just emit a signal from the outputview
each time
an index in a model is clicked, with a signature like this:

activated(const QModelIndex& index, const QString&
id);

And the plugin can connect itself to that and do whatever it
wants if
its an id it knows about and the index is valid.

Last thing: For executing I think a somewhat extended
ProcLineMaker
should be fine. I don't think we need much filtering there,
I think its
rather treating certain lines specially. At least I can't
see filtering
or sorting in the way of QSortFilterProxyModel to be done
here.

> I'm a bit confused about ProcLineMaker. What exactly
does it do, and will we 
> need it once we refactor the output view stuff a bit?

ProcLineMaker emits the lines as stringlist, but it doesn't
emit all
lines if the last line doesn't contain a n. It emits such
unfinished
lines only if the other outputchannel gets some output. So
for example
if the process ouputs these two strings:

stdout:
"Compiling foo.c
gcc -o foo.o foo.c"
stderr:
"Warning: missing newline character at end of file
"

Then you'd first get a signal with "Compiling
foo.c", after that the
stderr output is signalled to proclinemaker and it outputs
the rest of
the stdout output so you'd get 2 signals, one with the rest
of stdout
and another one with the warning right after that.

Andreas

-- 
Don't read everything you believe.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/5/28, Andreas Pakulat <apakugmx.de>:
> On 27.05.07 21:18:00, Matt Rogers wrote:
> > On Sunday 27 May 2007 21:00, Andreas Pakulat
wrote:
> > > On 27.05.07 20:41:32, Matt Rogers wrote:
> > > > - Outputviews should only be a display
mechanism. We need to come up with
> > > > something different to use to run
external processes and capture the
> > > > output.
> > > >
> > > > IOutputView:
> > > >
> > > > - Remove the reference to a new tab in
the API docs for the queueCommand
> > > > function. The view doesn't necessarily
have to be created within a tab.
> > > > Tabs are an implementation detail of the
view plugin.
> > > >
> > > > - Remove queueCommand. See above.
> > >
> > > I'll see if I can come up with an interface
or class for that tomorrow.
> > > Now its really too late ;)
> > >
> > > In that case I guess IOutputView would just
allow to create a view using
> > > a model, a title and possibly and id. Right?
Or do you want to have a
> > > model for all outputviews together?
> > >
> >
> > Right, a model, a title, and possibly and id is
all that I would see us
> > needing.
> >
> > My idea for the output view functionality was that
a plugin would provide a
> > model that contains the data for the view to
display. We would have another
> > interface that would provide the process execution
functionality and the
> > ability to capture the output. ATM, I think we
should capture stdout and
> > stderr separately, but I'm not totally convinced
that's the way to go. Then
> > the plugin responsible for providing the model to
the view would also do some
> > filtering on it, if needed before passing it to
the view. Maybe we have the
> > ability to provide a custom view too.
>
> Well, I had another thought or two just before sleeping
yesterday. Not
> everything is "finished" here, but how about
a special model class that
> has an additional method or slot for activating an item
(or provide a
> selectionmodel for that??) so the plugin can give
iouputview a model and
> the view can connect the activated signal to the slot
of the model. That
> way we don't need a custom view for just providing some
extra
> functionality (doing something when highlighted lines
are clicked) that
> is re-created by each plugin. I'm just not sure wether
we should
> subclass QAbstractItemModel or QStandardItemModel for
our custom model.
> We can of course also just emit a signal from the
outputview each time
> an index in a model is clicked, with a signature like
this:
>
> activated(const QModelIndex& index, const
QString& id);
>
> And the plugin can connect itself to that and do
whatever it wants if
> its an id it knows about and the index is valid.

I doubt the idea that each plugin provides their model.
Just providing model isn't sufficient to display custom
contents.
Think about the
case when some plugin needs special view, say
"CircularView",

Most importantly
I think OutputView doesn't need to be that flexible. After
all, outputview is
small utility class to display simple string output. If some
plugin needs
complex and flexible unique output, it may want to treat it
themselves, rather
than using outputview.

Most of the plugins may don't want to create and manage the
custom model
just to print out simple strings or clickable items. That's
the reason
of existance
of OutputView. If things get complicated, plugins will do
their own.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 06.06.07 13:47:46, dukju ahn wrote:
> 2007/5/28, Andreas Pakulat <apakugmx.de>:
> > And the plugin can connect itself to that and do
whatever it wants if
> > its an id it knows about and the index is valid.
> 
> I doubt the idea that each plugin provides their
model.

Not each, just each plugin that wants to output some
information like a
log or similar.

> Just providing model isn't sufficient to display custom
contents.
> Think about the
> case when some plugin needs special view, say
"CircularView",

Use case please? We're talking about output view here, that
is a view
that shows the output of a certain action or program. I
don't see how a
circular view could be usable for this.

> Most importantly
> I think OutputView doesn't need to be that flexible.
After all, outputview is
> small utility class to display simple string output. If
some plugin needs
> complex and flexible unique output, it may want to
treat it themselves, rather
> than using outputview.

Its not "just" a utility class, it provides GUI
features on top of the
output of process or "action". I think the
model/view approach lets us
unify the two things in the outputview. Currently I think
the model is
enough, maybe a delegate will be needed later on to provide
custom
drawing, but I don't see that atm.

> Most of the plugins may don't want to create and manage
the custom model
> just to print out simple strings or clickable items.

Thats easily done: use qstandarditemmodel and connect to the
signals
that the outputview will emit (I'm thinking about
replicating the
QItemSelectionModel interface to a certain extent on the
outputview
interface)

> That's the reason of existance of OutputView. If things
get
> complicated, plugins will do their own.

Why? It gets confusing if you have half a dozen different
dockwidgets
that provide some output-like information.

Andreas

-- 
You have an unusual understanding of the problems of human
relationships.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel