GNOME Bugzilla – Bug 547208
Empathy should include a plug-in architecture
Last modified: 2018-05-22 13:13:31 UTC
Many Gnome apps (Epiphany, Totem, Gedit etc) now include a facility for developers to easily add new functionality via the use of plug-ins. Such a system has many added benefits for both developers and users, who can pick and choose the features they like without cluttering the UI with things they don't want. Several of the feature requests found in Bugzilla (for example LaTeX maths rendering or OTR messaging) would be most appropriately implemented as plug-ins. In addition, new and highly desired features such as file transfer could be implemented as plug-ins, allowing early-adopters to test it without risking the stability of the programme for the majority of users. I realise this would probably entail a fair bit of work on the part of the Empathy developers, but I think that long-term the benefits would be worth it. Please give this idea some thought!
With the telepathy system plugins are not that useful because any application have the full access to the IM connection. Most features traditionnally done as plugin could be done as separate application. I personally think all application abuse of plugins. A plugin IS NOT a way to replace build-in configurable features. A plugin IS NOT a way for developers to say "you can do that as plugin so I don't build it in and I don't care about your interesting new feature". a plugin IS NOT a way for doing stupid things totally useless that some user can't live without, teach the user to be sane instead. A plugin IS the best way to integrate buggy, not maintained code into an applications. A plugin is a way for another application to integrate itself into empathy's UI. Just like flash player has a firefox plugin to plug into web page are read youtube video. All other uses of a plugin (most uses) are totally stupid and should never happen. So yes empathy could have plugins some day, but I see realy limited need for that.
Just to say that the "Share my Desktop" option in contact list launching a vnc tube is an example of feature that would gain to be a plugin.
Bug 574744 would be nice to implement as a plugin, too.
I do think plugin could make sense for some features.
+1. for eg of many features which are useful but not really something core devs should spend their time on see the plugins for pidgin.
"a plugin IS NOT a way for doing stupid things totally useless that some user can't live without, teach the user to be sane instead." With power comes responsibility. Sure you'll get quite a few pointless plugins, but really that can be a big draw to get new users. Look at Firefox, without extentions (read as plugins), do you /really/ think it would be as popular with as many people as it has been? If all it had was it's core functionality, it would still have a very niche market of techies/nerds/etc. It's all those stupid "can't live without" extentions that has got millions of average users using it. "All other uses of a plugin (most uses) are totally stupid and should never happen." That doesn't mean users don't want that stupid feature. Look at desktop effects. 95% pointless eye-candy, but users seem to really love it (and it has grown on me as well.) Anyways +1 for plugins. My preference would be to allow Lua as a scripting/plugin language, though just getting the initial C plugin implementation would be huge into eventually getting support for other languages. Just to be thorough, I should mention that plugins could possibly make debugging a bit more difficult since they could potentially cause unexpected results (not a huge deal really, users will just need to verify it's not the plugin(s) causing the issue.)
An easy way to get plugins in empathy would be to use Ethos http://git.dronelabs.com/ethos/about/ And since Empathy is already available as libempathy and libempathy-gtk, it'd technically be easy to have a plugin API. Now, the question is really should one that be allowed.
Ethos should be included in GNOME before then.
*** Bug 615079 has been marked as a duplicate of this bug. ***
Plugins would allow people to attain a feature that the development team doesn't want to implement. An example is the off the record ability. I have looked into this in Empathy, but is seems the developers don't want to implement it in Empathy preferring to wait for upstream development in the protocol itself despite many people wanting the feature and not wanting to "wait" for something that may never happen. This is so much requested, that they put it as part of their FAQ (with which I disagree, remember, it is written for the user, not for the developer). See: http://live.gnome.org/Empathy/FAQ#Will_Empathy_have_OTR_.28.22Off_The_Record.22.29_support.3F A plugin architecture would allow for ways to go ahead and implement what users want (or almost demand) compared to the beliefs of the developers. If users want it, a plug-in architectures gives one more possible way for users to get it. I'm sure enough people see the value in Empathy, but also want something like OTR that someone with the skills (wish I had them) would write such a plugin. Otherwise, please respect the user's wishes and implement OTR (for example) and don't make us wait for protocol upstream that may never happen. Thanks, Narnie
Note that thanks to Telepathy's design, lot of things can be done using external application. So if you have ideas of plugins, please explain them to us and we'll tell you if it can be done in a separated Telepathy app.
*** Bug 638069 has been marked as a duplicate of this bug. ***
My use case for a plugin architecture would be per-contact IM and signon sounds. It would be possible to implement this as an external application, but two big things would make this awkward: a) Empathy can be set to mute sounds while away, and can enable/disable sounds in general. An external application would need its own preference, requiring the user to set this preference manually in two different locations. b) The external application would have to duplicate a large part of empathy's contact list infrastructure in order to make a sufficiently friendly configuration system. Whereas in a plugin, it could add to empathy's UI--a per-contact menu item, adding a box to the New Contact or Contact Properties dialog, etc, and have a much simpler UI
I would make a plugin that supports changing the nickname for all the accounts in a single widget along with the profile picture/display image. I have done a similar plugin for pidgin but frankly I prefer empathy in some things. Note to the developers: actually the only thing keeping me from using empathy is that sometimes messages don't get sent to the recipient and there is no notification about this for the sender, the bug is reported already but a fix is still awaited. There is so much functionality that can be brought to empathy if a plugin system was implemented. It could really be the clincher for empathy.
(In reply to comment #14) > I would make a plugin that supports changing the nickname for all the accounts > in a single widget along with the profile picture/display image. I have done a > similar plugin for pidgin but frankly I prefer empathy in some things. That shouldn't be done by a plugin. See bug #612444
I've wanted to write a plugin that speaks new messages aloud using Speech Dispatcher (or whichever speech API GNOME3 blesses). I have a number of plugins across my desktop that do stuff like * read new e-mails' subjects and authors aloud,[0] * read the name of the next song and its artist aloud,[1] * read the time aloud.[2] They're not intended for accessibility, more for select notification-grabbing features. It's mostly because I like to do lots of stuff away from my computer, and when a potential distraction arrives, I want to know whether it's important without having to drop what I'm doing and walking over to investigate. I actually wrote one for Pidgin[3] and have missed its functionality since switching to Empathy. If there's a better place than Empathy to put such a feature (I've thought that the desktop notification API might be a better place to catch all my use cases :D), please say. 0. https://bugzilla.gnome.org/show_bug.cgi?id=607610 1. http://kosmokaryote.org/codepoems/djaqua/ 2. http://kosmokaryote.org/codepoems/bellaqua/ 3. http://kosmokaryote.org/codepoems/imaqua/ (not all links are up to date, since I got side-tracked by work and school, but I haven't given up on them.)
You could do such thing by writing a Telepathy Observer: http://telepathy.freedesktop.org/spec/Client_Observer.html You could use TpSimpleObserver from telepathy-glib to easily do that.
*** Bug 704923 has been marked as a duplicate of this bug. ***
Sure, it would be better if things were well integrated, or options, rather than plugins, but sometimes allowing plugins can lead the way, and fill those gaps. For example, empathy currently doesn't allow OTR (despite the technology being there), ( and doesn't have a well functioning system tray icon for my needs) . This means I have to install pidgin instead, and have all its disadvantages, which is significantly more difficult than installing one, or maybe two, plugins to solve the issue.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/24.