Re: [gedit-list] Plugins

[Jesse van den Kieboom <jesse icecrew nl>]

Op ma, 24-04-2006 te 15:00 +0200, schreef Paolo Borelli:
> > - Define categories for plugins and split gedit-plugins in those
> > categories. Also show the categories in the plugins list in gedit (maybe
> > with a collapsable treeview). Possible categories are: Desktop,
> > Application development, Web development. I think this is important
> > because the list of plugins will grow fast.
> >
> >   
> I am not sure categorization is the way we wont to go:
>  1 - the default set of plugins is manageable, the list grows only when 
> people start installing third party plugins. In my opinion chances are 
> that someone installing plugins can easily deal with a longer list. 
> Beside I think that most of users who install third party plugins only 
> installs the plugins they are interested in, so the list should not be 
> that big.
>  2 - categorizing has proven itself not really effective because often 
> it is not clear in which category something belongs. It also makes 
> finding stuff harder since you first need to guess the category.

It's more or less that I find myself scrolling through a list of plugins
in which a lot of plugins I don't want to use. This just clutters the
list for me. Maybe this is just a personal problem, but I think
categorization would solve this as I can just leave the categories I'm
not interested in collapsed. Defining good categories might be a problem
indeed, but I still think it's worth looking if the current plugins can
be split up in a clear way.

> > - Merge join/split lines with the advanced editing plugin
> > http://live.gnome.org/Gedit/AdvancedEditingPlugin
> >
> >   
> Sounds definately sane.

Okay, I think this can go in gedit-plugins, but we need to ask Marcus
Lunzenauer and Steve Fr�naux.

> > - The project plugin, I think there were about three persons working on
> > something, but there isn't really anything done as far as I know. I
> > think a good project plugin can be very useful for other plugins as well
> > because it allows for applying things to all files in the project
> > (thinking about cvs/svn plugin or formatting plugin)
> >
> >   
> A project plugin sounds all nice and fine. Interdependent plugins is a 
> can of worms I am not really eager to open, so IMHO the longer we resist 
> this temptation, the better.

I disagree. I think we should tackle this problem sooner then later.
I've argued before that I'd like to have inter-plugin communication
possibilities. Python plugins don't need any changes to be able to make
use of each other. I understand that dependencies involves a lot more
than just letting one plugin call stuff at another plugin, but in my
opinion a lot of plugins can make use of the project information in a
project plugin.

> 
> > - Put more structure in the available/requested plugins list. It's a bit
> > messy at the moment (in my opinion). Maybe move all plugin related
> > information to a separate wiki page (e.g. Gedit/Plugins or
> > GeditPlugins).
> >
> >   
> Sure, reorganizing the website&wiki plugins section sounds very good.

Okay, but.
 - Does gedit-plugins need a separate wiki (I created one for now, but
it generally contains the same information as already present on Gedit
at the moment) http://live.gnome.org/GeditPlugin

> > - Write a python plugin howto and create a generic python plugin
> > template
> >
> >   
> This has been on the plan for a while... it "just" needs someone doing it :)
> It would also make for a nice GnomeJournal article...

Well this probably can be done at the same time as the website reworking
because I think that's where the howto's should go.

> > - Design an API for the completion popup as we've talked about before.
> > There are quite some plugins that want to have popup lists (snippets,
> > word completion, ctags/cscope completion)
> >
> >   
> Anjuta people have implemented this and I also have a plugin by Muntyan 
> which implements it. Code seems pretty good. It however needs some 
> definite API proposals which takes into account all use cases and future 
> expansions. Ideally it belongs to SourceView, but we can first test it 
> in GeditView and then migrate it to sourceview when it has proven itself.

Okay, where is this code located so I can take a look (I had some ideas
myself, but luckily Muntyan already did the job :))?

> > - Decide what to do with the different ctags plugins. I personally don't
> > think ctags is really useful for the things we really want, decent code
> > completion
> >
> >   
> This is really a matter of someone interested in doing the work. I 
> personally don't use CTAGS, but many people do. If someone wants to pick 
> this up more power to him.

I don't either. But what ctags does is scan files and create an index of
all the tokens. The problem is, do we want a ctags parser (this would be
mostly just reading ctags and generate a list, which is what the plugin
I created a while ago does). Or do we want to have ctags functionality
(e.g. scan for tokens) which we can than use to do much more (again in
combination with the project plugin) like rescan on the fly, built
better and faster indexable cache of the available tokens. Ctags is nice
and all, but it requires the user to create the ctags file. When we know
all the files involved we can of course rescan those files with ctags
and than reparse the ctags file, but I'm generally against it :)

I'd rather have a generic ctags like library which allows for easy
implementation, good indexing and easy updating. I've talked to anjuta
guys about this before, but they didn't seem interested. I think anjuta
took pieces of ctags and incorporated that in anjuta, but a separate
library would be nice. Maybe I'm just ambitious here.

> > - Write a good cvs/svn plugin
> >
> >   
> Ditto, a plugin would be nice. Send it when it's ready ;)

Sure :)

-- 
Jesse van den Kieboom

Visit: http://www.icecrew.nl