[Lvlug] askSam/TWiki Clone (Project?)
Randy Kramer
rhkramer at gmail.com
Mon Aug 29 11:08:40 EDT 2005
I think I've mentioned before my desire to write an application that might at
least partially be described as an askSam/TWiki clone (and more). In any
case, I'd like to describe some of where I'm at and seek opinions and
suggestions.
Part of this would include a means to edit (almost) plain text (actually, text
with TWiki markup (or a variation thereof) (in files containing multiple
"records"), and then (often) passing single records through a "filter" to
convert the TWiki markup to (X)HTML and thence to an (X)HTML renderer /
snappy web browser for local display. (The content would always be stored as
text with TWiki markup.)
I've done some exploration of approaches to the editing | filtering |
rendering thingie:
---++ First Thought
My first (somewhat practical?) thought was to have a standalone editor (nedit)
that could invoke external commands, with selected text as a parameter.
(nedit can do this, with one problem I'll mention here and discuss more
later--when nedit sends such text it deletes it from the text file (buffer)
in the expectation that the external command will return text to be displayed
in its place (e.g., consider sort).
My intent was to write a Ruby, C, or whatever filter that would be invoked
from nedit, filter the text to convert TWiki markup, and send the text on to
something like khtml (the kde/konqueror HTML rendering / web browser
"widget", iiuc. For various reasons, I planned to communicate from the
filter to khtml via "ports" (not sure that's the right word, maybe
iostreams, ???), those reasons including:
* I want the khtml widget to be more a server than an invoked program (I
don't want it to have to startup every time I send it a new record for
display) (In most cases, I want the displayed data in khtml to be driven by
nedit--nedit sends new data, khtml displays it, without any need for the user
to interact with khtml to, for example, request a new page. Note however,
that at some point in time I do plan (want ) to allow the user to fill out
HTML forms in khtml and send that data (probably through a different filter
program) back to nedit for incorporation in the original file.
* I may need the filter program to send a copy of the original text (with
TWiki markup) back to nedit (because, as mentioned above, nedit deletes it),
and, iiuc,I can write that filter program so it uses stdin and stdout to
communicate with nedit while using iostreams/whatever to communicate with
khtml.
(Of course, an alternate solution is to modify nedit (make a patch that is
accepted "upstream" to make that deletion behavior optional. While I'm
talking about nedit patches, I'd also like to modify nedit to allow "real"
text collapsing (folding), i.e., actually hide text (and provide safeguards
against accidental deletion) rather than fold text into long lines that
extend far off to the right, as my current nedit fold macros do.)
Just mentioning some other things to come along--I want good search tools
(i.e., probably indexed, with boolean and similar operators), that will
search the TWiki marked up text file, then filter the found records to HTML
for display. (I suppose I could maintain an additional data file in HTML and
search that, or maintain the data in an HTML file for normal use and have a
filter that converts HTML back to TWiki markup for editing, but both of those
seem more cumbersome.
Note on programming: One of the things I hoped to gain with this approach was
a minimal need to learn programming languages. I'd have to deal with some
language to write the filter. khtml is written in C++ but already exists and
has the interface to communicate via iostreams/whatever (iiuc). Nedit
already exists (written in C, iiuc) but barring my desires to modify it, I
don't have to fool with its (C) code. So, I might get away with just
learning enough Ruby (although I am concerned about speed) to write the
filter.
---++ Second Thought
In the last day or so I had another idea that might allow a more integrated
approach. It was inspired by:
* knowing that nedit is not (afaik) available as a widget, but is available
in a client/server form where one instance of nedit runs as a server, and
small footprint nedit clients can be instantiated to edit files using the
server. (A common use of this is to use nedit as an "external" editor for a
mail client or similar.)
* thinking that I might have a more integrated result if I built this
thingie "into" something like khtml, and then, from it, invoked nedit in
client form to edit the files.
With an approach like this, I presumably don't have to deal with iostreams to
communicate with khtml (but maybe the communication to the nedit client is by
stdin and stdout). I haven't tried to investigate this approach to the
extent that I (tried to) investigate the first approach (note that I haven't
even mentioned the filter here yet, which is still required, but is maybe
just a "subroutine" (or object) that I add to the khtml code.
Note on programming: khtml is written in C++ (and if I pick some differernt
HTML widget, it will be written in some other language I don't know), so I
will have to deal with programming in C++ (which, if I didn't mention, I
don't know).
---++ Third Thought
I wonder if any of the various HTML editing tools have somewhat similar
features, or at least combine a plain text editor and an HTML renderer? If
so, maybe it would be easier for me to start with a product like that
(assuming I can find a free one) and modify it.
I haven't looked at HTML editors in quite a while, but may start today.
Anybody have suggestions? (A "real" WYSIWYG HTML editor might not quite do
the job for me, as it may not have the plain text editor part, but only an
HTML renderer with editing facilities.)
Note on programming: Like the second thought, I'll have to deal with the
language that the HTML editing tool is written in. (And I suspect I'd pick
that tool based on which one seems closest to my needs rather than the one
with the language that might be easiest for me to deal with (Pascal, if I
still remember any of it).)
---++ Disclaimer and Call for Help
I hope I don't sound terribly knowledgable about this, because I'm not. I
have something I want to do and I'm stumbling around in the dark trying to
create something to do it. Suggestions and help are welcome.
When I mention help, I'd love to have/create/start a group project to
accomplish all or some of what I have in mind. In anticipation of such
possibility, I haven't decided how I'd like to license the project, thinking
that others who want to participate may want a say in the license chosen.
Of course, the choice of license and choice of components are
interdependent--nedit is GPL, khtml is some free/open source license. But,
in the first approach (thought) the coupling to nedit and khtml may be (or
could be made to be) loose enough that the license on the filter (and other,
future components of the project) can be anything at all.
regards,
Randy Kramer
More information about the Lvlug
mailing list