gnomegnome3notifications
IMHO the notifications in GNOME (3) are hidden very quickly. Of course, it depends on the user, how fast he/she can read that notifications or so. So is there any way to change how long the notifications are displayed before they are hidden?
Quickly searching through dconf I could not find any setting for this.
Cross-posted from Ask Fedora.
This answer is not fully canonical--see Answerer's note at the end.
In this answer, I intend to provide concise explanations based on actual experience in Debian-based distributions (Xubuntu and Debian Xfce). Anyway, I have confirmed that the fonts settings doesn't take effect immediately for Qt applications in GTK+ environment of Debian.
First I don't know what tool to use.
If you are an experienced user, don't use any third-party configuration tool.
For convenience, users tend to use such tools like GNOME Tweak Tool. For best compatibility however, prefer to use graphical configuration tools provided by the desktop environment or respective toolkits. Else, use more advanced tools such as Dconf, Xfconf, or GSettings.
Oh, and then there is qtconfig, which seems to come in two versions, one for qt4 and qt5. I probably even missed a few.
Use qt4-qtconfig for Qt4, and similarly use qt5ct for Qt5.
To check which version of Qt used by particular application, trace the package dependencies using APT. For example, I have VLC installed in Xubuntu. Since VLC is using Qt, I can query the APT cache and use 'qt' as the keyword to filter any Qt dependencies.
$ apt-cache depends vlc | grep 'qt'
Depends: libqtcore4
Depends: libqtgui4
In this case, the result hinted that VLC is using Qt4 toolkit.
Another way is to check if any Qt packages have been installed. This can be done by running Dpkg command. I choose to filter the package that contains these keywords, 'libqt' and 'gui', since the earlier APT command above has hinted so.
$ dpkg-query -W | grep 'libqt' | grep 'gui'
libqtgui4:i386 4:4.8.5+git192-g085f851+dfsg-2ubuntu4.1
In this case, the result is showing Qt4 of version 4.8.x is installed. In case Qt5 package is installed, the result will contain libqt5gui5 instead of libqtgui4. Naming is different for Qt5, which is why I use grep twice to filter the result.
Currently, the fonts I see do not correspond to the font-settings of any of those tools.
As hinted earlier by L. Levrel, the system setup is messy. Never mind for GNOME/KDE/Qt applications, but running gnome-settings-daemon in Xfce system? Xfce has its own settings daemon xfsettingsd that is provided by this package xfce4-settings in Debian.
In the following screenshots, I am running Xfce Appearance, Qt 4 Settings and VLC media player in Xfce desktop environment, using Xubuntu and Debian Xfce. Then, I changed the default font from "Droid Sans (Regular)" to "Droid Sans (Bold)" at same font size 10.
For Xubuntu, the font settings were applied immediately for both GTK+ and Qt applications. The font specified in Xfce Appearance was sufficient to affect system wide, regardless of toolkit used.
For Debian Xfce, the font settings were applied immediately for GTK+ applications only. I had to use Qt 4 Settings to change default font in Qt, from "Sans Serif (Normal)" to "Droid Sans Mono (Regular)". I also had to manually save from the menu bar before the changes were applied.
Despite both Xubuntu and Debian Xfce were running xfsettingsd, Debian Xfce did not honour the font settings automatically for some reason. Possible clue: Debian Xfce may be missing certain packages that allow Qt applications to read system settings automatically.
Is there an established standard how these settings tools interact?
Likely no. This is why user should not use third-party tool to configure system settings. End users wouldn't know how these tools interact with each other, or these tools are unlikely designed to work in such mixed setup environment.
Do the various setting tools overwrite each other's data?
This depends on how the configuration tool works. If two different tools share same underlying configuration method i.e. GSettings, then both will supposedly read the same configuration file.
In the first screenshot, notice that Qt 4 Settings is still showing "Droid Sans (Regular)" instead of "Droid Sans (Bold)". The system wide settings in Xubuntu has changed, but the Qt 4 Settings doesn't reflect the changes immediately, possibly due to different toolkit in use. When quit and launch again, Qt 4 Settings will now show the latest font settings "Droid Sans (Bold)".
For the rest of questions, I'd suggest to look into the following linked pages for further reading.
Disclaimer: This answer is mainly based on my experience in Xubuntu 14.04 and Debian 8 Xfce (both running Xfce 4.10). Despite running a similar desktop environment, the experience was slightly different for the font settings to take effect. Known limitations are as follows.
TL;DR Don't mix tools created for a different environment; Don't use third-party configuration tools. Use graphical tool provided by desktop environment or respective toolkits.
Answerer's note: I had written this answer to be sufficient, but not fully canonical at the time. Hence this answer is now a community wiki, so that anyone with minimum reputation can improve this post to keep up with latest changes in each toolkit, or even re-explain the font settings discrepancy using a more concise example (if done so, remove relevant text from "Disclaimer").
Since gnome-shell exposes a JS eval interface on DBus which has access to all variables, the feat is possible with the following command:
gdbus call --session --dest org.gnome.Shell \
--object-path /org/gnome/Shell \
--method org.gnome.Shell.Eval \
"imports.ui.status.keyboard.getInputSourceManager().inputSources[0].activate()"
Which will activate 0th layout, and so forth. It is trivial to assign these commands to, say, underutilized 無変換 and 変換 on your Japanese keyboard.
And this is how to switch to last used input method (from comments):
gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell \
--method org.gnome.Shell.Eval "imports.ui.status.keyboard.getInputSourceManager()._mruSources[1].activate()"
Best Answer
As for now the answer seems to be: There is a ticket for this.
It does not seem possible yet, as a user on Ask Fedora found out.