Community
Participate
Working Groups
Some menus have simple Push state whereas they're actually Toggles. In most cases, those menus such as "Toggle Fullscreen" should be checkboxes.
(In reply to Mickael Istria from comment #0) > Some menus have simple Push state Please be specific. Otherwise this might be an open-ended bug. I disagree with the checkbox. Out of my head I'd say we only have it in the main menu at one place for auto-build. BUT: I agree that a "Toggle xyz" menu is bad since it does not tell the current state. Usually we change the label to indicate the state, e.g. Show/Hide Toolbar.
(In reply to Dani Megert from comment #1) > Please be specific. Otherwise this might be an open-ended bug. * Toggle split editor * Toggle word wrap * Toggle full screen > I disagree with the checkbox. Out of my head I'd say we only have it in the > main menu at one place for auto-build. > BUT: I agree that a "Toggle xyz" menu is bad since it does not tell the > current state. Usually we change the label to indicate the state, e.g. > Show/Hide Toolbar. Ok, we can try to change the label. Should we say "enable spit editor" and "disable split editor" for instance? However, I don't get why not a "Split editor" checkbox.
(In reply to Mickael Istria from comment #2) > Ok, we can try to change the label. Should we say "enable spit editor" and > "disable split editor" for instance? How about Split/Unsplit... ? > However, I don't get why not a "Split editor" checkbox. As said, we're not using them anywhere except at one place I think.
(In reply to Dani Megert from comment #3) > (In reply to Mickael Istria from comment #2) > > Ok, we can try to change the label. Should we say "enable spit editor" and > > "disable split editor" for instance? > > How about Split/Unsplit... ? Ok. And for "word wrap"? Other candidate would be "Toggle Block Selection" and "Show whitepace characters". Basically about every command which has a toggle button in toolbar. > As said, we're not using them anywhere except at one place I think. I also found checkboxes in "Edit > Smart Insert Mode", "Run > Skip all breakpoints", "Run > Use step fileters". But even if this is not something used so often, wouldn't it be worth adopting it instead for every command that have a yes/no state?
(In reply to Mickael Istria from comment #4) > (In reply to Dani Megert from comment #3) > > (In reply to Mickael Istria from comment #2) > > > Ok, we can try to change the label. Should we say "enable spit editor" and > > > "disable split editor" for instance? > > > > How about Split/Unsplit... ? > > Ok. > And for "word wrap"? > > Other candidate would be "Toggle Block Selection" and "Show whitepace > characters". Basically about every command which has a toggle button in > toolbar. I don't think we have a menu for word wrap or whitespace command.
(In reply to Dani Megert from comment #1) > I disagree with the checkbox. > BUT: I agree that a "Toggle xyz" menu is bad since it does not tell the > current state. Usually we change the label to indicate the state, e.g. > Show/Hide Toolbar. We do show toggle buttons for several of the mentioned operations in the toolbar. If the toggle button works, it means that the command already has a state. It would be pretty consistent to use the same state flag in the menu to make it checked in sync with the toggle button. I don't think changing labels are a good practice to deal with a state (it requires more user attention to understand the effect, the fact that 1st word change makes it harder to locate the counter-action later) when graphical layers do have the checkbox menu which is dedicated to that. Let's just use the right widget for the right concept (an action that does "switch" a state on or off) abd be consistent with enablement in toolbars.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
