OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
The mock-up collaboration thing with chat looks fantastic @tPerry2x !
I'm not religious about GitHub..I don't have a problem with using alternative system for collaborating... I can always mirror that merged IDE on MEGA to a GitHub Repo so that random people can have a copy of the work too.
That sounds like an ideal set of compromises that would suit everyone.
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
If we're going to work on a single version of the IDE, ...I'm concerned that a bunch of things in the IDE have multiple file edits involved in order to make certain changes work and some things may work on one platform but cause errors on another. I just don't want to be stepping on each-other's toes, you know what I mean?
Yes, that makes perfect sense. My approach does seem to be "what can I fix next?" -- and I'll go off and try something. We've also approached different solutions to the same problem at times, I'm sure. It is a lot of work to merge them, all in the name of possible speed of releases. However, speed isn't everything - and I like the fact that there's two approaches). That said, I'm not adverse to merging them.
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
Currently if I just copy my modified files, overwriting those files in OXT Lite, then Lite becomes the same as my version (just with different Icon / splash screen). The files need to be DIFF'd and then merged together. I started doing that before on several occasions, but it's a very time consuming task. I'll try to use this weekend (4-day holiday weekend here in the USA) to make a big push on that..
I'd like to understand how the diff tool works better in the IDE too, as I hoped we can use this, rather than relying on an external one. Something I'd build into that collab stack. There's some bits I'd definitely take from RCx/'Heavy' like your revMenubar - and using that as an example, that won't have the replicate option in, so a diff merge rather than a replace is definitely the way forward. I'd say initially, I'd expect a lot to break.
I'd like to take the preferences from OXT Lite though, as there's pref validation - and the entire stack has been re-laid out and made bigger (if you compare it to the LCC one). This is not simply scaled, I have resized the stack, moved controls around, added extra cards... you name it. It's not just script changes. There's the differences in the actual stacks themselves to bear in mind.
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
Probably after that I should make having a proper package manager for add-on things be a priority (rather than Tools-redo, which has been making me crazy anyway)
I didn't want to say anything, but yes - that way madness lies. It doesn't help the fact that LC used the same keywords for identifying sections, and the stack gets confused (which is why mine does a merry-dance with variables) to make things like the number of columns, the sections shown (which are labelled in OXT lite), and the conditional loading of light or dark tool icons (based on currently detected appearance).
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
...With that [package manager] out of the way, I'd be more likely to concentrate on core IDE things but still be able to deliver any "clever-clevers" when I think they're worthy of sharing.
For me, this is always part of the fun - seeing what other people have come up with as solutions. Mainly because I learn something by it.
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
I'm not sure why you'd want to disable the DataGrid but
NOT remove it? Is it a drag on anything if it's not in use? If it was removed I don't think that would be a very big disk space savings. Anyway,
No - you are correct, it saves next to nothing on disk space, but it saves quite a great deal of CPU use in the background as there's datagrid (dg) messages happening all the time when it's active. Also (as shown on
this post) - and the following picture:
...you'll see all the stacks it loads into ram when it's in use. Closing them off saves extra processing and saves available ram in the IDE. As a result, it does make it noticeably more responsive. But I'm aware some people use it, so that's why it's a pref.
OpenXTalkPaul wrote: ↑Wed Nov 27, 2024 6:54 pm
But that's a good way to handle it, having prefs for every modification, the only problem is editing revPrefGUI stack is a real pain using the Project Browser (or Application Browser).
I don't find it too hard to edit. I do it all with the inspector and Application browser, and can edit the stack through there by adjusting sizes, locations etc. It's like when I used to spend ages correcting artwork as a repro operator in illustrator - moving things around all day by just using the transform palette (and a calculator... because maths
)
The thing that comes to mind though is structuring of this shared folder.
We know it shares a common file structure when you get into the "Toolsets" folder, but MacOS has the "Tools" directory before that. I suspect this is so each modification does not break codesigning, because the codesigning is not interested in this "Tools" folder, so the mac engine is set to go there.
The Linux and Windows engine never looks for a "Tools" / "Toolsets" folder - they are straight into the "Toolsets" folders as default... then onto the similar folder structure.
What I'm getting at is, in theory I could be running the IDE in "collab-mode" and on my Linux computer. You could be doing the same, but sat at the Mac, also in "collab-mode". I wouldn't want to see your stuff before that "Toolsets" level, as remotely editing that on linux would definitely break your codesigning. So the IDE would need to know what was going on in "collab-mode" and lock the editing of stacks to prevent duplicate edits. This is also what I was thinking of the group chat in that mode, because that way - things can be tested 'live'.
I'd use UTC for universal co-ordinated timestamps.
I'm wondering if the IDE on Linux and MacOS would see the "Toolsets" folder if they were symlinked into the engine folder? In theory this would then mean they could be platform agnostic edits. (Although Windows
still doesn't handle symlinks properly) More on this later, I need to do some testing later to show you what I mean...
Edit. This is what I mean:
- proof-of-concept.png (414.4 KiB) Viewed 1171 times
Like this, the "Toolsets" folder isn't in the expected location for the IDE (it could be sat in our Mega sync'd folder through the mega desktop app) - the IDE still loads it, because as far as it's concerned, it
is there - it's symbolically linked.
This way, you can be editing using the mac engine, and I can be editing the SAME ide using the Linux engine simultaneously.
Of course, you can use the command line to make symlinks, or
you can use my tool here.