Re: [Gimp-developer] moving windows in the git version
On 02/17/2010 08:37 AM, Olivier wrote: > For several weeks now (I compile the git version every Monday), the > windows in normal mode (i.e. multi-window mode) behave in a weird way: I > place them where I want them on one virtual screen, and then I move to > another one virtual screen. When I come back, the windows have moved to > a different place, always the same. Sorry about that, hopefully fixed forever with this commit and a regression test I added: commit 45efd8407938e1f7487b9b372c195aab32a4f90a Author: Martin Nordholts Date: Thu Feb 18 07:21:20 2010 +0100 Bug 608834 - Toolbox and docks move on desktop change Make sure that after we have set GTK_WIN_POS_MOUSE on a dialog created with the dialog factory, it is eventually reset. Also remove the only occurance of the DEBUG_FACTORY define. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Multi-column dock windows and 2.8 schedule" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] UI Proposal for GIMP 2.8 color management
Hi all, this is probably a bit more of outside-the-box thinking than was originally asked for. However, i believe the described user interface enables fairly smooth workflows, so please give it a shot. The approach taken is notably different from the way established applications deal with color spaces, so some reasoning is provided. Without a chance to compensate for the length, a short summary is preprended. At the bottom, a direct reply to the spec [1] is given. regards, yahvuu In short: - Every GIMP composition (aka XCF) has a color profile, the working color space. - The working color space is an image mode, in addition to RGB/grey/indexed. Import: - Open non-XCF: working space = file's color profile if exists; else sRGB. - Open as layers: convert new layer to working space The user can override these default choices immediately after import: http://yahvuu.files.wordpress.com/2009/08/implicit-confirm.png The secondary workflow (non-XCF to non-XCF) supports working with non-managed images. GIMP remembers wether the imported image had a profile attached and adjusts export defaults accordingly. Export: A drop-down selector offers options ranging from "embed full profile" to "don't write a profile". Full version: ** Working Color Space Every GIMP composition has an associated color profile, the working space. The working space is considered an image mode. It can be read off and modified via the Image->Mode menu. Along the lines of: Color profile (sRGB IEC61966-2.1) Info... Assign Color profile... Convert to Color profile... The new menu entry displays the "Color Profile" tab of the "Image Properties" dialog. For new images, the working space can be set in the "new image" dialog or by choosing a suitable template. Other image editors use a preference option to enforce a globally pre-determined working space. Such a policy is very questionable, as 8-bit processing demands the working space to be chosen carefully, dependent on both the image and the task at hand. ** Import It is not possible to do the Right Thing automatically when a bitmap gets imported. Ultimatively, color space handling is an artistical choice. A seemingly pretty well-determined scenario shows why: Say, the current composition is a collage of 20 photos, in sRGB mode. Now via File->"Open as Layers" an AdobeRGB bitmap gets inserted. It seems obvious that the new bitmap should be converted to sRGB. However, if the user plans to desaturate the new layer, assigning sRGB instead of converting would probably be a better choice. And even if a conversion were the right choice, GIMP wouldn't know the desired rendering intent (a very good guess is possible, though). Additionally, in quite some cases the profile detection will fail due to missing EXIF support / proprietary profile tagging schemes (bug #492048). There are two basic scenarios for import: - Open : start a new composition - Open as Layers: insert a new bitmap into an existing composition. In the first case, any desired color space adjustment can be carried out using the Image->Mode commands. In the second case, however, all pre-existing layers would be affected as well by these commands. So there must be a way to manipulate the new layer without deteriorating the rest of the composition. The notorious pop-up solution would be a big kill-joy: http://yahvuu.files.wordpress.com/2009/08/conversion-popup.png in ASCII: "GIMP can't know what to do with the new bitmap": [ ] assign profile XY [ ] convert to profile XY [x] do nothing The problem with that approach is that the user has to confirm even if the default choice is perfectly fine. The solution is to allow the user to adjust afterwards. That could look like following: http://yahvuu.files.wordpress.com/2009/08/implicit-confirm.png The idea is to make the commit implicit: if the user moves on and continues working on the composition (e.g. painting), this means that the choice of color space treatment is accepted. The color space setting can be adjusted interactively, which is an additional bonus. For notifying of invalid profiles or other problems, a warning/info button can be displayed: http://yahvuu.files.wordpress.com/2009/08/conversion-delayed-confirm-warning.png [I hope that something along these lines is feasible.] Note the similarity of this approach with the way a newly pasted layer gets positioned: as GIMP cannot know the desired position, a reasonable default is offered and the user can adjust later on. (Imagine every layer pasting ac
Re: [Gimp-developer] moving windows in the git version
On Wed, Feb 17, 2010 at 7:34 PM, Akkana Peck wrote: > Olivier writes: > > For several weeks now (I compile the git version every Monday), the > windows > > in normal mode (i.e. multi-window mode) behave in a weird way: I place > them > > where I want them on one virtual screen, and then I move to another one > > virtual screen. When I come back, the windows have moved to a different > > place, always the same. > > https://bugzilla.gnome.org/show_bug.cgi?id=608834 > > That also has a workaround, if you want to patch your local version > so you can use gimp in the meantime. > > GIMP remains usable, of course, simply somewhat irritating! With regards to Sven Neumann's comment mentioning "some window managers", the problem occurs with Metacity, although I had the impression it was the reference window manager for GIMP. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
Olivier writes: > For several weeks now (I compile the git version every Monday), the windows > in normal mode (i.e. multi-window mode) behave in a weird way: I place them > where I want them on one virtual screen, and then I move to another one > virtual screen. When I come back, the windows have moved to a different > place, always the same. https://bugzilla.gnome.org/show_bug.cgi?id=608834 That also has a workaround, if you want to patch your local version so you can use gimp in the meantime. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dynamic plugin menu
Am Mittwoch, 17. Februar 2010 15:33:23 schrieb Gena Batsyan: [...] > > I don't think though that the extension mechanism should be used for the > > purpose of being able to install changing menu procedures. It seems like > > quite some overkill to keep a plug-in process running just for this. > > I agree, it's not very clean and is a waste of resources. > > I'd gladly avoid this if there was a clean way for a > plugin to modify it's menu without hanging all the time in memory as an > extension. > > For instance GIMP could introduce an internal procedure one could call > from a plugin that would trigger plugin's query() again. > I think this would be a nice non-intrusive add-on without the need to > modify the API. I wonder if this could not be implemented as an extension then ? Not sure about it, but if an extension can register a callback procedure, then this extension could stay in memory while the plug-in is only loaded when necessary. Of course, your project would then consist of two programs, the extension for handling the dynamic menu stuff and the plug-in itself. Torsten 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] dynamic plugin menu
Sven Neumann wrote: > Hi, > > On Tue, 2010-02-16 at 14:11 +0200, LightningIsMyName wrote: > > >>> "A temporary procedure is a procedure which is only available while one >>> of your plug-in's "real" procedures is running. " >>> >> That is correct - If you will look at line 107 >> http://git.gnome.org/browse/gimp/tree/plug-ins/script-fu/script-fu.c#n107, >> you will see that the plugin is registerd as an extension and not as a >> regular GIMP plugin. On line 217 and 221, the plugin registers itself >> as an extension, and this way it allows itself to run from the moment >> gimp starts up, untill GIMP is exited. >> When registering an extension instead of a "normal" GIMP plugin, the >> run procedure will be called during GIMP's start-up, and the plugin >> will then be able to register temporary procedures (exactly like the >> Script-Fu scripts) that will be available untill GIMP exits. >> > > Just to make this clear. The point of being an extension is not being > run at start-up. You can have that without making your plug-in an > extension. The point of registering as an extension is that your plug-in > will install temporary procedures. If you want to be called at every > startup, you can get that simply by installing an init_proc handler in > the GimpPlugInInfo struct. > > I don't think though that the extension mechanism should be used for the > purpose of being able to install changing menu procedures. It seems like > quite some overkill to keep a plug-in process running just for this. > I agree, it's not very clean and is a waste of resources. I'd gladly avoid this if there was a clean way for a plugin to modify it's menu without hanging all the time in memory as an extension. For instance GIMP could introduce an internal procedure one could call from a plugin that would trigger plugin's query() again. I think this would be a nice non-intrusive add-on without the need to modify the API. Anyone interested to add this functionality to the mainline? Kind regards, Gena > > Sven > > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dynamic plugin menu
LightningIsMyName wrote: Thanks a lot for your help! With a just a little of refactoring I've managed to let the plugin be launched at startup as an extension, and handling procedures as temps. Works great and I could dynamically change the menu items after a procedure has been executed. The only "problem" - the plugin has to be damn clean since it will live as long as gimp does. > Hello Gena, > > I tried to browse the source of the script-fu plugin to answer your > question, and this is what I came up with: > > >> "A temporary procedure is a procedure which is only available while one >> of your plug-in's "real" procedures is running. " >> > > That is correct - If you will look at line 107 > http://git.gnome.org/browse/gimp/tree/plug-ins/script-fu/script-fu.c#n107, > you will see that the plugin is registerd as an extension and not as a > regular GIMP plugin. On line 217 and 221, the plugin registers itself > as an extension, and this way it allows itself to run from the moment > gimp starts up, untill GIMP is exited. > When registering an extension instead of a "normal" GIMP plugin, the > run procedure will be called during GIMP's start-up, and the plugin > will then be able to register temporary procedures (exactly like the > Script-Fu scripts) that will be available untill GIMP exits. > > Just to show you how the script-fu extension continues to run after it > was intialized, look at the list of all the running procedures on your > computer and you should see that as long as gimp is open, there is > also a procedure called script-fu running. > > After creating the temporary procedures with your extension, you can > unregister them using gimp_uninstall_temp_proc, and the register them > again inside another menu. > What I suggested is probably not the best way in the world, but it's > the only way I can think of. > > Hope this helps, > ~ LightningIsMyName > > On Tue, Feb 16, 2010 at 10:27 AM, Gena Batsyan wrote: > >> Hi! >> I've been trying to find a way for a plugin to update menu entries it >> has initially registered from query() via gimp_install_procedure() >> >> When the plugin is being run it wishes to update the menu entries, for >> instance putting some named presets previously selected in the plugin >> interface to be easily and directly accessible from the gimp menu >> without opening plugin interface again. >> >> Is there a way to affect menu entries generated by a plugin after it's >> query() has been called? >> >> I thought maybe using gimp_install_temp_proc instead of >> gimp_install_procedure would do the trick, but documentation says: >> >> "A temporary procedure is a procedure which is only available while one >> of your plug-in's "real" procedures is running. " >> >> What exactly does it mean "while my 'real' procedure is RUNNING"? >> >> gimp_install_temp_proc does also accept the menu spec, so the procedure >> should also be available in menu, but at which times? >> >> Kind regards >> ___ >> 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] moving windows in the git version
Alexia Death wrote: >> windows key + left/right mouse drag still works here. > Is that something that has a chance to work in KDE? yep, i'm running Kubuntu here. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
On Tue, Feb 16, 2010 at 10:59 PM, yahvuu wrote: > Alexia Death wrote: > > AFAIK toolbox size issues are a side effect of the incomplete swm. >> One of the intersting aspects is that since swm does not restore >> properly I can be in swm mode on startup and have a toolbox thats >> frozen in one spot. It cant be stretched and it cant be moved. > > windows key + left/right mouse drag still works here. Is that something that has a chance to work in KDE? -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
Alexia Death wrote: > AFAIK toolbox size issues are a side effect of the incomplete swm. > One of the intersting aspects is that since swm does not restore > properly I can be in swm mode on startup and have a toolbox thats > frozen in one spot. It cant be stretched and it cant be moved. windows key + left/right mouse drag still works here. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
On Wed, Feb 17, 2010 at 10:30 AM, Laxminarayan Kamath wrote: > Something similar here. Using git version. ( max 3 or 4 days old, > current one is somehow not compiling, trying to see whats choking it) > . I took the toolbox and kept it at the right edge (size jsut enough > to keep the tools arranged in two columns). Then minimized and > restored again. It got restored at almost the same position, but the > size was huge, enough to almost cover the screen when i brought the > whole thing into view. AFAIK toolbox size issues are a side effect of the incomplete swm. One of the intersting aspects is that since swm does not restore properly I can be in swm mode on startup and have a toolbox thats frozen in one spot. It cant be stretched and it cant be moved. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
Something similar here. Using git version. ( max 3 or 4 days old, current one is somehow not compiling, trying to see whats choking it) . I took the toolbox and kept it at the right edge (size jsut enough to keep the tools arranged in two columns). Then minimized and restored again. It got restored at almost the same position, but the size was huge, enough to almost cover the screen when i brought the whole thing into view. -- Laxminarayan Kamath Ammembal http://lankerisms.blogspot.com (+91) 9945036093 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
On Wed, Feb 17, 2010 at 6:07 PM, Olivier wrote: > For several weeks now (I compile the git version every Monday), the windows > in normal mode (i.e. multi-window mode) behave in a weird way: I place them > where I want them on one virtual screen, and then I move to another one > virtual screen. When I come back, the windows have moved to a different > place, always the same. > > I'm with Debian testing and GNOME. I can confirm this (although I'm using Arch Linux + AwesomeWM) : I put the toolbox over at the right edge of the screen. When I come back, it's squashed ridiculously narrow near the left edge of the screen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
