SIDEBAR
»
S
I
D
E
B
A
R
«
GNOME Shell attach-modal-dialogs true?!
Jun 2nd, 2023 by miki

While once again being annoyed by the obnoxious way modern GNOME handles in-application dialogues (fx. Nautilus’ Properties dialog) as modal (ie. freezes the parent window) AND even prevents movement of the dialogue relative to the parent I did some searching which revealed a partly solution!

This was also complained about in a 2017 LibreOffice bug report which concluded that the immobility is a GNOME 3 desktop default behaviour caused by the setting attach-modal-dialogs.

Details in the related GNOME bug report shows how to disable this by modifying gsettings;

In a regular upstream GNOME session, `gsettings set org.gnome.shell.overrides attach-modal-dialogs false`, a schema of ‘org.gnome.shell.extensions.classic-overrides’ for the classic session and afaik ‘org.gnome.mutter’ for a Ubuntu-patched GNOME.

Now knowing which term to search for, lots of discussion about this shows up (including posts similar to this), the best write up of the mitigation is probably this askubuntu question. And the mother opinionated Ubuntu bug report is this where Ubuntu officially states;

We do not consider Gnome’s defaults in this area unreasonable.

But the reason for this behaviour? Seems to be unknown as even this 2018 bug report on gnome-shell hasn’t received any official answer or comment about why this would be a sane default. Go figure…

TLDR;
On Ubuntu 20.04 and similar distributions turn off GNOME’s attach-modal-dialogs feature by doing;

$ gsettings set org.gnome.mutter attach-modal-dialogs false

Or if you like the mouse; install & launch gnometweaks and click “Windows” -> “Attach Modal Dialogues”;

Oh, and remember to read the Nielsen Norman Group article “Modal & Nonmodal Dialogs: When (& When Not) to Use Them” (summary: Modal dialogs interrupt users and demand an action. They are appropriate when user’s attention needs to be directed toward important information).

Edit:
2023-07-30: add gnome-tweaks approach

[Danish] Webmaster! Skalér nu de billeder!
May 1st, 2019 by miki

Tænk hvor meget trafik, processerings- og ventetid der ville være sparet hvis nogen gad at overveje hvad billeder på en hjemmeside anvendes til og tilpasse de transmitterede data derefter!

Her et enkelt sølle eksempel af mange observerede (ingen særlig grund til at klandre den specifikke afsender her, blev bare trigget af at klikke på et link i et nyhedsbrev just modtaget) fra SDFE‘s nyhedsoversigtsside, hvor det er så åbenlyst tydeligt på billedindlæsningshastigheden at billederne er alt for meget større end nødvendigt.

Inspicering i browseren (f.eks. med Firefox dev-tools: F12->Network) viser da også at billedindholdet fylder 14,85 MiB ud af sidens samlede størrelse på 16,23 MiB (91,5%).

SDFE.dk nyhedsoversigtsside, billederoverførsel

Hvad værre er at billederne på denne side kun anvendes som meget små illustrationer til en række artikler, men hentes som enorme filer i opløsningen 1920×1080. Inspektion af det første billede i browserens DOM-inspektør (Firefox: F12->Inspector) afslører at browseren kun viser billedet i en opløsning på 100×56! Der går altså 1920*1080-100*56=2’068’000 (99,73%) pixels til fuldstændig spilde.

SDFE.dk digebillede, vist størrelse vs. datastørrelse

Et hurtigt forsøg med at nedskalere et enkelt billede (terminal-foo!), uden at gå ind i så avancerede emner som JPG-kompressionskvalitet eller alternative billedformater (for ikke at tale om reel billedoptimering), kan give en ide om hvor meget data der egentlig overføres unødigt ved visning af denne side:

$ wget –quiet https://sdfe.dk/media/2919562/dige-1920×1080.jpg
$ gm convert -resize 100×56 dige-1920×1080.jpg dige-100×56.jpg
$ ls -l dige-*
-rw-rw-r– 1 miki miki 17420 Apr 30 15:54 dige-100×56.jpg
-rw-rw-r– 1 miki miki 1568308 Apr 24 14:54 dige-1920×1080.jpg
$

Billedets størrelse reduceres her fra 1’568’308 bytes (1,60 MiB) til 17’420 bytes (17,01 KiB). Det er relativt en besparelse i overførselsmængden på dette billede på 8903%, vel at mærke med nøjagtigt det samme visuelle udbytte! For ikke at tale om den besparelse i hukommelsesforbrug og processeringstid der også opås ved at sidebeskuerens browser skal forholde sig til en tilsvarende mindre mængde data.

Under antagelse af at tilsvarende reduktioner kan opnås på det samlede sæt af billeder på denne side, vil overførselsbehovet kunne reduceres fra 15’206,40 KiB til 170,80 KiB. Tænk lige over det næste gang, webmaster!

Andre eksempler

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2023 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0