@dave concerning the gtk problem

maybe this will help.

desktop-defaults-run is running using the root account's gtk settings. any app running with desktop-defaults-run will launch with whatever the gtk theme is for the root account, which at the moment happens to be Raleigh.

apps launched directly by the user through the application menu (rox-term instead of terminal for instance) launch with the user's gtk settings.

***edit*** interestingly I don't seem to be able to change the root account's gtk theme with appearance. The changes don't take effect.

Now that is really strange that desktop-defaults-run is running as root. Does it even ask for a password?
I have never had it ask for the root password.... But I cannot test at the moment and verify. They do all seem to be gtk 3 though?

For the root account you will need to have bashrc load /usr/local/lib/desktop-session/desktop-session-xdg-dirs.sh
It needs the export for gtk2, but I do not have one for gtk3....

Dave wrote:Now that is really strange that desktop-defaults-run is running as root. Does it even ask for a password?
I have never had it ask for the root password.... But I cannot test at the moment and verify. They do all seem to be gtk 3 though?

For the root account you will need to have bashrc load /usr/local/lib/desktop-session/desktop-session-xdg-dirs.sh
It needs the export for gtk2, but I do not have one for gtk3....

apps don't launch as root and no password is asked for, but it is using the Raleigh theme, which is the root accounts (or maybe default?) theme.

skidoo wrote:here are fbgrab images

Brilliant! Thank you. I will send you some new configs to try.

(er, fbcat)(why is fbcat not pre-installed? it's only 59Kb)

Didn't know about fbcat. Thanks.

the gtk theme issue I mentioned earlier also occurs on the a3 (not a3.2) liveCD, and on an installed system. It almost seems random. I haven't been able to figure out when the problem comes up, but I think its when the filemanagers launch.

Also, I think the filemanager-switching with the desktops is overly complicated. It made sense back when there wasn't a desktop-session app running but not so much now. Plus since you have to enable a switch in a .conf file to make filemanager selected in desktop-defaults actually become the default. The whole desktop-defaults system makes sense except for the filemanager selection. I think the auto-filemanager switch with the desktop environment needs done away with in favor of the selection in desktop-defaults.

development video of the gtk theme issue I've been babbling about.

this video is unlisted on my channel.

Digging and Digging and Digging... but gtk issues still persist.
Could you try a bit of a hack for now?

Edit /usr/local/bin/desktop-defaults-run
@ line #4 enter However this will only fix the problem of the gtk theme not being found for anything started with desktop-defaults.
This problem was a massive PITA and now has come up again, so I do not know how much trust I put into this being the full solution.

I have read countless posts online that seem to have the same problem, but now instead of truely fixing the problem the"fix" is to copy entire themes to ~/.gtk.... or throw the above export line into several .desktop files, scripts, startups, etc....

If you would like to see a real mess remove the above export line from the bottom of /usr/local/lib/desktop-session/desktop-session-xdg-dirs.sh.

This seems to be related to certain programs as they are seemingly orphaned. (PPID = 1). Any that are based on desktop-session or another process like the Window Manager, have the export from desktop-session-xdg-dirs.sh and open gtk correctly.

Now on that note, the above hack does not seem to patch it 100% either as it only refers to gtk2 not gtk3 items... however I cannot find an similar export line for gtk3 so that leaves them hanging with the default raleigh theme...

On that note, researching the ability to use gtk(2)(3) apps standalone seems to be done away with for some reason (intentional or not I do not know). Visiting various IRC channels seems to suggest that nobody is really sure why the various gtkrc's / gtk.ini files are being ignored. So I thought well lxappearance still allows for the options, but why then does lxde not have this issue? Well it seems that lxde session has a built in xsettings daemon (good for moniter, fonts, icons, colors, mouse, keyboard,sound,etc settings). So lxde has the option but only for the sake of making lxappearance standalone, because in reality lxde does not use the rc/ini files directly. This made me investigate further into how xfce does gtk handling, and why Jerry did not have any bash exported variables to make it work in MX. And as it seems xfce is using an xsettings daemon as well (xfsettingsd). KDE, GNOME, MATE, UNITY, etc... all xsettings daemons.

So installing xsettingsd as a test and setting up a config (~/.xsettingsd) like so.... and adding xsettingsd & to desktop-session startup seems to make everything look correct and a little more crisp.

Now xsettingsd has not GUI for configuration and lxappearance does not work with it. So this is not really usable (and it is one more thing running that really should not be) . However after a few more days research it seems that gtk is loosing the option to run independent in favor of needing a xsettings daemon. In the same fashion as sysv-init being supported as an alternate init system to systemd, it is becoming extremely difficult to use...

Though it does seem overwhelmingly due to the desktop* scripts. Removing the export from /usr/local/lib/desktop-session-xdg-dirs.sh will show the true colors... as will doing a fresh install of 13.2 and updating it to testing / sid. (At least here). So if there is any other information that anyone can come up with to try to see how to make it work as before (like in antiX 13.2 *NOT UPDATED*). It would be extremely appreciated. Otherwise I think we will have to move to using a minimal xsettings daemon.
I have not looked into how any other minimal system finds a solution to this. Maybe that is the next direction to look.

dolphin_oracle wrote:the gtk theme issue I mentioned earlier also occurs on the a3 (not a3.2) liveCD, and on an installed system. It almost seems random. I haven't been able to figure out when the problem comes up, but I think its when the filemanagers launch.

Also, I think the filemanager-switching with the desktops is overly complicated. It made sense back when there wasn't a desktop-session app running but not so much now. Plus since you have to enable a switch in a .conf file to make filemanager selected in desktop-defaults actually become the default. The whole desktop-defaults system makes sense except for the filemanager selection. I think the auto-filemanager switch with the desktop environment needs done away with in favor of the selection in desktop-defaults.

Turning on the override in the config produces the desired result?
If so do you think this should be the default?
And on that note which file manager should be set default?

I would be ok with removing the auto switching entirely, but I though it was desired to have the same file manager as desktop option.
I don't know about everyone else here but personally I would strongly dislike having to reset defaults on each live cd boot, rather than choosing another session. This was one of the driving motivators, because it was very unamusing to boot space-icewm option and having to change every menu item from rox to space. Now that might not be such a big deal anymore because the one spot changes all, but..... that is just my opinion. ( Probably similar in feeling to the startup window stuff and having to close it every boot.)

Turning on the override in the config produces the desired result?
If so do you think this should be the default?
And on that note which file manager should be set default?

I would be ok with removing the auto switching entirely, but I though it was desired to have the same file manager as desktop option.
I don't know about everyone else here but personally I would strongly dislike having to reset defaults on each live cd boot, rather than choosing another session. This was one of the driving motivators, because it was very unamusing to boot space-icewm option and having to change every menu item from rox to space. Now that might not be such a big deal anymore because the one spot changes all, but..... that is just my opinion. ( Probably similar in feeling to the startup window stuff and having to close it every boot.)

can the default be set to antiX-Filemanager.sh, so that you can choose rox, spacefm, or antiX-Filemanager (or switch with desktop, or whatever) from desktop-defaults. This would get rid of the need for the override, and have the default be the switching, but when another choice is set in desktop-defaults, it will automatically"stick".

for me, choice of desktop doesn't necessarily mean I want to switch file-managers, and its jarring if you don't expect it, but wasn't a big deal in 13 since there wasn't an app purporting to set the default file-manager. Now that there is an app for setting the default file manager, the choices of that app should really be respected without having to dig into a .conf file to flip a switch.

Hmm interesting...
yes I can separate them again and give it a go, but that does duplicate some code.
Seeing how they did the same thing antiX-FileManager.sh and now desktop-defaults i did combine them and made it configurable... I will relook into it though. Maybe the config file could be exchanged for just a .desktop file set as the default.

Edit /usr/local/bin/desktop-defaults-run
@ line #4 enter
Code:
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"


However this will only fix the problem of the gtk theme not being found for anything started with desktop-defaults.
This problem was a massive PITA and now has come up again, so I do not know how much trust I put into this being the full solution.

well, at a minimum it cleared up the problem for desktop-default-run. apps run that way now launch with the correct gtk theme.

@ D.O.
If you would like to try the updated desktop-defaults-run have a look here

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/desktop-defaults"
linktext was:"https://github.com/antiX-Linux/desktop-defaults"
====================================


You should be able to download
/usr/local/bin/desktop-defaults-run
/usr/share/applications/antix/desktop-defaults-follow-fm.desktop
/usr/share/desktop-defaults/file-manager.desktop

and copy them into that location on the system.
running desktop-defaults-run -fm should use the selected (the new .desktop and the changed symlink make it follow by default)
running desktop-defaults-run -fm --follow should follow the session (or running the new .desktop file)

Related to this

dolphin_oracle wrote:

Edit /usr/local/bin/desktop-defaults-run
@ line #4 enter
Code:
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"


However this will only fix the problem of the gtk theme not being found for anything started with desktop-defaults.
This problem was a massive PITA and now has come up again, so I do not know how much trust I put into this being the full solution.

well, at a minimum it cleared up the problem for desktop-default-run. apps run that way now launch with the correct gtk theme.

Do you feel that this"fixes" the gtk problem well enough ?

Do you feel that this"fixes" the gtk problem well enough ?

I think yes. At least, I haven't been able to launch an app via any other method (command line, run box, etc...) and duplicate the problem since adding that export line.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/1393"
linktext was:"http://permalink.gmane.org/gmane.linux. ... .user/1393"
====================================

"If there are something left under your .wh..wh.plnk or .wh..wh..tmp, it is an unexpected situation for aufs and may be a problem."
-- Junjiro R. Okajima (aufs author/maintainer)

dynamic root persistence, semi-automatic mode
I discovered ~68Mb of files sitting in /live/aufs-ram/.wh..wh.plnk/

While skimming the content in some of the files pathed here, I found a reference to"mtpaint" (an app I never use).
I've arrived at this guess, as to the scenario which produced the stranded files:

= = = = =

In testing the 14-a3.2 mini-release this time, I had initially chosen a TINY (smallest offered) rootfs size.
When BitJam asked for"fbgrab" screencaps, I installed fbcat package... followed by (dunno another way to convert PPM to jpg)
imagemagick package, plus its boatload of dependent packages.

At shutdown, the persist-save operation failed, due to insufficent space (changes currently held in RAM exceeded size of rootfs container).
Mumbling"aw, crap...duh!" I rebooted, resized the rootfs, installed fbcat+imagemagick again & successfully performed persist-save.

Log from the imagemagick install shows I'm calling this a"bug".
68Mb isn't earth-shattering, but the stranded files unnecessarily bloat the rootfs
& could accumulate, resulting from multiple (failed) persist-resize operations.

edit:
I deleted the files from"plnk" directory immediately after reporting this (Nov21) and have been monitoring it for new files.
Today, mid-session, one new file appeared.
filename is 10383.875271 the name probably indicates"dirInode.fileInode", but IDK how to match that against current inodes
filesize is 139 bytes
permission/owner: -rw-r--r-- root:root
lastModified: 2014-10-08 07:22

file contains these 4 lines plaintext FWIW, during this install, I've not used crontab nor gweled (nor messed with etc/ssl)
[/color]

==================

update:

Someone else should verify this. AFAIK, it is consistently repeatable:

On a freshly installed iso, setup dynamic root persistence, semi-automatic mode.
Inspect /live/aufs-ram/.wh..wh.plnk/ and note that it is an empty dir.
From terminal, or via synaptic (same result either way)"apt install aspell" to upgrade that package
and, immidiately afterward, note that stranded files now exist in the .wh..wh.plnk directory.
At shutdown, perform a persist-save.
Upon reboot, note that the stranded files remain (are persisted).

I've determined that files are getting written to the plnk directory during every / any package upgrade operation.
Using the aspell example, I determined that one of the stranded files is a copy (md5sum identical) to /usr/bin/aspell-input
and, across several tests (upgrading various packages) I've determined that the plnk directory can be (and should be) removed prior to performing a persist-save.

TODO: check whether files accumulated in plnk directory of my antix 13.2 pendrive

FWIW, after emptying the plnk dir, I've tested manually editing /usr/bin/aspell-input and the manual edit does not cause appearance of a new entry in the plnk directory.

@BitJam
here are second-time-around (revised templates) fbgrab images

all these look perfect in Ctrl+Alt+F5 consoles
1920x1080 1600x900 1440x900 ...but for the latter 2, during live init, the text is still overflowing past the bottom decorative frame.
I tried tweaking the template values, but doing so only seemed to affect the (screencapped) terminal output.
(? the initramfs contains an overriding bootsplash default template?)

tgz file contained a"verbose-1366x768.png" ( note: a"silent-" imagefile for that resolution was absent, so I copied one into place )
but it seems my system doesn't support a 1366x768 mode.