VCS Gui-Interface "Design"

Jens Herden jens at kdewebdev.org
Tue Sep 4 18:32:35 UTC 2007


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.


> That would mean we limit KDevelop to 1 Vcs System per project, which
> isn't extremely unreasonable though there might be cases where people
> have CVS and .svn in the same project (been there, done that). 

IMHO support for one VCS per project should be enough, everything else leads  
to a polluted UI. People who want to have this esoteric setup can use the 
konsole for the second VCS. 


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

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/9ddccafa/attachment.sig>


More information about the KDevelop-devel mailing list