I believe, however, that a need for a basic, lightweight HTML renderer
is needed. Tkhtml 3 is becoming quite a complex beast, it's still in
alpha, and development on it has slowed. I'm wondering if an effort to
simply modernize the Uehler widget, make its display a bit cleaner, and
easy to plug in to Tk applications, would be useful, especially for apps
that made use of basic HTML without CSS.
I'm especially interested in this because there is no BSD-licensed
text-widget-based HTML rendered out there--there are similar packages
that use the GPL, but I'd like to use the BSD license.
Would anyone else find this of interest? Is it worth it for me to invest
time on this, set up a SF project, perhaps solicit contributions from
others? Or is the Uehler code simply too ancient (it supports only HTML
2.0) to be relevant today?
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
I for one think it is worth while project.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
I would find it of interest, but I think it's a bigger project than
you might think. The text widget makes the easy stuff very easy (my
own part-time attempts can render <i>, <b>, <pre>, <code>, <h1> and
<li> with sixtyish lines of code) but the hard stuff will be, well,
Hard.
I definitely think there's a void to be filled. Even if the code only
supported a small subset of html it would be useful if it was
lightweight, robust and easy to use (eg: htmlwidget .html -text
"<b>Hello world!</b>").
I keep hoping TkHtml will come to the rescue and be part of Tk proper
some day, but that project seems to have lost a lot of momentum (from
an outsiders perspective anyway).
A Tk widget based on the platform's native browser rendering engine
would be nice. E.g. IE on Windows, Safari (WebKit) on OSX and maybe
Firefox on Linux ... not sure how/if that can be done but then you
wouldn't have to worry about keeping the widget up to the latest
standards, etc.
Some kind of Tk web browser widget would be very useful but please keep
it out of Tk proper, it should remain as a separate extension IMHO.
Ummm, perhaps its just me, but I'd much rather see a standards compliant
rendering engine, so I'd suggest basing it upon Firefox for both Linux and
Windoze, and Macs can use either webKit or gecko ... I've wasted more time
trying to get Exploder to properly render standard html/css than I should
have over the years, and frankly, I'm tired of it. No point in saddling
Tcl/Tk with second rate software when good software will work just as
well.
Rob Sciuk
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups
>
> I would find it of interest, but I think it's a bigger project than
> you might think. The text widget makes the easy stuff very easy (my
> own part-time attempts can render <i>, <b>, <pre>, <code>, <h1> and
> <li> with sixtyish lines of code) but the hard stuff will be, well,
> Hard.
>
> I definitely think there's a void to be filled. Even if the code only
> supported a small subset of html it would be useful if it was
> lightweight, robust and easy to use (eg: htmlwidget .html -text
> "<b>Hello world!</b>").
The code already exists--it is the engine of TclTutor and has been
maintained by Clif Flynt for several years. The latest version is at his
website somewhere. It does a decent job with basic HTML, as you'll see
if you play with it. My objective is to clean up the top layer of it
(GUI) and make it more "pluggable" into applications, as well as adding
things like handling external browsers, etc. I doubt I'll do much with
the HTML parsing code itself.
>
> I keep hoping TkHtml will come to the rescue and be part of Tk proper
> some day, but that project seems to have lost a lot of momentum (from
> an outsiders perspective anyway).
Agreed. I can't get it to build on the Mac anymore, and it's so complex
it's hard to integrate into an application anyway.
I'm not envisioning anything that ambitious.
Who said anything about a web browser widget? I didn't say I wanted a
web browser, I want an HTML widget that can render text marked up with
HTML. I personally think that should be in the core. I don't think it
needs to have all the HTML bells and whistles, but should at least do
a credible job rendering basic HTML such as lists, headings, pre-
formatted paragraphs and the like. I wouldn't expect it to be good
enough to create a full blown web browser, but it should be good
enough to render rich dialogs, help pages, "about" boxes and similar
type things.
I personally think it MUST be that ambitious (but using a single
rendering engine of course - webkit or gecko). Mainly because I'm so
used to write "modern" html that I can't stand not having CSS at my
disposal. Even email clients support inline CSS at minimum. For me,
BASIC HTML looks something like:
<html>
<body>
<div id="header">
<span class="main_title">
Title
</span>
</div>
<div id="content">
<h1>Page Title</h1>
<p>
Some content..
</p>
</div>
<div id="footer">
Disclaimer: IANAL
</div>
</body>
</html>
These days, this is how most websites are structured thanks to the
semantic web movement. Going back to using (was deprecated, now
considered illegal) <font> tags is just painful.
So, unless someone feels up to the challenge of writing a pure tcl CSS
parser and pure Tk CSS renderer the best option is to embed a C/C++
rendering engine. After all, embedding is our speciality right?
While most likely agree it would be nice to have a full blown browser
widget at our disposal, that's not what this thread is about. The
original question was whether there was a need for a "basic,
lightweight HTML renderer".
I guess your answer is "no" since you said it "MUST" be more
ambitious. My answer is "yes, I think there's a need for a basic,
lightweight HTML renderer". It would be very useful for displaying
dialogs and short labels with rich text.
Right now the solution is to use the text widget and to insert a bunch
of tags, which can be rather cumbersome. I'm much rather write:
htmlable .l -text "Are you <b>sure</b> you want to <i>blah blah</
i>?"
...rather than
text .t -borderwidth 0 -highlightthickness 0 -width 35
bindtags .t [list .t Label . all]
.t tag configure bold -font boldFont
.t tag configure italic -font italicFont
.t insert end "Are you " {} "sure" bold " you want to " {} \
"blah blah" italic "?" {}
.t configure -state disabled
yes, they did.
When Apple wrote safari --and based it on khtml--,
they made the exact same decision.
Lightweight, easy maintainable code.
Well, webkit seems to supplant khtml,
and the apple-license, and LGPL(1 and 2)
shouldn't be to much of a problem,
considering that OSX is FreeBSD, too.
Another option: lynx (written in c, lightweight,
GPL).
-roger
>
> I believe, however, that a need for a basic, lightweight HTML renderer
> I'm wondering if an effort to
> simply modernize the Uehler widget, make its display a bit cleaner, and
> easy to plug in to Tk applications, would be useful, especially for apps
> that made use of basic HTML without CSS.
In rereading this thread today, I am struck by the thought that
perhaps what is going on is something I often see with my users... a
case where the requirements and implementation details are
intermingling a bit too soon.
I see two thoughts in this thread: "do we need a modern html rending
widget" and "do we need a rendering widget which provides a more
natural method of displaying 'rich text'".
It seems to me that some writing this thread see the word "html" and
think "html == web browser" while others think "html == text markup
language".
Perhaps a preceeding question could be:
What text markup language seems most natural and flexible when writing
dialogs, help screens, and other similar pieces of applications?
Once a text markup language is chosen, then one can think about
rendering the language.
Currently in the tcl community several rudimentary languages are in
use which may or may not suit all the original poster's needs - the
documentation markup language used in tcllib and a few other places,
the wiki's page markup, nroff, vanilla html. It's hard to say how they
fit the need until the needs are specified in some kind of detail.
For instance - the example later in the thread talked about support
for plain text, bold text, italic text, at the very least. Another
respondent talked about semantic markup - title, headings, paragraphs
perhaps, etc. Perhaps another person might find useful specification
of color, relational sizing of fonts, perhaps even hyper links. And
someone might want to indicate that ease of specification is important
- running the gamet from TeX or nroff to SGML to something simple like
POD/wiki language/stext or one of the other simple markups.
Once someone interested in the project has a set of specific features
they want to support, then they can look at the various languages
currently available and determine whether any of them meet that need.
If so, then tracking down some sort of parsing code shouldn't be too
horrible. Translating the parsed language into Tk/Ttk elements would
then be the last step... and that might be the easiest of them
all :smile:
My project is going to be very limited in scope.
It will consist mainly of updating the htmllib.tcl package at this URL:
http://noucorp.com/cgi-bin/noucorp/generic.tcl?dir=/var/www/html/tcl/utilities
Specifically, I'm going to do the following:
1. Clean its display a bit. At present it displays hyperlinks with a
change in relief rather than with underlining.
2. Update its demo client with a more modern layout. At present the
scrollbar is on the left, it has no method for navigating back to
previously viewed pages, and so on.
3. Add a mechanism for it to call external browsers for hyperlinks that
begin with http://. At present it can only display local HTML.
4. If possible, add hooks for the client to be displayed either in its
own toplevel window, for instance as a help viewer (which it currently
supports) and also to make the display a child widget--this might allow
HTML to function as rich text in an "about the app" dialog, or to
provide more detailed error messages, etc.
I do not envision turning this project into a general-purpose way to
display HTML in an arbitrary widget (for instance, in a label). Nor do I
envision this turning into a full-fledged web browser. To be honest, it
will probably be limited to its current support for HTML 2.0--I have no
plans to fiddle with the rendering code at that level. Nor will I add
support for CSS.
If others want to play with the code once I release something, and take
it in a different direction, of course they are more than welcome to do so.
May I suggest adding a mechanism to register handlers for protocols -- thus
I may want to use the the http and ftp packages to support getting those
files but hand off mailto: protocols to m favorite mail reader.
> Kevin Walzer
> Code by Kevinhttp://www.codebykevin.com
In line with Gerald's comments, maybe all 'links' should do a
callback, and then we can all decide what to do as needed.
I want to use it to run a help system, currently I use
tclhttpd3.5.1-dist/tclhttpd3.5.1/bin/mini/mini1.1.tcl
with an external browser launched in a way similar to http://wiki.tcl.tk/557
but mangled for 8.4 (without assuming that auto_noexec was active).
Dave
I would propose a glob style mechanism to mux links.
you can have the http:// ftp:// mailto: stuff and
organize it in such a way that forex only select links
are handled by a special renderer/handler.
uwe
Now that's a sensible suggestion. Separates the rendering from the
fetching. (Note that the reason why this whole thing - HTML rendering
- is hard is that a very large fraction of a web browser is needed to
do it. Consider how to handle the callback attributes that have
javascript content, and remember that many pages need such things to
render correctly nowadays...)
Donal (I'd rather be a Luddite).
It may not be quite what you are after, but the GRIDPLUS2 text widget
has this type of functionality. It's not extactly HTML but does borrow
some of the tags (<b></b>, <i></i> etc) and has a few of its own.
See: http://www.satisoft.com/tcltk/gridplus2/text.html#text-example4
Best Regards,
=Adrian=