Plugin system
Contents |
A plugin system
At first I thought that a plugin system which lets plugins create new user interfaces is overkill. However, when I looked at other Bible programs I saw that there are many features which could be plugins.
Examples
These could include
- text coloring (like in e-Sword, The Word)
- note editor
- some Bible translating tools?
- different search engines/UIs (a graphical search editor)
- printing system
- advanced copypaste system for office application integration
- new kinds of text views
- memorizing help system
- daily reading plan
- parallel Gospel harmony
- new backends plus interface enhancments for them, like STEP reader
- (...find new ideas by researching existing software...)
Let's take a text coloring feature for example. I have not felt any need to add colored backgrounds (underlining) to my Bible texts. But when reading some Bible software reviews I noticed that some people need it desperately. If the software has that feature, it adds user interface elements which I don't need. That may not be a big problem, but Bible software needs screen estate and user wants it as simple as possible for his needs.
Another example could be some tool to assist Bible translators. I can't even imagine what that tool would be. 99% of the people would just hate it.
But what if the software has some kind of plugins? There would be configuration window where you can choose which plugins you want to use. There could be even some very common features as plugins - they just would be enabled by default. For some more specific needs people can be told to check the corresponding item in the config window.
Development
Plugin is of course more than user interface. It's an architectural design decision. One benefit of a plugin system is that it makes things modular and independent, which is good.
Think about the coloring example. With non-modular code you just hardcode features into classes. You would have to modify the main menu, window specific UI elements, rendering engine etc. You would edit the code files in all of these places.
With plugin architecture you would make a new directory. You would maybe subclass things, but mostly use clear interfaces #including header files. You would not touch in one file in other directories. You could add compilation options to enable/disable the feature. If you enable it, you can open your compiled application as if nothing new has added, and then enable your plugin in the config dialog. Adding plugin adds new user interface elements and functionality, removing plugin removes them and makes UI simpler.
That might be very important for new developers. Now that BT will go cross-platform it may draw more attention amongst developers. If they see it's easy to start playing with new code they might do it. It just needs good documentation.
But...
I don't know how this all happens. And I don't know how it would affect the overall design and architecture. I don't know if it adds too much overhead or is too much work or if it really would help developers. I just can imagine.
There are open source applications which have plugin systems - we could learn from them. Firefox is the best example.
I'm not talking here about similar system where users can download independent plugins. That would be too much and there's no need for that. This system would just enable modular, independent development and highly configurable user interface.
--Eeli
