On Tue, Sep 07, 1999 at 11:17:47AM +0200, Daniele Medri wrote: > Hi, > yesterday night on #gimp (irc.gimp.org) a discussion about a future > reorganization of gimp. > I think this: > > 1 - why don't make a Filter item in menu.. and put all items here? > No difference between script-fu, perl or bin. Well, there is a difference however. Scripts and bin plugins dont share the same behaviour (especially bin plugins and script-fu scripts). Script-fu isnt undoable for example. I for one, like to know if the random menu item I'm about to execute is a script, a perl plugin, a bin plugin, or other. I have no idea if most users feel the same way however. And isnt there already a Filter item in the menu? I could see a potential argument for killing the filter menu entirely and moving all plugins up a level. Would eliminate a level of nesting. Of course, then your top level menu would have about 30 menu items in it. Enough to scare even the most hardened gui menu navigator. How to pack the 200+ menu items in a sane fashion without having them too deeply nested or with too many top level categories is quite the fun problem. The number of top level entries is somewhat important if anyone ever wants to implement a per image window top bar menu. > The item Filter must read dinamically what is there in pluging > directory and split plugin for subdirectory inside. > The concept is similary to photoshop. Standard filter defined.. and > the OPEN reading of directory for other plugin. > > This could be useful for a rapid and personal reimpostation of these. > > Another solution to manage better plugins.. could be a new panel in > preferences where people could choice what plugin use in session. The > concept is similary to MacOs extensions. > In theory, a user just needs to edit pluginrc to move plugins to wherever they want, exclude any they dont like, etc. Of course, there is no gui way to do this, and current behaviour is to add any new plugins on startup, like it or not. > 2 - Split all plugin and extension for distribution as: > > gimp-base.package > gimp-extratools.package > gimp-extrapattern.package > gimp-extrabrushes.package > gimp-extra...etc > Splitting data is easy enough, and there is currently the standard data included in the main tarball, and a data-extras package (in need of update however...). Splitting off other stuff is some what more difficult however, though probabaly more important. Splitting all the plugins into their own module might not be a bad idea (especially if all plugin developers had access to their plugins in the tree). This would help solve the current problems of maintaining plugins in the main distro. Currently, its difficult for core maintainers to keep up with non cvs plugin releases, and vice versa. Especially since that often means two different build systems. And the issue of core maintainers keeping up with the 320,000 lines of code in plug-ins/ is also something that needs to be addressed. Of course, the pro's for keeping them in the main tree is primarily one for users convience (ie, one package to get a useful gimp...). In the end, it might also be easiest just to stick to the current situation. How to split, if they should be split, when/if they should be split... I havent a clue. Anyone else? > So gimp could be small for non-power-user... > Complete for power user with choice > > 3 - menu Xtns > There are a lot of tools.. > In the optic of a graphics designer.. i think that mask all the > server-backend in one windows, a dialogs too, could be useful. > Dont quite follow this... > 4 - macro generator to generate script must have more priority > And an almost complete rewrite. Probabaly not likely to happen any time soon. In the TODO. > 5 - Save / Load Selection > > Save --> save a selection with name > Load --> load, subtract, add selection > > (not direct use of save-to-channel) > shrug. The functionality is there, making it pretty with helper menu entries might not hurt. > 6 - Optimize plugins for the basic and useful operation: > drop-shadow (glue drop-shadow and xach effect.. or other) > glow, addbevel, inner/outer bevel (like eye candy) and putting these > in cvs projects. > eh? > 7 - unify standard text tool and dynamic font plugin > In the TODO. Waiting for code... > 8 - adding text on path.. for string over a curved line. > ditto. Adrian Likins adrian@xxxxxxxx
