Clarification on a VCS-Iface Issue

Hi,

to those of you that were involved in the Vcs-Iface Design
decisions
(and all others as well of course :

Did we decide that the actions like commit, add, copy, move
(the
non-Show-versions) have to work without _any_ gui at all, or
are they
allowed to popup dialogs when they need input like
authentication
information, or say a commit message (as import for example
misses a
commit message argument)?

I'm not sure wether we discussed this at all and having had
a look at
the svn plugin its clear that we need a decision. I don't
think it makes
sense to restrict these actions to non-gui-mode, as then
they'd have to
fail and they can't be executed without some sort of GUI
running anyway.

If we decide this I'll put a clear doc about the difference
between
showwXXX and XXX into the api docs. Currently I'm leaning
towards
something along the lines (assuming we allow gui from XXX
methods):

showXXX - allows the user to input the parameters for the
action to be
executed, always shows this GUI

XXX - tries to execute the action without user-interaction,
but will
create a dialog if needed for input of missing information

Andreas

-- 
Never give an inch!

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

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


On Sep 3, 2007, at 6:24 PM, Andreas Pakulat wrote:

> Hi,
>
> to those of you that were involved in the Vcs-Iface
Design decisions
> (and all others as well of course :
>
> Did we decide that the actions like commit, add, copy,
move (the
> non-Show-versions) have to work without _any_ gui at
all, or are they
> allowed to popup dialogs when they need input like
authentication
> information, or say a commit message (as import for
example misses a
> commit message argument)?
>
> I'm not sure wether we discussed this at all and having
had a look at
> the svn plugin its clear that we need a decision. I
don't think it  
> makes
> sense to restrict these actions to non-gui-mode, as
then they'd  
> have to
> fail and they can't be executed without some sort of
GUI running  
> anyway.
>
> If we decide this I'll put a clear doc about the
difference between
> showwXXX and XXX into the api docs. Currently I'm
leaning towards
> something along the lines (assuming we allow gui from
XXX methods):
>
> showXXX - allows the user to input the parameters for
the action to be
> executed, always shows this GUI
>
> XXX - tries to execute the action without
user-interaction, but will
> create a dialog if needed for input of missing
information
>
> Andreas

This is where I dislike having two different sets of API
that perform  
the same thing. It was said that this is for scriptability.
However,  
doesn't a platform app have to be running to be able to run
scripts  
anyways. Why can't we just normalize it so that it does what
you  
suggest in the XXX case and remove the showXXX versions of
the same  
functions?
- --
Matt


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

iD8DBQFG3Mg7A6Vv5rghv0cRArteAJ940zJbiYh6aArJlQm44CvXQ0Ac/QCg
sZhq
7E2WMh8BzJPaFqq4lApXKZA=
=P44Y
-----END PGP SIGNATURE-----

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

Andreas Pakulat wrote:
> Did we decide that the actions like commit, add, copy,
move (the
> non-Show-versions) have to work without _any_ gui at
all, or are they
> allowed to popup dialogs when they need input like
authentication
> information, or say a commit message (as import for
example misses a
> commit message argument)?
> [snip]
> If we decide this I'll put a clear doc about the
difference between
> showwXXX and XXX into the api docs. Currently I'm
leaning towards
> something along the lines (assuming we allow gui from
XXX methods):
> 
> showXXX - allows the user to input the parameters for
the action to be
> executed, always shows this GUI
> 
> XXX - tries to execute the action without
user-interaction, but will
> create a dialog if needed for input of missing
information

What I recall the difference being is:

showCommit(<files>, "Look, Ma! A commit")
pops up a dialog asking for a 
commit message; the message is initialized to "Look,
Ma! A commit" but 
can be changed.

commit(<files>, "Automated commit") attempts
to commit without showing a 
dialog.

IMO authentication is always allowed, although it would be
best if the 
back-ends have some form of 'ask-once' policy, so that e.g.
the first 
operation you do in a project asks for a password, and after
that we 
cache the information for that repo until the platform (e.g.
Quanta, 
KDevelop) is closed.

If we merged things, I think an optional flag specifying the
allowed 
level of interaction would be desirable. This would further
allow a 
'NoInteraction' flag where things needing authentication
would fail.

-- 
Matthew
When in doubt, duct tape!


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

On 04.09.07 10:32:27, Matthew Woehlke wrote:
> IMO authentication is always allowed, although it would
be best if the 
> back-ends have some form of 'ask-once' policy, so that
e.g. the first 
> operation you do in a project asks for a password, and
after that we 
> cache the information for that repo until the platform
(e.g. Quanta, 
> KDevelop) is closed.

Well, IMO thats wrong. The plugin shouldn't store the
authentication
information, it should use the facilities the vcs provides.
So if a vcs
always asks for authentication information the plugin should
do so as
well. For svn there's a "store credentials"
option, which is a good
thing, because some people are not comfortable with svn
storing
username+password in plain text (or you could say some are
too paranoid
to allow that ;)

> If we merged things, I think an optional flag
specifying the allowed 
> level of interaction would be desirable. This would
further allow a 
> 'NoInteraction' flag where things needing
authentication would fail.

I don't want to add another parameter, instead I think we
should drop
those that don't make much sense. If a commit message is
given that
commit message should be used, I can't imagine a use-case
where a
commit-message is used but the user might want to change
it.

Andreas

-- 
Be free and open and breezy!  Enjoy!  Things won't get any
better so
get used to it.

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

On Wednesday 05 September 2007 04:02, Andreas Pakulat
wrote:
> On 04.09.07 21:04:23, Matt Rogers wrote:
> > On Sep 4, 2007, at 8:14 PM, Andreas Pakulat
wrote:
> > > On 04.09.07 18:54:34, Matt Rogers wrote:
> > >> We should always retrieve a result. Don't
we always need to know
> > >> whether something succeeded or not?
Whether or not we display it to
> > >> the user is up to the user of the API. We
need to remove all of the
> > >> showXXX methods. They're redundant.
> > >
> > > I don't think they are. Those are
specifically to let the user see
> > > the result
> > > instead of just fetching it and eventually
doing something with it.
> > > For
> > > cases where the user of the API wants the
developer see the result of
> > > the diff, the showXXX methods can be used,
which saves the user of the
> > > API some code to write that would put the
diff into a diff-viewer.
> > > This
> > > code would be redundant for _every_ user of
the API that wants to show
> > > the diff to the user and that redundancy is
avoided by having showXXX
> > > methods.
> >
> > Ok, so diff is a valid use case for these show
methods. Perhaps we
> > can rename them displayXXX instead? Do you have
other valid use-cases
> > for other methods? Diff is the only one where I am
aware of where it
> > makes sense. Perhaps log as well.
>
> I'll go through the interfaces tonight and come up with
a list.
>
> > Another idea:
> > What about just having the XXX methods in most
cases displaying these
> > things in a tab in the text editor? We provide a
virtual protected
> > function that allows the user of the API to
customize how the display
> > is handled, and the XXX function calls it. This is
similar to how
> > it's handled in QItemDelegate and that's basically
the same sort of
> > functionality we're talking about here.
>
> I think I don't really follow you. How can the user of
the API provide a
> function to customize the display when the versioning
interface has no
> idea about the user? Its currently a one-way-API, a
user can call a
> function from the Vcs API but the Vcs API doesn't know
anything about
> the user (wether its a script, a class from shell, or
another plugin). I
> think I need a bit more detail on this to understand.
>

If you look at the docs for QItemDelegate, you can see it
provides four 
virtual functions for customizing the drawing. Reading the
source, 
QItemDelegate's paint() call calls each one of those virtual
functions, 
allowing the developer deriving from QItemDelegate to
provide their own 
custom drawing mechanism if they so choose. Most of the time
though, it's not 
needed, but the flexibility is there.  

We'd be doing the same sort of thing here.

Example: 

We have a diff() function that calls some "virtual void
displayDiff()" 
function, which, wherever it gets implemented, does
something we want it to 
do. Continuing with the above example, it'd open a new tab
in KDevelop with 
the output of the diff command as the text. the displayDiff
function could be 
overridden as needed to customize how the output is
displayed.

Does this explanation provide enough detail or did I leave
something out?
-- 
Matt

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

On 05.09.07 19:16:54, Matt Rogers wrote:
> On Wednesday 05 September 2007 04:02, Andreas Pakulat
wrote:
> > I think I don't really follow you. How can the
user of the API provide a
> > function to customize the display when the
versioning interface has no
> > idea about the user? Its currently a one-way-API,
a user can call a
> > function from the Vcs API but the Vcs API doesn't
know anything about
> > the user (wether its a script, a class from shell,
or another plugin). I
> > think I need a bit more detail on this to
understand.
> >
> 
> If you look at the docs for QItemDelegate, you can see
it provides four 
> virtual functions for customizing the drawing. Reading
the source, 
> QItemDelegate's paint() call calls each one of those
virtual functions, 
> allowing the developer deriving from QItemDelegate to
provide their own 
> custom drawing mechanism if they so choose. Most of the
time though, it's not 
> needed, but the flexibility is there.  
> 
> We'd be doing the same sort of thing here.
> 
> Example: 
> 
> We have a diff() function that calls some "virtual
void displayDiff()" 
> function, which, wherever it gets implemented, does
something we want it to 
> do. Continuing with the above example, it'd open a new
tab in KDevelop with 
> the output of the diff command as the text. the
displayDiff function could be 
> overridden as needed to customize how the output is
displayed.

ok, understood so far. Except one thing: I don't think I
want more than
1 way of displaying a diff - well maybe two (one time as
unified diff
inside kate, one time similar to kompar or kdiff3).

I can't quite imagine how an implementation could look like,
I mean
where to put the virtual, the vcs plugins already have the
option of
providing their own ui for any of the showXXX methods. And
if not on the
vcs plugin, where else would this be? Should the Vcs plugin
store state
then, like a "delegate" to render its ui? Would it
make sense to do this
globally or on a per-project basis?

Andreas

-- 
Abandon the search for Truth; settle for a good fantasy.

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