Dec. 24th 2021 - Rebuild the Builder

[astu]

Hello all

It's Christmas Eve and I have nothing better to do than to occupy myself at the computer... To relieve Paul a little bit, I nailed the "Extension Builder" project to my cheek.

I hope Paul will let me post my progress here *laughs*.
And I try not to write as much as Paul does

My first conclusion:
The structure of the Extension Builder is so... convoluted.
For example, all already installed widgets are loaded into an ENUM button, which can't be selected because it's covered by another opaque button. Also, the builder seems to be an essential part of the IDE.... If you remove it from the palette directory \Toolset\palettes\extension builder, the IDE does not work... and then the appearance of the builder is also additionally described in the script which makes changes to the design of the builder difficult. It is also not really obvious which script accesses where. So at the moment it's just not obvious for me, when and where e.g. the revidedeveloperextensionlibrary is accessed...

The whole construct looks like the development was stopped because it worked like that. As if it was not important to continue the development of the builder.

So I will have to redesign the "Extension Builder" and make some adjustments to be able to include new functions.

I wish you all a blessed Christmas, Hanuka or whatever you celebrate.

Greetings
Andreas (aka astu)

[OpenXTalkPaul]

Hello all

It's Christmas Eve and I have nothing better to do than to occupy myself at the computer... To relieve Paul a little bit, I nailed the "Extension Builder" project to my cheek.

I hope Paul will let me post my progress here *laughs*.
And I try not to write as much as Paul does

My first conclusion:
The structure of the Extension Builder is so... convoluted.
For example, all already installed widgets are loaded into an ENUM button, which can't be selected because it's covered by another opaque button. Also, the builder seems to be an essential part of the IDE.... If you remove it from the palette directory \Toolset\palettes\extension builder, the IDE does not work... and then the appearance of the builder is also additionally described in the script which makes changes to the design of the builder difficult. It is also not really obvious which script accesses where. So at the moment it's just not obvious for me, when and where e.g. the revidedeveloperextensionlibrary is accessed...

The whole construct looks like the development was stopped because it worked like that. As if it was not important to continue the development of the builder.

So I will have to redesign the "Extension Builder" and make some adjustments to be able to include new functions.

I wish you all a blessed Christmas, Hanuka or whatever you celebrate.

Greetings
Andreas (aka astu)

Ah, you're talking about the Builder Stack, not the lower level bits that compile the intermediate byte code? Or do you mean both things, but first fix the GUI? I agree that there is lots of spaghetti wiring in the IDE. It is a beast that needs taming. If any part of the IDE startup fails then most of the rest of the IDE does not get loaded, making any changes made so far a 'try-it and see what it breaks' sort of exploration. I'm always working on copies of the IDE files so that I can quickly revert. The IDE stacks handle a lot of functionality, and much of it is scattered across several IDE stacks, frontscripts, backscripts libs... This is why I think it's very important that we document everything that we can about what goes on in the IDE.

Extension Builder stack certainly seems unfinished to me, the SVG Extension Icons previews if there is any, have never aligned to the same position that the default icons are rendered for example... and there's no denying that the 'Extension Manager' stack with it's additional, empty or partially functioning additional tabs, is incomplete. Extension Builder I've seen exactly what you mean about the UI having layers of controls, disabling other controls underneath, and there was hard coded links left in to a dev's local storage files.

I do hope you are working from OXT repo files, I made changes to the Extension Builder already, one that fixed a cross-platform (macOS/Win10 related) compiling problem. I also made some changes that effect the colors in the Extension Manager Extension lists which I'd like to revert or modify again because disclosure popup menus blend in too much on the darker stripped grid list items, but those colors come from a completely separate library.

Right now I'm very interested in the standalone builder, and macOS code signing, entitlements and such. The standalone builder is actually made of a few separate libraries. I spent my Christmas Eve morning looking into creating a code signing certificate for self-signing the Binaries of the IDE. Interested in how an entity becomes a 'signing authority'. I'm looking to re-sign the now unsigned binary, using ad-hoc self signing or perhaps an Apple Dev ID generated one. As far as I know, it doesn't actually need to be signed, even in the latest macOS Monetary you can run un-signed apps IF you do the right-click to open trick, TWICE, after some scary warnings from the Finder, but that's less then optimal way to distribute a Mac app these days. Unfortunately I fear Apple will only go even further into being a isolated system with Apple being the sole gatekeeper, in the name of security.

Obviously, I didn't release anything on Dec.25th like I had wanted to. I've had several major distractions in my life recently, beyond normal Holiday family related things this time of year. It's been one domestic disaster after another, starting with our dishwasher needing replacing, and going up to our family room ceiling needs replacing from water damage (that's another story), it's been like the movie "The Money Pit" over here, lol.

But it hasn't been all bad. I got put into a raffle for some workstations that were replaced this year and wound up winning a build-to-order iMac that's a few years old (6th Gen i7) but still a really nice rig since it had max custom config options. I'm thinking I could sell it and use the money to cover an M1 mac to use for dev. I'm torn though, with it's 27" 5K Retina display, 4GHz i7, 4GB GDDR5 dedicated GPU, 32GB Ram, and an SSD (that I happened to know was barely even used), it's a really nice rig for working in Illustrator, PhotoShop, etc.

I have (almost) this entire week off to work on things.

I hope everyone is having a nice winter Holiday Season, cheers!

[astu]

...
I do hope you are working from OXT repo files, I made changes to the Extension Builder already, one that fixed a cross-platform (macOS/Win10 related) compiling problem. I also made some changes that effect the colors in the Extension Manager Extension lists which I'd like to revert or modify again because disclosure popup menus blend in too much on the darker stripped grid list items, but those colors come from a completely separate library.
...

Yes, I am talking about the stacks here. I am of the opinion that a developer must first find errors and problems in a conversion / new construction and fix or rewrite them before you go to the design element.
Function before appearance.

In the case of the ExBuilder, unfortunately, the design had to be adjusted first and a few flaws ironed out.

I mainly work on the stack in a separate installation of version 6.4(dp4). There was a small change 7 months ago to the stack in the LC repo, but this is only maginal. In the OXT-Repo I have uploaded nothing yet, because without consultation here the risk is too big for me to shoot something else, because I had not yet looked what was changed there.
And first it must be still functional in LC, before I can make appropriate adjustments in the direction of OXT. But I will also have a look at the OXT repo to see what changes have been made to the script that I should pay attention to.

So far I have only worked on the layout and removed a few elements that were unnecessary. And all concern so far only the Extension Builder and its Behavior Script. -> revextensionbuilder.livecode and revextensionbuilderbehavior.livecodescript

By the way, I work according to a roadmap. in which I work through the individual steps accordingly and I can track what the last steps were.

Cya
Andreas

[OpenXTalkPaul]

...
I do hope you are working from OXT repo files, I made changes to the Extension Builder already, one that fixed a cross-platform (macOS/Win10 related) compiling problem. I also made some changes that effect the colors in the Extension Manager Extension lists which I'd like to revert or modify again because disclosure popup menus blend in too much on the darker stripped grid list items, but those colors come from a completely separate library.
...

Yes, I am talking about the stacks here. I am of the opinion that a developer must first find errors and problems in a conversion / new construction and fix or rewrite them before you go to the design element.
Function before appearance.

In the case of the ExBuilder, unfortunately, the design had to be adjusted first and a few flaws ironed out.

I mainly work on the stack in a separate installation of version 6.4(dp4). There was a small change 7 months ago to the stack in the LC repo, but this is only maginal. In the OXT-Repo I have uploaded nothing yet, because without consultation here the risk is too big for me to shoot something else, because I had not yet looked what was changed there.
And first it must be still functional in LC, before I can make appropriate adjustments in the direction of OXT. But I will also have a look at the OXT repo to see what changes have been made to the script that I should pay attention to.

So far I have only worked on the layout and removed a few elements that were unnecessary. And all concern so far only the Extension Builder and its Behavior Script. -> revextensionbuilder.livecode and revextensionbuilderbehavior.livecodescript

By the way, I work according to a roadmap. in which I work through the individual steps accordingly and I can track what the last steps were.

Cya
Andreas

I sort of had a rough road map but once I got into the de-brandling and realized how interconnected things in the IDE can be, that plan went off the rails a bit.
The changes were all done via GitHub so there's a record of every change merged, although that can not show you details of changes in binary stack files

Off the top of my head I can tell you I added a filter to the handler that scans the Builder project folder for .lcb files to compile. It removes any file in the file list that begins with a "." character which typically means it's invisible file on POSIX systems. The problem was this: if you develop on macOS and then move the same project folder to Windows, then Windows would recognize macOS "._filename.lcb" meta data files as if they are valid files and causes Extension builder to think that there is more then one lcb file in that folder, and then not allow it to be compiled, incorrectly reporting that there is NO builder files in the folder!

AFAIKR there was changes to the textColor of foreColor of the buttons in the GUI stack part of it to ensure the Button text was black so that it would be readable in darkMode on macOS.

[astu]

It looks like we just have different approaches to this. My work is first of all about the Extension Builder stack and its Behaviorscript.

I have pulled the part from the OpenXtalk IDE-DontPanicEdition/IDE Bundle/Contents/Tools/Toolset/palettes/extension builder/ and will make a comparison.

But if I see it correctly your changes refer primarily rather to the libraries directly for the compiling are responsible. This is not done in the behavior of the Extension Builder. Therefore, I see here no problems that the "new" Extension Builder should cause problems here. I try to follow your changes as good as I can and I can see it.

I know that you have managed the project so far almost all by yourself and you have my full respect for it. I also find it a pity that not more people support the project here. For me, i would like to support the project here where I can.

But if you allow me a small criticism:
Without wanting to poke you in the head, for me the functionality is more important than a "DarkMode" design. Please do not get lost in the design. A DarkMode is nice to have, but not essential. More important is really first the function and the rebranding.

Let's first fix the bugs and flaws that have accumulated over the last few years.
The rebuilding of the Extension Builder is only a small, for some maybe not important, step. But it is a start to fix what has been ignored for a long time, as well as the compiling problem you have solved. Such things should be addressed first.

[OpenXTalkPaul]

It looks like we just have different approaches to this. My work is first of all about the Extension Builder stack and its Behaviorscript.

I have pulled the part from the OpenXtalk IDE-DontPanicEdition/IDE Bundle/Contents/Tools/Toolset/palettes/extension builder/ and will make a comparison.

But if I see it correctly your changes refer primarily rather to the libraries directly for the compiling are responsible. This is not done in the behavior of the Extension Builder. Therefore, I see here no problems that the "new" Extension Builder should cause problems here. I try to follow your changes as good as I can and I can see it.

I know that you have managed the project so far almost all by yourself and you have my full respect for it. I also find it a pity that not more people support the project here. For me, i would like to support the project here where I can.

But if you allow me a small criticism:
Without wanting to poke you in the head, for me the functionality is more important than a "DarkMode" design. Please do not get lost in the design. A DarkMode is nice to have, but not essential. More important is really first the function and the rebranding.

Let's first fix the bugs and flaws that have accumulated over the last few years.
The rebuilding of the Extension Builder is only a small, for some maybe not important, step. But it is a start to fix what has been ignored for a long time, as well as the compiling problem you have solved. Such things should be addressed first.

Criticize away! I'm not easily offended, and as long as it's constructive criticism...

I will say that this is a criticism that I have heard before and taken note of (@Richmond). My response is this...
I have had to edit many of the stacks in the IDE in order to debrand it, which has always been the first main goal. Some of these, such as the "Resource Center" (which hasn't been updated in a decade it seems) involved extensive edits.

I use and like darkMode, it's increasingly popular with the general public (Win10+ with Win11 adding it system wide), with LC Ltd. added preliminary support for it. DarkMode has practically become a requirement for me. I wrote a Builder extension library that does system-level darkMode on the Mac (window frames, menus, etc.) that I've been using/testing with the IDE. DarkMode isn't 100% compatible since most of the "Classic Controls" are custom drawn controls, mostly buttons need to have dark-on-light or light-on-dark set in their foreGroundColor/backGroundColor properties, depending on mode, in order to be readable (some of these are edits that need to be made to the default properties (which are Tab Separated .TSV files).

These are usually simple edits to do for GUI stacks that I might as well do while I'm in those stacks editing them anyway. They don't take a lot of time to do. Usually finding the control that needs editing is the bulk of the time. But I will admit it can become distracting from the more important goal of debranding, particularly with stacks that are generated via script in memory by the IDE, which includes the Property Inspectors, revMenuBar, revTools etc.

Part of the time I've spent has been used in learning how the whole IDE is constructed, in order to rebuild it. Indeed many entries in the syntax Dictionary needed to be edited for unbranding and the dictionary needed to be rebuilt from "source" .lcdoc md files. It is made of a stack, Behaviors scripts, an SQL db, HTML/CSS and JavaScript!

I fully intend to go down through every single part of the IDE, down to the underlying engines C++ code, and I have spent some time setting up to compile the binaries from source (which I then had a major delay from messing up partition tables while trying to set up for tripple-OS booting). But for me fixing the IDE itself IS fixing bugs and 'stretch goal' ('modern and polished IDE') left unfinished.

Keep in mind that I am only a hobbyist coder (and hobbyist musician). I think of myself first and foremost as a graphic artist and so I'm always going to be interested in GUI things (and sound/music stuff). But I certainly would LOVE ANY and all help I can get with ANY of it! I'd also note that I'm perfectly willing to let someone else to lead, someone that has more experience in this sort of large scale development project would be great... or even someone who just wants to take a crack at it! In fact it would be a bit of a relief!

We do need to communicate what we are each doing so that we don't reinventing the same wheel.
GitHub can help with that.
I'm sure everyone has different ideas what should be a priority.
So here is a list of goals that I had in mind after rebranding:

•  Fix the Browser Widget on Linux 64 (and possibly get it working on Linux 32) which would likely involves some editing of revTools palette scripts, and also enable the syntax Dictionary to work in the same way that it works on Win/macOS, which is via the Browser Widget.
• RECOMPILE The Engines on ALL platforms, which doesn't really need to be done yet, since there hasn't been any changes to the C++ source, but it is important to get set up for when there is. One thing that would be immediately beneficial would be to remove the embedded LC user registration stack (which is currently presented on first run, and then checked at every launch).
• Finish and expand the "Extension Manager" stack, repurposing it as a "Package Manager", perhaps combining the "Resource Center". This will be able to use remote repositories in a decentralized way. KODI user add-ons (which are mostly Python scripts) is the example I intend to model this on.
•  Replace all of the "classic controls" with Builder extensions that use either multi-platform "native" controls for whatever the platform it's running on, or custom scalable vector versions with lots of customization options, or both! My thinking here is that someone building a GUI stack shouldn't have to worry about using a "Mac native" button widget on macOS, an "HTML5 native button" (whatever that is) on an Emscripten build, etc. The current methods do NOT work for the 'build once deploy across platforms' ideal.
•  Update the Android Deploy scripts to add option to use the newer .aab bundle packaging format (which is now a requirement for Google PlayStore.
• Change the Tools palette and ToolBar, making certain things more like a page layout program. I'd like a separate align / distribute objects palette which I've already done some work on (in the style of Adobe Illustrator) as well as a properties / styles palette.
• Finish Darkmode on all platforms (Windows needs system level darkmode support).
•  More extensions! For example a cross-platform PDF Widget would be nice. PDFium could be wrapped (which is what LC did in their commercial product), or it could be some other PDF rendering engine, such whatever the platform native PDF view is if any (I've already made a widget that wraps Apple's PDFKit).

I'm sure I'll think of more later.