WindowsLike GUI (diskuse)

[Spike]

Včera sis nainstaloval svou první Mandrivu a jsi z toho trochu vyjukaný, viď? O co myslíš, že se snaží vývojáři Wine?

[dataman]

Vývojáři WINE snad vytvářejí emulátor, který spouští WIN aplikace (a to pouze na 32bit linuxu). Já myslel vytvořit knihovnu, se kterou by se program jednoduše znovu zkompiloval bez změny kódu programu.

[Luboš Doležel (Doli)]

= winelibs

[Luboš Doležel (Doli)]

a to pouze na 32bit linuxu

IMO můžete na 64bit wine spouštět 64bit Win32 aplikace.

[David Watzke]

Je to 32bit Wine kompilovaný na 64bitu. Ale zkompiluje se obyčejně. Nevím jak to přepíná emerge.

[Spike]

Nemůže, protože Wine IMHO ještě nemá funkční implementaci Win64 API. (64bit Win32 aplikace? LOL)

Na amd64/x86_64 platoformě můžeš pouze spouštět Wine v 32-bit režimu.

[David Watzke]

a to pouze na 32bit linuxu

Seš úplně mimo.

[Spike]

Víš co, ty jsi asi ztracený případ. Viděl jsi někdy Wine? Navšívil jsi winehq.org? Jedna z prvních věcí, na kterou bys narazil, je prohlášení samotných vývojářů, že se nejedná o emulátor*, nýbrž o implementaci WinAPI.

Jinak se samozřejmě dají psát aplikace pod winelib, takže by asi mělo jistý smysl portovat tu knihovnu i na jiné platformy, ale hlavním cílem projektu je spouštění win32 binárek. A tam se z x86 nehneme.

*I když je to trochu sporné - aplikacím, které emulují/napodobují/nahrazují komerční servery např. pro MMORPG (třeba pro Lineage 2, Ragnaroc Online atp.), se také říká emulátory.

[Michal Vyskočil]

Vývojáři WINE snad vytvářejí emulátor, který spouští WIN aplikace (a to pouze na 32bit linuxu). Já myslel vytvořit knihovnu, se kterou by se program jednoduše znovu zkompiloval bez změny kódu programu.

Wine is not emulator. Wine je implementace WinApi pro Posixové systémy. Vytvořit jednu knihovnu je nesmysl, už kvůli tomu, že si Windows dodnes nosí balast ještě dob Windows 3.11 (jakže se jmenovalo to rozhraní pro multimédia? DDI?) kvůli zpětné kompatibilitě. Což je imho krásná ukázka koncepce v komerčním provedení .

[trekker.dk]

Snažíš se objevit Ameriku. Pro GUI takové knihovny dávno existují - Gtk a Qt. Při programování pak stačí použít direktivy pro podmíněný překlad.

Příkladem budiž FreeCiv a battle for Wesnoth

[honza]

To bude zase diskuse ... asi zakládáte rád flame ....

[Luboš Doležel (Doli)]

ty komereční jsou častěji kvalitnější, stabilnější

Nebudu komentovat, to by byl zase flamewar.

Programátor má potom těžký výběr

OMFG. Chudáček programátor. A co třeba Javisti, když si musejí vybírat mezi AWT/Swing/SWT.

a o to těžší je převést nějaký program do linuxu

Směšné. To je asi jako říct, že lidi chodí pěšky, protože si nedokážou vybrat auto.

Možná by nebylo špatné, kdyby někdo napsal knihovny

Už je tu Winelibs.

Asi nemáte potuchu, jak pokročilejší je GTK/Qt ve srovnání s WinAPI. V GTK/QT (a i v Javě) se prostor okna nějak "rozděluje", takže z toho plynou výhody, jako je bezproblematické roztahování okna (widgety se přizpůsobí). Ve Windows je to natvrdo (ano, třeba Delphi apod. to nějak "řeší"): control má natvrdo své rozměry i umístění.

WinAPI je založeno na těžce neefektivním zasílání zpráv; troufám si říct, že přímé volání metod/funkcí toolkitu bude rychlejší.

GUI je z celé aplikace naprosté minimum - tím že do Linuxu (ještě více) zanesete nekvalitně navržené GUI/API Windows, které se s časem rozšiřuje už od dob Windows 3.1 (a asi i 2.0), ničemu nepomůžete.

[Michal Vyskočil]

Asi nemáte potuchu, jak pokročilejší je GTK/Qt ve srovnání s WinAPI. V GTK/QT (a i v Javě) se prostor okna nějak "rozděluje", takže z toho plynou výhody, jako je bezproblematické roztahování okna (widgety se přizpůsobí). Ve Windows je to natvrdo (ano, třeba Delphi apod. to nějak "řeší"): control má natvrdo své rozměry i umístění.

Přesně tak, vždyť GUI definované v XML souboru má být novinka nových Windows (Avalon, Aero, nebo tak se to bude jmenovat), zatímco trapné Qt i Gtk to už hezkých pár let zvládají. Layout managery, aby ve Windows pohledal (pouze .Net je už obsahuje). Už jsem vzpomínal v článku o Kommanderu, viděl jsem aplikaci ve Visual Basicu, kde yohle programátor řešil ručně a byla to podstatná část kódu aplikace

[Luk]

Pár technických poznámek:

A co třeba Javisti, když si musejí vybírat mezi AWT/Swing/SWT.

Tady je to jasné. AWT je pasé (některé věci se stále používají, ale GUI jako takové ne), se SWT mám špatné zkušenosti - takže u mě jednoznačně vítězí Swing.

WinAPI je založeno na těžce neefektivním zasílání zpráv; troufám si říct, že přímé volání metod/funkcí toolkitu bude rychlejší.

Přímé volání ano. Ale co třeba události v Qt (vytvořit instanci potomka QEvent, nastavit parametry, zavolat metodu), o signálech/slotech nemluvě. Zasílání zpráv (jak synchronní, tak asynchronní) zase tak těžce neefektivní není, tady bych zásadní problém neviděl. Zvlášť v porovnání s X protokolem.

GUI je z celé aplikace naprosté minimum

GUI je ta nejnáročnější a nejkomplikovanější část aplikace. U průměrné aplikace zabere vývoj a ladění GUI přes 60 % času stráveného celou aplikací. Nicméně souhlasím s tím, že zatahovat Win32 API do Linuxu (WINE nepočítám) by byla chyba.

[Miloslav Ponkrác]

Koněčně někdo, s kým mohu souhlasit!

Takže ano, nic jiného, než Swing na Javě nemá smysl. SWT je hroznej bastl a AWT už je pryč.

Na zasílání zpráv bych taky neviděl jako něco neefektivního.

A též souhlasím s tím, že tvrdit, že GUI je naprosté minimum je omluvitelné pouze u člověka, který nemá zkušenosti s programováním, jinak by tohle opravdu seriózně nemohl tvrdit.

[Luboš Doležel (Doli)]

Zasílání zpráv (jak synchronní, tak asynchronní) zase tak těžce neefektivní není

Pravděpodobně nemáte moc velké zkušenosti z prvky jako je Win32 TreeControl. Je to brutálně pomalé.

GUI je ta nejnáročnější a nejkomplikovanější část aplikace.

Já GUI dodělávám k existujícímu kódu. A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.

[Luk]

Dovolím si tvrdit, že zkušenosti s programováním ve Win32 API a MFC mám poměrně velké. TreeControl je obecně špatně navržený, proto ta pomalost (vím o ní moc dobře), totéž i další komponenty. Problém je mj. ve zbytečném překreslování, takže se musí dělat různé opičárny, jak tohle eliminovat.

Ale stojím si za tím, že mechanismus posílání zpráv (a to ani ten, co je ve Windows) není brzdou GUI.

Zaslání synchronní zprávy není nic jiného než zavolání callbacku s určitými parametry - takže jediné, co může malou chvíli trvat je výběr správného callbacku podle čísla zprávy.

Zaslání asynchronní zprávy je zase vložení malé struktury do fronty. Po odebrání zprávy v hlavní smyčce se zase jen vybírá callback k zavolání.

Kdo zná Qt nebo třeba Swing v Javě, tak ví, že to tam v principu funguje úplně stejně. Spíš ještě složitěji, protože se konstruují instance objektů událostí.

A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.

Mohou být aplikace se strohým GUI (např. pár vstupních a výstupních polí, nějaké to tlačítko). Ale většinou je to mnohem horší - sice to jde v základu naklikat, ale pak nastává dlouhé období jemných úprav, aby byly např. povoleny (nebo viditelné) jen ty prvky, které mají v dané situaci význam.

Každé složitější GUI musí být také již ve fázi návrhu (před implementací) otestováno po ergonomické stránce. To mnoho vývojářů zanedbává, a výsledkem je nespokojenost uživatelů.

Prostě, kvalitní GUI je vždy těžká práce.

[Luk]

Dovolím si tvrdit, že zkušenosti s programováním ve Win32 API a MFC mám poměrně velké. TreeControl je obecně špatně navržený, proto ta pomalost (vím o ní moc dobře), totéž i další komponenty. Problém je mj. ve zbytečném překreslování, takže se musí dělat různé opičárny, jak tohle eliminovat.

Ale stojím si za tím, že mechanismus posílání zpráv (a to ani ten, co je ve Windows) není brzdou GUI.

Zaslání synchronní zprávy není nic jiného než zavolání callbacku s určitými parametry - takže jediné, co může malou chvíli trvat je výběr správného callbacku podle čísla zprávy.

Zaslání asynchronní zprávy je zase vložení malé struktury do fronty. Po odebrání zprávy v hlavní smyčce se zase jen vybírá callback k zavolání.

Kdo zná Qt nebo třeba Swing v Javě, tak ví, že to tam v principu funguje úplně stejně. Spíš ještě složitěji, protože se konstruují instance objektů událostí.

A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.

Mohou být aplikace se strohým GUI (např. pár vstupních a výstupních polí, nějaké to tlačítko). Ale většinou je to mnohem horší - sice to jde v základu naklikat, ale pak nastává dlouhé období jemných úprav, aby byly např. povoleny (nebo viditelné) jen ty prvky, které mají v dané situaci význam.

Každé složitější GUI musí být také již ve fázi návrhu (před implementací) otestováno po ergonomické stránce. To mnoho vývojářů zanedbává, a výsledkem je nespokojenost uživatelů.

Prostě, kvalitní GUI je vždy těžká práce.

[Luk]

K...., co jsem to zase vyvedl?!!!

[David Watzke]

Kliknuls 2x, nebo tě zmátla chybová hláška. Já už jim to nežeru.

[Luk]

Chybová hláška nebyla (narozdíl od včerejška, kdy jsem to jako blbec odeslal znovu). Asi jsem kliknul 2x, fakt nevím...

[Yin]

Dobrý programátor sa nezamýšla nad tým, ktorú knižnicu použije vo svojej aplikácii. Dobrý programátor robí GUI až nakoniec.

V komerčných firmách sú programátori platený za prácu. Členovia týmu pracujú často v jednej budove/kancelárii a komunikácia nie je problém. K dispozícii je tým profesionálnych testerov a nad tým všetkým stojí minimálne jeden manažér "s bičom". To je krvou zaplatená kvalita.

Nefňukaj! Nie je umenie pracovať s kvalitnými aplikáciami. Predstav si, čo dokážeš ak teraz prestaneš používať X-i...

[doubleZ]

Tak to se mi sakra líbí!!! Tvá slova káži tesat do kamene, vyřezat těm, kdož pochybují (a mezitím jim odinstallit Xka ).

[Heron]

málo opravdu kvalitních programů, které trpí spoustou nedodělků

Dává ta věta někomu smysl? Kvalitní program má nedodělky?

Programátor má potom těžký výběr, pro které rozhraní program udělat.

Může si napsat vlastní.

Pokud chce napsat kompatibilní program napříč mnoha OS, může to napsat v Javě. Možná to ještě nevíte, ale Linux a Windows nejsou jediné OS.

[Miloslav Ponkrác]

Myslím si, že autor blogu si stěžuje neoprávněně, protože jeho přání už se dávno vyplnilo. Stačí používat .NET framework a jeho WinForms navrhnuté Microsoftem jako wrapper pro Windowsovskou grafiku. No a tým kolem Mona se tvrdě snaží tato windowsovská okýnka naemulovat se vším všudy přesně tak, jak se chovají na Windows.

Takže autore blogu nehořekujte, přesuňte se na Mono platformu a můžete používat Windowsovskou grafiku nejen na Linuxu, ale třeba i Apple počítačích, či jinde. Užijete si naprosto do sytosti a nemusíte si stěžovat. Budete mít přesně to, po čem toužíte a voláte

Těším se na to, aý tým kolem Mona začne prosazovat takové věci, jako jsou COM, Registry, a podobné věci.

[Michal Vyskočil]

Pozor, na to, že už asi měsíc je nový .NET 2.0 a mono stále nemá WinForms 100%.

Jinak zmínky o COM a registrech jsou imho dost mimo, protože právě .NET tohle (konečně) odstraňuje i v samotných Windows.

[Miloslav Ponkrác]

Upřímně řečeno, ani bych nečekal že Mono bude nějak rychle kopírovat novinky Microsoftu z .NET platformy. Stejně tak vím, že WinForms není na 100%, ale snaží se o to. A to je přesně to, co požaduje autor tohoto blogu, nebo ne?

Registry se samozřejmě snaží .NET učinit obecně nepotřebnými pro .NET aplikace, ale COM tam ještě dost často zatahuje, sem tam je to tam dost vidět.

Zase bych nesouhlasil, že tyhle věci odstraňuje .NET i v samotných Windows. Protože nic Win aplikacím postaveným nad .NET frameworkem samozřejmě nebrání do registrů sahat, stejně tak jako používat COM. A i samotný .NET framework ve Windows samozřejmě registry používá a na COM je vystavěn taky.

[Michal Vyskočil]

Jo máš pravdu, nechal jsem se včera trochu unést. To, že je ta aplikace v .NET samozřejmě neříká nic o tom, že si toho programátoři laskavě všimnou a přestanou používat registry a unmanaged kód. Ostatně, většina si dodnes nezvykla, že je oddělený administrátorský a uživatelský účet, přitom NT jsou, tuším, 10 let staré

[franta]

nedelej si dal ostudu a radsi ten zapis rovnou smaz
je to fakt blabol

[juice]

tak

ja som po prečítaní tohoto zápisu najprv premýšľal, či náhodou nie je zase 1. apríla, ale potom som si spomenul, že ešte musím kúpiť nejaké darčeky, takže mi došlo, že asi nie

[Foobar.Beer]

Diky .. zasmal jsem se fakt dobre .. mam navrh: co takhle misto bashe pouzit DOS? mozna bys to spustil i s nejakym windows emulatorem ... nebo .. pokud ti windows v linuxu opravdu chybi tak, ze bys je tam chtel cpat, pouzivej windows ..

[Dag]

Má prostá duše zase něco nechápe. Až dojdu k závěru, že pro Win jsou lepší programy, tak si nainstaluju rovnou Win. Pokud chci používat hlavně, nebo výlučně programy psané pro Win, tak proč si dávat na počítač Linux? Já mám Linux abych na něm používal programy psané pro něj, ale možná je to podivínství(???).

[franta]

Co si budeme namlouvat. Pro linux je dnes jen málo opravdu kvalitních programů, které trpí spoustou nedodělků, a ještě méně komerečních programů.

Tahle veta me prijde hodne podivna. Myslis, ze lidi jsou az takovy masochisti a pouzivaj nekvalitni sw jen proto, aby to tomu zlymu Microsoftu "natreli" ? Asi ne, vid To, ze nektery programy holt nemaj ten spravnej cool design, jeste nic nevypovida o jejich kvalite. Dobra prostitutka se preci taky nehodnoti podle toho, jak je zmalovana, ale jaka je v posteli ..
Co se tyce tech graf. toolkitu, to je vec nazoru. Me osobne prijde argument, ze cim vic g. toolkitu, tim hlubsi vrasky pro programatory, jako naprosta blbost
A ad ty win kompatibilni knihovny, uaaaa mamkooo!

Hezkej den

[David Watzke]

Dobra prostitutka se preci taky nehodnoti podle toho, jak je zmalovana, ale jaka je v posteli ..

Ne? A podle čeho?

[franta]

<jen_zertik>
tomu nerozumis, klucino
Vysel ti novej maskovanej ebuild, tak supajda
</jen_zertik>

[David Watzke]

<naprosto_vážnej_výraz>
Novej? Mám ho už jakou dobu... Novej maskáč už ani nepamatuju.
</naprosto_vážnej_výraz>

[Foobar.Beer]

Jeste me tak napadlo .. "ty mas fakt pri programovani problem vybrat si mezi gtk a qt?" ? "neni na case zacit se zabyvat radsi treba zemedelstvim" : ""?

[Pavel Stárek]

No, abychom to autorovi ještě více "usnadnili", tak mu doporučíme ještě toolkit wxWindows (wxWidgets)

[Luk]

Ano, ten je výborný. Spojuje výhody GTK a Qt, je přenositelný, a používá ho už spousta velkých projektů (včetně komerčních, třeba AVG).

[Luboš Doležel (Doli)]

Ten výhody nespojuje, Ba naopak. Je to hnusné, na makrech založené, API ve stylu MFC.

[Luk]

Spojuje. Z Qt si bere objektovost, naopak má lepší licenci. API je někde uprostřed mezi MFC a Qt. Mnohem hnusnější API má GTK+, ale je věcí každého, co mu víc vyhovuje.

[Bubak]

To radsi Fox-toolkit!

[mimi.vx]

a co qt a gtk ... ty jedou stoprocente v obojim....

[Luk]

"Stoprocentně" bych netvrdil. Osobně mám s GTK+ pod Windows velice špatné zkušenosti. Padá a padá...

[Pavel Stárek]

Svého času mi padaly aplikace s nějakou verzí GTK+ pro Windows z tohoto zdroje při zobrazení Open/Save dialogu. Teď mám verzi 2.6.10rc něco a zatím mi všechny aplikace chodí (GIMP, PyGTK, AbiWord atd.).

[Luk]

Nejhorší zkušenost mám s GIMPem, a to hlavně v posledních verzích. Momentálně u sebe GIMP pod WinXP nemohu vůbec používat - spadne při otírání dialogu pro otevření souboru

[Luk]

otírání -> otvírání

[Pavel Stárek]

No já používám z toho odkazu verzi gtk-sdk-2.6.10rc1 a zdá se že to chodí. Ono stačí pustit Glade a dát Otevřít a nesmí to spadnout. Jedna verze to prostě dělala.

[Pavel Stárek]

Poté už by nebyl takový problém převádět spoustu kvalitních programů do linuxu.

Nevím sice které "kvalitní programy" pro Windows máš na mysli, ale předpokládám, že firmy jako Adobe, Autodesk, Microsoft a jiní se určitě nebudou snažit "nějak matlat" svoje aplikace tak, aby nějak chodily v nějaké distribuci GNU/Linux . Nemám nic proti Windows (dokonce pro ně pracovně vyvíjím i nějaké aplikace), ale i v mnou používané distribuci (Fedora Core 4) jsem našel alternativy pro mnou používané aplikace z Windows. A pokud budu potřebovat napsat nějakou multiplatformní aplikaci, tak si ji napíšu v Javě (JFC/Swing toolkit), nebo v Pythonu (PyGTK bindings pro GTK).