Panel datasources

[Ken L]

Is there a particular reason that Panels can't take data-sources? I'm currently implementing a panel docked interface and I got the combat tracker embedded into the desktop to scale with dimensions, but I can't get Maps to behave.

The reason is that an ImageControl during its initialization, creates a databasenode as a child of the window's databasenode to store its attributes, but windowclasses within panels can't be initialized with a datasource.

The combat tracker works since the CT window doesn't need its databasenode as the windowlist control has a <datasource> tag so it can pull from any DB node, not necessarily a nested node (which combattracker.list just happens to be).

I posted in the Laboratory forums about this, but it's become a blocking element for me to create a true 'map as a background' interface, which honestly was my biggest want after changing platforms. D20pro and Roll20 have it, so does maptools, why not FG?

This single feature unlock of allowing a <datasource> tag, even if only static for initialization (as opposed to windowlist which allows it to be swapped) would allow desktop panel widgets to be backed by real DB elements rather than just handlers. At the very least however, the ability for an image control to specify its node for creation?

[Moon Wizard]

I just answered you on Discord as well. I've been heads down coding. To be truthful, it's better to post in the forum; since it's easy for me to bookmark threads to come back to, once I get a breather from coding.

As far as I know, the original developers didn't design panels to be used with data sources; so this is essentially an ask for a new feature to be added. I can see the benefits; but it also needs to be prioritized with everything else. Developer features do get a separate prioritization from user features.

Currently, I've been working hard to reduce my time on the forums and doing improvements/maintenance in order to spend more time on FGU. Up until the last couple months, I had prioritized improvements/maintenance over FGU, but switched gears then.

Regards,
JPG

[Ken L]

I would rather have FGU than this, but given the current expat of R20 users, having the map as a background as an option is a huge UI win that would carry over into FGU.

[Moon Wizard]

Yeah, that's pretty much my battle every month. There's always some business need or new partnership or competitor meltdown to compete with FGU prioritization.

Cheers,
JPG

[Ken L]

Well if it helps sweeten the pot, I'll release the map-as-a-background code MIT for integration into coreRPG if we get panel datasources. Thought I suspect, as you already know, once panel datasources are in, there' little additional extra code needed to make it happen aside from moving the image toolbar to somewhere more convenient.

[Moon Wizard]

The code would have to be released to us with your permission before applying any license to it; or I won't touch it. I have no interest in maintaining and keeping track of multiple licenses within our code.

What you are asking for is definitely on my list to consider for near future versions, because I think it could be useful for many things including potentially what you want.

However, I think that map as background is going to need more than just panel data sources or even something different. Currently, there's no mechanism to change a window's or control's data source dynamically (with exceptions for subwindow and windowlist specifically); and panel data sources wouldn't change that. A data source for panels would just create all the controls with the correct sources at initialization. Dynamic reassignment of all windows/controls is a much bigger ask; and not something I have plans for.

Since I'm assuming you want the map as background panel to be dynamic, that means you need to use a subwindow/windowlist for creating/removing the map being used as a background. This is similar to how the top level links list works in the library currently. In fact, you might be able to do what you want today using that approach.

Regards,
JPG

[Ken L]

The windowlist would work on <images> but would make an window list of images. You'd have to disable every other element save one, but it kinda-of-could work, but in a very bad way.

I also only contribute to MIT / Apache when it comes to propitiatory contributions.

[Moon Wizard]

Sounds like a better solution might be to add an API to subwindow that can set the window class/source...

JPG

[Ken L]

Using windowlist with the datasource as <image> works, but it'll load every single image, so if you have the monster manual loaded, FG will freeze for a good 10m or so on load or however long it takes (I didn't bother waiting for it). The optimal solution would be subwindow as you stated. I haven't tried anything fancy such as changing the init script to toggle every other image invisible yet, and I'm not sure if that would prevent FG from loading it in anyway on the wings.

edit: It also seems to have issues with bounds given it's a list, not a singular element.

[Ken L]

I've attached a quick extension for you to pursue Moon, it mocks up the concept, the pink boxes marking the frame of the windowlist vs the map "element". windowlist can 'look' like a map-as-a-background, but barely supports it. I have other extensions that move around the side-bar and chat window so chances are this will render the map over them both if loaded on coreRPG were as from my vantage they're rendered 'over' it.

Just use an empty campaign with a single image in the campaign's image folder for the map prior to launching. Naturally It'll be the only one to show up when the client loads. Put more than one and you start to get a list-like behavior with element spacing near the bottom.