richmond62 wrote: ↑Thu Dec 22, 2022 9:30 pm
The AppImage is NOT non-functional
And I did NOT state is was 'non-functional', what I did state was that it was 'pretty non-functional' meaning
that is was sufficiently non-functional, on XFCE (Xubunut) at least to be unusable.
That's why I'm only
a bit offended.
Admittedly I had not tested the AppImage with XFCE before uploading it to GitHub, I've been using KDE Plasma and elementaryOS Pantheon lately as those have been the best GUI experience for me on Linuxi (plural?). I have since installed Xubuntu into a VM container for clean-install testing and mostly it's the message box and dictionary problems, although the Dictionary did display for me fine, it has some search box issue that apparently only effects XFCE.
If you could offer some more detailed information about
exactly how it's unusable for you and what
exactly you are running (version numbers and that sort of thing) or what is installed on you Linux at least as far as what libraries and window manager things are available, that would be great! Various features (like Chromium Embedded Framework which is used in several places in the IDE) have their own dependencies and they aren't the same as what I've seen listed 'over there', which usually seems to list just the minimum dependencies to get basic engine features to work. And the other issues seem to be related to the engines window-modes (palette stack, modeless, modal, etc.) having issues with specific windowing systems. It would be great if we could compile a list of exactly which Desktop Environments / Window Managers have issues and
exactly what those issues are. We don't have bugzilla over here, we have 'GitHub Issues' (although I am open to doing something else).
Better then detailed reporting would be to make and share a tool that could collect that information for a user so that they can post it here (or better yet on GitHub repo). I have built the beginnings of a Command-Line-app-browser-GUI stack that may be a good starting point or help developers build such a tool (useful on macOS too).
The Dictionary problems on Linux could become moot, as I have been working on a stack based on something MaxV (who occasionally pops in here) posted about 8 years ago. It's a basic Dictionary browser (no 'Guides' tab) stack that reads directly from API.sqllite database files. Currently the Docs stack uses these DBs to build new web page files that it caches and then caches again, and in LC creates new disk-space-wasting caches for each and every new version (without deleting the old versions cache), but this stack keeps things simple (K.I.S.S.) and reads individual entries directly from the DB file quick, does minimal formatting and then displays it quickly. I had look at using BN's tinyDictionary as an option too, but my issue with that is it is slow to load, tinyDict seems to be building a whole new DB each time it opens, and I had trouble editing the layout which is built around Bernd's 'mod-table-field' thing which is similar to the 'DataGrid' (perhaps OXT could/should include it as an option?), it's has some nice features but maybe more than is needed for a utilitarian stack. The later issue is one that I have with a few otherwise really nice 'add-ons', they try to do too much, more than is needed ( like adding user notes to the DB entries or parsing all of the Extensions add-in docs data all at once), adding bloat and slowing down execution. To my mind being able to find some syntax to use should be as quick of an action as the computer and IDE can possibly do that, and MaxV's dictionary was the closest thing I found to that end. The problems was it's OLD, written for version 7 or 8, and needed to be update to work with v9 as they changed the formatting of the API DB. Additionally I had to modify both of these dictionary stacks to support the difference between LC and OXT (namely the removal of the word 'LiveCode' from the database's API category names). Lastly being a regular stack should make it easy / useful to back-port to say v.7 (for the dusty old ARM7 Raspberry Pi builds). This fast dictionary could become the default, leaving the 'Browser widget webpage dictionary version available as a Preferences option if the user prefers that.
A side note about GitHub
I don't understand the resistance to using GitHub (or GitLab, or whatever.) that seems to prevail. Maybe the reason it seems to be unpopular with this community is because xTalk's stacks have traditionally been binary formats that aren't so version-control-system friendly and so there is less utility to that? I don't know, but I do know you can upload binary files to GitHub just fine, and it has
issue tracking and other things useful for collaborative efforts and project management, and GitHub is free for open-source projects to use so that's handy. Theres a lot of really smart people in the xTalk community that genuinely love and care about xTalk language and want to see it being used by the general public at large, if they/we could all just come together to
collaborate on this general goal (be the 'Python' of the AI fueled 'natural language' age) it could be "insanely great"!