nachdem der Monster-KDE-Thread hier inzwischen etwas OT geworden ist,
und auch noch nix von Nazis und EOT zu sehen war, habe ich meine
Frage unter einem neuen Subject gepostet:
Kann mir mal jemand erklaeren, wo die _grundsaetzlichen_ Unterschiede
zwischen dem GNOME und KDE-Projekt liegen ? Sie verfolgen doch beide
das gleiche Ziel: ein "up-to-date" Desktop-Environment, oder taeusche
ich mich ?
Worin unterscheiden sich die verwendeten Libraries GTK und QT ?
(ja ich weiss - QT ist Loehnwaere ausserhalb freier Software, GTK nicht.
Ich moechte auch nur _funktionale und konzeptionelle_ Unterschiede
sowie Funktionsumfang wissen )
Was war der Grund, weshalb die KDE-Leute was eigenes angefangen haben, statt
GNOME zu unterstuetzen ?
Auf den KDE-Webpages ist von gegenseitiger Unterstuetzung die Rede, aber was
richtig klares findet man da nicht - ist GNOME vielleicht schon tot ? Tut sich
da noch was, oder arbeiten jetzt alle an KDE ?
TIA
Peter
| Kann mir mal jemand erklaeren, wo die _grundsaetzlichen_ Unterschiede
| zwischen dem GNOME und KDE-Projekt liegen ?
Gnome basiert im Gegensatz zu KDE nur auf Freier Software.
| Worin unterscheiden sich die verwendeten Libraries GTK und QT ?
Qt ist aufgebohrtes C++ und Gtk plain C.
| Was war der Grund, weshalb die KDE-Leute was eigenes angefangen haben, statt
| GNOME zu unterstuetzen ?
Reihenfolge war umgekehrt.
| Auf den KDE-Webpages ist von gegenseitiger Unterstuetzung die Rede, aber was
| richtig klares findet man da nicht - ist GNOME vielleicht schon tot ? Tut sich
| da noch was, oder arbeiten jetzt alle an KDE ?
Schon mal bei www.gnome.org gewesen?
Meines Wissens nach investieren Redhat und Debian recht viel in GNOME.
Redhat will glaube ich seine Admin Tools auf GNOME umprogrammieren.
--
Written and Copyright (?) by : Guenter Schwann
======= ========= = =================
> Worin unterscheiden sich die verwendeten Libraries GTK und QT ?
gtk ist hübscher <g>.. doch echt.. die ganzen elemente sind da viel
feiner/schöner. während gtk sehr viel mit ein pixel lines & co macht
müssen es bei QT min. 3 alleine für nem billig button_shadow oder so
sein :-(
> Was war der Grund, weshalb die KDE-Leute was eigenes angefangen haben, statt
> GNOME zu unterstuetzen ?
idiotie ? debilität ? größenwahn ? langweile ? kommerzielle interessen
(irgendwannmal) ? sponsoring von qt ?
--
Adam Kopacz - http://www.idnet.de/~AdamK
ID.net Internet Services Deutschland GmbH - http://www.idnet.de
Guard Control - Wach und Kontrolldienst GmbH - http://www.bewachung.com
> Das Gnome Projekt ist keinesfalls tot, sondern sogar quicklebendig.
> Momentan stecken die Entwickler in den Vorbereitungen fuer eine erste
> Beta Release. Der momentane Stand der Entwicklung sieht uebrigens
> schon sehr vielversprechend aus. :-)
Ich habe mir vor etwa zwei Wochen und dann ein paar Tage via CVS
aktualisiert die aktuellen GNOME-Sourcen angesehen und einige Zeit
damit verbracht, alles zum compilieren zu bekommen.
Mein Eindruck war, daß da noch eine Menge Arbeit nötig ist, bis eine
laufende Desktop-Umgebung zusammengekommen ist, obwohl die ersten
Eindrücke, dessen, was lief (panel, help-browser) großartig waren.
Ich verfolge nur die gnome-announce-Liste, wurde irgendwo anders (auf
der WWW-Seite, auf gnome-list etc.) schon mal näheres über eine erste
Beta gesagt? Eventuell ein möglicher Termin? Ich warte gespannt auf
GNOME.
--
Hendrik Seffler · hen...@xion.owl.de · http://home.pages.de/~seffler/
> Paul Seelig (pse...@mail.uni-mainz.de) wrote:
> : peter.s...@gmx.net writes:
> :
> : Das Gnome Projekt ist keinesfalls tot, sondern sogar quicklebendig.
> : Momentan stecken die Entwickler in den Vorbereitungen fuer eine erste
> : Beta Release. Der momentane Stand der Entwicklung sieht uebrigens
> : schon sehr vielversprechend aus. :-)
>
> Meines Wissens nach investieren Redhat und Debian recht viel in GNOME.
> Redhat will glaube ich seine Admin Tools auf GNOME umprogrammieren.
Redhat will ja in der nächsten Version auf linuxconf umstellen. Dafür
ist dann ein GNOME- bzw. GTK Frontend sehr gut denkbar.
Gruß,
Julian
--
************************************************************************
Julian Einwag - Herm-Loens-Str.9 - 96106 Ebern - wjei...@swin.baynet.de
Private homepage: http://www.swin.baynet.de/user/amon+einwag/
***** Send mail request for PGP key ************************************
>> [Unterschiede GNOME/KDE]
> Beide Projekte wollen ein freies leicht bedienbares Desktop
> Environment auf die Beine stellen, das ueber die Funktionalitaet eines
> beliebigen Windowmanagers hinausgeht und versuchen, die Vorteile einer
> MS-Win95/Mac GUI fuer das X Window System unter diversen Unixen zu
> realisieren.
>> Worin unterscheiden sich die verwendeten Libraries GTK und QT ?
> [KDE verwendet nicht freies Qt]
> Das ist der Kritikpunkt, aufgrund dessen das Gnome Projekt ins Leben
> gerufen wurde. Dieses verwendet das mit dem freien Grafikprogramm
> 'gimp' entstandene Widgetset 'gtk+', das unter der LPGL (nicht unter
> der GPL!) steht und also beliebig verwendet und manipuliert werden
> darf - selbst fuer kommerzielle Software.
>
> Qt ist momentan wohl noch das leistungsfaehigere Widgetset von beiden,
> da es zum einen Motif besser emuliert und auch ein MS-Windows Look &
> Feel gestattet. Im Gegensatz zum noch arg mauslastigen 'gtk+' laesst
> sich damit erstellte Software fast gleichwertig sowohl mit der Maus
> als auch der Tastatur bedienen.
Mmmm. gtk ist doch meines Wissens eine reine C-Library. Heisst das
'+' in gtk+, das es nun C++-Code ist, oder gibts so was wie einen
Wrapper fuer C++ ?
>> Was war der Grund, weshalb die KDE-Leute was eigenes angefangen haben, statt
>> GNOME zu unterstuetzen ?
>>
> Falsche Frage, es war genau andersherum. Gnome wurde erst deutlich
> nach KDE ins Leben gerufen aufgrund der mit Qt verbundenen Probleme.
Urgs... Da hab ich wohl nicht aufgepasst... Ich dachte GNU ist immer
zuerst da (mit dem Konzept) und braucht dann allerdings lange mit
der Implementierung ;) ...
>> Auf den KDE-Webpages ist von gegenseitiger Unterstuetzung die Rede, aber was
>> richtig klares findet man da nicht - ist GNOME vielleicht schon tot ? Tut sich
>> da noch was, oder arbeiten jetzt alle an KDE ?
>>
> Leider bekommen die jeweiligen Entwickler es aus wie auch immer
> gearteten Greunden nicht hin, auf zwei Parties gleichzeitig zu tanzen.
> Jegliche Zusammenarbeit liegt nicht nur brach, sondern ist wohl noch
> nicht mal ansatzweise zustandegekommen. :-(
Eigentlich bedauerlich, allerdings hat der Tag fuer alle nur 24h.
> Das Gnome Projekt ist keinesfalls tot, sondern sogar quicklebendig.
> Momentan stecken die Entwickler in den Vorbereitungen fuer eine erste
> Beta Release. Der momentane Stand der Entwicklung sieht uebrigens
> schon sehr vielversprechend aus. :-)
Ja die Screenshots ueberzeugen wirklich. Und die Leute (drei) von RH-Labs
wollen ja die meiste Zeit an GNOME arbeiten, wie ich mitlerweile rausbekommen
habe (obwohl da wohl auch ein bischen Zeit fuer Enlightment drauf geht ;) ).
Abschliessende Frage:
Hintergrund meines ersten Postings war, dass ich mich auch mit der Programmierung
unter Linux und X beschaeftigen moechte. Allerdings will ich natuerlich nicht
alle Reaeder neu erfinden und frage daher nach den Basics der beiden Projekte.
Da ich persoenlich eine saubere C++-Klassenbiblothek bevorzuge stach mir latuerlich
KDE ins Auge... Das relativiert sich natuerlich jetzt ein bischen...
Ist KDE gerade einfach nur trendy, oder laesst sich darauf auch laengerfristig
aufbauen ?
GNOME hat IMHO das bessere Konzept (CORBA, usw.) aber traegt das auch auf Dauer
- d.h. siegt der pragmatische Ansatz von KDE ?
Was denkt Ihr ?
TIA
Peter
Das ist wohl richtig, bezieht sich in diesem Fall auf GNUstep.
Ja, GNU hat zwei vrschiedene GUI-Projekte, die jedoch nicht
miteinander konkurrieren, weil in der freien Wildbahn kaum einer
was von GNUstep weiss oder es gar verstanden hat.
>Ist KDE gerade einfach nur trendy, oder laesst sich darauf auch laengerfristig
>aufbauen ?
KDE ist durchaus laengerfristig tragbar. Zwar ist Qt als Basis
von KDE nicht frei im Sinne der GPL, aber es ist trotzdem "sehr
frei" in dem Sinne, dass es eine Reihe von Rueckversicherungen
gibt, die z.B. eine Weiterentwicklung garantieren, Kooperation
zwischen KDE und Qt garantieren und die Freigabe der Sourcen
erzwingen, sollte Troll gekauft werden oder aufgeben.
Letztendlich hat Qt eine sichere Zukunft.
Es existieren uebrigens Wrapper fuer Qt, die den Zugriff auf die
Bibliothek aus C, aus Perl und aus anderen Sprachen erlauben.
Und was GNUstep und Qt/KDE angeht: Qt/KDE ist das, was man
bekommt, wenn man die Systematik von GNUstep/OpenSTEP auf die
Programmiersprache C++ anwendet. Das (Laufzeitbindung von
Methoden und Moeglichkeiten der Intrspektion) ist bei der
Entwicklung von Anwendungen eine extrem grosse Hilfe, weil es
eine Menge C++-inhaerente Probleme fuer die GUI-Klassen einfach
abschafft.
Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
"It's not a bug, it's the future."
-- Nach einem Verschreiber von Markus Jotter <mar...@jotter.rhein-neckar.de>
> Beide Projekte wollen ein freies leicht bedienbares Desktop
> Environment auf die Beine stellen, das ueber die Funktionalitaet eines
> beliebigen Windowmanagers hinausgeht und versuchen, die Vorteile einer
> MS-Win95/Mac GUI fuer das X Window System unter diversen Unixen zu
> realisieren.
Ja, dies war der ursprüngliche Gedanke beider Projekte. Mittlerweile
zeigen sich IMHO klare Differenzen nicht nur in der 'politischen' Wahl
des Widget-Sets, sondern auch im Design. KDE bemüht sich um eine
Oberfläche aus einem Guß und ist deshalb monolithisch. Der Windowmanager
kwm, der Filemanager kfm und das K-Panel bauen aufeinander auf und sind
zum vollen KDE-Genuß vorgeschrieben. Dadurch sind Look'n'Feel sehr
kohärent, was insbesondere Windows-Umsteigern entgegenkommt.
Gnome hingegen hat sich in der kurzen Zeit seiner Existenz zu einem
offenerem Design hin entwickelt. Die Wahl von Window- und Filemanager
ist frei, auch der GMC (=gnomifizierte Midnight Commander) ist hier nur
eine Option. Bestehende Windowmanager sollen sehr einfach an Gnome
anzupassen sein. Im Gnome-Projekt aufgehen werden u.a. Enlightenment
(dessen Entwickler Rasterman von RedHat eingestellt wurde, um
Gnome-Software zu schreiben) und scwm. Außerdem verwendet Gnome als
Objektschnittstelle nicht proprietäre Standards wie qt/KDE, sondern
benutzt CORBA. Ebenso wird das für GNUstep entwickelte Display
Ghostscript in Gnome eingehen. Gnome bemüht sich also mehr als KDE um
die Integration offener Standards, wahrscheinlich jedoch um den Preis
jener großen Kohärenz, die KDE auszeichnet.
> > (ja ich weiss - QT ist Loehnwaere ausserhalb freier Software, GTK nicht.
> > Ich moechte auch nur _funktionale und konzeptionelle_ Unterschiede
> > sowie Funktionsumfang wissen )
> >
> Qt ist momentan wohl noch das leistungsfaehigere Widgetset von beiden,
> da es zum einen Motif besser emuliert und auch ein MS-Windows Look &
> Feel gestattet. Im Gegensatz zum noch arg mauslastigen 'gtk+' laesst
> sich damit erstellte Software fast gleichwertig sowohl mit der Maus
> als auch der Tastatur bedienen.
Das ist zwar richtig, jedoch bietet GTK hier IMHO interessantere
Perspektiven. Da es sich bei GTK um GNU-Software handelt, kann dessen
Funktionalität nach der Basar-Methode erweitert werden. Es ist nicht
durch die Manpower und strategischen Prioritäten einer Firma eingeengt,
die ihr Produkt kommerziell vermarkten und deshalb resourcenschonend
entwickeln muß. Ein Beispiel: Es ist damit zu rechnen, daß künftige
GTK-Versionen ein NeXTStep-Look'n'Feel implementieren. Mit den
entsprechenden Window- und Filemanagern wird sich dann der gesamte
Gnome-Desktop auf NeXTStep trimmen lassen.
Eine ähnliche Dynamik ist bei Qt nicht zu erwarten, da sich kaum ein
freier Programmierer die Mühe machen wird, dessen Sourcen z.B. um ein
NeXTStep-Look zu erweitern - oder, wichtiger noch, eine Unterstützung
für 1-bit-s/w-Displays einzubauen -, wenn das Produkt nicht freie
Software ist oder TrollTech sogar entscheidet, man werde das Feature
nicht verwenden, weil es die Pflege und weitere Entwicklung von Qt
verkompliziere. Hierin liegt die wirkliche Einschränkung der Qt-Lizenz
gegenüber GPL und LGPL.
> Leider bekommen die jeweiligen Entwickler es aus wie auch immer
> gearteten Greunden nicht hin, auf zwei Parties gleichzeitig zu tanzen.
> Jegliche Zusammenarbeit liegt nicht nur brach, sondern ist wohl noch
> nicht mal ansatzweise zustandegekommen. :-(
De facto gibt es eine Konkurrenz beider Projekte. Die ursprüngliche Idee
des Gnome-Projekts, die KDE-Sourcen auf GTK zu portieren, ist
mittlerweile tot. Ich halte das sogar für eine gute Entscheidung, weil
die Anwender künftig die schöne Qual der Wahl zwischen zwei
verschiedenen Desktop-Philosophien haben werden. Die Frage "Gnome oder
KDE?" wird ebenso interessant und müßig sein wie "bash oder tcsh",
"Emacs oder vi", "Mozilla oder lynx", "elm oder pine" etc.etc. IMHO
spricht das nur für die Linux-Plattform.
Florian
--
Florian Cramer <para...@gmx.net>, PGP public key available on request
combinatory poetry site: <http://www.earthcorp.com/paragram>
Wie hoch sind die Chance, eine Klassenbibliothek erstellen zu
können, die die Funktionen von GTK und Qt kapselt und einem
erlaubt Programme per Compilerparameter für das eine oder andere
System zu erstellen?
(Hmm, meine C++ Kenntnisse sind gerade erst im Entstehen, daher
kann diese Frage durchaus etwas naiv wirken.)
Martin
--
Martin Neumann, Lindenbreede 14, 49124 Georgsmarienhütte
»Das Usenet wird vielleicht eher durch die Killfiles gerettet. Wer
keine Antwort kriegt langweilt sich und geht wieder zur Therapie.«
~ Oliver Gassner in <3521a5f3...@news.pf.bawue.de>
cu
FLoh
---
,,,
(o-o)
--oOOO---(o)---OOOo-----------------------------------
| "I call it performace art, she |
| .oooO Oooo. calls it a waste of time. -- |
| ( ) ( ) History will decide" STEVE MARTIN |
-----\ (------) /-------------------------------------
\_) (_/
Die ganze Sache ist allerdings recht akademisch, weil man Qt und GTK+
gleichzeitig installieren kann, so dass der Programmierer die volle
Wahlfreiheit hat. Und zur allergroessten Not hilft immer noch
statisches Linken ;-)
Tschau,
Robert
--
Robert Fendt <fe...@student.physik.uni-dortmund.de>
public PGP key available !
--
Hiermit untersage ich die Nutzung und Uebermittlung meiner Daten zu
Werbezwecken oder fuer die Markt- bzw. Meinungsforschung gemaess
Par. 28 Abs. 3 Bundesdatenschutzgesetz.
> Der Gedanke, die Resourcen, die
> momentan in GNOME und KDE gesteckt werden zu buendeln, hat etwas verlockendes
> an sich - da muessten sich einige grosse Softwarehersteller warm anziehen.
> Aber das hat wohl nicht sein sollen...
Es wäre schon viel gewonnen, wenn GNOME und KDE auf einer Ebene
interoperabel wären, die über `Applikationen können auf demselben
X-Display laufen' hinausgeht.
Einigermaßen ähnlich sehen die Sachen ja schon aus, jetzt müßten nur
noch Dinge wie Drag & Drop funktionieren oder ein einheitliches
Hilfesystem existieren. Einheitlich in dem Sinne, daß beide dieselben
Dokumente finden und anzeigen können (sollte durch HTML nicht so das
Problem sein) und daß die beiden von anderen Programmen aus auf dieselbe
Art angesprochen werden, so daß man sich aussuchen kann, ob man das von
GNOME oder das von KDE benutzen möchte. Und so weiter.
Vielleicht kommen wir irgendwann mal da hin, wenn beide sich mehr mit
CORBA beschäftigen. Ich würde die Luft beim Warten aber nicht anhalten.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
The reason why so few marriages are happy is because young ladies spend their
time in making nets, not in making cages.
--- Jonathan Swift, *Thoughts on Various Subjects*
JE> vo...@sbox.tu-graz.ac.at (Guenter Schwann) writes:
JE>
>> Paul Seelig (pse...@mail.uni-mainz.de) wrote:
>> : peter.s...@gmx.net writes:
>> :
>> : Das Gnome Projekt ist keinesfalls tot, sondern sogar quicklebendig.
>> : Momentan stecken die Entwickler in den Vorbereitungen fuer eine erste
>> : Beta Release. Der momentane Stand der Entwicklung sieht uebrigens
>> : schon sehr vielversprechend aus. :-)
>>
>> Meines Wissens nach investieren Redhat und Debian recht viel in GNOME.
>> Redhat will glaube ich seine Admin Tools auf GNOME umprogrammieren.
JE>
JE> Redhat will ja in der nächsten Version auf linuxconf umstellen. Dafür
JE> ist dann ein GNOME- bzw. GTK Frontend sehr gut denkbar.
Dieses Gnome-Frontend ist schon laenger in Arbeit und wahrscheinlich in
der RH 5.1 (die wohl zur LinuxExpo am 28. Mai herauskommen wird) schon
enthalten. Ein Gnome-Frontend fuer rpm, das Glint ersetzen wird, ist
auch schon so gut wie fertig.
Jochem
--
# Jochem Huhmann <j...@gmx.net> Duisburg (Germany)
# Der Red Hat Kompakt-Index: http://www.revier.com/redhat/
man file: "This software is not subject to any export provision of the United
States Department of Commerce, and may be exported to any country or planet."
FC> Gnome hingegen hat sich in der kurzen Zeit seiner Existenz zu einem
FC> offenerem Design hin entwickelt. Die Wahl von Window- und Filemanager
FC> ist frei, auch der GMC (=gnomifizierte Midnight Commander) ist hier nur
FC> eine Option. Bestehende Windowmanager sollen sehr einfach an Gnome
FC> anzupassen sein. Im Gnome-Projekt aufgehen werden u.a. Enlightenment
FC> (dessen Entwickler Rasterman von RedHat eingestellt wurde, um
FC> Gnome-Software zu schreiben) und scwm.
Fuer WindowMaker gilt aehnliches, auch wenn wohl kein WM direkt in in
Gnome aufgehen wird. Man will halt einfach die mwm-Hints benutzen, um
mit dem WM zu kommunizieren und bei Bedarf weitere Hints einfuehren.
Sowas kann dann jeder beliebige WM unterstuetzen, wenn deren
Entwickler sich diese (nicht allzugrosse) Muehe machen wollen. Man wird
wohl bald bei Gnome einfach seinen Lieblings-WM benutzen koennen und
trotzdem eine Integration wie bei KDE haben.
FC> Das ist zwar richtig, jedoch bietet GTK hier IMHO interessantere
FC> Perspektiven. Da es sich bei GTK um GNU-Software handelt, kann dessen
FC> Funktionalität nach der Basar-Methode erweitert werden. Es ist nicht
FC> durch die Manpower und strategischen Prioritäten einer Firma eingeengt,
FC> die ihr Produkt kommerziell vermarkten und deshalb resourcenschonend
FC> entwickeln muß. Ein Beispiel: Es ist damit zu rechnen, daß künftige
FC> GTK-Versionen ein NeXTStep-Look'n'Feel implementieren. Mit den
FC> entsprechenden Window- und Filemanagern wird sich dann der gesamte
FC> Gnome-Desktop auf NeXTStep trimmen lassen.
Genauer gesagt arbeitet rasterman daran, den gesamten Look&Feel-Code
von GTK in eine einzelne shared lib auszulagern, so dass man das
Aussehen von GTK beliebig gestalten kann, ohne an GTK selbst etwas
aendern zu muessen (Themes). Bei den Buttons ist er schon soweit,
irgendwo auf www.labs.redhat.com liegt ein netter Screenshot herum, der
zeigt, was damit moeglich ist. In nicht allzuferner Zukunft kann man
sich dann wohl aussuchen, ob GTK-Programme nach Motif, Windows, NeXT,
Macintosh oder sonstwie aussehen sollen.
FC> De facto gibt es eine Konkurrenz beider Projekte. Die ursprüngliche Idee
FC> des Gnome-Projekts, die KDE-Sourcen auf GTK zu portieren, ist
FC> mittlerweile tot. Ich halte das sogar für eine gute Entscheidung, weil
FC> die Anwender künftig die schöne Qual der Wahl zwischen zwei
FC> verschiedenen Desktop-Philosophien haben werden. Die Frage "Gnome oder
FC> KDE?" wird ebenso interessant und müßig sein wie "bash oder tcsh",
FC> "Emacs oder vi", "Mozilla oder lynx", "elm oder pine" etc.etc. IMHO
FC> spricht das nur für die Linux-Plattform.
Genau. Monokultur ist eh out ;-)
Es hat ja gute Gründe, daß StarDivision StarView nicht mehr als
Wrapper um Motif etc. benutzt, sondern nativ implementiert. Im
Quelltext kann man sich ja bei Netscape jetzt mal angucken, wie
krank so was ist. Insbesondere kann man ja mal die Zeilen zählen,
die allein für das Cross-Platform-Framework draufgehen und ver-
gleichen mit dem Umfang einer Bibliothek wie Qt oder gtk.
> * Beide Bibliothek verfolgen unterschiedliche Paradigmen, die sich u.a. aus
> der verwendeten Programmiersprache ergeben. GTK stammt aus der C Ecke, Qt
> ist eine C++ Bibliothek. Das schlaegt sich im Design der Bibliotheken
> nieder.
Gar nicht mal. gtk ist im Gegenteil sehr stark an Qt orientiert. Der
Signal-Slot-Mechanismus ist z. B. bei Qt abgekupfert. Die
Widget-Hierarchie ist auch sehr ähnlich. Die Probleme ergeben sich
eher z. B. bei der Event-Verarbeitung, die unterschiedlich ist.
> * Qt ist eine kommerzielle Bibliothek (aber frei benutzbar fuer kostenlos
> verfuegbare Anwendungen).
Umgekehrt: Es ist kostenlos benutzbar für frei verfügbare Anwendungen.
> * Die Anhaenger von GTK verkaufen das C Binding als wesentlichen Vorteil.
> Der Support fuer eine reine C++ Bibliothek duerfte daher von dieser Seite
> her eher gering sein.
Das ist eine sehr höfliche Umschreibung von "Bei GNOME darf man als
C++-Programmierer einen Spießrutenlauf durchmachen, gegen den sich
die spanische Inquisition als barmherzig ausnimmt".
Bernd.
Na klar: Statt einfach die kwm-Hints zu übernehmen, muß man natürlich
eigene, inkompatible erfinden. Ja, in einem muß man dir recht geben:
gnome hat ein Konzept. Und das heißt "Möglichst inkompatibel mit KDE
sein, und das um jeden Preis".
Bernd.
Und wieso hat KDE eigene Hints erfunden, statt die etablierten und
standardisierten mwm-Hints zu benutzen? Mit dem Argument schießt du
dir selbst in den Fuß.
Tschüss, Florian
| JE> Redhat will ja in der nächsten Version auf linuxconf umstellen. Dafür
| JE> ist dann ein GNOME- bzw. GTK Frontend sehr gut denkbar.
|
| Dieses Gnome-Frontend ist schon laenger in Arbeit und wahrscheinlich in
| der RH 5.1 (die wohl zur LinuxExpo am 28. Mai herauskommen wird) schon
| enthalten. Ein Gnome-Frontend fuer rpm, das Glint ersetzen wird, ist
| auch schon so gut wie fertig.
Miguel hält einen Vortrag in Köln zum Thema Gnome:
http://www.linux-kontress.de
| Wie hoch sind die Chance, eine Klassenbibliothek erstellen zu
| können, die die Funktionen von GTK und Qt kapselt und einem
| erlaubt Programme per Compilerparameter für das eine oder andere
| System zu erstellen?
WxFTP ist mit so einer Klassenbibliothek gemacht, die alternativ auf
Motif oder Gtk aufsetzt. Außerdem gibt es das Ding für Windows.
Jeder Versuch sowas zu unternehmen ist halb zum Scheitern verurteilt,
da in den meisten Fällen nur ein unflexibles Monster daber
rauskommt. Irgendwann hat das Layergestapel mal ein Ende.
| Ich verfolge nur die gnome-announce-Liste, wurde irgendwo anders (auf
| der WWW-Seite, auf gnome-list etc.) schon mal näheres über eine erste
| Beta gesagt? Eventuell ein möglicher Termin? Ich warte gespannt auf
| GNOME.
Bis man von einer wirklichen Beta sprechen kann wird noch viel Zeit
vergehen. Der Corba-Support von Gnome steckt noch in den Kinderschuhen
und eine Corba-Implementation ist mindestens so aufwendig wie Gtk+
selber.
Das einzige was es im Augenblick gibt, sind einzelne Programme. Jedes
mehr oder weniger fertig. Oft jedoch eher weniger als mehr. Aber Gimp
hat auch ne Weile gebraucht von der ersten Motif-Version bis
heute. Gnome hat das Zeug dazu, ein Kondensationskeim für eine
wirklich freie und gute Corba-Implementation zu werden wie es Gimp für
Gtk+ war. Aber wenn keiner mithilft dann halt nicht...
| ist. Es ist ein Unterschied, ob eine Bibliothek objektorientiert
| designed ist, oder ob irgendjemand irgendwann mal einen Wrapper um
| eine C Bibliothek gelegt hat
Schon mal in den Sourcecode reingeschaut?
Aus gtkobject.h:
/* GtkObject is the base of the object hierarchy. It defines
* the few basic items that all derived classes contain.
*/
struct _GtkObject
{
/* A pointer to the objects class. This will actually point to
* the derived objects class struct (which will be derived from
* GtkObjectClass).
*/
GtkObjectClass *klass;
/* 32 bits of flags. GtkObject only uses 4 of these bits and
* GtkWidget uses the rest. This is done because structs are
* aligned on 4 or 8 byte boundaries. If a new bitfield were
* used in GtkWidget much space would be wasted.
*/
guint32 flags;
/* reference count.
* refer to the file REFCOUNTING on this issue.
*/
guint ref_count;
/* The list of signal handlers and other data
* fields for this object.
*/
gpointer object_data;
};
/* GtkObjectClass is the base of the class hierarchy. It defines
* the basic necessities for the class mechanism to work. Namely,
* the "type", "signals" and "nsignals" fields.
*/
struct _GtkObjectClass
{
/* The type identifier for the objects class. There is
* one unique identifier per class.
*/
GtkType type;
/* The signals this object class handles. "signals" is an
* array of signal ID's.
*/
guint *signals;
/* The number of signals listed in "signals".
*/
guint nsignals;
/* The number of arguments per class.
*/
guint n_args;
/* The functions that will end an objects life time. In one way ore
* another all three of them are defined for all objects. If an
* object class overrides one of the methods in order to perform class
* specific destruction then it must still invoke its superclass'
* implementation of the method after it is finished with its
* own cleanup. (See the destroy function for GtkWidget for
* an example of how to do this).
*/
void (* shutdown) (GtkObject *object);
void (* destroy) (GtkObject *object);
void (* finalize) (GtkObject *object);
};
[X] Du hast vom USENET nichts verstanden.
Bernd.
Welche benutzt er denn nicht??
Bernd.
>Gar nicht mal. gtk ist im Gegenteil sehr stark an Qt orientiert. Der
>Signal-Slot-Mechanismus ist z. B. bei Qt abgekupfert. Die
Nach dem, was ich über Qt und gtk gehesg habe, handelt es sich bei GTK
um den Versuch, eine Klassenbibliothek in C zu implementieren.
Das hat unter anderen den Nachteil, daß man gtk ein seperates Toolkit
benötigt, um ein neues Widget zu erzeugen, während dies bei Qt
aufgrund des OO-Konzeptes ohne zusätzliche Tools geht.
mfg: Jochen Schmitt
>| ist. Es ist ein Unterschied, ob eine Bibliothek objektorientiert
>| designed ist, oder ob irgendjemand irgendwann mal einen Wrapper um
>| eine C Bibliothek gelegt hat
>Schon mal in den Sourcecode reingeschaut?
Aber bei gtk hast Du den Nachteil, daß Du den OO-Ansatz nur mit einen
höheren Aufwand nutzen kannst, da ja die Schnittstelle in C
Implementiert wurde.
mfg: Jochen Schmitt
| Genauer gesagt arbeitet rasterman daran, den gesamten Look&Feel-Code
| von GTK in eine einzelne shared lib auszulagern, so dass man das
| Aussehen von GTK beliebig gestalten kann, ohne an GTK selbst etwas
| aendern zu muessen (Themes).
Ich glaube nicht, daß er das schafft, da er ziemlich auf Pixmaps
fixiert ist. Die sind ziemlich resourcenfressend und unflexibel.
BG> j...@gmx.net (Jochem Huhmann) writes:
>> Fuer WindowMaker gilt aehnliches, auch wenn wohl kein WM direkt in in
>> Gnome aufgehen wird. Man will halt einfach die mwm-Hints benutzen, um
>> mit dem WM zu kommunizieren und bei Bedarf weitere Hints einfuehren.
BG>
BG> Na klar: Statt einfach die kwm-Hints zu übernehmen, muß man natürlich
BG> eigene, inkompatible erfinden. Ja, in einem muß man dir recht geben:
BG> gnome hat ein Konzept. Und das heißt "Möglichst inkompatibel mit KDE
BG> sein, und das um jeden Preis".
Nur dass es die mwm-Hints schon lange vor Gnome und lange vor KDE gab.
Wenn ich bei Gnome bald die Auswahl zwischen icewm, WindowMaker, fvwm2,
E und scwm habe, dann interessiert es mich nicht sonerlich, wenn ich kwm
nicht benutzen kann. So toll ist der ja nun doch nicht.
Deshalb unterstützt der kwm sie ja auch, nicht wahr?
> Wenn ich bei Gnome bald die Auswahl zwischen icewm, WindowMaker, fvwm2,
> E und scwm habe, dann interessiert es mich nicht sonerlich, wenn ich kwm
> nicht benutzen kann. So toll ist der ja nun doch nicht.
Die Auswahl kannst du heute schon bei KDE haben. Die zu ergänzenden
Hints sind exzellent dokumentiert. Dagegen weiß man ja bei GNOME
überhaupt nicht, was ein Windowmanager überhaupt zu leisten hat.
Es ist ja sehr bezeichnend, daß die Seite
http://freeweb.pdq.net/redline/wmhints/
mit "This page removed" anfängt.
Bernd.
Weiß ich nicht, aber das Bezugsposting (von von einem gewissen Bernd
Gehrmann, der Gnome offenbar nur aus seinen Vorurteilen kennt) warf
Gnome vor, dass es die mwm-Hints nutzt, statt die KDE-Hints zu
benutzen. Dann kannte er KDE also auch nicht, denn wenn KDE auch die
mwm-Hints nutzt, gibt es ja gar keine Probleme.
Bei den zusätzlich ggf. nötigen Hints ist die Gnome-Position übrigens,
dies mit dem wm-Maintainern abzusprechen, um ein tragfähiges und
allgemein akzeptiertes Konzept zu bekommen. Das hat KDE mit seinem
Einheits-wm natürlich nicht nötig.
Tschüss, Florian.
--
#!/bin/sh -
set - `type $0` 'tr "[a-m][n-z][A-M][N-Z]" "[n-z][a-m][N-Z][A-M]"';while [ \
"$2" != "" ];do shift;done;echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub \
signature|'`echo $1|$1`'`;rpub "Jr ner fvtangher bs Obet."'|$1|sh
peter.s...@gmx.net writes:
[...]
> Worin unterscheiden sich die verwendeten Libraries GTK und QT ?
>
> (ja ich weiss - QT ist Loehnwaere ausserhalb freier Software, GTK nicht.
> Ich moechte auch nur _funktionale und konzeptionelle_ Unterschiede
> sowie Funktionsumfang wissen )
Ich habe mir vor Urzeiten mal Qt gezogen (vor Version 1.0) und damit
rumgespielt, und ich muss sagen, ich war beeindruckt. Die Beispiele
haben funktioniert, mir ist kein Programm in der Library abgestürzt,
und der Port auf ein bis dato nicht unterstütztes System (AIX) war in
einer halben Stunde fertig.
Letzte Woche habe ich mal gtk+ ausprobiert, und nachdem das
Testprogramm testgtk mit SIGSEGV ausgestiegen ist (o.k., es das Signal
abgefangen und eine Diagnose geliefert), habe ich mich nicht
mehr drum gekümmert (ich habe keine Zeit, dem Fehler nachzugehen).
=> I am not impressed. Die Stabilität von Qt erscheint mir wesentlich
besser.
Den C++ Wrapper gtk-- habe ich dann gar nicht erst übersetzt (ich
arbeite in C++).
Meine 2 Pf.
-- kga
-------------------------------------------------------------------------
Klaus-Georg Adams Email: Klaus-Ge...@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie, Lehrstuhl II Tel: 49(0)721 608 3485
Universität Karlsruhe, D-76128 Karlsruhe
-------------------------------------------------------------------------
SZ> j...@gmx.net (Jochem Huhmann) writes:
SZ>
>| Genauer gesagt arbeitet rasterman daran, den gesamten Look&Feel-Code
>| von GTK in eine einzelne shared lib auszulagern, so dass man das
>| Aussehen von GTK beliebig gestalten kann, ohne an GTK selbst etwas
>| aendern zu muessen (Themes).
SZ>
SZ> Ich glaube nicht, daß er das schafft, da er ziemlich auf Pixmaps
SZ> fixiert ist. Die sind ziemlich resourcenfressend und unflexibel.
Er will es eben nicht Pixmap-basiert machen, sondern, wie ich schon
schrieb, den gesamten Code in eine shared lib auslagern. Die Probleme
mit Pixmap-basierten Themes sind ihm nach seiner Aussage durchaus
bewußt. Wenn Du magst, kannst Du Dir den schon bestehenden Code ja
ansehen, er liegt im Gnome-CVS.
Die Erfahrung mit testgtk wuerde ich als "Vorfuereffekt" einstufen.
Nach Durchsicht des gtk-Tutorias (ein Muss!) kann man nach meiner Meinung
mit gtk sehr gut arbeiten.
Die wahre Objektorientierung (man wollte am Ende der 60er halt nicht von
Klassenorientierung sprechen, gibt es noch einen allgemeineren Begriff
als Objekt?) ist anscheinend schwer zu fassen, aber irgendwie sollte
doch einfache Vererbung mit virtuellen Klassenhierarchien (C++slang)
bei wohlwollender Würdigung des gtk-Codes erkennbar sein.
Berücksichtigt man noch die vielen schon existierenden und
GUTAUSSEHENDEN Widgets, die existierenden Anbindungen an moderne
Programmiersprachen (z.B. objektorientiert: Eiffel,ObjC,C++,TOM,Python),
gibt es schon viele Gründe für die Linuxgemeinde, hauptsächlich gtk zu
verwenden.
Und was nützt dir ein Port, den du nicht verwenden darfst,um Programme
zu schreiben, die jemand außer dir benutzen soll?
Tschüss, Florian
Offenbar. Bei einigen Leuten scheint hier die Argumentation nach dem
Schema zu laufen "Ich setze mal ein Gerücht in die Welt, irgendwas
wird davon schon hängenbleiben."
Bernd.
Momnet, *DU* hast Gnome vorgeworfen, sie würden vorsätzlich die
Interoperabilität verhindern, weil sie mwm-Hints statt KDE-Hints
verwenden.
Tschüss, Florian.
> Ja sicher. Noch besser geht's in Assembler.
Mikrocode!
SCNR
Jens
--
Raise my eyes, she stands
Holding out healing hands
Irgendwer, der den Part übernehmen will, dass man auch mit C++ nicht
objektorientiert programmieren kann?
Der Fairness halber sollte man erwähnen, dass Troll diffs akzeptiert und
wohl auch einarbeiten wird...
Florian
>> und der Port auf ein bis dato nicht unterstütztes System (AIX) war in
>> einer halben Stunde fertig.
>
>Und was nützt dir ein Port, den du nicht verwenden darfst,um Programme
>zu schreiben, die jemand außer dir benutzen soll?
Wie kommst Du darauf, bei AIX handelt es sich doch um ein Unix-Derivat
von IBM, für das es sicher auch ein X gibt, so daß hierfür wohl die
freie X-Lizenz anwendbar sein dürfte.
mfg: Jochen Schmitt
Im Bezug auf C++ sind die GNOME/GTK Leute IMHO etwas jostisch
eingestellt. Nicht umsonst heißen die C++ Bindings für GTK "GTK--"...
--
************************************************************************
Julian Einwag - Herm-Loens-Str.9 - 96106 Ebern - wjei...@swin.baynet.de
Private homepage: http://www.swin.baynet.de/user/amon+einwag/
***** Send mail request for PGP key ************************************
> Marco Budde <Marco...@hqsys.antar.com> wrote:
> > CP> >Mmmm. gtk ist doch meines Wissens eine reine C-Library. Heisst das
> >
> > Genau, aber halt objektorientiert. Das geht ja auch in C.
>
> Ja sicher. Noch besser geht's in Assembler.
*vollunterschreib*
Falsch. Ich habe geschrieben:
> Na klar: Statt einfach die kwm-Hints zu übernehmen, muß man natürlich
> eigene, inkompatible erfinden
Da steht überhaupt kein Vorwurf drin, daß GNOME mwm-Hints verwendet.
Das wäre ja auch absurd, denn die mwm-Hints sind eine Untermenge von
dem, was kwm und so ziemlich jeder andere brauchbare Windowmanager
unterstützt. Wenn GNOME aber Interoperabilität nicht verhindern
wollte, könnten sie auch die anderen kwm-Hints benutzen, statt eigene
zu erfinden. Natürlich spricht nichts dagegen, eigene zu benutzen,
wenn kwm in irgendeinem Bereich Funktionalität fehlen würde. Solche
Überlegungen wurden aber nie angestellt. Stattdessen wurde von vorn-
herein gesagt: "Wir müssen etwas eigenes machen".
Bernd.
Windowmanager loeten?
Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
"Why don't elephants eat penguins ?
Because they can't get the wrappers off ..."
-- /usr/games/fortune
ich denke es ist offensichtlich, da"s Florian nicht auf das 'frei' in
der Qt-License im Sinne von 'Freibier' hinaus wollte, sondern auf die
Restriktion, da"s eigenh"andige "Anderung am Qt-Source und
anschlie"sende Verteilung des modifizierten Qt erstmal nicht erlaubt
sind. Das die Trolle sich diesbezgl. sicher kooperativ zeigen werden
und die "Anderungen nach einer Evaluierung in Qt einflie"sen lassen
ist jedoch anzunehmen. Irgendwie scheint mir, die meisten haben das
mit der 'free software' nicht so ganz verstanden und denken immer nur
in Kategorien wie Preis und Nutzungslizenz - sie sind von M$
anscheinend schon gut konditioniert worden ;-) Wie hie"s es noch so
sch"on treffend:
Think of the 'free' in free software as in 'free speech' and not as
in 'free beer'...
Insofern ist Qt - wenn auch brilliant - IMHO keine 'freie Software' im
oben genannten Sinne. Letztendlich mu"s jeder Entwickler selbst
entscheiden, ob er mit der Qt-Lizenz leben kann. Die Entwickler von
KDE k"onnen es offensichtlich und die von Gnome offensichtlich nicht -
wo liegt das Problem? Schlie"slich sollte jeder immer noch selbst
entscheiden, worin er seine Arbeitkraft steckt. Vorschriften zu
machen, ala nimm KDE oder nimm Gnome - im Extremfall dann auch noch
von 'Nur-Usern' - ist da v"ollig deplaziert.
Gru"s
Oliver
--
Oliver Flimm Email: fl...@ph-cip.uni-koeln.de
CipLab, Institutes of Physics fl...@ub.uni-koeln.de, fl...@guug.de
Cologne, Germany WWW : http://www.ph-cip.uni-koeln.de/~flimm
Man kann in Assembler nur unwesentlich besser programmieren als in C++.
Wie bekannt, ist C++ ja keine OO Sprache und als solche auch nicht entworfen
worden. Wer wirklich Objektorientiert Programmieren möchte, sollte dies
in Objective C oder Eiffel tun. Selbstverständlich kann man GTK auch
mit Objective C und Eiffel einsetzen.
Jost
> Wie bekannt, ist C++ ja keine OO Sprache und als solche auch nicht entworfen
> worden. Wer wirklich Objektorientiert Programmieren möchte, sollte dies
> in Objective C oder Eiffel tun. Selbstverständlich kann man GTK auch
> mit Objective C und Eiffel einsetzen.
>
> Jost
Hmm....C++ ist schon eine OO Sprache, auch wenn sie einen nicht dazu zwingt,
OO zu programmieren...
Harry
Florian Hars <Floria...@desy.de> writes:
>
> Klaus-Georg Adams <Klaus-Ge...@chemie.uni-karlsruhe.de> writes:
> > Ich habe mir vor Urzeiten mal Qt gezogen (vor Version 1.0) und damit
> [...]
> > und der Port auf ein bis dato nicht unterstütztes System (AIX) war in
> > einer halben Stunde fertig.
>
> Und was nützt dir ein Port, den du nicht verwenden darfst,um Programme
> zu schreiben, die jemand außer dir benutzen soll?
Das war doch wohl üble Rhetorik oder? Ich habe die Diffs per mail an
die Trolls geschickt, nach einer halben Stunde 'ne Rückfrage wegen
Groß- oder Kleinschreibung eines Makros erhalten, und in der nächsten
Release war der AIX Support drin.
=> Du hast nicht verstanden (oder willst es nicht verstehen) warum die
Trolls keine modifrisierten Version von Qt erlauben.
=> Ich mag Qt trotzdem nicht, hauptsächlich ist mir der moc
unsympathisch. Ausserdem haben sie Yet Another Library von
Containerklassen (o.k., damals gab es noch keine STL), aber IMHO
müssten sie das heute, im Jahr 1 nach ANSI C++ umstellen.
=> Und wenn ich mir ansehe, wie gtk+ programmiert ist, dann kann ich
nur drei Sachen sagen:
Ich hasse Makros.
Ich hasse Casts.
Wenn ich OO will, dann programmiere ich nicht in C. (Alles IMHO, YMMV,
do what you want, flames nach /dev/null)
Wenn es trotzdem funktioniert, schön. Aber wenn das Testprogramm
abstürzt... das erschüttert das Vertrauen doch etwas.
Vielleicht schaue ich mir gtk+ (und falls testgtk dann nicht abschmiert,
auch gtk--) in ein paar Monaten noch mal näher an.
| Nein, aber ungefaehr so wie in dem von Dir geposteten Abschnitt habe ich es
| mir vorgestellt. Was soll an den dargestellten Strukturen objektorientiert
| sein? Der Name der Strukturen?
Es wurden Vererbung, Kapselung von Daten und Algorithmen und
dynamische Messages dargestellt. Das sind meines Erachtens die
Grundlagen von OO.
| Merke: Bloss weil jemand etwas "object" nennt muss es noch lange nichts damit
| zu tun haben.
Merke: Erst wer in der Lage ist in C objektorientiert zu
programmieren, hat OO wirklich verstanden.
| Es gibt natuerlich viele Aspekte, die einen objektorientierten Ansatz
| ausmachen.
Die einen bei einer bestimmten Anwendung alle ziemlich egal sein
können, solange sie der Anwendung nichts bringen...
| Und einige dieser Aspekte lassen sich durchaus auch in C
| verwirklichen. Beim groessten Teil ist eine Nachbildung aber entweder
| unmoeglich, oder es ist ein immenset Aufwand des Programmierers selber
| notwendig, d.h. der Code ist fehlertraechtig und schwer zu warten.
Stammt die Standard-Antwort aus irgendeiner Supportdatenbank?
Manche Leute halten moc für das einzig gute an QT und Templates für
den letzten aufgeblasenen Blödsinn (warum zehn fast identische
Containerklassen, wenn es eine auch tun würde), aber über Geschmack
kann man ja trefflich streiten.
> Vielleicht schaue ich mir gtk+ (und falls testgtk dann nicht abschmiert,
> auch gtk--) in ein paar Monaten noch mal näher an.
Das warten dürfte nicht viel an Stabilität bringen, da sich in den
nächsten Monaten wohl nur die instabile Entwicklerversion ändern wird,
nicht die stabile 1.0.
| Das ist eine sehr höfliche Umschreibung von "Bei GNOME darf man als
| C++-Programmierer einen Spießrutenlauf durchmachen, gegen den sich
| die spanische Inquisition als barmherzig ausnimmt".
Nu übertreib mal nicht. Es programmieren auch einige mit gtk--
| Solche Überlegungen wurden aber nie angestellt. Stattdessen wurde
| von vornherein gesagt: "Wir müssen etwas eigenes machen".
Das Thema Windowmanager-Hints ist noch nicht abgeschlossen. Jetzt
abschließende Bewertungen zu publizieren, ist was für Leute, die
Konflikte zementieren wollen.
| Die Auswahl kannst du heute schon bei KDE haben. Die zu ergänzenden
| Hints sind exzellent dokumentiert. Dagegen weiß man ja bei GNOME
| überhaupt nicht, was ein Windowmanager überhaupt zu leisten hat.
Damit wäre ja jetzt eindeutig klar, daß dein einziges Ziel ist, Stunk
zu machen.
| Es ist ja sehr bezeichnend, daß die Seite
|
| http://freeweb.pdq.net/redline/wmhints/
|
| mit "This page removed" anfängt.
Die Gnome-Site fängt mit www.gnome.org an. Wenn es bei so einem jungen
Projekt wie Gnome überhaupt irgend etwas halbwegs Offizielles gibt,
dann allerhöchstens dort. Wobei ich die Definition von Offiziellem
lieber den KDE-Leuten überlasse. Gnome's Ziel ist Pluralität.
Übrigens: unter http://www.ping.de/sites/aibon/wmhints/ steht auch nix
zum Thema Window-Manager hints.
| Marco Budde <Marco...@hqsys.antar.com> wrote:
| > CP> >Mmmm. gtk ist doch meines Wissens eine reine C-Library. Heisst das
| >
| > Genau, aber halt objektorientiert. Das geht ja auch in C.
|
| Ja sicher. Noch besser geht's in Assembler.
Weder C noch C++ reichen für eine GUI. Das sollte ja wohl mitlerweile
jedem klar sein. Jetzt stellt sich die Frage, ob man lieber ein
aufgebohrtes C++ mittels MOC durch einen halbherzig optimierten
C++-Compiler jagt und dabei alle Vorzüge von C über Bord wirft, oder
ob man versucht, was für C zu programmieren, was dann natürlich
schreibintensiver ist aber ohne Probleme von dem wohl meistbenutzten
Compiler aller Zeiten optimiert werden kann. Gtk+ bewertet die
Einfachheit einer plain-C Implementation gegenüber einem
MOC-C++-Gespann nunmal höher als die Einfachheit des Sourcecodes. Und
wenn man eine richtige Hochsprache braucht, kann man ja Gtk+ in Guile
benutzen. Und für OO-Freaks gibt's auch andere Anbindungen zu
richtigen OO-Sprachen.
| Letzte Woche habe ich mal gtk+ ausprobiert, und nachdem das
| Testprogramm testgtk mit SIGSEGV ausgestiegen ist (o.k., es das Signal
| abgefangen und eine Diagnose geliefert), habe ich mich nicht
| mehr drum gekümmert (ich habe keine Zeit, dem Fehler nachzugehen).
| => I am not impressed. Die Stabilität von Qt erscheint mir wesentlich
| besser.
bei mir funktioniert Gimp prima. (mache inzwischen ganze Webserver damit)
Er sagte "strukturiert", _nicht_ "prozedural".
Korrektur: Erst wer in der Lage ist in C objectorientiert zu
programmieren, hat das C++ Objektmodell verstanden.
Wer Objective-C und Smalltalk kennt und deshalb die Vorzüge
eines vernünftigen Laufzeitsystems zu schätzen weiß, kann
über diese Art von Objektorientierung in C nur schmunzeln.
Wie Dilbert sagen würde: Zeit für einen Paradigmen-Wechsel...
-tr
--
Thorsten Roskowetz | E-mail: ro...@earthling.net
Nene, Relais werden gesteckt ...
Und wieder wech ...
Christoph
--
# Xelen - a PCB package for Linux
# http://www.uni-paderborn.de/StaffWeb/jogger
#
# Christoph Drube, Pohlweg 74/12, 33098 Paderborn
#
# email: jog...@uni-paderborn.de
> AL> Einigermaben ahnlich sehen die Sachen ja schon aus, jetzt mubten nur
> AL> noch Dinge wie Drag & Drop funktionieren oder ein einheitliches
>
> Sowas wie DnD sollte man am besten in ein voellig getrennte Bibliothek
> auslagern, so dass auch die Programmierschnittstelle ueberall gleich ist.
> Und die Bibliothek sollte dann auch gleich noch andere DnD Protokolle wie
> CDE DnD verstehen.
>
Hi !
Mhh, ich hab mir die XDnD-Specs gesaugt. Ich werde mal fuer Tk eine
Library beginnen ...
Du meinst die Graphiken, welche die Server rausblasen? Ich gehe davon aus,
dass Du keine Executables zusammenpixelst. 8)