Rework of the outputview interface

Hi,

as Matt suggested some time ago, I reworked the outputview
to more
closely follow the MVC pattern.

The outputview now has a much simpler interface, registering
a new view
with title, setting a model for that view and emitting a
signal whenever
an index in the view is activated.

Also this adds a really simple OutputModel for convience, it
just
provides 2 slots to connect to ProcessLineMaker or the new
ExecuteCommand class on top of a QStandardItemModel. This is
not meant
to get extended, unless we find that various
outputview-users do the
same thing in their custom models. Really just convenience
(thats also
why it lacks api docs, I will add these before commit of
course)

Last but not least there's the new ExecuteCommand class, it
provides
simplified signals on top of QProcess to make it easier to
execute
commands for the outputview. I've put it into util because
it can be
used for other things as well (if you only need the output
and
failed/completed signal). For more complex needs QProcess
(or the
proposed KProcess from Oswald) can be used.

2 things that are missing:

a) context menu access for the outputviews
b) removing a view (and letting the user clean up their
data)

I will do both tomorrow, adding a viewClosed() signal to
IOutputView and
checking where we need to implement customContextMenu().

Please review and post your comments. The first patch is for
the
platform, including porting svn plugin. The second patch is
for KDevelop
itself, I only ported the qmake builder as the make builder
is
relatively complex already and I don't have time today for
that. (first
patch is too large so I needed to compress it)

Andreas

-- 
You will have good luck and overcome many hardships.

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

2007/6/8, Andreas Pakulat <apakugmx.de>:
> Hi,
>
> as Matt suggested some time ago, I reworked the
outputview to more
> closely follow the MVC pattern.
>
> The outputview now has a much simpler interface,
registering a new view
> with title, setting a model for that view and emitting
a signal whenever
> an index in the view is activated.
>
> Also this adds a really simple OutputModel for
convience, it just
> provides 2 slots to connect to ProcessLineMaker or the
new
> ExecuteCommand class on top of a QStandardItemModel.
This is not meant
> to get extended, unless we find that various
outputview-users do the
> same thing in their custom models. Really just
convenience (thats also
> why it lacks api docs, I will add these before commit
of course)
>
> Last but not least there's the new ExecuteCommand
class, it provides
> simplified signals on top of QProcess to make it easier
to execute
> commands for the outputview. I've put it into util
because it can be
> used for other things as well (if you only need the
output and
> failed/completed signal). For more complex needs
QProcess (or the
> proposed KProcess from Oswald) can be used.

The outputview is good but I have some comments on
ExecuteCommand

Before reworking, the user just queued command and forgot
about process.
Then, the command runner automatically registered itself
into outputview,
and redirected/filtered outputs to outputview. But now,
after reworking,
the caller should manage both ExecCmd and outputview, an
unnecessary
burden -- he should capture the output from executer and add
to outputview
manually.

Rather, I suggest ExecuteCommand automatically register
itself to outputview
and redirect outputs to it. Without this, executeCommand is
not that very
useful IMHO -- because it is very thin wrapper and provides
no additional
featuers.

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

On Friday 08 June 2007 11:43, Andreas Pakulat wrote:
> Hi,
>
> as Matt suggested some time ago, I reworked the
outputview to more
> closely follow the MVC pattern.
>
> The outputview now has a much simpler interface,
registering a new view
> with title, setting a model for that view and emitting
a signal whenever
> an index in the view is activated.
>
> Also this adds a really simple OutputModel for
convience, it just
> provides 2 slots to connect to ProcessLineMaker or the
new
> ExecuteCommand class on top of a QStandardItemModel.
This is not meant
> to get extended, unless we find that various
outputview-users do the
> same thing in their custom models. Really just
convenience (thats also
> why it lacks api docs, I will add these before commit
of course)
>
> Last but not least there's the new ExecuteCommand
class, it provides
> simplified signals on top of QProcess to make it easier
to execute
> commands for the outputview. I've put it into util
because it can be
> used for other things as well (if you only need the
output and
> failed/completed signal). For more complex needs
QProcess (or the
> proposed KProcess from Oswald) can be used.
>
> 2 things that are missing:
>
> a) context menu access for the outputviews
> b) removing a view (and letting the user clean up their
data)
>
> I will do both tomorrow, adding a viewClosed() signal
to IOutputView and
> checking where we need to implement
customContextMenu().
>
> Please review and post your comments. The first patch
is for the
> platform, including porting svn plugin. The second
patch is for KDevelop
> itself, I only ported the qmake builder as the make
builder is
> relatively complex already and I don't have time today
for that. (first
> patch is too large so I needed to compress it)
>
> Andreas

Comments:

Instead of ExecuteCommand for the class name, use
CommandExecutor instead.

Looks fine otherwise.
-- 
Matt

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

On 09.06.07 08:47:19, Matt Rogers wrote:
> On Friday 08 June 2007 11:43, Andreas Pakulat wrote:
> > Hi,
> >
> > as Matt suggested some time ago, I reworked the
outputview to more
> > closely follow the MVC pattern.
> >
> > The outputview now has a much simpler interface,
registering a new view
> > with title, setting a model for that view and
emitting a signal whenever
> > an index in the view is activated.
> >
> > Also this adds a really simple OutputModel for
convience, it just
> > provides 2 slots to connect to ProcessLineMaker or
the new
> > ExecuteCommand class on top of a
QStandardItemModel. This is not meant
> > to get extended, unless we find that various
outputview-users do the
> > same thing in their custom models. Really just
convenience (thats also
> > why it lacks api docs, I will add these before
commit of course)
> >
> > Last but not least there's the new ExecuteCommand
class, it provides
> > simplified signals on top of QProcess to make it
easier to execute
> > commands for the outputview. I've put it into util
because it can be
> > used for other things as well (if you only need
the output and
> > failed/completed signal). For more complex needs
QProcess (or the
> > proposed KProcess from Oswald) can be used.
> >
> > 2 things that are missing:
> >
> > a) context menu access for the outputviews
> > b) removing a view (and letting the user clean up
their data)
> >
> > I will do both tomorrow, adding a viewClosed()
signal to IOutputView and
> > checking where we need to implement
customContextMenu().
> >
> > Please review and post your comments. The first
patch is for the
> > platform, including porting svn plugin. The second
patch is for KDevelop
> > itself, I only ported the qmake builder as the
make builder is
> > relatively complex already and I don't have time
today for that. (first
> > patch is too large so I needed to compress it)
> >
> > Andreas
> 
> Comments:
> 
> Instead of ExecuteCommand for the class name, use
CommandExecutor instead.

Ok, I don't care that much for the name 

> Looks fine otherwise.

Cool.

Andreas

-- 
You are as I am with You.

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

On 09.06.07 09:28:20, dukju ahn wrote:
> 2007/6/8, Andreas Pakulat <apakugmx.de>:
> > Hi,
> >
> > as Matt suggested some time ago, I reworked the
outputview to more
> > closely follow the MVC pattern.
> >
> > The outputview now has a much simpler interface,
registering a new view
> > with title, setting a model for that view and
emitting a signal whenever
> > an index in the view is activated.
> >
> > Also this adds a really simple OutputModel for
convience, it just
> > provides 2 slots to connect to ProcessLineMaker or
the new
> > ExecuteCommand class on top of a
QStandardItemModel. This is not meant
> > to get extended, unless we find that various
outputview-users do the
> > same thing in their custom models. Really just
convenience (thats also
> > why it lacks api docs, I will add these before
commit of course)
> >
> > Last but not least there's the new ExecuteCommand
class, it provides
> > simplified signals on top of QProcess to make it
easier to execute
> > commands for the outputview. I've put it into util
because it can be
> > used for other things as well (if you only need
the output and
> > failed/completed signal). For more complex needs
QProcess (or the
> > proposed KProcess from Oswald) can be used.
> 
> The outputview is good but I have some comments on
ExecuteCommand
> 
> Before reworking, the user just queued command and
forgot about process.
> Then, the command runner automatically registered
itself into outputview,
> and redirected/filtered outputs to outputview. But now,
after reworking,
> the caller should manage both ExecCmd and outputview,
an unnecessary
> burden -- he should capture the output from executer
and add to outputview
> manually.

ExecuteCommand has nothing to do with the outputview.

> Rather, I suggest ExecuteCommand automatically register
itself to outputview
> and redirect outputs to it. Without this,
executeCommand is not that very
> useful IMHO -- because it is very thin wrapper and
provides no additional
> featuers.
 
It is useful if you don't need all that extra stuff that
QProcess
provides, for example you don't need to know what the
exitcode of a
process is, just wether it suceeded or failed. The same
thing for
reading its output, ExecuteCommand simplifies this.

And as I said ExecuteCommand has nothing to do with
outputview, its just
a simplifying wrapper around QProcess (and it may get some
more features
wrt. environment setting, if KProcess doesn't provide that).
Registering
a view in the outputview and providing a model that does
highlighting
and such things is up to the plugin that wants to present
something in
the outputview.

Andreas

-- 
Try to get all of your posthumous medals in advance.

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

2007/6/9, Andreas Pakulat <apakugmx.de>:
> On 09.06.07 09:28:20, dukju ahn wrote:
> > The outputview is good but I have some comments on
ExecuteCommand
> >
> > Before reworking, the user just queued command and
forgot about process.
> > Then, the command runner automatically registered
itself into outputview,
> > and redirected/filtered outputs to outputview. But
now, after reworking,
> > the caller should manage both ExecCmd and
outputview, an unnecessary
> > burden -- he should capture the output from
executer and add to outputview
> > manually.
>
> ExecuteCommand has nothing to do with the outputview.
>
> > Rather, I suggest ExecuteCommand automatically
register itself to outputview
> > and redirect outputs to it. Without this,
executeCommand is not that very
> > useful IMHO -- because it is very thin wrapper and
provides no additional
> > featuers.
>
> It is useful if you don't need all that extra stuff
that QProcess
> provides, for example you don't need to know what the
exitcode of a
> process is, just wether it suceeded or failed. The same
thing for
> reading its output, ExecuteCommand simplifies this.
>
> And as I said ExecuteCommand has nothing to do with
outputview, its just
> a simplifying wrapper around QProcess (and it may get
some more features
> wrt. environment setting, if KProcess doesn't provide
that). Registering
> a view in the outputview and providing a model that
does highlighting
> and such things is up to the plugin that wants to
present something in
> the outputview.

Then, how about having such convenient  class? It's not an
ExcuteCommand.
Why each plugin should do all that same jobs to run a simple
program and
redirect output to outputview? In the plugins' viewpoint,
running process
is now more harder than before. After all, we lost the
existing feature.

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

On 09.06.07 10:19:35, dukju ahn wrote:
> 2007/6/9, Andreas Pakulat <apakugmx.de>:
> > On 09.06.07 09:28:20, dukju ahn wrote:
> > > The outputview is good but I have some
comments on ExecuteCommand
> > >
> > > Before reworking, the user just queued
command and forgot about process.
> > > Then, the command runner automatically
registered itself into outputview,
> > > and redirected/filtered outputs to
outputview. But now, after reworking,
> > > the caller should manage both ExecCmd and
outputview, an unnecessary
> > > burden -- he should capture the output from
executer and add to outputview
> > > manually.
> >
> > ExecuteCommand has nothing to do with the
outputview.
> >
> > > Rather, I suggest ExecuteCommand
automatically register itself to outputview
> > > and redirect outputs to it. Without this,
executeCommand is not that very
> > > useful IMHO -- because it is very thin
wrapper and provides no additional
> > > featuers.
> >
> > It is useful if you don't need all that extra
stuff that QProcess
> > provides, for example you don't need to know what
the exitcode of a
> > process is, just wether it suceeded or failed. The
same thing for
> > reading its output, ExecuteCommand simplifies
this.
> >
> > And as I said ExecuteCommand has nothing to do
with outputview, its just
> > a simplifying wrapper around QProcess (and it may
get some more features
> > wrt. environment setting, if KProcess doesn't
provide that). Registering
> > a view in the outputview and providing a model
that does highlighting
> > and such things is up to the plugin that wants to
present something in
> > the outputview.
> 
> Then, how about having such convenient  class? It's not
an ExcuteCommand.
> Why each plugin should do all that same jobs to run a
simple program and
> redirect output to outputview? In the plugins'
viewpoint, running process
> is now more harder than before. After all, we lost the
existing feature.

We didn't loose any feature, but we gained more control for
the plugins.
Its now easier for a plugin to provide custom highlighting,
font-attributes and even icons for the output. Its also
easier for the
plugin to decide wether it wants to open a new outputview or
just clear
an existing one, that wasn't easily possible before.

Its still relatively easy to provide a simple outputview,
see the svn
plugin (which I ported already). The QMake Builder is more
complex
because it needs to generate a separate process for each
build and later
on remove them again.

Now IOutputView really is what its name suggests: A View.

Andreas

-- 
Break into jail and claim police brutality.

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

> > > > Before reworking, the user just queued
command and forgot about process.
> > > > Then, the command runner automatically
registered itself into outputview,
> > > > and redirected/filtered outputs to
outputview. But now, after reworking,
> > > > the caller should manage both ExecCmd
and outputview, an unnecessary
> > > > burden -- he should capture the output
from executer and add to outputview
> > > > manually.
> > >
> > > ExecuteCommand has nothing to do with the
outputview.
> > >
> > > > Rather, I suggest ExecuteCommand
automatically register itself to outputview
> > > > and redirect outputs to it. Without
this, executeCommand is not that very
> > > > useful IMHO -- because it is very thin
wrapper and provides no additional
> > > > featuers.
> > >
> > > It is useful if you don't need all that extra
stuff that QProcess
> > > provides, for example you don't need to know
what the exitcode of a
> > > process is, just wether it suceeded or
failed. The same thing for
> > > reading its output, ExecuteCommand simplifies
this.
> > >
> > > And as I said ExecuteCommand has nothing to
do with outputview, its just
> > > a simplifying wrapper around QProcess (and it
may get some more features
> > > wrt. environment setting, if KProcess doesn't
provide that). Registering
> > > a view in the outputview and providing a
model that does highlighting
> > > and such things is up to the plugin that
wants to present something in
> > > the outputview.
> >
> > Then, how about having such convenient  class?
It's not an ExcuteCommand.
> > Why each plugin should do all that same jobs to
run a simple program and
> > redirect output to outputview? In the plugins'
viewpoint, running process
> > is now more harder than before. After all, we lost
the existing feature.
>
> We didn't loose any feature, but we gained more control
for the plugins.
> Its now easier for a plugin to provide custom
highlighting,
> font-attributes and even icons for the output. Its also
easier for the
> plugin to decide wether it wants to open a new
outputview or just clear
> an existing one, that wasn't easily possible before.
>
> Its still relatively easy to provide a simple
outputview, see the svn
> plugin (which I ported already). The QMake Builder is
more complex
> because it needs to generate a separate process for
each build and later
> on remove them again.

The lost feature I mentioned is about running a process and
forgetting  it.
I agreed that plugin gained more control on view. I said
that view is good.
The key of my argument was this -- some (utility) class
which
automatically registers itself to outputview and redirect
outputs to it.

I'm just suggesting one additional class.

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

On 09.06.07 12:33:31, dukju ahn wrote:
> > Its still relatively easy to provide a simple
outputview, see the svn
> > plugin (which I ported already). The QMake Builder
is more complex
> > because it needs to generate a separate process
for each build and later
> > on remove them again.
> 
> The lost feature I mentioned is about running a process
and forgetting  it.

Uhm, right, the owner of the "process class" is
moved from the
outputview to the plugin. But I don't see that as a
problem.

> I agreed that plugin gained more control on view. I
said that view is good.
> The key of my argument was this -- some (utility) class
which
> automatically registers itself to outputview and
redirect outputs to it.
>
> I'm just suggesting one additional class.

Well, I don't see the need. Its IMHO not enough
functionality this class
would have to justify it. All you need to do for the hookup
is connect
2-4 signals and 2 calls to the outputview.

Andreas

-- 
If you stand on your head, you will get footprints in your
hair.

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

2007/6/9, Andreas Pakulat <apakugmx.de>:
> On 09.06.07 12:33:31, dukju ahn wrote:
> > > Its still relatively easy to provide a simple
outputview, see the svn
> > > plugin (which I ported already). The QMake
Builder is more complex
> > > because it needs to generate a separate
process for each build and later
> > > on remove them again.
> >
> > The lost feature I mentioned is about running a
process and forgetting  it.
>
> Uhm, right, the owner of the "process class"
is moved from the
> outputview to the plugin. But I don't see that as a
problem.
>
> > I agreed that plugin gained more control on view.
I said that view is good.
> > The key of my argument was this -- some (utility)
class which
> > automatically registers itself to outputview and
redirect outputs to it.
> >
> > I'm just suggesting one additional class.
>
> Well, I don't see the need. Its IMHO not enough
functionality this class
> would have to justify it. All you need to do for the
hookup is connect
> 2-4 signals and 2 calls to the outputview.

Then, ok. I'm convinced. Additions can be made at anytime.
If we
really feels that
such class is really necessary, we can just add it later.
Not now.

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