[Marble-devel] Review Request: Adjustable route overlay color and transparency

Bernhard Beschow bbeschow at cs.tu-berlin.de
Tue Nov 1 15:51:12 UTC 2011 


> On Oct. 27, 2011, 6:16 p.m., Bernhard Beschow wrote:
> > Thanks for the patch, having the route colors adjustable rather than hardcoded is a very good idea. Having applied your patch and seeing the rather complicated color selection dialog, however, I wondered whether it was sufficient to just set a (single) alpha transparency value, as requested in the bug report. As an additional benefit, this would also prevent regular users to "mess" with the routing colors, which have been choosen to be distinct from the tracking etc. ones (such that they make up a "color theme").
> > 
> > What I suggest is therefore the following: Keep the colors "soft"-coded from the config file, such that computer-savvy users can still change the colors. For regular users, there should only be a single alpha transparency selector in the config dialog, setting a common transparency for all three routing colors.
> > 
> > What do you think?
> 
> Torsten Rahn wrote:
>     What is complex about the color selection? We do it the same way for the other plugins from what I can see ...
>     
>
> 
> Bernhard Beschow wrote:
>     Well, I was just expressing my personal perception of the color selection dialog. First, I have no idea what the radio buttons are about. Second, the technical term "Alpha" is used, whereas we use the IMO more user-friendly term "transparency". So, in order to change the transparency value (for a single case!), users first have to identify the correct field out of seven (!) fields. However, this is a challenge in itself, because users have to map the term "transparency" to "alpha". These might be the reasons why the color selection dialog appears complex to me.
>     
>     Anyway, the appearence of the color selection dialog just made me realize that color selection has a few issues: First, it might suffice to set a single transparency value for all three cases, which may be enough to satisfy the original request. Second, selecting custom colors might break our "color theme". If there was a need to change the colors, we'd probably have an issue with our defaults.
>     
>     In any case, having the colors soft-coded in the config files, power users were still able to change the colors.
> 
> Bernhard Beschow wrote:
>     I admit that we use the term "transparency" only in our discussion. Still, I find this term to be more intuitive and non-technical than "alpha".
>     
>     Moreover, it might seem that I question the whole patch. However, this is not the case. I much prefer soft-coded values rather than hard-coded ones! So the approach taken for the config settings goes IMO in the right direction.
> 
> Torsten Rahn wrote:
>     Hi Bernhard. You are totally right, that QColorDialog these days is almost too much of a Cockpit UI experience. I feel that the plain palette (which currently defaults to 40 colors instead of Oxygen which I consider a bug) should be central to the user experience and the tweaking stuff (like Hue, RGB, etc.) should only appear on demand.
>     In earlier versions of QColorDialog the palette part was indeed on the top left and much more prominent than the rest of the dialog's features. Seems things have become worse. 
>     However I feel that this issue is separate from this patch, since it affects QColorDialog itself and it should be resolved for all the other instances where we are using QColorDialog as well. A stripped down version of QColorDialog with some easy way to adjust alpha would be nice to have for most other use cases we have.
> 
> Torsten Rahn wrote:
>     oh yes, and of course in that user friendly color dialog we could use the less technical term "transparency" indeed. ;-)
> 
> Bernhard Beschow wrote:
>     I agree, changing QColorDialog is a separate issue. Still, I wonder whether we really need users to adjust the colors for the routes. IMO, an in-place user control to change the transparency value for all three cases at once, such as a slider, would do. A preview of the colors would be nice, though.
> 
> Torsten Rahn wrote:
>     I think allowing to change colors is something that should be possible given that different maps have different color schemes and one might want to choose a different one to match the color scheme of the preferred map (e.g. for print out).
>     Regarding the obstruction of the path that you are driving into: How do the other navigation solutions do it? Do they show arrows instead of the plain path? Or do they choose the color so that you can still see what is displayed behind? Maybe we should also evaluate to default to a different route visualization during the actual navigation mode.

> I think allowing to change colors is something that should be possible given that different maps have different color schemes

Ok. So what about usetting the QColorDialog::ShowAlphaChannel option of the color dialog and have a single transparency slider for all three colors on the settings page, possibly with a live preview?


- Bernhard


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102540/#review7696
-----------------------------------------------------------


On Oct. 26, 2011, 9:41 a.m., Florian Eßer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102540/
> -----------------------------------------------------------
> 
> (Updated Oct. 26, 2011, 9:41 a.m.)
> 
> 
> Review request for Marble.
> 
> 
> Description
> -------
> 
> The patch from http://mail.kde.org/pipermail/marble-bugs/2011-September/001532.html
> 
> ==============
> 
> Hi,
> I had the same problem myself recently.
> 
> So here's a patch that adds an option "Adjust track color" in the
> track's context menu just below "Export route".
> 
> Todo / Possible enhancements:
> * make all the different route types (e.g. deviated from route)
>   configurable, not just the standard one. Right now, only the alpha
>   values get adjusted for all track types/colors.
> * save/load to config file
> ** and then: button to restore the nice marble defaults if you have
>    experimented to much ;-)
> 
> Greetings
> Florian
> 
> On 28.08.2011 09:48, Robin Seidel wrote:
> > hi, thanks for the great marble!!! I have one wish: could you allow 
> > to adjust the transparency of the route overlay, so one can see the 
> > track beneath, this would be especially helpful for walking routes, 
> > where one may not want to take the smallest paths. Once the route is
> >  found one can currently not easily see what's beneath.
> > 
> > best regards
> > 
> > robin
> 
> 
> Diffs
> -----
> 
>   src/lib/routing/RoutingLayer.cpp 77af021 
>   src/lib/routing/RoutingManager.h cbe70bf 
>   src/lib/routing/RoutingManager.cpp 7cdffa1 
>   src/lib/routing/RoutingProfilesWidget.h e2d7333 
>   src/lib/routing/RoutingProfilesWidget.cpp 88c880e 
>   src/lib/routing/RoutingSettingsWidget.ui 27849c2 
>   src/marble.kcfg 06277c8 
>   src/marble_part.cpp 3f26b50 
> 
> Diff: http://git.reviewboard.kde.org/r/102540/diff/diff
> 
> 
> Testing
> -------
> 
> I haven't tested it it with the Qt-only version yet. (--> kcfg ??)
> 
> 
> Screenshots
> -----------
> 
> Routing settings with new color buttons.
>   http://git.reviewboard.kde.org/r/102540/s/318/
> 
> 
> Thanks,
> 
> Florian Eßer
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20111101/fb18a133/attachment.html>

More information about the Marble-devel mailing list