Jon Trulson <j...@radscan.com> writes: > On 07/31/2018 07:53 PM, Matthew R. Trower wrote: >> Jon Trulson <j...@radscan.com> writes: >> >>> Not a clue. I think ultimately we would want it to generate HTML and >>> just use a web browser for both help and the guides. >> >> I'd really hate to see that. >> >> * DtInfo is part of CDE. >> >> * DtInfo (like all of CDE) is very lightweight. >> >> * DtInfo provides index and search capabilities (this is a primary >> strength of DocBook). Doesn't that sort of go out the window with >> HTML? >> > > Well, converting to docbook XML (not html) should preserve all of that > functionality actually. With that, we could generate HTML if we > wanted, or PDF's of the guides, or a variety of other formats. But I > don't know what the cde-specific software like dthelp and dtinfo are > actually doing. > > There's the format and manipulation of the documentation itself - this > is what I'm talking about.
Sure, I'm with you so far (on DocBook XML). But you mentioned generating HTML and just using a web browser. Are you suggesting that we throw out DtInfo and friends and use a web browser (e.g. Firefox, Dillo) instead? Or simply that we could generate additional formats (e.g. HTML) for convenience? Or, are you suggesting that an HTML renderer be embedded into DtInfo? I see below that you probably don't want to throw it out, so I guess I misunderstood you here (on HTML and browsers). What did you mean? > I'm not sure what you mean by out-of-tree technology. I do not think > trying to maintain ancient copies of code (nsgmls, et. al) is a viable > solution. No one maintains it. Well, I guess I just don't think the situation is so dire. We're here in 2018, and it's still chugging along. I don't see any tickets about it. Is it broken? I'm not really suggesting that the ideal route is to keep our in-tree toolchain forever, though. The statement about in-tree, out-of-tree, modern, etc came about as a result of general feelings about the tech industry's push for newer and shinier, even at the cost of (in my eyes) quality. I feel especially keenly about it in heritage projects like this. I think that balance is important, and am conservative about ripping out existing tech in favor of new. I'm having a hard time putting my full thoughts on this to digital paper right now, and it's probably not worth it as I think I may have misunderstood you. Also, I suspect you've learned a thing or two in your career about bit-rot and maintainership that I should probably defer to. =) > I do suggest we offload the utilities portion (like osgmls) to OS > versions and not keep bit-rotting versions in our tree. I don't have a problem with using system opensp. I don't see that affecting anybody, really, so I'm happy to reduce our code footprint. > I am also for converting the current older SGML document formats to > XML and docbook 5. As to how that affects dthelp/dtinfo, I just don't > know at this time. Thats probably reasonable enough, if not pressing (not that you suggested it was). I'm curious about SGML (a scheme dialect? I'm with the editor (esr?) on this one), but it seems the DocBook community prefers XML (considered lightweight in this context? Oh my). In addition to the newer tooling, it might make onboarding easier for revising / adding documentation to the project. Honestly, I suspect XML probably *is* more reasonable for documentation anyway. -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
