Portál AbcLinuxu, 16. června 2025 19:21
21.2.2009 12:21
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
A jak to souvisi s tou zpravickou ?
A neskončí to podobně jako Qt Jambi? Ostatně, jaké jsou vlastně výhody oproti psaní GUI ve Swingu? Ani jednu z knihoven jsem podrobně nestudoval, ale jak je to například s přenositelností GUI na jiné systémy než je Linux? U Qt bych si ještě dokázal představit, že to poběží bezproblémově pod Windows nebo Mac OS X. Ale GTK? Ten si myslím, že bude jenom pro Windows a pokud pro Mac, tak tam bych předpokládal dost ubohý vzhled. Ostatně, už jenom kvůli integraci Swingu do Macu bych rozhodně grafickou knihovnu neměnil...
22.2.2009 14:06
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
ale jak je to například s přenositelností GUI na jiné systémy než je Linux? U Qt bych si ještě dokázal představit, že to poběží bezproblémově pod Windows nebo Mac OS X. Ale GTK?
To je vtip? Pokud někde něco běží, tak určitě GTK+. V oficiálním listu platforem je jak Linux, tak Windows a MacOS.
Ten si myslím, že bude jenom pro Windows
MacOS má dokonce svůj vlastní portál.
a pokud pro Mac, tak tam bych předpokládal dost ubohý vzhled.
Jinak pokud nějaký vzhled mít bude, tak nebude ubohý, ale ten výchozí. Sami vývojáři uznávají, že vypadá pěkně hnusně. Bohužel jej při kompilaci nijak snadno nelze změnit (i když třeba ikony se zrovna nacházejí v gtk/stock-icons, takže s tím by šlo něco dělat) a vůbec:
If you mean the default theme that is built into GTK, I doubt it. But it is pretty ugly. Themeing is really up to your gnome-settings-daemon, though.
http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-modify-style and http://library.gnome.org/devel/gtk/stable/gtk-Resource-Files.html kinda talk about all this, though
to be honest, I'm pleased that I've never had to mess with any of that. It's kind of a GNOME thing; we don't mess with a user's desktop wide preferences [ie, theme] whenever possible and without a really good reason.
Ovšem nikdo nebrání ho změnit po kompilaci. To výchozí téma určitě bude mít co dělat s Windowsy rovny a nižšími než 2000, protože tam zapadne dokonale.
22.2.2009 14:12
Limoto | skóre: 32
| blog: Limotův blog
Qt běží taky leckde... A mylím, že do Macu zapadá dobře.
Hustý, tak to klobouk dolů! Takhle to má vypadat 
Já jsem kdysi zkoušel Psi pod Macem a bylo tak hnusné, že jsem ho radši nepoužíval. Ale to je v tom případě způsobeno tím, že si s tím autoři nedali potřebnou práci...
22.2.2009 14:47
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Qt běží taky leckde...
A opak bych si nedovolil tvrdit. Pouze dodávám, že GTK+ na tom není jinak.
A mylím, že do Macu zapadá dobře
Znova netvrdím opak, jen dodávám, že GTK na tom může být stejně když se chce.
BTW: Zrovna v tomto případě WebKitu se nepoužívá Qt, ale nativní podpora Macu:
$ ls /usr/src/WebKit/WebKit/mac/ Carbon DOM ChangeLog ChangeLog-2007-10-14 MigrateHeaders.make Plugins Storage WebKit.exp WebView Configurations ForwardingHeaders ChangeLog-2002-12-03 icu Misc PublicHeaderChangesFromTiger.txt WebCoreSupport WebKit.order DefaultDelegates History ChangeLog-2006-02-09 Info.plist Panels Resources WebInspector WebKitPrefix.h
GTK+ na tom bohužel jinak je. Prozatím vyžaduje ke svému běhu X, což není zrovna dobré. Krom toho, to že vypadá podobně jako nativní GUI bohužel také nestačí. Díval jsem se na ten projekt a:
Držím jim palce, je s tím ještě hodně práce. Ale bohužel to není zatím ve stavu, kdy by se to dalo označit jako použitelné...
Btw.: Když teď koukám do toho výpisu, co ten prohlížeč používá, tak tam vidím Carbon. To není zrovna dobrá volba, vzhledem k tomu, že toto API je tak trochu deprecated. Ačkoliv Cocoa na Carbonu závisí, tak preferovaný framework pro nové aplikace je právě Cocoa, nikoliv Carbon, který neobsahuje 64-bitovou podporu. Bojuje s tím i Adobe, avšak u nich je to pochopitelné, protoze Photoshop je strasne stary program...
O Glade vím. Ale nevěděl jsem, že se dá nainstalovat i pro Mac. Takže si sypu popel na hlavu. Avšak integrace s Interface Builderem by byla lepší – avšak nepodstatně pracnější na napsání.
Ten odkaz vím, sám jsem ho sem posílal a podívej se na status projektu - ve vývoji.. Cocoa závisí na Carbonu – využívá některé jeho funkce; to je známá věc. Stačí si přečíst pár příruček. Pokud Qt obaluje Cocoa, tak to je fajn. Já jenom, že jsem v tom výpisu zahlédnul Carbon. Ale v tomto případě nechci nic usuzovat, protože jsem se do zdrojáků nedíval (ani se o tom moc nezmiňuji).
Zatím to vidím tak, že pokud chci psát program v C/C++ a chci mít multiplatformní GUI, tak se víc hodí Qt než GTK+. Na stabilní nativní GKT+ si holt ještě budeme muset počkat.
Což je častý omyl. Carbon je sice legacy APi, které sloužilo k přechodu z Mac OS 9 na Mac OS X, avšak ne rozhodně tak, že by se už vůbec nemělo používat. Komerční aplikace jej využívají stále a Cocoa jeho některé funkce taktéž. Nevím však bohužel které přesně, protože tak hluboko do toho nevidím. Některé věci bys totiž bez Carbonu jenom čistě pomocí Cocoa ani neudělal. Ale tady už se fakt pouštím na tenký led, protože moje znalosti jsou prozatím spíše rámcové v tomto ohledu. Rozhodně bych doporučoval navštívit ADC a přečist si ty tutoriály. Speciálně o Cocoa, tam jsem to četl.
jj, ty MacPorts jsem právě nevěděl, že to obsahujou
Vážně si raději něco nastuduj Carbon je totiž do 64-bitové architektury převeden částečně. Nejsou převedeny pouze ty části, jenž jsou deprecated. Zbytek pochopitelně musí být 64-bitový, jinak by jej 64-bitová Cocoa těžko použila. Pokud tě zajímají podrobnosti, je dobré si přečíst příručku pro přechod na 64-bitové aplikace. Je napsána zvlášť pro Carbon a zvlášť pro Cocoa. A přiznávám se bez mučení, že jsem ji nečetl Na školení zabývající se přechodem na 64-bit jsem sice byl, avšak již v té době nám říkali, že se to musí opravdu vyplatit, takže jsem se tomu dál nevěnoval
At WWDC 2007, Apple revealed that it will not be possible to compile Carbon apps as 64-bit code for Leopard, contrary to previous statements. Some lower-level parts of Carbon, such as the File Manager, are expected to be available in 64 bit.Jestli tuhle část „zpřístupnili“ pro 64bit, protože nemá (zatím?) v Cocoa protějšek, nebo co tím sledují, to nevím.
Vidouce, že stále nechápeš co mám na mysli jsem ti našel i přímý link, který všechno vysvětluje... Teď už je doufám (ne) podpora 64-bitového Carbonu jasná. Doporučuju se v případě zájmu poohlédnout i po již výše zmíněných příručkách, které přechod patřičně rozebírají do detailu.
Uh, tak už nevím jak tě přesvědčit 
Tohle je moje poslední šance :-) Hledej tam slovo Carbon, je to vysvětleno přibližně uprostřed pod třetím obrázkem...
No, pokud bys chtěl oficiálnější vyjádření ohledně Carbonu, tak kromě ADC můžeš zkusit i Wikipedii 
Nechápu kam míříš. Poslal jsi odkaz na Cocoa, ale já měl na mysli Carbon, který jsem odkazoval já
Jistě, však nic takového ani neříkám. Carbon prostě není preferované API, protože obsahuje části, které jsou deprecated a které nebudou převedeny pro 64-bit. Ostatně, jak to nakonec dopadne se podle mě dozvíme ve Snow Leopardovi. Proč Javu nemá Apple rád, to je mi záhadou. Naštěstí tohoto názoru se zastává pouze vedení, jejich inženýři se na mailing listu snaží a spolupracují s vývojáři Sunu... Docela zvláštní postoj
Ačkoliv Cocoa na Carbonu závisíTřeba kvůli tomuto tvrzení jsem poslal odkaz na Cocoa?
Víš, když něčemu nerozumíš, tak se do toho prosím nemontuj... Tady jde o vysvětlení principů, nikoliv o důkaz, že to tak je. Vzhledem k tvému komentáři usuzuji, že o architektuře Macu víš jako já o sibiřských psech, takže pojmy jako /System/Library/Framework ti stejně budou cizí... Pochopitelně, že je možné si to jakýmkoliv způsobem ověřit, avšak to tu neřešíme.
Vzhledem k tvému komentáři usuzuji, že o architektuře Macu víš jako já o sibiřských psech, takže pojmy jako /System/Library/Framework ti stejně budou cizí...
Follow up…
22.2.2009 09:01
23.2.2009 10:54
petr-hadrabas-macbook-pro:~ petr$ otool -L /System/Library/Frameworks/Cocoa.framework/Cocoa
/System/Library/Frameworks/Cocoa.framework/Cocoa:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.33.0)
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 186.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1)
petr-hadrabas-macbook-pro:~ petr$ otool -L /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.43.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 186.0.0)
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv (compatibility version 1.0.0, current version 67.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.21.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox (compatibility version 1.0.0, current version 353.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.5.7)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 34102.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libauto.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 36.0.0)
/usr/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.16.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI (compatibility version 1.0.0, current version 62.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.15.0)
Pochopitelně, že je možné si to jakýmkoliv způsobem ověřit, avšak to tu neřešíme.
A co tu teda řešíte? Akorát si vyměňujete linky do Wikipedie a mlátíte prázdnou slámu. Připomíná mi to prasata z Bristolu. Věděj hovno, uměj hovno, ale dokážou o tom celý dny akorát tak blbě kecat. Jdi si radši krást na Torrenty a osvobozovat zločince.
To, že Cocoa používá Carbon jsem věděl dřív, než jsem Macy vůbec měl. To, že například přetypování CFStringRef na NSString funguje, jsem si tisíckrát ověřil. A že lze instance NSStringů šukat funkcema Carbonu (Core Foundation), to taky.
Ale třeba se pletu a vím o všem hovno. Přecijen, moc jsem toho nenapsal. Jen jsem se nahákoval do WindowServeru na Tigeru. Mohl bych to zkusti na Leopardu, jestli mi hoši nezrušili nedokumentované funkce, které používám.
Mohl bych to zkusti na Leopardu, jestli mi hoši nezrušili nedokumentované funkce, které používám.
Ale no jó. Funguje naprosto dokonale. Hoši prostě věděj, jak mi udělat radost. Hezky pěkně napoprvý bez nejmenších potíží. Takhle se dělá software.
Za druhé: otool. Ten nástroj znám a místo abych na něj odkázal jako ty, tak tu posílám odkazy... Nice. Můžu říct, že tohle se ti povedlo
Za třetí: ta konverze není nic světoborného, v podstatě jsem na ní prvně přišel tím, že jsem z AddressBooku při vytahování položek poslal zpravu class a ono to nevratilo NSString, ale z CoreFoundation. Opět uznávám, že tohle jsem mohl použít jako pádný argument a zbytečně se nevykecávat.
Za čtvrté: Ten WindowServer zní zajímavě Ostatně, ono vůbec tak nějak ten systém není tak neprůstřelný, jak ho marketing líčí. Na kernel panic po upgradu na Leoparda člověk taky nemusel zrovna dlouho čekat...
22.2.2009 16:04
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Prozatím vyžaduje ke svému běhu X, což není zrovna dobré.
No a to právě není pravda. Zrovna jako výhoda GTK bývá uváděna schopnost běžet na různých grafických backendech. Samozřejmostí je X11. Pak dále ten bazmek co používá Windows (Bývá uvedeno jako win32. Nevím co tam používají, ale prostě není potřeba používat Xming nebo X11/Cygwin), Quartz(což bude asi nějaké to nativní API pro Mac, ne?) a Framebuffer pro použití v Embedded zařízeních(Ve verzi 1.X dokonce dovolovalo GTK používat čistý framebuffer bez knihovny DirectFB. Což je mnohem dřív než se na to v Qt vůbec myslelo. Tam se k framebufferu přiklonili až po odkoupení a nasměřování Nokií) viz. GNOME mobil, OpenMoko nebo Maemo.
To jsi špatně pochopil. Myslím tím X11.app, což je docela šílenost. Vzhledem k tomu, že Mac neznáš, tak nevím jak bych ti to vysvětlil... To se prostě musí vidět Jde o to, že se X11 server na Macu standardně nespouští. Tím, že si ho spustím externě se mi naváže na Quartz, avšak veškerá integrace se zbytkem systému je v /dev/null (velmi sušně řečeno).
22.2.2009 16:44
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Pak mi nezbývá, než se uchýlit k zbabělé taktice citací:
Qt je multiplatformny vsestranny toolkit.
GTK je len widget toolkit.
GTK je GUI knižnica, zatiaľ čo Qt je kompletný toolkit na tvorbu desktopových, mobilných, a teoreticky aj serverových (aj keď to už je trochu overkill) programov.
Ono jaksi Qt není (jenom) GUI toolkit, ale aplikační framework…
GTK dělá jen přesně to k čemu je určené. Starost o GUI. Nic víc, nic míň. Jestli je to dobře nebo špatně nechám na vývojářích, kteří s těmito toolkity pracují.
Z čehož bohužel vyplývá, že GTK teda nebude nikdy plnohodnotnou volbou pro psaní aplikací, protože zbytek si buď bude muset vývojář dopsat sám, nebo použít externí knihovny. Krapet škoda...
22.2.2009 18:26
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
22.2.2009 19:28
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Otázkou je, na kolik se vyplatí kombinovat použité jazyky. Nicméně je to v poslední době trend, takže není problém vidět aplikace v Javě, co používají Ruby apod. Různých bindingů je kýbl a existují dokonce i pro Objective-C, kde Apple přidal podporu pro Python a Ruby bridge. Takže máš asi pravdu
22.2.2009 18:48
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Přesně tak.
src/3rdparty$ ls
clucene des freetype harfbuzz libjpeg libmng libpng libtiff Makefile md4 md5 patches phonon ptmalloc README sha1 sqlite webkit wintab xorg zlib
22.2.2009 19:26
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
To je pohled programátora aneb aby šla práce lépe od ruky a v jednom prostředí. Pohled uživatele/občasného kompilátora té aplikace je trošku jiný.
22.2.2009 19:49
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Z čehož bohužel vyplývá, že GTK teda nebude nikdy plnohodnotnou volbou pro psaní aplikacítvrzením, že ne všichni po tom touží. Že jsou jedinci, kteří právě po tomhle netouží. Nic víc.
22.2.2009 18:41
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
No záleží jak se to vezme. Když se podíváte do zdrojáků Qt, tak je tam složka pro platformně specifické věci. A ve složce unix není nic jiného než binding zrovna na ty otevřené knihovny. Já osobně zastávám názor, že je lepší když je program složen z více nezávyslích knihoven či systémových volání a všechny ty slepené části si ovládá sám program. Pokud je potřeba portace, tak se má dělat v kompilátoru a programu než v nějakých modulech, které si právě vyřeší framework. Ale je to jen můj názor a programování ve frameworcích je bohužel silnější než můj názor. Ale vzhledem k tomu, že GTK+ oproti Qt vůbec nijak neupadá (spíš bych řekl , že právě naopak) bych řekl, že s tímto názorem nebudu sám(i když je také dost možné, že se u všelijakých těch projektů volí to GTK spíše protože každý si tam musí přidat svoje blbinky aby byla aplikace dostatečně coolovní).
22.2.2009 15:17
Limoto | skóre: 32
| blog: Limotův blog
Je to browser Arora, kterej je napsanej kompletně v Qt a používá QtWebKit.
Není to zas tak strašné, už jsem viděl odpornější GUI. Ty ikony se dají předělat, horší jsou ty input boxy... Ale snad to časem vychytají.
22.2.2009 15:48
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Já vím. Aroru ještě poznám a zvláště když ji zrovna v tento moment kompiluju. Jen upozoňuju, že pokud to není ze zdrojáků, ale nějaká předkompilovaná binárka, tak WebKit dovoluje použít jako cíl právě nativní prostředí Macu a docela bych se divil, kdyby ho zrovna tam nepoužili. A i samotná Arora obsahuje ./src/Info_mac.plist. Výchozí vzhled Qt je totiž Oxygen.
22.2.2009 16:05
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
22.2.2009 17:15
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
Oxygen je výchozí téma KDE 4, v Qt ho nenajdeš (aspoň co se Qt 4.4 na Arch Linuxu týče - ale nikde jsem neslyšel ani zmínku o tom, že by se Oxygen měl stát součástí Qt).
22.2.2009 17:50
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Oxygen je výchozí téma KDE 4, v Qt ho nenajdeš (aspoň co se Qt 4.4 na Arch Linuxu týče - ale nikde jsem neslyšel ani zmínku o tom, že by se Oxygen měl stát součástí Qt).
Aha. To je fakt. Zkompiloval jsem si totiž vlastní Qt, ale nějak zapomněl že ten Oxygen už mi tam Ubuntu natlačilo samo. No bez něj to stejně vyzkoušet nemůžu, protože by se mi zase odinstalovaly všechny Qt aplikace. Docela by mě ale zajímalo co se zobrazí, když nebude nainstalovaný Oxygen.
22.2.2009 18:02
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
22.2.2009 20:25
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
Výchozí téma záleží na platformě. Jak vypadají widgety pro jednotlivá zabudovaná témata se můžeš podívat tady.
22.2.2009 16:26
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
22.2.2009 15:31
Milan Vít | skóre: 23
| blog: about:linux
| Orlová
Ten status bar se mi taky vůbec nelíbí, tuším, že stejný má i Firefox a – je zkrátka pěstnaokoidní.
Ne, vtip to není. Vtip je spíš základní GIMP pod Macem (o trochu méně už GimpShop). A trochu trapnej vtip Ale nehádejme se o blbostech, protože koukám, že jsi tu napsal docela dost zajímavých odkazů. Dík.
O tom portálu jsem nevěděl, rozhodně zajímavé... Jenom tam tak nějak nepíšou, jestli na provozování takovéto aplikace je potřeba X, nebo ne. Což je dost zásadní informace. Nicméně, našel jsem http://developer.imendio.com/projects/gtk-macosx/ a tam píšou, že se na tom pracuje. To je fajn, ale v praxi to znamená, že GTK+ na Macu žádná sláva a na produkční nasazení bych ho nepoužil.
Vzhled GTK+ aplikací se pochopitelně dá nastavit, ale... Uživatel chce svůj nativní vzhled, ne nějaký Windows 2000. Dvojnásob to platí na Macu. Natožpak aby přes nějaké klikátko někde musel měnit dodatečně vzhled. To je však i častý nešvar Java aplikací. Většina vývojářů je uchvácena tím, že tam jde dát jiný než nativní vzhled a tak je to pak barevné jako cirkus, ale absolutně to nezapadá do systému.
Jinak díky moc za odkazy, jdu si s tím pohrát Mě se GTK+ líbilo na Linuxu hlavně kvůli grafickému návrháři. Avšak i proto, že je naprogramováno objektově v čistém C.
A ještě jedno rýpnutí na závěr: nepíše se MacOS, ale Mac OS X To jenom pro upřesnění, protože MacOS neznamená nic a Mac OS znamená systémy 9 a nižší, což je dneska už dost archaismus. Většině lidí to dělá dost problém pochopit
22.2.2009 15:38
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Ne, vtip to není. Vtip je spíš základní GIMP pod Macem (o trochu méně už GimpShop). A trochu trapnej vtip
Pokud myslíte toto, tak to je právě ten nešvar výchozího vzhledu o kterém mluvím výše. Nevím proč tam je. Snad právě z toho důvodu, že se tam strkal za dob Windowsů 2000 nebo protože je rychlý a nebo aby nebyl nijak křiklavý a zapadl (stačí se podívat na výchozí Tango - to má hodně vysoký kontrast právě v barevných složkách a tak by mohlo dosti křičet v nějakých konzervativnějších prostředích i když by dle mého názoru vypadalo všude mnohem lépe), ale sami vývojáři uznávají, že je to problém. Zatím to na mě působí tím dojmem, že vývojáři GTK aplikaci to nechávají na GTK+ nebo uživateli, vývojáři GTK říkají, že to není jejich starost, ale starost projektu GNOME a to to právě řeší jen při kompletní instalaci GNOME (tam je výchozí vzhled úplně jiný a ještě se dá zaměnit třeba za Clearlooks) což zrovna u jiných OS než Linux moc nejde a uživatel křičí, že to měla být starost všech výše jen né jeho. Takový začarovaný kruh. A jeho rozseknutí znesnadňuje to, že ten výchozí vzhled je tam různě zadrátován ve zdrojácích a vývojářům GTK se do toho moc nechce(a vůbec se jim nedivím). No aspoň ten GIMP si už trošičku polepšil. Vsadím boty, že na téma výchozího vzhledu GTK+ už někde nějakých pár flejmů určitě proběhlo.
O tom portálu jsem nevěděl, rozhodně zajímavé...Jenom tam tak nějak nepíšou, jestli na provozování takovéto aplikace je potřeba X, nebo ne. Což je dost zásadní informace.
--with-gdktarget=[x11/win32/quartz/directfb] select non-default GDK target
To je fajn, ale v praxi to znamená, že GTK+ na Macu žádná sláva
Neříkal jsem že sláva, ale že to jde.
a na produkční nasazení bych ho nepoužil.
Vždyť Vás k tomu také nikdo nenutí.
Vzhled GTK+ aplikací se pochopitelně dá nastavit, ale... Uživatel chce svůj nativní vzhled, ne nějaký Windows 2000. Dvojnásob to platí na Macu. Natožpak aby přes nějaké klikátko někde musel měnit dodatečně vzhled.
No a právě všichni od toho dávají ruce pryč a nechávají to na uživateli.(Ty výše zmíněné anglické slova nejsou můj výmysl, ale slova právě jednoho z GTK vývojářů se kterým jsem mluvil) A ten zase křičí, že to je starost všech jen ne jeho. Jinak se to dá změnit textově(což je dokonce doporučovaná a oficiální cesta změny GTK+ tématu jinde než v GNOME).
Jinak díky moc za odkazy, jdu si s tím pohrát
Zajímavé. Většinou jsem toto slyšel právě jako nevýhody GTK.
A ještě jedno rýpnutí na závěr: nepíše se MacOS, ale Mac OS X
Pro mě je to Masox. V životě jsem s tím nedělal, viděl jen z rychlíku a tak si myslím, že je docela egal jak to nazývám.
No, uznávám, že výchozí vzhled GTK+ aplikací je dost šilený, avšak že jak vidím, tak to není jednoduché vyřešit tak, aby byli všichni spokojeni. Ale že tam něco je špatně, to vidí holt každý. Nechci tu vyvolávat zbytečný flame o tom, že ten výchozí vzhled je strašný, nebo že celkově Linuxové GUI je dost nedozrálé. V podstatě je mi to i ukradené. Původní zprávička byla o Qt a to si myslím, že se integruje dobře. GTK+ má holt před sebou ještě dlouhou cestu, ale je skvělé vidět, že se na tom pracuje. Na Linuxu je to v pohodě, ale když si budu moc i na Windows nebo Macu vybrat Qt, GTK+ nebo Javu, tak si myslím, že toto už je dobrá konkurence. Protože psát aplikace v Cocoa jinde než na Macu lze bohužel těžko. Ačkoliv, znám člověka, který to dokázal, takže nereálné to není, jenom to chce nějakou tu práci s tím Ostatně, já se Objective-C začal paradoxně učit na Linuxu, když jsem ho ještě používal...
Kompilace přímo pro Quartz je super, bude dobré až bude hotová.
Dobře, pro tebe to je Masox, ale já Linuxu také neříkám Linuxi :-P Ale proč ne, mohl bych začít
22.2.2009 17:30
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
No, uznávám, že výchozí vzhled GTK+ aplikací je dost šilený, avšak že jak vidím, tak to není jednoduché vyřešit tak, aby byli všichni spokojeni.
Je. Donutit vývojáře aby GTK prohrábli vidlemi, nahradili tu odbarvenou parodii na Tango pravým nefalšovaným Tangem (to IHMO vypadá na jakémkoliv Desktopu bombasticky) a do ./confifigure vecpali volbu --theme=PATH kdyby přeci jen byl někdo nespokojen. Pak by sice zase začali křičet uživatelé Windowsů, že každá GTK aplikace vypadá jinak, ale na centralizované verzi GTK knihoven pod okny už se také pracuje (ta už je teda hotová, spíš se na ni musí přizpůsobit aplikace). Ale ať teda jen neosočuju. U Windowsí verze se engine dá změnit náhradou souboru gtkrc v modules/engines/ms-windows/Theme/gtk-2.0. U ostatních systémů se jaksi předpokládá, že jsou víceuživatelské a na UNIXovém základu, takže si to uživatel změní buď přímo klikátkem a nebo právě konfiguračním souborem ve svém domovském adresáři a nebo teda admin v /etc. Ikony se dají změnit v gtk/stock-icons akorát zas používají jinou pojmenovávací konvenci než je tomu zvykem u GTK témat.
Ale že tam něco je špatně, to vidí holt každý. Nechci tu vyvolávat zbytečný flame o tom, že ten výchozí vzhled je strašný
O tom není třeba diskutovat. Ten strašný je.
nebo že celkově Linuxové GUI je dost nedozrálé.
Pozor. Odbarvená parodie na tango + ten hranatý engine != ani zdaleka Linuxovému GUI.
GTK+ má holt před sebou ještě dlouhou cestu, ale je skvělé vidět, že se na tom pracuje.
Furt nechápu o jaké cestě a nebo práci je řeč.
Na Linuxu je to v pohodě, ale když si budu moc i na Windows nebo Macu vybrat Qt, GTK+ nebo Javu, tak si myslím, že toto už je dobrá konkurence.
Vždyť to už klidně můžete učinit teď, akorát budete muset udělat tu práci o které se domníváte, že patří někomu jinému.
22.2.2009 19:56
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
22.2.2009 20:08
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Ty fakt asi nevis o co jde.
Nevím. Jak už jsem říkal, tak jsem nedělal ani s Macem natož s GTK pod Macem. Já spíš reagoval na ten vzhled a upozorňoval, že je v listu oficiálně podporovaných platforem.
GTK proste neni multiplatformni.
Dobře, ale min. je dvou-platformní. UNIX/Linux a Windows. Tím jsem si na 99% jistý.
23.2.2009 16:08
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
