Displaying htmltext outside of xtalk

[tperry2x]

Alternatively, If you wanted to format the text inside of the xTalk IDE, how about something like this? :

format.png (79.18 KiB) Viewed 2702 times

The nice thing about this, is it'll adhere to whatever you have your script editor colour formatting set to in the preferences (whichever colour scheme you are using). It'll also work with whatever appearance mode (dark, light, GTK Yellow) system theme you might have chosen.

[Skids]

Thanks for your post, I shall see what I can come up with.

S

[Skids]

Maybe just include a substack with a field?

Do you mean add a sub stack to stack that is the target of the drag drop of the custom control ?

S

[FourthWorld]

Maybe just include a substack with a field?

Do you mean add a sub stack to stack that is the target of the drag drop of the custom control ?

I wouldn't copy it into the user's stack, just the delivery stack.

[richmond62]

I would have an invisible substack attached to your palette with a scrolling text field or a browser object to 'dump & display' the relevant info for whichever object an end-user selects on your palette.

[richmond62]

Screenshot 2024-08-21 at 14.50.09.png (311.2 KiB) Viewed 2348 times

[richmond62]

Screenshot 2024-08-21 at 16.19.44.png (287.01 KiB) Viewed 2338 times

[richmond62]

https://learninglivecode.blogspot.com/2 ... could.html

[richmond62]

If you append to the htmlText copied from a field into a string:

data:text/html,

you should be able to paste it into the field at the top of your browser to display that in the browser window.

Of course that does NOT open your htmlText at 'the flick of a switch' in a browser directly from an OXT button.

HOWVER, having tried that, I cannot get it to work.

[OpenXTalkPaul]

I'm pretty sure the 'Answer' can display styled text.
But you could also make a sub-stack in your palette that's like 'Answer', or that is a transient stack created on-the-fly that display's your styled text in a field and destroys itself from memory when it's closed.

But if you really want the text to be displayed in externally, in a browser you'd typically want to write an HTML doc to a file and then launch it with the systems default browser. You could also write the RTFtext of styled feild text to a file and then open in the systems default rich text editor, with a fairly high degree of certainty there will be some default app that can open rtf. Hell, if you really want to get fancy you could make docs as a PDF file and embedded into a customprop as binary data attached to your group, when needed have your palette write that data to file.pdf in your temp storage and launch it in the systems default PDF viewer. Doing any of these should not trigger any security warnings because you're app is only writing to it's temp folder, which should have the proper privileges allow for your app to write to it (even on mobile devices, maybe even when running on the Emscripten Engine).

If you wanted to have the docs added to at the dictionary (and I'm talking about the Browser Widget based Dictionary here), you would need to write that data with the appropriate .lcdoc flavored markdown tags, keywords, etc. and then call some handlers in the revDocsParser IDE library. I'll try to make some instructions for doing that.

Normally Widgets, xBuilder or XTScript Library Extensions are installed from a compressed package (.lce which is actually a zip file), and when it does it extracts the file "API.lcdoc" from the package and then revDocsParser parses it adding it's data to the dictionary immediately. API.lcdoc is usually created by the extension builder stack when you use it to compile or package an extension. It scrapes the .lcb source file for any inline documentation comments to create it. You can also create that file manually instead of using inline code comments. Markdowns are typically very simple formatting tags, which is basically the whole point of their existence, something else (like GitHub for example) is typically used to processes the .md into styled text. Another advantage to this format is that it has an established system of asscoiative keywords that are used to create links to other related dictionary entries (or even 'glossary' terms). You can also add a guide .md file including images to a docs folder in the package, that should gets automatically added to the 'Guides' section tab in the Dictionary stack.

I'm not sure if the stack versions of the fast alternative version of Dictionary or Guides that's in OXT Lite supports adding these files when a new package is installed.
If all Linux distros were fully compatible with the BowserWidget, then there would be no need for alternative documentation viewers in my opinion.

[tperry2x]

If all Linux distros were fully compatible with the BrowserWidget, then there would be no need for alternative documentation viewers in my opinion.

Indeed, but we are where we are with that. Unfortunately, I don't think that's going to happen any time soon. So, I added the glossary terms to the text version of the dictionary.

[OpenXTalkPaul]

If all Linux distros were fully compatible with the BrowserWidget, then there would be no need for alternative documentation viewers in my opinion.

Indeed, but we are where we are with that. Unfortunately, I don't think that's going to happen any time soon. So, I added the glossary terms to the text version of the dictionary.

I thought Mark Wielder was able to compile Linux version including updated Chromium CEF?
I suppose that might not help at all with weirdness between various window managers that don't like 'Native Layer'/FFI based widgets (which is what the BrowserWidget is). Do we have a list yet of exactly which window managers freak out, and which don't? I mean I have had usable Browser Widget on certain Linux distros.
Also before Widgets, wasn't there a revBrowser External for Linux like there was for macOS/Win? I'm curious if that external from v7 or v8 couldn't be pulled in and work with OXT/LCCE 9.x and if that would behave any better than Widget's 'Native Layer mechanism. That External basically just rendering the same 'browser factory' instances, but without the Extension Builder, into a rectangle on-top of a card, which is similar to the way 'Native Layer' works.

Of course we can continue to launch the HTML/JS version Dictionary in the OS' default web-browser on Linux, or use the stack/DB based version 'Dictionary', which does have the advantage of being far more easily editable by IDE users.