On 07/31/2018 08:47 PM, Matthew R. Trower wrote:
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?
No, I don't want to throw it out, though in the end, we may want to
alter how it works internally - say using some sort of html widget for
display and navigation rather than the custom parser/renderer that
appears to be present now.
But again, I do not know enough about how the internals work to do
anything other than speculate at this time.
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. =)
My issue is in duplicating existing software with older, unmaintained
versions. I don't like that. It's extra maintenance and a source of
potential trouble (security issues, coverity issues, even compiler
warning issues.)
Time and development resources for working on CDE are restricted -
therefore the less we have to worry about, the better off we will be in
terms of being able to deliver something usable in a modern environment
with the resources we have...
Also, I don't think the future of CDE is in keeping things exactly as
they are -- the world has moved on from some of the technologies that
were brand new when CDE was under active development. I don't think it
is reasonable, or feasible to keep everything exactly as it was in 1995.
So, no I don't want to remove dtinfo and dthelp, but updating them to
something based on modern standards and practices is not a bad goal
either. Hell, some of this stuff was developed before the Internet was
even a thing. And some of the code is really bad. Preserving and
maintaining that is not long term a goal, it can't be.
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.
Yes, there's a lot to learn here. That's another problem - trying to
maintain something you don't really understand :)
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
------------------------------------------------------------------------------
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
