Stefan,
If you release a piece of software into the public domain, be prepared
to listen to the whims of its users. If you wanted TSVN to be closed
of features that you don't like, then you should have made it closed
source.
I am sure you are clever enough to implement such an API system that
is bomb proof. I already stated that the interface would need to be
simple for this reason.
The third party plugin and its interface within TSVN could even be in
a different thread.
There are hundreds of other programs that allow third party programs,
and they don't seem to put "But what about bugs" as a showstopper, in
any case surely a bug report, "When I run my program TSVN crashes"
would get a farly short response.
I sent this to see what others think, let them have their say.
j.
On Sep 11, 4:38 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> the-moog wrote:
> > I would like to be able to add my own commands to the TortoiseSVN
> > context menu, I believe this could be done via some sort of API and/or
> > static configuration.
>
> > The question is: Do others think this is a good idea, who would make
> > use if it?
>
> > It would work like this:
> > TSVN could be installed normally, then additional program installs
> > would add functionality through external .dll and/or static
> > configuration files. These external files would register their
> > functionality with TortoiseSVN, adding (indeed perhaps removing) items
> > from the Tortoise context menu. Although separate programs, modified
> > versions of the TSVN windows installer could add these plugins during
> > TSVN install in one pass for easy software distribution.
>
> > This external 'plugin' would probably be able to do most of its work
> > through TortoiseProc, though the API would supply something like the
> > following (pseudo) function:
> > AddContextMenuItem(MenuItem,Location,MenuCallbackFunction)
> > GetWorkingVersion(Context)
> > GetRepositoryPath(Context)
> > GetContextPath(Context)
> > GetContextFile(Context)
> > GetModifiedState(Context)
> > CallTortoiseProc(Command)
> > Others....?
>
> > The only change to TortoiseProc would be the need for silent
> > operating, allowing user interaction to be eliminated if necessary.
>
> Letting external plugins deactivate TSVN menus? I don't think so. We'd
> have to deal with users reporting bugs to us which are not TSVN bugs at all.
>
> > Thus, these external plugins would have access to some subset of
> > TSVN's functionality through a combination this new API and the
> > existing TortoiseProc, this new functionality would include, but not
> > be limited to:
> > Gaining information about the working version
> > Adding items to the context menu(s) while registering some .dll
> > callback in the process.
>
> The problem with that approach is that we're dealing here with shell
> extensions. One bug would crash the desktop.
> I don't like to take that risk.
>
> > The benefit would be that an organisation need only install, configure
> > and maintain one install; instead of installing both TSVN and SVN
> > Client plus their additional tool(s). Lastly and most importantly it
> > would also provide a consistent interface to SVN under windows meaning
> > less training within organisations regardless of their differing
> > needs.
>
> Such plugins would have to be COM-objects and implement an interface we
> would have to design ourselves. But then it may be easier for you to
> just implement your own shell context menu handler.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> signature.asc
> < 1KViewDownload
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-09-11 18:44:26 CEST