Jakub Steiner <[EMAIL PROTECTED]> writes:
> * Something I am guilty of never getting to was speccing out a
> search based interface to filters (plugins). I believe a search
> based interface will be more efficient than navigating through a
> nested structure of a menu.
That reminds me that with all the recent changes to the plug-in
registration, the current Plug-In Browser has become less useful than
it used to be. And I think that it could make sense to replace it by a
menu browser. Users shouldn't really have to care about whether a
function is implemented in the core or in a plug-in or script. We
should probably do the following:
- Improve the PDB interface for getting plug-in information.
The current API doesn't really work well. All it offers is
retrieving a list of all plug-ins. There should be an API that
allows queries using regular expression similar to
gimp-procedural-db-query. This will allow to improve the Plug-In
Browser and long-term it will help for tasks such as one-click
plug-in installation/deinstallation. Also we will want to show
this information in the proposed Menu Browser (see below).
- Improve the Plug-In Browser using the new API.
This will show that the new API does what it's supposed to do. It
includes adding search functionality similar to what the Procedure
Browser offsers. Both plug-ins already use the GimpBrowser widget so
this should be relatively easy.
A menu browser could also be implemented as a plug-in, provided that
we added a PDB API to access the menu structure. But soon enough we
would want to allow changes to the menus from the browser, turning it
into a menu editor. At this point it probably starts to make sense to
implement it in the core instead of exposing all the details of the
menu system to the PDB and even allowing to edit by means of PDB calls.
Not sure if such a menu browser could double as the filter browser you
asked for. You probably had something less intrusive in mind.
Could this (the plug-in browser changes and the menu editor) perhaps
become a SoC project?
> * Improve SIOX to give nice anti-aliased result. The current
> implementation is a nice bulletpoint in a feature-list, but
> the result is very jaggy and hardly usable as is. Unless you
> work at 4 times the final resolution perhaps.
Perhaps Gerald could elaborate a bit about the Detail Refinement Brush
for SIOX. There is already code for this in GIMP CVS. It just isn't
> * Flowed text. The text tool doesn't allow to create blocks of
> justified text.
Yes, there's quite a bit of improvements that could be done to the
text tool. I think this could be a nice SoC project and I would like
to mentor it.
Gimp-developer mailing list