VCS Gui-Interface "Design"

[Jens Herden]

> > Yes and No. I think it should be possible for the user to see easily
> > which VCS they are currently using. But I also think that the same action
> > should have the same name independent of the used VCS.
>
> Hmm, maybe
>
> "Version Control" -> (CVS|Subversion|...)
>                      Add
> 		     ...
>
> i.e. a label with the type in the submenu?


Yes, this would be a good solution :-)


> > Does this mean you have to introduce some kind of flags to see what kind
> > of features the plugins actually support?
>
> Not necessarily. Thats why we have an interface class for the basic
> stuff. Any Vcs Plugin will have to implement that interface fully and we
> tried to keep it to the "bare minimum" that all Vcs systems understand.
> Well, all Vcs Systems for which people stood up in the design phase
> (IIRC that were CVS,Subversion and Perforce for most of the stuff).

I see, if the policy is to implement all of it there is no problem.


> > The benefit of letting the plugins handle the actions is that outside
> > nobody has to know what the plugin is capable to do. But if you pull
> > out stuff you have to export this knowledge in order to not offer
> > actions that have no effect.
>
> That might be needed for the other interfaces, because IIRC those have
> actions that don't need to be implemented or can't be implemented. But I
> don't see a real problem there, those interfaces are reasonably small
> ones.

As long as it is the same "you have to implement all of the interface" there 
is also no problem. The other option would be to let the plugins handle these 
cases and let the plugin offer an action collection which can get plugged 
into the submenu.

Jens

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070904/73985182/attachment.sig>