В Чтв, 17/05/2007 в 18:26 +0200, Vincent Untz пишет: > Hey, > > It's great to see more and more applications creating a plugin > architecture. However, I think it's worth discussing a bit some of the > issues we're facing wrt plugins. I'm just raising three points to start > the discussion, but there are probably other interesting items that are > worth discussing. > > > Naming > ====== > Plugin vs extension? It has already been raised on the list [1], but > there wasn't a lot of replies there. Using the same term everywhere is > really the only way to go. > > My €0.02: I think that people are getting used to the Extension term, > and it sounds less geeky. > > > UI and code sharing > =================== > Every time a new module is getting the plugin love, I'm seeing this: "I > stole the gedit/epiphany code and integrated it". Wow. Copy and paste? > Would it be possible to share all this code in a library? (maybe it's > not, I don't know: I didn't look at that code) > > Also, each module is having its own plugin/extension manager dialog, and > they are all looking the same, but with small variations. Wouldn't it > make sense to standardize this? Again, maybe a library could help. > > (And in the future, we might want to get some "update the extensions > from the internet" feature, and we don't want to implement this ten > times, do we?) > > > Moving features to plugins/extensions > ===================================== > (thanks to Baptiste for having raised this specific issue) > > One of the first thing people are doing with plugins/extensions is > moving some of the current features there. It often makes sense from the > code point of view, since things will be cleaner. But it doesn't always > make sense for the user. > > Some of the features implemented in plugins/extensions should just > always be there, and it's useless to disable the plugin/extension. The > handling of multimedia keys come to my mind (I believe RB is already > doing the right thing in this specific case and always uses this > plugin). Plugins/extensions about integration with the rest of the > desktop are another example. > There could also be some way to automatically enable a plugin/extension > when it makes sense. > > It's probably worth considering global settings for various types of > plugins/extensions. Many applications may want to ship a > plugin/extension changing the status in galago. Maybe it's worth > considering the option of having only one place where we say "Enable > galago" instead of having all the applications expose the > plugin/extension. Or they could all expose the plugin/extension, but > only to override the global setting. > > > All this needs to be discussed, and we can probably determine what makes > sense, and what we can do to make this kind of feature work better in > GNOME. > > Thanks, > > Vincent Although problem with GUI library with widgets for GNOME desktop is important it's probably a subject for another discussion. Yes, we need a library with quickly maintained but not probably stable widgets. Without extensive testing it's hard to write a stable interface for GTK. But here I think the third issue is more important - is plugin framework really required? A few bad properties of plugins: 1. They are badly tested. So called Evolution plugins distributed with Evolution aren't translated properly even now. As with every GUI option we create a lot of cases to test and make our system very complicated. With current overcomplicated systems stability and safety became much more important. We can't guarantee stability in plugins and user doesn't care is it flash plugin or epiphany itself crashed and thus a hour of his work is lost. 2. They duplicate package-management system. It's really not so good we don't have a package management application and use distro-oriented tools, but is it a reason to introduce an application or UI to manage installed functionality? Why not just use package manager for this task? Package manager has almost all required functions - signature checks, search, meta-information, dependency tracking and so on. 3. They are hard to find out. When user installs application it should just work as expected nothing more. I remember I spent several hours trying to find out they way to export certificate from epiphany. Of course the first thing you might do is to search menu item for plugins. Also you can try to adjust dozen option in your app? Isn't it easier to move to another desktop environment. 4. As noted before they require too complicated interface to work with application. Signing and searching is the minor things. What about safety for cooperation and dependency issues? Dynamic linking is not a solution here, it should be some sort of IPC with mandatory error checking, dbus probably. Applications can define extension points through dbus and others can use them but it's very different from plugins. Don't forget about required documentation for plugin-writers. 5. Usually people say that plugins make code modular. I don't see how. You can make your code modular just by separating a library or a file and defining interface. Probably someone will add more, it would be appreciated. I haven't seen eog-ng yet and probably it's not my domain but I can't imagine what can be implemented there with plugins.
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=