Re: [Development] configure failure on Mac
On 3 October 2013 11:09, Sorvig Morten morten.sor...@digia.com wrote: On Oct 3, 2013, at 3:10 AM, Glen Mabey gma...@swri.org wrote: I'm on the dev branch but experienced this issue before the 5.2 and 5.3 branches split. macbookpro:qtbase$ ./configure -prefix ~/src/take2/install snip Running configuration tests... The test for linking against libxcb and support libraries failed! You might need to install dependency packages, or pass -qt-xcb. See src/plugins/platforms/xcb/README. Which seems to me like it's performing X11 checks on the wrong platform. I can file a bug if I'm really not missing something obvious … Do you happen to have xcb and/or pkgconfig installed via Macports? I can reproduce the build error in that case. A quick workaround is to configure with -no-pkg-config. This should arguably be the default when building for OS X: But if you happen to have pkg-config in your path, why should we then not use it. The user has one way or the other added it to the path, so why shouldn't it be used. I think the interesting question is why configure fails when you have a version of xcb that is missing some headers. Maybe a warning would be enough? Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Stepping down as the maintainer of QtWayland
Hi, I'm stepping down as the maintainer of QtWayland, as I don't have time to ensure that QtWayland is in top notch shape. I would like to propose Andy Nichols as the new maintainer. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qpa api - current status
On Tue, May 29, 2012 at 10:52:30AM +0200, Knoll Lars (Nokia-MP/Oslo) wrote: On 5/29/12 8:22 AM, ext Jørgen Lind jorgen.l...@nokia.com wrote: Hi 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Status: In progress, I am atm, marking handle() as obsolete and as an alias to platformXXX(). But since when did the word handle() mean anything else in API design? Im all for clear and verbose function names, but think this is just making the api ugly. To me if you ask for a handle of a class you will get the underlying structure. It then should be crystal clear to the developer that this class can not be used as a public class. The problem is that handle() is very unspecific, and that code ported from Qt 4.x to Qt 5 will silently break when people call handle(), as you get something else back then you thought you would. Renaming the methods at least turns the silent breakage into an explicit one. QWidget is not a QWindow subclass. For QFont's handle(), this function should be considered removed for Qt 5, since its hardcoded to return 0. QCursor has also a handle function which doesn't look right to me at first glance. My point was actually just to justfy why we used the handle() functions in the first place. Believe it or not, we used to have platformWindow for QWidget back when there was no QWindow. But it never looked so good in use. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing input for eglfs and friends
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing input for eglfs and friends
Hi The initial issue with our current input handling for platforms like eglfs, which do not handle input on its own, is, that we have input plugins for mouse/keyboard/touch (evdev), which are seperate from each other. So one needs to specify -plugin evdevkeyboard on the commandline in order to get keyboard input. The evdev* plugins are trying to use udev to detect all available devices and also handle the remove and add events for such input devices. To get rid of the -plugin argument we would like to create the keyboard/mouse/touch plugins always from eglfs directly. This works fine when udev is present, but fails badly without udev, as all plugins currently default to event0, if you dont specify the device explicitly again on the commandline. A fix would be to add a fallback device discovery, which picks up all available devices without udev and creates the specific keyboard/mouse handler. But this raised the problem of the lack of detecting if its a keyboard or mouse or whatever from the evdev side, as evdev does not have such a destinction. It just handles input events and does not care if its a key or mouse event. Thus udev has some tricks to probe different attributes through evdev to get the device type, which I dont really want to pull into our code. For those reasons, I will go ahead and merge evdevkeyboard and evdevmouse as a start. The merge potentially also adds the ability to properly send key and mouse events from devices, that have both event types (like a scroll wheel on the keyboard) I cannot merge evdevtouch for now, since I dont have a proper touchdevice to test with. I think evdev is excelent, but eglfs isn't linux specific. When we made eglfs it was intended as a platform which also could be copied and altered to fix special embedded deviceses needs. Moving all this logic into the plugins just so that we wont need to add -plugin at the command line seems the wrong direction to take. I think we should focus on keeping eglfs as small as possible, but keeping the readability of the code, so that the entry level for extending eglfs will be low. Also what about the embedded devices that uses some other input api than evdev. Do we include code for them in eglfs? To solve the no -plugin problem, can't we do something like we do for the platform plugins, ie. have a define which can contain a list of plugins which should be loaded as default. Theres some interesting semantics to this, but that can be left to the guy that implements this to solve:) Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
We can talk about making it into a nicer API in a future version of Qt, but for Qt 5, we should keep it as it is. Understood. I'm not against out-of-qtbase plugins. I am against forcing them to use private and changing API like QtPlatformSupport. Ah, now I see. This is where the missmatch is. QPA is by definition private apis that might change. It will stay like that for Qt 5. Maybe for Qt 6 we'r so confident that we might lock it down. Normally I define it like so: There is absolutely no abi, what so ever. You cant expect to take a plugin built with one sha, to be built with another sha... So 5.0 plugins will not work with 5.0.1 plugins. There is also no API guarantee. That means we won't break api just because we like to, but it also means it CAN change. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. That requires moving the Wayland platform plugin back into qtbase. Pretty please with sugar on top, do NOT do this. I understand that you only see the Wayland side of things, But there are loads of people interested in not having their plugin in the Qt source code. Using the pri approach is STUPID! The hacks you will force upon people is just not nice! We have been there, and we don't want to go back. Lets just keep/add again the -l flags, and let configure figure out if their going to be included or not. Building platform plugins outside the Qt source tree IS a usecase we'r going to support. Not only because of QtWayland but because there might be someone developing ie. an ios plugin that they don't want to have inside QtBase. People might have special HW that where they just write a plugin to do special ioctl to controll the display. We don't want all plugins to be in QtBase but more importantly we can expect all plugins to be in QtBase. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
