Re: [Gimp-developer] Where to post rotate brushes bugfix?
On Fri, Sep 25, 2009 at 11:42 PM, Tal ta...@inbox.com wrote: I found and solved a new bug in the bilinear rotate transform algorithm that sometimes caused artifacting on brush edges for brushes rotated 90, -90, -180, 180 degrees. Since the previous bugzilla report http://bugzilla.gnome.org/show_bug.cgi?id=520078 is marked as fixed, what is the best way to proceed and submit the patch? Should I upload the patch to the existing 520078 bug report or is it worth creating a new bug report just for this bugfix? Thanks, Tal Creating a new bug wit the patch would be best I think ;) -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where to post rotate brushes bugfix?
On Fri, 2009-09-25 at 12:42 -0800, Tal wrote: I found and solved a new bug in the bilinear rotate transform algorithm that sometimes caused artifacting on brush edges for brushes rotated 90, -90, -180, 180 degrees. Since the previous bugzilla report http://bugzilla.gnome.org/show_bug.cgi?id=520078 is marked as fixed, what is the best way to proceed and submit the patch? Should I upload the patch to the existing 520078 bug report or is it worth creating a new bug report just for this bugfix? That's good news, please open a new bug for it! thanks, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
Jon A. Cruz wrote: I think I might have one that can count as subtly different. Working on a prime image and drawing pieces, reference, etc from other images. Especially since I tend to think spatially, this is one I do a lot. I also tend to combine this workflow with others you have already listed. is this 'compare and reference' as fully covered by the polaroids? --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
Re: [Gimp-developer] Peter's single-window proposal
Citing a passage regarding the image parade on Peter Sikking's blog post: What I find very intriguing is that the notion of which file is open starts to blur. Having a file being loaded from disk becomes a side effect of clicking it to make it the current file. Similarly GIMP can decide to start closing files with no unsaved changes when there are too many of them open and memory gets tight. My current thinking is that it is not necessary to mark files in the parade as being open. The concept quasi disappears for users. The white stars indicate unsaved changes. It should be noted that many plug-ins and filters provide dialogs in which the user is prompted (via drop-down lists) to select images/layers/channels/paths from amongst those available in currently opened images. It would seem unwieldy for the code to have to open previously closed files to search for these potential images/layers/channels/paths every time such a dialog is presented (and the resulting drop-down lists could contain LOTS of entries in which the user holds no interest). Thus it may be necessary to retain the concept of opened images and provide a means of distinguishing unopened images in the image parade (if they are to be included). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Can I have tabs and Apply button in the plugin GUI?
Dear developers, Can someone tell if this GUI design is possible? http://pastebin.com/m1ccbcd06 The reason I would like to have tabs is because of the work flow, and the values in the Modify tab will be different depending to the loaded audio[0] file. If tabs is possible, can I also have the Apply button? And if so, will the Apply button apply changes to all tabs or just the active tab? Hugs, Louise [0] The user loads audio files, and the plugin convert it to graphics/spectrogram. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
/ For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking // about: URL. / Eeek, here is the missing URL: http://curlyankles.sourceforge.net/widgets_docking.html Alexandre Hello, I think the term single-window mode is potentially confusing. It's how you dock the windows together that gives the user the *perceived* single-window or multiple-window mode. If implemented correctly the user that prefers a multiple-window mode gimp wouldn’t see much difference from the existing gimp version to a gimp version that supported a single-window mode. Maybe after an install the gimp could start with a window layout (docking schema) that mirrors the existing multiple-window gimp layout; the user could then dock/group together whatever undocked/floating/torn (terminology???) window he wanted; therby creating his own single-window mode gimp. This was one of the goals I was trying to achieve whilst writing the curlyankles library; as I could see merits in both multiple and single window layout strategies; without having to tie a user into either. How could I know how someone else wanted to work? Therfore IMHO if implemented correctly single-window and multiple-window gimp modes could both coexist together. Regards Cole ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where to post rotate brushes bugfix?
On 09/28/2009 10:06 AM, Michael Natterer wrote: On Fri, 2009-09-25 at 12:42 -0800, Tal wrote: I found and solved a new bug in the bilinear rotate transform algorithm that sometimes caused artifacting on brush edges for brushes rotated 90, -90, -180, 180 degrees. Since the previous bugzilla report http://bugzilla.gnome.org/show_bug.cgi?id=520078 is marked as fixed, what is the best way to proceed and submit the patch? Should I upload the patch to the existing 520078 bug report or is it worth creating a new bug report just for this bugfix? That's good news, please open a new bug for it! There is one already: https://bugzilla.gnome.org/show_bug.cgi?id=596472 / Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I have tabs and Apply button in the plugin GUI?
On 09/28/2009 02:21 PM, Louise Hoffman wrote: Dear developers, Can someone tell if this GUI design is possible? http://pastebin.com/m1ccbcd06 The reason I would like to have tabs is because of the work flow, and the values in the Modify tab will be different depending to the loaded audio[0] file. If tabs is possible, can I also have the Apply button? And if so, will the Apply button apply changes to all tabs or just the active tab? Hugs, Louise Hi Louise Yes it's possible, you can create any GTK+ interface in plug-ins. To get tabs you'd use GtkNotebook. You can hook any code to an Apply button, including code that takes the active tab into account. Hugs, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I have tabs and Apply button in the plugin GUI?
Yes it's possible, you can create any GTK+ interface in plug-ins. To get tabs you'd use GtkNotebook. You can hook any code to an Apply button, including code that takes the active tab into account. Hi Martin, Thank you very much for the detailed answer. That is just perfect =) Can I ask another question? Right now when I start GIMP, all plugins can not be opened, because there is no canvas. Once the user have defined an image size in File-New all the plugins become available. Is it possible that my plugin can be opened without a canvas? The reason for this is, that it would be very convenient if the user could set image size in the plugin, and once the user presses Apply, GIMP creates the canvas. Can that be done? And if so, do you have a link to the API's that allow me to do that? Hugs, Louise ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Cole wrote: I think the term single-window mode is potentially confusing. It's how you dock the windows together that gives the user the *perceived* single-window or multiple-window mode. well, if I have to formulate it, then single-window is users' preference for a flat working surface, where nothing overlaps. Multi-window is a staggered environment. one thing is bugging/intriguing me and that is the (single) point where single-and multi-window 'lines cross'. That is when one image is open and for single window toolbox and inspector column(s) have been torn off. Forgetting the parade for a moment, single-and multi-window look the same in that situation. It is tempting to think that from there users can 'just go in four directions,' by opening a tab, a new window, docking toolbox or inspector column(s). that is just 3 directions, because exactly docking on a multi-window environment is not a viable route afaics, docking global stuff to image instances. But I said forgetting the parade for a moment because that exactly points at the kind of UI optimisation that can be done if it is known whether a flat or staggered environment is the goal. I'll also be damned to double a number of menu items because the result could be a new window or a new tab. this now works automatic according to the single-window mode setting. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
saul goode wrote: Citing a passage regarding the image parade on Peter Sikking's blog post: What I find very intriguing is that the notion of which file is open starts to blur. It should be noted that many plug-ins and filters provide dialogs in which the user is prompted (via drop-down lists) to select images/layers/channels/paths from amongst those available in currently opened images. It would seem unwieldy for the code to have to open previously closed files to search for these potential images/layers/channels/paths every time such a dialog is presented (and the resulting drop-down lists could contain LOTS of entries in which the user holds no interest). Thus it may be necessary to retain the concept of opened images and provide a means of distinguishing unopened images in the image parade (if they are to be included). you are pointing out a serious spanner in the works. and if I do not find a way to houdini me out of that one, then that will be it for fuzzy... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I have tabs and Apply button in the plugin GUI?
Yes, just pass NULL to the image_type argument to gimp_install_procedure() [1] That's how file plug-ins and plug-ins under File - Create for example is able to run without any image opened. That's much better than I expected =) I will start on that tomorrow. Thanks a lot =) Hugs, Louise ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
On Monday 28 September 2009, saulgo...@flashingtwelve.brickfilms.com wrote: It should be noted that many plug-ins and filters provide dialogs in which the user is prompted (via drop-down lists) to select images/layers/channels/paths from amongst those available in currently opened images. It would seem unwieldy for the code to have to open previously closed files to search for these potential images/layers/channels/paths every time such a dialog is presented (and the resulting drop-down lists could contain LOTS of entries in which the user holds no interest). The point when the user can choose the desired other image does not require the full image, a name + thumbnail is all that's shown with the current implementation. If this requirement doesn't change, I don't see a problem. The thumbnails are there for the gallery anyway and the drop-down list could be just another instance/view of the very same gallery, maybe. Real access to the relevant image's content is only done when it's needed. And the gallery's entries would be in roughly chronological order wrt the last showing time anyway, I suppose. Cheers, 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
