UserLinux

[BeS]

Hallo,

Ehrlich gesagt kann ich mir auch nicht vorstellen wie bei GNOME die zugrunde liegende Technik jemals besonders gut sein soll, wenn das DE im wesentl. aus völlig getrennt entwickelten Programmen besteht deren Hauptgemeinsamkeit letztlich eigentlich nur GNOME's HIG und GTK sind.

Naja, dass kommt wohl auch auf den Standpunkt an. Was verstehst du unter Technik? Tendenziell kann man vielleicht sagen das sich OOP und C++ eher für eine GUI eignen und ich bin auch immer wieder beeindruckt in welchen relativ kurzen Abständen neue KDE Versionen herauskommen und diese auch immer wirklich tolle neue features dabei haben.
Auf der anderen Seite ist aber KDE/QT ziemlich auf C++ beschränkt. Wenn man etwas programmieren will, ist man also zu einem großen Teil, darauf angewiesen das man C++ kann.
Bei GTK+ finde ich es dagegen sehr interessant wie man mit wirklich vielen Sprachen relativ einfach ein Fenster auf den Bildschirm bekommt. Wenn z.B. ein Perl Programmierer mal eine kleine GUI zu seinem Programm schreiben will ist das kein Problem:

Code: Alles auswählen

use Gtk;
init Gtk;

my $window = new Gtk::Window( "toplevel" );
$window->show_all();
main Gtk;

und schon hat er sein Programm in eine GUI gepackt. Will er das ganze in ein QT/KDE Programm verpacken, dann ist das schon nichtmehr so trivial.
Das würde ich schon auch als technischen Punkt sehen und hier hat GTK einen Vorteil.

Letztlich wird es wohl immer eine Geschmacksfrage bleiben. Ob gnome KDE aber jemals in den Features oder der Kompaktheit/Integrierung einhohlen oder überholen wird, wage ich zu diesem Zeitpunkt mal zu bezweifeln. Auf der anderen Seite wird gnome/gtk wohl auf der Technischen- oder Programmiererseite immer einen gewissen Vorteil haben, da das Toolkit eben nicht so stark an eine Sprache gebunden ist wie QT.


PS: Der Artikel hört sich wirklich interessant an, ich bin mal gespannt ob KDE 3.2 wirklich so schnell sein wird...

[Bert]

Es gibt auch für QT Bindings für Perl, Python, Java,... Da seh ich keinen Unterschied.

[BeS]

Hallo,

Es gibt auch für QT Bindings für Perl, Python, Java,... Da seh ich keinen Unterschied.

ich habe aber schon oft von Leuten die QT und GTK kennen gelesen, dass die verschiedenen Bindings bei QT nicht so gut umgesetzt sind und eher etwas "Stiefmütterlich" behandelt werden. Das soll u.a. auch daran liegen, dass QT schon sehr stark auf C++ setzt und verschiedene Konstrukte nur schwer auf andere Programmiersprachen abzubilden sind. Da soll es dann GTK zu gute kommen, dass es sehr modular und unabhängig aufgebaut ist.

Aber persönlich habe ich da noch keine Erfahrung gemacht. Wenn du da andere Erfahrungen hast, bin ich an gegenteiligen Meinungen immer interessiert.

[Bert]

Erfahrungen leider nicht. Leider reicht meine Zeit / Lust nach 8+ Stunden auf Arbeit Programmieren dann meistens nicht mehr sehr weit, jedenfalls nicht weit genug da selber aktiv zu werden.

Hab halt nur Berichte gelesen und Beispiele angeschaut und etwas mit QT Rumgespielt. (in C++) Mir persöhnlich gefällt dabei auch vom Programmierstil die QT Weise besser. Aber das mag daran liegen, das ich C nicht sonderlich mag (C++) dagegen schon

[Sturmkind]

Hallo,

gestern auf Pro-Linux.de gelesen:


Debian und KDE kündigen strategische Partnerschaft an
=> http://www.pro-linux.de/news/2003/6285.html

Debian und das KDE-Projekt werden morgen eine engere Kooperation beider Projekte ankündigen.

Hintergrund der Kooperation soll laut Informationen von Pro-Linux die erst kürzlich von Bruce Perens vorgestellte UserLinux-Strategie sein, die GNOME als Desktop-Umgebung propagiert und KDE lediglich optional erwähnt. Daher will das KDE-Projekt die Desktop-Umgebung an die Debian-Distribution anpassen und um zusätzliche Tools für geschäftliche Belange erweitern. Im Einzelnen planen die Entwickler, KDE um einen Kiosk-Modus zu erweitern, der eine bessere Steuerung der Zugriffe und Freigaben unter KDE regeln wird. Ferner will KDE ein neues und einfacheres Tool zur Konfiguration des Systems erstellen. Das Tool wird Administratoren erlauben, Benutzerrechte und Einstellungen auch in großen Umgebungen und für nicht-KDE-Anwendungen zu setzen und zu überwachen. Ein integrierter Terminal-Server und -Client für neue und effizientere Kompression unter X, ein verbessertes KDE-Print, sowie neue Applikationen wie Kontact mit Kolab-Server und KERP, runden das Angebot ab.

Eine weitere Neuerung, die die neue strategische Ausrichtung des Projektes kennzeichnen wird, stellt ein UserLinux Installer-Frontend dar, das sich im Moment erst in der Planungsphase befindet. Als Basis soll nach Informationen des KDE-Teams der bereits bestehende Ark-Linux-Installer dienen. GUI-Tools zur Konfiguration des Systems, die direkt in die Desktop-Umgebung eingebunden werden werden, sollen zudem eine intuitivere Arbeit ermöglichen und die Nutzung von Debian-Technologie wie DebConf ermöglichen.

Eine der wohl wichtigsten Bestrebungen des Teams soll eine bessere Integration von GTK+ und GNOME-Anwendungen unter KDE darstellen. Dabei werden sich die Entwickler auf bereits bestehende Lösungen wie Geramik stützen und zusätzlich weitere Lösungen entwickeln. Dazu gehören unter anderem eine bessere Integration von OpenOffice.org und Mozilla unter dem K Desktop Environment.

Die im Moment nur zum Teil realisierten und sich teilweise erst im »Proposal«-Status befindenden Änderungen sollen laut Angaben der KDE-Entwickler für alle Parteien Vorteilhaft sein. Zum einen wird das Projekt UserLinux, das auf Debian basieren wird, helfen und zum anderen allen Debian-Nutzern eine Integration von KDE ermöglichen, die bis dato in keiner anderen Distribution möglich war.

Update: demon (17:56): Mehr Informationen im "Papier" der Entwickler.

Update2: demon (22:45): Eine offizielle Ankündigung finden Interessenten ab sofort auf Seite von dot.kde.org.


Na da hoffe ich wen es wirklich spezielle Debian Systemtools geben wird das diese als Module im Kontrollzentrum eingebunden sind so das die Konfiguration übersichtlich und zentral erreichbar ist.

Grüße
Sturmkind

[Bert]

Nun, den kompleten Text hatten wir in dem Thread schon.
Aber danke fürs erneute Abtippen

[DavidJ]

>Naja, dass kommt wohl auch auf den Standpunkt an. Was verstehst du unter Technik? Tendenziell kann man vielleicht sagen das sich OOP und C++ eher für eine GUI eignen und ich bin auch immer wieder beeindruckt in welchen relativ kurzen Abständen neue KDE Versionen herauskommen und diese auch immer wirklich tolle neue features dabei haben.

Ich habe bei "Technik" nichts bestimmtes im Sinn. Da ich aber häufig Sachen gelesen habe, in denen der Eindruck vermittelt wird, dass KDE mehr aus einem Guss ist und sich viele Sachen ohne viel Aufwand ändern ließen und GNOME dann mehr oder weniger als Gegensatz dazu herangezogen wird, dachte ich mir es wäre tendenziell was dran. Kurz, ich habe etwas für bare Münze genommen, ohne selbst die Kompetenz zu einem Urteil zu haben.

Und dass GNOME teilweise wirklich Programme enthält die, mehr oder weniger, fremdentwicklungen sind stimmt ja nunmal. Ich erkenne bei GNOMEs Zusatzprogrammen oft nicht etwas, was mir das Gefühl gibt, dass sie tatsächlich zusammengehören.
Als Gegenbeispiel könnte ich hier den Browser Epiphany nennen, wobei ich ihn noch nicht sonderlich genutzt habe. Mozilla bzw. Mozilla-Firebird ist für mich einfach zu sehr der perfekte Browser

Oder dass Evolution im nächsten GNOME Release drin sein soll wundert mich. Das Teil ist von einem Programm das übersichtlich ist und einfach funktioniert 'ne ganze Ecke entfernt. Wenn ich hier zum Vergleich nochmal Epiphany heranziehe dann fällt einfach auf dass Epiphany seine Aufgabe gut erfüllt ohne einem im Weg zu sein, einfach und funktional - genau die Art von Programm die man einem normalen User empfehlen kann. Evolution hingegen ist doch sehr umfangreich und vom Just Works Ansatz doch noch zu weit entfernt.


Das oben geschriebene bitte mit einem "IMHO" lesen.


>Auf der anderen Seite ist aber KDE/QT ziemlich auf C++ beschränkt. Wenn man etwas programmieren will, ist man also zu einem großen Teil, darauf angewiesen das man C++ kann.

Wie bereits vorher gesagt, ich kann das ganze nicht von einem wirklich kompetenten Standpunkt beurteilen. Habe lediglich viel darüber gelesen, wobei man auch sehen muss, dass häufig ein gewisser Eindruck von den Autoren von Artikeln, etc. vermittelt werden möchte. Als Beispiele seien hier die gern bemühten Punkte, "pauschale Überlegenheit GNOMEs in Sachen UI" und "pauschale überlegenheit KDEs in Sachen "Technik"", genannt.
Es sind irgendwie Mantras die ständig von den "Parteien" runter gebetet werden - Mal geschieht dies eher subtil, mal eher als direkte Aufstellung von sog. Fakten. Eine richtige, sprich, umfangreiche, tiefgehende und sachliche Gegenüberstellung der realen Tatsachen zu den Themen UI und zugrunde liegender Techniken habe ich leider noch nirgendwo entdeckt. Aber sowas wäre wohl auch eine extrem umfangreiche Arbeit.


Naja, irgendwann fängt man dann an selbst allgemeine Aussagen zu treffen ohne wirklich Ahnung zu haben.

[BeS]

Hallo,

Und dass GNOME teilweise wirklich Programme enthält die, mehr oder weniger, fremdentwicklungen sind stimmt ja nunmal. Ich erkenne bei GNOMEs Zusatzprogrammen oft nicht etwas, was mir das Gefühl gibt, dass sie tatsächlich zusammengehören.
Als Gegenbeispiel könnte ich hier den Browser Epiphany nennen, wobei ich ihn noch nicht sonderlich genutzt habe. Mozilla bzw. Mozilla-Firebird ist für mich einfach zu sehr der perfekte Browser

Oder dass Evolution im nächsten GNOME Release drin sein soll wundert mich. Das Teil ist von einem Programm das übersichtlich ist und einfach funktioniert 'ne ganze Ecke entfernt. Wenn ich hier zum Vergleich nochmal Epiphany heranziehe dann fällt einfach auf dass Epiphany seine Aufgabe gut erfüllt ohne einem im Weg zu sein, einfach und funktional - genau die Art von Programm die man einem normalen User empfehlen kann. Evolution hingegen ist doch sehr umfangreich und vom Just Works Ansatz doch noch zu weit entfernt.

Also zu evolution kann ich jetzt nichts negatives sagen. Ich verwende zwar zu 99% mutt, habe mir aber auch schon das eine oder andere mal evolution angesehen und fand es eigentlich ganz nett.

Aber hier kommt man sicher auch an einen Punkt, wo die Frage aufkommt was überhaupt zu einer DE gehöhrt? Gehören dazu wirklich auch solche Sachen wie Browser, mailclient, office Programme,...?
Man könnte ja auch sagen das es KDE übertreibt, da gibt es z.B. schon Programme um verschiedene Medien abzuspielen (xmms, xine, mplayer,...) und dann wird bei KDE nochmal neue Programme entwickelt (noatun, kaboodle,..)
Auf der anderen Seite sind das dann aber natürlich genau die Sachen, die KDE einheitlich aussehen lassen.

Letztlich kann man die Frage nie allgemeingültig beantworten.
Für mich gehört zu einer DE in erster Linie: ein windowmanager, panals und desktop-icons die man möglichst flexibel anordnen kann und ein filemanager.

Alles andere sind für mich Zusatzprogramme, die aber nicht wirklich zu einer DE gehören.

Es sind irgendwie Mantras die ständig von den "Parteien" runter gebetet werden - Mal geschieht dies eher subtil, mal eher als direkte Aufstellung von sog. Fakten. Eine richtige, sprich, umfangreiche, tiefgehende und sachliche Gegenüberstellung der realen Tatsachen zu den Themen UI und zugrunde liegender Techniken habe ich leider noch nirgendwo entdeckt. Aber sowas wäre wohl auch eine extrem umfangreiche Arbeit.

Ich glaube das kann man auch garnich sachlich und eindeutig klären. Es fängt ja schon mit der Definition an was direkt zu einer DE gehört.
Und auch beim Toolkit kommt natürlich ein C++ Programmierer wahrscheinlich eher zu einem anderen Ergebnis als ein C Programmierer...

Man kann aus seiner perspektive versuchen die Situation zu beschreiben, es kann aber nie eine allgemeine Aussage sein die für alle zutrifft.

Hier gibt es z.B. eine Seite die versucht hat die beiden Toolkits sachlich zu vergleichen, wobei es einem meiner Meinung nach bei der Entscheidung auch nicht wirklich hilft: http://www.asiaosc.org/article_17.html

PS: Aus technischer Sicht ist mir noch zwei mögliche Vorteil von GTK eingefallen:
1. Man kann GTK Programme auch in der Konsole im framebuffer Modus verwenden
2. Das Toolkit ist in zwei Teile aufgeteilt, alles was man braucht um die Fenster zu zeichnen und den Rest. Dadurch kann man die netten Funktionen der glibs wie glist, gtree,... auch in consolen-Programmen verwenden.

[Bert]

Nun, für mich gehören neben einem Einheitlichen Look&Feel auch solche Sachen wie funktionierendes Copy&Paste zu einem DE. Idealer Weise auch EIN Editor, der in andere Anwendungen eingebetet werden kann, so daß ich nicht in jeder Anwendung erst suchen muß, wie denn nun Suchen/Ersetzen funktioniert.

2. Das Toolkit ist in zwei Teile aufgeteilt, alles was man braucht um die Fenster zu zeichnen und den Rest. Dadurch kann man die netten Funktionen der glibs wie glist, gtree,... auch in consolen-Programmen verwenden.

Sowas hat man in C++ ja sehr elegant duch die STL gelöst

[Bert]

lol Hab mir gerade mal den Link oben angeschaut.
Bes: Das ist nicht Dein Ernst oder? Der Vergleich ist ja mehr als nur oberflächlich.

am new to GUI development in GNU/Linux, but personally i feel that using GTK will be faster in both compilation and execution time.

But the development of QT seems to be faster than GTK.

Naja. Ich hatte mich schon gefreut, mal einen ordentlichen Vergleich zu sehen, da meine Meinungsbildung bezüglich GTK (von der technischen Seite her) doch etwas länger her ist und ich meine Meinung gerne überprüft hätte. Hmm, so wichtig ist es ja auch wieder nicht

[BeS]

Hallo,

lol Hab mir gerade mal den Link oben angeschaut.
Bes: Das ist nicht Dein Ernst oder? Der Vergleich ist ja mehr als nur oberflächlich.

sicher ist es nicht viel, habe auch selber geschrieben das es einem bei der Entscheidung wohl nicht weiter helfen wird. Es ist aber immerhin mal der Versuch ein paar Daten tabellarisch gegenüberzustellen. Wenn man sonst nach "QT vs. GTK" sucht finden man ja nur Diskussionen wo GTKler und QTler versuchen sich gegenseitig schlecht zu machen. Also ich habe bisher zumindest nichts wiklich gutes finden können und da stellt der Link oben zumindest mal ein paar Daten gegeneinander um einen generellen Überblick zu erhalten...
Zumindest das objektivste was ich bisher, neben den ganzen flames, gefunden habe.

Aber wie ich oben geschrieben habe, glaube ich das man die beiden Toolkits/DEs eh nicht ausschließlich objektiv und sachlich vergleichen kann.