> $ strings /usr/dt/bin/sdthotkey|grep dtwmrc > $HOME/.dt/$LANG/dtwmrc > $HOME/.dt/dtwmrc > /etc/dt/config/$LANG/sys.dtwmrc > [...]
> I'd think those would be just be a search path for valid spots CDE might > merge in configuration. Am I wrong and dtwm only wants a single-master > dtwmrc? I haven't looked at the code for this. But given how CDE handles other configuration and resources, those are probably override paths, not merged configurations. So it (probably) looks first in $HOME/.dt, then /etc/dt/config, and so forth (and uses the first file it finds). This is useful because site installs and especially network installs can have a master configuration, then overridden configuration per-machine, per-user, etc... but it doesn't go the full mile with merging. -mrt Original Message From: Swift Griggs Sent: Thursday, June 27, 2019 14:00 To: CDE development Subject: Re: [cdesktopenv-devel] sdtedit freely available ? On Thu, 27 Jun 2019, Richard L. Hamilton wrote: > I have Solaris 9 and 10 systems running. If you have the choice, look > at Solaris 9 rather than 10. Thanks for the tip. I have access to SunOS 4.1.2 - Solaris 11.3 with every major rev (even the rarely used stuff like Solaris 7 (SunOS 5.7) and 2.4 etc... So, I can fire that up easily. > ldd /usr/dt/sdthotkeys shows a bunch more libraries on Solaris 10, that > from the look of the names, have to do with optionally supporting > Trusted Solaris Ewww. TSEC / C2 mode. Yeah, that's not my cup of tea. I don't need MAC for CDE :-) > Should be easier to figure out how it does what it does without > additional complications. Indeed. Thanks again for the tip. > You may be able to use xscope to catch some of any X-based communication > between processes Well, if I could just write something that generates (and doesn't screw up) a dtwmrc file with the right hotkeys in there, that'd be good enough for me. I would scratch my head at any ToolTalk or RPC stuff in something as simple as a keystroke editor, but hey, I'm often wrong, too. > My program (dtwmcmd - send f.commands to dtwm) may be floating around > somewhere; but my website no longer exists, so I've attached a copy. Thanks. Sounds like if I was able to use that functionality it might enable the ability to "notify" dtwm the keystrokes are new and it needs to re-read it's configuration file. However, I can't see it needing more complexity than that. A full dtwm would work in the meantime. > $ strings /usr/dt/bin/sdthotkey|grep dtwmrc > $HOME/.dt/$LANG/dtwmrc > $HOME/.dt/dtwmrc > /etc/dt/config/$LANG/sys.dtwmrc > [...] I'd think those would be just be a search path for valid spots CDE might merge in configuration. Am I wrong and dtwm only wants a single-master dtwmrc? > In other words, it probably looks at the places above (except the ones > ending in tmp and old), and according to that input plus user input That's my read, too. > And perhaps tells dtwm to do an f.restart -noconfirm when it's done > that. Sounds like a very good educated guess. > All of which implies it may have to be able to parse existing dtwmrc > files to determine existing hotkey settings. Yikes. Here's hoping that's not the case, but I think you are a good guesser and probably right. > nm on /usr/dt/bin/sdthotkey definitely suggests it was written at least > partly in C++, given the mangled names. Ugh. Well, that won't be me. I haven't written C++ in 15 years. I've been writing programs in C as recently as last week. Not slamming C++, I'm just ignorant of it, mostly. > that I think means you won't be allowed to redefine keys already defined > elsewhere, although you should read it for yourself, because that's not > exactly what it says. I will, thanks again for all your helpful pointers. Thanks, Swift _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
