If you look at this wiki page: Development/DispatchCommands https://wiki.documentfoundation.org/Development/DispatchCommands it contains a list of UNO commands extracted from some version of the LibreOffice code. Each of these commands has its own unique ID, called "Resource ID" or "Slot ID" (SID). For example: SID: 5502 SID URL: "slot:5502" Dispatch command: ".uno:SaveAs" Symbolic constant: SID_SAVEASDOC In some parts of the code, you can see that instead of the using the dispatch command, the equivalent SID is used. This can cause problems, because: 1. One may use wrong SID mistakenly: https://git.libreoffice.org/core/+/1aa57f44c0d37ef23551943a64211dea17903873 2. The SID may change because of some problems or technical issues: https://git.libreoffice.org/core/+/8ea9a8bc43ea054521a44dc8e3bc537110ca9e33 Some of the instances can be found using: git grep -e slot:[0-9] So, a better approach would be using dispatch commands instead of the SID URLs. This task is defined to use "dispatch command" instead of "numerical ID" for the UNO commands. A sample conversion would be: "slot:5502" -> ".uno:SaveAs"
Hi, I would like to work on this issue. I ran the grep command that you mentioned in your report and found a couple of java files. For example this one: framework/qa/complex/contextMenuInterceptor/ContextMenuInterceptor.java which uses the following code: // initialize root menu entry "Help" xRootMenuEntry.setPropertyValue("Text", "Help"); xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); xRootMenuEntry.setPropertyValue("HelpURL", "5410"); xRootMenuEntry.setPropertyValue("SubContainer", xSubMenuContainer); xRootMenuEntry.setPropertyValue("Image", myBitmap); Question 1: Does this report affects the above code? If yes, Question2: What would be the equivalent call to xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case?
(In reply to Shivam Jha from comment #1) > Question2: What would be the equivalent call to > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case? Note that the wiki page mentioned in comment 0 has history, which starts on 2015; it has some (not all) historical values there, that changed over time, and now are different. So e.g. 5410 may be found there, if you look at the last of 2015's initial set commits to that page. And that is exactly why the numeric codes of slots should not change, and hence the answer to Question 1 is definitely yes.
(In reply to Mike Kaganski from comment #2) > And that is exactly why the numeric codes of slots should not change Oh sorry, got distracted - it was meant to say "And that is exactly why the numeric codes of slots should not be used - that may change"...
(In reply to Mike Kaganski from comment #2) > (In reply to Shivam Jha from comment #1) > > Question2: What would be the equivalent call to > > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); in this case? > > Note that the wiki page mentioned in comment 0 has history, which starts on > 2015; it has some (not all) historical values there, that changed over time, > and now are different. So e.g. 5410 may be found there, if you look at the > last of 2015's initial set commits to that page. > > And that is exactly why the numeric codes of slots should not change, and > hence the answer to Question 1 is definitely yes. So I looked through the history: https://wiki.documentfoundation.org/index.php?title=Development/DispatchCommands&oldid=114486 and found that equivalent uno command for slot:5410 is .uno:HelpMenu Does that mean I just have to replace xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the property name (The first parameter) will change if we want to use a uno command instead of the slot value?
(In reply to Shivam Jha from comment #4) > equivalent uno command for slot:5410 is .uno:HelpMenu > Does that mean I just have to replace > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with > xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the > property name (The first parameter) will change if we want to use a uno > command instead of the slot value? I don't know what Hossein thinks about it, but I would assume this to be your homework. Generally any change needs testing if it works as intended, so I'd assume that you run the code (maybe that would be the hardest part of the hack), and check if it worked correctly before (it should not); then test is simple replacement of value would fix it.
(In reply to Mike Kaganski from comment #5) > (In reply to Shivam Jha from comment #4) > > equivalent uno command for slot:5410 is .uno:HelpMenu > > Does that mean I just have to replace > > xRootMenuEntry.setPropertyValue("CommandURL", "slot:5410"); with > > xRootMenuEntry.setPropertyValue("CommandURL", ".uno:HelpMenu"); ? Or the > > property name (The first parameter) will change if we want to use a uno > > command instead of the slot value? > > I don't know what Hossein thinks about it, but I would assume this to be > your homework. Generally any change needs testing if it works as intended, > so I'd assume that you run the code (maybe that would be the hardest part of > the hack), and check if it worked correctly before (it should not); then > test is simple replacement of value would fix it. @Mike: I agree with you. The assignee have to understand and test the changes before submitting them. I think this procedure would be good: 1. Understand what does this line of code does (or it was meant to do). + Wiki can help 2. Make sure this line of code works correctly. + Test it live with LibreOffice 3. Change it to something like blank to see if the functionality fails. + Change, build and test 4. Put the new code in place and make sure the functionality works again. + Change, build and test @Shivam: If you have 2 line to change, change and test both of them. See what is appropriate for each of these lines.
@Shivam: Please work on 5401 (.uno:HelpIndex ) and 5404 (.uno:HelpTip ), as they are still available. 5400 (.uno:HelpOnHelp) and 5410 (.uno:HelpMenu) are removed here: https://wiki.documentfoundation.org/index.php?title=Development/DispatchCommands&diff=236500&oldid=177137 Maybe we can take care of 5400 and 5410 later. You can run UNO commands easily using a Python UI test: https://wiki.documentfoundation.org/Development/UITests This is an example test: #!/usr/bin/python from libreoffice.uno.propertyvalue import mkPropertyValues from uitest.framework import UITestCase from uitest.uihelper.common import get_state_as_dict import time class Test(UITestCase): def testUNO(self): time.sleep(2) print(self.xUITest.executeCommand(".uno:Quit"))
Thanks that is very helpful
FTR: one special case of using slots is special "factory URL" syntax, like private:factory/swriter?slot=21053 see SfxFrameLoader_Impl::load. One place where it's used is in createSystrayMenu (sfx2/source/appl/shutdowniconw32.cxx), using IMPRESS_WIZARD_URL (private:factory/simpress?slot=6686). I don't know what would be the optimal fix in this case, but possibly allowing to take "?.uno:Foo" instead of "?slot=nnn" would work, and impl_findSlotParam could convert the .uno to respective slot dynamically (e.g., using SfxGetpApp()->GetInterface()->GetSlot(sUnoURL)), to not change other code. Caolan: do you think it's reasonable to add such "UNO slot parameter" to recognized syntaxes in impl_findSlotParam?
This is multi-hacker, so please just work on it, and don't assign it to yourself.
(In reply to Mike Kaganski from comment #9) > Caolan: do you think it's reasonable to add such "UNO slot parameter" to > recognized syntaxes in impl_findSlotParam? I never really looked into it, but FWIW I see currently we have one private:factory/sdatabase?Interactive example and a private:factory/swriter/GlobalDocument variant along with, as far as I can see, only these other cases private:factory/simpress?slot=6686 private:factory/swriter?slot=21051 private:factory/swriter?slot=21052 private:factory/swriter?slot=21053 where the impress one is the old "start with wizard" case (I think) which we removed (or made non-default at one point). Though ironically we now have a new "pick template" dialog which is shown by default. And I think the writer ones are the "business card", "label", "xml form?") wizards or something like that. Maybe for those 4 cases we should follow the sdatabase case and just assign 4 "names" to these rather than replace it with an open-ended ?.uno:Command but I don't have any firm opinion there
Re-evaluating the EasyHack in 2022 This enhancement to the code is still relevant. Using dispatch command instead of numerical ID for the UNO commands can be done in many places found by the above grep command.
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/71311f88f7d83d8669576a98d300780d3d8bd02a tdf#146150: Use dispatch command in framectr.cxx It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
apurvapriyadarshi committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/31ca96ff3075343c8d0c334fc77a9d0969986d77 tdf#146150 Use dispatch cmd for the corresponding SID It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Shardul Vikram Singh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e0c2d334f195ba4d727c94f0ba9795b88bc47fe4 tdf#146150 Replace SID with dispatch cmd in ContextMenuInterceptor.java It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.