Opened 6 years ago

Closed 5 years ago

#2080 closed enhancement (fixed)

wxGUI: changing properties of barscale or legend

Reported by: martinl Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: wxGUI Version: svn-trunk
Keywords: decorations, d.barscale, d.legend, d.northarrow Cc:
CPU: All Platform: All

Description

Hi,

when changing properties of barscale or legend you need to go through two dialogs. The first dialog allows to disable/enable decoration and launch properties (autogenerated) dialog. Here 'Apply' button has no effect, so you cannot see immediately the change. You close the properties dialog and then the first dialog. After these steps decoration is re-rendered.

My suggestion is to avoid the first dialog. Clicking on decoration would launch properties dialog immediately. Right click shows contextual menu with one item 'Hide'. To show decoration you would go to the toolbar and to add selected decoration again. Or global contextual menu (which has currently only one item 'Copy to clipboard..') could have item to 'Show/hide barscale', 'Show/hide legend', ...

Change History (14)

comment:1 in reply to:  description Changed 6 years ago by mlennert

Replying to martinl:

Hi,

when changing properties of barscale or legend you need to go through two dialogs. The first dialog allows to disable/enable decoration and launch properties (autogenerated) dialog. Here 'Apply' button has no effect, so you cannot see immediately the change. You close the properties dialog and then the first dialog. After these steps decoration is re-rendered.

My suggestion is to avoid the first dialog. Clicking on decoration would launch properties dialog immediately. Right click shows contextual menu with one item 'Hide'. To show decoration you would go to the toolbar and to add selected decoration again.

+1

comment:2 Changed 6 years ago by hamish

CPU: UnspecifiedAll
Keywords: d.barscale d.legend added
Platform: UnspecifiedAll

martinl:

Right click shows contextual menu with one item 'Hide'.

how would you make that "discoverable" for new users without them having to read the docs in frustration to find out how to do it? perhaps clicking the barscale/legend icons in the top bar could present a drop down menu? (?) [afair the reason that Macs only have one mouse button was to force the programmers to come up with intuitive solutions]

I can't find a ticket for it right now in a search, but the other big issue with the GUI legends and barscales is the full-window "glass pane" slide. If you grab on one side of the decoration it works, on the other side it doesn't. the solution seems to be to render the graphic at=50,50, then crop away to ~15 pixels around the outer extent of the graphics so grabbing the top-"glass pane" will move the decoration you expect, not the one who's "glass pane" happens to be on top. ..or find some other method to overlay them on the map canvas.

Another issue with the current method is that the north arrows (which should probably be presented separate to the barscales in the GUI (perhaps using wrapper scripts?) tend to get clipped off the edge of the transparent background layer they are rendered on when using the default placement. Otherwise I would have liked to swap the default GUI legend/barscale placement top-bottom.

thanks, Hamish

comment:3 in reply to:  2 ; Changed 6 years ago by annakrat

Replying to martinl:

My suggestion is to avoid the first dialog. Clicking on decoration would launch properties dialog immediately. Right click shows contextual menu with one item 'Hide'. To show decoration you would go to the toolbar and to add selected decoration again. Or global contextual menu (which has currently only one item 'Copy to clipboard..') could have item to 'Show/hide barscale', 'Show/hide legend', ...

This sounds good to me. Right click is intuitive enough for me but usually the functionality is also accessible in another way (and now I have no idea how).

Replying to hamish:

I can't find a ticket for it right now in a search, but the other big issue with the GUI legends and barscales is the full-window "glass pane" slide. If you grab on one side of the decoration it works, on the other side it doesn't. the solution seems to be to render the graphic at=50,50, then crop away to ~15 pixels around the outer extent of the graphics so grabbing the top-"glass pane" will move the decoration you expect, not the one who's "glass pane" happens to be on top. ..or find some other method to overlay them on the map canvas.

Actually, I found a solution for it recently but I haven't implemented it yet. PIL can trim the image automatically:

    imageBox = pilImage.getbbox()
    cropped = pilImage.crop(imageBox)

so you just have to convert it to PIL (or load it directly from file) and back to wx. And place the legend or barscale on a reasonable place (not just 0, 0).

Another issue with the current method is that the north arrows (which should probably be presented separate to the barscales in the GUI (perhaps using wrapper scripts?) tend to get clipped off the edge of the transparent background layer they are rendered on when using the default placement. Otherwise I would have liked to swap the default GUI legend/barscale placement top-bottom.

wrapper script seems to be a good idea

comment:4 in reply to:  3 ; Changed 6 years ago by martinl

Replying to annakrat:

[...]

Another issue with the current method is that the north arrows (which should probably be presented separate to the barscales in the GUI (perhaps using wrapper scripts?) tend to get clipped off the edge of the transparent background layer they are rendered on when using the default placement. Otherwise I would have liked to swap the default GUI legend/barscale placement top-bottom.

wrapper script seems to be a good idea

currently you can add barscale or north arrow, but not both. Moreover north arrow is not rendered well, better to say only right-side of the north arrow is rendered (because default x=0,95).

Instead of making wrapper for adding north arrow (it will also require to hide north arrow related options when adding barscale in wxGUI) what about splitting this functionality into two separate modules, ie. d.barscale and d.northarrow?

comment:5 in reply to:  4 Changed 6 years ago by annakrat

Replying to martinl:

Replying to annakrat:

[...]

Another issue with the current method is that the north arrows (which should probably be presented separate to the barscales in the GUI (perhaps using wrapper scripts?) tend to get clipped off the edge of the transparent background layer they are rendered on when using the default placement. Otherwise I would have liked to swap the default GUI legend/barscale placement top-bottom.

wrapper script seems to be a good idea

currently you can add barscale or north arrow, but not both. Moreover north arrow is not rendered well, better to say only right-side of the north arrow is rendered (because default x=0,95).

Instead of making wrapper for adding north arrow (it will also require to hide north arrow related options when adding barscale in wxGUI) what about splitting this functionality into two separate modules, ie. d.barscale and d.northarrow?

I completely agree. I just thought there is some reason that it's one module.

comment:6 in reply to:  2 Changed 6 years ago by martinl

Replying to hamish:

martinl:

Right click shows contextual menu with one item 'Hide'.

how would you make that "discoverable" for new users without them having to read the docs in frustration to find out how to do it? perhaps clicking the barscale/legend icons in the top bar could present a drop down menu? (?) [afair the reason that Macs only have one mouse button was to force the programmers to come up with intuitive solutions]

hm, the most of applications which I use behave similarly. When I want to delete or change properties of selected object eg. in Dia I go to the contextual menu (open by right click on the object). So I usually expect this behaviour without reading any documentation and having any "frustration".

I do not claim that my suggestion is perfect. Please suggest another. My motivation is to avoid extra dialog as we have now. It's just annoying when you want to change style of selected decoration, you need to go through two dialogs. Moreover "Apply" button doesn't behave in the sense which could be expected by the user. Current situation is not good, let's find better.

Ideally the functionality to hide/show decoration could be accessible in different ways. Eg. in contextual menu (object-related) and check menu item in toolbar (it will introduce limitation, you will be able to add only one decoration of given type). The question is if we want to allow the user to add multiple barscales, northarrows or legends.

comment:7 Changed 6 years ago by hamish

Keywords: d.northarrow added
Version: unspecifiedsvn-trunk

annakrat:

Right click is intuitive enough for me but usually the functionality is also accessible in another way (and now I have no idea how).

Yes, I don't mind at all if right click opens a context menu, it could be a nice time-saver, but I think it should be available in another way too. IIUC the idea is to right-click on the menubar icon? If so I don't think that's something I would ever try if not told about it, but maybe I should try that more & there's a world of functionality I've never discovered.

but maybe I don't understand the suggestion, ie what's being right-clicked?

an idea for a single barscale or north arrow would be to keep the menu- bar icon depressed when active as a push-button, and clicking to raise it again would turn it off. Like how a bold or italics button works in a word processor. the help page could instruct to use command layers to add a second legend for the rare times people would like to do that.

so single click on the menubar icon calls the d.* module with --ui, then when the user presses ok the decoration is drawn on the monitor, and the menubar icon remains depressed. right clicking on the depressed icon would get you back to the module --ui (if command line options were remembered you can do full command line + '--ui' to get pre-seeded menus using the recently-used option settings; or at least that works in G6). left clicking on the depressed menubar icon removes it from the display and raises the button again.

second legends, barscales, and north arrows could be added as command layers with an mini-tutorial in the help pages on how to do that.

what do you think? could the at= option survive for the second entry into the module UI? (e.g. if you like the placement but want to change the color when the backdrop raster is replaced by one of similar hue to the symbol)

"glass pane" slide.

Actually, I found a solution for it recently but I haven't implemented it yet. PIL can trim the image automatically:

>    imageBox = pilImage.getbbox()
>    cropped = pilImage.crop(imageBox)

so you just have to convert it to PIL (or load it directly from file) and back to wx. And place the legend or barscale on a reasonable place (not just 0, 0).

that is excellent news, thanks. (you mentioned it before and I forgot? :)

martinl:

Instead of making wrapper for adding north arrow (it will also require to hide north arrow related options when adding barscale in wxGUI) what about splitting this functionality into two separate modules, ie. d.barscale and d.northarrow?

sure, done.

annakrat:

I completely agree. I just thought there is some reason that it's one module.

barscale and north arrows were in one module simply because they shared many of the same placement, color, & text options and it saved some time to only maintain the code once. but it makes sense to split them out, the background/fill color had problems trying to be two things at once anyway.

martinl:

(it will introduce limitation, you will be able to add only one decoration of given type). The question is if we want to allow the user to add multiple barscales, northarrows or legends.

multiple barscales can be useful for showing both miles and km, and of course allowing both a barscale and a northarrow at the same time is desirable.

Hamish

comment:8 Changed 6 years ago by hamish

ps- D_line_width() seems broken, also for d.vect. Setting it has no effect.

comment:9 in reply to:  7 Changed 6 years ago by annakrat

Replying to hamish:

but maybe I don't understand the suggestion, ie what's being right-clicked?

Right click on the decoration itself, like now double-click opens the dialog.

Thanks for the splitting of the module, I will try to have a look at the GUI today or in the next days.

Anna

comment:10 Changed 6 years ago by annakrat

Please test r57738 if it is acceptable for you or you have any better suggestions.

comment:11 in reply to:  10 ; Changed 6 years ago by martinl

Replying to annakrat:

Please test r57738 if it is acceptable for you or you have any better suggestions.

much much more better! There is only one limitation - you cannot add multiple barscales, legends, or northarrows, right?

comment:12 in reply to:  11 ; Changed 6 years ago by annakrat

Replying to martinl:

Replying to annakrat:

Please test r57738 if it is acceptable for you or you have any better suggestions.

much much more better! There is only one limitation - you cannot add multiple barscales, legends, or northarrows, right?

Yes, but this limitation was there even before. The workaround is to add the command layer which then behaves little differently (no moving around). But I guess this is not the common requirement.

comment:13 in reply to:  12 ; Changed 6 years ago by martinl

Replying to annakrat:

much much more better! There is only one limitation - you cannot add multiple barscales, legends, or northarrows, right?

Yes, but this limitation was there even before. The workaround is to add the command layer which then behaves little differently (no moving around). But I guess this is not the common requirement.

right, the correct sentence is "There is *still* one limitation".

comment:14 in reply to:  13 Changed 5 years ago by wenzeslaus

Resolution: fixed
Status: newclosed

Replying to martinl:

Replying to annakrat:

much much more better! There is only one limitation - you cannot add multiple barscales, legends, or northarrows, right?

Yes, but this limitation was there even before. The workaround is to add the command layer which then behaves little differently (no moving around). But I guess this is not the common requirement.

right, the correct sentence is "There is *still* one limitation".

Original issue is solved. Closing.

Please, open a new enhancement ticket if you want track this limitation.

See also GSoC 2015 ideas page.

Note: See TracTickets for help on using tickets.