CLion - C/C++ IDE a JetBrainstől

Meglepődve tapasztaltam, hogy a JetBrains szép csendben kiaraszolt egy C/C++ IDE-vel (egyelőre még csak EAP állapotban van), és a képek alapján igéretesnek tűnik. Lehet, hogy a hétvégén körbetesztelem majd egy picit...

Főbb jellemzők:
- GCC/G++ és CLang támogatás
- MinGW/Cygwin támogatás Windows platformon
- Windows / Linux / OS X támogatás (gondolom BSD-n is fut)
- CMake alapú projektek (autoconf/Makefile támogatás még nincs)
- Beépítetten tartalmaz kitesztelt GDB (7.8) és CMake (2.8.12.2) binárisokat

Letöltés: [ Linux | Windows Installer | Windows ZIP | OS X DMG ]

Linkek: [ JetBrains - CLion főoldal | 1.0 Roadmap | QuickStart guide ]

( wachag | 2014. 09. 22., h – 16:17 )

Jók lennének ezek az IntelliJ-s dolgok, csak engem rettenetesen zavar, hogy nem a natív widgeteket használja Linux alatt... Jó lenne már végre elfelejteni az AWT-t, Swing-et, és helyette natív toolkitet használni... (pl. SWT).

Azert Linuxon elegge nem definialt a "nativ widget" fogalma, ugyanis maga az X11 nem tartalmaz widgetkeszletet.
Az egyes DE-k pedig mas-mas widgetkeszletet hasznalnanak.
Az SWT is csak par nem-Javas (hivjuk igy a nativ widgeteket) toolkitet tamogat.
Linuxhoz csak a GTK-hoz letezik support.
Igy pl. KDE alatt nem neznek ki jol a widgetek.

Amit a köznép Linuxnak hív, azok GNU/Linux disztribúciók: Linux kernel, GNU eszközök és csomó más opensource szoftver, a legtöbbnek semmi köze a GNU projekthez. Van, ahol bizony nem a GNOME a default desktop env, sőt egyáltalán nem GTK alapú a desktop env.

A GNOME nem a GNU Project által fejlesztett környezet. A GNOME-ot a The Gnome Project készíti, a GNOME Foundation szárnyai alatt.
http://www.gnome.org/about/

Érdekes, hogy a GNU Project szerint a gnome az része a GNU-nak (http://www.gnu.org/software/) azonban a Free Software Directory szerint nem:
http://directory.fsf.org/wiki/GNU
Viszont a GNU oldalán az szerepel, hogy a teljes csomaglista a FSF oldalán található (azaz az utóbbi link elvileg helyes):
http://www.gnu.org/philosophy/categories.html#GNUsoftware
" also, the Free Software Directory identifies all GNU packages."

Van logika hozzá, csak nem ennyire trükkös.

Egyszerűen meg kell nézni, hogy ki mit támogat milyen módon. A Qt sokáig nem volt LGPL, így alapvetően két csoport használta a Qt-t:
1) KDE és háza tája
2) Drága, fizetős multi-platform GUI alkalmazások
Később az LGPL-nek köszönhetően megjelenhetett egy harmadik:
3) Ingyenes vagy olcsó multi-platform GUI

Érdemes megnézni, hogy ki fáradozik inkább a másikkal való kompatibilitáson:
- Qt törekszik a natív megjelenítésre minden platformon (Windows, Mac OS X, Linux = GTK+). Igen, Qt-szinten meg van oldva, hogy a Qt-s programok úgy jelenjenek meg Linux alatt mint egy GTK+-s program.
- A Javás SWT-nek szintén GTK-s backend-je van a Linuxra.
- Megint csak a KDE-sek fáradoznak azon, hogy a GTK+-s programok illeszkedjenek megjelenésben a KDE-s programok közé, nem pedig a GTK+-s arcok gyúrnak arra, hogy a KDE platform "támogatott" legyen.

Sok nagy alkalmazás, vagy kereskedelmi program Linuxos verziója GTK+-s, pl. LibreOffice, Firefox, GIMP, Opera, Chrome. Akad Qt-s is, főleg multi-platform GUI miatt, pl. VirtualBox. Érdekesség, hogy az Opera például Qt-ről váltott GTK+-ra nem rég.

Ha mint platformot nézzük, megint csak a GNOME erősebben támogatott, mint KDE. A főbb desktop disztribúciók alapvetően GNOME platformra épülő GUI-val jönnek (GNOME, Unity, Cinnamon - ezek mind a GNOME infrastruktúrájára épülnek). A "Linux desktop" jellegű innovációknak is a GNOME az elsődleges platformja, gondoljunk pl.
- a NetworkManagerre, ami eredetileg GNOME-ra volt elérhető, később KDE-s UI-t is fabrikáltak hozzá a KDE-s arcok.
- az automount fejlesztésekre. Az XFCE-sek nyavajogtak kicsit, hogy de a HAL az BSD-n is megy, de aztán végül csak benyelték a udev/udisk/upower mittudoménmit.
- arra, hogy a Linux-specifikus systemd függés is GNOME-ban jelent meg először.
De így van ez egy csomó infrastrukturális komponenssel, hogy GNOME-ban debütál, majd esetleg a KDE átveszi. (Lásd KDE4 dobta a DCOP-t a DBus kedvéért.) Előfordul ugyan, hogy a KDE előbb innovál valamit, de azt általában a GNOME nem veszi át, hanem megcsinálja újból másként. Mindez azt igazolja, hogy sokkal több erőforrás megy a GNOME-ba, és ahhoz képest a KDE inkább hobbi jellegű projekt. (Bár abban is van némi igazság, hogy az egész Linux "desktop" egy hobbi dolog.)

Hadd említsem még meg a Dropbox Linuxos kliensét, ami kitalálhatjátok, hogy melyik fájlkezelővel integrálódik. (Megoldás: Nautilus)

Ezzel nem azt akarom mondani, hogy a Qt vagy a KDE rossz, hanem hogy a standard Linux desktop a GNOME/GTK+. A Qt egy multi-platform GUI (és sokminden más) library, így természetesen támogatja a "natív" megjelenést Linuxon is. A KDE valóban egy desktop platform, de a helyzet az, hogy erre a platformra magán a KDE-n és néhány háztáji alkalmazáson kívül senki nem épít.

"Megint csak a KDE-sek fáradoznak azon, hogy a GTK+-s programok illeszkedjenek megjelenésben a KDE-s programok közé, nem pedig a GTK+-s arcok gyúrnak arra, hogy a KDE platform "támogatott" legyen"

Meg a Qt-sok.

Egyebkent meg csak vissza kell lapozni a HUP-ot hogy ezt megerthessuk: mindig is a KDE-sek nyurrogtek a leghangosabban, amikor valami toolbol GTK-s verziot ajanlott valaki, a Gnome-sok legfeljebb amiatt nyuglodtek egy KDE-s szoftver miatt, hogy ahhoz fel kell tenni a fel KDE-t. Es egyebkent ez a GTK appok elonye is: nem jar mellejuk DE.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Igen, csak tisztan Qt-s alkalmazas keves van, mint azt mar fent is elmondtak. Inkabb KDE-s cuccok jonnek, ha jonnek egyaltalan, Qt-re direktben csak az fejleszt, akinek fontos a multiplatformitas. Es eleg keves teruleten fontos ez.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> akinek fontos a multiplatformitas. Es eleg keves teruleten fontos ez.

Ez így 2014-ben elég durva kijelentés. Gyakorlatilag consumer piacon a multiplatform* az Isten.

* Az, hogy hogy oldod meg, nyilván senkit nem érdekel, de az ember igyekszik nem a nulláról újrakezdeni minden platformra.

Attol, mert ez a hype, meg nem minden esetben van ertelme. Ha olyan a felhasznaloi kor, akkor akar az is eleg lehet, ha windows-only adod ki. Legtobb esetben egyebkent igy van. A multiplatformitas mindig pluszkoltseggel jar, raadasul lassabb is ugy fejleszteni.

Azt szeretnem alahuzni, hogy ez a desktop alkalmazasokra vonatkozik, a mobilos appok egy mas kategoria.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Egy multiplatformos appot minden tamogatott platformon le kell tesztelni, ami egyreszt megnoveli a fejlesztes idejet (legalabb a teszteles idejevel, ez ugye nem csak a szintetikus (unit, integracios, stb) teszteket takarja, hanem a tenyleges eszkozon torteno tesztelest is, raadasul a tobb kulonbozo platform altal generalt hibak javitasa tovabbi idot vesz igenybe.

Persze, lehet ugy is multiplatformos appot fejleszteni, hogy megnezed, hogy mukodik-e windowson, aztan ha ott megy, akkor biztos megy majd linuxon meg osx-en is, ha megse, akkor majd az ilyen marginalis userek megvarjak a kovetkezo verziot, ahol kijavitod az oket erinto hibakat is. Csak eppen az ilyenfajta fejlesztesi modell baromira nem professzionalis, a verpistike szinvonalnal eppen csak egy nanometerrel van feljebb, szabad szemmel megkulonboztethetetlen tole.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> megnezed, hogy mukodik-e windowson, aztan ha ott megy, akkor biztos megy majd linuxon meg osx-en is, ha megse, akkor majd az ilyen marginalis userek megvarjak a kovetkezo verziot, ahol kijavitod az oket erinto hibakat is

Hehh, kísértetiesen emlékeztet egy nagy online-játékboltra. :)

Eközben a CS:GO topikban az emberek egyik szeme sír, a másik nevet: jó-jó, volt release, csak nem működik. Így működik a világ, már _meg_lehet_venni_pénzért_a_bétát_*; persze az, hogy ez most jó-e nekünk vagy nem, az más történet.

Sőt a pre-pre-pre-pre-pre-pre-pre-alfát is, ráadásul elég drágán, ahhoz képest, hogy a játék indulás előtt feldob egy érmét, hogy lesz-e crash az első 5 percben.

Hát nem tudom, én baromi sokszor olvastam azt, hogy bármit csak ne kelljen felrakni hozzá a kde-t.

"mindig is a KDE-sek nyurrogtek a leghangosabban, amikor valami toolbol GTK-s verziot ajanlott valaki"

Ezzel amúgy csak az a baj, hogy a gtk-s alkalmazások egyáltalán nem tudnak semmilyen módon integrálódni a kde-s környezettel (leszámítva ami freedesktop szinten egységes), pl. file chooser. Ez nem csak linuxon probléma, windowson is ez van. Hiába tudod rávenni az alkalmazást, hogy vegye fel a qt-s témát, az ilyenek miatt baromi kényelmetlen egy gtk-s alkalmazás egy nem gtk-s környezetben. Egyébként nem tudom, egy kde-s/qt-s alkalmazás mennyire tud idomulni egy gtk-s környezethez?

Azt hiszem, ez a dolog mostanaban valtozoban van, mindket oldalrol. A Gtk ugyan meg mindig nem kepes a KDE filechooseret hasznalni (valoszinuleg azert, mert egyik fel sem akar API-kompatibilitast nyujtani a masiknak), ettol eltekintve azonban kinezetben kozelednek egymashoz az allaspontok, meg ha vannak is utkozopontok.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Inkabb ne. Az IntelliJ felulete tok jol meg van tervezve, egy elbokott KDE-s vagy GNOME-s theme ne akarja nekem szetverni. Kevesbe szep igy, de legalabb kiszamithato.

Raadasul Gnome alatt van lehetoseg GTK kinezetet kerni, szoval nekem olyankor tok nativan nez ki.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

1) OS tema != aktiv tema
2) ha a gombok szelesebbek (akarmiert, mert mas meretu az arnyek, van rajtuk plusz margin/padding), vagy a textboxok mas meretezessel jonnek, akkor az szetverhet bizonyos formokat, ahol elegge kicentiztek a helyet. Van nehany ilyen, es elegge hasznalhatatlanna valna, ha hirtelen egy-ket textbox megnone.

--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( nevergone v | 2014. 09. 22., h – 17:52 )

Ha már itt tartunk, használ valaki Jetbrains terméket Ubuntu 14.04 alatt GNOME-mal? Nekem nem működik a full screen mód, workspace váltásnál eltűnik az ablak, bár az ablakválasztó mutatja, de kiválasztás után megint eltűnik. Nem tudom, esetleg az Intel videókártya-driver okozhatja a gondot?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

Mire gondolsz full screen mode alatt? en teljes mereten hasznalom, ugy jo szokott lenni, MATE alatt nem zavar a ket vekony bar.

Esetleg probalj mas look&feel-t
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Eltüntethető az ablak fejléce, hogy csak a navbar látható (view -> enter full screen). Ha ilyen módban workspace-t váltok, akkor láthatatlanná válik az ablak, csak nagy ritkán sikerül visszaváltanom rá. Gyanítom, hogy a Super gombra megjelenő ablakválasztónak köze van hozzá, mert azzal rögtön produkálja a jelenséget.

Kipróbáltam teljesen új profillal egyéni beállítások nélkül 7-es és 8-as Oracle Java-val, jelentkezik. A 7-es és a 8-as PhpStorm biztosan érintett.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…