GNU bug report logs - #68765
30.0.50; Adding window-tool-bar package.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: philipk <at> posteo.net, 68765 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: bug#68765: 30.0.50; Adding window-tool-bar package.
Date: Tue, 04 Jun 2024 18:59:21 +0300

> Date: Mon, 03 Jun 2024 22:24:55 -0700
> From: Jared Finder <jared <at> finder.org>
> Cc: juri <at> linkov.net, 68765 <at> debbugs.gnu.org, philipk <at> posteo.net,
>  monnier <at> iro.umontreal.ca
> 
> > How about if we make the behavior simpler and more predictable:
> > 
> >   If a window's buffer has a non-nil value of window-toolbar-mode,
> >   show the window-specific tool bar regardless of what it is and
> >   whether it is the same as the default.
> > 
> > Why is this not good enough?
> 
> I want the window-specfic tool bar to never be shown if there are no 
> tool bar buttons, to conserve space.  However, if tab-line-format is non 
> nil, the tab line takes up space even if the resulting tab line is nil.  
> This can happen if one sets the default tool bar to nil, while keeping 
> the mode specific tool bars.

If the issue is not to show an empty tool bar, then this could be done
by a special test, without affecting behavior in other cases.  And
having the tool bar completely empty is such a rare and strange
situation that we could even leave it alone, under the assumption that
such a "tool bar" is simply a bug of sorts.

Complicating the overall behavior, let alone the difficulties of
explaining the behavior in documentation, on behalf of such rare and
very special cases is hardly a good tradeoff, won't you agree?

> I think there's also a useful case where the frame tool bar is used to 
> show a "global" tool bar with buttons that do not act on the current 
> buffer (in the current default tool bar: new file, open file, open 
> directory, all the modifier tool bar buttons) and the window tool bar is 
> used to show buttons that act on the buffer.  In this case, you don't 
> want the "global" tool bar to change based on frame's selected window.  
> The "tool-bar-always-show-default" variable I added as well as the logic 
> with ignoring the default value of tool-bar-map was to enable this use 
> case.  I treat the default value of tool-bar-map as "no tool bar buttons 
> for this window" since all those buttons are for the global tool bar.  
> It'd be fine to limit behavior to only when tool-bar-always-show-default 
> was set.

I'm not against tool-bar-always-show-default and its effect.  But
introducing that optional behavior doesn't require any particular
behavior from window-specific tool bars, it's almost an orthogonal
feature.

My conclusion from this is that the two considerations you provided
in favor of a much more complex behavior do not contradict my
suggestion.  The first consideration is about a very rare case, which
we could simply ignore (but if you feel strongly about  detecting
empty tool bars and not displaying them, I won't object), while the
second consideration  does not require the complicated behavior of
window-specific tool bars.

If I missed something, or if you still disagree, please tell what and
why.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.