Ist gnome dermaßen Stark am Desktop vertretten das sich der Aufwand lohnt? ich meine es gibt noch XFCE, was bei Debian zum Standard wird, und noch viele andere wie MATE, KDE, LXDE usw.
Ich dachte Gnome3 ist nicht gerade die beliebteste DE oder?
Das scheint dem Entwickler egal zu sein. "Insellösung" und "nicht erweiterbar" passt genau in mein derzeitiges Bild von Gnome und ist damit IMO die konsequente Fortführung der Gnome-Philosophie.
Das sehe ich auch so. Das Bedarf bei den Entwicklern da ist, nicht selbst mit der Shell konfrontiert zu werden, kann ich mir gut vorstellen. Entwickler sind ja auch Nuzter.
Das jetzt eine allein auf Gnome 3 spezialisierte IDE entwickelt wird ist ein Zeichen, dass dem Gnome 3 Projekt die Entwickler davonlaufen und man nun versucht, mit einem Leckerbissen, nämlich dieser IDE, dem Entwicklerschwund gegenzusteuern. Das ist jedenfalls meine Meinung dazu.
Der im Artikel genannte Entwickler hat natürlich auch noch seine private Motivation dazu, keine Frage. Die spielt ebenfalls noch eine kleine Rolle, dennoch würde ich die jetzt aber nicht allzu sehr gewichten.
Das jetzt eine allein auf Gnome 3 spezialisierte IDE entwickelt wird ist ein Zeichen, dass dem Gnome 3 Projekt immer beliebter wird und man nun versucht, mit einem Leckerbissen, nämlich dieser IDE, dem Interesse der User gerecht zu werden.
Im Grunde gibt es für beide Möglichkeiten hier wohl keine Datengrundlage.
Wenn man mehr Entwickler gewinnen will, sollte man sich eher öffnen, statt sich zu isolieren. Ein eingeschränktes Entwicklungswerkzeug, was für alles andere nutzlos ist, ist unterm Strich nutzlos. Kein Entwickler will sich noch eine IDE auf die Kiste packen.
Wo steht das diese IDE mehr Entwickler zu Gnome bringen soll? Diese IDE wird von einem Gnome Entwickler für Gnome Entwickler gebaut. Bist Du Gnome Entwickler, dass Du für diese sprechen kannst?
Gnome3 ist jedenfalls nicht mehr so beliebt wie einst Gnome2. In den meisten Distros ist es dennoch als Zweit- oder Dritt-DE mit dabei, da man nachwievor den Gnomeunterbau für viele Anwendungen benötigt, die unter anderen DEs gebraucht werden.
Wie vielen Prozent Nutzern es dabei überhaupt auffallen würde, wenn die Gnome3-GUI gar nicht in startfähigem Zustand mit dabei wäre, ist schwer zu sagen. In den meisten "Haupt-Distros" dürfte dieser Wert aber weit unter 50% liegen, vielleicht mit Ausnahme Fedoras und Debians.
Wenn aber der Autor meint, dass er nun diese "Insellösung" unbedingt programmieren müsse, dann nur zu. Schaden wird Ihm dieses Unterfangen ganz bestimmt nicht.
Die ganzen anderne Desktop-Umgebungen, wie Unity, XFCE, MATE, LXDE usw. benutzen die GNOME-Bibliotheken. Das ist eine anderer Oberfläche, aber derselbe Unterbau. Und genau hier sehe ich das Problem: Mit Ausnahme von vielleicht Unity haben die anderen Projekte nicht genügend Entwickler, ihre Umgebung auf eigene Beine zu stellen. Daher sind diese immer von GNOME abhängig und werden wohl nie relevant werden.
Dass GNOME eine IDE bringt, war schon lange geplant und entspricht der Strategie, eine "Plattform" bereitzustellen, auf der Apps aufsetzen können. Einzige Alternative sind hier die KDE Frameworks. Und das könnte durchaus Entwickler anlocken, da man jetzt eine einheitliche Plattform hat und nicht ein Sammelsurium von Bibliotheken, wo man sich erst das passende raussuchen muss.
Unity hat schon oft die technische Grundlage gewechselt. Erst Clutter, dann Nux, dann parallel Qt für Unity 2D, dann Qt wieder eingestellt, und jetzt doch wieder Qt, wobei die Nux-Variante eingestellt wird. Fertig soll das erst 2016 werden. Kein Wunder, Unity war bisher GNOME 3 mit einem anderen Fenstermanager (Compiz), und die Unity Shell läuft als Compiz-Plugin. Die müssen im Prinzip von vorn anfangen.
LXDE fusioniert mit Razor Qt, was sich sicher auch noch eine Weile hinzieht.
Die Stärke von Qt liegt in der Plattformunabhängigkeit, die Philosophie dahinter ist ähnlich wie bie Java. Gtk und GLib dagegen zielen darauf, möglichst gute Integration in GNOME zu gewährleisten, und das wurde in letzter Zeit sehr ausgebaut, man kriegt mit GNOME derzeit einen sehr konsistenten Desktop hin.
Bei allem Respekt für den Entwickler, der offenbar einen (persönlichen) Traum leben wird und will: Was zum Geier soll denn eine IDE *ohne* Schnittstellen? Gerade im Bereich der Softwareentwicklung kommen (und gehen!) Technologien schneller, als man das in einer IDE wirklich nachziehen könnte. Natürlich muss eine IDE auch nicht für alles und jedes eine Plugin-Stelle bereit stellen, aber ich denke nur alleine an Versionskontrollsysteme... Git, Mercurial, Bazaar, auch noch SVN usw. bilden doch eine Vielzahl, die ein Mann einfach nicht abbilden kann. Eine IDE, die "nur" eines davon spricht, fällt dann schon für alle Benutzer eines anderen Dienstes flach.
Beim Thema Unit-Tesing sieht es dann ähnlich aus... das ist einfach nicht nur Sprach spezifisch, sondern dort ebenfalls fragmentiert in verschiedene Frameworks. Man wird sein Projekt sicherlich nicht einfach mal so umstellen, weil man für "Builder" ein anderes Test-Framework nutzen muss...
Eine zugeschnittene Lösung kann durchaus einige Vorteile haben.
Das, zumindest erstmal, außen vor lassen von Schnittstellen beschleunigt die Entwicklung, weil man weder großartig an Schnittstellendesign feilen muss, noch schon vorhandene Schnittstellen und ihre Benutzungen kontinuierlich den Anforderungen anpassen muss.
Durch die Zielsetzung, eine IDE für GNOME zu sein, kann z.B. als Versionskontrolle Git vorrausgesetzt werden. Vermutlich gilt das auch für Unittests und ähnliches.
Hm... ja, ok, stimmt zum Teil schon, aber: Wird denn dennoch so programmiert, dass es intern gute Abstraktionen gibt? Denn dann ist der interne Code vermutlich modular genug, dass man bei wechselnder Technologie im GNOME-Umfeld einfach und sicher reagieren kann. Plane ich tatsächlich via Plugins Schnittstellen ein, so bin ich letztendlich zu einem sauberen inneren Design gezwungen... das kann durchaus Vorteile haben.
Generell gebe ich dir natürlich Recht, aber speziell bei der ersten Version, wo man ja auch noch die Anforderungen nicht so im Detail kennt, ist es oft am Besten, die Lösung mal zu einfach wie möglich zu halten.
Ist gnome dermaßen Stark am Desktop vertretten das sich der Aufwand lohnt? ich meine es gibt noch XFCE, was bei Debian zum Standard wird, und noch viele andere wie MATE, KDE, LXDE usw.
Ich dachte Gnome3 ist nicht gerade die beliebteste DE oder?
Das scheint dem Entwickler egal zu sein. "Insellösung" und "nicht erweiterbar" passt genau in mein derzeitiges Bild von Gnome und ist damit IMO die konsequente Fortführung der Gnome-Philosophie.
Lieber eine funktionierende Insellösung als die nächste überkomplexe und nie fertig werdende Universallösung.
Das sehe ich auch so. Das Bedarf bei den Entwicklern da ist, nicht selbst mit der Shell konfrontiert zu werden, kann ich mir gut vorstellen. Entwickler sind ja auch Nuzter.
Es gibt sehr gute Nicht-Insel (Festland?) Lösungen.
Aber prinzipiell: Warum nicht? Das ist ja das schöne an Linux, man kann sich aussuchen mit was man programmiert.
Ich empfehle Gnome Tweak Tool + Gnome Shell Extensions und Gnome Shell Frippery...
Meinst du das ernst, oder ist das ein Scherz?
Das jetzt eine allein auf Gnome 3 spezialisierte IDE entwickelt wird ist ein Zeichen, dass dem Gnome 3 Projekt die Entwickler davonlaufen und man nun versucht, mit einem Leckerbissen, nämlich dieser IDE, dem Entwicklerschwund gegenzusteuern.
Das ist jedenfalls meine Meinung dazu.
Der im Artikel genannte Entwickler hat natürlich auch noch seine private Motivation dazu, keine Frage.
Die spielt ebenfalls noch eine kleine Rolle, dennoch würde ich die jetzt aber nicht allzu sehr gewichten.
Das jetzt eine allein auf Gnome 3 spezialisierte IDE entwickelt wird ist ein Zeichen, dass dem Gnome 3 Projekt immer beliebter wird und man nun versucht, mit einem Leckerbissen, nämlich dieser IDE, dem Interesse der User gerecht zu werden.
Im Grunde gibt es für beide Möglichkeiten hier wohl keine Datengrundlage.
Wenn man mehr Entwickler gewinnen will, sollte man sich eher öffnen, statt sich zu isolieren. Ein eingeschränktes Entwicklungswerkzeug, was für alles andere nutzlos ist, ist unterm Strich nutzlos. Kein Entwickler will sich noch eine IDE auf die Kiste packen.
Wo steht das diese IDE mehr Entwickler zu Gnome bringen soll? Diese IDE wird von einem Gnome Entwickler für Gnome Entwickler gebaut. Bist Du Gnome Entwickler, dass Du für diese sprechen kannst?
Gnome3 ist jedenfalls nicht mehr so beliebt wie einst Gnome2. In den meisten Distros ist es dennoch als Zweit- oder Dritt-DE mit dabei, da man nachwievor den Gnomeunterbau für viele Anwendungen benötigt, die unter anderen DEs gebraucht werden.
Wie vielen Prozent Nutzern es dabei überhaupt auffallen würde, wenn die Gnome3-GUI gar nicht in startfähigem Zustand mit dabei wäre, ist schwer zu sagen. In den meisten "Haupt-Distros" dürfte dieser Wert aber weit unter 50% liegen, vielleicht mit Ausnahme Fedoras und Debians.
Wenn aber der Autor meint, dass er nun diese "Insellösung" unbedingt programmieren müsse, dann nur zu. Schaden wird Ihm dieses Unterfangen ganz bestimmt nicht.
Die ganzen anderne Desktop-Umgebungen, wie Unity, XFCE, MATE, LXDE usw. benutzen die GNOME-Bibliotheken. Das ist eine anderer Oberfläche, aber derselbe Unterbau. Und genau hier sehe ich das Problem: Mit Ausnahme von vielleicht Unity haben die anderen Projekte nicht genügend Entwickler, ihre Umgebung auf eigene Beine zu stellen. Daher sind diese immer von GNOME abhängig und werden wohl nie relevant werden.
Dass GNOME eine IDE bringt, war schon lange geplant und entspricht der Strategie, eine "Plattform" bereitzustellen, auf der Apps aufsetzen können. Einzige Alternative sind hier die KDE Frameworks. Und das könnte durchaus Entwickler anlocken, da man jetzt eine einheitliche Plattform hat und nicht ein Sammelsurium von Bibliotheken, wo man sich erst das passende raussuchen muss.
Sind Unity, LXDE, usw. nicht gerade dabei auf Qt zu wechseln?
Unity hat schon oft die technische Grundlage gewechselt. Erst Clutter, dann Nux, dann parallel Qt für Unity 2D, dann Qt wieder eingestellt, und jetzt doch wieder Qt, wobei die Nux-Variante eingestellt wird. Fertig soll das erst 2016 werden. Kein Wunder, Unity war bisher GNOME 3 mit einem anderen Fenstermanager (Compiz), und die Unity Shell läuft als Compiz-Plugin. Die müssen im Prinzip von vorn anfangen.
LXDE fusioniert mit Razor Qt, was sich sicher auch noch eine Weile hinzieht.
Die Stärke von Qt liegt in der Plattformunabhängigkeit, die Philosophie dahinter ist ähnlich wie bie Java. Gtk und GLib dagegen zielen darauf, möglichst gute Integration in GNOME zu gewährleisten, und das wurde in letzter Zeit sehr ausgebaut, man kriegt mit GNOME derzeit einen sehr konsistenten Desktop hin.
Respekt!
Das hängt doch ganz davon ab was er dort verdient hat.
Bei allem Respekt für den Entwickler, der offenbar einen (persönlichen) Traum leben wird und will: Was zum Geier soll denn eine IDE *ohne* Schnittstellen? Gerade im Bereich der Softwareentwicklung kommen (und gehen!) Technologien schneller, als man das in einer IDE wirklich nachziehen könnte. Natürlich muss eine IDE auch nicht für alles und jedes eine Plugin-Stelle bereit stellen, aber ich denke nur alleine an Versionskontrollsysteme... Git, Mercurial, Bazaar, auch noch SVN usw. bilden doch eine Vielzahl, die ein Mann einfach nicht abbilden kann. Eine IDE, die "nur" eines davon spricht, fällt dann schon für alle Benutzer eines anderen Dienstes flach.
Beim Thema Unit-Tesing sieht es dann ähnlich aus... das ist einfach nicht nur Sprach spezifisch, sondern dort ebenfalls fragmentiert in verschiedene Frameworks. Man wird sein Projekt sicherlich nicht einfach mal so umstellen, weil man für "Builder" ein anderes Test-Framework nutzen muss...
Nun ja, entwickeln darf natürlich jeder alles
Eine zugeschnittene Lösung kann durchaus einige Vorteile haben.
Das, zumindest erstmal, außen vor lassen von Schnittstellen beschleunigt die Entwicklung, weil man weder großartig an Schnittstellendesign feilen muss, noch schon vorhandene Schnittstellen und ihre Benutzungen kontinuierlich den Anforderungen anpassen muss.
Durch die Zielsetzung, eine IDE für GNOME zu sein, kann z.B. als Versionskontrolle Git vorrausgesetzt werden.
Vermutlich gilt das auch für Unittests und ähnliches.
Hm... ja, ok, stimmt zum Teil schon, aber: Wird denn dennoch so programmiert, dass es intern gute Abstraktionen gibt? Denn dann ist der interne Code vermutlich modular genug, dass man bei wechselnder Technologie im GNOME-Umfeld einfach und sicher reagieren kann. Plane ich tatsächlich via Plugins Schnittstellen ein, so bin ich letztendlich zu einem sauberen inneren Design gezwungen... das kann durchaus Vorteile haben.
Generell gebe ich dir natürlich Recht, aber speziell bei der ersten Version, wo man ja auch noch die Anforderungen nicht so im Detail kennt, ist es oft am Besten, die Lösung mal zu einfach wie möglich zu halten.
Wir werden ja sehen, wie sich das entwickelt
Na wenn das mal nicht die Nutzer verwirrt. Aber irgendwann werden C und Python sicherlich "wegoptimiert", um der Verwirrung entgegen zu wirken.