idea: Exposée-like effect for visualizing complex stacks of svg elements in Inkscape ?
I have been using inkscape a lot recently and I noticed that sometimes it can become very annoying to select svg elements that are in the middle of a pile of other elements.
Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and after that, all shapes would be places back in their correct places. Sometimes I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode, not actualy modifying elements in the SVG DOM.
I'd like to have some feedback on this idea. thanks,
Felipe Sanches (Juca)
Felipe Sanches <juca@...360...> writes:
I have been using inkscape a lot recently and I noticed that sometimes it can
become very annoying to select svg elements that are in the middle of a pile of other elements.Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and after that, all shapes would be places back in their correct places. Sometimes I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode, not actualy modifying elements in the SVG DOM.I'd like to have some feedback on this idea.
There's something similar in the most recent version of Powerpoint for mac, I think. Only, instead of an expose-like effect, it shows the stack layered in 3d. Here's a description with a screenshot: http://www.joycescapade.com/2010/10/microsoft-office-for-mac-2011.html
But I believe there's an better way to implement something like this without having to create fancy motion graphics: suppose you have some modifier to the selection cursor so that when you click a point, Inkscape makes a query of all the shapes below the cursor, then opens something that looks like a context menu (near the cursor point, that is) with a list of shapes with thumbnails next to them where icons usually are. then you can select a shape from the list, which adds this shape to the existing selection. I think ALT + right-click is a good combo.
On 2010-12-04 19:53, Felipe Sanches wrote:
I have been using inkscape a lot recently and I noticed that sometimes it can become very annoying to select svg elements that are in the middle of a pile of other elements.
Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and after that, all shapes would be places back in their correct places. Sometimes I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode, not actualy modifying elements in the SVG DOM.
I'd like to have some feedback on this idea. thanks,
I like the idea, also to be able to select items that are not necessarily on top of each other, but are very close (this can be very frustrating, requiring very precise mousing and/or zooming).
For shapes that are not on top of each other I think it should just be like a kind of magnifier glass, but how would you propose to "pull apart" completely covered shapes? I could imagine something could be done that's similar to certain graph layout algorithms. But it would have to be pretty fast.
The menu idea mentioned by Michael might also be an option, but I have some (although it was brief) experience with something like that and found it a bit inconvenient, especially as you have to make a coupling between the text in the menu and the objects in your image. Thumbnails would help, but if they're as small as icons they might be of limited use, if they get larger it may just be more natural to have a zoom-like behaviour. Also, such a menu solution could make it a bit more awkward to also handle selecting non-overlapping (or partially overlapping), but very close, shapes.
+1, I love the exposé idea.
Without knowing much about the internals of Inkscape, I'd imagine that being fairly advanced graphics software, most of the graphics-level stuff required for animation & scaling will be already in place, and the difficult part will not be creating a flashy-looking animation, but rather designing a functionality that will be intuitive.
- Bryan
On Mon, Dec 6, 2010 at 23:03, Jasper van de Gronde <th.v.d.gronde@...528...>wrote:
On 2010-12-04 19:53, Felipe Sanches wrote:
I have been using inkscape a lot recently and I noticed that sometimes it can become very annoying to select svg elements that are in the middle of a pile of other elements.
Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and after that, all shapes would be places back in their correct places. Sometimes I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode, not actualy modifying elements in the SVG DOM.
I'd like to have some feedback on this idea. thanks,
I like the idea, also to be able to select items that are not necessarily on top of each other, but are very close (this can be very frustrating, requiring very precise mousing and/or zooming).
For shapes that are not on top of each other I think it should just be like a kind of magnifier glass, but how would you propose to "pull apart" completely covered shapes? I could imagine something could be done that's similar to certain graph layout algorithms. But it would have to be pretty fast.
The menu idea mentioned by Michael might also be an option, but I have some (although it was brief) experience with something like that and found it a bit inconvenient, especially as you have to make a coupling between the text in the menu and the objects in your image. Thumbnails would help, but if they're as small as icons they might be of limited use, if they get larger it may just be more natural to have a zoom-like behaviour. Also, such a menu solution could make it a bit more awkward to also handle selecting non-overlapping (or partially overlapping), but very close, shapes.
What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Monday, December 06, 2010 08:18:56 pm Bryan Hoyt | Brush Technology wrote:
+1, I love the exposé idea.
Without knowing much about the internals of Inkscape, I'd imagine that being fairly advanced graphics software, most of the graphics-level stuff required for animation & scaling will be already in place, and the difficult part will not be creating a flashy-looking animation, but rather designing a functionality that will be intuitive.
- Bryan
On Mon, Dec 6, 2010 at 23:03, Jasper van de Gronde <th.v.d.gronde@...2509.....> wrote: On 2010-12-04 19:53, Felipe Sanches wrote:
I have been using inkscape a lot recently and I noticed that sometimes it can become very annoying to select svg elements that are in the middle of a pile of other elements.
Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and after that, all shapes would be places back in their correct places. Sometimes I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode, not actualy modifying elements in the SVG DOM.
I'd like to have some feedback on this idea. thanks,
I like the idea, also to be able to select items that are not necessarily on top of each other, but are very close (this can be very frustrating, requiring very precise mousing and/or zooming).
For shapes that are not on top of each other I think it should just be like a kind of magnifier glass, but how would you propose to "pull apart" completely covered shapes? I could imagine something could be done that's similar to certain graph layout algorithms. But it would have to be pretty fast.
The menu idea mentioned by Michael might also be an option, but I have some (although it was brief) experience with something like that and found it a bit inconvenient, especially as you have to make a coupling between the text in the menu and the objects in your image. Thumbnails would help, but if they're as small as icons they might be of limited use, if they get larger it may just be more natural to have a zoom-like behaviour. Also, such a menu solution could make it a bit more awkward to also handle selecting non-overlapping (or partially overlapping), but very close, shapes.
For what it's worth, alt-click in Inkscape currently lets you cycle through the objects under the cursor (first alt-click selects the top object, second alt-click selects the next one down, and so on). There is a good description of this at the bottom of the "Basic" tutorial (Help->Tutorials->Basic).
--Mark
Yes, alt-click is a very useful feature.
But it's often very hard to know which object you're selecting, because you can't actually see it.
An alternative to the exposé concept would be to have all the overlapping objects turn semi-transparent (say 30%), except for the currently-selected object. Might be simpler to implement, and equally useful? I guess there are some pros & cons -- it'd be harder to select an object (you'd still have to cycle thru), but it would be easier to see the position & appearance of the object.
If you could use the scroll-wheel to cycle through the objects when Alt is pressed, that would make it faster, and avoid the chance of accidentally double-clicking (I do that all the time when using alt-click -- rather frustrating).
- Bryan
On Wed, Dec 8, 2010 at 16:03, Mark Voorhies <mark.voorhies@...2508...> wrote:
On Monday, December 06, 2010 08:18:56 pm Bryan Hoyt | Brush Technology wrote:
+1, I love the exposé idea.
Without knowing much about the internals of Inkscape, I'd imagine that
being fairly advanced graphics software, most of the graphics-level stuff required for animation & scaling will be already in place, and the difficult part will not be creating a flashy-looking animation, but rather designing a functionality that will be intuitive.
- Bryan
On Mon, Dec 6, 2010 at 23:03, Jasper van de Gronde <
th.v.d.gronde@...528...> wrote:
On 2010-12-04 19:53, Felipe Sanches wrote:
I have been using inkscape a lot recently and I noticed that sometimes it can become very annoying to select svg elements that are in the middle of a pile of other elements.
Thus, I was thinking that we could have a key-combo that would break appart all "hidden" shapes to allow you to select one of them, and
after
that, all shapes would be places back in their correct places.
Sometimes
I do something similar to that by hand, but an automated UI feature would be very useful. Also, it would be solely a visualization mode,
not
actualy modifying elements in the SVG DOM.
I'd like to have some feedback on this idea. thanks,
I like the idea, also to be able to select items that are not necessarily on top of each other, but are very close (this can be very frustrating, requiring very precise mousing and/or zooming).
For shapes that are not on top of each other I think it should just be like a kind of magnifier glass, but how would you propose to "pull apart" completely covered shapes? I could imagine something could be done that's similar to certain graph layout algorithms. But it would have to be pretty fast.
The menu idea mentioned by Michael might also be an option, but I have some (although it was brief) experience with something like that and found it a bit inconvenient, especially as you have to make a coupling between the text in the menu and the objects in your image. Thumbnails would help, but if they're as small as icons they might be of limited use, if they get larger it may just be more natural to have a zoom-like behaviour. Also, such a menu solution could make it a bit more awkward to also handle selecting non-overlapping (or partially overlapping), but very close, shapes.
For what it's worth, alt-click in Inkscape currently lets you cycle through the objects under the cursor (first alt-click selects the top object, second alt-click selects the next one down, and so on). There is a good description of this at the bottom of the "Basic" tutorial (Help->Tutorials->Basic).
--Mark
What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2010-12-08 04:40, Bryan Hoyt | Brush Technology wrote:
Yes, alt-click is a very useful feature.
But it's often very hard to know which object you're selecting, because you can't actually see it.
An alternative to the exposé concept would be to have all the overlapping objects turn semi-transparent (say 30%), except for the currently-selected object. Might be simpler to implement, and equally useful? I guess there are some pros & cons -- it'd be harder to select an object (you'd still have to cycle thru), but it would be easier to see the position & appearance of the object.
Purely as a solution for multiple objects in one place I think this might be a very interesting option, as it's probably a lot more feasible than the exposée-like effect and could really make it easier to select an object.
It might be good to make the transparency effect "cumulative" though, in the sense that if you have 10 objects above the "current" object then the combined opacity of all those 10 objects would be 30%.
If you could use the scroll-wheel to cycle through the objects when Alt is pressed, that would make it faster, and avoid the chance of accidentally double-clicking (I do that all the time when using alt-click -- rather frustrating).
This could be an interesting addition. I think this could largely negate any advantages of being able to pick a shape vs. cycling through it.
Now, anyone wants to code this so we can try it out?
Hi all,
If you could use the scroll-wheel to cycle through the objects when Alt is pressed, that would make it faster, and avoid the chance of accidentally double-clicking (I do that all the time when using alt-click -- rather frustrating).
[...] Now, anyone wants to code this so we can try it out?
I thought I'd use this as a small project after a long break to take a first step back into Inkscape development (see bzr rev. #9976). You can now cycle through items that are stacked on top of each other by using Alt+mouse wheel scroll (use Shift+Alt to add to selection). I hope it is intuitive enough but let me know of any problems or suggestions you might have. At the moment, groups are not honoured (i.e., only individual items within groups are selected). Should this be added (perhaps using Ctrl as the keyboard modifier)? Could there be problems with nested groups, though?
Cheers, Max
P.S.: I also extended the status messages in the Selection tool to indicate this new way of selecting items but given that I am not a native speaker I'm sure they can be improved so feel free to modify them.
On 22/12/10 17:35, Maximilian Albert wrote:
I thought I'd use this as a small project after a long break to take a first step back into Inkscape development (see bzr rev. #9976). You can now cycle through items that are stacked on top of each other by using Alt+mouse wheel scroll (use Shift+Alt to add to selection). I hope it is intuitive enough but let me know of any problems or suggestions you might have. At the moment, groups are not honoured (i.e., only individual items within groups are selected). Should this be added (perhaps using Ctrl as the keyboard modifier)? Could there be problems with nested groups, though?
Inkscape 0.48+devel r9976 on OS X 10.5.8:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Reproducible with default preferences, SVG file used for testing attached (objects on three layers), as well as backtrace.
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000000bc 0x0014fee9 in SPItem::get_arenaitem (this=0x0, key=0) at sp-item.cpp:1544 1544 for ( SPItemView *iv = display ; iv ; iv = iv->next ) { (gdb) bt #0 0x0014fee9 in SPItem::get_arenaitem (this=0x0, key=0) at sp-item.cpp:1544 #1 0x000f22dc in sp_select_context_root_handler (event_context=0x5141428, event=0x6e88f08) at select-context.cpp:532 #2 0x0006df4c in sp_event_context_virtual_root_handler (event_context=0x5141428, event=0x6e88f08) at event-context.cpp:966 #3 0x0006e93c in sp_event_context_virtual_item_handler (event_context=0x5141428, item=0x54a5350, event=0x6e88f08) at event-context.cpp:1007 #4 0x00333cdc in sp_marshal_INT__POINTER_POINTER (closure=0x50d2510, return_value=0xbfffe65c, n_param_values=3, param_values=0x5141428, invocation_hint=0xbfffe510, marshal_data=0x30640) at helper/sp-marshal.cpp:247 #5 0x032c80a9 in g_closure_invoke () #6 0x032da163 in signal_emit_unlocked_R () #7 0x032db537 in g_signal_emit_valist () #8 0x018fe741 in gtk_signal_emit () #9 0x0023fd35 in sp_canvas_arena_send_event [inlined] () at display/canvas-arena.cpp:335 #10 sp_canvas_arena_event (item=0x52e2028, event=0x6e88f08) at display/canvas-arena.cpp:322 #11 0x00333f75 in sp_marshal_BOOLEAN__POINTER (closure=0x50b7350, return_value=0xbfffeaac, n_param_values=2, param_values=0x6d1f6f8, invocation_hint=0xbfffe960, marshal_data=0x23fc90) at helper/sp-marshal.cpp:124 #12 0x032c80a9 in g_closure_invoke () #13 0x032da2e8 in signal_emit_unlocked_R () #14 0x032db537 in g_signal_emit_valist () #15 0x018fe741 in gtk_signal_emit () #16 0x00264443 in emit_event (canvas=<value temporarily unavailable, due to optimizations>, event=0x6e88418) at display/sp-canvas.cpp:1364 #17 0x0026aba2 in sp_canvas_motion (widget=0x4388380, event=0x6e88418) at display/sp-canvas.cpp:1622 #18 0x0176652b in _gtk_marshal_BOOLEAN__BOXED () #19 0x032c80a9 in g_closure_invoke () #20 0x032da2e8 in signal_emit_unlocked_R () #21 0x032db537 in g_signal_emit_valist () #22 0x032dbaf9 in g_signal_emit () #23 0x018958a6 in gtk_widget_event_internal () #24 0x01764728 in gtk_propagate_event () #25 0x01764c9d in gtk_main_do_event () #26 0x02756b15 in gdk_event_dispatch () #27 0x03380a9d in g_main_context_dispatch () #28 0x0338459b in g_main_context_iterate () #29 0x03384877 in g_main_loop_run () #30 0x01763c71 in gtk_main () #31 0x01178d4b in Gtk::Main::run () #32 0x00005cec in ~vector [inlined] () at stl_vector.h:986 #33 sp_main_gui (argc=1, argv=0xbffff374) at main.cpp:993 #34 0x000048e6 in start () (gdb) quit
2010/12/22 ~suv <suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
However, I just noticed another crash problem with the file you attached. It doesn't occur from within gdb, though, so I can't get a backtrace. Grrr. I seem to remember these types of bugs were mentioned before. Anyone knows what could be causing such a bug that is not visible from within gdb? I'll try to look into it later (but expect to have limited internet access over the next few days so not sure if I can commit a fix immediately).
Cheers, Max
On 2010-12-23 17:12, Maximilian Albert wrote:
2010/12/22 ~suv<suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
I'm dying to try this out, but haven't really had a chance yet... Will report as soon as I have done so.
However, I just noticed another crash problem with the file you attached. It doesn't occur from within gdb, though, so I can't get a backtrace. Grrr. I seem to remember these types of bugs were mentioned before. Anyone knows what could be causing such a bug that is not visible from within gdb? I'll try to look into it later (but expect to have limited internet access over the next few days so not sure if I can commit a fix immediately).
Could it be that gdb does something with initialization? Just a wild guess, but for me errors caused by unitialized values or overruns (of small array on the stack for example) usually are the hardest to track down. Also, have you tried just sprinkling printf's around? Crude, sure, but often quite effective.
On Thu, Dec 23, 2010 at 8:12 AM, Maximilian Albert <maximilian.albert@...1439...> wrote:
2010/12/22 ~suv <suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
It appears to not do the opacity stuff unless both a fill and a stroke are set. I've tried and ~suv confirmed that either one alone will not work. she also mentioned that even if you have a filled object with the stroke set and stroke size is zero it won't work either.
Cheers, Josh
P.S. Great feature, already getting used to it in my workflow. :)
On 23/12/10 18:42, Josh Andler wrote:
It appears to not do the opacity stuff unless both a fill and a stroke are set. I've tried and ~suv confirmed that either one alone will not work. she also mentioned that even if you have a filled object with the stroke set and stroke size is zero it won't work either.
ahem, no - the other way round ;) (works if fill is solid and stroke is set with "stroke-width:0" i.e. not visible rendered):
|07:21| < ScislaC> su-v: the new Alt-Scrolling feature... I can only seem to get it to work on (rectangles is my test for now) objects that have BOTH a fill and stroke... otherwise it isn't doing the transparency |07:34| < su-v> ScislaC: yep, seems that with either no fill or no stroke, the object isn't rendered with reduced opacity if not selected |07:37| < su-v> ScislaC: but using a black stroke with 0 width works again (even though the stroke is not rendered (zero width)) |07:37| < su-v> on a filled rectangle |07:39| < su-v> ScislaC: and it works on clones, even if it fails with the original
hth, ~suv
Ahhh, sorry remembered the 0 stroke backwards. On Dec 23, 2010 10:51 AM, "~suv" <suv-sf@...58...> wrote:
On 23/12/10 18:42, Josh Andler wrote:
It appears to not do the opacity stuff unless both a fill and a stroke are set. I've tried and ~suv confirmed that either one alone will not work. she also mentioned that even if you have a filled object with the stroke set and stroke size is zero it won't work either.
ahem, no - the other way round ;) (works if fill is solid and stroke is set with "stroke-width:0" i.e. not visible rendered):
|07:21| < ScislaC> su-v: the new Alt-Scrolling feature... I can only seem
to get it to work on (rectangles is my test for now) objects that have BOTH a fill and stroke... otherwise it isn't doing the transparency
|07:34| < su-v> ScislaC: yep, seems that with either no fill or no
stroke, the object isn't rendered with reduced opacity if not selected
|07:37| < su-v> ScislaC: but using a black stroke with 0 width works
again (even though the stroke is not rendered (zero width))
|07:37| < su-v> on a filled rectangle |07:39| < su-v> ScislaC: and it works on clones, even if it fails with
the original
hth, ~suv
Hi,
thanks for the helpful feedback, everyone! This is the first time I've had internet access since before Christmas and I'm likely to be offline for another week or so, but I'll keep looking into the things you mentioned. I haven't been able to reproduce the crash I noticed a while ago but indeed found an uninitialized pointer, so perhaps this already fixes it. Regarding the reduced opacity not working under certain circumstances, I'll have another look but I don't really know what the proper way of temporarily changing an items opacity is. At the moment I'm just using nr_arena_item_set_opacity(...), but that was a pure guess which seemed to work. Hints as to the proper method would be appreciated.
A happy new year to everyone and see you in 2011 when I'm back online! Max
2010/12/23 Josh Andler <scislac@...400...>:
On Thu, Dec 23, 2010 at 8:12 AM, Maximilian Albert <maximilian.albert@...1439...> wrote:
2010/12/22 ~suv <suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
It appears to not do the opacity stuff unless both a fill and a stroke are set. I've tried and ~suv confirmed that either one alone will not work. she also mentioned that even if you have a filled object with the stroke set and stroke size is zero it won't work either.
Cheers, Josh
P.S. Great feature, already getting used to it in my workflow. :)
Hi,
Happy belated new year, everyone! I'm finally back to a decent internet connection so further replies should happen much more promptly. :) I have just committed a one-line change which should hopefully fix the opacity issue. However, it tampers with the internal property 'render_opacity' of NRArenaItem, which I don't really understand, so there is a risk of introducing other bugs further down the line. Thus I'd be very grateful if some expert in this portion of the code base could comment on whether this is the right thing to do or not.
Has anyone had any other problems with the new feature or seen any crashes recently? Max
2010/12/28 Maximilian Albert <maximilian.albert@...1439...>:
Hi,
thanks for the helpful feedback, everyone! This is the first time I've had internet access since before Christmas and I'm likely to be offline for another week or so, but I'll keep looking into the things you mentioned. I haven't been able to reproduce the crash I noticed a while ago but indeed found an uninitialized pointer, so perhaps this already fixes it. Regarding the reduced opacity not working under certain circumstances, I'll have another look but I don't really know what the proper way of temporarily changing an items opacity is. At the moment I'm just using nr_arena_item_set_opacity(...), but that was a pure guess which seemed to work. Hints as to the proper method would be appreciated.
A happy new year to everyone and see you in 2011 when I'm back online! Max
2010/12/23 Josh Andler <scislac@...400...>:
On Thu, Dec 23, 2010 at 8:12 AM, Maximilian Albert <maximilian.albert@...1439...> wrote:
2010/12/22 ~suv <suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
It appears to not do the opacity stuff unless both a fill and a stroke are set. I've tried and ~suv confirmed that either one alone will not work. she also mentioned that even if you have a filled object with the stroke set and stroke size is zero it won't work either.
Cheers, Josh
P.S. Great feature, already getting used to it in my workflow. :)
-----Original Message----- From: Maximilian Albert [mailto:maximilian.albert@...1439...] Sent: dinsdag 11 januari 2011 20:54 To: Josh Andler Cc: inkscape; ~suv Subject: Re: [Inkscape-devel]idea: Exposée-like effect for visualizing complex stacks of svg elements in Inkscape ?
Hi,
Happy belated new year, everyone! I'm finally back to a decent internet connection so further replies should happen much more promptly. :) I have just committed a one-line change which should hopefully fix the opacity issue. However, it tampers with the internal property 'render_opacity' of NRArenaItem, which I don't really understand, so there is a risk of introducing other bugs further down the line. Thus I'd be very grateful if some expert in this portion of the code base could comment on whether this is the right thing to do or not.
Has anyone had any other problems with the new feature or seen any crashes recently?
Hi Max,
I just tried it, what an awesome feature! And already I have found the first bug :P ;-)
See the attached file. The green rectangle has 60% opacity. When cycling through the objects, the green rectangle is displayed with 100% opacity; I think this is not a problem and it is probably nicer than showing it at its own 60% opacity when selected. But when I stop cycling (release Alt), the green rectangle is still shown at 100% opacity.
I like this feature and think it will be useful for many.
Ciao, Johan
On 12/23/2010 05:12 PM, Maximilian Albert wrote:
However, I just noticed another crash problem with the file you attached. It doesn't occur from within gdb, though, so I can't get a backtrace. Grrr. I seem to remember these types of bugs were mentioned before. Anyone knows what could be causing such a bug that is not visible from within gdb? I'll try to look into it later (but expect to have limited internet access over the next few days so not sure if I can commit a fix immediately).
Sometime ago I was wondering the same thing, and found some explanation here
http://www.codeguru.com/forum/archive/index.php/t-269905.html http://stackoverflow.com/questions/186237/program-only-crashes-as-release-bu... http://www.gamedev.net/community/forums/topic.asp?topic_id=565024
Although it's mostly Visual C++ related, there are some useful pointers there.
Good luck,
Diederik
From: Maximilian Albert <maximilian.albert@...1439...> Subject: Re: [Inkscape-devel] idea: Exposée-like effect for visualizing complex stacks of svg elements in Inkscape ? Date: Thu, 23 Dec 2010 17:12:02 +0100
2010/12/22 ~suv <suv-sf@...58...>:
Great feature :) - haven't tested in depth though for further feedback because Inkscape immediately crashes/hangs if the mouse pointer is moved just a little bit while 'Alt' is still pressed and one object is selected while the other ones stacked below the pointer area are rendered with reduced opacity.
Good catch! Sorry that I didn't notice this problem before, but as I just found out my laptop's touchpad freezes the mouse pointer position while scrolling so the crash didn't occur on my laptop. Should be fixed in bzr rev. 9980.
However, I just noticed another crash problem with the file you attached. It doesn't occur from within gdb, though, so I can't get a backtrace. Grrr. I seem to remember these types of bugs were mentioned
try 'ulimit -c XXX' to create coredump for crashing processes for linux of cause.
before. Anyone knows what could be causing such a bug that is not visible from within gdb? I'll try to look into it later (but expect to have limited internet access over the next few days so not sure if I can commit a fix immediately).
Cheers, Max
Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (11)
-
unknown＠example.com -
Bryan Hoyt | Brush Technology -
Diederik van Lierop -
Felipe Sanches -
Jasper van de Gronde -
Josh Andler -
Mark Voorhies -
Maximilian Albert -
Michael Grosberg -
Thinker K.F. Li -
~suv