Hacking a Theme

[bmos]

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.

[Tuleen Donai]

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:

[10/2/2020 9:57:34 AM] [<color="red">ERROR</color>]  Attempt to instantiate missing window class ()

I'm not sure how to follow up with this, as FGU is not really telling what it's trying to instantiate!!!

[bmos]

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:

[10/2/2020 9:57:34 AM] [<color="red">ERROR</color>]  Attempt to instantiate missing window class ()

I'm not sure how to follow up with this, as FGU is not really telling what it's trying to instantiate!!!

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:

	for _,w in ipairs(window.recordlist.getWindows()) do
		w.synchState();
	end

The issue I was having is that this code needs to be executed within the context of the windowclass "library" and I couldn't figure out how to do that (I was playing with it for around an hour last night).

That code normally exists in CoreRPG template_utility.xml

[Tuleen Donai]

Search the files for "color="red""

That just the error message in the log. When it's displayed in FGU, the word ERROR is red.

[bmos]

That just the error message in the log. When it's displayed in FGU, the word ERROR is red.

Oh! Thanks for clarifying
Post your current ext?

[Tuleen Donai]

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.

[Tuleen Donai]

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: )

	<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:

	<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)

[bmos]

It seems it is controlled by the application and not these config files (.xml and .lua)

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.

[Tuleen Donai]

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 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.

However, it doesn't matter if I name that window "chatshortcuts" or leave it as it was originally "shortcuts" - same exact behavior.


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.

[Tuleen Donai]

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!