Hi Everyone, I am writing this mail to seek your feedback on the correct behavior for the *Tools > Macros > Edit Macros...* menu item. My recent work on making the Basic IDE launch asynchronous has led into this situation, and I would appreciate your input on the best way to resolve it.
*basctl: Asynchronously launch IDE to fix UI freeze and crash* - https://gerrit.libreoffice.org/c/core/+/189922/ ---------------------------------------------------------------------------- *The Journey So Far: Fixing the BASIC Macros UI Freeze* It all started with the new Object Browser in the Basic IDE, which highlighted a situation where closing the "BASIC Macros" UI which was freezing after the IDE was launched synchronously led to the LibreOffice crash post clicking on this. *tdf#165785: [GSoC] Add UI shell and integration for Object Browser* - https://gerrit.libreoffice.org/c/core/+/186822 To fix this, I created a solution to make the IDE launch asynchronous. To avoid repeating code, I centralized this logic into a new shared function, *basctl::asyncIdeLaunch*, basctl/source/basicide/asyncidelaunch.cxx which is now used by files: `macrodlg.cxx`, `MacroManagerDialog.cxx`, `moduldlg.cxx`, `moduldl2.cxx` The only place the *synchronous launch* was intentionally left is in the error handler *HandleBasicError* in `basobj3.cxx`, where it seems to me is required. ---------------------------------------------------------------------------- *The Discovery of this situation* Last night while testing with Hossein, we discovered a strange situation with the direct menu path *Tools > Macros > Edit Macros...:* *1*. If I start a fresh session of LibreOffice, this path opens the IDE with a broken?/default, "no context" UI with our Object Browser patch. -> Similar to this screenshot - https://bug-attachments.documentfoundation.org/attachment.cgi?id=202574 *2*. Interestingly, if we first open the IDE the "long way" via *Tools > Macros > Organize Macros > Basic > "BASIC Macros" UI > Edit Button > IDE launch* the IDE opens correctly as it was earlier before these async changes. *3*. After doing this once, the direct *Tools > Macros > Edit Macros...* path also starts working correctly for the rest of the session. This suggests the "long way" correctly "primes" the Basic engine?, and then this direct path benefits from this for the rest of the session? ---------------------------------------------------------------------------- *The Investigation: Different UI Workflows* Our investigation shows that different menu items have very different workflows, with the Edit Macros... path being the outlier: *1. **Tools > Macros >**Run Macro...* opens the *"Macro Selector" dialog,* which asks the user to choose a macro before running it. * 2. Organize Macros> Basic...* opens the *"BASIC Macros" dialog,* which also requires the user to choose a macro before clicking "Edit". *3. **Tools > Macros >**Edit** Macros... *tries to launch the IDE directly, which fails on the very first launch with our new Object Browser patch changes. *4. Tools > Macros > Macro Manager... *opens the *"Macro Manager" UI* which again asks the user either Edit/Rename/Run/Export macro etc. ---------------------------------------------------------------------------- *The Historical Findings* I used these command - git log -p -S "Edit Macros" -- officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu git log -p -S "Edit Macros" -- officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu | grep -C 3 -E "commit |Author|Date|Edit Macros" Digging into the git history reveals to me this is likely an accident. *1. Frank Schoenheit (2009):* The *SID_BASICIDE_APPEAR* command handler in *sfx2/source/appl/appserv.cxx* was created with a special, low-level hack specifically for autorecovery. The commit message makes this clear. The accompanying comment warns that the IDE "does not really play nice with the framework's concept." *autorecovery: open the Basic IDE via SFX' document loader* *Link:* https://git.libreoffice.org/core/+/aafbcb76ec238c947a304a71e44ac1e856136ca3 *Here is the code snippet -* line 1726: #if HAVE_FEATURE_SCRIPTING case *SID_BASICIDE_APPEAR*: { SfxViewFrame* pView = lcl_getBasicIDEViewFrame( nullptr ); if ( !pView ) { SfxObjectShell* pBasicIDE = SfxObjectShell::CreateObject( u"com.sun.star.script.BasicIDE"_ustr ); pBasicIDE->DoInitNew(); pBasicIDE->SetModified( false ); try { // load the Basic IDE via direct access to the SFX frame loader. A generic loadComponentFromURL // (which could be done via SfxViewFrame::LoadDocumentIntoFrame) is not feasible here, since the Basic IDE // does not really play nice with the framework's concept. For instance, it is a "singleton document", // which conflicts, at the latest, with the framework's concept of loading into _blank frames. // So, since we know that our frame loader can handle it, we skip the generic framework loader // mechanism, and the type detection (which doesn't know about the Basic IDE). const Reference< XComponentContext >& xContext( ::comphelper::getProcessComponentContext() ); Reference< *XSynchronousFrameLoader* > xLoader( xContext->getServiceManager()->createInstanceWithContext(u"com.sun.star.comp.office.FrameLoader"_ustr, xContext), UNO_QUERY_THROW ); ::comphelper::NamedValueCollection aLoadArgs; // more code...... another patch after this - *autorecovery: rename SfxViewFrame's LoadDocument to LoadDocumentIntoFrame, and introduce a new LoadDocument,* which does not take any frame-like argument. Makes writing code easier (and more explicit) for clients which do not have a frame, but want to load non-hidden. https://git.libreoffice.org/core/+/0247f43171fb87df8035762f618e342a38f29779 https://git.libreoffice.org/core/+/0247f43171fb87df8035762f618e342a38f29779%5E%21/ * 2. Jens Carl (2019): A duplicate command,* .uno:ToolsMacroEdit, was removed. This left the user-facing Edit Macros... menu item permanently tied to the special-purpose .uno:BasicIDEAppear command, which was likely never intended for direct user interaction? The review comments show some uncertainty at the time. *Remove .uno:ToolsMacroEdit command* A search with git grep ".uno:ToolsMacroEdit" showed that the entry isn't used anywhere (also .uno:BasicIDEAppear provides a similar functionality). *Link:* https://gerrit.libreoffice.org/c/core/+/73582 Change-Id: Ib97f4ebd6707d82f9077dd2f4e6c05e537f8154d ---------------------------------------------------------------------------- *The Question for the Community* Given this history, the direct launch seems to have been an accidental link, not an intentional design what I have been able to understand especially when we see that *Tools **> Macros > **Run Macro...* opens the *"Macro Selector" dialog* instead of direct IDE launch. *What is the best way to fix this?* *Option A: Fix the direct launch.* We could try to make the SID_BASICIDE_APPEAR handler "smarter" by adding more logic to it to guess a default context. This preserves the direct-launch behavior but adds complexity to the existing code. *Option B: Change the workflow to match the others.* Could we match this behavior with the "BASIC Macros" dialog UI? Or making it similar to *Tools **> Macros > **Run **Macro... ?* Or what should be the behavior of this *Tools > Macros > Edit Macros...* selection should be? ---------------------------------------------------------------------------- *Previous Updates:* Week 1: https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html Weeks 2-3: https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html Week 4: https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html Week 5: https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html Week 6: https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html Week 7: https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html Week 8: https://lists.freedesktop.org/archives/libreoffice/2025-July/093572.html Week 9-10: https://lists.freedesktop.org/archives/libreoffice/2025-August/093662.html Week 11: https://lists.freedesktop.org/archives/libreoffice/2025-August/093694.html Week 12-13: *h**ttps://lists.freedesktop.org/archives/libreoffice/2025-August/093738.html <http://lists.freedesktop.org/archives/libreoffice/2025-August/093738.html>* Thank you for your time and consideration. -- *Regards,* *Devansh*
