Arch Linux BBS - Applications & Desktop Environments

Hi. I used to use the anonymous login on Nautilus to access shared storage. It appears to have disappeared and been replaced by a demand for a username, workgroup and password.Can I get it back ?It appears to be something deliberate, as I tried booting from a Ubuntu key and it works fine there, so presumably it is not the server.If I cancel it goes through to displaying the shared folders, it just won't connect any more.I can connect via nfs and the command line fine.(Later)Found the answer. Need to access the shares seperately e.g. smb://192.168.1.70/homes rather than just smb://192.168.1.70

The option to choose the color can be much interactive. so i think its better to do a dry run first and choose the color and then select the source index when combining with qs..

You have tried with the manual method described at https://wiki.archlinux.org/title/ICC_profiles#Wayland ?

seth wrote:newer builds of vivaldi break HW acceleration under Wayland/HyprlandSame for* an X11 session* a different wayland compositor (weston)* --ozone-platform=x11?Don't have X11 on this system, but sway behaves the same way.Interestingly the platform=x11 *seems* to fix the issue although it is probably just a bandaid rather than a real fix, right? I have to figure out the HiDPI config for that one, window is huge Graphics Feature Status ======================= * Canvas: Hardware accelerated * Direct Rendering Display Compositor: Disabled * Compositing: Hardware accelerated * Multiple Raster Threads: Enabled * OpenGL: Enabled * Rasterization: Hardware accelerated on all pages * Raw Draw: Disabled * Skia Graphite: Disabled * TreesInViz: Disabled * Video Decode: Hardware accelerated * Video Encode: Software only. Hardware acceleration disabled * Vulkan: Enabled * WebGL: Hardware accelerated * WebGPU: Hardware accelerated * WebGPU interop: Hardware accelerated * WebNN: Disabled

seth wrote:i didnt think it would be a big dealIt's not but it's better to get to the bottom of this than to pitch anecdotal resolutions.You can check older journals to see whether you had those secrets-encryption-key related errors.sudo journalctl | grep -C3 secrets-encryption-keyi did checked journal but didn't see any messages about that, the message was very generic about dependency too, unfortunately i kept clearing the journal every time i tried new things to see the logs because the old messages threw me off, so now i don't have the exact error message it gave me, probably a horrible practice that's why i deleted that from the original post i made

Hmm, that's odd..I mean, it's not as though it totally ignores my fontconfig. As mentioned, adding the following does actually make it do what I want (though at the cost of replacing Arial everywhere):<alias> <family>Arial</family> <prefer> <family>Noto Sans</family> <family>Noto Naskh Arabic</family> </prefer> </alias>But I guess it seems that Firefox respects some things in fontconfig and not others.

\o/Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.Thanks.

That fixed it, thanks!

Sounds similar to https://bbs.archlinux.org/viewtopic.php?id=312291 (chromium + kwallet, unresolved)

Last issue that this configuration creates, is that because LAlt is a modifier that now jumps to a different group on-press I now always switch from the US layout to any other as opposed to going to the next because in the moment of activating the binding I am in the US layout. I've partially resolved it by putting a 0.2s sleep before calling the command to change layouts and invoking it on key release instead of press, but it is still not quite ideal.From the perspective of how pleasant it is to switch between keyboards, the approach of creating a virtual modifier that gets sacrificed later in the keybind processing would be nicer. However, this approach is so much simpler and cleaner I think it is worth it.

There's nothing to monitor, but there's https://aur.archlinux.org/packages?O=0&K=noglycin

If not solved, I did a test on the latest Fvwm3 GitHub (fvwm3 1.1.5 (1.1.4-8-g843e7fd6b). It works fine with xterm. Check the screenshot.

Gnome ships it in the gnome shell package so Arch ships it in the gnome shell package. There's nothing inherently special about this and how this has always worked, what exactly do you expect Arch to do?

If this helps you want to figure which parameter is critical - "intel_idle.max_cstate=1" is the worst one, so rule that out first.Ie. try whether you can remove "intel_idle.max_cstate=1" w/o breaking things, then to cut down the other ones - I suspect it's "i915.enable_dc=0"?

Well for this case it’s the nvidia-390xx-utils package from AUR, and updating it fixed the issue. Thank you for your time