jEdit Community Wiki > Main > ImprovingJEditDev	jEdit Community Wiki webs: Main | Plugins | Know | TWiki | Sandbox
	Main . { Whats New | Users | Groups | Changes | Index | Search | Go }

Opening up and improving jEdit's development

Here are some ideas on how to open up and improve jEdit's development. Feel free to add your own ideas and discuss the existing ones.

Things that are decided upon should be moved to the Development Tasks page. There all things that should be done are listed and if a developer decides to take on one of them he can put is name there so that everybody knows who is doing what and nothing is done twice.

• General Development Strategy
• Plugins
• Documentation
• Bugs
• Community Site and Wiki
• Ideas collected from the jedit-users mailing list

General Development Strategy

• Switch from CVS to Subversion?
• Should there be a small group of developers who review patches and then check them in? Or should every developer check in his own changes?
• Use the Source Forge "Patches" tracker?
• Add new features or concentrate on removing bugs and improving the existing ones?

Plugins

• Try to combine similar plugins
  • Merge of buffer-switching plugins

Documentation

• Keep the jEdit help viewer or switch to HTML documentation for external browsers?

Bugs

Community Site and Wiki

• Move old pages or information to a special "Old Stuff" page.
• Is it possible to combine the user databases of the community site and the Wiki? So you only have to remember one username and password.
• Update to the newest TWiki version

Ideas collected from the jedit-users mailing list

These are some ideas I collected from recent posts to the jedit-users mailing list.

• Ideas by Vampire
  • The plugins should have the possibility to split there documentation in several pages. It is possible, but it is not solved very good. In the treeview you have still only the main-index-page. The Plugin can either write all its documentation in one long page, which is not really handy or can link the pages itself, which is too not really handy for navigating through the docs. If the plugin has more than one page of documentation the treeview should let you access them directly I think. And there should be a standard for the format of the documentation, the Layout I mean. I like the layout ot the Users's Guide and used by some plugins too e. g..

• • Plugins should store data ONLY in the settings-directory (e.g. ~/.jedit), I mean in a subfolder there. Some plugins store something somewhere else. But that is not good in my opinion. 1. It is a plugin of jEdit, so the data should be stored together with the others, and if I want e. g. transfer my settings I should only have to copy the settings-directory and don't have to search for every plugins settings-directory. If the user really wants to change the location the plugin can provide a choice in its options to change the path, but the default location should be under the settings-directory. Too not under ~/.jedit, but under the settings-directory which can be somewhere else too. Of course this is not really something for compiling in the core, because of that it is put in paranthese, but I felt I have to speak that out. Oh, almost forgotten, plugins should on uninstalling have an option to clean up. Settings, Properties etc. If I only installed a plugin to test if it fits my need I don't want to have some dead files and properties laying around after deinstalling it. For some others I would keep the settings for later reinstalling maybe.)

• • For the Plugin-Manager I would love to have e. g. one more Tab, which shows Plugins that are available, but not useable and why. Either because they are deprecated or what is more often the reason because they need something updated. One example: I told a friend he should use the Project Viewer Plugin for Projectmanagement, but he couldn't find it in the Plugin Manager. After minutes of wondering I had the idea that the Plugin maybe need at least jEdit 4.2final and he worked with jEdit 4.2preX. With a tab showing the not useable Plugins with reason, e. g. jEdit needs update or JVM needs update, he would have seen the problem right after occurence.

• • Too for Plugin-Manager: I want to be able to disable a plugin. Not only for the current session, how it is at the moment, but upon I wish to reactivate it. Maybe additional groupable too, so that I can activate some plugins at once, or deactivate. This with multi-group too, means that one plugin can be in more than one group. One reason is that heap used is decreased and speed of jEdit is increased. And another important reason is that the Plugins-menu is not so full blown if i can acitvate Plugins only if I need them and don't have to have all Plugins I sometimes use activated all time. (Yes, I could uninstall/reinstall each time, but that is not really handy.

• Andy Streich
  • A way for the user to arrange the plugin menu. I image one menu item expanding into a submenu with the complete list so you can always access all of them (now in two clicks rather than one) and then items below (or above) that the user places in an arrangement that suits her or him.

• • Be nice too if the Plugin Manager "Manage" tab listed the size of each plugin for those of us who need to manage that carefully; then you'd have the information you want in one place. Currently that is on the Install tab or in the file system itself of course.

-- Dennis Benzinger - 22 Jul 2005