Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I don't really see the value in having the loupe possess both the magnified view and the focus view. Several good points have been brought up The handle must be shorter and translucent (why not just eliminate the handle?) ... How will the tool behave at the window limits (with no handle, this becomes trivial)? As long as it is a simple matter to toggle the loupe on and off via keystroke so that you don't have to take your eyes off of the screen area of interest, I think doing so would allow the user to still stay grounded in the macroscopic while working in the microscopic without the need for the handle and focus view. I also had one other thought I'd like to share ... I think it would be very convenient for the Shift+mouse wheel zoom feature to apply to the loupe window when the loupe is visible. This would allow a quick means of changing the loupe magnification without having to look anywhere else on the screen or take your hand off of the mouse. It also makes sense because if shift+mouse wheel does not apply to the loupe, using it may cause the area of interest to move out of the window altogether, requiring the user to pan/scroll the window back. Even if the shift+mouse wheel zoom is centered on the loupe, other areas of interest might be moved out of the window. For example, if adding catch lights to a person's eyes, you might want to be able to see both eyes in the macroscopic view to make sure that the size and position of the lights is the same. If you have already done the left eye and are currently using the loupe on the right eye, a shift+mouse wheel zoom that applies to the entire window or is centered on the loupe might cause the left eye to move out of the macroscopic window. A startup tip should also be written to present instructions for using the loupe. --- peter sikking [EMAIL PROTECTED] wrote: Sven wrote: I am not sure if Sven wants another feature request in bugzilla. If so I will write it. Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports. just checking, because of: I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. then saul wrote: I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Indeed, the handle of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). my thanks for you and the 'puter, again. Firstly, there is an effective warping of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). the last point is exactly how it works (also for humans) and means no HIG felonies. Nonetheless, this behavior can be disorienting. It should be noted that the overly-long handle shown in the simulation exaggerates the severity of this problem. the point of my 'must be close, but out of the way' guiding principle. More important is the general nature of the tracking of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port). that is at the user's discretion. I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. excellent point. since the point of the loupe is working precise, the mouse must move at the speed of the zoomed view. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. your solution really got me thinking. there are multiple other alternatives. at the end it is about having the most stable, predictable loupe placement, and technical feasibility. The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. well, if you want
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven Neumann wrote: Wouldn't it be easier if you could quickly zoom in (and back out again to the previous zoom level) without having to open a new view for this? In the SVN version you can already revert to previous zoom level. What's the point of doing this in a separate window? Sorry for such a late reply. I like to use a different view to make precision adjustments because it means that I can have both scales visible simultaneously and can see how my changes look at normal scale while I'm making them. Davidm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Tue, 2007-03-20 at 18:01 +0100, peter sikking wrote: I am not sure if Sven wants another feature request in bugzilla. If so I will write it. Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports. I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. For someone who isn't deeply involved with GIMP development, it seems impossible to find out what would be important to work on or even to get an idea of the direction that GIMP is taking. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
WARNING TO DIALUP USERS! The GIF file linked to in this post weighs in at 2.2Mb. Quoting peter sikking [EMAIL PROTECTED]: saul on the irc made this film (thanks): http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change. I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Indeed, the handle of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). The red dot which I employed in the zoomed porthole of the loupe would be replaced by a cursor/outline representing the active tool (but my main concern was with the relative motions of the different elements). Personally, I am not that enthusiastic about the proposed loupe gadget's interface and consider a dockable tracking view to offer a better solution. It is not a firm aversion to the loupe but more just reservations about the comfort of its use. I would not discourage anyone from actually producing a test implementation. Firstly, there is an effective warping of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). Nonetheless, this behavior can be disorienting. It should be noted that the overly-long handle shown in the simulation exaggerates the severity of this problem. More important is the general nature of the tracking of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port). I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. This assumption may be faulty but it would seem that if you are zoomed in at 10X and the mouse inputs are not scaled appropriately then you will experience difficulty with positioning of the tool within single-pixel precision (in the zoomed port). If sub-pixel mouse resolution is high enough than the loupe could track the mouse 1:1 and the image in the zoomed port could track it at 10X the speed (or whatever the zoom factor is set at) -- I don't believe this to be the case. The simulation shows a 4X zoomed version of the image in the larger port. Based on the preceding assumption, the movement of the loupe itself would become 1/4th the movement of the mouse pointer when the loupe is not invoked. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. Within the large port, this behavior of mouse movement not resulting in movement of the pointer, but in the scrolling of the image behind it is somewhat non-standard (excepting for traditional cases where a pointer butts up against a window border, resulting in scrolling of a view window). While there are certainly similar loupe gadgets present in a few other programs, the only ones I have encountered are more interested in _viewing_ things at a microscopic scale and not actually _working_ at that level. I am suspicious that the more intense focus of the user entailed will exascerbate the disparities in the screen response to mouse movements. For a dockable tracking view, I would suggest the following be considered for incorporation into its implementation: 1) The view always tracks the cursor when the cursor is over the image window. 2) That the display (outline, mask, etc) of the active tool within the tracking view be optional. 3) That a modifier key would switch mouse input scaling to match the zoom factor of the tracking view. 4) That when the modifier key is depressed, a rectangular outline appear in the image window indicating the bounds of the tracking view (and that the mouse scaling mentioned in 3) is active. P.S. My apologies if this appears twice on the list. My first attempt to submit it did not seem to work. ___
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
I think that the user should be able to select between a 1:1 mouse resolution scale and one that matches the scaling of the loupe's zoom. This would be good to offer at least on any test version that is developed, until enough user feedback is obtained to eliminate one of the options. --- [EMAIL PROTECTED] wrote: I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. This assumption may be faulty but it would seem that if you are zoomed in at 10X and the mouse inputs are not scaled appropriately then you will experience difficulty with positioning of the tool within single-pixel precision (in the zoomed port). If sub-pixel mouse resolution is high enough than the loupe could track the mouse 1:1 and the image in the zoomed port could track it at 10X the speed (or whatever the zoom factor is set at) -- I don't believe this to be the case. The simulation shows a 4X zoomed version of the image in the larger port. Based on the preceding assumption, the movement of the loupe itself would become 1/4th the movement of the mouse pointer when the loupe is not invoked. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven wrote: I am not sure if Sven wants another feature request in bugzilla. If so I will write it. Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports. just checking, because of: I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. then saul wrote: I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Indeed, the handle of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). my thanks for you and the 'puter, again. Firstly, there is an effective warping of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). the last point is exactly how it works (also for humans) and means no HIG felonies. Nonetheless, this behavior can be disorienting. It should be noted that the overly-long handle shown in the simulation exaggerates the severity of this problem. the point of my 'must be close, but out of the way' guiding principle. More important is the general nature of the tracking of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port). that is at the user's discretion. I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. excellent point. since the point of the loupe is working precise, the mouse must move at the speed of the zoomed view. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. your solution really got me thinking. there are multiple other alternatives. at the end it is about having the most stable, predictable loupe placement, and technical feasibility. The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. well, if you want to see the spec of dust to the top-left of your current view better, you move the mouse top-left, and you see the spec of dust centred. sounds good to me... While there are certainly similar loupe gadgets present in a few other programs, the only ones I have encountered are more interested in _viewing_ things at a microscopic scale and not actually _working_ at that level. I am suspicious that the more intense focus of the user entailed will exascerbate the disparities in the screen response to mouse movements. we really will have to work hard to make this reach the transformative potential it has. Working with it is the highest goal. --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
On 3/19/07, Sven Neumann [EMAIL PROTECTED] wrote: We aren't using cairo yet. But I don't see what you would want to use gdk_draw_drawable() for. OK - I have more to learn! app/dialogs/dialogs.c, IIRC Thanks. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Chris, First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. don't worry, I am also fired up about this one. here is why: people have talked to me a week or more ago on the irc along the line of: what's the big deal, one way or another will do. here is the big deal: for my pov the dockable magnifier is just-another-feature, it will make some people happy in some situations. the pop-up loupe however, has the potential to be a transformational feature. It has the potential (when properly designed) to fully transform the way most people work with GIMP in work-macroscopic/change-microscopic situations, that go way beyond the mentioned setting selections pixel-precise. saul on the irc made this film (thanks): http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change. I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. practically speaking, this will have to wait for cairo, and I see you are already off the mark. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. I am not sure if Sven wants another feature request in bugzilla. If so I will write it. --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
Peter, I'm glad you've become the ambassador for this. Your description of a loupe is basically what I was proposing in my original bugzilla proposal #409802 ( http://bugzilla.gnome.org/show_bug.cgi?id=409802 ). Rather than add another proposal, why not just flesh out the details of your vision on that bug report? I hope enough others agree that this will dramatically change the way work is done in GIMP to make this a reality. . Mark --- peter sikking [EMAIL PROTECTED] wrote: Chris, First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. don't worry, I am also fired up about this one. here is why: people have talked to me a week or more ago on the irc along the line of: what's the big deal, one way or another will do. here is the big deal: for my pov the dockable magnifier is just-another-feature, it will make some people happy in some situations. the pop-up loupe however, has the potential to be a transformational feature. It has the potential (when properly designed) to fully transform the way most people work with GIMP in work-macroscopic/change-microscopic situations, that go way beyond the mentioned setting selections pixel-precise. saul on the irc made this film (thanks): http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change. I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. practically speaking, this will have to wait for cairo, and I see you are already off the mark. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. I am not sure if Sven wants another feature request in bugzilla. If so I will write it. --ps principal user 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 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 3/4/07, Sven Neumann [EMAIL PROTECTED] wrote: But yes, the most obvious and by far the easiest solution is to add a tracking view that users can add to their docks similar to the Navigation dialog. I've filled out a feature request based on this approach. I've also taken initial steps to implement it, but I have some questions ;) 1. gdk_draw_drawable - should this be used, or dropped in favor of cairo/gnomecanvas/other? 2. adding a new widget was pretty straightforward, but mine is still missing the icon in the tab, and I see this in the terminal: gimp_menu_factory_manager_new: no entry registered for Magnifier. My grep-fu isn't working - where does one reference the icon/menu item? Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Mon, 2007-03-19 at 04:06 -0500, Chris Mohler wrote: 1. gdk_draw_drawable - should this be used, or dropped in favor of cairo/gnomecanvas/other? We aren't using cairo yet. But I don't see what you would want to use gdk_draw_drawable() for. 2. adding a new widget was pretty straightforward, but mine is still missing the icon in the tab, and I see this in the terminal: gimp_menu_factory_manager_new: no entry registered for Magnifier. My grep-fu isn't working - where does one reference the icon/menu item? app/dialogs/dialogs.c, IIRC Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. Finally, I'm looking at the latest SVN to see if this is a project that's within my abilities. It looks like a lot of the code that's needed already exists and just needs to be extended into a new dialog - pointers/pitfalls welcome. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven wrote, GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. easiest to implement, yes. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up. Again, I have nothing against a tracking view with a different magnification than the main window. But it does not solve most of the use cases that came up in this thread, only the exceptional ones Raphael came up with. Let's look at a couple of aspects: affordance: I see a lot of value in supporting work macroscopic, adjust/paint microscopic. there is a lot more than selections that can benefit from this. That is why I find it a pity to solve it in a way that can only be afforded by users with seriously big screens. I would like everyone with smaller than 1600x1000 screens to look at their GIMP set-up and figure out where to put an extra 200x200 view. I am on 1280x854 and would not know where to put it. This is what I mean with 'the cost is too high to have it open all the time.' closeness: Experiment for everyone: move your mouse cursor dead centre of your screen. Focus your eyes on it. Now look quickly at one of the corners of your screen (where the permanent view would sit). If you did not turn your neck, you strained your eyes. Is this supporting working swiftly, at a pro's pace? Do you want to strain yourself like that all day? Now compare this to focussing on the dead centre mouse cursor, and quickly looking at an area beside it. Quicker and painless, no? This is what I mean with 'it has to be close (but out of the way) in order to support working swiftly.' size matters: The permanent dialog has to be compromised in size, exactly because it is permanent. 200x200 is a lot of pixels in this context. A pop-up loupe however, can easily be 400x400, showing a lot more image data at the moment that is is needed. final plea: Again, I have nothing against a tracking view with a different magnification than the main window. But is you want to make a real, substantial and general improvement in GIMP and support work macroscopic, adjust/paint microscopic, then a pop-up loupe is the way to go. It is a cool cairo project, and I'd be happy to specify it. --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
Here is the feature request (as I see it): distill away. Magnifier: (Needs a better name - spy glass, super loupe?) The maginfier provides the ability to see an up close view of the area immediately surrounding the cursor, in a manner that does not interfere with the current view of the image. The center of the up-close view represents the cursor, the image scrolls' past the center of the up-close view as the cursor moves across the image. In case that's clear as mud: the cursor is fixed in the magnifier view, and only the image data moves. (Think of the bombsight on a war plane) A static magnifier could be added to the navigation dialog[1], below the current image map, and small in size. Additionally, a command or shortcut could be applied to pop-up (and banish) a magnifier. Both the static and pop-up magnifier should have a simple plus or minus zoom setting[2], and possibly a text entry for percentage. In short, the main purpose of the tool would be to provide a precision view of the cursor when making selections[3] that are too large for the image window when zoomed in - removing the need to zoom in and out multiple times while making a selection, therefore making workflow easier. Chris [1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new info dialog similar to PS, in which the color values under the cursor are reported, along with selection size, tranform values, etc. Most of this info is reported already in the status bar though. [2] Another shortcut for zooming the magnifier? [3] A suggestion was made to tie the magnifier to the selection tools, but it seems that a magnifier could also prove useful when performing other operations besides selections. Moving a selection for example: one could grab the selection at the very edge and watch for alignment with a particular area (in the magnifier), while still being able to see the overall layout. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Sun, 2007-03-04 at 12:53 -0600, Chris Mohler wrote: [1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new info dialog similar to PS, in which the color values under the cursor are reported GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 3/4/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-03-04 at 12:53 -0600, Chris Mohler wrote: [1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new info dialog similar to PS, in which the color values under the cursor are reported GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up. Wow. Until today, I had overlooked the 'pointer' dialog. D'oh! Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Sun, 2007-03-04 at 15:01 -0500, [EMAIL PROTECTED] wrote: It would seem to me that, depending upon how it were implemented, a view window with tracking capabilities might be sufficient to meet the needs of the user without having to resort to the implementation of a new tool. I don't think anyone suggested making this a new tool. If it was a tool, you couldn't use other tools at the same time. That would render it almost useless. But yes, the most obvious and by far the easiest solution is to add a tracking view that users can add to their docks similar to the Navigation dialog. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi Gimpers, allow me to join the brainstorm. As the loupe tool seems to be most useful for making pixel-perfect selections while retaining a global view on the image, what if the selection tools provided that functionality? When creating or resizing selections, the loupe would show up after holding the mouse button for a certain amount of time, automatically. Alternatively it could be a checkbox in the tool's preferences. I also believe the preview is more useful being rectangular rather than round. cheers -- Jakub Steiner [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On Sun, 25 Feb 2007 21:01:47 +0100, peter sikking [EMAIL PROTECTED] wrote: Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale. I would like to know why you state that the user requirements include showing for a _moment_ what you are doing at high magnification. If the view of the zoomed-in area does not overlap the normal work area, some users may be equally interested in seeing at all times what they are doing at high magnification so that, for example, they could detect any unusual details that are not visible at a smaller scale. Or they could be interested in seeing the high magnification area at many moments that are relatively close to each other in time so that, for example, they could precisely adjust several points in a path or iscissors curve. To me, the argument that the zoomed-in area should only be displayed for a brief moment is far from obvious. I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way. everything speaks for a key-triggered loupe. Again, this is far from obvious. You state that it always needs to be out of the way but there is no real way to ensure that it is _always_ out of the way, except by letting the user position some window in advance (which then speaks against a key-triggered loupe). Otherwise, there is no way for GIMP to predict what area close to the mouse pointer is a safe area that the user is not interested in. The user may still be interested in some context around this area in order to be able to align things, repeat some pattern, etc. during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way. You assume that focusing on the detail means that the user lost interest in the context. This is not always the case. If you do not let the user position the high magnification area (as would be possible with an auto-tracking view), then the key-triggered loupe would probably have to support a combination of modifiers so that the user can tell GIMP: no, don't pop it up somewhere above my mouse pointer, but rather somewhere in the lower left corner, or somewhere far to the right. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Mark Lowry wrote: Good point. A GIMP magnifier such as we are discussing should magnify the actual image, not just the desktop portrayal of the image. Yes of course. Sorry not to have explicitly written this. If a second, stationary window is used rather than a moving lens, I would suggest that it should have its own buttons for controling the magnification level. also the temporary loupe can have its own zoom level and also I will give it an option to work absolute (to the image data) or relative (to the zoom level in the actual image window). This means you can set it to display the image data at 400%, or 400% of the window level (window is at 33%, result in the loupe is 132%). And all this of course not far away in the preferences, but there when the loupe is there. A few people here seem to favour a permanent loupe window because it would not cover the main image. Now let me first say that additional view windows (different from the cloned main window that the GIMP already had now) tracking the mouse pointer, already have been identified as a requirement in our UI evaluation. These however, do not solve the problem we got here. Now, a permanent loupe window does cover the main window, in a way. It simply eats screen real estate. Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale. I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way. everything speaks for a key-triggered loupe. during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way. the next moment when one is focussed on the macroscopic image, the loupe is gone, taking no screen real estate. gg: mouse wheels are not universally available, so they can never be part of the primary solution. Like second monitors, they are extras, and we provide extra UI and shortcuts to help the people who have them, and actually like them. --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. like this? http://www.creativepro.com/img/story/20051219_fg5.jpg assigned to a spring-loaded key (push down: magnifier appears, release: disappears). Settings need to be adjustable on the fly, hmmm. magnified area can stay out of the way automatically, without jumpy behaviour, like magic. --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
I was thinking more like this ... http://pic20.picturetrail.com/VOL66/86790/6669793/233033597.jpg --- peter sikking [EMAIL PROTECTED] wrote: Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. like this? http://www.creativepro.com/img/story/20051219_fg5.jpg assigned to a spring-loaded key (push down: magnifier appears, release: disappears). Settings need to be adjustable on the fly, hmmm. magnified area can stay out of the way automatically, without jumpy behaviour, like magic. --ps principal user 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 Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On Saturday 24 February 2007 14:12, Mark Lowry wrote: I was thinking more like this ... http://pic20.picturetrail.com/VOL66/86790/6669793/233033597.jpg Hello, I have to admit that this is a great idea. But I think it is better to have both normal and magnified view at the same time, because it can be hard to follow an edge or to see the global aspect if the magnified view hide the normal view. My 0.02 euros... -- Frédéric http://www.gbiloba.org pgpi5ZC8ZtXib.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 2/24/07, Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. This could be accessed, for example, by pressing SHIFT+Z, upon which a small window would open up and display the area around the cursor. The window that pops up could have some check boxes for the amount of magnification to be used (1x, 2x, 3x, 5x, etc.). I really _miss_ this feature! One of the things I do all the time, is selecting rectangular regions from an image, with pixel perfect precision and then copy + paste as new. To achieve the pixel perfect precision, I have to zoom in a lot (10x and maybe more) and try at the same time to make a selection of an area which doesn't even fit my screen. It's hard and irritating. The important things in implementing something like this are: 1) You have to have an unobstructed view of the image (that's why I don't like peter sikking's proposal) 2) You must be able to see the outline of the brush or the cursor position, in the zoomed in view and the zoomed in view should follow the normal view (that's why a second zoomed in view of the image, with View-New View, wouldn't work) How about another tab that shows the zoomed in view, with the above characteristics and a key that when you press it and the zoom tab is enabled, it would raise this tab on the front? Of course, finding a key would be difficult... Can ctrl for example be used for this purpose without affecting its use from the other tools? Should be? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Steve Stavropoulos wrote: I really _miss_ this feature! One of the things I do all the time, is selecting rectangular regions from an image, with pixel perfect precision and then copy + paste as new. The important things in implementing something like this are: 1) You have to have an unobstructed view of the image (that's why I don't like peter sikking's proposal) here is the workflow that I am seeing for you: - set the course selection rectangle - grab a side or corner handle, set it pretty damn close, press magnifier key, see magnified view out if the way of your cursor, set corner/edge pixel perfect, release handle, release magnifier key - repeat last step for the other 3 corners/sides unobstructed and precise enough? --ps principal user 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] Enhancement Proposal: Add a temporary magnifier
IMO, you definitely need to see the mouse cursor in the magnified view, and you should be able to interact with it. Windows has a magnifier that uses a second window for the magnified display. The good is that the cursor shows up in the enlarged view ... the bad is that the window takes up so much room on your screen and you have to relocate it frequently while you work. You can dock it on the edges of the screen or have it float, however. If you want to see/try the Windows implementation, it is under StartProgramsAccessoriesAccessibilityMagnifier. Here's a screen shot of the Windows version in action. http://pic20.picturetrail.com/VOL66/86790/6669793/233053894.jpg The Windows version is not bad, but improvements could be made and I don't know if other operating systems have such a tool. A version that resides in GIMP and is designed with retouchers in mind would be a very nice feature, I think. --- Sven Neumann [EMAIL PROTECTED] wrote: Hi, how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view? Sven Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Sat, 2007-02-24 at 07:41 -0800, Mark Lowry wrote: Here's a screen shot of the Windows version in action. http://pic20.picturetrail.com/VOL66/86790/6669793/233053894.jpg The Windows version is not bad, but improvements could be made and I don't know if other operating systems have such a tool. A version that resides in GIMP and is designed with retouchers in mind would be a very nice feature, I think. Pretty much every desktop comes with such a tool and it shouldn't be our business to duplicate this functionality. But a magnifier on the desktop level can only magnify the screen view. It wouldn't give a more detailed view of the image. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view? IMO, there should be a fixed crosshair or something in the center of the zoom window that corresponds to the cursor. As the tool moves around the image, the image scrolls but the crosshair does not move. I do not think there needs to be be any interaction, other than being able to set the magnification level desired - either in prefs or in the window itself. I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time. Just my 2¢, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On Sat, 24 Feb 2007 20:10:47 +0100, Akkana Peck [EMAIL PROTECTED] wrote: peter sikking writes: what I am asking myself is 'does this thing need to be circular? XEphem has a magnifier in some of its views, like the moon view. It's just a square with a yellow border, and you can drag the mouse around and magnify different parts of the image in real time. http://shallowsky.com/tmp/xephem-moon-view.jpg I don't find it very useful in xephem because there's not enough detail to be worth magnifying, but I'd love a quick way in GIMP of saying Show me what this small region looks like at full size, even though the image window is zoomed out at 33%. In GIMP, as Sven already said, you can get more useful information than a mere screen magnifier could give. I think that might be a different use case from what's being discussed here, though, because seeing a brush cursor doesn't make much sense in this model. I'd be moving the mouse around to select what area gets zoomed, not to paint or do other operations. If I want to see both zoomed and normal views while I'm actually painting, opening a second view works fine for me. Chris Mohler writes: I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time. I'd use a popup but I wouldn't use a dialog. If it was a dialog that I had to position on the screen and dismiss later, I'd just as soon open a new view and zoom it. Especially if there were other preliminary steps, like the select-a-region step Peter described. just a quick thought following from an earlier comment. As an aid to getting pixel precision on a larger area than could be displayed in one go at a sufficient resolution. If the mouse wheel is configured like googleEarth zoom, could this provide a way to pinpoint with pixel accuracy each corner of the rectangle without the need for a loupe? Scroll zoom , select rectangle vertex 1, zoom out, find second part in image, zoom in, click second defining vertex. Currently the zoom is disabled while the mouse button is down. I'll let Peter suggest the best way implement this. Whether by allowing mouse scroll events while left button is depressed , or by some other selection means. Currently I dont see a way to select a rectangle larger than the visible area without compromising precision. gg. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Hi, On Sat, 2007-02-24 at 13:29 -0800, Mark Lowry wrote: If a second, stationary window is used rather than a moving lens, I would suggest that it should have its own buttons for controling the magnification level. Its desktop location should also be able to be remembered upon exiting GIMP or any time it is closed so that when it is launched again it re-opens in the same location. It could be dockable. In the long term our plans for dockables is that anything that you ever added to a dock will open again where you had docked it the last time. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 2/24/07, Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. This could be accessed, for example, by pressing SHIFT+Z, upon which a small window would open up and display the area around the cursor. The window that pops up could have some check boxes for the amount of magnification to be used (1x, 2x, 3x, 5x, etc.). It doesn't soom to differ significantly from existing Navigation window Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 2/24/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: to be used (1x, 2x, 3x, 5x, etc.). It doesn't soom to differ significantly from existing Navigation window It does! Navigation window provides a zoomed out view of the entire image -- this provides a zoomed in view of the area that the cursor is in. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
