Qt - xinit keyboard

 ( makgab | 2015. március 24., kedd - 16:22 )

Üdv!

Az "xinit /path/to/app -- :0" indított Qt alkalmazásban a billentyűzet eseményei nem kezelődnek le. Pl.:


void MainWindow::keyPressEvent(QKeyEvent *event)
{
// Exit from app
if (event->text() == "q" or event->text() == "Q" ) {
on_exit_clicked();
} // if
}

Mire nem figyeltem?
Az xinit-nek kellene valami paraméter? Próbálgatom az .xinitrc állományt is...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Mi van a .xinitrc -ben?
--
Blog | @hron84
Üzemeltető macik

Nincs .xinitrc fájl egyelőre.
De annyi kiderült, hogy ha az egeret a mainwindow form fölé viszem, akkor focus-ba kerül a mainwindow és működik a keyevent.
Tehát a mainwindow::mainwindow konstruktor végére tettem egy setFocus()-t hogy mindenképp fokuszba legyen:

...
setFocus();
} // end of mainwindow::mainwindow

De ezzel sajnos nem oldódott meg a helyzet. Az egeret még mindig a form fölé kell vinni, hogy a keyevenet-et el tudja kapni (xinit-el indítva).
:(

Off: ha csak a Qt-s alkalmazás lesz, miért nem a Qt Embedded verziót használod?

azt nem nézegettem még...

Ezért szoktam javasolni állandóan, hogy "előbb olvas, aztán kérdez" :-)

Az Qt Embedded ezt a problémát valószínű ugyanúgy nem oldja meg.

A Qt Embedded alatt jó esetben X sincs, tehát helyből fura, amit írsz.
Másrészt használtam, és nem volt gondom vele.

Úgy tűnik, ha xinit-el van indítva az alkalmazás:
xinit /path/to/app -- :0
akkor csak abban az esetben kezelődik le a keyevent (kerül focus-ba a form), ha az egér a form felett van. :(

Hiába teszek a mainwindow konstruktorába bármit:

mainwindow::mainwindow(...) {
...
activateWindow();
setFocus();
}

Ugye használsz valamilyen ablakkezelőt (gnome, kde, whatever)? Legjobb, ha nem árulod el, melyiket, hiszen könnyen lehet, hogy az a "hiba" okozója.

Nem. Pont ez a lényeg, hogy a Qt-s alkalmazást ablakkezelő nélkül használom (csak xinit-el indítva).
Ablakkezelő nélkül, ha az egeret ráhúzom az ablakra, akkor elkapja a key eventeket. Persze lehet, hogy csak én nem tudtam ezt... :)

Jó szórakozás lesz majd, ha dialog box fog nyílni, vagy több ablakod lesz. Továbbra is zsákutcának tartom a koncepciót.

egy ablak lesz csak. semmi más.

A Qt azt hiszem magatol is dobal fel neha hibaablakot. Tenyleg jobban jarnal egy blackbox vagy twm ablakkezelovel a hatad mogott. Nem esznek semmit, cserebe megoldanak minden problemat.
--
Blog | @hron84
Üzemeltető macik

Azért lenne jó wm nélkül, mert nem kell a wm kerete (címsor, bezár ikonok...stb. nem kell), tehát csak a csupasz ablak kellene.
Tehát ezért van xinit-el indítva az app.
De ha megoldható másképp, akkor jó.

Kérlek, kérlek, olvass már dokumentációt. Qt window styleokat kiváltképp. Ha csak ezért nem kellene WM, akkor megoldható.

(Szerk: igen, én abban hiszek, hogy konkrét válasz helyett többet ér, ha megtanul az ember önmaga választ találni. Jobb szeretem, ha az ember rávezetődik a dologra)

Nem kell egyáltalán wm. egy korábbi topicban került elő a wm nélküli "xinit"-es indítás.
Ez tökéletese is lenne.

Es kedz illetve NevemTeve kollegak felveteseire van valami valasz? Pillanatnyilag a jelenlegi tudasunk altal en is amondo vagyok, hogy itt valami helper programok biztos hogy fognak kelleni, mert a wm nem csak abbol all, hogy kereteket rajzolgat az alkalmazasok kore, hosszu es reszletes listak keringenek a neten, hogy miert is kell egy WM az X rendszerebe.
--
Blog | @hron84
Üzemeltető macik

Bocsánat, de kimaradt, hogy ez egy RPi-re kellene minden féle sallang nélkül majd egy adott célfeladatra.

Akkor meg Qt embedded. Az való erre. Topicjaidból sejtettem, hogy arra kell, nem véletlen mondom jó ideje.

Sőt, többet mondok: buildroottal össze is rakhatod magadnak az egész minimális rendszert pillanatok alatt.

Köszönöm, megnézem.
Ha jól olvasom, akkor a virtual frambuffert használja és a libxtst library kell csak a fordításhoz.
Illetve paraméterekkel lesz indítható az app:

Option Description
-width The width of the virtual framebuffer (default: 240).
-height The height of the virtual framebuffer (default: 320).
-depth The depth of the virtual framebuffer (1, 8 or 32; default: 8).
-nocursor Do not display the X11 cursor in the framebuffer window.
-qwsdisplay <:id> The Qt for Embedded Linux display ID (default: 0).
-skin .skin The preferred skin. Note that the skin must be located in Qt's /tools/qvfb/ directory.
-zoom Scales the application view with the given factor.

Egy fluxbox konkretan 0 eroforrast eszik, es eszmeletlen vekony ablakkeretet gyart. De ha legalabb megnezted volna az alternativakat, akkor lehet hogy ezt a csomo szivast itt mind megsporolhattad volna magadnak. Nem csak LXDE meg GNOME meg KDE van a vilagon.
--
Blog | @hron84
Üzemeltető macik

Imho csak a gond lesz vele, ha nem most, akkor később.
Annyira fáj egy minimal WM-et berakni (nem desktop managert). Nem hiszem, mert ha igen, akkor a Qt Embeddeded megnézted volna.

Más programmal is ugyanez a jelenség? (pl. xinit xterm)? Ha igen, akkor így működik az X, ha nem, akkor még van esélyed.

OFF: szerintem is hülye ötlet WM nélkül, de:

Próbáld meg az ablakodat fókuszba helyezni (a Qt-s setFocus() ugye csak az ablakon belül állítja, de az ablakodnak is meg kellene kapnia a fókuszt előszőr...).

Itt van pl az xdotool windowfocus .. parancs ( doksi: http://www.semicomplete.com/projects/xdotool/xdotool.xhtml )

UPDATE: hehe, esetleg ez is érdekes lehet, ha nagyon akarsz lehet WM nélkül élni bár elég hekkelős: https://github.com/patrickhaller/no-wm