Liferea und Wayland

„Naiver Thor, laß es zuende sein.“ Das wird leider nichts, das Thema will einfach nicht beendet werden ;D Da gibt es soviel was sich erst jetzt, wenn man es voll benutzt zeigt, da wird das Blog noch lange von belegt werden 😉

Gnome – Wayland & Liferea

Liferea kennt Ihr ? Das ist der RSS-Feedreader meiner Wahl. Ihr habt ihn auch schon hier gesehen:

Jetzt sieht das auf dem Bild natürlich so aus, daß alles geht. Geht im Prinzip auch, aber der dort zusehende Firefox, kann dummerweise kein OSK aufrufen, weil es die NICHT-Waylandversion ist, und man halt die Waylandunterstützung braucht. Jetzt fragt Ihr zu Recht, daß mir das ja hätte auffallen müssen, als ich das Bild da gemacht habe.

Leider nein, weil man das OSK nicht braucht, um eine Webseite zu scrollen. Das fiel dann erst heute morgen auf, als ich einen Webseitenlink wie gewohnt an jemanden, der sich für das gelesene Thema interessiert, mailen wollte. Der Thunderbird-Verfassen-Dialog ging auch auf, nahm aber keine Eingaben an 😀

Ursache – eine ungünstige Verkettung

Im Liferea ist in den Tool-Einstellungen der zuverwendende Browser auf Mozilla als Synonym für Firefox gestellt. Das führt natürlich dazu, daß der normale Firefox geladen wird. Der lädt natürlich auch den normalen Thunderbird 😀

Also stellen wir das von :

Liferea Einstellungen tools - browser

auf

immernoch die Browsereinstellungen in Liferea

um. Jetzt ist die Kette korrekt: Firefox-Wayland lädt Thunderbird-Wayland und das OSK ist da und benutzbar.

Merke: Mit Wayland als Basis, wird man noch an einigen Stellen nachjustieren müssen, bis das einwandfrei läuft. Ich bin gespannt, was der nächste Beitrag so bringt. Ach was solls, das nächste Thema ist „USB-LAN Adapter am Surface“.

Games: Astrolords mit Touchsupport?

Die Gnome Surface Tips

Und es geht weiter mit dem Tablet und seinen Problemchen. Heute zeigen wir einen Fall von Links-weiß-nicht,was-Rechts-tut! Und das es sowas in Computerprogrammen gibt, war lange ein Mythos, aber mit dem räumen wir heute auf. Und wir brauchen nicht mal eine KI dafür bemühen 🙂

Gnome und das Touchpad

Vorweg, das betrifft vermutlich auch die TouchPads von Laptops, daher können die Laptopuser auch gleich mitlesen.

Also, was war passiert? Am Anfang hatte das Touchpad nur eine Linke Taste, d.b Rechts ging nicht. Da kam eine Option in den Gnome-Tastatureinstellungen gerade recht : Die Halten zum Klicken Funktion ….

Gnome Tastatureinstellungen

Überraschenderweise klappte das seit einigen Tagen nicht mehr. Da es um Gnome geht, kommen einem ja nur min. zwei bis drei Möglichkeiten in den Sinn, wie man das verkonfigurieren kann. Da noch kein DCONF-Editor drauf war, schied das schonmal aus. Aber, es ist das Gnome-Tweaktools installiert worden und jede Menge Gnome-Extentions, da sollte man mal nachsehen 🙂

Und ohne es in die Länge zu ziehen, das war aktiviert :

und SO hätte es eigentlich sein müssen :

Damit verhält sich zwar der Mauszeiger nicht mehr wie das zuerst erwartet war: Anklicken-Halten-Rechtsklick simulieren. Dafür aber kann man jetzt mit dem Touchpad endlich wieder so arbeiten, wie man das mit einer Maus gewohnt ist. Vorausgesetzt, das TypeCover ist angeschlossen.

Games: Astrolords mit Touchsupport?

WordPress 5.1.1 Multisites mit DB-Updateproblem

Nächste Warnung: Wer eine WordPress Multisite betreibt und von 5.0 auf 5.1.1 aktualisiert wird, der könnte ein Problem haben, ohne es zu wissen.

Datenbankupdate nicht ausgeführt

Die Fehler reichen von Logmeldungen wie dieser:

WordPress-Datenbank-Fehler Table ‚db466398.wp_blogmeta‘ doesn’t exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (6) ORDER BY meta_id ASC von include(‚wp-load.php‘), require_once(‚wp-config.php‘), require_once(‚wp-settings.php‘), require(‚wp-includes/ms-settings.php‘), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

bis hin zu 500er Fehlern, wenn man die Webseiten aufruft.

Das Problem wurde vor 4 Wochen bereits bekannt, konnte aber nicht zuverlässig reproduziert werden von den Devs, tritt aber so oft auf, daß es kein Zufall mehr ist, ich habs ja auch gehabt 😉

Lösung:

Einloggen in die Datenbank und das hier ausführen:

CREATE TABLE `wp_blogmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`blog_id` bigint(20) NOT NULL DEFAULT 0,
`meta_key` varchar(255) DEFAULT NULL,
`meta_value` longtext DEFAULT NULL,
PRIMARY KEY (`meta_id`),
KEY `meta_key` (`meta_key`),
KEY `blog_id` (`blog_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Dann hören die Meldungen im Errorlog des Apachen auf. Ob das auch den 500er behebt, kann ich nicht sagen, da er mir nicht passiert ist. Wer sich jetzt fragt wo ich die Struktur her habe, es gibt in WP eine Datei, in der die DB Schemata drinstehen, da bekommt man das her.