Re: [gedit-list] Plugins

[Paolo Borelli <pborelli katamail com>]

(sorry for the dupe Jesse, I missed cc'ing the list)

Jesse van den Kieboom wrote:
> 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.
>
>   

Dunno... what other people think? As I said above I am not totally
convinced that this is a real problem since most of the people will not
have so many plugins installed. Apart from that I am pretty confident
that categories are note the way to solve it, since they make stuff
harder to find unless you know where you need to look for. For similar
discussions you can dig on old gnome discussions about the add to panel
dialog :)

>   
> > > - 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.
>
>   

My gripe with this is that it could be easily abused. I'd rather see a
bottom up approach:
- what are the specific use cases?
- does this use cases really need cross-plugin comunication?  Would
they be better solved by putting a widget in the core and allow plugins
to use them
- python allows runtime testing, maybe we should just take advantage of
it and see how things go.

Basically - if it wasn't clear - I am really scared by overengineering
the solution. The new gedit plugin system is still young and I'd prefer
see some more dust settle before expanding it.

> > > - 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
>
>   

I'd say that the GeditPlugins page should just talk about the
gedit-plugins package with a description of the included plugins,
instructions on how to get a plugin included etc. Plugins request and
other third party plugins can stay on the main page or if the list grows
too long on another separate page.

> > > - 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.
>
>   
This is really up to who wants to do the work. I don't think one thing
should block the other.
> > > - 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 :))?
>   
http://ggap.sourceforge.net/files/completion-0.0.2.tar.bz2 (not sure if 
it's a stable URL)


> > > - 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.
>
>   
Well, as I said this is just really up to who wants to have fun writing
it. I really don't see one thing blocking the other: someone is used to
ctags and wants to do a ctags plugin in gedit? Cool, I will not stop
you! Someone else doesn't feel ctags is up to the job and wants to
design a better solution? Even better, go for it! Want to turn it into a
generic library that can be used by anjuta and others? Sure, sounds
great! :)

This is really what plugins are about... If someone wants to see a
feature he has the chance to do it, choosing the result/effort ratio he
is willing to spend.


Paolo