Hi, Jakub Steiner <jimmac@xxxxxxxxxx> 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 used yet. > * 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. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
