MyGUI plugin for OpenMW resources #261
Conversation
|
I need a suggestion where to put the plugin sources. It can't go in libs/, because libs are not allowed to depend on components. But it can't go in apps/ either. A shared library is not an app. We might need a new top level directory. |
|
we have libs which are static libs, so maybe we should have a new top level for shared libs, like /slibs or if this is a one-off/unique case, then another place /extern like where shiny is? |
|
Perhaps "plugins/". Could also move openengine and platform to a different sub-directory, leaving "libs/" for libraries built from the components (like apps is for apps). |
|
I thought about "plugins" as well, but that makes it seem optional or interchangeable in some way. |
|
+1 for plugins. Its a good description. |
| @@ -190,7 +192,7 @@ namespace MWGui | |||
|
|
|||
| mSleeping = canRest; | |||
|
|
|||
| dynamic_cast<Widgets::Box*>(mMainWidget)->notifyChildrenSizeChanged(); | |||
| dynamic_cast<Gui::Box*>(mMainWidget)->notifyChildrenSizeChanged(); | |||
There was a problem hiding this comment.
Why to use dynamic_cast if its result is always supposed successful? It is necessary either use static_cast or check its result for nullptr
There was a problem hiding this comment.
One possibility is if you want to easily catch a bad cast. If the dynamic_cast fails, it will give nullptr which will cause the call attempt to crash with a null this pointer, whereas a static_cast will give it a bad-but-maybe-usable this pointer.
We could probably make a template function that does a dynamic_cast, but throws a runtime exception if the result is null.
There was a problem hiding this comment.
We could probably make a template function that does a dynamic_cast, but throws a runtime exception if the result is null.
MyGUI already has such a function (Widget::castType). I will change all dynamic_casts on widgets to use it instead.
Yes, but where are the different binaries installed? Is that done automatically in some way and I don't need to add anything? |
|
@scrawl how is this plugin supposed to be used? I mean, what should user do after downloading OpenMW with this stuff? |
|
The plugin needs to be manually copied to MyGUI's plugin folder. It doesn't really matter where we install it, it just needs to be accessible. |
|
wait.. what? OpenMW is going to be shipping it's own shared lib now (for MyGUI that is specific to just OpenMW)? I'm wondering about the Debian/Ubuntu packaging process here, I'm sure it is doable I just want to make sure this what you are telling us. :) |
|
Yes, all distributions of OpenMW should contain this shared library. That is what I am proposing. |
|
I'm wondering if it would be a good idea to have the code for the various custom widgets and the font loader within the plugin itself, and not in components/ as they are now. This means OpenMW would need to either load the plugin, or link against it at build time. Pros:
Cons:
IMO linking against the plugin would be a good idea, but I'm open to other suggestions. |
|
Not much on the pro side IMO. Binary size hardly matters. And forcing packages to include the plugin seems unnecessary. |
Why not? It's surely better than going after each individual packager and yelling at them to include it. This plugin must be obtainable for each OpenMW user, or they will miss out on an important feature. |
|
We don't use any of this at this point, right? This would be for future UI mods, which is a post-1.0 feature for which we don't have a concept yet. As least I don't. Forcing stuff on people that we don't even know yet how/if it will be used seems wrong. |
|
UI mods are not a post 1.0 feature. They have been possible since... ever? Just pick one of the GUI layouts or skin files and change them. The MyGUI tools greatly facilitate this process. Of course there is more to think about, content file integration, refactoring/generalizing widget use in OpenMW code, which should be done post 1.0. |
|
You can modify the GUI by changing the MyGUI resources (basically hacking OpenMW). Not the same as modding the contents of the data directories (via OpenCS and external tools that are used to create art assets). Anyway, I don't really like the idea of making OpenMW depending on a plugin. That is a break from our current architecture. If there is code that can be meaningfully shared by both OpenMW and a plugin used by MyGUI tools it should go into components. The plugin is okay, but it should serve as an interface to the MyGUI tools only. |
|
I still disagree, but not strongly enough to insist on it. Go ahead and merge it as-is, then. Regarding the term "hacking" - any mod is basically a hack. Of course a mod may need to be updated whenever the parent content has been updated. In this case, GUI mods created in the way I described would not necessarily be compatible with all versions of OpenMW, but there's really no way around that. |
That's what I meant. Modded content should be compatible with all (not outdated) versions of OpenMW. That's why I called it hacking. Anyway, merging ... |
ghost
deleted the
Previous attempts to use MyGUI's tools (LayoutEditor, SkinEditor, FontEditor) were not successful because it can not use resources from BSA files. Even after manually extracting them, it still wasn't working, due to backslashes use in path references.
I added a MyGUI plugin that can be loaded by the MyGUI tools and will register Ogre resource groups/archives for BSA archives and the MW data directory, according to the user openmw.cfg, just like it is done in OpenMW. It also registers some custom widget classes used by OpenMW so that they show up as expected.
As always, was only tested on Linux. The install rules need testing on all platforms. I did not add any install rule for Mac, because I could not find any for the other targets either. @Corristo?