Dictionary rewrite - thoughts, please

[Brahmanathaswami]

OK... not waiting for more talk... have at it on the GUI here:

https://www.figma.com/file/eLKlg073BC1A ... ry-Designs

Don't ask permission to change it.. just make it better

[Mikey]

I've unleashed a monster, lol

[Brahmanathaswami]

I added a screen shot of the dictionary pre 8... anyone else have a screen shot of BG;s dictionary? I'll try to install that here.

Perhaps we can all list what we like/want in broad strokes without thinking initially about how the UI will "do it"

[Brahmanathaswami]

What up, BG?

maybe bjoernke just needs help to bring his old dictionary up to 8.1.3? I loved it.

[FourthWorld]

Putting this in for the record: Path to dictionary goes like this in LC for Mac... we probably need to be using special folder path.

Applications/LiveCode Business 8.1.3 (rc 1).app/Contents/Tools/Documentation/html_viewer/resources/data/api/api.sqlite

Rather than work with it directly, when I was exploring the possibility of writing an alternative Dictionary I found the IDE's API call for querying by token to return an array. I can't recall what it is offhand (I'll have to dig it up from notes), but I found it in the Script Editor's Documentation pane.

The array it returns is really great - very tidy, very complete. Well worth considering, since that chunk of the work has already been done, so folks working on this project can focus on UI.

[Mikey]

Right. In all likelihood the data structures are fine.

[Brahmanathaswami]

More input from HQ (Elanor):

Re field "entry-data" blob in the api.sqllite dbase: Yes, it is an encoded LiveCode array, you can use arrayDecode to turn the blob
data back into a LiveCode array. I suggest you have a look at the `revIDEDocumentationLibrary` stack. It may be that that you don't need to access the database directly and the API can provide the information that you need.

Yep agreed, we an focus on UI...

[Mikey]

At some point I think making the db more obvious/easier would be a good thing to do, but after we do the first work.

[BvG]

What up, BG?

maybe bjoernke just needs help to bring his old dictionary up to 8.1.3? I loved it.

Well, actually I need anyone else to do it, 'couse most likely I won't be able to do it.

The current IDE dictionary stack is not that different from the old (xml) way it was done, the main difference is that the text itself is not livecode style htmltext, but some form of markup (of which they don't know all the specifics themselves: "we used some php script", note that they also made their own additional markup, mostly to have sub-divisions).

Basically if you want to update bvg docu and call it MikeyDocu, all you'd need to do is a markup interpreter to get htmltext out of the existing dictionary. It's probably not a huge amount of work.

[Mikey]

What do we like about the new dictionary?

[Mikey]

Here's another great (but phase 2) suggestion, and Ali should get the credit for it: When there is an issue with the documentation, for example http://quality.livecode.com/show_bug.cgi?id=19192, the person who is filing the issue should be able to fix the entry in their dictionary and submit the correction. If we could magically turn that into a pull request, even better.

[Mikey]

Next thing to think about: Would it be faster/easier/cheaper/better to (try to) "just" switch frameworks? I haven't tried it, or thought about trying it until last night when I was poring over all the...stuff...that went into making the documentation the way it is, now.

[Mikey]

or what about going completely nuts and converting everything to run in dash and zeal?
Here's one discussion: https://codetuts.tech/tools-to-read-off ... mentation/

Similar to the idea of editing your scripts in a text editor http://beebom.com/best-text-editors-for-mac/ because they are better text editors than the script editor, and they are constantly being worked on, this would make for one less thing the team/community has to maintain.

Launching the external documentation viewer would be a matter of having a preference pointing to the viewer, then when you hit the api menu item, launching it.

[Mikey]

Also per Ali,

The database is built from the .lcdoc files and from the extracted inline LCB docs by the revDocsParser script - each of the binary blobs is just the docs data in a livecode array, encoded using arrayEncode.

I suggest using the API in revIDEDocumentationLibrary to access the database, or extending it there if there are any functions missing.

You *probably* don't need to know much about the docs generation, unless you do, in which case it is a combination of revDocsParser and the docs builder https://github.com/livecode/livecode/bl ... codescript

The current dictionary uses json instead of the database, but they are both generated from the same array of docs data, so they should be the same, essentially. It would be good to get rid of the json data entirely, as it's obviously harder to add to / remove from dynamically (as happens when eg a widget is loaded), and doesn't hepl with searching etc.

[bn]

Hi all,

here is a very preliminary stub of a stack that reads from stack "revIDEDocumentationLibrary" the array with the dictionary information, puts it into a modifiedTableField (homegrown).

This happens on preopencard, so there is a slight delay when opening the stack.

Clicking on a line or moving with the arrowKey up/down shows the details in a field below. The field entries are not formatted yet. No hyperlinks etc.
Sort by clicking in header, search using search field. Empty search field restores whole dictionary.

Just to show how easy it is to get at the information.

Kind regards
Bernd