OpenXTalk Forums

How about .webp images as they seem to be proliferating like rabbits?

Non-quadrangular buttons?

Start with round ones.

Pent, Hex, Oct?
- -
Faking buttons with Polygonal vector graphics . . . no 3D . . . not the same.

Make the 'SpeechBubble' graphic capable of taking editable text (like a text field) rather than having to group it with a text field:
- -
OK, OK: I wondered if I wasn't being overly critical, so I tried:
- -
BUT . . . 'clunk, click, every trip.'

When I said things were can add, I meant user guides and documentation.

Also engine improvements and fixes. Someone getting the Mac version to compile without error, not on about arm support - just getting a compile to succeed would be a start.

The windows version of the engine updated, and the gyp build tool eliminated / swapped out.

When I said things were can add, I meant user guides and documentation.

Obviously that was not clear enough for me to work out.

Anyway, 'tis not a bad thing to have a place for suggestions.

With regard to this:
- -
This is a good example of the sort of 'widget' (locked group?) we could run up inwith xTalk.

While, currently, you have 2 Dictionary stacks (or ways to access the Dictionary information).

I wonder if there is a way you could 'reintegrate' the LC Dictionary for people who may prefer that style?

Okay, multiple points to unpack here...

With the grouped objects (and yes, I agree - the term 'Widget' is so ambiguous) Do you remember I previously experimented with buttons that had a load of grouped objects, with the view to having this as a palette - a bit like Mark's powerTools palette, where you can choose various button styles.

Okay - so maybe not styled as MacOS 10.6 ones - as I shouldn't really be ripping off Apple's UI inside OXT, but you get the idea - we can have a load of preset buttons from a selectable panel.

-
The process is very easy indeed.

richmond62 wrote: ↑Tue Jul 16, 2024 4:15 pm While, currently, you have 2 Dictionary stacks (or ways to access the Dictionary information). I wonder if there is a way you could 'reintegrate' the LC Dictionary for people who may prefer that style?

I probably could, and this would require a lot more work. If you have tried to build a dictionary stack - it's not as easy as you first might think, but could be done to 'mimic' the LCC style a bit more. The reason the dictionary doesn't display all the entries upon open is purely one of lag and loading time. This is why it only starts searching after you've typed 3 characters or more - to keep the number of responses returned and the lag down.

NOT an easy process if you don't want to use a browser stack. Which I don't. Because of issues with the browser 'widget'. As mentioned multiple times, and not going over all that again.

"Lag time" . . .
- -
Nope.

Presumably you have not included new terms in the Dictionary???

The only snag I can see with the LC 8.2 and so on Dictionaries is their web browser thingy which is a non-starter on Linux.

I have none of my pre-Apple-went-bonkers Macs currently connected, but I will dig out the revDictionary stacks from LC 7 and LC 6 and see if they will behave themselves in these respects:

1. Cross-platform.

2. Displaying the dictionary information stored inwith the IDE.

richmond62 wrote: ↑Tue Jul 16, 2024 4:36 pm Presumably you have not included new terms in the Dictionary???

Nope, because I don't know how.

Nope, because I don't know how.

Oh, Sh*t.

Where are the Dict info source files stored?

file:///Users/richmond/Library/Application%20Support/RunRev/Documentation%20Cache/8_2_0_dp_2_community/api.html

Time to get out my long-armed shovel.

Ahhhhhh: very sexy:
- -
BUT, where are the OXT files?

(unless, of course, they are just @#$%^&ing the 963 ones.)

Paul did do a huge guide previously, trying to explain how to add items to the dictionary, how it's loaded - how the IDE is supposed to pick up on it....
It's generated dynamically when the IDE starts up, and when plugins are added.

I hope I don't offend him, but it was the same problem as livecode builder - it was not easy to follow and not too long after reading into it, it was still a total mystery.

If it was "up to me", the database would be gone tomorrow.
What I'd do instead of the database is automate a recursive script to take each dictionary entry and generate a new card with that name on a new stack. A stack comprising of however many cards (as the documentation says there's "no limit" to the number you can have)... so, then if we need to update a record in future - you navigate to the card in that stack and edit the entry on that card. Simples.

However, when I say "up to me", I realise I'm not just working to satisfy myself here - I am trying to listen to other people's suggestions (believe it or not ) and that's the only reason why I've persisted with the database approach. If not, like I say, it would be toast by now.

Quote myself here but:

It's generated dynamically when the IDE starts up, and when plugins are added.

This is the reason going away from a database approach is frowned upon I think, because if a user adds documentation for their plugin, how do we pick up on it in our dictionary?

Well, quite simply we have the dictionary card load in text files from inside the custom plug in folder and create the card as needed.
I think that's the simpler approach. I've not really seen any noteworthy examples where a third party plugin author has written bits that get patched-in to the dictionary ad-hoc (but then, in all honesty I've not been looking - because I wouldn't know WHAT to look for) - we've come back full circle to that old chestnut

Whereas, if the dictionary had tabs for newly added custom plugins, you could browse through the syntax and that would give you an idea how to use the plugin.

Aha: here are the 'little dears':
- -
Mind you, how one gets into one of the files in one of those folders in a meaningful way is another big, fat question.

And which one. ROFL!

At the risk of insulting your Mac knowledge I heartily recommend:

https://www.barebones.com/products/bbedit/

That doesn't look very dynamic.

So the IDE traverses each one of these subfolders, looking for documentation, as far as I understand it.
Then it somehow amalgamates this into the dictionary when building the api and html files for viewing later.

(by the way, I'll find that bit of code - because it is an absolute nightmare)

It adds a considerable lag to the startup time, so removing it would speed things up.
Calling it as a stack would also only load it into memory as needed. AND no browser required.

That's if I was doing what I wanted.

Well, opening that api.html file with a browser is a bucket of brown stuff:
- -
If I enter a search term in the 'search' box nothing happens at all.