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.
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..
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...
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
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
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.
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.
Telemetrie je peklo a "optimalizace " na zaklade toho jeste vetsi.
Priklad - v komercnim elektro cad-u Altium Designer byvala kota pro prumer, nyni lze v UI vlozit jenom kotu pro polomer. Ale importovane stare soubory to pobere vcetne prumeru. Proste se rozhodli "vypustit" featuru, protoze to lidi nepouzivaj.. ale zadelali si na dalsi problemy protoze to stejne musi renderovat. Tak namisto toho aby sw podporoval jasne dane featury, postupne se z nej vypousti ty, ktere "pry" vetsina nepouziva. Kdyz si nekdo kupuje SW z velke konkurencni nabidky, tak snad proto, ze ma nejake vlastnosti, a ne proto, ze se citi jako prumerny user.
Pokud je spravne rozhodnuti "osekame nas sw na totalni minimum" (coz je momentalni realita vsech producentu), tak z pohledu vyrobce mozna ano. Ale z pohledu uzivatele.. asi ne. Pred 10-ti rokama jsem byl rozhodne spokojenejsi s tim, co IT nabizelo za moznosti, dnes to je marny.. sice mame nekolikanasobne vyssi vykon, ale ty softy jsou zamerene uplne mimo misu (rozumej - na zacatecniky, masy, namisto profesionalu). A hipsterske vedeni vubec nechape co po nich jako chci, kdyz dotaz napr. smeruje k pozadavku k formatum souboru, abych do jejich nastroje mohl natahat svoji praci. Hlavne, aby bylo vsechno v cloudu protoze jsme neschopni, vid :)
Jako vazne?
1. Aplikace padaj protoze firma nema normalni vedeni produktu a vykonneho teamu, ani dobre programatory, nebo dobre QA testy. Neco co pada se nemelo nikdy k uzivateli ani dostat, copak jsme beta-testeri? Dnes asi ano. Nastesti vyrobci HW jsou posledni co nejak dbaji na to, aby veci fungovali, protoze hw nezmenis.. u sw se jen mavne rukou a prislibi update.
Prodleva v UI? Jo.. kdyz jsem jednou nahlasil, ze po SAVE si muzu udelat obed a dolozil, ze po par bajtech delaj fsync() kdezto ja mam NFS.. tak mi rekli tak to pouzivejte lokalni ulozite. Pritom stacilo udelat na tech par MB u nejvetsich projektu malloc(). Nikdo se takovym "nepodstanym" vecem, jako ze zrovna vam to jede pomalu, venovat nikdy nebude.
Pomalost startu je znova jenom problem c. 1.
Chtel jsem videt konkretni use-case, kde velika spolecnost na zaklade telemetrie priznala ze bez ni by se ten problem nikdy nevyresil. Kdyz srovnam aplikace, ktere maji a nemaji telemetrii, osobne mi prijde to co telemetrii nema stabilnejsi a rozumnejsi co se tyce organizace a zmen featur.
Ti co maj telemetrii to proste flakaj a optimalizuji sve interni procesy k minimalizaci nakladu, produkt jde stranou.
"Chtel jsem videt konkretni use-case, kde velika spolecnost na zaklade telemetrie priznala ze bez ni by se ten problem nikdy nevyresil."
To je blbý dotaz. Vždycky to jde vyřešit i jinak... Otázka je, zda se to někdy vyplatí a pokud ano tak kdy.
"Aplikace padaj protoze firma nema normalni vedeni produktu a vykonneho teamu, ani dobre programatory, nebo dobre QA testy."
Nebo protože prostě někde v divočině se stalo něco, co u autorů a testerů ne...
Jsem poslední, kdo by chtěl zlehčovat práci QA... ale je to zase jen jeden z nástrojů. A i když mám dobré QA tak chci mít třebas logy a monitoring na produkci - což je podobný případ. Teoreticky ho můžeš odmítnout, prakticky....
"Ti co maj telemetrii to proste flakaj a optimalizuji sve interni procesy k minimalizaci nakladu, produkt jde stranou."
Jsi si jistý? A pokud ano - je tam nějaká kauzalita?
Chtel jsem videt konkretni use-case, kde velika spolecnost na zaklade telemetrie priznala ze bez ni by se ten problem nikdy nevyresil.
To jako fakt? Telemetrie není žádný čaroděj, který vývojářům a produkťákům přesně vymyslí, co a jak mají vylepšit. Je to prostě nástroj pro dodatečnou QA přímo v poli. Jaky ty telemetrická data kdo použije je úplně jiná záležitost. Logika, "telemetrická data se používají nesprávně, takže celou telemetrii úplně zahodíme" je chybná. Podobně bys mohl zkonstruovat třeba argument "aplikace s GUI se tváří příliš jednoduché k použití a lidé mají tendenci je pak používat špatně, budeme tedy poskytovat jen TUI".
Podobně bys mohl zkonstruovat třeba argument "aplikace s GUI se tváří příliš jednoduché k použití a lidé mají tendenci je pak používat špatně, budeme tedy poskytovat jen TUI".
Kezby vyrobci toho windows programu udelali command line verzi - pro konverzi formatu souboru. S tim klikanim, vybiranim, next, next, next, next, next, next jsem promarnil uz hodiny. Problem je, ze vyrobce a taky lokalni support si mysli a tvrdi ze konverzi/import udela uzivatel jednou - kdyz zacne pouzivat jejich soft a pak se na veskery zbytek sveho toolchainu vykasle. A ja mam use-case kdy se to periodicky synchronizuje.
Vracím notebook, vůbec nefunguje.
A co mu je?
Pomocí reverzního inženýrství jsem spolu s mými kolegy našel chybu v procesoru - jedná se o chybu v litografickém procesu, konkrétně hradlo A0-234-67544489 vykazuje větší parazitní kapacitu.
Debugováním instrukční sady procesoru jsme dospěli k tomu, že je pouze potřeba upravit instrukci FH66.
Nějak takto si představuješ uživatele? :-)
Já tam teda vidím tohle - tedy tahá se to z https a zámeček mám zelený.
Zajímalo by mě, co tam skutečně vidíš ty, jestli ti tam ve Švícarsku náhodou nedělají nějaké to MITM :-)
<img class="opinions-comment-user-avatar__image" src="https://i.iinfo.cz/g/avatari/r2/46/416746.jpg" alt="hawran.diskuse" height="36" width="50">
Zadna aplikace ci vyrobek pro osobni pouziti nema nic pravidelne reportovat svemu tvurci ci nekomu jinemu. Jakakoliv telemetricka data mohou byt pouzita k analyze chovani uzivatele. Vic k tomu neni co rict. Kdo to nechape ma bud male zkusenosti, malou predstavivost nebo je psychopat.
jiste, zakazme prodavat noze, protoze za cas s nima budou vsichni vrazdit...
muzes poukazat na nejaky alespon castecne souvisejici projekt ktery nejdrive mel telemetrii volitelnou/zakazanou a pozdeji ji zapnul ve vychozim stavu? vynech prosim closedsource aplikace nebo Windows, protoze tam souvislost neni zadna... ;-)
dalsi nejdriv vychozi vypnuto a pak to zmenili na vychozi zapnuto? nebo to pridali rovnou jako zapnuto? to by pak byla situace jina ;-)
proc se to zkousi u svobodneho sw? protoze vyvojari nemaji testovaci oddeleni placene z prodeje sw, a pro nektere uzivatele je jednodusi si to volitelne zapnout, nez aby volitelne vyplnovali bugreporty z kterych vyvojari maji sanci poznat ze existuje bug, to ze ne kazdej i nahlasenej bug se vyresi na tom podle me nic nemeni...
kdyz nebude na to qt knihovna, tak misto pripadneho zapnuti (vzdy te same) budou vyvojari qt app pridavat (vzdy jine) reseni vlastni... stale nechapes?
nebo jinak, mas problem s tim ze pri instalaci Qt budes mit v systemu telemetrickou knihovnu, kterou Qt aplikace co budes pouzivat nepouzijou kdyz si to ty sam nevyberes?
z odkazu:
This is a work-in-progress project to create a telemetry library for various Qt applications. The library linked to Qt application allows to collects usage data from the application's users. This data could be used to improve application user experience. The idea is to collect anonymous data only, i.e. there is no way to map the collected data to any user identity. The feature is opt-in and collected data will be totally transparent to the user.<rm>
Není to tak dlouho, co se řešila inkluze telemetrie do webového frameworku Django. Nejdříve pod zástěrkou zlepšení uživatelské zkušenosti a zefektivnění řešení bugů a podobné bla bla markeťárny. Ve skutečnosti to byl požadavek investora, pro financování jejich foundation. Proč taková podmínka a že z ní vyplývá další nakládání s nasbíranými (meta)daty je snad jasné.