1. Wenn E17 jetzt schon eine komplette Desktopumgebung ist ("nur noch nicht ganz fertig"), frage ich mich, warum man von niemandem hört, dass er auch nur eine Komponente davon verwendet.
2. Die EFL sind revolutionär und haben komplett neue Ideen -- naja, wenn ich mir die Beispielprogramme so ansehe, dann sieht das von den APIs aus wie GTK+ 1.x. Wenn man die saubere und simple objektorientierte C-Programmierung mit GObject und GTK+ 2.x gewohnt ist, sieht das nach einem Rückschritt aus. (Dass das Ganze untendrunter performancemäßig was kann, streite ich nicht ab.)
3. Inwiefern die GNOME-APIs in einer Weise "verkrüppelt" sein sollen, wie die EFL das nicht sind, wüsste ich in diesem Bezug dann gerne. Fakt ist, dass du GTK+/GNOME mit ungefähr drei, vier Handvoll Grundfunktionen programmieren kannst, wenn du eine Klassen- und Propertyreferenz hast. Die EFL scheinen mir voller Generator- und Akzessorfunktionen, eben wie GTK+ 1, und was daran gut sein soll, muss mir jemand mal erklären. Wenn man in den Code z.B. der EWL reinsieht, fragt man sich die ganze Zeit, warum die Leute da ihr eigenes GTK stricken wollen. M.E. wäre es für die E17er vernünftiger gewesen, ggf. an der Optimierung und/oder Backend-Abstraktion von GTK+ mitzuarbeiten und ihre Anwendungen dann darauf aufzubauen, statt einen kompletten neuen Stack an Bibliotheken hochzuziehen. So muss da eben eine ganze Reihe Räder neu erfunden werden, es sei denn, solche Sachen wie Barrierefreiheit, Unterstützung für linksläufige und/oder nichtlateinische Schriftsysteme etc. sind für die coolen E17-Hacker eh nur Ballast.
1. weil es ja relativ neu und noch nicht so bekannt ist, dass dauert seine Zeit. Es gibt ausserdem schon ein paar funktionierende Projekte die die EFL verwenden (File Manager, Login Manager, Photo Viewer, etc.), auf der Enlightenment Homepage findest du sie.
2. Damit meinte ich dass der OO Ansatz der GTK API (in C umgesetzt) aufgesetzt, unnatürlich und verkrüppelt wirkt. Die EWL verfolgt hier einen Stil der wesentlich schlanker und C-freundlicher ist ohne dass die Libraries mies strukturiert sind. Mir scheint es als ob das GTK-Team hier unbedingt alles in OOP durchziehen wollte - obs passt oder nicht (IMHO weitere Arme OOP-Hype geschädigte). Versteh mich nicht falsch - ich mag die GTK API's, aber jedesmal wenn ich neue GObject's anlegen muss läuft es mir kalt den Rücken hinunter.
Ausserdem: du meinst die Ideen der EFL sind nicht revolutionär weil die API's deiner Meinung nach altbacken sind????? Lies deinen ersten Satz (ab 2.) bitte nochmal und überleg dir mal wie sinnvoll er ist. Schau dir mal die EFL genauer an dann kommst du vielleicht selber darauf wieso einige davon so begeistert sind.
3. siehe 2, Irgendwie wird hier alles wild durcheinander verglichen - Sorry ich hab hier den Fehler gemacht GNOME APIs mit EFL (E's Bibliotheken - ALLE) APIs zu vergleichen, nicht wirklich sinnvoll da beide nicht direkt vergleichbar sind da sie verschiedene Funktionalitäten anbieten.
Was man jedoch vergleichen kann ist die EWL (E's Widget Library) und GTK - hier ist deine Argumentation irgendwie komisch da sich, für den Anwendungentwickler (wenn es um die Basiswidgets geht) in GTK+2 gegenüber GTK+1 kaum was verändert hat (was die APIs angeht). Jeder kann hier selbst vergleichen: GTK+1.2 Tutorial vs GTK+2 Tutorial. In GTK+2 ist jedoch wesentlich mehr Funktionalität hinzugekommen (vor allem Pango u. ATK) - da von Anfang an klar war dass die Funktionalität in GTK+2 nicht mehr verwaltbar ist haben sie ein komplettes Objektmodell (mit Vererbung, Polymorphie, Laufzeittypenüberprüfung, etc.) geschaffen - GObject, was mein eigentlicher Kritikpunkt an GTK ist da hier IMHO ein zusätzlicher Layer an Komplexität geschaffen wurde der sich nicht gut in die C Sprache einfügt. Für die meisten Anwendungsentwickler ist das ziemlich egal, für diejenigen die die GTK (bzw. GNOME) Bibliotheken erweitern wollen (z.B. neue Widgets screiben) nicht, da sie direkt damit arbieten müssen.
Die APIs der EWL sind aus der Sicht des Entwicklers denen von GTK ziemlich ähnlich - hier wurde wirklich dupliziert (APIs muss man ja schreiben - da hat man sich an Bekanntem orientiert - weise, nicht?). Allerdings wollte das E Team über alles dagewesene hinaus (was sie IMHO auch geschafft haben) und somit ist die EWL (und auch die EFL) wesentlich flexibler, schlanker und schneller als vergleichbare SW. Du sieht also dass hier nicht wirklich viel dupliziert worden ist. GTK/GDK wären hier als Basis viel zu inflexibel gewesen. Sachen wie die Unterstützung für linksläufige und/oder nichtlateinische Schriftsysteme (Pango für GTK-basierte System) werden glaube ich von Etox (E's Text-Layout Bibliothek) unterstützt, sicher bin ich mir hier allerdings nicht. Das mit der Barrierefreiheit weis ich wirklich nicht - ich hoffe doch dass irgendwann einmal ATK (ist ja unabhängig von GTK) unterstützt wird.
Deine Aussage "die coolen E17-Hacker" sagt eh schon vieles über dich aus, besonders deine Vorurteile gegenüber ihnen. Dabei haben sie einfach nur andere Ziele als GTK, QT & Co. und sie arbeiten sehr hart für Leute wie mich um einen angenehm benutzbaren, gut aussehenden und flexiblen Desktop zu kreieren. Danke!
2. Die EFL sind revolutionär und haben komplett neue Ideen -- naja, wenn ich mir die Beispielprogramme so ansehe, dann sieht das von den APIs aus wie GTK+ 1.x. Wenn man die saubere und simple objektorientierte C-Programmierung mit GObject und GTK+ 2.x gewohnt ist, sieht das nach einem Rückschritt aus. (Dass das Ganze untendrunter performancemäßig was kann, streite ich nicht ab.)
3. Inwiefern die GNOME-APIs in einer Weise "verkrüppelt" sein sollen, wie die EFL das nicht sind, wüsste ich in diesem Bezug dann gerne. Fakt ist, dass du GTK+/GNOME mit ungefähr drei, vier Handvoll Grundfunktionen programmieren kannst, wenn du eine Klassen- und Propertyreferenz hast. Die EFL scheinen mir voller Generator- und Akzessorfunktionen, eben wie GTK+ 1, und was daran gut sein soll, muss mir jemand mal erklären.
Wenn man in den Code z.B. der EWL reinsieht, fragt man sich die ganze Zeit, warum die Leute da ihr eigenes GTK stricken wollen. M.E. wäre es für die E17er vernünftiger gewesen, ggf. an der Optimierung und/oder Backend-Abstraktion von GTK+ mitzuarbeiten und ihre Anwendungen dann darauf aufzubauen, statt einen kompletten neuen Stack an Bibliotheken hochzuziehen. So muss da eben eine ganze Reihe Räder neu erfunden werden, es sei denn, solche Sachen wie Barrierefreiheit, Unterstützung für linksläufige und/oder nichtlateinische Schriftsysteme etc. sind für die coolen E17-Hacker eh nur Ballast.
2. Damit meinte ich dass der OO Ansatz der GTK API (in C umgesetzt) aufgesetzt, unnatürlich und verkrüppelt wirkt. Die EWL verfolgt hier einen Stil der wesentlich schlanker und C-freundlicher ist ohne dass die Libraries mies strukturiert sind.
Mir scheint es als ob das GTK-Team hier unbedingt alles in OOP durchziehen wollte - obs passt oder nicht (IMHO weitere Arme OOP-Hype geschädigte). Versteh mich nicht falsch - ich mag die GTK API's, aber jedesmal wenn ich neue GObject's anlegen muss läuft es mir kalt den Rücken hinunter.
Ausserdem: du meinst die Ideen der EFL sind nicht revolutionär weil die API's deiner Meinung nach altbacken sind????? Lies deinen ersten Satz (ab 2.) bitte nochmal und überleg dir mal wie sinnvoll er ist.
Schau dir mal die EFL genauer an dann kommst du vielleicht selber darauf wieso einige davon so begeistert sind.
3. siehe 2,
Irgendwie wird hier alles wild durcheinander verglichen - Sorry ich hab hier den Fehler gemacht GNOME APIs mit EFL (E's Bibliotheken - ALLE) APIs zu vergleichen, nicht wirklich sinnvoll da beide nicht direkt vergleichbar sind da sie verschiedene Funktionalitäten anbieten.
Was man jedoch vergleichen kann ist die EWL (E's Widget Library) und GTK - hier ist deine Argumentation irgendwie komisch da sich, für den Anwendungentwickler (wenn es um die Basiswidgets geht) in GTK+2 gegenüber GTK+1 kaum was verändert hat (was die APIs angeht). Jeder kann hier selbst vergleichen: GTK+1.2 Tutorial vs GTK+2 Tutorial. In GTK+2 ist jedoch wesentlich mehr Funktionalität hinzugekommen (vor allem Pango u. ATK) - da von Anfang an klar war dass die Funktionalität in GTK+2 nicht mehr verwaltbar ist haben sie ein komplettes Objektmodell (mit Vererbung, Polymorphie, Laufzeittypenüberprüfung, etc.) geschaffen - GObject, was mein eigentlicher Kritikpunkt an GTK ist da hier IMHO ein zusätzlicher Layer an Komplexität geschaffen wurde der sich nicht gut in die C Sprache einfügt. Für die meisten Anwendungsentwickler ist das ziemlich egal, für diejenigen die die GTK (bzw. GNOME) Bibliotheken erweitern wollen (z.B. neue Widgets screiben) nicht, da sie direkt damit arbieten müssen.
Die APIs der EWL sind aus der Sicht des Entwicklers denen von GTK ziemlich ähnlich - hier wurde wirklich dupliziert (APIs muss man ja schreiben - da hat man sich an Bekanntem orientiert - weise, nicht?). Allerdings wollte das E Team über alles dagewesene hinaus (was sie IMHO auch geschafft haben) und somit ist die EWL (und auch die EFL) wesentlich flexibler, schlanker und schneller als vergleichbare SW. Du sieht also dass hier nicht wirklich viel dupliziert worden ist. GTK/GDK wären hier als Basis viel zu inflexibel gewesen.
Sachen wie die Unterstützung für linksläufige und/oder nichtlateinische Schriftsysteme (Pango für GTK-basierte System) werden glaube ich von Etox (E's Text-Layout Bibliothek) unterstützt, sicher bin ich mir hier allerdings nicht.
Das mit der Barrierefreiheit weis ich wirklich nicht - ich hoffe doch dass irgendwann einmal ATK (ist ja unabhängig von GTK) unterstützt wird.
Deine Aussage "die coolen E17-Hacker" sagt eh schon vieles über dich aus, besonders deine Vorurteile gegenüber ihnen. Dabei haben sie einfach nur andere Ziele als GTK, QT & Co. und sie arbeiten sehr hart für Leute wie mich
um einen angenehm benutzbaren, gut aussehenden und flexiblen Desktop zu kreieren. Danke!