Somehow I lost focus on what i had suggested earlier... Lazy loading apart, can we bring up the windows and allow new file creation or importing files, while the brushes get loaded in the background?
On Fri, Dec 9, 2011 at 2:49 PM, Alexia Death <[email protected]> wrote: > On Fri, Dec 9, 2011 at 2:38 AM, Ofnuts <[email protected]> wrote: > > IMHO the problem is more with the current single-level display of > brushes. > > Gimp will look in subfolders of the declared folders, but it should allow > > some hierarchical navigation as well. The current interface must have > been > > designed when the designers thought that 100 brushes would be plenty.. > They > > were right on one point: the resulting interface is very hard to use with > > more than 100 brushes. > Tagging tries to relieve that... There is a very recent patch in > master that adds subfolders into the tag cloud. but yeah, it wont cure > the loading slowness. > > > And once you have a hierarchical navigation, you only need to load the > > brushes from the current brush folder. > You wont get around lazy loading with that. Tool presets have brushes > saved in it. What should happen if the preset's brush or gradient or > whatever isn't in the current set? What if a script refers to a brush > that isn't currently active? Nothing is ever as simple as it looks. > There is a lot of interdependency among various bits of gimp and > sometimes gimp-s aim for stability complicates matters as well. Gimp > has had brush scaling for ages now, and we still have gazillion round > brushes, no longer visible in UI but still present, because scripts > may make use of them. > _______________________________________________ > gimp-developer-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- * Regards, * *Srihari Sriraman *
_______________________________________________ gimp-developer-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gimp-developer-list
