removing showXXX

Hi,

I was about to implement showDiff() for Subversion and
already found it
cool to replace the current slot for the diff-context menu
with just a
call to showDiff. But then I found some
"questions":

a) how to show the widget
b) how's the lifespan of the job and the widget object
c) how to let the widget know about the job

Especially c) leads one directly to something like:

DiffWidget( VcsJob* job, QWidget* parent );

And when you're there, you don't actually need showDiff
anymore, because
it doesn't provide anything you can't do with the
kdevplatform-diffwidget and the normal diff() call. (I know
the
diffwidget doesn't exist yet).

Same problems arise for the other showXXX methods, namely
log, annotate,
change, ls and cat. For all of those we will have a widget
that can
display the result of the according VcsJob and thus the
"extra work" to
display the result instead of doing something with it is
practically
non-existent.

Also it removes some confusion from the API.

So are there any objections against removing the showXXX
methods, do I
overlook anything?

Andreas

-- 
Future looks spotty.  You will spill soup in late evening.

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

Andreas Pakulat wrote:
> I was about to implement showDiff() for Subversion and
already found it
> cool to replace the current slot for the diff-context
menu with just a
> call to showDiff. But then I found some
"questions":
> 
> a) how to show the widget
> b) how's the lifespan of the job and the widget object
> c) how to let the widget know about the job
> 
> Especially c) leads one directly to something like:
> 
> DiffWidget( VcsJob* job, QWidget* parent );
> 
> And when you're there, you don't actually need showDiff
anymore, because
> it doesn't provide anything you can't do with the
> kdevplatform-diffwidget and the normal diff() call. (I
know the
> diffwidget doesn't exist yet).
> 
> Same problems arise for the other showXXX methods,
namely log, annotate,
> change, ls and cat. For all of those we will have a
widget that can
> display the result of the according VcsJob and thus the
"extra work" to
> display the result instead of doing something with it
is practically
> non-existent.
> 
> Also it removes some confusion from the API.
> 
> So are there any objections against removing the
showXXX methods, do I
> overlook anything?

Remind me again what happened to commit() vs. showCommit()?

Otherwise, as long as the platform is able to handle
appropriate 
wrapping of what the VCS provides, this sounds good. (What
about 
overloads; is the plugin able to implement its own
DiffWidget if it 
needs to extend it for some reason? I guess this isn't
likely with diff 
widget, but maybe for change/log/annotate...)

-- 
Matthew
Me: wtf?? "#warning This is temporary since Dec
2000". Seven-year 
"temporary" code?
Mathieu Chouinard: Sounds like the correct definition of
temporary 


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

On 13.11.07 14:28:07, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > I was about to implement showDiff() for Subversion
and already found it
> > cool to replace the current slot for the
diff-context menu with just a
> > call to showDiff. But then I found some
"questions":
> > 
> > a) how to show the widget
> > b) how's the lifespan of the job and the widget
object
> > c) how to let the widget know about the job
> > 
> > Especially c) leads one directly to something
like:
> > 
> > DiffWidget( VcsJob* job, QWidget* parent );
> > 
> > And when you're there, you don't actually need
showDiff anymore, because
> > it doesn't provide anything you can't do with the
> > kdevplatform-diffwidget and the normal diff()
call. (I know the
> > diffwidget doesn't exist yet).
> > 
> > Same problems arise for the other showXXX methods,
namely log, annotate,
> > change, ls and cat. For all of those we will have
a widget that can
> > display the result of the according VcsJob and
thus the "extra work" to
> > display the result instead of doing something with
it is practically
> > non-existent.
> > 
> > Also it removes some confusion from the API.
> > 
> > So are there any objections against removing the
showXXX methods, do I
> > overlook anything?
> 
> Remind me again what happened to commit() vs.
showCommit()?

Doesn't exist (and IIRC never existed). We said at some
point that
showXXX would mean show the result in a GUI. IIRC we said
the interface
API should automatically ask for stuff thats missing via a
GUI.

> Otherwise, as long as the platform is able to handle
appropriate 
> wrapping of what the VCS provides, this sounds good.
(What about 
> overloads; is the plugin able to implement its own
DiffWidget if it 
> needs to extend it for some reason? I guess this isn't
likely with diff 
> widget, but maybe for change/log/annotate...)

A VCS plugin can surely implement its own logging,
annotation or
whatever output, but that wouldn't be available to users of
the API,
only available via QAction elements that the plugin provides
itself (via
context menu, toolbar/menu)

Andreas

-- 
It was all so different before everything changed.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Nov 13, 2007, at 11:33 AM, Andreas Pakulat wrote:

> Hi,
>
> I was about to implement showDiff() for Subversion and
already  
> found it
> cool to replace the current slot for the diff-context
menu with just a
> call to showDiff. But then I found some
"questions":
>
> a) how to show the widget
> b) how's the lifespan of the job and the widget object
> c) how to let the widget know about the job
>
> Especially c) leads one directly to something like:
>
> DiffWidget( VcsJob* job, QWidget* parent );
>
> And when you're there, you don't actually need showDiff
anymore,  
> because
> it doesn't provide anything you can't do with the
> kdevplatform-diffwidget and the normal diff() call. (I
know the
> diffwidget doesn't exist yet).
>
> Same problems arise for the other showXXX methods,
namely log,  
> annotate,
> change, ls and cat. For all of those we will have a
widget that can
> display the result of the according VcsJob and thus the
"extra  
> work" to
> display the result instead of doing something with it
is practically
> non-existent.
>
> Also it removes some confusion from the API.
>
> So are there any objections against removing the
showXXX methods, do I
> overlook anything?
>
> Andreas

YAY! Thanks! No objections from me.


I rule all, which means i automatically override everybody
else, so  
you should go ahead and do it. ;) (j/k)
- - - --
Matt


- - -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHOjIxA6Vv5rghv0cRAsuLAJ4jP2hsiY6ucn5ctwSza+wiowHSagCg
kBHx
kqXaUf6s2ruyQgPcfruTA04=
=050w
- - -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHOknUA6Vv5rghv0cRAuqCAKCkfC6JVUBuWno+wtHyXvlbqsMorQCf
VjEI
YBFyLMgI/5zsiPQQjqbjnoA=
=h+/Y
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHOkrEA6Vv5rghv0cRAn/jAJ91+B3ijS3YTix2eIqmijkxsI4HTgCd
GAxS
xCaFw4l0KDB/QCJPOV7UQR0=
=jcLe
-----END PGP SIGNATURE-----

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

On 13.11.07 19:09:24, Matt Rogers wrote:
> > So are there any objections against removing the
showXXX methods, do I
> > overlook anything?
> 
> YAY! Thanks! No objections from me.

lol, yeah sometimes it really needs an implementation to
find the wrong
parts in an API.

Andreas

-- 
There was a phone call for you.

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