Re: [Gimp-developer] GSOC - Free Transform Tool
Stephen McKeague wrote: what needs sorting out is that after some manipulation the transformation frame can be any kind of shape that can be made out of 4 corners connected by 4 straight lines, including a twisted bow tie type of shape. this general shape is then clipped by the viewport of the image window, which is really a rectangle. This clipped general shape then needs to be manipulated. I still have to investigate what is reasonable for users to be able to do in these situations and how I can make this happen. Yeah, after a perspective change of close to 90deg in any one direction - even if this was actually a mistake - the frame will be rendered unusable because of the low resolution between the different handles. Given that currently you will not be able to undo just part of the overall Free Transform, good point, undo in steps during the use of the tool is on the menu. this may be aggregated for undo too after the tool is left. this will pose a problem (Large shears will exhibit the same behaviour). One possible solution would be that transform frame would only mirror the actual transformation up to a certain threshold. Otherwise the decision could be left to the user to accept (or undo) the current transformation and start a new free transform (and thus new transformation frame). Any update on your thoughts on this? well, this needs UI spec work, for these (valid) edge cases, but that needs to have context of users (when the intent is there) working at a magnification that is workable. but this is hard thinking work and TBD. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] User Friendly Plug-In Browser
Hello, I'm an applicant for GSoC 2010. I got inspired by the menu search idea and proposed the user friendly plug-in browser that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it. Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of? Thanks, Avgoustinos Kadis Proposal: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/avgoustinos/t127081249399 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On 04/10/2010 11:26 AM, Avgoustinos Kadis wrote: Hello, I'm an applicant for GSoC 2010. I got inspired by the menu search idea and proposed the user friendly plug-in browser that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it. Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of? The idea makes complete sense and has been discussed every now and then. There are a couple of requirements that a design would have to fulfil: * The preview calculations needs to support different sources, most notably GIMP legacy core, plug-ins, and GEGL, so a good architecture is necessary * Preview calculations needs to be done in a lazy on-demand manner to make the UI responsive. That is, preview calculations needs to happen outside of the UI thread so one can browse around freely without being forced to wait for previews to finish rendering / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 development still under control ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
I understand (about the good architecture). It should be designed carefully to support all the sources (I was aware only of the plug-ins). Does this object model you use for C allows inheritance? About the preview calculations. I was thinking that it might be faster to pre-calculate all the plug-ins/core/GEGL on 2-3 fixed sample images [300x300] (ex. an apple, a person, a building and a sunset) and store them on the user's machine. Each time he opens this feature browser, if there is a new feature without a sample image, it'll be calculating it and storing it on hard disk. It should still happen in a separate thread of course but I think it would speed up things. What do you think about it? Avgoustinos On Sat, Apr 10, 2010 at 11:00 AM, Martin Nordholts ense...@gmail.com wrote: On 04/10/2010 11:26 AM, Avgoustinos Kadis wrote: Hello, I'm an applicant for GSoC 2010. I got inspired by the menu search idea and proposed the user friendly plug-in browser that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it. Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of? The idea makes complete sense and has been discussed every now and then. There are a couple of requirements that a design would have to fulfil: * The preview calculations needs to support different sources, most notably GIMP legacy core, plug-ins, and GEGL, so a good architecture is necessary * Preview calculations needs to be done in a lazy on-demand manner to make the UI responsive. That is, preview calculations needs to happen outside of the UI thread so one can browse around freely without being forced to wait for previews to finish rendering / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 development still under control ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On 04/10/2010 01:03 PM, Avgoustinos Kadis wrote: I understand (about the good architecture). It should be designed carefully to support all the sources (I was aware only of the plug-ins). Does this object model you use for C allows inheritance? GIMP uses GObject which supports inheritance. About the preview calculations. I was thinking that it might be faster to pre-calculate all the plug-ins/core/GEGL on 2-3 fixed sample images [300x300] (ex. an apple, a person, a building and a sunset) and store them on the user's machine. Each time he opens this feature browser, if there is a new feature without a sample image, it'll be calculating it and storing it on hard disk. It should still happen in a separate thread of course but I think it would speed up things. Always using the same images is the easy way, using it on the current image is the harder but better way. If you go for the easy way I think you should plan for introducing the hard way later, just to make sure that the solution scales. / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 development still under control ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible Future of ScriptFu/TinyFu: visual editors, action framework, sequences
I have posted a Make shortcut plugin to the Gimp Registry. It lets a user choose from a view of the menu tree of plugins, to create a new plugin (a script) that is a shortcut to a target plugin. It is very rudimentary, but could be extended into a visual editor of sorts, to create named sequences of actions. The visual editor (proposed here as a GSOC project: http://archives.free.net.ph/message/20100325.130320.3246ef1c.en.html ) seems too ambitious. Sequences are enough, represented by lines of text for menu items. Graphical pictures of flowcharts is not necessary, at least as a start. (A UNIX perspective: text is enough.) One problem is that the PDB does not give access to default parameters of plugins. It seems that defaults are maintained by the individual plugins, not by the PDB. I am not sure there is even a convention for storing default parameters. I saw one C-language plugin that stored default in the data attribute of PDB procedures. Pygimp plugins seem to store defaults using Python shelf. I haven't explored how Scheme scripts store defaults. A user of a visual editor would want the defaults. Another problem is that other menu items in GIMP (not plugins) are not exposed by the PDB. I have just started to explore, but it seems the actions (sequences) of other menu items in Gimp might be exposed in the XML for the other menus of Gimp. It would be much easier to create a visual editor if there was a uniform API for determining the actions of all Gimp menu items (not just the plugins.) I am not familiar with the action framework. I would appreciate a link. As to the implementation language, Python seems OK: plenty of support, portable, high level, objects. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
If using the current image will be better (more desired by the user) then we could focus on this one and find ways (multiple threads, resize before applying the plugin etc) to make it fast. It sounds more challenging this way :) Great! Thanks, Avgoustinos On Sat, Apr 10, 2010 at 1:55 PM, Martin Nordholts ense...@gmail.com wrote: On 04/10/2010 01:03 PM, Avgoustinos Kadis wrote: I understand (about the good architecture). It should be designed carefully to support all the sources (I was aware only of the plug-ins). Does this object model you use for C allows inheritance? GIMP uses GObject which supports inheritance. About the preview calculations. I was thinking that it might be faster to pre-calculate all the plug-ins/core/GEGL on 2-3 fixed sample images [300x300] (ex. an apple, a person, a building and a sunset) and store them on the user's machine. Each time he opens this feature browser, if there is a new feature without a sample image, it'll be calculating it and storing it on hard disk. It should still happen in a separate thread of course but I think it would speed up things. Always using the same images is the easy way, using it on the current image is the harder but better way. If you go for the easy way I think you should plan for introducing the hard way later, just to make sure that the solution scales. / Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 development still under control ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On Saturday 10 April 2010 19:46:44 Avgoustinos Kadis wrote: resize before applying the plugin That's an important point anyway, since many plugins are not scale invariant. So maybe cropping into a relevant region may be more appropriate in some cases. Just my 2¢ worth of thoughts, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On Sat, 2010-04-10 at 10:26 +0100, Avgoustinos Kadis wrote: I'm an applicant for GSoC 2010. I got inspired by the menu search idea and proposed the user friendly plug-in browser that would allow users to find the plug-in they want by seeing the effect on an example image. The whole thing is to browse through images rather than through text. The reason is that the names of plug-ins say nothing to many of the users (including me) and they hesitate to try them. But by seeing the effect of the plug-in they will be more willing to use it. Could you please give me some feedback on my proposal? I would like to know if this idea is feasible. Are there any aspects I didn't think of? I think the idea is nice, but very hard, if not impossible, to implement. All plug-ins have a number of parameters and the output depends a lot on the values chosen for these parameters. That makes it very hard to automatically create reasonable previews of all filters. Also the PDB currently does not support default parameters, so there is no way to automatically select reasonable default values for plug-ins. The user friendly plug-in browser would have to have a hard-coded data-base of parameters. That would be a pain to maintain. IMO it makes much more sense to concentrate on selecting plug-ins based on a search in their names, descriptions and help texts. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] wiki down...
On Mon, 2010-03-29 at 21:41 -0400, Liam R E Quin wrote: On Mon, 2010-03-29 at 21:53 +0200, peter sikking wrote: I would be happy if Liam could host it. he seems to have the most direct control over his server. I can try to install mediawiki this week (don't expect a problem, the server is running centos linux it's packaged) and then I'll ask Sven for the backups. I got the backups from Sven and tried restoring them at Easter, using the version of mediawiki that was running before, and ran into problems restoring the SQL dump, but at that point I'd already spent a day on it. I do have the wiki running, but it doesn't see the data. I hope to have another day for it next weekend. Anyone with postgresql and mediawiki experience is welcome to contact me to help it go faster! Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
