A place to discuss and plan OpenSource xTalk (not exclusively LCC based)
and Community Builds of LCC ...Ask NOT what xTalk can do for you...
Get involved you DO have something to contribute, no matter your skillset!
Forum rules
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!
I want to move away from a database approach in favour of a stack/card one.
It would be more accurate to say move back to a stacks/card approach, because that's how it was in 6.x before they changed it into sqlite + HTML/JS in Browser Widget. But even the way they did that was kind of hard to understand the system that was used to organize the many stacks that made up the thing. Look at the 6.x documentation folder and you'll see what I'm talking about.
I sort of like the idea of just using .txt or .rtf files in a folder, with a stack that indexes them, reads them into memory, styles them, etc.
I was not aware of that. That's cool. Here I am, reinventing the wheel... lol.
To be honest though, I'd rather work from a fresh clean slate on this.
There may be some typos in the dictionary data, but I didn't put them there - they exist in the 'vanilla' LCC versions too - but if they are text files, they are going to be nice and easy for all of us to edit in future.
I should also clarify: the dictionary database I've used is the one supplied by TerryL (the one that's been in OXT Lite for a while).
I'm not using the LCC database, so all the terms such as 'Livecode' are already swapped with xTalk, for example.
However I'm not using the database that's in your OXT RCx 'heavy' Paul - not because there's anything wrong with it at all. Purely the reason is that I didn't know if you've since added anything extra to that database that might only be relevant to OXT heavy.
I know you did mention previously that any additional database syntax is being pulled from various ide plugin folders, but I absolutely wanted to start with an (as close to) original database (but the LCC terms swapped out for 'xTalk' and 'the IDE'), which is the one I used.
(As we've been using in OXT lite for a while).
Just thought I'd clarify where my source data is coming from. As such, it won't have the midi stuff you've added, or the general music library - as you'd expect.
As per my original goal with OXT Lite, it's mainly a bug fix release and a debranded copy. (Yes, there's a few little UI additions here and there, but only because the original corresponding bits in LCC were broken).
Anyway, I'm drifting off topic. I've only done the xTalk script section of the database so far. I'll do the 'builder' and there's another section referring to 'data grids' - which will give you three search options when you search for terms in my new dictionary.
The search options will follow soon, so you can limit your searches to 'keyword, function, etc' too
Have now put the list of entries above the search result field. (as per the LCC design).
Tested on Linux and Windows. Mac testing to take place later in the week.
(There shouldn't be any difference, but want to test fully - just to make sure).
coming-along-slowly.png (49.7 KiB) Viewed 2967 times
I should mention, the 'keyentry' at the end of those lines in the search result, will disappear and be replaced with a prefixed icon in the list.
tperry2x wrote: ↑Mon Jul 22, 2024 9:45 am
I should mention, the 'keyentry' at the end of those lines in the search result, will disappear and be replaced with a prefixed icon in the list.
So, the key is a keyword
the F is a function
the gearwheel is a glossary icon (probably make this a G)
the P is a property
The envelope is a message
There's also H for handler and others, such as control structure etc
I took these from the icons on card 1 of the revIcons stack - if you open up the card, it's mainly the stuff in the 'Script Editor' group:
group.png (22.55 KiB) Viewed 2946 times
But, feedback is always good because now is the best point to change anything - even if it is a one-liner icon ID reference.
richmond62 wrote: ↑Mon Jul 22, 2024 3:39 pm
The trouble is that while an open envelope may signify 'messages' to Thee and Me, most of the kids I teach wouldn't know an open envelope if it hit them in the face.
That is probably very true.
The same way as none probably get what this icon signifies, as it's 'old-hat'.
whats-that-grandpa.png (5.49 KiB) Viewed 2914 times
However, this probably leads to a larger question. Should we also be changing the icons across the top bar to something more 'modern' - perhaps a similar icon to the telegram paper-airplane?
dict-and-icons-and-stuff.png (99.79 KiB) Viewed 2914 times
Also, that ties into your other post about eliminating the icons on the toolbar (which I don't think we should do, as I'd rather click a button than go hunting for it in menus / sub menus)
I will change the icons, probably to some hand-drawn (by myself, so no licensing etc) versions - based on this style.
For the time being, you can test the text-based dictionary here.
screenshot.png (95.41 KiB) Viewed 2867 times
Please consider this a BETA version. It's by no means final. I've not included the builder or datagrid syntax choices yet.
On another related note, for anyone new to xTalk - one of the issues we've raised is not actually knowing what to search for. I'm hoping this version of the dictionary will help with this, with the popup list of matching terms as shown below. If you search for 'mouse' for example, you'll get a list of other terms that might be helpful.
I've added the ability to select between the xTalk Script, the Datagrid Syntax, or xTalk-Builder (formerly known as LCB)
Hopefully it's now starting to resemble the LCC web-dictionary a bit, but as a stack.
I plan to put the filtering options on the left, and have a section where you can save favourites - or at least things you've looked up previously.
Does any of this seem good / bad / (indifferent) ?
tperry2x wrote: ↑Sun Jul 21, 2024 2:49 am
I know you did mention previously that any additional database syntax is being pulled from various ide plugin folders, but I absolutely wanted to start with an (as close to) original database (but the LCC terms swapped out for 'xTalk' and 'the IDE'), which is the one I used.
That's correct, those revDocsParser scripts pull in extension syntax dynamically, so there's a base DB and then the extra stuff is added if any is installed when the Dictionary first opens. The bottom line is isn't shouldn't be a problem to use my edited dictionary files in the repo for your purposes. I don't think there's anything in there that's from any of my added extensions (at one point I did and it created double entrees of the items so I removed them)
tperry2x wrote: ↑Sun Jul 21, 2024 2:49 am
Just thought I'd clarify where my source data is coming from. As such, it won't have the midi stuff you've added, or the general music library - as you'd expect.
You may find a handful of added or changed a glossary terms, such as 'MIDI' or 'OpenXION' or 'LiveCode'. Those aren't specific to any additions in DPE/Heavy. The one way to add glossary terms is by adding them to that folder as .lcdoc markdown. You can delete the ones you don't like (again I made very few changes to glossary terms).
Are you going to support linking the dictionary keywords for click-jumping to different referenced dictionary entries?
Many of the problems with the inherited dictionary where words are missing entirely from being displayed are a result of bad tagging for those automatically generated keyword hyperlinks. The missing words are actually there if you look at the raw markdown.
OpenXTalkPaul wrote: ↑Thu Jul 25, 2024 12:16 am
Are you going to support linking the dictionary keywords for click-jumping to different referenced dictionary entries?
Many of the problems with the inherited dictionary where words are missing entirely from being displayed are a result of bad tagging for those automatically generated keyword hyperlinks. The missing words are actually there if you look at the raw markdown.
I like the idea of that, so yes - that's something I'd like to experiment with adding.