VCS Gui-Interface "Design"

Andreas Pakulat apaku at gmx.de
Tue Sep 4 19:16:15 UTC 2007


On 04.09.07 20:32:35, Jens Herden wrote:
> On Tuesday 04 September 2007, Andreas Pakulat wrote:
> > Hi,
> >
> > I'd like to discuss how the Vcs support should surface in the KDevelop
> > GUI. The main question here is: Do we want to "hide" the actual Vcs
> > System used for a file/folder from the user and provide something like a
> > "Version Control" entry in context menu and such?
> 
> 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?

> > Of course 
> > this would happen _only_ for the actions in IBasicVersionControl+ any
> > actions from the other vcs-ifaces that the plugin provides. A Vcs Plugin
> > may still provide an additional entry for any special actions it wants
> > to provide.
> >
> > The main reason for this approach would be consistency, i.e. no matter
> > what Vcs you're using, you'd get the same GUI items. But it also would
> > mean we don't have to provide tons of API on the plugin class itself,
> > because this would simply use the IBasicVersionControl API that the
> > plugin has already - the svn plugin currently has I think 3 or 4 methods
> > for each action, 2 from the iface and 2 other which is a lot of
> > duplication.
> >
> > Andreas
> >
> > PS: Currently the two vcs plugins provide menu entries and some context
> > menu all of their own and I don't really like it :)
> 
> 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).

> 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.

Andreas

-- 
You have an ability to sense and know higher truth.




More information about the KDevelop-devel mailing list