[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