Iris Inputs not working in plugins about iris HOT 15 CLOSED

@SirMallard UserInputService does not work in widgets at all. I've also noticed quite a few problem as well, such as:
overlapping and errors within Iris where it tries to access .AbsoluteSize in a folder.

if rootParent.Parent:IsA("GuiBase2d") then
    size = rootParent.AbsoluteSize -- this part
else
    size = workspace.CurrentCamera.ViewportSize
end

Happens if UseScreenGuis have been turned off.

Small update: Got Iris working in a widget. Last thing to do is to figure out why some elements are behind of each other.

from iris.

James also ran into this issue and there is a old-ish fork which solves this issue: https://github.com/jammees/Iris-plugin

In this fork he supercedes UserInputService, which may be a better alternative to config inputs.

from iris.

Yeah, I can have a look at creating a way to add a custom UserInputService, since all the widgets use the one WidgetsUtility version. It shouldn't be too difficult to supercede that.

from iris.

Hi! I did not have much time working on the fork recently. However, if needed I can try and make a pull request some day so that Iris will work in a plugin environment as well.

from iris.

@jammees Could you explain exactly what doesn't work when within the plugin environment. Is it just the UserInputService that does not work or is it other things? I don't have much experience with plugins.

from iris.

I think I'm done making Iris work in a widget. I tried my best not to touch anything else that was not related to the problem. I would like to know one thing though. Is there any reason behind ResizeBorder being a TextButton?

from iris.

I think it's so that it can sink inputs.

from iris.

I see. I just found it a weird approach since there was already a button behind it, which is the WindowButton itself. I wanted to know because for some reason UI elements would not display correctly in a widget. I find it especially weird is that Iris uses Global ZIndexBehaviour, but the same thing in a widget just makes some elements appear behind each other. In this case I decided to use Sibling.

However, ResizeBorder as you have mentioned sinked all of the inputs, meaning the widget was not responding to moving or resizing. As a fix I decided to make ResizeBorder into a frame.

On a second note: I am not sure if it is an okay thing if I make Iris use frames intead of folders if UseScreenGuis was set to false. For some reason Iris kept trying accessing properties that folders do not have at all.

(The fork had been updated to the latest version if needed)

from iris.

Thanks for all this work. If I'm reading through your code correctly, you add a frame which acts as a 'proxy UserInputService' and fixes most of the issues. I'm also looking into how you've fixed issues regarding the folders.

@Michael-48 Would it be worth including a custom UserInputService implementation in the default release or adding it as an additional file, since most people won't use it. I like the idea of having a register command which can be called on Iris to change the features before starting it, hence being able to register a different UserInputService.

from iris.

I understand the virtue of compartmentalizing input, and I agree it should be. I can't think of a use case for overriding UserInputService beyond this issue with plugins. If that really is the only use case, it might be extraneous to provide a way for users to set a custom UserInputService. The approach I have in mind is similar to the existing solution for getting the current time. 

    widgets.IS_STUDIO = widgets.RunService:IsStudio() 

     function widgets.getTime() 

         -- time() always returns 0 in the context of plugins 

         if widgets.IS_STUDIO then 

             return os.clock() 

         else 

             return time() 

         end 

     end

Let me know your thoughts, and if you have anything more in mind for a register command. I like the idea of that, though I'm struggling to imagine how it may best be implemented.

from iris.

why not just always use os.clock for time?

from iris.

I've spent some time going through the code and trying to determine how to get a plugin working with the least amount of effort from a user. From what I've seen, you have done a good job of getting Iris to run just in a plugin.

My question is about the general principle of Iris running in widgets. I would like to be easily abe to write little scripts and run them in the plugin environment using Iris. When I imagined this, I thought it would mean that each window was a separate widget, but I can see it was enough effort trying to get Iris to work in a single widget, yet alone multiple.

However, it still stands the Iris having an individual widget for each window would be much more appealing. Therefore, I am considering whether to include within Iris a way of hooking each Window into a separate widget?

I don't know what your thoughts are on this, since it's quite a lot of work, but I think would be valued.

from iris.

Sorry for the late reply. The best way to approach this problem would be to be able to make multiple instances of Iris and each instance of Iris would handle its own widgets. It would make working with Iris overall easier in my opinion as it would not be required to keep using that hook to assign that widget to a DockWidget individually. Other than that this would be a great feature and could be useful.

from iris.

I've been going more through plugins and I've had the chance to develop some ideas. I believe Iris should stick to some core concepts:

1. It should only be runnable once. ie. it is a static library, hence the Init method. If we were to allow multiple versions of Iris it would be better to rename .Init() to .new(), which also changes a whole bunch of the internal systems.
2. It should not include 'add-on' features in the base library. This is about plugins. I could include specific config options and functions which only work with Plugins, but I dislike this because it would bloat Iris and it's meant to be minimal. That is not to say that we would not provide code for plugins, it would just be seperate, and would instead hook onto Iris, rather than be embedded within it.
3. Iris should follow the principles of Dear ImGui, that being bloat-free and with minimal dependencies. This also incorporates the reasons behind some features, such as simplifying certain widgets, so that they don't end up with multiple functions. I'd rather extend an existing widget, such as Text, rather than create a new one, such as TextWrapped.

These probably will change, but they apply to my current view on plugins. I am still going to try and get it to work, but I don't want radical change to the library, and it would not be directly incorporated into the library, rather there would be additional files provided explaining how you 'hook' into Iris to make it work. This should make any changes clearer and easier to explain.

You can see what I've done in the plugin branch.

from iris.

This is the work I've done on plugins. I'm going to leave it for now, since it works and is fairly easy to get running now. #41 I'll probably come back and update this, but I'm going to close it for now.

from iris.