Tk Source Code

View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to [email protected]
or submit via the online form by Sep 9.
Ticket UUID: 43b596451ec6b59359145ff32e689a2eec70bb85
Title: relief for active menu entries
Type: Bug Version: 8.6
Submitter: anonymous Created on: 2015-01-21 03:14:29
Subsystem: 10. Generic Menus Assigned To: fvogel
Priority: 5 Medium Severity: Cosmetic
Status: Closed Last Modified: 2018-09-23 13:01:15
Resolution: Fixed Closed By: fvogel
    Closed on: 2018-09-23 13:01:15
I apologise if I missed something but as it appears to me
active menu entries are hard coded with bevelled edges

please make them inherit the menu relief
or make it otherwise configurable

I know I can set the activeborderwidth to zero
but then legibility suffers as the spacing is too cramped
User Comments: fvogel added on 2018-09-23 13:01:15:
TIP #517 was accepted by the TCT (YES: 8 ; NO: 0 ; PRESENT : 0).

The corresponding implementation is now merged to trunk.

fvogel added on 2018-09-16 16:21:36:
TIP #517 currently in VOTING state.

fvogel added on 2018-09-12 20:45:49:

TIP #517 created to deal with this ticket.

fvogel added on 2018-09-11 11:16:12:

Thank you for your feedback.

I have added the Windows implementation of -activerelief in branch bug-43b596451e.

Regarding macOS I think this feature cannot be available since DrawMenuEntryBackground() is an empty procedure, probably because the native menues are used on this platform.

I will have to write a TIP and get it voted before I can merge.

On the other issue you saw with activeborderwidth != borderwidth, yes could you please open a dedicated ticket, and specify the platform where this problem happens (because I don't see any problem on Win). Thanks!

anonymous added on 2018-09-11 10:16:08:
While both approaches have their pros, I would slightly favour the variant with the new option because of its greater flexibility. Maybe someone wants, for wahtever reasons, another style of border.

Another problem, probably deserving a separate ticket, is revealed if you set activeborderwidth != borderwidth. Then you can easily see that there is a bug in the geometry calculation for the menu. I could not yet identify the problematic code, but will eventually if noone has an idea.

fvogel added on 2018-09-09 08:06:50:

Alternatively, instead of adding a new -activerelief option (that would be considered only on Linux) we could change the rendering of the active entry in Linux menues as TK_RELIEF_FLAT, and keep the current TK_RELIEF_RAISED only if tk_strictMotif is set.

See this proposal in an alternate bugfix branch bug-43b596451e-alt

The drawbacks are that this is a backwards incompatible change: the look of menues will be changed, and adding an-activebackground option will likely be needed in user code.

What do people think about this? What would be the preferred approach to solve this ticket, add a -activerelief option to menues or change the default rendering of the active entries?

fvogel added on 2018-09-08 22:18:16:

Please check out branch bug-43b596451e, where I have added a -activerelief option to menues. This is implemented for Linux only so far.

Test script:

package require Tk
menu .m
menu .m.f
.m add cascade -label File -menu .m.f
.m.f add command -label "Item 0"
.m.f add command -label "Item 1"
.m.f add command -label "Item 2"
.m.f add command -label "Item 3"
. configure -menu .m
.m.f configure -activeborderwidth 10 -activebackground grey75
.m.f configure -activerelief flat

Is this what are would like to have?

anonymous added on 2018-09-03 09:56:51:
The main idea is to give the menu entries more space, needed for reliable finger gestures (no mouse).
Setting the activeborderwidth to 0 and inserting empty items is just a very bad workaround. Probably using images in compound items would be a better approach.
But setting the activeborderwidth to some larger value and choosing the relief is what you really want to do. In all the other parts of Tk you are now able to simply get rid of this old Motif style, so menus should be no exception.

By a short look at the sources, the raised border is set in DrawMenuEntryBackground in tkUnixMenu.c. For Windows it seems already set to be flat (cannot test).

anonymous added on 2018-09-03 04:57:05:
yes OP is still here but I'm too preoccupied at the moment
having just moved and preparing for the rainy season
not to mention I have yet to setup an internet connection

bll added on 2018-09-01 09:16:59:
font create small
font configure small -size -1
menu .mb
. configure -menu .mb
menu .mb.example -tearoff 0
.mb.example add command -label Menu-1
.mb.example add command -label {} -font small -state disabled
.mb.example add command -label Menu-2
.mb add cascade -label Example -menu .mb.example
.mb configure -activeborderwidth 0
.mb.example configure -activeborderwidth 0

anonymous added on 2018-09-01 09:01:06:
That is what I meant. But I think most modern UI toolkits, GTK for example, render active menu entries flat instead of raised.
Especially with Androwish in mind, I would assign this RFE a higher priority.

fvogel added on 2018-09-01 07:17:11:

To the OP (if still in the room more than 3 years after posting): Could you post a demo script showing the issues you mention with active menu entries?

To the anonymous poster below: Regarding "Google's Material Design", is it that you have in mind?

anonymous added on 2018-09-01 01:31:44:
Yes, active entries are always drawn with relief raised.
Please add an option "activerelief".
For example, to mimic Google's Material Design I would like to set this to flat.