feat(native): add Gtk APIs for windows/widgets #982
Conversation
There was a problem hiding this comment.
I think this looks much better! There's one downside to this approach compared to using a single event queue though, that I neglected to mention earlier. The order of events between event systems aren't preserved here, so if some code assumes it is, it might fail unpredictably. This might not be a problem in practice, but it's hard to tell the future. I think it would be a good idea to document it at least.
…t/native/gtk-window
Using long was only a safe assumption on certain architectures. CI on Windows was breaking because of it.
|
I have updated your lock dirs and formatted the code. |
…t/native/gtk-window
…/revery into feat/native/gtk-window
| @@ -22,7 +28,7 @@ open { | |||
| bunch of GtkWidgets for one window, so this table maps Sdl windows | |||
| to GtkWidgets. | |||
| */ | |||
| let windowToWidgetTable = WindowTbl.create(1); | |||
| let windowWidgetCache = WindowWidgetCache.create(~initialSize=8, 64); | |||
There was a problem hiding this comment.
What if you have more than 64 windows? Or, more likely, you create more than 64 temporary windows after the main window while continuing to use its associated widget?
There was a problem hiding this comment.
That's a good point. I wonder if I can use the "depth" of the widget in the hierarchy as the weight in the cache. I'll look into that.
There was a problem hiding this comment.
I used the depth of the widget in the hierarchy to determine the weight of the item in the cache. This means root windows wont have to be recreated while temporary child windows will be.
There was a problem hiding this comment.
👍 Seems like a good strategy to me!
|
Change looks good to me (pending resolving Glenn's feedback). Can you please test and verify Onivim 2 builds/runs with the latest changes? |
|
@bryphe sure! Will do. |
This way child windows should be "lower" weighted than the root widget/window.
…t/native/gtk-window
|
I have updated your lock dirs and formatted the code. |
|
@bryphe sorry for the delay, I've been busy moving into my new apartment. I just tested with Oni and it works, I just had to resolve |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This should be a better version of #978. This uses Gtk's poll -> flush mechanism rather than using their event loop.
Unfortunately we can't make the Gtk window part of the window struct on Linux it seems, since the Window creation requires some initialization that isn't done by the point at which we create the window, leading to a segfault. In order to try to fix this I made a
Hashtblthat maps Sdl windows to Gtk widgets so we don't end up with a bunch of duplicate Gtk widgets in memory.