From: Po Lu <luangruo@yahoo.com>
To: Tobias Bading <tbading@web.de>
Cc: emacs-devel@gnu.org
Subject: Re: icon-title-format vs. frame-title-format (Bug#61496)
Date: Fri, 05 May 2023 19:00:48 +0800 [thread overview]
Message-ID: <878re3kppb.fsf@yahoo.com> (raw)
In-Reply-To: <4920048a-aded-3588-50d2-4bea3c0c096b@web.de> (Tobias Bading's message of "Fri, 5 May 2023 12:40:37 +0200")
Tobias Bading <tbading@web.de> writes:
> Oh god, what have I done? XD
>
> But holding back isn’t one of my strong suites, so here goes nothin’…
>
> The X Window System may have introduced and/or (re)used certain terms, like
> “normal” and “iconic” for different states of top-level windows, but that
> was ages ago. That the term “iconic” was chosen is very unfortunate IMHO.
> It contains the word “icon” and thus suggests/implies that a currently
> invisible window is represented by some icon somewhere. Window managers like
> mwm may have chosen to actually represent invisible windows this way back
> then.
And yet, on my GNOME 3 desktop, iconified windows _are_ still
represented by an icon placed within the dash area in the overview
panel. ``Iconification'' is simply the more accurate term: there is
nothing minimal about the huge previews displayed in the overview area,
but the previews do correspond to icons.
Not that I like GNOME's new design. I think it's horrible.
Anyway, I don't object to explaining what we call ``minimized'', as long
as it is confined to some short introductory text in the manual. But we
should never use the term ``minimized'' ourselves.
> Today, a lot of free software desktop environments, window systems,
> window managers etc are available. Some may present invisible windows
> as icons, others as buttons in window lists, a thumbnail in a dock, or
A thumbnail, or a button containing an icon, is not/does not contain an
icon?
next prev parent reply other threads:[~2023-05-05 11:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 18:40 icon-title-format vs. frame-title-format (Bug#61496) Tobias Bading
2023-05-03 18:56 ` Eli Zaretskii
2023-05-03 19:10 ` Tobias Bading
2023-05-04 0:12 ` Po Lu
2023-05-04 4:03 ` Tobias Bading
2023-05-04 4:38 ` Po Lu
2023-05-04 4:46 ` Tobias Bading
2023-05-04 4:59 ` Tobias Bading
2023-05-04 14:51 ` Óscar Fuentes
2023-05-04 16:08 ` Eli Zaretskii
2023-05-04 16:37 ` Óscar Fuentes
2023-05-04 17:36 ` Eli Zaretskii
2023-05-05 0:15 ` Po Lu
2023-05-05 1:02 ` Óscar Fuentes
2023-05-05 4:44 ` tomas
2023-05-05 5:33 ` Eli Zaretskii
2023-05-05 7:28 ` tomas
2023-05-05 10:39 ` Eli Zaretskii
2023-05-05 5:24 ` Po Lu
2023-05-05 5:29 ` Eli Zaretskii
2023-05-05 10:40 ` Tobias Bading
2023-05-05 11:00 ` Eli Zaretskii
2023-05-05 11:00 ` Po Lu [this message]
2023-05-05 11:17 ` Eli Zaretskii
2023-05-05 12:29 ` Po Lu
2023-05-05 13:31 ` Eli Zaretskii
2023-05-05 23:52 ` Po Lu
2023-05-06 6:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878re3kppb.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=emacs-devel@gnu.org \
--cc=tbading@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).