GTK vagy Qt4

Grafika: GUI, OpenGL

Ott kezdődött a dolog, hogy saját tapasztalat szerzés miatt gondoltam megtanulom a GTK-t is. Linuxos programozás során általában a Qt-t használtam eddig, mivel a cégnél ezt használjuk. És nekem nincs is a Qt-vel semmi bajom.

Amit nem tudok és ebben kérném a véleményeteket: kb. 2 évnyi Gnome-ozás után áttértem KDE-re, majd egy év után vissza Gnome-ra. És ennyi tapasztalat után most úgy gondolom, hogy nekem a Gnome az ideális. Ami a lényeg, hogy nagyon sokat hallom azt, hogy ha valaki Gnome-ot használ, nem érdemes Qt-s (KDE-s) alkalmazásokkal keverni. Miért? Mert ugye én csak ez miatt preferálom saját részre a GTK-s fejlesztést. Aki Qt-vel fejleszt az mind KDE-t használ? Vagy nálatok hogyan megy ez?

Mellékesen: rá lehet venni valahogy a Gnome-ot, hogy a Qt-s alkalmazások is használják a Gnome kinézetét (mappaikonok, szinek stb.)? Ugyanis fordítva ez működik.

Mindentől függetlenül. Mert ha rajtam múlik, akkor Qt-s alkalmazásokat használok Gnome alatt. Van itt egy kis probléma, amit nem igazán értek. Anjutaval létrehoztam egy alap C++ GTK+-os projectet. Szépen lefordul, megjelenik a "Hello World" feliratú ablak. Az eclipsel létrehozott C++ projectemhez (ami egyébként alapból megint csak fordul) hozzáraktam az Anjuta .glade fájlját, majd a main tartalmát bemásoltam az eclipses main-be. Persze ez így nem fordul le, de ezen még meg sem lepődnék (hátha hiányzik neki a tömérdek Anjutás fájl közül valami). De nem, a hibaüzenetek szerint nem találja a fejfájlokat (libglademm/xml.h, gtkmm.h). Itt a forrás: 


#include <libglademm/xml.h>
#include <gtkmm.h>
#include <iostream>


#ifdef ENABLE_NLS
#  include <libintl.h>
#endif


/* For testing propose use the local (not installed) glade file */
/* #define GLADE_FILE PACKAGE_DATA_DIR"/gtk-proba/glade/gtk-proba.glade" */
#define GLADE_FILE "gtk-proba.glade"
   
int
main (int argc, char *argv[])
{
	Gtk::Main kit(argc, argv);
	
	//Load the Glade file and instiate its widgets:
	Glib::RefPtr<Gnome::Glade::Xml> refXml;
	try
	{
		refXml = Gnome::Glade::Xml::create(GLADE_FILE);
	}
	catch(const Gnome::Glade::XmlError& ex)
    {
		std::cerr << ex.what() << std::endl;
		return 1;
	}
	Gtk::Window* main_win = 0;
	refXml->get_widget("main_window", main_win);
	if (main_win)
	{
		kit.run(*main_win);
	}
	return 0;

Ezek szerint az eclipse nem látja a gtk-s fejállományokat? Vajon miért? Vagy így akárhogy akarom sehogy se fog működni? Akkor hogyan tudok eclipse-ben GTK-s alkalmazást fejleszteni?

  • 4096 megtekintés

( gd | 2008. 02. 05., k – 23:15 )

Más kinézet, ikonok, másképp működő widgetek, más dislógusablakok - ezért nem szerencsés GNOME alatt KDE programokat használni. Továbbá, ha vannak a GNOME-nak minden GNOME alkalmazásra kiterjedő keretrendszerei, a Qt program nem azokat használja. (Ez inkább fordított esetben probléma: KDE-ben alapvető funkciók vannak integrálva, és zavaró, ha egy program nem a KDE-s rendszereket használja.)

( asm v | 2008. 02. 05., k – 23:49 )

Licenc szempontjabol nagy kulonbseg van a ketto kozott:
LGPL (GTK) vs. GPL (Qt opensource)
Sok esetben az utobbi nem opcio egy sw eseten...

Na ha jól értelmezem, akkor ez azt jelenti, hogy a GTK-val készült szoftvert teljesen védhetem a forráskódot, míg az opensource-os Qt csak nyílt lehet.
Ha erre gondoltál, akkor jelen esetben csak saját magam számára írt programokról van szó, aminek a licenszelése szinte mindegy. Viszont ezt eddig még nem tudtam, hogy ilyen különbség is van.
--
A lehetetlen csak a lusta ember kifogása!

( hrgy84 | 2008. 02. 06., sze – 09:09 )

Egy: A #include sorok sosem latszanak ha nem code tagek koze rakod a kododat.
Ketto: Azert nem szerencses Gnome alatt Qt-s appokat hasznalni, mert teljesen mas kinezetuk van. A Qt nem kepes teljesen integralodni a Gtk temaival, es eleg hulyen tud festeni egy tok mas temaju ablak egy egyseges rendszerben. Nyilvan erre workaround a curves tema, de ha valaki nem azt hasznalja, akkor szopacs.

Arrol nem beszelve, hogy a Qt gyakorlatilag megegyszer megvalositja azt, amit a Gtk mar megvalosit. Ez alapvetoen nem gond, foleg a sokkal baratsagosabb API felulet okan, csakhogy a Qt nem eppen a kis mereterol hires. A Gtk sokkal modularizaltabb a Qt-nal, igy nem toltesz be egyszerre mittomen mekkora libet, hanem csak azt, amire telleg szukseged van. Gtk-hoz is van C++ wrapper API, GtkMM a neve, illetve mindenfele *MM libek vannak meg, ezek a megfelelo Gtk-s libek C++ wrapperei (GnomeVFSMM, stb.)

( develru | 2008. 02. 06., sze – 23:27 )

Eclipse-ben a project beállításoknál a C/C++ Buil -> Tools setting -> GCC C++ Compiler -> Directoris-nál hozzáadom a megfelelő könyvtárakat, akkor felismeri a fejfájlokat. Viszont buildnál ezer hibaüzenetet kapok. Kb. az összes ilyen:

/usr/include/glibmm-2.4/glibmm/containers.h:68: error: ‘bidirectional_iterator_tag’ in namespace ‘std’ does not name a type

A legjellemzőbb dolog erre, hogy nem értem...

Alapból a doksi azt írja, hogy a ezzel fordítsam: g++ simple.cc -o simple `pkg-config gtkmm-2.4 --cflags --libs` . Így rendben is volnánk.

Eclipsel miért nem megy. Töredelmesen bevallom eddig semmi komolyabbra nem használtam a CDT. Biztos bennem van a hiba, csak nem tudok rájönni.

Lenne valaki olyan kedves és megírná nekem valami tutornak a címét, amiből tudnék valamit ehhez kiokoskodni!
--
A lehetetlen csak a lusta ember kifogása!

( tr3w v | 2008. 02. 07., cs – 01:01 )

Csak a magam nevében beszélhetek, de én Gnome-ot használok, Opera-val netezek és Qt alá fejlesztek.

Ezzel semmi probléma, a gnome nekem letisztultabb/jobban tetszik (bár most a KDE4 bíztató) viszont Qt sokkal jobb C++-os fejlesztésre mint a gtkmm, főleg cross-platform esetben.

A kinézettel sincs gond, volt valami qt3config vagy hasonló nevű progi amivel egy hasonló skint adtam a Qt-s progiknak mint amit Gnome alatt használok.

Persze KDE-s programokat használva már tényleg gond lehet a "más keretrendszer"...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Automatikusan egyik irányba sem megy, de ez nem feltétlenül gond, hiszen most rityiről van szó, és nem egy átlag r=1 userről (kivéve ha őt oda számolod. :) )
A kérdés az volt, hogy mekkora gondot okozhat neki az, ha egy-két saját Qt-s alkalmazását használni akarja Gnome alatt. A válasz: semekkorát, vagy minimálisat. (KDE már más tészta lenne)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Alapvetően a signal/slot elgondolással nincs gond, sőt.
(Gtkmm is azt használja (libsigc++))
Azzal lehet vitatkozni, hogy a Qt előfordítós megoldása mennyire szép illetve mennyire C++. A Qt3-as időkben nekem sem tetszett, és gányolásnak tartottam.

Most viszont (Qt4) az előfordítónak hála olyan lehetőségek vannak, amik egyébként nem lehetnének, kezd a dolog értelmet nyerni. :)
Hogy a signal/slotnál maradjak, lehetőség van aszinkron összekötésre, ezáltal különböző thread-ek signal-slot párjainak összekötésére, mindezt egy egyszerű connect-tel.

Volt egy nagyon jó cikk a témában, de már csak a google cache-ben találom... itt
A végén van egy összehasonlítás (boost.signals vs Qt signals)

Tehát összegezve, igen, még mindig azt kell használni, és nem, nem hülyeség. :)

(U.I.: Ne a Qt3 alapján ítéld meg a Qt4-et, azt én se szerettem, ezt viszont a legjobb cross-platform (C++) frameworknek tartom)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Alapvetően a signal/slot elgondolással nincs gond, sőt."
Nem az elgondolással volt nekem se gondom, hanem a megvalósítással.

"Ne a Qt3 alapján ítéld meg a Qt4-et"
Nem a Qt4-et ítéltem meg, hanem a Qt-t úgy általában. Az előző hozzászólásodban te is csak verziószám nélkül emlegetted.

"Nem az elgondolással volt nekem se gondom, hanem a megvalósítással."

Sejtettem, ezért próbáltam rávilágítani, hogy ennek az esetleg nem szép megoldásnak van pozitív hozománya is...

"Nem a Qt4-et ítéltem meg, hanem a Qt-t úgy általában. Az előző hozzászólásodban te is csak verziószám nélkül emlegetted."

Igen, ezért emeltem ki, hogy a Qt4 sokkal jobb mint a 3, tehát ha te a 3-at ismerted és nem szeretted, azért még adhatsz egy esélyt a 4-nek.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Néha úgy érzem amikor Qt4-el programozok, hogy ez már nem is C++. De persze ez nem helytálló, csak néha vannak dolgok amiben nem biztos, hogy teljesen megengedi a "C++-os" programozást. Sokkal jobban rá vagyok kényszerítve a Qt-s libek használatára, és sokszor a C++-os standard libeket nehezebb használni.
De ettől függetlenül én is a legjobb cross platformos dolognak tartom, főleg C++ hoz. Viszont ha már Gnome, akkor megpróbálkozom ezzel a gtkmm-es dologgal is. Vannak progik amiket nagyon hiányolok, és nincs Gtk-s megfelelője. Mondjuk ilyen a Tellico, ami ráadásul lassúnak tűnik nekem Gnome alól. Arra gondoltam, hogy megpróbálom a Tellico forráskódja alapján megírni gtkmm-el. Még nem néztem meg a forráskódot, de remélem menni fog, aztán legfeljebb megosztom a tapasztalatokat.

--
A lehetetlen csak a lusta ember kifogása!

"vannak dolgok amiben nem biztos, hogy teljesen megengedi a "C++-os" programozást"

Mire gondolsz?

Szerintem a C++-os programozást elősegíti, de valóban gyakran elfedi a standard libet. Ami nem meglepő, hiszen ez egy egységes framework. Én még nem éreztem ennek negatív hatását, igaz az elején kicsit szokni kellett, hogy pl ne vector-t, hanem QList-et használjak...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"pl ne vector-t, hanem QList-et használjak"

Pont ilyenekre gondoltam. Tudom, hogy alapból ez nem rossz, de nekem van egy csomó algoritmusom, ami a standard libekre épül. És ezt nem egyszerű átírni. De eddig még mindig meg tudtam ezt is oldani, csak több időt vesz igénybe, mint egyszerűen meghívni.

--
A lehetetlen csak a lusta ember kifogása!

Ezt megértem.

Mondjuk pont a konténerekkel nincs sok gond, egyrészt használhatod az STL-eseket, és max átalakítod ha valamiért a Qt-nak úgy kell, másrészt általában elérhető az STL-es felület is (pl.: QList::push_back()), így szinte csak ki kell cserélni a vector-t QList-re és kész. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( develru | 2008. 02. 07., cs – 10:47 )

Az alap problémát megoldottam. Azt viszont nem tudom mennyire szép megoldás. A fentebb említett doksikat is megnézem és lehet találok szebb megoldást is.

Eclipse-ben standard projektet hoztam létre (nem managed), ehhez hozzáadtam a következő makefile-t: 


main : main.cpp 
	g++ main.cpp -o main `pkg-config gtkmm-2.4 --cflags --libs libglademm-2.4`	 
 
all : 
	${MAKE} main 
clean : 
	-del main.o

Így teljesen korrektül működik.
--
A lehetetlen csak a lusta ember kifogása!

A libglademm függ a gtkmm-től, úgyhogy a pkg-config-nál a gtkmm-2.4-et akár el is hagyhatod.
Másrészt említetted, hogy a projekt beállításoknál hozzáadtál megfelelő könyvtárakat. Biztos, hogy az összes szükséges, header file-okat tartalmazó könyvtárat hozzáadtad?
pkg-config --cflags --libs libglademm-2.4 |sed -e 's/-[Ll][^ ]*//g' -e 's/-I//g'

S mi a helyzet a szükséges libekkel, és az azokat tartalmazó könyvtárakkal?
pkg-config --cflags --libs libglademm-2.4 |sed -e 's/-[IL][^ ]*//g' -e 's/-l//g'
pkg-config --cflags --libs libglademm-2.4 |sed -e 's/-[Il][^ ]*//g' -e 's/-L//g'

Igazából ezt most nem igazán értem. Ha nem managed projectet használok, és a fentiek alapján létrehozom a makefile-t, akkor mindenféle hibaüzenet nélkül működik.

Ha meg managed projectet használok, akkor nem tudok, meg nem is akarok kézzel turkálni sehova, azért managed. Viszont a beállításoknál, az értelmes dolgokat hozzáadom, és a forráskódban nem is talál hibát, felismeri a fejfájlokat is. Csak a fordításnál dobja a fenti hibákat, ezért le se fordul. Viszont azokhoz nekem semmi közöm, azokat nem én írtam :)

--
A lehetetlen csak a lusta ember kifogása!

( turul16 v | 2008. 02. 07., cs – 12:10 )

Azert rossz mert, ha van egy rahadli GTK progid, az kb. ugyanozokon libraryken osztozik a memoriban.
He betoltesz egy Qt/KDE progit, az hozza magaval QT/KDE stuffokat a memoriba, igy tovabb tart ez elso QT/KDE dolog betoltese, valamint tobb memoriat hasznalsz shared librarykra.

( turul16 v | 2008. 02. 07., cs – 12:12 )

"Ezek szerint az eclipse nem látja a gtk-s fejállományokat? Vajon miért?"

Ha tippelhetek amikor indexeltetted vele a hedereket, akkor nem voltak fent a GTK -sok, probald ujra indexeltetni.