Vlákno názorů ke zprávičce Qt 5.13 bude patrně mít volitelnou telemetrii od kofola - Fakt všichni musejí cucat data? Nešlo by to...
-
co nechapes na tom ze vyxhozi stav bude vypnuto?
uz vidim ty "svatoucky" co budou brblat ze to pak urcite vyvojari zmenej na vychozi zapnuto...
taky by me zaji,alo kolik z tech co moznost to zapnout nechteji, nekdy nahlasili qt bug... protoze asi je nepochoputelne ze bug se lepe opravi kdyz o nem vyvojar vi... ;-) -
Opravi jo?
My delali appku v QT a na fullscreenu se nezobrazovalo menu po pravem kliku (kde byla polozka Exit fullscreen), takze se to pouzivalo dost pitome (user si musel pamatovat klavesu na opusteni fullscreen rezimu).
A kdyz se kouknem do bugu.. je to tohle https://bugreports.qt.io/browse/QTBUG-49258 (nahlaseno 2015) coz bylo uznano jako duplikat https://bugreports.qt.io/browse/QTBUG-7556 - bugu ktery je unresolved od 2010 !
K takovemu pristupu, kdy se 9 let na neco hodne podstatneho a souvisejiciho se zakladni funkcionalitou dlabe ta telemetrie nepomuze.
-
Neviditelný (neregistrovaný)
Vzhledem k tomu, že tohle chování je dáno tím, jak funguje DWM ve Windows s tím mohou Qtčka těžko něco účinně dělat. K dispozici je akorát "oficiální" workaround (https://doc.qt.io/qt-5/windows-issues.html#fullscreen-opengl-based-windows).
-
Problem je, ze se to nechova konzistentne (intel vs nvidia, single vs dual monitor). Kdyz uz si dali v QT tu namahu renderovat vsechny widgety skrze openGL, tak to menu si tam mohli zkompozitovat klidne ve sve rezii taky. Takto se jen vymlouvaj vsichni na neco jineho. Ale zajimave ze v obsolete QGLWidget-u se ten bug neprojevuje - pokrok nezastavis :)) A pak se nekdo divi, ze nadavam na to, jak jde cele odvetvi do kopru..
-
Neviditelný (neregistrovaný)
Problem je, ze se to nechova konzistentne (intel vs nvidia, single vs dual monitor)
Qtčka jsou moc vysokoúrovňový toolkit na to, aby mohly efektivně řešit bugy na úrovni OS a grafických ovladačů. Podobně proaktivní se občas snaží být vývojáři KWinu a ve finále to způsobí stejně tolik bugů, kolik jich to vyřeší.openGL, tak to menu si tam mohli zkompozitovat klidne ve sve rezii taky
K tomuhle se myslím používají QGraphicsView, QGraphicsScene apod. Pokud si chce programátor zobrazit klasický QWidget, který se chová jako normální samostatné okno, přece mu v tom Qtčka nebudou aktivně bránit. To, že to v nějakých situacích nefunguje správně je IMHO spíš omezení skutečně "multiplatformního" vývoje. Vohejbáky speciálně pro Windows a MSVC mám v Qtčkovém kódu taky...Ale zajimave ze v obsolete QGLWidget-u se ten bug neprojevuje
QGLWidget ve fullscreenu se chová stejně rozbitě jako QOpenGLWidget, aspoň v diskusi k jednomu z těch bugreportů se to píše. Windows nemám jinde než ve virtuálech bez 3D akcelerace, takže to nemůžu vyzkoušet... -
Ivan (neregistrovaný)
Mam uplne stejnou zkusenost. Na jednu stranu je chapu, ze veri ze vetsi mnozstvi vlastnosti jim pritahle vetsi mnozstvi zakazniku a tim stabilizuji svoji firmu. Na druhou stranu tezko muze nekdo postavit komercni aplikaci na frameworku, ktery ma leta neresene bugy ktere se nedaji obejit. Ta situace se opakuje pri kazdem vydani nove verze Qt se zacnou chlubit nejakou cool featurou, a uzivatele jim zacnou pripominat leta neresene bugy.
Tezko rict, jak z toho ven. GTK je jako multiplatformi framework nepouzitelne. Napr: MySQL Workbench to vyresil tak, ze pouziva pouze STL+Boost a svuj vlastni mikro-framework pro GUI, ktery si sami napsali. Pak je tu jeste FLTK, kdybych zacinal nejaky OS projekt, tak bych asi spis zkusil tohle nez QT.Abych si jen nestezoval, vypada to, ze na mych oblibenych chybach zacal nekdo pracovat:
https://bugreports.qt.io/browse/QTBUG-25509
https://bugreports.qt.io/browse/QTBUG-27097
https://bugreports.qt.io/browse/QTBUG-25318
https://bugreports.qt.io/browse/QTBUG-25913 -
j (neregistrovaný)
A co ty nechapes na tom, ze jakejkoli kod navic jsou prinejmenesim dalsi bugy navic nehlede na to, ze potichu neco co tam je "omylem" zapnout je otazkou jednoho pidipatche ze? Vubec nemluve o tom, ze jakakoli sitova komunikace libovolny kompotnenty ktera principielne vubec nijak komunikovat nepotrebuje je bezpecnostni dira jak doprdele.
-
- kod navic v oddelene knihovne ktera je nepouzita je 0 aktivnich bugu navic
(porovnej s poctem bugu kdyby misto moznosti knihovny kazdy vyvojar qt aplikace zbastlil do kodu svoje vlastni reseni telemetrie)- omylem zapnout na vychozi muze stejne tak byt kdyz by takova knihovna nebyla a v ramci primarni by se funkce telemetrie pridala do ni
- proto je vhodne aby tu komunikaci kdyztak zajistovala oddelena pripravena (=pokazde stejna) knihovna
-
nemo22 (neregistrovaný)
Problem mozno nieje v telemetrii ako takej ale v dovodoch preco ju nasadit a potom v samotnom prevedni. Bug reporty ktore mohol uzivatel odoslat z aplikacie povedzme cez email su tu uz roky, takze nic nove. Problem telemetrie je ze je to nieco automaticke, nekontrolovane co sa deje mimo uzivateloveho dosahu a posiela boh vie co a boh vie kam.
A co sa tyka implementacie, co znamena v tomto pripdade ze QT ju bude obsahovat ale default bude vypnuta ? Ako ze kazda aplikacia skompilovana voci QT 5.13 bude obsahovat kod na odosielanie telemetrie len sa nebude pouzivat ? Ak ano tak to bude "super" featura hlavne pre rozne backdoory a malware. Staci najist komercnu aplikaciu skopilovanu nad qt 5.13 a upravit paramtere odosielania. -
Neviditelný (neregistrovaný)
Ale vůbec ne. Pochopil jsem to tak, že jako jsou teď v Qt QTcpSocket, QMessageBox, QSqlTableModel apod. přibude sada tříd QTelemetry, která bude implementovat instrumentaci pro sběr a odesílání nějakých provozních dat. Usnadní se tím práce programátorům, kteří si ty nástroje pro reportování bugů mailem apod. nebudou muset psát sami. Zda to bude ve výchozím stavu zapnuté a co a kam to bude odesílat bude plně na vůli toho kterého vývojáře.
