On Fri, Feb 21, 2025 at 08:19:28PM -0600, Matthew D. Fuller wrote: > On Wed, Feb 19, 2025 at 09:35:54AM -0600 I heard the voice of > Quentin Barnes, and lo! it spake thus: > > > > At this stage, I'm primarily looking for feedback if what I had done > > made sense and was a good solution to the problems I'm attempting to > > address. > > What I recall from looking at it at the time was that it seemed > conceptually reasonable, and the discussion seemed to converge to a > reasonable-sounding implementation.
That's what I gathered from the discussion of my implementation. I just didn't know about the bigger picture of its concept overall. I also didn't know if I had any errors of omission on my part where others' use cases might need additional variables. > Though I don't recall looking too > much at the actual code, so I guess we should check that it works > right when you link it into sshd. I'm not sure what you mean by linking it into sshd. Could you expand on how one might test that way? Did you mean run ctwm over an ssh tunnel? > IWBNI we could do something smarter with MonitorLayout, but all the > smarter things I came up with were incredibly dumb. I don't think I > ever convinced myself just what the right thing to do with no XRR info > was; we should probably at least have some kinda signal that it's > getting fake info, if give fake info. I'll give it a shove back up my > stack and see what I can see... That's unfortunately one of those areas my knowledge domain is nearly nil. I maybe think I see where you might want to go with MonitorLayout. What I understand is MonitorLayout creates an abstraction of one or more aliases for new virtual "monitors" on top of slicing up what's a physical or virtual monitor. If you just want to utilize the underlying physical monitors and their geometries (like I do), MonitorLayout seems to just get in the way. I couldn't come up with an modification of its approach that would allow reuse for my purposes. (Although, I didn't think terribly long about it.) Maybe someone else will have some inspiration. > > > > Back then and now, I wasn't sure what documentation needed to be > > > > modified for the change. If my fix is still acceptable, what doc > > > > files should I look at modifying? Anything besides "ctwm.1.adoc"? > > Yeah, there's a bit in the manual there describing the other m4 vars, > so it'd slot in with them. Here's a first pass: https://github.com/qbarnes/ctwm-mirror/tree/monitor_vars_man_page Let me know if there's any adjustment to language or style. As you'll notice, I had to use a "pass:[​]" trick to get adoc to correctly parse "`n`" so it matched formatting of similar variables in the doc with a flexible component. If there's a better way, please let me know. > > > > On other issues, I noticed some problems when updating my patch. > > > > Specifically, "cmake_files/do_install.cmake" was overlooked by the > > > > recent md->asciidoc changes causing "make install" to fail. > > Ridiculous. Nobody would be dumb enough to miss changing that. I'll > be sure to remove any evidence of such a thing happening. If it > happened. Which it obviously didn't. :) > > I've never used cmake directly either. I just used "make". I'm on > > Linux (Fedora 41) if that makes a difference. I'm not sure why it > > decided to invoke cmake under the covers, [...] > > 'cuz cmake is the build system. The base Makefile just has some > simple targets that thunk through to it for the simple cases, so you > don't have to worry about the details. For more involved cases or > where you'd want more control, you'd generally be doing that yourself > (e.g., any distro package probably ignores /Makefile completely and > manually does whatever cmakery makes sense for them), but who wants to > think too much if you don't have to? So it sounds like `Makefile` is just a bootstrapping facade. If cmake detects anything has changed since it was last run, it re-generates. > -- > Matthew Fuller (MF4839) | [email protected] > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream.
