shtmlview is pur Tcl only snit megawidget to display a large subset of HTML. It should be used for local HTML files only for instance to display help pages within a Tk application. It does not support stylesheets and not http(s) addresses. As it is aTcl only extension it does not require any compilation. It is based on old code from Stephen Uhler, Clif Flynt and Robert Heller.
* Project page: hhttps://github.com/mittelmark/DGTcl
* Download: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
* Manual: http://htmlpreview.github.io/?https://github.com/mittelmark/DGTcl/blob/master/lib/shtmlview/shtmlview.html
* Wikipage: https://wiki.tcl-lang.org/page/shtmlview
Version 0.9.3 adds support for mouse-wheel scrolling and contains bug-fixes for text copy and http(s) links and anchor links (thanks to aplsimple).
On 3/10/2022 6:05 AM, D Groth wrote:Tcl only extension it does not require any compilation. It is based on old code from Stephen Uhler, Clif Flynt and Robert Heller.
shtmlview is pur Tcl only snit megawidget to display a large subset of HTML. It should be used for local HTML files only for instance to display help pages within a Tk application. It does not support stylesheets and not http(s) addresses. As it is a
* Project page: hhttps://github.com/mittelmark/DGTcl
* Download: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
* Manual: http://htmlpreview.github.io/?https://github.com/mittelmark/DGTcl/blob/master/lib/shtmlview/shtmlview.html
* Wikipage: https://wiki.tcl-lang.org/page/shtmlview
Version 0.9.3 adds support for mouse-wheel scrolling and contains bug-fixes for text copy and http(s) links and anchor links (thanks to aplsimple).
Sounded interesting so I gave the example from the manpage a try. Maybe
my snit package (2.3.2 from tcllib 1.19) is too old?
% ::shtmlview::shtmlview .help -toolbar true -browsecmd browsed
Error in constructor: bad window path name ".help.toolbar"
% set errorInfo
bad window path name ".help.toolbar"
while executing
"pack $win.toolbar -side top -fill x -expand false"
(procedure "::shtmlview::shtmlview::Snit_methodconfigureToolbar"
line 10)
invoked from within
".help configureToolbar -toolbar true"
("uplevel" body line 1)
invoked from within
"uplevel 1 $command"
(procedure "::snit::RT.method.configurelist" line 37)
invoked from within
"$self configurelist $args"
(procedure "::shtmlview::shtmlview::Snit_constructor" line 10)
invoked from within
"::shtmlview::shtmlview::Snit_constructor ::shtmlview::shtmlview ::shtmlview::shtmlview::Snit_inst2 .help .help -toolbar true -browsecmd browsed"
("eval" body line 1)
invoked from within
"eval [linsert $arglist 0 ${type}::Snit_constructor $type $selfns
$instance $instance]"
(procedure "RT.ConstructInstance" line 9)
invoked from within
"RT.ConstructInstance $type $selfns $name $args"
(procedure "::snit::RT.widget.typemethod.create" line 62)
invoked from within
"::shtmlview::shtmlview .help -toolbar true -browsecmd browsed"
("uplevel" body line 1)
invoked from within
"uplevel #0 {::shtmlview::shtmlview .help -toolbar true -browsecmd
browsed}"
--
computerjock AT mail DOT com
Thanks for the report, I think I fixed the issue. The snit version should be modern enough.
Here again the download link: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
shtmlview is pur Tcl only snit megawidget to display a large subset of HTML. It should be used for local HTML files only for instance to display help pages within a Tk application.
Version 0.9.3 adds support for mouse-wheel scrolling and contains bug-fixes for text copy and http(s) links and anchor links (thanks to aplsimple).
El jueves, 10 de marzo de 2022 a las 13:05:30 UTC+1, D Groth escribió:and forward with several files opened. I think it would be better if you get the realpath of the file and always save the full path to the file to reload it.
shtmlview is pur Tcl only snit megawidget to display a large subset of HTML. It should be used for local HTML files only for instance to display help pages within a Tk application.When opening files with browse command it doesn't keep the file path unless you provide it, so if you provide only a name for a file in current directory when you change directory shtmlview is not able to reopen the file, this happen when moving back
Version 0.9.3 adds support for mouse-wheel scrolling and contains bug-fixes for text copy and http(s) links and anchor links (thanks to aplsimple).
Also back and forward buttons only works with files but not with anchors inside a file.
I don't know if those two characteristics are features or bugs, so I just report them for you knowledge and decide what to do (I feel more comfortable working as I expect, but it's just me)
Anyway I find the megawidget pretty interesting and very usefull for documentation or guides. Thanks for your work.
regards
Thanks for the reports. I now added as well support for backward and forward with internal anchors, and I used file normalize to store the complete file path. Not sure if this solves your change directory problem. It should ...extending is not that easy ;)
Here again the download link: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
I hope this works. Please note that is very old code from a few famous Tcl coders (Uhler 1995, Flint 1999-2000, Heller 2002-2008 around) which I just merged together into this megawidget to make it usable for a broader community, so fixing and
D Grothand forward with several files opened. I think it would be better if you get the realpath of the file and always save the full path to the file to reload it.
pd schrieb am Donnerstag, 10. März 2022 um 23:16:03 UTC+1:
El jueves, 10 de marzo de 2022 a las 13:05:30 UTC+1, D Groth escribió:
shtmlview is pur Tcl only snit megawidget to display a large subset of HTML. It should be used for local HTML files only for instance to display help pages within a Tk application.When opening files with browse command it doesn't keep the file path unless you provide it, so if you provide only a name for a file in current directory when you change directory shtmlview is not able to reopen the file, this happen when moving back
Version 0.9.3 adds support for mouse-wheel scrolling and contains bug-fixes for text copy and http(s) links and anchor links (thanks to aplsimple).
Also back and forward buttons only works with files but not with anchors inside a file.
I don't know if those two characteristics are features or bugs, so I just report them for you knowledge and decide what to do (I feel more comfortable working as I expect, but it's just me)
Anyway I find the megawidget pretty interesting and very usefull for documentation or guides. Thanks for your work.
regards
Thanks for the reports. I now added as well support for backward and forward with internal anchors, and I used file normalize to store the complete file path. Not sure if this solves your change directory problem. It should ...
D Grothand forward with several files opened. I think it would be better if you get the realpath of the file and always save the full path to the file to reload it.
pd schrieb am Donnerstag, 10. März 2022 um 23:16:03 UTC+1:
When opening files with browse command it doesn't keep the file path unless you provide it, so if you provide only a name for a file in current directory when you change directory shtmlview is not able to reopen the file, this happen when moving back
Also back and forward buttons only works with files but not with anchors inside a file.
El viernes, 11 de marzo de 2022 a las 10:41:40 UTC+1, D Groth escribió:back and forward with several files opened. I think it would be better if you get the realpath of the file and always save the full path to the file to reload it.
Thanks for the reports. I now added as well support for backward and forward with internal anchors, and I used file normalize to store the complete file path. Not sure if this solves your change directory problem. It should ...now, it appears to work ok back and forward with several files but when in anchors even when back button is enable it generates this error if pushed:
{
Error reading C:/Users/prueba/Downloads/shtmlview/
couldn't open "C:/Users/prueba/Downloads/shtmlview/": permission denied
}
shame errors appear in place of images when trying to load the images in an html file.
Maybe it's a matter of windows OS and not a problem of the tcl source.
D Groth
pd schrieb am Donnerstag, 10. März 2022 um 23:16:03 UTC+1:
When opening files with browse command it doesn't keep the file path unless you provide it, so if you provide only a name for a file in current directory when you change directory shtmlview is not able to reopen the file, this happen when moving
Also back and forward buttons only works with files but not with anchors inside a file.
I fired up my Windows VM and I think I found the problem with the anchor links. The error for the should be now gone.
Not sure about the images, png and gif images should be supported, even if they are in different folders. If there are jpeg images it might help to install the tkimg extension. I will look into the support of jpeg images.
Here again the download link: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
El domingo, 13 de marzo de 2022 a las 10:55:13 UTC+1, D Groth escribió:be better if the error is shown in stderr or console and never treated as a opened file.
I fired up my Windows VM and I think I found the problem with the anchor links. The error for the should be now gone.Now the problems with permisions are fixed but I see other "problems":
Not sure about the images, png and gif images should be supported, even if they are in different folders. If there are jpeg images it might help to install the tkimg extension. I will look into the support of jpeg images.
Here again the download link: https://downgit.github.io/#/home?url=https://github.com/mittelmark/DGTcl/tree/master/lib/shtmlview
- It should be a button in the toolbar and/or an item in menu to close files, at least the visible file. Now there's no way to close and free an opened file, even if you want it anymore.
- when you try to browse and non existant file, an error is generated, this is ok but the problem is the error is taken as an html file and opened in the browser and you also can navigate backward and forward as it were a real file [img3.png]. It would
- urls in an html file are not managed properly, the browser tries to load them from a local path rather to access the url and download them previously. Maybe this program is intented to process local files and local resources only, but then it wouldbe better if it doesn't try to load resources at all if there're not present in the local storage. The browser inserts into the file error messages indicating the resources cannot be found, I think there're only two options: 1) dowload them and load into
The problem is the browser treats url as relative or absolute paths in the current storage. The loaded html files has a line like:
<img src="/2022/assets/logos/galpon.png" height="250" alt="Logo GALPon">
and the browser tries to load image file /2022/assets/logos/galpon.png in root mount point rather than in web domain, as that file doesn't exists you get the error message:
couldn't open "/2022/assets/logos/galpon.png": no such file or directory
in place of the image.
A similar problem appears when the image is fully indicated as an url with http protocol, a line like:
<img src="https://www.avarcacastell.com/es/themes/theshop/img/langs/es.jpg" alt="Español">
and the browser tries to load the image in "C:/Users/prueba/Downloads/https://wwww.avarcacastell.com/es/themes/theshop/img/langs/es.jpg" showing the error
couldn't open "C:/Users/prueba/Downloads/https://wwww.avarcacastell.com/es/themes/theshop/img/langs/es.jpg" : no such file or directory
instead of the image.
Maybe you prefer to report this issues directly in github rather here in order not to pollute this list.
regards
A few issue can be fixed probably, but please: as stated in the documentation, the widget is not intended to be a web browser. It is a HTML and Markdown viewer for local files only, images and hyperlinks should be relative, so the widget should be usedfor instance embedded within your own application to display HTML or Markdown help pages or to browse local HTML/Markdown files which use relative links (absolute links are evil, we can't move things around). The Tcl documentation is a good example where
The red text for an image which can't be shown, because it is an http(s) image is intended to inform the user.
I am not sure what you mean, you would like to close a file. What should be shown instead in the widget? Should the text widget just be cleaned, or a default page should be shown instead? For instance a help page?
Indeed for bugs the github issue page is the better place, more general discussion may be better here.
I think points 1-3 should be solved with the version currently on Github (the widget does not anymore tries to open files which are not there). Not sure yet if it is a good idea do hide an http(s) image simply completely without an error text in theHTML code, but probably for this is the alternate text between the image tag shown.
I understand now that the close a file feature should remove the file from the history and load the previous file instead. And that the next widgets *browse* command might start a complete new history if requested. So for instance if I call the widgetdirectly from the terminal with:
$ tclsh shtmlview.tcl file1.html file2.html test.mdfor instance.
or even
$ tclsh shtmlview.tcl *.html *.md
after closing file1.html from the widget therafter file2.html should be displayed and the history should be cleaned, so that I can process all files similar like in an image viewer where I can walk through the images of a directory with a single N key
Right?used for instance embedded within your own application to display HTML or Markdown help pages or to browse local HTML/Markdown files which use relative links (absolute links are evil, we can't move things around). The Tcl documentation is a good example
We should discuss this in the new shtmlview repository https://github.com/mittelmark/shtmlview/issues in separate issue threads as the discussion becomes more an more tree like with different topics and suggestions ;)
Simply open there for each issue / feature request an issue. So that we can back linearize the discussion ....
pd schrieb am Dienstag, 15. März 2022 um 10:19:11 UTC+1:
El martes, 15 de marzo de 2022 a las 6:33:01 UTC+1, D Groth escribió:
A few issue can be fixed probably, but please: as stated in the documentation, the widget is not intended to be a web browser. It is a HTML and Markdown viewer for local files only, images and hyperlinks should be relative, so the widget should be
saved from a online web page. The point is how the program will perform with unexpected. I see this possibilities:Yes, I understand that, for that reason I said "Maybe this program is intented to process local files and local resources only", but the point is what to do when you command to browse a file containing non local references, for example an html file
viewing (browsing) one of the opened files, I'm not interested in having it opened anymore, so I want to close it and not pollute the opened files list, that is, I select "close the file" and from now, the file is vanished in the browser, I cannot reach1- the browser refuses to load the file with non local references
2- the browser loads the files but ignores non local references
3- the browser loads the file and tries to interpret non local references as local ones (current behaviour)
I consider (3) a bug, (1) a non optimal solution and (2) the right solution, but that's only my opinion.
The red text for an image which can't be shown, because it is an http(s) image is intended to inform the user.Another possibility is simply not loading the image and don't showing anything rendered (no image and no error), the absence of image is enough to inform the user something went wrong (and you can also lauch errors to stderr).
I am not sure what you mean, you would like to close a file. What should be shown instead in the widget? Should the text widget just be cleaned, or a default page should be shown instead? For instance a help page?Every time you issue the command "browse <file>" you opened the file in the browser window and you can navigate for all opened files with backward and forward buttons. If I open several files, in certain moment of time maybe I'm not interested in
Indeed for bugs the github issue page is the better place, more general discussion may be better here.ok, I will make suggestions and issues there since now
don't take my words as criticism, I value your widget and find it very interesting and usefull as a kind of "norton guide" local documentation, that's the reason I'm suggesting ideas to, in my opinion, improve it
regards
El martes, 15 de marzo de 2022 a las 6:33:01 UTC+1, D Groth escribió:used for instance embedded within your own application to display HTML or Markdown help pages or to browse local HTML/Markdown files which use relative links (absolute links are evil, we can't move things around). The Tcl documentation is a good example
A few issue can be fixed probably, but please: as stated in the documentation, the widget is not intended to be a web browser. It is a HTML and Markdown viewer for local files only, images and hyperlinks should be relative, so the widget should be
Yes, I understand that, for that reason I said "Maybe this program is intented to process local files and local resources only", but the point is what to do when you command to browse a file containing non local references, for example an html filesaved from a online web page. The point is how the program will perform with unexpected. I see this possibilities:
1- the browser refuses to load the file with non local referencesviewing (browsing) one of the opened files, I'm not interested in having it opened anymore, so I want to close it and not pollute the opened files list, that is, I select "close the file" and from now, the file is vanished in the browser, I cannot reach
2- the browser loads the files but ignores non local references
3- the browser loads the file and tries to interpret non local references as local ones (current behaviour)
I consider (3) a bug, (1) a non optimal solution and (2) the right solution, but that's only my opinion.
The red text for an image which can't be shown, because it is an http(s) image is intended to inform the user.Another possibility is simply not loading the image and don't showing anything rendered (no image and no error), the absence of image is enough to inform the user something went wrong (and you can also lauch errors to stderr).
I am not sure what you mean, you would like to close a file. What should be shown instead in the widget? Should the text widget just be cleaned, or a default page should be shown instead? For instance a help page?Every time you issue the command "browse <file>" you opened the file in the browser window and you can navigate for all opened files with backward and forward buttons. If I open several files, in certain moment of time maybe I'm not interested in
Indeed for bugs the github issue page is the better place, more general discussion may be better here.ok, I will make suggestions and issues there since now
don't take my words as criticism, I value your widget and find it very interesting and usefull as a kind of "norton guide" local documentation, that's the reason I'm suggesting ideas to, in my opinion, improve it
regards
1- the browser refuses to load the file with non local references
2- the browser loads the files but ignores non local references
3- the browser loads the file and tries to interpret non local references as local ones (current behaviour)
don't take my words as criticism, I value your widget and find it very interesting and usefull as a kind of "norton guide" local documentation, that's the reason I'm suggesting ideas to, in my opinion, improve it
regards
I understand now that the close a file feature should remove the file from the history and load the previous file instead. And that the next widgets *browse* command might start a complete new history if requested. So for instance if I call the widgetdirectly from the terminal with:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:59:33 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,961 |
![https://www.avarcacastell.com/es/themes/theshop/img/langs/es.jpg"](https://www.avarcacastell.com/es/themes/theshop/img/langs/es.jpg"){kind=link}
![https://wwww.avarcacastell.com/es/themes/theshop/img/langs/es.jpg"](https://wwww.avarcacastell.com/es/themes/theshop/img/langs/es.jpg"){kind=link}