Re: [Lazarus] WebAssembly
On 11.11.2016 02:26, Mattias Gaertner via Lazarus wrote: So it is not yet clear when it will be ready and how the end product will work on the various browsers. Mozilla promises "March 2017". Any information on other brands ? I only found "Microsoft says it is close to shipping the browser preview of WebAssembly on Microsoft Edge and ChakraCore" -> https://mspoweruser.com/microsoft-edge-get-webassembly-browser-preview-soon/ -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] WebAssembly
On 11.11.2016 01:33, Lars via Lazarus wrote: Maybe best to start from scratch. Regarding the Lazarus paradigm "write once, compile and run everywhere", IMHO not a good idea. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 00:53, Lars via Lazarus wrote: > I do appreciate simple documentation without eye > candy crap. :) Just take a look at Apple's OSX built-in help (not the online content). It is minimalist and mostly text - with a hint of good typography. It works! Microsoft Windows 7 does very similar to Apple - simple and elegant. You don't need some Telly Tubbies color scheme in your help contents (just because HTML allows for it) - it just distracts from the help itself. I've seen many such [terrible] CHM or HTML help in my days. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 00:47, Lars via Lazarus wrote: > But, could one compile fpc code to javaapplet jvm bytecode? FPC 3.x can compile to Java Bytecode, but I've never actually tried it myself. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 01:11, Lars via Lazarus wrote: > port alternative to port 80 which may be blocked by firewall. That I would > want to avoid, as it's just another hassle. You can always use any other port >1024 for that. I've implemented a commercial application that works mostly online, but we wanted a offline version too. So I built a local mini webserver inside the main application. The application launched your default web browser with a URL and port number which the main application served. It worked beautifully. But for help, firing up Chrome of Firefox is just too damn slow, and eats way to much memory. Also you will have to implement your own search (which will be slow over HTML files), table of contents and index pages. Then what about other useful features like bookmarking a help topic, inline annotations (user defined notes added to a help topic at runtime). As for communications with a external [dedicated] help viewer. fpGUI's Docview does that via IPC, Microsoft's WinHelp I think could do it too, OS/2 VIEW help viewer did lots of 2-way communications with applications. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 11/10/2016 08:11 PM, Lars via Lazarus wrote: The best reason to have some local (whatever how limited) widget is for IDE popups of helptext instead of an external browser. External browser requires alt-tabbing away from the ide which is a pain. A external browser cannot be communicated with once you open the html file. with a local widget, you can communicate with that widget. With an external browser, once you've loaded the page there is no way to communicate. An an external browser doesn't offer a search system if it's a static html file served off line. So then you end up with people just using google and online help and stack exchange, instead of reading documentation. what's wrong with something like LHelp and using IPC to tell it where to load the next help from that the user has asked for?? from these cheap seats i have way over here, it seems like you are over engineering this... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] WebAssembly
On Fri, November 11, 2016 2:23 am, Michael Schnell via Lazarus wrote: > On 11.11.2016 01:33, Lars via Lazarus wrote: > >> Maybe best to start from scratch. >> > Regarding the Lazarus paradigm "write once, compile and run everywhere", > IMHO not a good idea. The issue is you are working in a sandbox. Lazarus is designed to take control of the computer using all the dangerous things without any sandbox, such as being able to delete and write to pretty much any file you want that has the correct permissions in place. A sandbox is much more specialized to develop for, because you may only be able to access certain directory with limited files So you could modify lazarus to work with this sandbox restriction, but, might be easier to design from scratch. ... I understand the desire to just take existing LCL app and port it to the web browser, but that's a pipe dream, because browsers will be in sandboxes that just don't work like client applications on Ms Windows, BSD/Linux. Another option is just to use a separate widget set and see how that works, such as fpGUI widget. But I guess that means you can't as easily take an existing app and port it. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Fri, November 11, 2016 3:54 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 00:53, Lars via Lazarus wrote: > >> I do appreciate simple documentation without eye >> candy crap. > > :) Just take a look at Apple's OSX built-in help (not the online > content). It is minimalist and mostly text - with a hint of good > typography. It works! Microsoft Windows 7 does very similar to Apple - > simple and elegant. I've always liked the website delphibasics .co .uk (or whatever the address is). Would the current help systems be even capable of looking like that? Must be just a few div boxes. Really simple, interesting color shades. No fancy garbage, just simple boxes of text. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Fri, November 11, 2016 4:03 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 01:11, Lars via Lazarus wrote: > >> port alternative to port 80 which may be blocked by firewall. That I >> would want to avoid, as it's just another hassle. > > You can always use any other port >1024 for that. No issues with default firewalls? Last thing I want, is a customer having to futz around with router firewall, windows firewall, etc. > But for help, firing up Chrome of Firefox is just too damn slow, and > eats way to much memory. Also you will have to implement your own search > (which will be slow over HTML files), table of contents and index pages. But isn't that what iota full text search is for, to preindex all the search stuff so no time is spent grepping through html files The issue with Iota I found was that it was written in an old fpc style where some things are not proper code, but compiled at that state of fpc development. iota, if you don't know, is a full text search indexing library for fpc. Discussed briefly on the fpc mailing lists eons ago. > Then what about other useful features like bookmarking a help topic, > inline annotations (user defined notes added to a help topic at runtime). > User defined notes, were not available in chm files were they? I thought chm/hlp file were just dumb, fixed help files with no bells an whistles. i.e. total commander style help. With a chrome embedded browser object, you can use the DOM to manipulate the document. That's basically how chrome plugins work in the browser where you can modify the html page and add widgets to someone else's site, on your client side. If you wanted to add notes to html help you could use the DOM to do it and store those extra notes in a database, or something. I'd be interested in how many people do this: add notes to their help, inline. We know that people add notes at the end of the documentation, like the php manual where people add comments to the bottom of the page. I didn't realize there were help systems were you could inline some notes? > As for communications with a external [dedicated] help viewer. fpGUI's > Docview does that via IPC, Microsoft's WinHelp I think could do it too, > OS/2 VIEW help viewer did lots of 2-way communications with applications. > > Which is an interesting question: why hasn't firefox allowed IPC from external apps. Could be a security vulnerability. Maybe just one of those interesting features that could be, should be, would be, but no one has thought of implementing. If firefox had IPC you could navigate to an anchor from an external exe. Also an interesting question is why hasn't adobe got something like this so that adobe files could be used as help files: scroll to a certain part of the pdf file programmatically using IPC, or maybe using an adobe embedded object. I find pdf files just a little too slow, though, and not as responsive, due to them being like a resource intensive graphic. So I suppose pdf files ruin the zippy feeling of a fast help system. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 22:46, Lars via Lazarus wrote: > Would the current help systems be even capable of looking like that? Must > be just a few div boxes. Really simple, interesting color shades. No > fancy garbage, just simple boxes of text. I don't know how much CSS the HTML component in LHelp supports. But if you look at the source of that website, they actually use HTML tables to do most of the layouting. Looking at the following page... http://delphibasics.co.uk/RTL.asp?Name=CurrencyString Also Free Pascal's fpdoc already generates all that same information: * summary line (name, one line description and unit name) * declaration * Description * extra notes * example code * See also (related commands) The fpdoc linear output writers (LaTeX, INF etc) formats the above information quite neatly. Then again, I thought we were talking about application help which could take on a whole different layout compared to technical API documentation. As for the color they used. Yes, they are nice pastel colors, but they don't really add much value. If the headers were more prominent (larger and nicer font), then the colored boxes probably wouldn't be needed. By using colour like that, you are also limiting your audience - eg: what about colour blind people? Just take a look at this web page and see what different color vision deficiency can do to the same image. http://www.color-blindness.com/coblis-color-blindness-simulator/ Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Fri, November 11, 2016 4:37 am, wkitty42--- via Lazarus wrote: > what's wrong with something like LHelp and using IPC to tell it where to > load the next help from that the user has asked for?? > I'll have to experiment with LHelp, thanks > from these cheap seats i have way over here, it seems like you are over > engineering this... > Anyone who pulls in a 150MB-300MB chromium embedded plugin is likely over engineering (not to mention bloatware). I'm critical of my own original post. Would be much better if there was a chromium lite version that you could embed which was only 2MB or 1MB. One plan I had was to simply port an existing html documentation system that runs on a cgi program on a server, over to offline help, with minimal effort. Chromium embedded seemed the way to go because you can literally trick chromium embedded into being a cgi like device, on the client side, without any web server. Whether LHelp can do that, is something I'd have to research. I have some existing projects where the help system is already in place, on a server, and I don't much feel like writing two sets of help systems one that works offline and one that works online, I'd rather just have one system that works online and offline. So I figured CEF3 or CEF1 would be a way to make already existing online documentation, work offline too. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Fri, November 11, 2016 4:23 pm, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 22:46, Lars via Lazarus wrote: > >> Would the current help systems be even capable of looking like that? >> Must >> be just a few div boxes. Really simple, interesting color shades. No >> fancy garbage, just simple boxes of text. > > I don't know how much CSS the HTML component in LHelp supports. But if > you look at the source of that website, they actually use HTML tables Holy batman, they are using tables? Wow.. I was sure it was a Div box based website but they are using classic tables. Interesting. > By using colour like that, you are also limiting your audience - eg: > what about colour blind people? Would be interesting if there was a firefox/chrome plugin that converted a website to be all black and white to help people, or maybe grayscale. But good point. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 23:09, Lars via Lazarus wrote: >> You can always use any other port >1024 for that. > > No issues with default firewalls? Last thing I want, is a customer having > to futz around with router firewall, windows firewall, etc. It was 4 years ago, but as far as I remember, we didn't have any firewall issues on Windows. > But isn't that what iota full text search is for, to preindex all the > search stuff so no time is spent grepping through html files Yeah, but deployment is going to be a pain isn't it? I know of iota, but I don't know how it works. I would imagine it needs to run continuously in the background? ps: I believe the is a FTS indexer as part of FCL as well. Though I think it was written for databases, not for HTML files. > User defined notes, were not available in chm files were they? I thought > chm/hlp file were just dumb, fixed help files with no bells an whistles. Now there's an interesting question. :) WinHelp supported both Annotations and Bookmarks, though the annotations were not inline - it simply showed a paperclip icon or something that you had to click to see the user defined notes, and was limited to one note per help topic. Window's CHM viewer only support bookmarks (they call it Favourites). So it actually has less features than WinHelp did. :) DocView supports inline annotations, bookmarks, full text search, advanced search terms (eg: search for this but don't include that, search by phrase, or fine something spelled similar to search term you entered). Docview also allows multiple annotations per help topic. The Bookmarks, Annotations and Advanced Search features are not part of the INF file format, docview implements those. Full Text Search comes standard with INF though - any word in the whole INF file is only stored once (all others are simply pointers to the word lookup table). This is also why INF is so compact (eg: one help file will be 3MB in INF, but that same help content will be a 12MB CHM file) On a side note: I use Docview's annotations support a lot! My Free Pascal RTL and FCL help is full of my own comments, code examples etc. I also use it to note down errors in the help (eg: spelling mistakes, grammar, examples) and then later when I have time, report those on Mantis as they are then easy to find again. > I didn't realize there were help systems were you could inline some notes? Take a look here: http://fpgui.sourceforge.net/screenshots_apps.shtml In the first screenshot, note all the green text. They are inline annotation examples. You can simply click them to edit them too. The yellow text is the highlighted search terms it found in that page. Both colors are user configurable, and so too is the font and page background color. In the "Search Results" list box, the numbers behind the help topics are a search rating value. The higher the value, the more precise the search result was (eg: the search term appeared more than once in that help topic). Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-11 23:39, Lars via Lazarus wrote: > Would be interesting if there was a firefox/chrome plugin that converted a > website to be all black and white to help people, or maybe grayscale. But > good point. Opera 12.x (and earlier) had that built in. Newer versions of Opera (based on Chrome) doesn't support that any more - and neither does Chrome or Firefox. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
