Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Stefan Monnier]

> +** Emacs will now redisplay frames that are made visible by a compositor.
> +This means even if `frame-visible-p' returns nil or `icon', the frame
> +will be redisplayed if it is being displayed to the user by the
> +compositing manager, which can happenas part of a preview for
> +iconified windows.

FWIW, while this sounds about right for `icon`ified frames, for those
frames that are marked as actually invisible, I think we should try and
keep them as invisible as possible.  IOW if they appear as
preview/thumbnails somewhere it should itself be considered as a bug
(either in our code or in the compositing manager or ...).
Keeping the preview's appearance up-to-date is wasted efforts in
this respect.


        Stefan


PS: In case you need to see concrete uses of invisible frames, you can
    find one in `server.el` and another in GNU ELPA's `xclip.el`.
    There are probably others, but these are the one I know of because
    I coded them :-)

RE: [External] : Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Drew Adams]

> for those
> frames that are marked as actually invisible, I think we should try and
> keep them as invisible as possible.  IOW if they appear as
> preview/thumbnails somewhere it should itself be considered as a bug
> (either in our code or in the compositing manager or ...).
> Keeping the preview's appearance up-to-date is wasted efforts in
> this respect.

+1

> PS: In case you need to see concrete uses of invisible frames, you can
>     find one in `server.el` and another in GNU ELPA's `xclip.el`.
>     There are probably others, but these are the one I know of because
>     I coded them :-)

I too have code that makes frames invisible (or visible,
or iconifies them).  E.g., in `frame-cmds.el'.  E.g.,
`C-h f hide-everything':

  hide-everything is an interactive compiled Lisp function in
  'frame-cmds.el'. 

  (hide-everything)

  Hide all frames of session at once.
  Iconify minibuffer frame; make all others invisible.
  Remembers frame configuration in register `C-l' (Control-L).
  To restore this frame configuration, use `C-x r j C-l'.

Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Mon, 26 Dec 2022 09:04:26 -0500
> 
> > +** Emacs will now redisplay frames that are made visible by a compositor.
> > +This means even if `frame-visible-p' returns nil or `icon', the frame
> > +will be redisplayed if it is being displayed to the user by the
> > +compositing manager, which can happenas part of a preview for
> > +iconified windows.
> 
> FWIW, while this sounds about right for `icon`ified frames, for those
> frames that are marked as actually invisible, I think we should try and
> keep them as invisible as possible.

I'm not sure I agree.  I believe this could belong to some new GUI
ideas (all of which are invariably copy-cat'ed from MS-Windows ;-),
whereby you have a means of showing a small-but-still-readable image
of an otherwise invisible frame, e.g., by hovering the mouse above
some desktop icon or widget.  If that is the intent, then this is not
a bug, but a feature of those WMs, and an important/boastable feature
at that.

> Keeping the preview's appearance up-to-date is wasted efforts in
> this respect.

Not in the eyes of those beholders, it isn't.

But I do think this should be an optional feature (we could argue
later about the defaults).  In an Emacs session with a dozen
invisible/iconified frames, updating those frames without the user's
say-so could be a misfeature and a performance hit.

Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Stefan Monnier]

>> FWIW, while this sounds about right for `icon`ified frames, for those
>> frames that are marked as actually invisible, I think we should try and
>> keep them as invisible as possible.
>
> I'm not sure I agree.  I believe this could belong to some new GUI
> ideas (all of which are invariably copy-cat'ed from MS-Windows ;-),
> whereby you have a means of showing a small-but-still-readable image
> of an otherwise invisible frame, e.g., by hovering the mouse above
> some desktop icon or widget.

If there's some representation of that frame somewhere on the screen,
then I think it belongs in the `icon`ified state, not the
`invisible` state.

> If that is the intent,

In my experience the intent of `invisible` frames is for them to be
literally invisible as if the frame did not exist at all.
Quoting from the docstring of `make-frame-invisible`:

    On graphical displays, invisible frames are not updated and are
    usually not displayed at all, even in a window system’s "taskbar".

> But I do think this should be an optional feature (we could argue
> later about the defaults).  In an Emacs session with a dozen
> invisible/iconified frames, updating those frames without the user's
> say-so could be a misfeature and a performance hit.

Hmm... didn't think of that aspect, but indeed, my Emacs sessions usually
grow to around a hundred frames, the vast majority of which are `icon`ified.
The usual redisplay optimizations should hopefully keep the performance
impact in check, tho (except for those iconified frames that display
a buffer that's changed in the background, I guess).

Rather than rely on "optional feature", would it be possible to rely on
"expose events" to detect when an iconified frame needs to be updated?


        Stefan

Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Tue, 27 Dec 2022 10:29:19 -0500
> 
> >> FWIW, while this sounds about right for `icon`ified frames, for those
> >> frames that are marked as actually invisible, I think we should try and
> >> keep them as invisible as possible.
> >
> > I'm not sure I agree.  I believe this could belong to some new GUI
> > ideas (all of which are invariably copy-cat'ed from MS-Windows ;-),
> > whereby you have a means of showing a small-but-still-readable image
> > of an otherwise invisible frame, e.g., by hovering the mouse above
> > some desktop icon or widget.
> 
> If there's some representation of that frame somewhere on the screen,
> then I think it belongs in the `icon`ified state, not the
> `invisible` state.

You'd be surprised how visible can "invisible" frames be, on some
modern desktops.

> Rather than rely on "optional feature", would it be possible to rely on
> "expose events" to detect when an iconified frame needs to be updated?

I'm not sure such events are delivered in these cases, but Po Lu will
probably know.

Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Stefan Monnier]

> You'd be surprised how visible can "invisible" frames be, on some
> modern desktops.

Maybe Emacs should work harder to make them "more invisible" (e.g tell
the GUI that it now has a ridiculously small size (without changing the
Emacs-facing size, of course))?


        Stefan

RE: [External] : Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Drew Adams]

Apologies if you feel this is too far afield.
I mention it because the discussion has now
touched on the area of desktop icons that can
be made to show popup previews of frames that
might themselves not be visible, and on the
need/cost of updating such previews.
___

My library `thumb-frm.el' provides something
similar.  It lets you "thumbify" frames to
(any size) thumbnail versions.

These are not icons in the usual sense.  But
on a desktop they appear/act much like icons.
They can be any size, down to the size of the
smallest MS Windows icons (~1x1 cm).  They're
not just previews; they're normal frames.

By default (controlled by a user option) they
have no menu-bar or tool-bar, have a scroll
bar (6x6-pixels), and are 30% transparent when
not selected (opaque when selected).

You can move them about and resize them, like
other frames.  You can scroll them, page them,
search in them, `M-x' in them - even edit in
them (though for most edit operations the text
is too tiny).  (You can of course use `C-x C-q'
in them.)  You can monitor the progressive
output in a buffer such as `*Messages*' from a
height of 100, 1,000 or 10,000 meters.

In one sense they're kind of like tabs on a tab
bar - that's one way to use them.  But they can
be any size and anywhere on the desktop (even
on top of or overlapping each other), and they
show you more than just a buffer name.

Thumbnail frames are just tiny - they're still
normal frames.  Going back & forth between the
thumbified and dethumbified versions of a frame
is a single keystroke or click.

And each (the thumbnail and the full-size
frame) has its own position and size - moving
or resizing one doesn't affect the other.  A
thumbnail records and restores the properties
of the frame it was thumbified from.

By default (a user option), (de)thumbifying is
a _replacement_ for (de)iconifying - commands
such as `iconify-frame' are advised to use
thumbnails instead.

The original behavior of iconifying commands
remains available using different names:
`thumfr-really-iconify(-or-deiconify)-frame'.
Similarly, by default `raise-frame' does a 
dethumbify, and its original behavior is via
command `thumfr-only-raise-frame'.

In addition, you can substitute thumbifying
for iconifying at a lower level, letting you
use the window-manager's "minimize" button to
thumbify:

(define-key special-event-map [iconify-frame]
            'thumfr-thumbify-frame-upon-event)

And anywhere that your window manager would
give you a preview of a frame it will still
give you a preview, whether or not the frame
is thumbified.

E.g., on MS Windows, task-bar mouseover of the
GNU Emacs icon shows previews of the frames
equally, thumbified or not, and the previews
are all at the same scale.  In the preview you
can't tell the difference (except by, say,
noticing a menu-bar, if that's excluded from
thumbnail frames).
___

Dunno whether or how much you might think this
is related to having desktop icons be able to
show a frame preview on mouseover.  I think it
gives you a preview (which can be much more
than a preview, and which needs no refreshing)
_in the "icon" itself_.

https://www.emacswiki.org/emacs/download/thumb-frm.el

This page provides some (old) description and
screenshots.

https://www.emacswiki.org/emacs/FisheyeWithThumbs

But, by default, I now use thumbnails that are
quite a bit smaller than what's shown there.

And I personally don't bother with any of the
arranging or cycling commands.  I just thumbify
a frame at its same location, and if I want the
thumbnail elsewhere I move it.

And if I want, I resize it like any other frame,
using my `zoom-in|out':

https://www.emacswiki.org/emacs/download/zoom-frm.el