User:ScotXW/GNOME braindamage

TODO: do drag'n'drop like Windows
gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse gconftool-2 --type boolean --set /apps/metacity/general/auto_raise true gconftool-2 --type string --set /apps/metacity/general/auto_raise_delay 600

or install gnome-tweaks, then under "Windows", Windows focus select "focus-on-hover" + "raise window when focused".

Problem is, this does not work while a mouse-button is pressed (let's say because you want to drag'n'drop some files from one window (Nautilus) to another (Audacious, VLC, …).

Development (cgit)

 * https://git.gnome.org/browse/
 * https://git.gnome.org/browse/gtk+/commit/?h=wip%2Fgtk4
 * https://git.gnome.org/browse/gtk+/commit/?h=wip%2Fmir
 * https://git.gnome.org/browse/gtk+/commit/?h=wip%2Fmir2
 * https://git.gnome.org/browse/gtk+/commit/?h=wip%2Fmir3.10

Snooping through the cgit interface, as of 3017-03-16 I cannot find GTK+ 3.89 nor 3.90…
 * https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22
 * ⇒ oh, here ⇒ https://git.gnome.org/browse/gtk+/tag/?h=3.89.5
 * https://git.gnome.org/browse/gtk+/tag/?h=gtk-3-22

Now, howto see all the differences that have been done to 3.89/3.90? kernel.org uses webgit howto, gnome.org uses cgit.

GTK+ 4 development series
So let's look a the GTK+ 4 development series (= 3.90, 3.92, …):
 * GSK (GTK+ Scene Graph Kit): https://git.gnome.org/browse/gtk+/log/?qt=grep&q=GSK&ofs=200
 * replay frames: https://blogs.gnome.org/mclasen/2016/11/02/another-gtk-update/
 * render-nodes: https://git.gnome.org/browse/gtk+/log/?qt=grep&q=rendernodes
 * https://www.bassi.io/articles/2016/08/10/gsk-demystified-2/ and maybe https://blog.gtk.org/2016/06/15/drawing-in-gtk/
 * https://mail.gnome.org/archives/gtk-devel-list/2016-December/msg00013.html
 * https://blogs.gnome.org/mclasen/2017/01/01/gtk-happenings-2/
 * Vulkan renderer/rendering path: https://git.gnome.org/browse/gtk+/log/?qt=grep&q=Vulkan&ofs=100
 * Benjamin merged the Vulkan renderer for GSK, as comparison point for the GL and Cairo renderers. The Vulkan renderer adds a new optional dependency on a working Vulkan implementation, as well as glslc
 * As of GTK+ 3.89 the Broadway-back-end is still around (thought it was already removed) https://mail.gnome.org/archives/gtk-devel-list/2016-December/msg00012.html


 * 1) A GTK+ hackfest is planned for March 2017; the main topic is going to be improving performance, especially with regards with rendering
 * 2) Benjamin Otte is reworking the OpenGL renderer for GSK to ensure it’s well integrated into the GDK rendering
 * 3) Additionally, Benjamin Otte is also working on an experimental Vulkan-based renderer for GSK
 * 4) Timm Bäder is changing the GtkWidget and GtkContainer API to converge the two classes into a single scene graph
 * 5) The GTK+ road map is available


 * http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/lecture_notes/

GTK+ Scene Graph Kit vs. Clutter / COGL / libchamplain / …
Watching Emanuelle Bassi's videos at FOSDEM, GUADEC, etc. it seems that the GTK+ Scene Graph Kit – finally merged into GTK 3.90 – is the culmination of trying to integrate Clutter into GTK. Certain applications, like e.g. GNOME Videos (aka Totem) or GNOME Boxes, Cheese preferred to use Clutter and GTK+ over using solely GTK+. Now that GSK is finally written and integrated into GTK 3.90, does this mean, GNOME Videos, GNOME Boxes will be ported to use solely GTK+?

Will libchamplain be ported to GTK?

Is the new "Vulkan renderer for GSK" better then Clutter_(software)?

udisks
/etc/fstab is only read at system boot-up. In case the user wants to automatically configure (here: mount) the file systems of the partitions present on the disk, which is manually connected to the system after boot-up, the user can rely on the combination of udev and udisksd to handle this.

HarfBuzz & Pango
At linux.conf.au 2017 Simon Cozens explained the rendering of fonts. (The actual "rendering" is done by Cairo (graphics). See what harfbuzz and pango actually do:



GtkSourceView
GtkSourceView is a "source code editing widget", i.e. a syntax (or rather only keyword) highlighter, i.e. it does the syntax highlighting.
 * https://wiki.gnome.org/Projects/GtkSourceView
 * https://developer.gnome.org/gtksourceview/stable/
 * https://git.gnome.org/browse/gtksourceview/


 * Used by gedit, GNOME Builder, GNOME Web, pluma (text editor), etc.
 * Not used by Vim, mutt, notepad++, Sublime Text, Microsoft Visual Studio, Mozilla/Firefox?, KDE, …
 * GeSHi is used by e.g. DokuWiki.
 * python3-pygments is a Python thing, used by e.g. Sphinx (documentation generator)

Color schemes
Once the keywords are defined (the actual syntax is really only understood by some compiler), one could use different color schemes to display it. File holdings such color schemes also have different file structures…
 * https://github.com/altercation/solarized

Ethan Schoonover defined a set of colors – a "color theme" – he named "solarized". Then this color set was ported to all sorts of applications. And yes, each application uses its own file structure… (syntax/keyword definition and color scheme can be and are independent from one another because all grammars share some basic elements. Alternatively one could just use numbers and have the color schemes map to those.) Bottom line: stuff has to be ported to multiple applications.

There is e.g. vim2gtksourceview2, a small python script that converts from vim's color scheme into a GtkSourceView-2 color scheme.

gspell
gspell ist a wrapper around Enchant (software), which was already an attempt to unify spell checking. grammar checking is then another thing.
 * https://wiki.gnome.org/Projects/gspell

D-Bus
The idea behind D-Bus, a daemon doing inter-process communication (IPC) and remote procedure call (RPC) seems very counter-intuitive! Even a microkernel keeps IPC to itself. As a file is en entity of an file system, an abstraction, a process is an entity of some operating system kernel. When working on kdbus, a project aimed at porting a substantial amount of D-Bus into the Linux kernel, while keeping some parts of it in user-space, Lennart Poettering pointed out, that most kernels/OSes have been design from ground up around IPC. Kdbus was not accepted. Work on BUS1 began.

Put it into Talk:D-Bus.

cf. The Linux Programming Interface by Michael Kerrisk!

gtk3-icon-browser
The package gtk-3-examples in Debian 9 Stretch now also contains the, a small program written by Matthias Claasen back in 2014 to conveniently browse the icons in the "current" icon theme.
 * https://fedoramagazine.org/new-icon-browser-tool-for-gtk-developers-in-development/

The GNOME way
While the GNOME file manager (called Nautilus/GNOME Files) supports certain operations by default others (like Xfce's or LXDE's file managers) do not. For these file manager additional software was written, e.g.
 * https://wiki.ubuntuusers.de/Gigolo/
 * https://wiki.ubuntuusers.de/Samba_Client_PyNeighborhood/
 * Alacarte for GNOME 2

This means, that for the new and unexperienced user, GNOME and GNOME applications just work! When using Xfce or LXDE the user has to learn about these additional programs and make things work… Xfce and LXDE are good desktop environments, but obviously less well suited for unexperienced users. Thanks to the "Microsoft way" there are a lot of users with very little knowledge and understanding but with very high expectations.

The GNOME way is not equal to the Microsoft way. The user is expected to have some understanding of how things work, and deduce from that understanding what does work and what does not. And once the user knows what he wants to do, he simply needs to painlessly learn, HOW to accomplish this on his/with his Linux kernel-based operating system running the desktop environment of his choice and the software of his choice.

When trying to explain things like "video codec", the Wikipedia goes the Idiocracy way. One step beneath the Microsoft way.

The "everything is a file" paradigm/concept is not only useful to write good software, but also very useful to learn about how to make good use of a computer. …
 * data is stored as a file (in German the new Portmanteau "Datei" from Daten + Kartei was created!)
 * the storage is organized as/by a file system
 * a lot of file systems have been developed/specified
 * for some file systems there are multiple implementations
 * there are many different file structures, specified by very different entities
 * there are libraries/executables to read and write certain file structures.
 * operations can be done to a "file" open, i.e. load into memory by some program to view or to alter (edit) it, copied, moved
 * certain files can be executed, i.d. a process is created;

What the f*ck is D-Bus?

--gapplication-service
Many GNOME applications actually install two binaries now: one in  and one in   (on Fedora!). The libexec one is a D-Bus service and the actual executable code, while the one in /usr/bin is just a wrapper or launcher executable that simply just sends a D-Bus message and quits. You can alternatively launch nautilus by entering:

Why? Where is the difference?

Nautilus makes use of GVfs. In case Nautilus depended on it, who would make sure it is started with Nautilus? Nautilus itself? Systemd? dbus? gapplication?

(Like GVariant, and … GApplication is part of GIO: https://developer.gnome.org/gio/stable/GApplication.html)

.desktop files
.desktop files are simple text-files. It is just that, due to GNOME braindamage "GNOME Files/Nautilus" by default treats them differently. Use the terminal to see/edit them, e.g.: You should not edit them, because your edits are not guaranteed to be persistent, as .desktop files belong to packages and may be overwritten by your package management system.

There is the directory, which should take precedence over the system wide one.

Specification for .desktop-file are done at freedesktop.org, and then implemented by GNOME/KDE/….


 * https://standards.freedesktop.org/desktop-entry-spec/latest/
 * https://developer.gnome.org/integration-guide/stable/desktop-files.html.en
 * https://wiki.archlinux.org/index.php/Desktop_entries
 * German language: https://wiki.ubuntuusers.de/.desktop-Dateien/

How Windows XP did it
In Windows XP you could edit any entry in the "start/launch menu" itself, and additionally the files in the directory. The "start/launch menu" thereby mapped the contents of the directory containing the menu entry files. A directory there was represented by a directory in the "start/launch menu". This could not be more user-friendly.

For GNOME2 there was Alacarte, but it doesn't work in GNOME Shell 3. The way to group "menu entries for applications" in directories, is to use GNOME Software!

power button
When AT was replaced with ATX the "power button" was introduced. It is not connected to the PSU but to the Motherboard. The only thing it does, is send a signal "button press" and the operating system can be configured to do whatever the system administrator want it to do! By default it probably should poweroff the system… I want mine to power off my system. But GNOME does not allow me to do so. Why?


 * One could start a terminal and type.
 * One could edit  to configure the handling of the "power button".
 * One could install some acpid and configure it handle the pressing of the "power button".

The default setting on my OS was nothing and I cannot chose poweroff. Why?

GNOME accessibility
I think Accessibility Toolkit is very fine software that probably deserves a price. See also https://wiki.debian.org/accessibility But I don't want it on my system. On Debian 9 do: If you only removed at-spi-bus-launcher and at-spi2-registryd, GNOME application would take minutes to start! Alternatively one could try sudo systemctl disable at-spi-dbus-bus.desktop org.a11y.atspi.Registry.service org.a11y.Bus.service
 * apt-get purge libatk-adaptor
 * at-spi2-core cannot be removed, because GNOME Files (Nautilus) depends on the package. So remove its contents:
 * /etc/X11/Xsession.d/90qt-a11y
 * /etc/xdg/autostart/at-spi-dbus-bus.desktop
 * /usr/lib/at-spi2-core/at-spi-bus-launcher
 * /usr/lib/at-spi2-core/at-spi2-registryd
 * /usr/lib/systemd/user/at-spi-dbus-bus.service
 * /usr/share/dbus-1/accessibility-services/org.a11y.atspi.Registry.service
 * /usr/share/dbus-1/services/org.a11y.Bus.service
 * /usr/share/defaults/at-spi2/accessibility.conf

Of course, GNOME's Accessibility Implementation Library Gail has been completely merged into GTK+, bringing GNOME yet another step closer to accessibility that's built in, not bolted on. https://help.gnome.org/misc/release-notes/3.2/ Of course you can still remove libgail-3-0 from Debian 9, which packs GNOME 3.22 ;-)

NetworkManager
For a static IPv4/IPv6 edit:
 * sudo systemctl disable network-manager.service
 * vim /etc/network/interfaces
 * vim /etc/resolv.conf

PulseAudio

 * apt-get purge pulseaudio

GNOME button-layout
To tell GTK+ where to place the close,minimize,maximize-Buttons in the GtkTitleBar as well as the GtkHeaderBar enter: Both gtk-menu-image and gtk-button-images were deprecated and ignored, after that they made them deprecated but not ignored… To enable icons in roll-down-menus enter:


 * Debian meta-packages: gnome-core and gnome are bloated. Too keep  working, you need to manually install each component you really want after un-installing the meta-packages…

Differences between GNOME and KDE SC
On the difference between GNOME and KDE SC: https://mjg59.dreamwidth.org/2092.html
 * KDE builds on top of what's already there, while GNOME is happy to flatten some mountains first.
 * KDE assumes a platform and attempts to work around its shortcomings. GNOME helps define the platform and works on fixing its shortcomings.

Differences between GTK and KDE Frameworks 5
Regarding functionality GTK+ must be compared with Qt and not with KDE Frameworks!

Toronto GTK+ hackfest in June 2016
As can be seen in the articles KDE_Frameworks_5 and KDE_Software_Compilation
 * KDE developers first release 5.0, and then guarantee API and ABI stability for this entire 5.x release cycle.
 * in the past GTK developers took the same approach: first release GTK 2.0, then guarantee API and ABI stability, for the entire 2.x release cycle.
 * As explained by Benjamin Otte in this GUADEC'13 video, GTK developers experienced a very serious development delay with this approach. During GTK 3.x it turned out to be complicated to impossible to develop the toolkit further and add the requested features while not being allowed to break API. Thus during the development of GTK 3.x, there were regular API breaks.
 * At the 2016 GTK hackfest in Toronto it was discussed to make this new approach official: blog post 1, blog post 2
 * GTK 4.0 will not be stable, but instead GTK 3.26 (equals to 14 releases during 7 years of development) and GTK 4.6 (equals to 4 released during 2 years of development)
 * this is what the GTK 3.x development cycle has been doing anyway, but now it is official, and developers won't even try to keep the API stable but focus entirely on development and it is planed to release a stable version, which non-GNOME application developers can target, every 2 years.

GTK+ developer blog from 2016-Sep-01
Update as of 2016-Sep-01: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
 * last GTK+ 3.x release: GTK+ 3.22 (autumn 2016) will be the last 3.x release
 * GTK+ 3.22 will receive bug fixes for at least 3 years
 * maintenance after this point may continue, depending on the amount of volunteer resources available
 * distributors of operating systems with long term support release cycles that extend past three years may want to contact the GTK team to establish a policy for back-ports
 * GTK+ Scene Graph Kit has not been integrated into 3.22
 * GTK+ 4.0 development series: following 3.22 will not be 4.0 but instead 3.90, 3.92, … => meaning that the entire GTK+ resources flow into the development of 3.90, 3.92, etc. This development will culminate in the 4.0 release. And with the 4.0 release the resources will be a split into:
 * development series: actual development of 4.90, 4.92, 4.94, … with 5.0 as goal
 * every six months a new even development version will be released
 * new major versions will be released once new features have stabilized, which is expected to be roughly every 2-3 years
 * When bumping to a new major version deprecated API will be removed!
 * Alongside these stable series, GTK+ development will continue in semi-stable development series. These development releases will contain some API changes between minor versions (say between 3.90 and 3.92), although changes will be limited wherever possible. This is the path that we expect GNOME applications to take, but other application developers may choose this option if they want access to the latest features, at the cost of some potential porting work for each minor release.
 * While the GTK+ team reserves the right to change API during development series, this does not mean that the whole GTK+ API will constantly break each release; only specific, and hopefully rarely used parts of the API may change, and if the changes are too extensive they will very likely be delayed to the next major development cycle. We’ll ensure that these changes are well-communicated in advance.
 * stable series: consecutive releases of GTK 4.2, 4.4, 4.6, 4.8, … with no specified development goal
 * whereas previously minor releases were published every six months, now they will be made as and when necessary
 * ! all updates within long-term stable series will be ABI stable !
 * new minor releases may introduce new widgets, or update the implementation of windowing system protocols in the GDK back-ends, but no additional features or theme changes will be allowed

Changes to the Toronto guidelines: It helps to risk a peek at the GTK+ Roadmap. The move away from X11 and the targeting of touchscreens simply requires a certain set of changes. These have to be tackled by the available manpower. Additionally there was Cairo and other stuff. It was certainly more easy to do Clutter, than it will be to integrate Clutter with GTK+. GTK+ Scene Graph Kit proves this.
 * development will be named x.9y instead of x.y;
 * some resources will go into producing a "stable series"

Me (SoctXW) has created and populated Category:Software that uses GTK+. In comparison to Qt much more – quite mature – software that adopted the GTK+ toolkit has been abandoned. Subsurface originally opted for GTK+, then switched to Qt. The authors (Linus Torvalds and Dirk Hohndel) bothered to explain their motivation.

GNOME Office
GNOME Office, in contrast to the Calligra Suite or LibreOffice, was never designed from scratch by any one team. Instead, it consist of applications, which were authored by independent individuals and have been developed by an increasing number of volunteers and GNOME developers. https://wiki.gnome.org/Apps/GnomeOffice
 * Standard: AbiWord, Evince, Evolution, Gnumeric, Inkscape and Ease
 * Other: GnuCash, gLabels, GLOM and Dia
 * Related: HomeBank or Grisbi for the home office

GNOME Chemistry Utils
Retrieved from GNOME article older version

GNOME Chemistry Utils comprises some programs and a library containing Gtk+ widgets and some C++ classes related to chemistry. Their homepage is here: https://wiki.gnome.org/Apps/ChemistryUtils. As of January 2016 they all use GTK 2.x, and maybe people will bother to port them to GTK 3.20 or newer.


 * GChemPaint, a 2D chemical editor
 * GChemCalc, a chemical calculator
 * GChem3D, a molecular structure viewer
 * GCrystal, a crystal structure viewer and editor
 * GSpectrum, a simple spectrum viewer
 * GChemTable, a periodic table of the elements


 * EasyChem, a program to draw high-quality molecules and 2D chemical formulas site
 * Ghemical, a computational chemistry software package

GNOME Chemistry Utils further comprises widgets not in libgtk: a periodic table of the elements (/GtkPeriodic and /GtkComboPeriodic), a crystal structure viewer (/GtkCrystalViewer) and a molecular structure viewer (/GtkChem3DViewer).


 * See KDE's Kalzium for off-line working or Periodic table in Wikipedia for on-line working. In case you wish some animation (change over time) instead of colors regarding timepoint of isolation maybe search YouTube. Or info regarding crystal system, [magnetism]], etc.

GStreamer confusion and howto deal with multimedia files in general
Both authors I read, Fred Brooks and Andrew Tanenbaum, stressed how superior a certain approach to software is: one distinct application per "task". The problem is the definition of "task". A widespread definition seems to be: "deal with multimedia files (play, edit, tag, manage, etc.) regardless where they are located". With my knowledge I have arrived at a different definition:
 * manage any kind of file: use directory structure of file system and avoid the brtfs-feature "multiple-volumes" (multiple because I haven't required this so far and the complexity overwhelms me), use file browser and GNU tools (cp, mv, etc.) => no additional file database
 * in case I need to store files remotely, I prefer setting up a solution employing the Network File System protocol or the Server Message Block protocol (what would I need WebDAV for?)
 * I prefer one distinct application
 * for watching motion pictures: VLC media player; the plumbing is identical to the software for listening to music, but the interface needs to be entirely different!
 * alternatives using SDL:, mpv, mplayer2
 * for listening to music (audio): Audacious
 * alternatives:  from alsa-package, alsaplayer, mpg123, mpg321, PlayItSlowly used GStreamer
 * for tagging: Puddletag; I prefer its user interface over Ex Falso, EasyTag, tagtool, MusicBrainz Picard
 * for simple audio recording: GNOME Sound Recorder
 * alternatives: arecord:  (from alsa-package)
 * for simple video recoding: Cheese (software), Guvcview
 * for converting the codec or file format (container): CLI-tools ffmpeg/avconv, though the write-to-file plugin of audacious offers a nice GUI (it uses GStreamer, afaik)

As far as I can see, GStreamer is absolute overkill for the above use cases. Not until trying out   did I truly understand the idea behing GStreamer:
 * depicts the overkill, because it would be pointless to write the entire GStreamer framework for such simple use cases!!!!

Connect some USB video camera (and a microphone to a USB sound card) to some cheap Raspberry Pi-like computer, run some Linux distribution on it. For the task of "getting the video and the audio stream in real-time to some other computer" GStreamer and the RT protocol provide a simple solution:


 * On the transmitter
 * On the receiver

I don't even like PulseAudio, because my sound card, DOES HAVE a hardware mixer. Sadly the device driver for Linux, does not support that functionality at all, not to mention handling this hardware mixer, like handling PulseAudio (which consumes CPU time and does lag sometimes behind). See e.g. paprefs for something graphical. While AMD TrueAudio sounds like a good idea (an audio acceleration DSP), it is not documented, unsupported under Linux, and relies on a additional sound card/sound codec.

Debian releases

 * Rocks'n'Diamonds, Zaz, … But cool stuff you find in Fedora but not in Debian:
 * https://apps.fedoraproject.org/packages/pipepanic http://www.users.waitrose.com/~thunor/pipepanic/
 * https://apps.fedoraproject.org/packages/gnome-2048

libgtkflow

 * GObject and libgflow: abstract representation of a data flow
 * GTK+ and libgtkflow: graphical representation of a data flow

https://github.com/grindhold/libgtkflow

udisks2 vs storaged
Fedora 25 is going to replace udisks2 (cf. GVfs, udisks) with storaged:
 * https://fedoraproject.org/wiki/Releases/25/ChangeSet#Replace_UDisks2_by_Storaged

That means more "enterprise features" in my desktop operating system. Adding much more complexity to it. For persons who think they are required to understand their operating system, this means: learn even more about stuff, that is absolutely superfluous in your desktop computer.