Размещение стороннего окна на форме QT

[Limetris]

Не замечали != нет.
Дерзайте, пробуйте, отписывайтесь. Мб найдете решение. а мб найдете грабли и расскажите своим последователям.

Одновременно, конечно не получится.
Но проблем будет куча. Это я гарантирую.

Я прекрасно осознаю чем это может грозить, поэтому сейчас ищу механизмы и тестирую их.
Естественно, что при неудаче это введено не будет.
Однако существует проблема, которую необходимо решить, не таким так иным способом.

[GreatSnake]

В догонку

фокус может принадлежать только одному элементу в системе, и переходя на одно окно, оно автоматически пропадает на другом.
И тут не будет разницы окно в окне или два окна по отдельности.

нужно различать "фокус окна" и "фокус ввода". Последний определяется GUI-тулкитом приложения, а не системой.
Чтобы приложение активировало этот фокус на конкретном элементе, главное окно должно сначала получить фокус окна от системы и уже input-manager тулкита активирует элемент с фокусом (посылает ему событие или ещё как-нибудь).
Так вот без дополнительных усилий встроенное окно фокус никогда не получит и input-manager встроенного приложения не отработает.
К тому же по нажатию [Tab] из одного окна в другое никогда не попадёшь)
Вот для понимания.

[Limetris]

нужно различать "фокус окна" и "фокус ввода". Последний определяется GUI-тулкитом приложения, а не системой.
Чтобы приложение активировало этот фокус на конкретном элементе, главное окно должно сначала получить фокус окна от системы и уже input-manager тулкита активирует элемент с фокусом (посылает ему событие или ещё как-нибудь).
Так вот без дополнительных усилий встроенное окно фокус никогда не получит и input-manager встроенного приложения не отработает.
К тому же по нажатию [Tab] из одного окна в другое никогда не попадёшь)
Вот для понимания.

Теперь я понял о чем ты 
Согласен, это одна из следующих возможных проблем, и если она возникнет, тогда буду думать решать ее или остановиться.
Сейчас меня интересует только размещение одного окна в другом средствами QT, даже ести там не будет фокуса, уже хорошо 

[Igors]

Хотя уже задумываюсь, что лучше сейчас это пересмотреть, чем потом рожать ёжиков ))
Как говориться, инициатива **** инициатора

Приятно видеть что человек с опытом.

Конкретно "по делу" имею сказать немного - да, Qt знает/помечает свои (т.е. созданные от QWidget) окна и считается с возможностью чужого, в этом случае возвращается "событие не обработано" и управление отдается др обработчикам что зарегистрированы для этого события. О том что окно/контрол из одного процесса может быть вообще прилеплено в другой - никогда не слышал в OSX, все списки окон и.т.п. - только в рамках процесса.

[Limetris]

Приятно видеть что человек с опытом.

Конкретно "по делу" имею сказать немного - да, Qt знает/помечает свои (т.е. созданные от QWidget) окна и считается с возможностью чужого, в этом случае возвращается "событие не обработано" и управление отдается др обработчикам что зарегистрированы для этого события. О том что окно/контрол из одного процесса может быть вообще прилеплено в другой - никогда не слышал в OSX, все списки окон и.т.п. - только в рамках процесса.

Спасибо, но опыта мне еще много набираться.

Понятно. Тут есть один момент, захватываемые окна также и обрабатываются теми процессами, которые их породили.
Просто должны находиться где-то не на Desktop-е, а в конкретном окне.
Если очень грубо сказать то в своем "эмуляторе" Desktop-а (аж самому страшно от такого сравнения  ).

Надо седня "обнулиться", а потом со свежей головой посмотреть на жопу под другим углом 

[Bepec]

Всё просто. Если вы хотите окна "забирать" у десктопа, тогда вам нужно реализовывать его функционал.
Если же вам нужно просто "манипулировать" окном, тогда уже вам достаточно управления им.

PS не стоит забывать, что все интерфейсы обманывают пользователя Имитацией трехмерности, красками и прочим

[Limetris]

Всё просто. Если вы хотите окна "забирать" у десктопа, тогда вам нужно реализовывать его функционал.
Если же вам нужно просто "манипулировать" окном, тогда уже вам достаточно управления им.

PS не стоит забывать, что все интерфейсы обманывают пользователя Имитацией трехмерности, красками и прочим

Дааа... я иногда тоже хочу быть просто пользователем, что-бы, минимум, не знать как оно все на самом деле устроено 

Средствами QT без применения WinAPI это возможно?

[Bepec]

НЕТ. ведь вы хотите чужое окно захапать. А чужое окно можно захапать только с разрешения менеджера рабочего стола. А менеджер рабочего стола имеет только платформозависимый апи.

[Limetris]

НЕТ. ведь вы хотите чужое окно захапать. А чужое окно можно захапать только с разрешения менеджера рабочего стола. А менеджер рабочего стола имеет только платформозависимый апи.

Понял. Буду думать...

Но в понедельник, седня все... обнуляться 
Удачных выходных, спасибо!

[OKTA]

Так и делайте на том же уровне WinAPI - но на кросс-платформенность это не претендует

Поэтому я и здесь, надеялся что в QT существует какой-либо свой механизм.

Такая необходимость "себе дороже". Ясно что даже в случае успеха такое окно станет источником многих забот. С др стороны Вы разжигаете/поощряете аппетит пользователя/заказчика - ведь Вы сказали "можно" (а часто хочется и прихвастнуть типа "элементарно" ). Ну так если можно - тогда давайте вводить там данные, получать результаты и.т.д. - иначе что толку с "показа окна"?, И соскочить уже будет не так просто, ведь Вы уже пообещали... Поэтому немедленно упереться рогом типа "низзя!" = лучшее решение

По поводу заказчика, согласен что его надо держать на нужном месте и в меру пресекать полет фантазии ))

Но к сожалению, такая необходимость возникла по моей инициативе, дабы не ломать половину GUI системы чтобы перенести на QT.
Хотя уже задумываюсь, что лучше сейчас это пересмотреть, чем потом рожать ёжиков ))
Как говориться, инициатива **** инициатора

Только не "QT", а "Qt".
И не "говориться", а "говорится" 

[Limetris]

Только не "QT", а "Qt".
И не "говориться", а "говорится" 

Вот спасибо, без этого я бы не выжил 

[OKTA]

Правило хорошего тона