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. 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 >> >> As far as I know, menus are searchable and the best example is the keyboard >> shortcuts dialog which has a searchbox to find the GIMP action you'd like to >> use. > > However, that action is not immediately activateable. > What I personally envision is something like the completion dialog > that you can find in GTKTreeViews (for example, typing something in > when the file list in a file selection dialog is focused, offers you a > choice of the possible items. And upon selection from that sub-list, > the file is immediately chosen.) > > So I asked on #gimp and I was told there was a discussion on IRC about >> finding a more usable replacement to the plugin browser. > > 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? 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. On Tue, Aug 10, 2010 at 3:31 AM, David Gowers <00ai99@xxxxxxxxx> wrote: > request of >> having a logo script browser... > > Well, if we did what you outline here, how would Script-Fu scripts > handle the necessary embedding of binary data (I don't mean to imply > that they couldn't, just that I do not know exactly how well they can > handle this kind of binary string literal). 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. 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". ~LightningIsMyName _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
