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 gnome–tweaks 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
Will investigate later and amend the post (promise!).
$ free; find . -size +25M -exec bash -c 'ls -l {}; eog {}; echo' \;; free total used free shared buff/cache available Mem: 7746692 5767656 843228 317764 1135808 1271048 Swap: 7950332 5113012 2837320 -rw-rw-r-- 1 miki miki 39926496 Jun 10 19:25 ./20190609_184124.jpg ** (eog:23320): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23320 Aborted (core dumped) eog ./20190609_184124.jpg -rw-rw-r-- 1 miki miki 38286099 Jun 10 19:26 ./20190609_183714.jpg ** (eog:23332): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23332 Aborted (core dumped) eog ./20190609_183714.jpg -rw-rw-r-- 1 miki miki 36181801 Jun 9 17:13 ./20190609_160437.jpg ** (eog:23343): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed ** (eog:23343): CRITICAL **: eog_reload_plugin_deactivate: assertion 'G_IS_MENU (menu)' failed -rw-rw-r-- 1 miki miki 39059177 Jun 10 19:25 ./20190609_184146.jpg ** (eog:23354): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23354 Aborted (core dumped) eog ./20190609_184146.jpg total used free shared buff/cache available Mem: 7746692 5773448 495604 659944 1477640 922956 Swap: 7950332 5112700 2837632 $
Here’s a quick Javascript bookmarklet I threw together for opening a new browser window showing an area in OpenStreetMap that is defined from extracting the current window’s URL and searching after useable values for latitude, longitude and zoom.
It grew out of an annoyance over Mapillary’s rendering of the Danish endpoint of the under construction HVDC Cobra Cable(more about it from 4C, even more from EnergiNet and the EU) in Endrup nearby where I live.
In Mapillary’s tiles rendering it is just a bunch of roads and a single POI indication. Whereas the Mapnik rendering shows the existing power infrastructure and the area under construction.
Well, I have been subjecting my oldstyle C brain to some Javascript lately so I decided to use that haemorrhage for attempting to put together a bookmarklet extracting coordinates from the current window’s URL and opening a new with the same approximate location in OSM.
It ended up like the below code block, and should also be usable on any other sites which receives locations via URL (both using HTTP GET notation with ‘?’ and locally in the page using anchors with ‘#’) and identifying them with key-value pairs using common names ({z,zoom},{lat},{lng,lon}). Note that this doesn’t include OpenStreetMap itself neither Google Maps as they only use the lat/lon values.
javascript:(function (){params={};kvs=document.location.href.split('&');kvs.forEach(function(kv){if(kv.indexOf('?'))kv=kv.substr(kv.indexOf('?')+1);if(kv.indexOf('#'))kv=kv.substr(kv.indexOf('#')+1);skv=kv.split('=');params[skv[0]]=skv[1];});window.open('http://openstreetmap.org/#map='+(params.z?params.z:13)+'/'+(params.lat?params.lat:55.5)+'/'+(params.lng?params.lng:(params.lon?params.lon:8.5)));console.log(params);})();
Copy and paste the above into the “Location” or “URL” of a bookmark and you’ll be able to click it to open a new OSM window on, at least for Mapillary maps pages, the same location as the original site. If nothing is found it will default to coordinates of my hometown of Esbjerg at 55.5/.8.5.
Here’s a prettified edition of the code:
params={}; kvs=document.location.href.split('&'); kvs.forEach(function(kv){ if(kv.indexOf('?')) kv=kv.substr(kv.indexOf('?')+1); if(kv.indexOf('#')) kv=kv.substr(kv.indexOf('#')+1); skv=kv.split('='); params[skv[0]]=skv[1]; }); window.open( 'http://openstreetmap.org/#map=' +(params.z?params.z:(params.zoom?params.zoom:13))+'/' +(params.lat?params.lat:55.5)+'/' +(params.lng?params.lng:(params.lon?params.lon:8.5)) ); console.log(params);
Having used the Arduino prototyping platform (a loose combination of specific pieces of somewhat open/free hardware and a more open/free software stack) for some time for educational and tinkering purposes in my local hackerspace (geeklabs.dk) I have seen and studied the Arduino UNO hardware and lots of its “clones/compatibles/knockoffs” and their common MCU (MicroController Unit);
Atmel ATmega328P
I had begun wondering what the P in the microcontroller model name actually meant. So here is an attempt to decode the Atmel megaAVR chip numbering system. The other existing AVR based series UC3, tinyAVR, XMEGA, Battery & Automotive, will probably employ similar naming schemes.
The remainder of the product name following “ATmega” expresses the available flash memory and the approximate pin count of the package in an integer and optionally other features as either integer or letter (like the initial wondering of P in 328P above).
Starting with the integer, it is a concatenation of two separate integers encoding the flash size and pin count as defined below. The division of the two is non-ambiguous leaving some interpretation to be done.
1st integer: onboard flash size 8 = 4 KiB 8 = 8 KiB 16 = 16 KiB 32 = 32 KiB 64 = 64 KiB 128 = 128 KiB 256 = 256 KiB
2nd integer: total pin number (none) = standard pin count (differs) 8=28/32-pin 4= 40/44/49-pin 5= 64-pin 0= 100-pin
Suffix (char or integer), multiple possible P = picoPower (max. consumption 9mA@8MHz,5v vs. 12mA@8Mhz,5v for non-P) 9=LCD controller U2 = USB controller U4 = USB controller A = ?
Exceptions Note that some of the product names are completely void of these rules. Others employ different numbering but still with a familiarity to the above.
An example: ATmega6490A: 64KB flash, 100-pin, LCD Controller
Sources
Eric S. Raymond, “The Cathedral and the Bazaar” (@Goodreads)
The above quotes the first lesson from Eric S. Raymond‘s (ESR) essay/book “The Cathedral and the Bazaar“ (link to full book, summary at Wikipedia), which has become a kind of bible within the FOSS ecosystem (also nicknamed CatB). In his text Eric investigates motivations and social organisation of free and open source software projects. Itches are known initiators of many both large projects and minor changes to FOSS software. Itches, and the scratching of those by developers in the FOSS community, highlights a FOSS software user’s right to access, modify and redistribute the source codes behind FOSS software. With access to the underlying source code of FOSS software, a developer is able to scratch an itch, and is usually very motivated by this, because it often is a very personal itch.
You can listen to an audio recording of Eric elaborating about the central topics of CatB in a recording from a talk at Linux Kongress all the way back to May 22th 1997 17:15 CEST (48k MP3, 96k MP3):
http://www.catb.org/~esr/writings/cathedral-bazaar/linux1_d50_48kbs.mp3
I’ve long been trying to keep a list of itches I want to scratch in free software projects/products. Realizing that most of these were lost in transit in the chaotic neuron mess of my brain, my intention now is to, also, keep track of them textually using the mechanisms of this site.
This effort will be an ongoing, and probably ever expanding, mix of my private personal itches and itches related to and spun-off from my software development work done as a professional embedded developer, but still personal itches.
You can head over to the static page at mikini.dk/what/itches and take a look at my past and present itches.
EDIT 2021-08-24: add prominent quote source, add GR quote link, add CatB main page link, add para. with audio recording, minor copyediting
