Logs: liberachat/#xmonad
| 2022-05-04 21:44:03 | <moonsheep> | is it a good idea to run xmobar within the same process as xmonad? (something like "forkIO $ xmobar config") |
| 2022-05-04 21:44:11 | <moonsheep> | btw what's the proper way to format inline code here? |
| 2022-05-04 21:44:22 | <geekosaur> | best bet is to use a pastebin |
| 2022-05-04 21:44:25 | <geekosaur> | @where paste |
| 2022-05-04 21:44:25 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2022-05-04 21:44:42 | <moonsheep> | even if for <30 char snippets? |
| 2022-05-04 21:44:55 | <geekosaur> | if you use matrix instead of irc, it will format and pastebin stuff for you |
| 2022-05-04 21:45:10 | <geekosaur> | short one-line stuff is fine. irc doesn't really do formatting though |
| 2022-05-04 21:45:20 | <moonsheep> | ah, thank you |
| 2022-05-04 21:45:44 | <moonsheep> | anyway, should I run xmobar in the same process as xmonad? |
| 2022-05-04 21:45:49 | <moonsheep> | or is that as stupid as it sounds? |
| 2022-05-04 21:45:57 | <geekosaur> | anyway you can't really run other stuff in xmonad threads, unless it opens its own server connection and even then it'll be limited |
| 2022-05-04 21:46:44 | <geekosaur> | Xlib doesn't really support multithreaded. if you make a specific call before opening the server it'll lock its global state around every call which slows everything down. |
| 2022-05-04 21:47:01 | <geekosaur> | (we mostly don't but get away with it; this is probably luck) |
| 2022-05-04 21:47:36 | <geekosaur> | that is,m there are a few contribs that do X calls in threads when they probably shouldn't because we don't tell Xlib to maintain its global state lock |
| 2022-05-04 21:47:45 | <moonsheep> | but from the pov of xmonad, what's the difference of xmobar running in a separate thread than in a separate process? besides, shouldn't that make communication easier? |
| 2022-05-04 21:47:58 | <geekosaur> | it makes communication harder, actually |
| 2022-05-04 21:48:09 | <moonsheep> | oh, because X maintains process-wide state? |
| 2022-05-04 21:48:38 | <geekosaur> | xmonad's main loop is not a full main loop like in e.g. a gtk app, it supports only XNextEvent and will not handle things like timers. and its state is designed to be single-threaded |
| 2022-05-04 21:49:02 | <moonsheep> | right |
| 2022-05-04 21:49:15 | <geekosaur> | you could hypothetically use TChans to communicate but anything that would block poses problems |
| 2022-05-04 21:49:52 | <moonsheep> | I feel like it would be so beautiful to actually configure everything through haskell and have xmobar be but another xmonad module |
| 2022-05-04 21:50:00 | <moonsheep> | oh well |
| 2022-05-04 21:50:22 | <geekosaur> | someone else here (abastro[m] I think, but they seem not to be here now) was trying to do it the other day and I was explaining all the shortcomings and limitations |
| 2022-05-04 21:50:46 | <geekosaur> | we'd really6 need a more complex main loop and better handleEventLoop support for it to work |
| 2022-05-04 21:50:47 | <moonsheep> | btw, is this situation any better with wayland? |
| 2022-05-04 21:53:33 | <geekosaur> | both xcb and wayland avoid global state, but server connections are inherently single-threaded |
| 2022-05-04 21:53:56 | <geekosaur> | (think about it. a message comes in from the server: which thread should read it? you have to read it to find out) |
| 2022-05-04 21:54:27 | <moonsheep> | right |
| 2022-05-04 21:55:51 | ← | moonsheep parts (~user@185.154.9.192) (ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-04 21:56:29 | <geekosaur> | gtk has a subsystem for routing stuff between the main gtk thread and subthreads so that multithreaded programs can use it |
| 2022-05-04 21:57:07 | → | moonsheep joins (~user@185.154.9.192) |
| 2022-05-04 21:57:14 | <geekosaur> | gtk has a subsystem for routing stuff between the main gtk thread and subthreads so that multithreaded programs can use it |
| 2022-05-04 21:57:36 | <geekosaur> | xmonad doesn't and in general doesn't need it |
| 2022-05-04 21:58:30 | <geekosaur> | we're more about minimal, so putting statusbar functionality in a different app process makes more sense to us (and to the xmobar maintainers) |
| 2022-05-04 21:58:52 | <moonsheep> | so then how should my config look? a directory with all the xmobar stuff, which gets compiled into an executable that's run by xmonad on initialization? |
| 2022-05-04 21:59:29 | <geekosaur> | there is some stuff for adding status items to the stuff we send to a status bar, but the clock one provided shows the limitations: since it only runs as part of the logHook, you'd only see the time update after a focus change or etc. |
| 2022-05-04 21:59:37 | <geekosaur> | yes |
| 2022-05-04 22:01:41 | <moonsheep> | I still feel like it would be way nicer if you could communicate with things like the status |
| 2022-05-04 22:01:41 | <moonsheep> | bar with primitives like channels though |
| 2022-05-04 22:01:51 | <moonsheep> | oops |
| 2022-05-04 22:02:19 | × | moonsheep quits (~user@185.154.9.192) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-04 22:02:38 | <geekosaur> | eventually you're putting too much stuff in one process. that's kinda the gnome way of doing things, and it has the shortcoming that your whole session dies if any component does |
| 2022-05-04 22:02:56 | <geekosaur> | (especially noticeable under wayland since one of those components is the compositor) |
| 2022-05-04 22:02:58 | → | moonsheep joins (~user@185.154.9.192) |
| 2022-05-04 22:03:04 | <geekosaur> | eventually you're putting too much stuff in one process. that's kinda the gnome way of doing things, and it has the shortcoming that your whole session dies if any component does |
| 2022-05-04 22:03:06 | <geekosaur> | (especially noticeable under wayland since one of those components is the compositor) |
| 2022-05-04 22:03:20 | <moonsheep> | fair enough |
| 2022-05-04 22:04:52 | <Hash> | Hey guys |
| 2022-05-04 22:04:58 | <Hash> | I lost my logs and I need you guys |
| 2022-05-04 22:05:29 | <Hash> | So, remember last year, I had this problem, where if using plasmashell kde panels with Xmonad, something changed and it won't show menus anymore or context menus |
| 2022-05-04 22:05:52 | <Hash> | So I had to edit some source in some KDE plasmaframework package, and make it compatible. I can't for the life of me find that info again |
| 2022-05-04 22:05:58 | <Hash> | I know I posted it here Xmonad channel. |
| 2022-05-04 22:06:10 | <Hash> | Can someone please, if you have a chacne, and you don't mind, grep your logs for me please? |
| 2022-05-04 22:06:31 | <Hash> | I need that patch. I'm sure I posted it somewhere as a link. I have the old compile packages and source, but I can't remember which line I edited. |
| 2022-05-04 22:06:35 | <moonsheep> | just joined today, can't really help |
| 2022-05-04 22:07:02 | <Hash> | just grep for my nickname Hash or 'stoned' |
| 2022-05-04 22:07:16 | <Hash> | And kde and xmonad |
| 2022-05-04 22:08:12 | <Hash> | I can't find it in the channel log online either. |
| 2022-05-04 22:14:16 | <Hash> | https://github.com/xmonad/xmonad/issues/174 |
| 2022-05-04 22:14:20 | <Hash> | I think this might be it. |
| 2022-05-04 22:17:11 | <Hash> | https://bugs.kde.org/show_bug.cgi?id=396177 |
| 2022-05-04 22:20:43 | <geekosaur> | I think that's it. I found the IRC log but it doesn't have details |
| 2022-05-04 22:22:16 | <Hash> | Oh thank you so much dude. |
| 2022-05-04 22:22:18 | <Hash> | I apprecaite you |
| 2022-05-04 22:22:26 | <Hash> | This is it. :) |
| 2022-05-04 22:23:41 | <geekosaur> | it also noted the KDE folks didn't want to fix the bug, sadly |
| 2022-05-04 22:25:58 | geekosaur | wonders (possibly again) if "kdeinit" is enough to get styled KDE stuff without plasma |
| 2022-05-04 22:51:19 | × | moonsheep quits (~user@185.154.9.192) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-04 22:58:25 | <abastro[m]> | geekosaur: It does seem like you can spawn a process which shares a TChan |
| 2022-05-04 22:59:23 | <Hash> | fixed. |
| 2022-05-04 22:59:25 | <Hash> | I don't want to upload a patch, because code changes from version to version. I'll post the exact C++ code needed to be changed. One has to intelligently apply it. Patches online won't work for this kde problem |
| 2022-05-04 23:05:29 | × | werneta quits (~werneta@137.79.215.173) (Ping timeout: 256 seconds) |
| 2022-05-04 23:12:56 | <geekosaur> | abastro[m], I doubt it, it's based on shared memory and distributed STM is quite sa different problem from single-process STM |
| 2022-05-04 23:13:26 | <geekosaur> | you may still have a TChan in the child after forkProcess but it won't communicate with the parent |
| 2022-05-04 23:21:24 | <Hash> | geekosaur: save this somewhere in your bookmarks or channel bot or something |
| 2022-05-04 23:21:26 | <Hash> | https://github.com/xmonad/xmonad/issues/174#issuecomment-1118020397 |
| 2022-05-04 23:21:32 | <Hash> | :) |
| 2022-05-04 23:21:46 | <Hash> | Should be helpful for anyone now using latest KDE and Xmonad together |
| 2022-05-04 23:22:38 | <abastro[m]> | geekosaur: oh, I see. So TChan does not work across process |
| 2022-05-04 23:23:29 | <geekosaur> | I think distributed software transactional memory is still Ph.D thesis material |
| 2022-05-04 23:26:37 | <abastro[m]> | I guess locks are indeed the way to go then |
| 2022-05-04 23:26:53 | <abastro[m]> | Sad haskell lacks proper locks |
| 2022-05-04 23:29:10 | <abastro[m]> | Actually I more and more realize that system tray and dm tools should fire up window managers like xmonad, not the other way around |
| 2022-05-04 23:35:35 | → | werneta joins (~werneta@137.79.199.110) |
| 2022-05-04 23:58:58 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::aa1d) (Ping timeout: 250 seconds) |
| 2022-05-05 00:01:20 | × | werneta quits (~werneta@137.79.199.110) (Ping timeout: 260 seconds) |
| 2022-05-05 00:21:44 | <yuu[m]> | is there a way to abstract having simultaneous sets of workspaces? ideally, i could have a default configuration for workspaces (like naming/enumeration) for every set that could be inherited, but it could be customized if i want. so i have a set 1 for a specific project, and a set 2 for another one. Reading the topics thing, it doesn't seem to be the right tool. |
| 2022-05-05 00:24:49 | <yuu[m]> | also, would be interesting if a certain workspace i could share its state between all sets, but most other workspaces wouldn't share any state. |
| 2022-05-05 00:48:53 | <yuu[m]> | seems like https://github.com/Procrat/xmonad-contexts |
| 2022-05-05 01:12:35 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-05-05 01:12:35 | → | allbery_b joins (~geekosaur@xmonad/geekosaur) |
| 2022-05-05 01:12:38 | allbery_b | is now known as geekosaur |
| 2022-05-05 01:29:11 | × | stackdroid18 quits (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-05-05 01:45:04 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-05-05 02:03:00 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 240 seconds) |
| 2022-05-05 02:24:50 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2022-05-05 02:56:04 | × | td_ quits (~td@muedsl-82-207-238-011.citykom.de) (Ping timeout: 248 seconds) |
| 2022-05-05 02:57:55 | → | td_ joins (~td@muedsl-82-207-238-115.citykom.de) |
| 2022-05-05 03:00:00 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::aa1d) |
All times are in UTC.