> I think that's a valid point :-) They are all inside qtbase because of > convenience. The build system wasn't and still isn't very friendly > when it comes to creating separate modules.
I honestly dont understand this point. And why does it have to be a submodule. Cant it just be a git repo with a qmake file, that builds the target to the same place where it would have been built in source? > I sort of agree with you and Jorgen. For eglfs, I have to point out > that the code there doesn't work on most boards out there since mostly > all boards need specific graphics initialization. So, yes, it's an > example and one that didn't work for me in most places :-) I also > added a eglfs/x11 backend sometime back to test in my laptop with > mesa. > > I don't mind creating a separate submodule to carry out the proper qpa > plugin work. Would you be OK with: > a. Giving us the eglfs plugin name :-) This is mostly for our > convenience. We spent quite sometime educating people to use eglfs > right from the Qt4 days. > b. I will create a eglexample plugin that is basically eglfs without > the complexity of hooks, cursors etc. It will load input plugins as it > does today > c. After 5.0, I will move eglfs into a separate repo like wayland.. > > Sounds ok to you guys ? Ok, as I understand it, there will never be a Qt on pi plugin, nor a Qt on snowball etc etc plugin. You guys just want one plugin. And you want eglfs. Yeah, maybe we should just add minimal_egl or smoething, and keep evolving eglfs in the direction you guys see fit? Jørgen _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
