On Tue, Aug 10, 2010 at 5:58 PM, LightningIsMyName <lightningismyname@xxxxxxxxx> wrote: > Hello, > > On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts <enselic@xxxxxxxxx> wrote: >> >> > 2. We need to define a "usable" plugin browser. One of the features I'm >> > missing the most, is a preview image. Plugins should have an option to >> > register a preview image of their effect (probably by having the image's >> > binary data embedded in them). This also relates to the feature request >> > of having a logo script browser... >> >> I don't think registering a fixed preview image is good enough, it > > Believe me, I really want a dynamic preview on the current image :-) > But, it's not practical as some plugins take way too long to operate - > trying to create a preview on the current image might take way too > long to be any good. Create the previews in an idle handler (ie. let the user select the operation even when the preview is not rendered, and cancel any pending preview rendering when a selection is made) We could combine this with the stored previews idea: show the stored preview with an overlay that indicates rendering of the preview for the current image is in progress... > > On Tue, Aug 10, 2010 at 3:31 AM, David Gowers <00ai99@xxxxxxxxx> wrote: >> On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName >> <lightningismyname@xxxxxxxxx> wrote: >>> Hello, >>> >>> I recently re-read all the GSoC suggestions for 2010, and I found this >>> interesting one about making the menus searchable: >>> https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility >>> >> The reason I made the description above is that the plugin browser is >> very limited.. you cannot activate non-plugin menu items (for example, >> I'd like to be able to access 'scale image' and 'scale layer' via a >> search -- I don't use them enough to warrant keyboard shortcuts, but >> enough that some acceleration is warranted. >> The same thing goes for virtually all GIMP-GAP operations). > > Sorry for my bad phrasing of the question - let me rephrase it: what > is left other than exposing the searchbox from there? Supporting '*' wildcards would be helpful IMO, but I agree that the shortcuts search is pretty adequate for this, when connected to activating the chosen action. > The searchbox there allows to find non-plugin actions, and these are > very neatly organized under several categories. When you search, the > categories are already expanded so you can see all the results, > organized, right away. That aspect is certainly good. > > What I suggest, it is possible to embed binary data in script-fu > scripts, but it's not easy/fun/simple. What I suggest is that as a > part of the refactoring process of the plugin system, we will allow > procedures to register a "sample" procedure. This procedure will be > called once to generate a preview image. But this procedure is > probably a bad idea (since generating the preview will take time, and > this can be long...) > The other option is to ship example images with script-fu scripts and > to allow them to return a pointer to that image for their preview. > This sounds more reasonable to me. Yes. However IMO, if we do that, we should not stop at previews for script-fu. We should provide a directory for general storage of these previews for any plugins. That way, it is much easier for ordinary users to provide improved previews for their most used plugins. > > One of the things we should remember is that we should still have some > sort of seperation between the plugin/script browser and between the > general procedure browser. Because if we want things like preview for > every action, it would be rather useless to have previews for internal > operations such as "raise layer". Certainly; there are actually four classes of actions: 1. actions owned by plugins, which have a menu item 2. actions owned by the GIMP core, which have a menu item (eg 'Raise layer') 3. actions owned by the GIMP core, which don't have a menu item (eg. 'Increase Aspect') Mostly we will want to search the union of 1 and 2, IMO. And sometimes, we will want to search 3 (eg. I would use this for tweaking the color picker radius, setting the brush scale to default (=1.0)) . That is possible without any need to change current code. I would like to point out anyway, that the PDB browser and the current keyboard shortcut dialog search, search different things... PDB browser searches PDB entries, KB shortcut dialog search searches action internal names+ user-visible names. It's definitely important to make that distinction apparent to the user, so that they don't expect to see PDB entries popping up in the action search box which is the subject of current discussion. David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
