Thread: Hacking a Theme
-
October 2nd, 2020, 02:13 #141
Try this, it doesn't have the bar behind the icons but I think it's a step in the direction you're trying to go.
bmos' extensions
he/them
-
October 2nd, 2020, 19:48 #142
I actually took some of the things you did and tried a couple more things. I got to where it looks as before - which is good (except for Initialization,) but I have this lingering error. Which is VERY non-descript:
Code:[10/2/2020 9:57:34 AM] [<color="red">ERROR</color>] Attempt to instantiate missing window class ()
-
October 2nd, 2020, 19:52 #143
Search the files for "color="red""
Regarding re-initializing it to not require "all" to be clicked, I think the code that needs to be executed is:
Code:for _,w in ipairs(window.recordlist.getWindows()) do w.synchState(); end
That code normally exists in CoreRPG template_utility.xmlLast edited by bmos; October 5th, 2020 at 15:38.
bmos' extensions
he/them
-
October 2nd, 2020, 20:15 #144
-
October 2nd, 2020, 20:18 #145bmos' extensions
he/them
-
October 3rd, 2020, 02:46 #146
Well, after wrestling and wrestling with manager_desktop.lua, desktop_panels.xml and desktop_classes.xml, I chose to go your route. I tweaked the chatbox.png frame to pretty it up, but I STILL cannot fix that initialization problem. Frustrating.
I even tried setting things in the manager_desktop.lua to first initialize to what we wanted, but it STILL left the Library Icon Huge and everything stacked on top of itself. Click the Library and reset the Icons, et voila.
Here is it in its current state - I believe very useable - not perfect - but useable.
-
October 5th, 2020, 01:31 #147
So ... on this initialization issue. If I create/define the window "Shortcuts" as it always has been (not inside the Chat Window,) with the definitions for a small stacked Icon bar that we want, and I add in the code in the <script> portion for registering the window, then it shows up, properly initialized on the right-hand side of the game window. It is fully functional, and updated when you reconfigure it with the Library. (chatshortcuts is defined but not intialized/regsitered.)
If I remove the <script> portion for registering the window, and add the same <script> to "chatshortcuts," a sub-window to "Chat" in a space to the left of said window, it WILL NOT initialize properly. The icons look stacked on top of one another, and fortunately, the Library Icon control miraculously ends up on top. If you open the library and reconfigure the bar, then it re-initializes properly, and is functional from that point on.
The change between the two is VERY easy in desktop_classes.xml.
Shortcut bar to the right (not in the chat: )
Code:<windowclass name="chatshortcuts"> <script /> <sheetdata> <subwindow name="shortcutbar"> <anchored position="insideright" width="30" /> <class>shortcutbar</class> <activate /> <fastinit /> </subwindow> </sheetdata> </windowclass> <windowclass name="shortcuts"> <script> function onInit() DesktopManager.registerContainerWindow(self); end </script> <sheetdata> <subwindow name="shortcutbar"> <anchored position="insideright" width="30" /> <class>shortcutbar</class> <activate /> <fastinit /> </subwindow> </sheetdata> </windowclass>
Shortcut bar is now contained in the Chat window to the left:
Code:<windowclass name="chatshortcuts"> <script> function onInit() DesktopManager.registerContainerWindow(self); end </script> <sheetdata> <subwindow name="shortcutbar"> <anchored position="insideright" width="30" /> <class>shortcutbar</class> <activate /> <fastinit /> </subwindow> </sheetdata> </windowclass> <windowclass name="shortcuts"> <script /> <sheetdata> <subwindow name="shortcutbar"> <anchored position="insideright" width="30" /> <class>shortcutbar</class> <activate /> <fastinit /> </subwindow> </sheetdata> </windowclass>
It sure seems like one option could be to allow the shortcut bar to live on the right side, and using a control button, move it to the chat window, back and forth. However, I don't think I have enough control of the "shortcutbar" window to do this. It seems it is controlled by the application and not these config files (.xml and .lua)
-
October 5th, 2020, 12:04 #148
While it is possible, I don't buy it.
I think CoreRPG is bringing a lot of baggage we don't understand
I often end up thinking things like that when I am developing and I have always found myself to be wrong and just missing some crucial piece of the puzzle.
I would guess that the issue is that the "self" passed by chatshortcuts is different than the "self" that is passed by shortcuts in a way that matters.bmos' extensions
he/them
-
October 5th, 2020, 15:07 #149
I hope your right! Hopefully, someone can suggest something. I've been over the CoreRPG code very thoroughly. I even tested this extenstion (with some labeling mods) with CoreRPG alone to eliminate any other potential (SFRPG) issues. Same exact behavior.
I would guess that the issue is that the "self" passed by chatshortcuts is different than the "self" that is passed by shortcuts in a way that matters.
The OTHER interesting tid-bit is, if you rename the window "shortcutbar" to ANYTHING else (like testshortcutbar," you lose functionality in BOTH cases. There is no other object or reference to an object called "shortcutsbar" in CoreRPG, except for desktop_classes.xml. There is a reference to a symbol name "shortcuts" in manger_desktop.lua with m_wShortcuts.shortcutbar.subwindow.createControl, but nothing else.
A window named "shortcutbar" is necessary to hook into the functionality within the application.
I think that this is perhaps a case of timing. Having the "shortcutbar" independent, results in it initializing properly (for a yet unknown reason,) and attaching said "shortcutbar" to the "chat" window, causes the icons to be displayed in an old large scale, and stack them on top of each other, as if there were no spacing specified. Ya, weird.Last edited by Tuleen Donai; October 5th, 2020 at 16:02.
-
October 5th, 2020, 23:16 #150
OK. I finally found it. You were correct, and it had nothing to do with the application or the Ruleset, but in the way the windows were defined in desktop_classes.xml. It had to do with the <fastinit/ > entry for the subwindows. There are two, on instantiating the "chatshortcuts" window inside the "chat" windowclass, and the second with the instantiation of the subwindow "shortcutbar" into the "chatshortcuts" windowclass. It turns out, you need to remove it from the 1st instantiation, and leave it there for the 2nd, then the initialization problem goes away.
Here is the fixed extension, with all of the extraneous changes removed.
Changes necessary- 1. Addition/Replacement of data_desktop_SFRPG.lua to remove the calls to add the button_Shipct to the shortcut stack.
- 2. Addition/Replacement of data_desktop.lua from CoreRPG in order add the button_Shipct to all the initializers with respect to modes for the shortcut stack.
- 3. Fixing of desktop_classes to "remove" original shortcutsbar definition (BMOS's suggested line --> '<windowclass name="shortcuts" join="remove" />') and removing <fastinit /> from "shortcuts" subwindow in "chat" window class.
- 4. Addition of button_shipct.png files to graphics/icons folder.
Change made, but not necessary: I changed the name of the shortcuts window in the "chat" window class to chatshortcuts. (Oh! And, I added button_assets.pngs too! I do not prefer the original SFRPG buttons.)
WHEW!Last edited by Tuleen Donai; October 5th, 2020 at 23:22.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks