Bitten by NativeWindowType in OgreBites

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
andrecaldas
Halfling
Posts: 54
Joined: Mon May 06, 2024 1:06 am
x 3

Bitten by NativeWindowType in OgreBites

Post by andrecaldas »

I am taking a look at NativeWindowPair in ApplicationContextBase:
https://github.com/OGRECave/ogre/blob/8 ... Base.h#L77

I am pretty sure that the "NativeWindowType" inside "NativeWindowPair" is not used for anything but:

  1. retrieving the "uint32" that we call "window id", like here.
  2. setting the window grab for the main window at exactly one single place.

Now, in the Qt implementation, the "NativeWindowType" is not "QWindow"!!! It is a hack: SDL_Window. You might have or not SDL... and this is still the "NativeWindowType" for any non android build. The Qt implementation casts "NativeWindowType" to "QWindow" all the time. I realize that this last problem is probably a consequence of the fact that you can have both: Qt and SDL in the same system. I think it is a little bit bad that the interface (that is, the ".h" files) are too dependent on the build type. But this is the subject of some future post.

In the specific case of NativeWindowPair, I think NativeWindowType could be substituted by "uint32_t windowID". Then, we could have a "NativeWindowType* mainWindow" to be used in "setWindowGrab".

Probably changing "NativeWindowPair" would be considered too much for Ogre 1.14. Is there a trunk for some version were it would be possibly considered?

I would love to have OgreBites a little easier to port to SDL3 (which I am doing right now), Gtk or any other windowing system. Also, I would love to have it less threatening to new comers, like me, that get very confused and scared when they see "#ifdef".

If you see problems with this proposal, please let me know. I do too... and I have some ideas for those, too. ;-)

paroj
OGRE Team Member
OGRE Team Member
Posts: 2134
Joined: Sun Mar 30, 2014 2:51 pm
x 1143

Re: Bitten by NativeWindowType in OgreBites

Post by paroj »

actually, the SDL_Window is not defined by SDL but is rather our own forward declaration that happens to match SDL. Rather think of NativeWindowType* as void*.

I agree that this is kind of confusing right now, but OgreBitesQt was introduced mid release cycle, so I did not want to break compilation by changing the type. Currently we are again mid release cycle, so the earliest we can change it is Ogre 15. I would change it to void* then.

andrecaldas
Halfling
Posts: 54
Joined: Mon May 06, 2024 1:06 am
x 3

Re: Bitten by NativeWindowType in OgreBites

Post by andrecaldas »

paroj wrote: Thu Aug 29, 2024 12:22 am

[...] the earliest we can change it is Ogre 15. I would change it to void* then.

May I suggest we have a ogre_15 branch for the sake of anyone who wants to contribute things that have to wait for Ogre 15? :mrgreen:

paroj
OGRE Team Member
OGRE Team Member
Posts: 2134
Joined: Sun Mar 30, 2014 2:51 pm
x 1143

Re: Bitten by NativeWindowType in OgreBites

Post by paroj »

having multiple active branches is a can of worms that I would like to avoid. Instead you can create a Draft pull-request that can sit around until the development of ogre 15 is open. See e.g. https://github.com/OGRECave/ogre/pull/3109

andrecaldas
Halfling
Posts: 54
Joined: Mon May 06, 2024 1:06 am
x 3

Re: Bitten by NativeWindowType in OgreBites

Post by andrecaldas »

paroj wrote: Thu Aug 29, 2024 11:39 am

having multiple active branches is a can of worms that I would like to avoid.

:lol: I understand!

paroj wrote: Thu Aug 29, 2024 11:39 am

Instead you can create a Draft pull-request that can sit around until the development of ogre 15 is open. See e.g. https://github.com/OGRECave/ogre/pull/3109

I think this is a good solution.
Do you calculate about 1 year from now?

paroj
OGRE Team Member
OGRE Team Member
Posts: 2134
Joined: Sun Mar 30, 2014 2:51 pm
x 1143

Re: Bitten by NativeWindowType in OgreBites

Post by paroj »

I used to do time based major releases with API breaks, but nowadays I would rather wait until enough API breaks accumulate that warrant the version bump.
Nobody wants to end up with a broken build just because SDL_Window changed to void - there must be some improvement that warrants fixing your code.
For Ogre 14 the driver was mostly the new threading model:
https://github.com/OGRECave/ogre/blob/m ... -workqueue

With Ogre 13, I started improving the API to allow keeping it stable longer - so its hard to tell when a tipping point will be reached:
https://www.ogre3d.org/2021/08/14/ogre-13-released

andrecaldas
Halfling
Posts: 54
Joined: Mon May 06, 2024 1:06 am
x 3

Re: Bitten by NativeWindowType in OgreBites

Post by andrecaldas »

paroj wrote: Thu Aug 29, 2024 1:41 pm

I used to do time based major releases with API breaks, but nowadays I would rather wait until enough API breaks accumulate that warrant the version bump.
Nobody wants to end up with a broken build just because SDL_Window changed to void - there must be some improvement that warrants fixing your code.
For Ogre 14 the driver was mostly the new threading model:
https://github.com/OGRECave/ogre/blob/m ... -workqueue

With Ogre 13, I started improving the API to allow keeping it stable longer - so its hard to tell when a tipping point will be reached:
https://www.ogre3d.org/2021/08/14/ogre-13-released

I am getting wiser every day. I love to read your posts!
Thank you for your patience!!! :-)

By the way... taking the risk of being really annoying...

  • What are the chances that OgreBites become an independent project?

Expected answer: I don't know Ogre's history... but I am expecting you to complain something like:

  • It was an independent project before! And after a long discussion and xxx, yyy and zzz problems, we have decided to make it part of Ogre.

It would be a nice thing, I think. Searching for SDL in the project I see that "samples" use it, "OgreBites" use it and the "tiny render system" uses it. So, it seems we could get rid of SDL in the Ogre project.

Also, searching for Qt, I see that only "OgreBites" uses it.

Pros: (I will wait for you to list the "cons" :mrgreen: )

  1. Ogre will have less dependencies.
  2. OgreBites will be a simple and focused project.
  3. OgreBites release cycle could be independent of Ogre's.
  4. Both, Ogre and OgreBites would have simpler cmake configuration options and logic.
  5. It would be much easier to "delegate": hey, you! i am too busy with Ogre! take care of OgreBites!
  6. OgreBites would get more attention from those who care for it! <3

Concerns:

  • Where would "samples" go, then?
paroj
OGRE Team Member
OGRE Team Member
Posts: 2134
Joined: Sun Mar 30, 2014 2:51 pm
x 1143

Re: Bitten by NativeWindowType in OgreBites

Post by paroj »

OgreBites used to be sort of independent ;) it was living as sample code:
https://github.com/OGRECave/ogre/tree/v ... on/include

however, most third-party applications relied on that code and simply copied it into their projects - which then got outdated and buggy.
Thats why OgreBites is now a proper component that can be shared.
Over time I then moved some platform specific stuff from OgreMain to OgreBites, like the ConfigDialog. This way you could port legacy code to OgreBites instead of the dialog just disappearing completely.
Additionally, ogre-python needs something to create a window and having OgreBites makes doing this from python much simpler.

Aside from that you can totally ignore OgreBites or just copy-paste it and maintain it as a separate project.