On Thu, Sep 11, 2008 at 12:42, the-moog <jason.morgan_at_cropwell.net> wrote:
> 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.
Public Domain != Open Source.
Stefan raises valid questions and concerns which you have not
addressed. Just because you have come up with an idea does not
obligate him to implement it. He even offered you a suggestion of
creating your own context menu handler.
> I am sure you are clever enough to implement such an API system that
> is bomb proof.
In a shell extension, it's more precarious than a regular application.
> I already stated that the interface would need to be
> simple for this reason.
As you noted above, it's open source. You can hack on the code yourself.
> The third party plugin and its interface within TSVN could even be in
> a different thread.
Have you read the source and know this for a fact?
> 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.
Are all those programs shell extensions?
Stefan is right, allowing a 3rd-party extension to disable core
functionality would just raise extra "why doesn't this work?"
questions on this mailing list, where they are not appropriate.
> 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
>
>
---------------------------------------------------------------------
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:48:35 CEST