Jon Trulson <j...@radscan.com> writes: > On 06/20/2018 06:46 PM, Matthew R. Trower wrote: >>> As for dtudc*, why? Who needs it? >>> If you really want it, there is no reason it could not just be >>> maintained outside of CDE as a separate project -- just requiring a >>> X11/Motif/CDE dev environment to build. >> Is there some strong reason we need to kill it? I understand why there >> might not be priority for others to fix it, but if I were willing to >> repair it, can it stay? I don't know anything about this component >> personally, but I'd like to see the traditional CDE toolkit and >> application base stay intact where at all possible. > > Yes. It is pure evil. It cannot be allowed to exist. > > Ok, the reason I killed it is because: > > 1) I had never heard of it before, it was never in any version CDE I > ever maintained (starting around 1997 or so). > > 2) It generates tons of compiler and coverity warnings. It seems to > actually duplicate some X11 headers (but renames them) for some evil > reason. Ok, I like to use the term 'evil' when looking at that code, > because it just sucks. > > 3) It does not serve any useful purpose that I can discern. I have a > feeling that this was some development tool, created in a hurry within > HP, IBM, whatever and it was just slapped in at the last moment > without any review.
You're right. Kill it with fire. By the copyright in the headers, it appears to be something Fujitsu cooked up circa 1995 for CDEnext. I guess it wasn't successful. > If someone (you) wants to revive it, then please: > > 1) grab it from on older commit before it was removed > > 2) work on it in your own personal repository > > 3) Once it is in shape - cleaned up, builds, runs, does not spit out > tons of compiler warnings, etc, then submit a PR/patch re-introducing > it, and we can review. I might do that some day, but as it doesn't seem to hold much historical value, I'm not going to make it a priority. I have no personal stake in the component beyond (perhaps somewhat morbid) curiosity. I rather doubt anyone is seriously impacted by the lack of this tool... > Well, my point is that dtmail isn't really safe to use on the > Internet. I'm only half-way joking when I say I want to kill it. But > dtmail has been around since the beginning of CDE, so I won't kill it > - I will advise not using though in it's current state. > > I had briefly talked to one of the original developers of it (he > emailed me out of the blue one day), and he told me he had introduced > a lot of things like SSL support and the like that for some reason > never made it into the TOG code base. > > He is retired now, and mentioned he might take up trying to fix it up > again, but that was 2-3 years ago and I haven't heard a peep from him > since. I don't blame him really :) Can you comment on what it needs to pass muster? I mark critical issues as proper imap synchronization capabilities (so it can actually fit into a modern mail workflow; right now IMAP support seems like glorified POP), and SSL support (for security). Of course, people might like things like multiple account support, but I'd count these as amenities rather than core needs. > In short, I want CDE to go down in history as the desktop environment > that exposed the Universe to the spectacle of its own destruction!! > BWAHAHHAHAHAHAH! > > Ok, with some seriousness - I want it to be reliable and useful. I > want it to work on modern systems, and using modern methods, libraries > and the like, while preserving that which makes CDE, well, CDE. Sounds good to me. I hope we can do it without breaking too many legacy systems in the process. > This includes UTF8 support, a more modern build system, and conforming > to modern standards (freedesktop,org, Xrandr, etc) as much as we can > accommodate. > > Of course this also depends heavily on Motif. I want it to be safe - > ie: not introduce security issues. I want it to not make maintaining > it a painful ugly experience. I want a basket of puppies too. > > dtudc* doesn't contribute anything IMO to that. But hey, if you want > to fix it up and re-introduce it as described above, knock yourself > out. Since you mention these things, here's a bit of a sitrep... Hey, as it turns out, XRandR is supported just fine through the current multihead code (as much as multihead works at all, anyway). So that's cool news. There's still fair bit of polish left to do on multihead in general (and on sizing bugs on single-head...). We could really use EWMH support in dtwm. Things like struts, and proper treatment of the front panel, would be really useful, I feel. CDE actually does run under en_US.UTF-8 locale (this is primarily how I run it). Some things are broken --- some of the man pages render a little funny, dtinfo main library browser doesn't know what directory to pull documents from (although auxilliary components appear to work fine). I expect that dtterm is not multi-byte capable. A lot of stuff seems to just fall back on C locale. The point is that first stabs at UTF-8 can probably come in the form of just picking something that's broken and fixing it --- preferably with some forethought, but it doesn't need to be an all-at-once deal. The build system... well, we've discussed the various options. I might take some early experimental stabs at it soon, in the name of parallelism. This would greatly speed up work on various other items. This will be my first real autotools project; are there any resources that you would recommend? All that said, what do you think the priority is here? -mrt ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
