Monthly Hv3 builds in 2011?
jemptymethod
start the year? See the following tiny modification I've made. This
turns out to be essential when running Hv3 from a starkit and/or
specifying a URL argument on the command line.
The issue I'm addressing dates back to Sep 2009, something I reported
on this list, but that somebody else confirmed was an issue for them
too:
http://groups.google.com/group/tkhtml3/browse_thread/thread/8e186f9355255d29
Here's the "patch", in essence, removing just one line. I've actually
been running this way successfully all the while in the context of my
DeskML project built on Hv3:
$ diff -r hv3-win32-monthly-2010_12.vfs hv3-win32-nightly-08_0203.vfs
diff -r hv3-win32-monthly-2010_12.vfs/hv3_http.tcl hv3-win32-
nightly-08_0203.vfs/hv3_http.tcl
570a571
> unset state(sock)
jemptymethod
described in the thread linked to below.
I can take care of the pure Tcl/Hv3 issue. This min-width issue
however might take some mucking about in tkhtml3 though? Not sure:
http://groups.google.com/group/tkhtml3/browse_thread/thread/38f10bfddc4312ac
George Jempty
On Dec 26, 6:53 am, jemptymethod <jemptymet...@gmail.com> wrote:
> I propose monthly Hv3 builds in 2011, or at least one small patch to
> start the year? See the following tiny modification I've made. This
> turns out to be essential when running Hv3 from a starkit and/or
> specifying a URL argument on the command line.
>
> The issue I'm addressing dates back to Sep 2009, something I reported
> on this list, but that somebody else confirmed was an issue for them
> too:
>
Caitlyn Martin
If you want anyone in the Linux world to care about HV3 again it's
probably more important to come up with a sane build method than to
worry about how frequently you release. We don't need a new version
every month. We do need semi-regular updates that can be compiled and
then packaged for various distros. The problem right now is that it
is incredibly difficult if not impossible to successfully build HV3 on
a current distro. Solve that and you will have renewed interest.
While HV3 will mainly be of interest to lightweight distros I also
think you need it to work on 64-bit as well as 32-bit Linux which you
have indicated is problematic. FWIW, Vector Linux Light 6.0 had HV3
as a default browser. I doubt if anyone will even package it again
for VL7 without an updated version that is sane to build.
Just my .02... If you are now the person driving development your
needs will obviously come first.
Good luck!
Cait
Mario Becroft
are doing something wrong--in the case recently reported on this list it
looked like one of the libraries tkhtml was being linked with was for
the wrong architecture. Obviously all binaries being linked need to be
either 32-bit or 64-bit and not a mixture of the two. This limitation is
not related to hv3 but applies to all software running on a linux system
or any UNIX-derived operating system generally.
I don't recall tkhtml or hv3 being in any way difficult to build so long
as you have the required libraries.
tkhtml/hv3 is the third best open-source html renderer/web browser after
gecko and webkit, and far ahead of anything else. It is also the
smallest and fastest of those three. In my opinion, the world
desperately needs a high-quality, compact web browser better than either
gecko or webkit. I am surprised that there is not more interest in
tkhtml and hv3 as currently it comes closer to meeting these
requirements than anything else out there.
Unfortunately, good as they are in some respects, tkhtml and hv3 would
need a huge investment of work to become feature complete and support
the latest web standards. Right now I have a project that is crying out
for tkhtml, but I cannot use it because it lacks some features we need,
and we cannot afford to develop those features on our own. Were there
more of a community with several active contributors then this might be
different.
I guess most people are not working on small systems where performance
and memory usage are important, and find gecko or webkit sufficiently
good that the benefits of a better product are outweighed by the
barriers to entry. In my opinion this is unfortunate, but I cannot
identify a practical way of doing anything about it.
--
Mario Becroft <m...@gem.win.co.nz>
jemptymethod
> hv3 works fine on 32-bit and 64-bit Linux. If it does not work then you
> are doing something wrong--in the case recently reported on this list it
> looked like one of the libraries tkhtml was being linked with was for
> the wrong architecture. Obviously all binaries being linked need to be
> either 32-bit or 64-bit and not a mixture of the two. This limitation is
> not related to hv3 but applies to all software running on a linux system
> or any UNIX-derived operating system generally.
rather just trying to use hv3 "out of the box" that I can download as
an .exe or .kit from http://tkhtml.tcl.tk/hv3.html. I got myself a 64-
bit, Windows-7 box largely for the purpose of exercising Hv3 on this
architecture, and then in turn was surprised and confused when Hv3 ran
as is on Windows-7.
> I don't recall tkhtml or hv3 being in any way difficult to build so long
> as you have the required libraries.
Perhaps as we try it and post here, you can guide us if we have
difficulty?
Thanks....George
Caitlyn Martin
>> I don't recall tkhtml or hv3 being in any way difficult to build so long
>> as you have the required libraries.
>
> Well Cait seems to think its difficult, and I've not tried it yet.
> Perhaps as we try it and post here, you can guide us if we have
> difficulty?
I'm glad you think it isn't difficult. I had all the libraries and,
indeed, built what was missing for my distro. Perhaps you should go
back through the list archives and look at the posts on the subject ad
the help offered my Adam Williamson of Red Hat (and formerly of
Mandriva). Adam's suggestions used to work for me, but not lately.
Regards,
Cait
jemptymethod
> Hi, George,
>
> >> I don't recall tkhtml or hv3 being in any way difficult to build so long
> >> as you have the required libraries.
>
> > Well Cait seems to think its difficult, and I've not tried it yet.
> > Perhaps as we try it and post here, you can guide us if we have
> > difficulty?
>
> I'm glad you think it isn't difficult.
whatsoever. Your feedback on the build process is appreciated, and I
hope Mario or whoever can possibly pitch in if we post issues we are
having.
I for one am very interested in building tkhtml3 for Mac, plus the
other stuff I'll need for Hv3, namely see (simple ecmascript engine).
I've had some success building software in the past in general, but
for the most part I'm a front end guy, so if I can't get stuff to
build, the errors and workaround processes to me are typically pretty
inscrutable. We shall see though.
jemptymethod
> On Dec 27, 11:03 am, Caitlyn Martin <caitlynmmar...@gmail.com> wrote:
>
> > Hi, George,
>
> > >> I don't recall tkhtml or hv3 being in any way difficult to build so long
> > >> as you have the required libraries.
>
> > > Well Cait seems to think its difficult, and I've not tried it yet.
> > > Perhaps as we try it and post here, you can guide us if we have
> > > difficulty?
>
> > I'm glad you think it isn't difficult.
>
> I'm with you Cait, I think it *might* be difficult
again, I really need to try.
From compile.txt within the unzipped "htmlwidget" directory:
" There are two ways to build the Tkhtml widget:
* Using the configure script. This is quick and easy if it works,
virtually impossible to debug if it doesn't."
Furthermore, from my reading of the make files, much of the process
for building SEE (simple ecmascript engine) is conflated with the
build process for tkhtml3 itself. To me it would seem they should be
separated a bit more. It would think it would be possible to build
one without the other. Divide and conquer would seem to be a good
starting point, but I've seldom had to delve into the minutiae of make
files.
jemptymethod
> On Dec 27, 6:51 pm, jemptymethod <jemptymet...@gmail.com> wrote:
>
> > On Dec 27, 11:03 am, Caitlyn Martin <caitlynmmar...@gmail.com> wrote:
>
> > > Hi, George,
>
> > > >> I don't recall tkhtml or hv3 being in any way difficult to build so long
> > > >> as you have the required libraries.
>
> > > > Well Cait seems to think its difficult, and I've not tried it yet.
> > > > Perhaps as we try it and post here, you can guide us if we have
> > > > difficulty?
>
> > > I'm glad you think it isn't difficult.
>
> > I'm with you Cait, I think it *might* be difficult
>
> From what I'm reading, the above impression seems correct, though
> again, I really need to try.
>
> From compile.txt within the unzipped "htmlwidget" directory:
>
> " There are two ways to build the Tkhtml widget:
>
> * Using the configure script. This is quick and easy if it works,
> virtually impossible to debug if it doesn't."
wrote this:
"If, like me, you are just an occasional user of Autotools, then
you'll find it useful if the "configure" script doesn't work out of
the box." See: http://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/product-reviews/1593272065/
Based on the above, I'm motivated to either buy this book outright or
add it to my Safari bookshelf.
C Y
there is an experimental CMake based build of tkhtml here:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/branches/cmake/src/other/tkhtml/
This is being driven by the need to build cross platform (including Visual C++
on Windows) without maintaining multiple build systems. It builds but is
untested (as yet) in a functional sense on Windows, but does work (at least as
far as BRL-CAD puts it to the test) on Linux and Mac X11. (Mac Aqua will come
after Windows issues have been hammered out.)
So far this script has been used only in the broader context of the new CMake
build system for BRL-CAD, so it assumes some variables that are set by higher
level logic and won't function "stand-alone". It can probably be made to do so
if there is interest.
Cheers,
CY
jemptymethod
> Well, for what it's worth (probably not much to the wider Tcl/Tk community)
> there is an experimental CMake based build of tkhtml here:
>
> This is being driven by the need to build cross platform (including Visual C++
> on Windows) without maintaining multiple build systems. It builds but is
> untested (as yet) in a functional sense on Windows, but does work (at least as
> far as BRL-CAD puts it to the test) on Linux and Mac X11. (Mac Aqua will come
> after Windows issues have been hammered out.)
>
> So far this script has been used only in the broader context of the new CMake
> build system for BRL-CAD, so it assumes some variables that are set by higher
> level logic and won't function "stand-alone". It can probably be made to do so
> if there is interest.
outside of my usual realm but I'm willing to dig in and hopefully get
at least reasonably passable. My book on autotools should arrive
today, and I've found some online material on CMake. I'll be getting
my FreeBSD image today too for usage within Windows/VirtualBox, so
that is going to be the first platform I target.