QBzr Eclipse plugin
Nicholas Allen
nick.allen at onlinehome.de
Wed Aug 20 18:53:41 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> I think you are right in that most users don't care what technology is
> used as long as the result is consistent and it works. On the other
> hand when it comes time to install people might question that all the Qt
> libraries get installed for an Eclipse plugin when everyone knows that
> SWT is the official Eclipse GUI toolkit. Not a strong argument but
> people will ask the question.
This will not be installed by my plug-in just like Bazaar will not be
installed by it either. The user must install bazaar and the qbzr
plug-in themselves.
There is also the issue of the licencing
> of the Qt library: some people still think there are issues with the Qt
> licence.
I am running it through a process. I am not embedding the code into the
Eclipse plug-in. This causes no problems with the GPL license.
>
>> I think one of the advantages is that Bazaar gets a common interface as
>> I know the TortoiseBzr project will be using QBzr too. The QBzr
>> interface seems to be improving at a faster rate than the bzr-eclipse
>> one so these benefits will come for free to Eclipse users.
>
> Consistency is indeed very important. The question is whether
> consistency across OS and applications is more important that
> consistency within an IDE. I would favour the latter, hence the
> original question.
It's possible to argue from both sides. I think a common graphical
interface to the version control system regardless of whether you are at
command line, Explorer on Windows or in an IDE like Eclipse or Visual
studio is a really nice feature. Also, as an end user you probably won't
be able to tell. SWT uses native widgets and QT can emulate the look and
feel of native widgets so well I don't think you could tell there was a
different widget set being used.
>
>> If you don't want to use it then don't. I'm publishing it because it
>> will be useful to me and I hope others. Choice is not a bad thing and
>> this project won't stop the work being done on the existing bzr-eclipse.
>
> Clear abstention is always an option. On the other hand we are
> proselytising and trying to sell Bazaar as the VCS of choice in Eclipse,
> NetBeans, IntelliJ IDEA, Emacs, etc. If there are multiple choices the
> danger is Balkanization. So having only one Bazaar Eclipse plugin may
> not be to everyone's taste but it means there is no possibility of
> undermining the overall message.
>
> Personally I tend to use command line bzr in a terminal and then do
> "synchronize" or "refresh" if I am using an IDE.
Me too - I found that even though I had the bzr-eclipse plugin installed
I always used the command line and qbzr and only used the Eclipse plugin
for rename and delete support (which I also intend to add). That's why I
decided to write this plug-in - to save me switching from Eclipse and
command line all the time.
This is essential
> using NetBeans as there appears to be no Bazaar plugin. It is also
> essential with IntelliJ IDEA at the moment as the bzr4idea plugin needs
> a lot of work to be really usable.
I think it doesn't make much sense to keep writing new graphical
interfaces to Bazaar for each and every IDE. It's nice to have one
really good GUI (and I think qbzr is on the right track) and use it
everywhere. I have managed to put together a functioning GUI to Bazaar
in Eclipse in 2 days and that required learning about the Eclipse
plug-in development process too. Using QBzr it will be easy to write
support for other IDEs in a similar time frame. This means Bazaar could
support all those IDEs in a very short time frame.
Nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIrFol1+i51gqqEGkRAhCRAJwIU9lfRFy0LOPQf2KHtDpMm/vpMwCfV3Sp
Bi3cxo98Nt6uUht3GhH7wl8=
=Fzdw
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list