namedWindow approach in combination with waitKey (Feature #3218)
| Status: | Open | Start date: | 2013-08-13 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Alexander Smorkalov |
% Done: | 0% |
| Category: | highgui-gui | ||
| Target version: | 3.0 | ||
| Difficulty: | Pull request: |
Description
For the moment, if you want your system to be able to wait for a keystroke, the waitKey() functionality can be used. However this requires you to have an active and open namedWindow. How hard would it be to remove this dependency? Many time I want to use the waitKey functionality, without opening a window, just by displaying results in the command line. I guess others will have experienced the same.
About the namedWindow, I think it is kind of weird that the namedWindow cannot be used like an object. Each function calling to this namedWindow, needs the exact name of the window again, which makes it kind of useless to predefine a namedWindow. Might it be possible to make an object from this, on which you can call a destroy for example?
Associated revisions
Merge pull request #3218 from berak:docfix_colormap_30
History
Updated by Sergei Nosov over 11 years ago
Hi, Steven!
Your suggestions are sound, but I don't think the issues really have high exposure.
1) you can always use smth like getchar to wait for a keystroke from user. It doesn't have the 'expiration time' parameter though, but to implement the expiration logic you must have smth like an event loop, which, for my money, doesn't worth it most of the time. Such kind of loop is started when you create named windows, so waitKey was made to work with it. You could start the loop without any windows, just to support waitKey, but again - I personally don't think it's a good design decision.
2) I believe this API is a legacy from the 'only C' days of OpenCV. It looks kind of awkward today and have potential drawbacks, but since highgui module is mostly meant for debugging, I believe it's good enough to have the work done.
That's just my opinion, I hope it makes some sense to you, too.
- Assignee set to Alexander Smorkalov
- Status changed from New to Open
Updated by Steven Puttemans over 11 years ago
I can find myself in your opinion and yes there are probably other ways around this.
Thanks for your input!
Just a remark about the legacy style. I think if we want people to be pushed towards the newer C++ interface, even if it is for debugging, their should be a uniform use of objects and their functionality. That is why I think this suggestion is still valid :)
Updated by Maksim Shabunin over 9 years ago
Issue has been transferred to GitHub: https://github.com/Itseez/opencv/issues/4613