Eclipse IDE je bohužel stále nepoužitelné

28.6.2009 16:33 | Přečteno: 2624× | Software

Potřeboval jsem si napsat malou aplikaci v C++, proto jsem se - vzhledem k nedávným diskusím o vývojových prostředích - rozhodl po mnoha měsících dát příležitost Eclipse IDE, abych zjistil, zda již někdejší problémy nejsou minulostí. Bohužel, nejsou...

V řadě různých diskusí po mnoho měsíců jsem uváděl důvody, proč považuji Eclipse za nepoužitelné IDE, zcela nesrovnatelné s Microsoft Visual Studiem a také pokulhávající za Netbeans IDE. Kromě nevěcných reakcí jsem občas narazil i na ujišťování, že problémy již byly odstraněny a že dnešní Eclipse je mnohem lepší než Eclipse před x měsíci.

Na základě toho jsem nyní podnikl pokus o použití Eclipse s pluginem CDT k vývoji malé aplikace v C++. Bohužel, po pár hodinách použití jsem musel Eclipse odstranit a pokorně se vrátit k Netbeans, kde jsem okamžitě pocítil ten obrovský rozdíl.

Co mi na Eclipse tolik vadilo? Tak především neskutečné problémy při triviální práci se schránkou. Operace Ctrl-C selhala ve cca polovině případů - někdy ve schránce zůstal původní obsah, občas se do ní uložilo něco úplně jiného, než bylo vybráno. Takhle nekraví žádná aplikace, kterou používám - ať už nativní nebo třeba napsaná v Javě. Pravděpodobnost selhání operace rostla s klesajícím časem stisku oné klávesové kombinace, pokud ale byly klávesy stisknuty příliš dlouho, výběr byl nahrazen písmenem "c". Opravdu vypečené chování...

Dále mě nepříjemně překvapila příšerná pomalost Eclipse. Stěžoval jsem si, že prostředí Netbeans ve verzi 6 výrazně zpomalilo, ale stále je nesrovnatelně rychlejší než Eclipse, kde na všechny operace čekám stovky milisekund až sekundy. Celé je to nějak podivně zabržděné.

Na žádné další problémy jsem sice nenarazil (také jsem s tím nic moc nedělal - žádné ladění, žádné mnohasouborové projekty, žádná složitá nastavení), nepočítám-li podivné odsazování při kopírování a vkládání celých strukturovaných bloků (switche apod.). Ale už to uvedené stačilo na to, aby mě toto IDE dokonalo otrávilo.

Je možné, že to nějak souvisí s konkrétním systémem (distribucí) nebo s konkrétní Javou. Testoval jsem to v distribuci openSUSE 11.1 s Javou 1.6.0_13, takže je klidně možné, že jinde pojede jinak. Ale vzhledem k tomu, že jiné aplikace fungují bez problémů, moc bych za to nedal.

       

Komentáře

[Algi]

Tak to je opravdu zvláštní. Může to být pomalým počítačem, to můžu potvrdit že pak jak Eclipse tak i NetBeans se občas krapet zaseknou. Ale aby mi nefungovala schránka, nebo aby operace takhle trvali, s tím jsem se na svém (nikoliv pracovním) stroji nesetkal. Krom toho, že schránka mi funguje vždy. To spíš v iReportu občas blbne, že dám pouze jednou zkopírovat a ono se nic nestane... Ale to mi dělá pouze Java na Windows. Moc ti to nezávidím, protože používat Javu na Linuxu je občas docela za trest...

[Luk]

Může to být pomalým počítačem

To může, ale Core2Duo@2,66 s 2 GB paměti zase až taková vykopávka není

Krom toho, že schránka mi funguje vždy.

Možná je to problém distribuce (knihoven X nebo co já vím...), protože co si vzpomínám, tak nějaké takové problémy jsem míval s Eclipsem už kdysi, na jiném stroji, s jinou verzí Eclipsu, s jinou verzí openSUSE. Ale žádná jiná aplikace takhle neblbla.

Moc ti to nezávidím, protože používat Javu na Linuxu je občas docela za trest...

Obecně s Javou problémy nemám. Netbeans, jEdit a další programy chodí zcela bez problémů.

[Jardík]

Jedinej systém, kde je GUI v javě označitelné za né moc pomalé, je MacOS X ... ve Windows to pak tak nějak dře, ale taky se to dá, ale v Linuxu, to je pomalej děs.

[Algi]

Záleží na tom, jaký Look and Feel použiješ. Pokud necháš ten systémový, pak je vykreslování stejně rychlé jako u nativních aplikací. Pokud nastavíš nějaký jiný, použije se vykreslování od Sunu a to je pomalé. A pokud navíc nastavíš i vlastní dekorace okna, pak je překreslování naprosto tragické.

[Jardík]

Pokud necháš ten systémový, pak je vykreslování stejně rychlé jako u nativních aplikací.

Mám přesně opačnou zkušenost. Ve Windows je rychlý jak Metal, tak Windows L&F. V MacOS jsem zkoušel jen nativní, byl rychlý. V Linuxu je GTK L&F nehorázně pomalý, bugový (např. špatně kreslené a nenativně fungující widgety) a nerespektuje některá nastavení GTK. Za to Metal tam běhá o mnoho rychleji, ale stále to nemá na ostatní zmíněné platformy.

[Algi]

 

Mám přesně opačnou zkušenost.

Počkej, to jsi mě špatně pochopil Já tím myslel, že pokud na Mac OS X necháš systémový (Aqua) L&F, pak je vykreslování stejně rychlé jako u nativních aplikací. Řekl bych, že se používají přímo nativní komponenty a nekreslí to Java. Ale ruku bych za to do ohně nedal, tak dobře Javu od Applu zase neznám. Jinak vykreslování nativního L&F jinde jsem moc nezkoušel...

Jinak GTK L&F není bohužel moc dobře udělaný - záleží na vzhledu, který máš v Gnome nastavený. Některé vzhledy (jako např. výchozí Ubuntu) pracují s Javou dobře, některé holt hůře... To už je holt daň za svobodu.

 

[=^..^= AmigaPower®]

Vsadil bych si na tu Javu, válčil jsem se strašnou spoustou verzí a nakonec jsem si nechal (pro mně a pro to co já používám) nejmíň problémovou 1.6.0

[=^..^= AmigaPower®]

...přesně je to: 1.6.0_02-b05

[Jakub Lucký]

sice nedělám s CDT, ale občas s Epic a PyDev, ale podobných problémů jsem si ještě nevšiml...

[User682]

zdravim,

Eclipse CDT jsem pred par dny pouzival. Pred par dny se mi podarilo dostat abiword do eclipse  CDT.

Pady aplikace nejsou. Co se tyce rychlosti neni problem ani tak na strane Eclipse. Problem je spise v tom v buildech. Zde bude asi nejaka mezera.

Specielne na Dual-Core procesoru to jiz leta. Osobne pouzivam 3GHz jednoprocessor.

Ale i tak by stalo za to par veci vylepsit. Dokonale to neni.

Osobne tedy spise pouzivam IDE, kvuli vlastnostem a ne kvuli rychlosti. Mimojine, jakou verzi Eclipse pouzivate ?

Pisete o pomalosti ? Co si pod tim ma clovek predstavit ? To pise dneska o vecech skoro kazdy . Je to modni. Zatimco v podobne rychlem .NET to je casto naprosto OK.

Na adresu Visual Studia - zkusenosti jsou - pouze dodam to, ze ma mnoho uzasnych vlastnosti a celkove to nikdo nedotahl do konce, tak aby chodily zakladni veci a daly se beznym zpusobem pouzivat. Aneb klasicke Microsoft-i - udelame to jinak.... bude inovace.

Proto radeji pouzivam Eclipse. Umi mene, ale lepe.

 Chapu, ze jste si zrovna ulevil blogem jaky je Eclipse srot, ale chtelo by to dopsat nejake detaily.

[Luk]

jakou verzi Eclipse pouzivate ?

Verze 3.4 (číslo buildu neznám, už jsem to odinstaloval - verze openSUSE balíčku je 3.4-6.2).

Pisete o pomalosti ? Co si pod tim ma clovek predstavit ?

Snad jsem to popsal dostatečně, ne? Prostě je to subjektivně pomalé, se stopkami v ruce jsem to neměřil. Když třeba přepnu taby s otevřenými soubory, reaguje to zřetelně pomalu, kdežto třeba Netbeans má tu reakci prakticky okamžitou. Totéž třeba vkládání ze schránky, chvíli se nic neděje, pak se kód vloží, ale okolní kód se posune až o pár stovek milisekund později.

[User682]

zdravim,

tak neco na tom pravdy bude. Nainstaloval jsem si cvicne 3.5.0 Eclipse (Eclipse for RCP/Plug-in Developers) a line to tedy je. Asi by se s tim dalo zit. Osobne verim spise versim x.1 a vyse.

Jinak tu k primerene (optimalni[mohlo by to byt lepsi]) spokojenosti mam tuto versi ohledne CDT.

Version: 3.4.2
Build id: M20090211-1700

Jinak na Eclipse Classic take 3.4.2 jsem od obeda psal linuxsoft a zadne problemy. Relativne dost svizne na 3Ghz Intel CPU. Obsazena pamet IDE tak do 150-200MB.

 

 

 

[User682]

jeste info: java -version

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
 

[=^..^= AmigaPower®]

...no a se starší javou?

[Daniel Kvasnička ml.]

Zakladni pravidlo pri pouzivani Eclipse v Linuxu, bez jehoz dodrzeni se nema cenu dal bavit, je: nikdy nepouzivej Eclipse balicky z distribucnich repos, vzdycky stahuj oficialni bundly z eclipse.org ...

[Luk]

vzdycky stahuj oficialni bundly z eclipse.org

To jsem už kupodivu udělal (tolik jsem chtěl dát Eclipsu šanci) a bylo to úplně stejné. Pravda, nevyzkoušel jsem úplně čerstvou verzi 3.5, takže až budu mít čas a náladu, učiním ještě jeden pokus a pak dám do blogpostu update, jak to dopadlo.

[kralyk z abclinuxu]

No však se podle toho to IDE jmenuje: Eclipse

[kralyk z abclinuxu]

Já používám Code::Blocks, je to spíš editor + build system než plně nadupané IDE, je takové hodně lightweight, ale dobře se mi integruje s pspsdk apod. Občas mi trochu vadí nedokonalé napovídání.
Asi vyzkouším to NetBeans, na které všichni pějou ódy...
Na projekty v Qt pak používám zásadně Qt Creator, ten je skvělej...

Co se týče toho HW, tak tím to fakt není - mám Core2Duo na 3GHz + 4GB RAM a stejně bylo Eclipse dost zasekaný...

[stativ]

Eclipse také nemám rád, ale musím se ho zastat v neprospěch netbeans. Problémy s kopírováním jsem v Eclipse neměl. Pomalé je, to souhlasím. Ale ta pomalost, kterou předvádí NetBeans je extrémní. Pravda, nemám super nadupaný počítač, ale když mi eclipse zvládne naimportovat projekt za max minutu a NetBeans to trvá skoro deset minut (pak mi došly nervy a NetBeans jsem „odstřelil“, bohužel se to opakovalo) tak je někde něco špatně. Osobně mám nejradši kdevelop 4. Občas* je znát, že je ještě ve vývoji, ale funguje dobře.

* narazil jsem na jeden bug, který jsem tedy popravdě ještě neměl čas reportovat ale chystám se. Občas když použiji u subversion volbu "compare to base" tak vypnutí kdevelopu způsobí pád. Naštěstí je to až při vypínání a jen občas, takže člověk může mezitím pár hodin pracovat bez sebemenších problémů. Ale nutnost pokaždé odklepnout okénko hlásící pád po vypnutí je nahouby.

[Deleted [8409]]

KDevelop 4? Není to tak dávno, co jsem ho zkoušel, padalo to při běžné editaci zdrojáků, něšlo ladit, nemohl jsem se s tím vůbec domluvit... Vím, že to je beta, ostrá verze bude stát podle mě za to, ale nyní bych se neodvážil v tom pracovat.

[stativ]

Tak mě padal při editaci u nějaké bety dva. Nyní používám svn verzi a nepadá. Pravda je, že oficiální tarbally se nejspíš trochu liší, protože u bety 3 zřejmě nebyl CMake plugin, který v svn byl. Jak je na tom s debugováním netuším, ale když se člověk mrkne do logu, tak to vypadá, že většina commitů se týká zrovna debugování. Já si vystačím s command line gdb a když už chci něco opravdu pohodlného, použiju ddd.

[Deleted [8409]]

Já ho mám v gentoo, takže snad celkem aktuální, ale fakt se v tom nedalo pracovat. Ale musím uznat to, že to bylo fakt rychlé (okanžité reakce, načítání souborů, ...).

[Honza Jaroš]

Problémy se schránkou v Eclipse se mi už asi před rokem podařilo vyřešit výměnou Glipperu za Parcellite. S Glipperem si to nějak nerozumělo, s Parcellite problémy nemám...

[Honza Jaroš]

Nicméně doplním, že Eclipse používám v již poněkud obstarožní verzi 3.3.2. Jak je tomu u novějších verzí netuším.

[Luk]

Zaprvé Glipper nepoužívám (používám KDE a tedy Klipper), zadruhé mi není jasné, proč by to spolu mělo souviset. Do běžné práce se schránkou (X Selections) snad tyto programy nezasahují, nebo ano? Měl jsem za to, že pouze umožňují pracovat s historií schránky, klasické copy/paste nechávají na pokoji...

[Honza Jaroš]

Mám pocit, že se cpou i do klasického copy/paste. Ale podrobnosti po mně nechtějte, prostě co jsem přešel z KDE na Gnome, měl jsem tyto problémy. Pak jsem kdesi narazil na radu zaměnit tyhle dva clippboard managery, že problémy způsobuje Glipper. Udělal jsem to a problémy skutečně zmizely (a při pokusu o návrat ke Glipperu se zase vrátily, takže jsem ho nakonec ze systému vykopal úplně). Víc jsem po tom nepátral, prostě mi to chodí a to je pro mně hlavní...

[Nikola Ciprich]

klipper a podobne kramy pro praci se schrankou prave ty problemy se schrankou zpusobuji, vim ze to mrvi i schranku v lotus notes (ktere prave take pouzivaji SWT)

[xm]

Tyhle "krámy" jako Klipper jsou naprosto úžasná věc, bez které si nedovedu pořádně představit práci. Žádné normální programy (Qt / Gtk) s nimi nemají sebemenší problém, na vině jsou tedy špatně napsané Java aplikace.

[Honza Jaroš]

No já mám pocit, že jsem s Glipperem měl tehdy podobný problém i v případě Firefoxu, ale ruku do ohně bych za to nedal. Parcellite mi pro změnu odmítá kopírovat adresáře při připojení přes rdesktop na windowsové servery (v Exploreru Ctrl+C a Ctrl+V), ale to mi nijak zvlášť žíly netrhá a jinak funguje spolehlivě...

[Algi]

Otázkou je, jestli je to vina Sunu (že si nedokáže poradit s Linuxem) nebo Linuxu (že na něm jsou programy co se starají o schránku a neumí komunikovat s Javou). Do Sunovské implementace nevidím, ale velmi bych pochyboval, že bude problém zrovna v Java aplikaci. Ta přebírá a zpracovává schránku standardním, na platformě nezávislým způsobem. To že si s tím nemusí správně poradit JRE je už jiné kafe. Vzpomenu třebas Esmsku, která na Macu v pohodě zpracovávala drag&drop operace a na Linuxu to musel Kamil speciálně ošetřit, aby získávala správna DataFlavor. Bugy jsou všude, nejen v Javě

[rastos]

Zaprvé Glipper nepoužívám (používám KDE a tedy Klipper)

Open Klipper configuration dialog and uncheck ‘Prevent empty clipboard‘ in Klipper’s settings.

[Luk]

Hmmm, zajímavé. Díky!

[dad]

rad bych se zeptal, jak dlouho je potreba, nez se clovek nauci rozumne ovladata to IDE?

[Luk]

To nevím. U Eclipsu zjevně dlouho. MS VS jsem se naučil vcelku obstojně za pár dní, Netbeans taky dost rychle, Eclipse neumím pořádně dodnes, přestože jsem v něm dělal (cca 8-16 hodin týdně) zhruba 2 roky.

[dad]

...MS VS jsem se naučil vcelku obstojně za pár dní ...

a tomu bych veril, vlastne ani nevim, co je na tom za uceni na nekolik dnu? Problem bude asi ve slove 'naucit'. Ja si pod tim predstavuji, doblecliknu na nejaky projektovy soubor a objevi se projekt, kde jsou vlevo nejak zobrazene soubory a ve zbytku je nekolik editacnich okenek. Pak nekde najdu menu/button pro prelozeni souboru, nejake knihovny nebo celeho projektu.  A pak tam nekde bude debug, v nejakem zdrojaku 'nejak' oznacim brakpoint a event. musim jeste najit tech par okenek pro vypis promenych a probehlych funkci. Tohle se prece vysvetli nekomu za 1/2 hodiny a muze zacit delat. A jak pisete, za 2 dny to ovlada poslepu.

Co je na te Eclipse jineho?

[Luk]

Tím "několik dnů" pro MSVS jsem měl na mysli to, že jsem v tom plnohodnotně (tj. nejen samotný vývoj, ale i grafický návrh GUI pro MFC a další podobné věci) pracoval bez přemýšlení, jak udělat to či ono. Prostě vysloveně intuitivní práci. To Eclipse nezvládám dodnes, pořád musím o všem přemýšlet. Tím spíš, že věci jako výpisy proměnných při ladění tam docela zlobily (já vím, to je problém CDT a ne Eclipsu jako takového...).

[dad]

ok, tak ted je to jasny.

Presto je to zvlastni, jak Vas tak pan Kysilku mam zarazene jako zkusene vyvojare a jak jste si vsimnul, pan Kysilka si to docela vychvaluje, zatimco jini tomu nemohou prijit na jmeno. Tady neco nehraje.

[Luk]

Tady neco nehraje.

To je (nejen) v IT normální Různí lidé používají stejné nástroje v různém prostředí, k různým účelům a hlavně každý trochu jinak přemýšlí. Když použiju své oblíbené přirovnání k autům, stejné auto je pro někoho plečka (která je víc v servisu než na silnici, špatně se řídí, je nepohodlná...) a jiný na něj nedá dopustit.

[kralyk z abclinuxu]

U MSVS, které jsem byl párkrát okolnostmi nucen použít, mě dycky hrozně rozčilovalo to nastavení. Člověk se musí jak blázen proklikat neuvěřitelným grafickým dialogem kdykoli chce přidat třeba nějakou statickou knihovnu apod...

[Luk]

Řekl bych, že zrovna tohle je srovnatelně složité v MSVS, Eclipse i Netbeans.

[kralyk z abclinuxu]

Upřímně, v Code::Blocks to není zas o moc lepší, když nad tím teď přemýšlím (ikdyž o něco jo), ale já tam dám většinou custom makefile a je vyřešíno...

V tomhle ohledu je docela fajn .pro soubory, který používá qt/qmake a Qt Creator. Přehledné, snadná editace, takle bych si to představoval...

[Miloslav Ponkrác]

U Eclipse mnohem déle, než u jiných IDE.

[User682]

zdravim,

pocitejte pri dennodennim pouzivani prvni tyden krusny a vse Vam jde pomalu.

Za mesic uz nejak prijatelne Eclipse IDE pouzivate. Za dalsi mesic uz to svisti.

Alespon tak moje praxe. Ucim se nektere veci velmi pomalu.

To ALL: Jinak celkove zajimava diskuze - Eclipse IDE, javova prostredi a funkcnost na linuxu bych probral zitra. Dnes nemam cas.

Zitra zkusim prihodit par zkusenosti a par veci ohledne javy a Linuxu z pohledu desktopovych prostredi(sam delam desktopove aplikace a komponenty). Jde o to, ze __casto__ je problem na strane linuxu.

gf

[Daniel Kvasnička ml.]

No musim se pridat k tem, kteri nevi o cem mluvis ... Pouzivam Eclipse kazdy den hodiny, je to muj hlavni pracovni nastroj a problemy se schrankou jsem nemel a pomalejsi jsou z meho pohledu NetBeansy Nadpis tveho blogpostu je silne zavadejici. Spis nadavej na autory CDT... a neprovozujes to uplnou nahodou na nejake z tech pokusnych free implementaci JVM, ze ne..?

[Luk]

Spis nadavej na autory CDT...

CDT na tom může mít vinu, ale pochybuji, že popisované problémy budou kompletně způsobovány CDT. Do chování schránky by snad neměl zasahovat, ne?

neprovozujes to uplnou nahodou na nejake z tech pokusnych free implementaci JVM, ze ne..?

Samozřejmě, že ne. Je to plnohodnotná Java od Sunu. Už kvůli bankovnictví KB tam ty pokusné hračky mít nechci.

[xm]

Bankovnictví od KB mi s OpenJDK funguje výborně. OpenJDK bych rozhodně za pokusnou hračku neoznačoval.

[Daniel Kvasnička ml.]

To jsem tim ani nemyslel, spis GNU Classpath a tak... OpenJDK je na urovni runtime plne kompatibilni s oficialni javou, pokud vim.

[Luk]

I když nejsem si jist, že je tam úplně všechno (všechny knihovny). Původně zcela jistě ne, jak ostatně Sun kdysi deklaroval.

[xm]

Pokud vím, tak všechny části, které nemohly být opensourcovány (původně to bylo asi 4% kódu jestli se nepletu), již byly nahrazeny. V OpenJDK 6 to podle Wikipedie bylo už jen méně než 1% (chyběla pouze SNMP implementace). Přičemž některé chybějící části byly nahrazeny částmi z GNU Classpath v rámci Red Hat projektu IcedTea a OpenJDK/IcedTea 6 prošlo už v červnu 2008 Java TCK testy a je to tedy oficiálně plně kompatibilní Java 6 implementace.

[xm]

Abych to ještě upřesnil, tak tady je výtah z článku o IcedTea na Wikipedii:

The second task was to provide Free equivalents of the binary plugins that existed in OpenJDK because Sun was unable to release all the source code. As of March 2008, this is no longer necessary for IcedTea6, as the OpenJDK6 build drops can be built with no binary plugins. With the release of b10 [17], which replaces the proprietary sound support with that from the Gervill project, a full implementation of Java 1.6 can be built without binary plugins. The only remaining binary plugin is for SNMP support, which is an optional provider for the JMX architecture and not part of the specification.

[Luk]

Díky za info, moc jsem to teď nesledoval. Každopádně ale zatím zůstávám u původní Javy, nijak mi její licence nepřekáží.

[Pavel Stárek]

Ono ani tak nejde (většinou) o licenci, mě spíš štve, že někteří lidé neustále odrazují jiné lidi od používání OpenJDK, které je normální free kompatibilní alternativou k jdk od Sunu a prošlo TCK testy. On ten Red Hat ty peníze do toho nelije zbytečně.

[Ladicek]

To nebude trvat dlouho, pokud vím, od verze 7 bude Sun JDK = OpenJDK.

[tomm]

Jo, problem se schrankou je domena verze 3.4 (Europa). Kdyz se mi to stavalo, tak jsem nejdriv myslel, ze je to problem pluginu pro vyvoj v Grails, ale kolegam i potvrdil, ze mu to dela i u cistych javovych zdrojaku. Problem se vyskytoval hlavne pri kopirovani vice radku najednou, kde chybel posledni radek.

Minuly tyden vysla nova majoritni verze a kolega hlasi, ze je vse zase bajecne Jenze ja kvuli Grails stacim mezitim prejit na NetBenas, kde je plugin pro vyvoj v Grails o nekolik milovych kroku vepredu. A navic v NetBeans velmi pekne funguje Vim editor (jVim), coz se o Eclipse rict neda. Na druhou stranu fatalni Eclipsovska editacni komba jsou killer feature a obcas mi chybi.

[Luk]

Jo, problem se schrankou je domena verze 3.4 (Europa).

Zkusím verzi 3.5 (viz výše), třeba už to bude opraveno. Ale co si vzpomínám, dělaly to i dřívější verze než 3.4.

[AHAHA]

Mozna je to trochu mimo misu, ale pro PHP jednoznacne doporucuji Netbeans, subjektivne se mi zda znacne chytrejsi (naseptavac, parsovani kodu) a rychlejsi nez Eclipse (zkousel jsem jen Eclipse 3.4 s PDT 2.0).

[default]

Hele, vyšly NetBeans 6.7. Doufám, že ten release definitivně vyřeší otázku Eclipse vs. NetBeans. Prý je tam podpora i pro Qt a mnoho dalšího…

[Icek]

JJ, vcera sem to zkousel, podpora QT je tam opravdu velice prijemna... sice me teda prijde lehce pomalejsi nez eclipse, naseptavac taky neni tak dobry, ale celkove mi to prijde na c++ privetivejsi nez Eclipse/CDT

[default]

Škoda, že v C/C++ nic nedělám. Vlastně už nedělám ani v tý Javě. Naposledy jsem dělal v Javě někdy před rokem. To jsem dělal nějaký webový služby v 6.5.1 (možná 6.5.0). A byla to pěkná pakárna. Poslední použitelný kus kódu jsem udělal v 5.5 nightly buildu.

Obecně se mi 5.5 líbily vůbec nejvíc. 6.5.0 byly pomalý a plný bugů. 6.5.1 byly rychlejší a stabilnější. Ale jedna věc mi na nich neskutečně s*ala: porád mi ty svině vnucovaly nějaký RESTfull support for web services či co. U toho jsem fakt tekl. Permanentně rozm*danej build systém, díky kolizi knihoven nefungoval deploy, bordel v SubVersion…

Tak ani nevím, jestli se mám obtěžovat s downloadem a ten krám instalovat.

A co se Eclipse týče, tam jsem po půl dni nebyl schopnej naimportovat projekt s hotovým Antím build.xml. V NetBeansech je to na dva kliky a prostě to funguje.

Jak tady má Kotyz v patičce "technický pokrok šetří váš rozkrok" — no nevím. Ču*ák mě bolí ještě teď.

[Algi]

Kdybys nepoužíval svůj rozkrok k importu projektů do Eclipse, měl bys ho rychleji Ale je pravda, že teď se cítím jako pěkná bábovka, že dělám importy pomocí New -> Java Project from Existing Ant Buildfile. Svůj ocas bych totiž na tuhle operaci nenasadil

[default]

Kdybys nepoužíval svůj rozkrok k importu projektů do Eclipse, měl bys ho rychleji

Neměl. Vůbec se mi to totiž nepovedlo. Takhle: povedlo. Ale Eclipse volal naprosto nesmyslný targety přestože klikátko ukazovalo korektní hodnoty.

Ale je pravda, že teď se cítím jako pěkná bábovka, že dělám importy pomocí New -> Java Project from Existing Ant Buildfile.

Takhle jsem to dělal v NetBeans taky. A vždy to šlo na první pokus. Takže jsem býval taky bábovka.

Svůj ocas bych totiž na tuhle operaci nenasadil

To byla spíš taková metafora. Myslel jsem to obecně, ne jen na ten import.

[default]

Jo, a jak jsi se kdysi ptal na to skrývací tlačítko toho toolbaru, tak jsem tak trošku investigoval a došel jsem k závěru, že to chce následující pokus:

Každá aplikace by měla mít instanci objektu NSApplication. NSApp obsahuje odkaz na tu instanci. A NSApplication umí vylistovat okna aplikace. Takže: jestliže NSApp není nil, pak je polovina úspěchu. Ta druhá závisí na tom, zda Java registruje okna správně do NSApplication.

Takže bych to viděl na jednoduché JNI volání, které by jen našlo správné okno a nastavilo mu tu vlastnost. Za předpokladu, že to funguje podle domněnky nahoře.

Omlouvám se, že jsem to sám nezkusil, ale nechce se mi kvůli tomu učit Java, C a Objective-C.

[Algi]

Už si přesně nevzpomínám, ale tuším že to registruje vcelku dobrým způsobem a rozhodně pro mě nebyl problém si to "své okno" najít. Akorát tam bylo jedno navíc

Večer se na to podívám, ačkoliv přesně nevím jestli to k něčemu bude. Zobrazit toolbar je jednoduché, ale pouze samotné tlačítko bez NSToolbar... Uvidím

[default]

A děláš to přes NSApplication v JNI? Ještě jsem se díval do com.apple.* balíků. Tam byla spousta zajímavých věcí, ale tohle prostě ne.

[Algi]

Jinak než přes JNI jsem to ani nezkoušel :-) Vzhledem k tomu, jak Apple velmi rád mění privátní package (viz poslední Update 4). Naivní řešení vypadá v podstatě takto:

void showToolbarButtons ()
{
  NSArray *windows = [[NSApplication sharedApplication] windows];

  for (NSWindow *i in windows)
  {
    [i setShowsToolbarButton: YES];
  }
}

Jinak vložit sem kód ze Safari je nadlidský úkon. Nakonec jsem musel použít Firefox

[default]

Jinak vložit sem kód ze Safari je nadlidský úkon. Nakonec jsem musel použít Firefox

JoJo, zvlášť z Xcode. Ale naštěstí stačí klepnout na Zdroj a vložit to přímo do zdrojáče.

[default]

Zobrazit toolbar je jednoduché, ale pouze samotné tlačítko bez NSToolbar...

To se mi nepovedlo. Když zavolám

    [theWindow setShowsToolbarButton:YES];

a toolbar nenastavím, tak se tlačítko nezobrazí. Je to i v dokumentaci, že tohle volání má smysl jen když existuje Toolbar…

[Algi]

Přesně tak a v tom je právě ten problém. Jde totiž o to, že já bych rád měl jenom to tlačítko a registroval v něm to kliknutí. Získat si notifikace o kliknutí podle mě nebude problém, někde jsem to už viděl. Ale když chci (nebo spíš musím) použít JToolbar namísto NSToolbar, tak nemám moc šanci to tlačítko zobrazit. No a kvízová otázka je: jak to hacknout pomocí nezdokumentovaných funkcí, aby se to tlačítko zobrazilo, i když není NSToolbar?

[Pavel Kysilka (goldenfish)]

zdravim,

v diskusi se rozebiraly chyby Eclipse, Javy a Linuxu. Neco pridam. Nehodlam polemizovat o pravdivosti. Nemam ani cas a naladu dohledavat presne detaily, spise predam letite zkusenosti.

 

Chyby a nedostatky Eclipse, s kterymi jsem se setkal:

- Clipboard - vyjimecne jsem to snad jednou/parkrat videl u nejake aplikace postavene nad eclipsem

- ClipBoard - nekdy se neprekopiruje neco pres prave tlacitko mysi.

- Eclipse PDT - par pri otevreni sablon - XTemplate - html (nekdy to chce vyreportovat) - XUL runner

- az prilis velka pomalost - nekdy. Hodne je to videt pri maximalizaci oken.

-  s volbou do konsole export _JAVA_OPTIONS='-Dsun.java2d.opengl=true' - 2D chodi o neco svizneji.

- formatovni zdrojaku nabori odrakovany zakomentovany kod - opraveno

- SWT tabulka s tisici zaznamy - rychle,svizne - ale Xorg zere 60-80% vykonu. Java do 20%. Ono celkove nejvice je problem Xorg.

- neviditelna menu - tohle snad v poslednich 1.6 verzich opravili.

- tisk - ten snad uz jede z SWT

- obcas pomale tabulky s vlastnimi slozitejsim renderery

- nedodate -li layout do komponenty , tak se nic nevykresli. To je ale vlastnost.

- nektere veci z SWT chodi na Linuxu lepe nez na Windows. Tak 70%. Ladit pro okna je obcas porod, aby to vypadalo rozumne. Specielne layouty, velikosti komponent. Naopak na Windows je 2D akcelerace rychlejsi oproti Linuxu v realnych aplikacich. SWT 3.4.2, co jsem zkousel.

Postrehy a poznamky:

- Na graficke vrstve se udelal za posledni roky v jave velky pokrok. Specielne na Linuxu, pokud take ctete zmeny u verzi Javy/SWT.

- Dost prace ale jeste chybi. Ono celkove je nejaky graficky subsystem velky problem a nikomu se do toho moc nechce. V bugzillach toho hnije mraky.

- Lidi, co vidi hloubeji do grafiky/gui, je velmi malo a nikdo je nevychovava. Kdyz jsou, tak nejsou moc oceneni [moje praxe].

- Oproti .NET platforme v grafice lepsi prace. Lepsi funkcnost, delate -li vice do hloubky. Tak casto neslozite aplikaci s nic nerikajici vyjimkou do Windows. Nebo  se Vam nestane, ze vsechno chodi, i kdyz je to blbe. Nedodelane modely [binding].

- Java je podle me velkou sanci pro linux. Mozna byla. Lepsi nez C-eckove veci. Tohle ale dav nepochopi. .NET nebude nikdy dodelany. .NET bude vzdy Microsoftem az prilis olepsovan, coz je jedna z jeho chyb. C-ckove veci jsou neefektivni a nejsou tak komplexni [hotove] jako java.

- velky problem je v implementaci HW akcelerace. Chybi treba gradienty a jine 3D veci, ktere graficke karty jiz nabizi desitku let a drti se to procesorem (CPU). Neco se dela, ale nez to proroste od ovladacu pres knihovny do aplikaci, tak to bude jeste nejaky cas [2 roky] trvat. Ono nez lidi zacnou nadavat na javu, co se tyce rychlosti, tak at si nejdrive pusti top/htop. Mozna, ze se budou divit.

- Eclipse prostredi se nemusi lidem libit. Nemusi se hodne lidem libit. Jenomze Eclipse neni jen IDE. Je to mraky pluginu a frameworku[uz aby to nekdo zmedializoval - s usmevem.....]. A to, ze se neco pomaleji prekresli na poslednich mistech v pomeru k funkcionalite - podle mych meritek.

- Psani GUI neni tak jednoduche jako namatlat kus kodu v html.

Asi vse. A pak nema clovek stihat psat u sebe blogy.....

 

[Algi]

- Lidi, co vidi hloubeji do grafiky/gui, je velmi malo a nikdo je nevychovava. Kdyz jsou, tak nejsou moc oceneni [moje praxe].

- Psani GUI neni tak jednoduche jako namatlat kus kodu v html.

Nevím jak je tomu na Linuxu, dlouho už jsem ho nespustil, natož pak Java aplikaci v něm. Ale přidám pohled ze své strany, tzn. z Mac OS X. Tam čistě osobně dělím Java aplikace do dvou skupin: naprosto příšerné a dobře udělané. Ta první skupina má bohužel 90%.

Příkladem dobře udělaného GUI je například muCommander. Zmínil bych asi i Esmsku, ale to by byla (z části) samochvála, takže to bohužel musím nechat na ostatních. Příkladů by se dalo najít víc, ale všechny mají jedno společné: alespoň jeden z programátorů používá Mac. Jistě, člověk co nikdy Mac neviděl pro něj těžko může vyladit GUI (obzvlášť když ani nevlastní ten stroj). Ale i tak mi přijde, že tihle lidé na GUI v Javě více dbají. Ale může to být pouze můj omezený pohled na věc.

Zbytek vašeho postu nemohu posoudit, Java na Linuxu mě trápila před dvěma roky a proto jsem si pořídil Mac. Pochybuju, že by od té doby udělal Sun alespoň z části tak dobrou integraci jako Apple. Opět nic ve zlém, ale postoj Sunu k Linuxu je fakt zvláštní. Už jenom ten jejich Java App Store, nebo JavaFX. Ze začátku je funkční pouze pro Windows a Mac OS X. Na jednu stranu dělá Sun, že Apple nezná, na druhou stranu se vzájemně podporují. Sun má svůj operační systém, ale chvílema mi přijde, jako by se za něj styděl. Screenshoty v návodech pro Javu jsou totiž z Windows