shared menus

[Maciej Pilichowski]

On Thursday 21 May 2009 21:37:13 Matthew Woehlke wrote:

> Maciej Pilichowski wrote:
> > On Thursday 21 May 2009 18:23:52 Matthew Woehlke wrote:
> >> I turned off shared menu for TAI container; shared menu (for
> >> TAI) has two effects:
> >> - menu might be above tab strip instead of below
> >
> > It was intended :-)
>
> ...but shared menu is not needed for this.

Well, but there is no difference. After all shared menu means -- show 
only one menu at a time. For TAI it can be only menu anyway. So from 
the inside, sure, there will be some technical difference, but as the 
effect you get the same.

So -- shared menu means -- show menu above tabbar.

> >> - menus can't appear in child windows (e.g. if child is a
> >> container)
> >
> > Only if child is TAI as well. If it is GAI this sentence is not
> > true.
>
> It is as of my last rewording of the section. Otherwise you have
> magic appearing/disappearing menus, depending on what window has
> focus. 

Well, we will show empty menu. We cannot show the menu from GAI-child 
if GAI does not shared menu too. 

> If you've got a solution to that, I'm all ears, but for now 
> my preference is that the menu is displayed in the topmost window
> that wants to display it.

I see it in reverse -- pass shared menu as far as containers allow for 
that. In your case if I set desktop has shared menu it will suck 
everything, even deep buried menu. I will actually lost control 
because in such case it does not matter what I set for other 
containers. Desktop is root and it gets everything.

In concept of allowing to pass menu desktop will get only menus from 
SAI for sure. It will get menu from TAI for example if TAI has also 
shared menu -- so in this case, options (for non-desktop) have 
effect.

> (IOW if you disable shared menus 
> everywhere /except/ the desktop... then you only ever get one menu,
> in the desktop.)

In the pass-allow concept yes, in take-all concept (yours) disabling 
does not matter once desktop has shared menu. 

> >> The second I think is undesirable as default.
> >
> > I made this on on one purpose only -- the most recognizable app
> > in KDE world TAI-like is Konqueror. Konq. has shared menu.
>
> I am confused. "Menus can't appear in child windows" happens when
> you have nested containers. I don't see how the Konqueror example
> is relevant.

I don't understand your confusion :-) Konqueror is TDI which can be 
thought as TAI. Launch Konqueror, open 10 tabs. You will get menu 
above the tabbar not below. So you get visual example of shared menu.

The same look you would get with NWI, with TAI shared menu.

> >> This brings up an important question, however; when using shared
> >> menu, what do you do if the app /has/ no menu? I'm not sure
> >> hiding it is good because then the layout potentially changes
> >> when you switch windows. Should we have some sort of "empty
> >> menu" that would be used if the child doesn't provide a menu?
> >
> > Yes. I would opt for creating menu "close" on-fly in case of
> > empty-menu. Or even with help menu as well. After all, space is
> > already taken, why not use it?
>
> The alternative is to hide the menu, but then you have magic
> disappearing menu. I think we are agreeing we don't like this :-).

Yes, indeed :-)

> (Actually you can't have help - at least, I don't think so, right
> now anyway - if app doesn't provide it,

We can make it up -- "about KDE", "KDE handbook", "report a bug".

> I wonder if this will
> lead to "optional" menus, as in, "show this stuff if a container
> wants a menu, but don't show a menu in this window".)

I hope not :-D

Cheers,