Es ist richtig, Code zu verwerfen, der sich als schlecht wartbar, oder unsicherer Blob erwiesen hat. Weiterhin ist es wohl besser, solche Funktion - wenn diese dann wirklich benötigt werden - modular zu gestalten und in Plugins auszulagern.
Wenn das Gnome Projekt nun noch anfängt, systematisch den gesamten restlichen Quellcode dieses DEs zu entschlacken, wäre das ebenfalls ein Gewinn. Und Gnome könnte wieder interessant werden. Im Moment sehe ich dieses Projekt als einfach zu überladen und damit einhergehend zu Ressourcenhungrig an. Übrigens genauso wie KDE/Plasma.
Grundsätzlich stimme ich hier zu, allerdings kann ich hier KDE/Plasma echt nicht mehr als resourcenhungrig verbuchen. Bei KDE wurde im Gegenteil immer gemosert, dass alles ständig neugeschrieben wird und die alten Funktionen (noch) fehlten. Seit Plasma 5.8 wird KDE bei mir mit jeder Iteration eher schneller als langsamer (und dabei kommen laufend noch Features dazu).
Teste mal KDE Neon. Das ist Plasma/KDE auf XFCE Augenhöhe von den Resourcen her.
Plasma resourcenhungrig? Guter Witz. Es ist der resourcenschonendste Desktop, den es gibt. Ohne PIM unter 300 MB. Und jetzt kommst du. Wie kommst du zu deiner Aussage?
JavaScript rauswerfen. Ganz ernsthaft, GNOME4 sollte GNOME3 ohne GJS werden. Die Shell-UI muss dann mit C, C++ oder RUST neu implementiert werden. Ein hoher Aufwand, aber von XML und GCONF hat man sich ebenso verabschiedet, das ganze ist dem Hype aus 2010 um JavaScript "auf dem Desktop" geschuldet.
Da sollte den Speicherverbrauch senken, Komplexität reduzieren und man hat keine komischen Unfälle mehr mit der Garbage-Collection. Bonus, die Abhängigkeit auf JavaScript fliegt raus.
Nachteil, Extensions in der bisherigen Form gibt es nicht mehr. Vielleicht macht auch ein Mittelweg Sinn und man behält zumindest die API für JavaScript.
Javascript hast du bei Qt auch an Bord, jedenfalls wenn du auf QML setzt. Soweit ich weiß gibt es den QtQuickCompiler nur in der komerziellen Version. Solange das am Ende in nativ ausführbaren Code überführt wird spricht da auch meiner Meinung nach nichts gegen, aber das scheint leider schon lange nicht mehr Standard zu sein.
Stimmt komplett nicht. Bei QML wird nur JavaScript verwendet, wenn der Entwickler JavaScript da einfügt. Man kann QML komplett ohne JavaScript verwenden und ohne irgendwelchen Overhead. Gut geschriebener Code macht das.
Der QtQuickCompiler ist in der Open Source Variante auch enthalten.
Stimmt komplett nicht? Ich nehme gerne Links entgegen, wo das mal ordentlich beschrieben wird. Ich lese mich in meiner Freizeit immer mal wieder etwas in Qt ein und es ist echt schwer etwas zu einem ordentlichen, sauberen Grundaufbau von einem Projekt zu finden. Default ist soweit mir bekannt ist jedenfalls, dass QML und Javascript JIT-kompiliert werden. In den Beispielen ist das so. Beim Erstellen von neuen Projekten in QtCreator auch. Wäre schön, wenn es komplett nicht stimmen würde, sieht für mich leider nicht so aus.
Schön zu lesen, dass der QtQuickCompiler (jetzt?) auch in der Open-Source-Variante enthalten ist.
Nachtrag: Ah, mit der neusten Version gibt es den QtQuickCompiler in der Open-Source-Version.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Mai 2018 um 13:23.
Ich habe die entfernten Funktionen bisher nicht benutzt. Deshalb werden sie mir auch kaum fehlen. Worüber Gnome aber m.E. aber mal nachdenken sollte, ist eine bessere Möglichkeit zur Gruppierung von Programmen (z.B. für Projekte, Aufgaben, usw.).
Ja, super, da soll man jetzt von Hand jedes Programm einzeln, selber einsortieren? Linux-Applikationen sind wunderbar vorsortiert - einer der größten Vorteile gegenüber Windows, wo das reine Chaos herrscht und Android, wo es bestenfalls eine alphabetische Sortierung gibt. Gnome-Entwickler: Hey, Linux ist an einer Stelle allen anderen voraus - lass es uns einstampfen.
Das Gnome-Shell-Application-Menu ist auch generell Schrott. Schau mal die Screenshots an. Da gibt es zwei Applikationen namens "KDE connect ..." und einmal "KDE conntect l...". Super! Tooltips gibt es natürlich auch nicht. Dafür rechts und links zwei Ränder, die (bei mir) fast 50% der Breite verbrauchen. Dauer müssen die die Virtuellen Desktops rechts natürlich stetig ausgeblendet werden, damit sie ja nicht zur Gesamtübersicht beitragen können.
Nichts gegen Deinen Hinweis - Danke dafür!
Es ärgert mich, dass Gnome 3 an einigen Stellen so übel verhunzt und unkonfigurierbar ist, dass man die ganzen Positiven Entwicklungen nicht nutzen kann. Gerade die Gnome-Shell ist nicht von Menschen entwickelt, die mit dem Desktop echt arbeiten wollen, sondern sich daran erfreuen, dass alles durchsichtig und animiert ist und sich alles stetig beim ein- und ausblenden herumzappelt. Das ist nämlich geiler, als in einem 600-Seitigen PDF ohne Konzentration auf den super slimmen, animierten Scrollbalken vor und zurück scrollen zu können und die Konzentration auf den Inhalt des Dokuments zu wahren.
[q]Da die Gnome-Shell mit einem ausgewachsenen App-Starter ausgeliefert werde und der Software-Store Gnome Software ebenfalls Apps starten könne, sei die Implementation in Nautilus überflüssig, so Soriano.[/q] Also, angenommen, ich lade mir ein Java-Programm aus dem Internet herunter, das nicht im Repository meiner Distro vorhanden ist, und will das Programm starten - wie mache ich das konkret ohne Nautilus? Danke für Eure Hilfe!
Vermutlich wirst man eine ZIP-Datei heruntergeladen haben. Die ist zu entpacken. Das geht ja noch mit GUI. Danach im Terminal in entpacken Ordner die vermutliche *.jar-Datei der Java-Anwednung suchen und im Terminal öffen. So in der Form "java -jar TVBrowser.jar"
Wenn mamn Glück hat klappt das gleich, sonst die Fehlermeldungen durchsehen.
Was auch helfen kann: Der Autor der Software hat bereits ein Startscript hintelegt (für Win z.B *.bat", unter Linux meinst *.sh".
Die sh--Datei im terminal mit "sh start.sh" starten.
Und mal im Editor ansehen, da sieht man dann die Aufrufparameter...
Also, angenommen, ich lade mir ein Java-Programm aus dem Internet herunter, das nicht im Repository meiner Distro vorhanden ist, und will das Programm starten - wie mache ich das konkret ohne Nautilus?
Wie die anderen schon sagten, erst mal vom Terminal ausprobieren ob das Programm läuft: $ java -jar programmname.jar
Danach im Verzeichnis /usr/share/applications/ oder besser im Unterverz. deines Homeordners: .../.local/share/applications/
eine Desktop-Datei (programmname.desktop) anlegen, die ungefähr folgenden Inhalt hat:
[Desktop Entry] Name=Name deines Java-Programms StartupNotify=true Icon=/pfad/icon-wenn-eins-da-ist.ico GenericName=Programmname Comment=Infos zum Programm Categories=Whatever Exec=/usr/bin/java -jar "/pfad/programmname.jar" Terminal=false Type=Application
Richtig so. Muss man jedoch selten machen. Wenn man eine Anwendung aus dem Repository installiert, ist die Desktop-Datei schon enthalten. Problemfeld sind wirklich nur handgebastelde Javaanwendung aus dem Internet.
So kann die Desktopumgebung einer Javaanwendung auch im laufenden Betrieb das Icon zuordnen, sieht hübscher aus (Okay, Java ist nie hübsch...) und hilft dem Anwender. Ist ein Workaround, weil Java ein Spezifikation nicht umsetzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 11:47.
Gemäß Kommentar des Entwickler ist die Konsole für so solche und ähnliche Fälle (z.B. AppImage) jedem Benutzer problemlos zuzumuten.
Die Reaktion der betroffenen wird zeigen ob dem so ist... Mir persönlich ist es egal, ich benutze KDE Plasma 5 und jetzt habe ich einen Grund mehr es dabei zu belassen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 14:03.
Ich glaube Du meinst GTK, welches jedoch von Gnome weiterentwickelt wird.
- XFCE basiert nicht auf Gnome - Mate basiert auf Gnome 2 - Budgie basiert auf Gnome 3, möchte aber davon und von GTK unabhängig werden, weil sich Gnome nicht kooperativ verhält.
Ich weiß nicht, ob und wieviel Mate mittlerweile von GNOME 3 übernommen hat, jedoch basieren tut es ursprünglich auf GNOME 2. Mittlerweile haben sie einiges (alles?) auf GTK 3 portiert, weswegen ich nie verstanden habe, warum sie nicht GNOME 3.6 geforkt haben, weil dort bereits alles auf GTK 3 gewesen wäre und die Funktionalität wie bei GNOME 2 gegeben war. Mate hätte sich das Portieren gespart und wäre heute um Jahre weiter. Vielleicht wollte Mate ursprünglich bei GTK 2 bleiben.
Sind die Mate-Entwickler nicht diejenigen, die Canonicals totes Pferd "Mir" weiterreiten und das inzwischen von einer Alternative für X11 und Wayland zu einem Wayland-Kompositor umgeplant haben?
Ja ursprünglich begann es noch als GTK2- Projekt, Mate selbst ist aber vollständig auf GTK3 portiert worden. Ein Fork von Gnome3 hätte doch gar kein Sinn gemacht und funktional ist es ja die Nische von Cinnamon das Gnome im Unterbau hat und eine andere Benutzerführung liefert. Schau dir ein aktuelles Mate an, es lohnt sich.
Ich meine ja, Gnome3 ohne Gnome-Shell mit Flashback-Panel, welches dem klassischen Gnome2-Panel sehr nahe kommt. Cinnamon hat Gnome3.6 geforkt, jedoch die Gnome-Shell umgebaut. Alle drei, Mate, Cinnamon und Gnome3 haben sich dann natürlich auseinander entwickelt.
Mate und Cinnamon, sollten fusionieren, um die klassischen Applikationen zu pflegen und weiter zu entwickeln. Im Prinzip machen sie ja, bis auf die Desktopoberflächliche, das gleiche.
Was ich an Gnome3 schätze ist die Integration von NextCloud. Vor allen Dingen des Kalenders und Adressbuches. Gibt es das bei Mate oder Cinnamon mittlerweile auch?
Ah, verstehe. Ich bin da ganz bei dir und gehe da noch viel weiter, Mate, Cinnamon und XFCE sollten fusionieren. Ich nutze keine Cloud, aber es gibt eine Integration von Owncloud und nach meinem Wissen funktioniert das ja dann auch für Nextcloud.
Nachdem die Gnome Entwickler beschlossen haben, Gnome2 als "deprecated" bzw. "veraltet" abzutun, wurde es von diesen Leuten 1:1 geforkt, umbenannt und weiterentwickelt.
Zunächst fand erstmal ein Bugfixing statt bzw. wurden einige wie auch immer geartete Elemente angepasst.
Der Fokus danach war das Portieren auf Gtk3.
Nichtsdestotrotz ist Mate eine Weiterführung von Gnome2, da es letztendlich Gnome2 ist. Halt jetzt weitgehend auf Gtk3 portiert.
Unterschied zwischen Toolkit und Desktopumgebung geläufig? [_] Ja [X] Nein
Mate und XFCE nehmen GTK3 als Toolkit und nicht aber GNOME3 als Basis. Das hat vor längerer Zeit z.B. Cinnamon gemacht, allerdings nur ausgesuchte Komponenten. Aber auch hier stimmt es: Weil es ja Cinnamon (und Budgie) gibt, kann man GNOME3 als überflüssig entfernen.
> Mate und XFCE nehmen GTK3 als Toolkit und > nicht aber GNOME3 als Basis.
Das ist vollkommen richtig!
Aber!
Ursprünglich hat sich Xfce einiges von Gnome1/2 entliehen. Das liegt aber etliche Jahre zurück. Wenn ich nicht falsch liege, so basierte das xfce4-panel auf gnome-panel.
Einige andere Bereiche ursprünglich auch. Nur sieht man da heute nix mehr von, da alles über die Jahre entkernt und verbessert wurde.
Einiges ist in Exo, Garcon, libxfce4ui, libxfce4util usw. eingeflossen.
Was auch immer bei XFCE noch Gnome1/2 Ursprung haben sollte, wurde auf GTK3 portiert. Und durch die Reste eines gnome2-panel codes basider XFCE immer noch nicht auf GNOME3.
Es ist ohnehin erstaunlich, dass fast jeder der GNOME3 modifizert es mit Extensions erweitert, die die DE wieder Gnome2-iger, Windows-iger oder Mac-OSX-iger machen.
Den originären genuine GNOME3 Workflow hingegen (ich finde ohne Extensions keinen echten "flow" ohne ein Dutzend Shortcuts) versucht keiner ernsthaft zu kopieren.
Der Nautilus wird doch schon seit Ewigkeiten immer weiter kastriert. Selbst das Löschen von Dateien per Maus hatten sie mal ausgebaut. Bals wird er ein reiner Dateibetrachter sein. Alles andere könnte den Anwender verwirren.
Bei iOS ist doch mitunter aus genau dieser Begründung von Anfang an gar nicht erst einer eingebaut worden und auch unter Android gab es aus ähnlichen Gründen lange keinen offiziellen Dateimanager.
Der Dateibrowser soll für entsprechende Dateien bei Doppelklick die Standardanwendung öffnen oder eben eine andere per Kontextmenü. Hier bleibt alles, so wie es ist.
Ich vermute, einige hier verstehen die beschriebene Änderung nicht. Es wird die Funktion entfernt, dass eine Anwendung (Executable) als solche explizit über Nautilus gestartet wird. Etwa per Doppelklick ein Shellskript, wovor Nautilus schon seit gefüllt immer umständlich warnt. Weil man dann nicht sieht, was passiert, daher mit Rechtsklick Terminal aufmachen und richtiger Weise im Terminal ausführen.
Einzig und allein nervige Java-Anwendung kommen oft nur mit Wrapperscripten und ohne .desktop-Datei. Die werden jetzt umständlicher zu starten sein oder man legt wie oben beschrieben eine .desktop-Datei an. Habe ich vor einiger Zeit schon getan für eine (nervige) eigene Javaanwendung, seit dem hat sie auch einen hübsches Icon und kann bequemer gestartet werden oder im Dateibrowser ins Verzeichnis zu navigieren. Abgesehen davon, dass diese nervigen Wrapperscripte meistens sowieso nicht funktionieren...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 11:38.
Die .desktop-Dateien können sinnvoller Weise nur in drei Verzeichnissen liegen: /usr/share/applications, /usr/local/share/applications oder ~/.local/share/applications
Zu Testzwecken fände ich eine direkte Ausführbarkeit aus Nautilus bequem, die Hauptaufgabe von Nautilus ist jedoch den Anwender in diesen Verzeichnissen die Dateien anlegen, ändern oder löschen zu lassen.
Die Entkernung in Gnome3 dient dem Platzmachen für "Flatpaks", denn darauf wird sich Gnome fokussieren.
Einige Nutzer orakeln hier mit java -jar usw., was zwar belustigend ist, aber letztendlich so unwahr garnicht ist.
Auch wenn du künftig einen anderen Desktop nutzen kannst, wirst du langfristig wohl damit konfrontiert, dass klassische Pakete wie deb oder rpm verschwinden werden und Programme wie Gimp, Libreoffice, Firefox (und denken wir an die ganzen proritären Programme) nur noch als Flatpaks angeboten werden.
Das heisst dann für dich:
Du wirst gezwungen werden, eine vorcompilierte binäre Laufzeitumgebung von flathub herunterzuladen. Diese wird dann in dein /var/lib/flatpak Verzeichnis installiert und darauf werden dann deine Programme laufen gelassen.
Weder du noch deine Distribution werden Einfluss auf diese vorcompilierten Binär"blobs" haben.
OSS ist nicht OSS wenn die Sourcen nicht offen vorliegen. Die neuen "Packs" sind letztendlich nur das Endprodukt, die du auch selbst Herstellen kannst.
CSS wird sich diese "Packs" auch zu nutze machen können und einfach ausliefern können.
> Eigentlich ändert sich nur die Installationsart.
Das ist bedingt richtig.
Bei der Verwendung von Flatpaks wird eine neue Laufzeitumgebung bei dir auf dem Rechner ins /var/lib/flatpak installiert.
Der Sinn von Flatpaks war ja, die Einhaltung von Binärkompatibilität. Diese kann nur auf Grundlage einer gemeinsamen binären Laufzeitumgebung garantiert werden.
Wenn z.B. nun Debian ihr eigenes Flatpak runntime kompiliert, Arch ihr eigenes, Fedora ihr eigenes, Gentoo ihr eigenes usw. dann ist doch das, was Flatpaks ausmacht dahin.
Sobald du mittels
flatpak install org.whatever.blah
auführst, wird automatisch getestet, ob eine signierte Laufzeitumgebung auf deinem Rechner installiert ist. Ist dies nicht der Fall, wird diese binäre Laufzeitumgebung von flathub heruntergeladen und auf deinem System installiert.
Es ändert sich daher was, da man dir eine 250mb Laufzeitumgebung auf dein Debian oder was auch immer System unterjubelt, damit deine Flatpaks dann auch laufen.
Historisch hab ich mich mal für KDE/Plasma als UI entschieden. Ich habe manchmal daran gezweifelt, ob die Macher noch wissen, was sie tun aber irgendwann hat sich auch das größte Chaos in Wohlgefallen aufgelöst.
Plasma 'heute' mag optisch nicht meinem Geschmack entsprechen aber es entwickelt sich funktional weiter und wird Schritt für Schritt stabilisiert. Man spürt an den Diskussionen, dass die Entwicklergemeine versucht, die Interessen des Benutzers im Auge zu haben. Die decken sich selten mit meine persönlichen aber das wäre ja auch ein Wunder ..
Wenn ich mir andere DE ansehe denk ich vielfach: ganz nett aber ich hab ja Plasma.
Wenn ich Gnome sehe denk ich nur: noch ein Jahr und die haben sich selbst abgeschafft.
Bedenkt man in diesem Kontext, dass selbst der Gründer und Initiator des Gnome Projekts letztendlich resigniert aufgegeben hat.
Niemand gibt ein Lebenswerk einfach so auf, es sei denn:
- Das Projekt geht in eine vollkommene falsche Richtug! (was jetzt der Fall ist) - Man hat das Projekt aus der Hand gegeben bzw. sich wegnehmen lassen (damit meine ich die Projektkoordination, so wie sie Linus Torvalds inne hat) - Interne Zerrissenheit
Der Nautilus-Dateimanager ist schon lange nur noch ein einziger Krampf. Als ich mit Ubuntu im Oktober 2007 anfing, gab es noch echte Fortschritte bei der Entwicklung des Nautilus. Man konnte mit der Maus über eine Musikdatei fahren und der Titel wurde angespielt - sehr praktisch. Heute gibt es nicht mal mehr vernünftige Dateioperationen. Daher verwende ich weitgehend nur noch Nemo - der ist um Klassen besser, nur leider etwas instabil.
Ohnehin ist der Gnome-3-Desktop zwar hübsch, aber nicht komfortabel. Wer denkt sich aus, dass der Aktivitäten-Knopf links, die Auswahl der einzelnen Desktops dann aber rechts liegt? Das kann nur jemand, der mit der Oberfläche rumspielt, aber nicht produktiv arbeitet.
Die Entwicklung von Gnome ist schlicht zum Heulen. Meine Meinung.
> Der Nautilus-Dateimanager ist schon lange nur > noch ein einziger Krampf. Wann war er das schonmal nicht ? Ich kann mich noch erinnern, als Eazel (die Firma dahinter) Nautilus bei Gnome einführte und somit das gmc (Midnight Commander mit Gtk+ Frontend) ersetzte. Nautilus war so derbe lahm und langsam, dass es niemand wirklich nutzen konnte.
Selbst damals wollte man bereits einen Gnome-Store ettablieren. Halt durch Nautilus und dem Support den Eazel verticken wollte. Die haben irgendwie 10-20 mio an Fördergelder verbrannt, für eine Software, die damals schon nicht wirklich zu gebrauchen war.
spätestens in 3-4 releases wird die komplette Funktionalität entfernt sein und der Code nur noch aus malloc() und sleep() bestehen.
Es ist richtig, Code zu verwerfen, der sich als schlecht wartbar, oder unsicherer Blob erwiesen hat. Weiterhin ist es wohl besser, solche Funktion - wenn diese dann wirklich benötigt werden - modular zu gestalten und in Plugins auszulagern.
Wenn das Gnome Projekt nun noch anfängt, systematisch den gesamten restlichen Quellcode dieses DEs zu entschlacken, wäre das ebenfalls ein Gewinn. Und Gnome könnte wieder interessant werden. Im Moment sehe ich dieses Projekt als einfach zu überladen und damit einhergehend zu Ressourcenhungrig an. Übrigens genauso wie KDE/Plasma.
Grundsätzlich stimme ich hier zu, allerdings kann ich hier KDE/Plasma echt nicht mehr als resourcenhungrig verbuchen. Bei KDE wurde im Gegenteil immer gemosert, dass alles ständig neugeschrieben wird und die alten Funktionen (noch) fehlten. Seit Plasma 5.8 wird KDE bei mir mit jeder Iteration eher schneller als langsamer (und dabei kommen laufend noch Features dazu).
Teste mal KDE Neon. Das ist Plasma/KDE auf XFCE Augenhöhe von den Resourcen her.
Plasma resourcenhungrig? Guter Witz. Es ist der resourcenschonendste Desktop, den es gibt. Ohne PIM unter 300 MB. Und jetzt kommst du. Wie kommst du zu deiner Aussage?
JavaScript rauswerfen. Ganz ernsthaft, GNOME4 sollte GNOME3 ohne GJS werden. Die Shell-UI muss dann mit C, C++ oder RUST neu implementiert werden. Ein hoher Aufwand, aber von XML und GCONF hat man sich ebenso verabschiedet, das ganze ist dem Hype aus 2010 um JavaScript "auf dem Desktop" geschuldet.
Da sollte den Speicherverbrauch senken, Komplexität reduzieren und man hat keine komischen Unfälle mehr mit der Garbage-Collection. Bonus, die Abhängigkeit auf JavaScript fliegt raus.
Nachteil, Extensions in der bisherigen Form gibt es nicht mehr. Vielleicht macht auch ein Mittelweg Sinn und man behält zumindest die API für JavaScript.
Javascript hast du bei Qt auch an Bord, jedenfalls wenn du auf QML setzt. Soweit ich weiß gibt es den QtQuickCompiler nur in der komerziellen Version. Solange das am Ende in nativ ausführbaren Code überführt wird spricht da auch meiner Meinung nach nichts gegen, aber das scheint leider schon lange nicht mehr Standard zu sein.
Stimmt komplett nicht. Bei QML wird nur JavaScript verwendet, wenn der Entwickler JavaScript da einfügt. Man kann QML komplett ohne JavaScript verwenden und ohne irgendwelchen Overhead. Gut geschriebener Code macht das.
Der QtQuickCompiler ist in der Open Source Variante auch enthalten.
Stimmt komplett nicht? Ich nehme gerne Links entgegen, wo das mal ordentlich beschrieben wird. Ich lese mich in meiner Freizeit immer mal wieder etwas in Qt ein und es ist echt schwer etwas zu einem ordentlichen, sauberen Grundaufbau von einem Projekt zu finden. Default ist soweit mir bekannt ist jedenfalls, dass QML und Javascript JIT-kompiliert werden. In den Beispielen ist das so. Beim Erstellen von neuen Projekten in QtCreator auch. Wäre schön, wenn es komplett nicht stimmen würde, sieht für mich leider nicht so aus.
Schön zu lesen, dass der QtQuickCompiler (jetzt?) auch in der Open-Source-Variante enthalten ist.
Nachtrag: Ah, mit der neusten Version gibt es den QtQuickCompiler in der Open-Source-Version.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Mai 2018 um 13:23.Ich stimme Dir vollkommen zu.
Genau das ist die eigentliche Fehlkonstruktion von Gnome3.
Das Problem ist, dass Gnome mehrfach bewiesen hat, dass sie keine Plugin-Schnittstellen können.
Ich habe die entfernten Funktionen bisher nicht benutzt. Deshalb werden sie mir auch kaum fehlen. Worüber Gnome aber m.E. aber mal nachdenken sollte, ist eine bessere Möglichkeit zur Gruppierung von Programmen (z.B. für Projekte, Aufgaben, usw.).
Das Gruppieren geht wohl mit Addons:
https://www.omgubuntu.co.uk/2017/04/add-app-folders-gnome-shell-overview
Ja, super, da soll man jetzt von Hand jedes Programm einzeln, selber einsortieren? Linux-Applikationen sind wunderbar vorsortiert - einer der größten Vorteile gegenüber Windows, wo das reine Chaos herrscht und Android, wo es bestenfalls eine alphabetische Sortierung gibt.
Gnome-Entwickler: Hey, Linux ist an einer Stelle allen anderen voraus - lass es uns einstampfen.
Das Gnome-Shell-Application-Menu ist auch generell Schrott. Schau mal die Screenshots an. Da gibt es zwei Applikationen namens "KDE connect ..." und einmal "KDE conntect l...". Super! Tooltips gibt es natürlich auch nicht. Dafür rechts und links zwei Ränder, die (bei mir) fast 50% der Breite verbrauchen. Dauer müssen die die Virtuellen Desktops rechts natürlich stetig ausgeblendet werden, damit sie ja nicht zur Gesamtübersicht beitragen können.
Nichts gegen Deinen Hinweis - Danke dafür!
Es ärgert mich, dass Gnome 3 an einigen Stellen so übel verhunzt und unkonfigurierbar ist, dass man die ganzen Positiven Entwicklungen nicht nutzen kann. Gerade die Gnome-Shell ist nicht von Menschen entwickelt, die mit dem Desktop echt arbeiten wollen, sondern sich daran erfreuen, dass alles durchsichtig und animiert ist und sich alles stetig beim ein- und ausblenden herumzappelt. Das ist nämlich geiler, als in einem 600-Seitigen PDF ohne Konzentration auf den super slimmen, animierten Scrollbalken vor und zurück scrollen zu können und die Konzentration auf den Inhalt des Dokuments zu wahren.
Design follows Fuction - nicht bei Gnome.
Der Witz ist zwar schon alt, aber
https://distrowatch.com/images/other/gnome4.png
:P
[q]Da die Gnome-Shell mit einem ausgewachsenen App-Starter ausgeliefert werde und der Software-Store Gnome Software ebenfalls Apps starten könne, sei die Implementation in Nautilus überflüssig, so Soriano.[/q]
Also, angenommen, ich lade mir ein Java-Programm aus dem Internet herunter, das nicht im Repository meiner Distro vorhanden ist, und will das Programm starten - wie mache ich das konkret ohne Nautilus?
Danke für Eure Hilfe!
Ubuntuusers Wiki: Java:
javaws http://www.domain.topleveldomain/PROGRAMM.jnlp
Ubuntuusers Wiki: Programme Starten:
java -jar programmname.jar
MFG
Consolenfrickeln? Sind dir die 2% Prozent Marktanteil immer noch zu hoch?
salopp:
Vermutlich wirst man eine ZIP-Datei heruntergeladen haben. Die ist zu entpacken. Das geht ja noch mit GUI. Danach im Terminal in entpacken Ordner die vermutliche *.jar-Datei der Java-Anwednung suchen und im Terminal öffen. So in der Form
"java -jar TVBrowser.jar"
Wenn mamn Glück hat klappt das gleich, sonst die Fehlermeldungen durchsehen.
Was auch helfen kann: Der Autor der Software hat bereits ein Startscript hintelegt (für Win z.B *.bat", unter Linux meinst *.sh".
Die sh--Datei im terminal mit "sh start.sh" starten.
Und mal im Editor ansehen, da sieht man dann die Aufrufparameter...
Wow! Und vorher musste man nur in Nautilus doppelklicken, um die Software auszuführen? Das ist ja mal ein Fortschritt!
;-)
Wie die anderen schon sagten, erst mal vom Terminal ausprobieren ob das Programm läuft:
$ java -jar programmname.jar
Danach im Verzeichnis /usr/share/applications/
oder besser im Unterverz. deines Homeordners:
.../.local/share/applications/
eine Desktop-Datei (programmname.desktop) anlegen, die ungefähr folgenden Inhalt hat:
[Desktop Entry]
Name=Name deines Java-Programms
StartupNotify=true
Icon=/pfad/icon-wenn-eins-da-ist.ico
GenericName=Programmname
Comment=Infos zum Programm
Categories=Whatever
Exec=/usr/bin/java -jar "/pfad/programmname.jar"
Terminal=false
Type=Application
Ideal für Leute, die meinen, mit Gnome hätten sie einen einfachen, intuitiven Desktop gewählt
Jup und die haben dann maximal i3 und thunar und kein Gnome
Richtig so. Muss man jedoch selten machen. Wenn man eine Anwendung aus dem Repository installiert, ist die Desktop-Datei schon enthalten. Problemfeld sind wirklich nur handgebastelde Javaanwendung aus dem Internet.
Kleiner Tipp:
StartupWMClass=HierNameDerKlasseWelcheBeimStartGeladenWird
So kann die Desktopumgebung einer Javaanwendung auch im laufenden Betrieb das Icon zuordnen, sieht hübscher aus (Okay, Java ist nie hübsch...) und hilft dem Anwender. Ist ein Workaround, weil Java ein Spezifikation nicht umsetzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 11:47.Gemäß Kommentar des Entwickler ist die Konsole für so solche und ähnliche Fälle (z.B. AppImage) jedem Benutzer problemlos zuzumuten.
Die Reaktion der betroffenen wird zeigen ob dem so ist...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 14:03.Mir persönlich ist es egal, ich benutze KDE Plasma 5 und jetzt habe ich einen Grund mehr es dabei zu belassen.
... und da es für Linux schon Desktopumgebungen wie Mate und XFCE gibt, ist GNOME überflüssig und kann entfernt werden ...
Und man reisst ja auch bei einem Haus nicht das Fundament ab, weil das Dach viel schöner ist
über LXQt könnte man mittelfristig aber nachdenken
- XFCE basiert nicht auf Gnome
- Mate basiert auf Gnome 2
- Budgie basiert auf Gnome 3, möchte aber davon und von GTK unabhängig werden, weil sich Gnome nicht kooperativ verhält.
Korrektur: Mate basierte urspünglich auf GTK2 und wurde auf GTK3 portiert
Ich weiß nicht, ob und wieviel Mate mittlerweile von GNOME 3 übernommen hat, jedoch basieren tut es ursprünglich auf GNOME 2. Mittlerweile haben sie einiges (alles?) auf GTK 3 portiert, weswegen ich nie verstanden habe, warum sie nicht GNOME 3.6 geforkt haben, weil dort bereits alles auf GTK 3 gewesen wäre und die Funktionalität wie bei GNOME 2 gegeben war. Mate hätte sich das Portieren gespart und wäre heute um Jahre weiter. Vielleicht wollte Mate ursprünglich bei GTK 2 bleiben.
MFG
Sind die Mate-Entwickler nicht diejenigen, die Canonicals totes Pferd "Mir" weiterreiten und das inzwischen von einer Alternative für X11 und Wayland zu einem Wayland-Kompositor umgeplant haben?
Ja ursprünglich begann es noch als GTK2- Projekt, Mate selbst ist aber vollständig auf GTK3 portiert worden. Ein Fork von Gnome3 hätte doch gar kein Sinn gemacht und funktional ist es ja die Nische von Cinnamon das Gnome im Unterbau hat und eine andere Benutzerführung liefert. Schau dir ein aktuelles Mate an, es lohnt sich.
Ich meine ja, Gnome3 ohne Gnome-Shell mit Flashback-Panel, welches dem klassischen Gnome2-Panel sehr nahe kommt. Cinnamon hat Gnome3.6 geforkt, jedoch die Gnome-Shell umgebaut. Alle drei, Mate, Cinnamon und Gnome3 haben sich dann natürlich auseinander entwickelt.
Mate und Cinnamon, sollten fusionieren, um die klassischen Applikationen zu pflegen und weiter zu entwickeln. Im Prinzip machen sie ja, bis auf die Desktopoberflächliche, das gleiche.
Was ich an Gnome3 schätze ist die Integration von NextCloud. Vor allen Dingen des Kalenders und Adressbuches. Gibt es das bei Mate oder Cinnamon mittlerweile auch?
MFG
Ah, verstehe.
Ich bin da ganz bei dir und gehe da noch viel weiter, Mate, Cinnamon und XFCE sollten fusionieren. 
Ich nutze keine Cloud, aber es gibt eine Integration von Owncloud und nach meinem Wissen funktioniert das ja dann auch für Nextcloud.
Ja, dann werde ich mir das mal ansehen. Danke für die Info!
Dein Vorposter hat recht:
MATE ist das Gnome2.
Nachdem die Gnome Entwickler beschlossen haben, Gnome2 als "deprecated" bzw. "veraltet" abzutun, wurde es von diesen Leuten 1:1 geforkt, umbenannt und weiterentwickelt.
Zunächst fand erstmal ein Bugfixing statt bzw. wurden einige wie auch immer geartete Elemente angepasst.
Der Fokus danach war das Portieren auf Gtk3.
Nichtsdestotrotz ist Mate eine Weiterführung von Gnome2, da es letztendlich Gnome2 ist. Halt jetzt weitgehend auf Gtk3 portiert.
Unterschied zwischen Toolkit und Desktopumgebung geläufig?
[_] Ja
[X] Nein
Mate und XFCE nehmen GTK3 als Toolkit und nicht aber GNOME3 als Basis. Das hat vor längerer Zeit z.B. Cinnamon gemacht, allerdings nur ausgesuchte Komponenten. Aber auch hier stimmt es: Weil es ja Cinnamon (und Budgie) gibt, kann man GNOME3 als überflüssig entfernen.
> Mate und XFCE nehmen GTK3 als Toolkit und
> nicht aber GNOME3 als Basis.
Das ist vollkommen richtig!
Aber!
Ursprünglich hat sich Xfce einiges von Gnome1/2 entliehen. Das liegt aber etliche Jahre zurück. Wenn ich nicht falsch liege, so basierte das xfce4-panel auf gnome-panel.
Einige andere Bereiche ursprünglich auch. Nur sieht man da heute nix mehr von, da alles über die Jahre entkernt und verbessert wurde.
Einiges ist in Exo, Garcon, libxfce4ui, libxfce4util usw. eingeflossen.
Was auch immer bei XFCE noch Gnome1/2 Ursprung haben sollte, wurde auf GTK3 portiert. Und durch die Reste eines gnome2-panel codes basider XFCE immer noch nicht auf GNOME3.
Es ist ohnehin erstaunlich, dass fast jeder der GNOME3 modifizert es mit Extensions erweitert, die die DE wieder Gnome2-iger, Windows-iger oder Mac-OSX-iger machen.
Den originären genuine GNOME3 Workflow hingegen (ich finde ohne Extensions keinen echten "flow" ohne ein Dutzend Shortcuts) versucht keiner ernsthaft zu kopieren.
Der Nautilus wird doch schon seit Ewigkeiten immer weiter kastriert. Selbst das Löschen von Dateien per Maus hatten sie mal ausgebaut. Bals wird er ein reiner Dateibetrachter sein. Alles andere könnte den Anwender verwirren.
Nun gut, wenigstens Google hatte offenbar ein einsehen: Files Go von Google
Würde mich ehrlich nicht wundern wenn der Datei-Manager von GNOME irgendwann mit recht ähnlichen Begründungen ganz raus fliegt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 14:16.Die vielen Dateien verwirren doch nur die Nutzer. Zukünftig werden nur noch bestimmte Ordner und spezielle Dateiformate angezeigt.
8)
Wie lange brauch ich mit der Spitzhacke, bis da wirklich keiner mehr ran geht ?
Spasseshalber könnten die ja Nautilus noch halb benutzbar halten und parallel währenddessen einen Nachfolger from scratch neu schreiben...
.... aber das wäre wohl zu banal
Der Dateibrowser soll für entsprechende Dateien bei Doppelklick die Standardanwendung öffnen oder eben eine andere per Kontextmenü. Hier bleibt alles, so wie es ist.
Ich vermute, einige hier verstehen die beschriebene Änderung nicht. Es wird die Funktion entfernt, dass eine Anwendung (Executable) als solche explizit über Nautilus gestartet wird. Etwa per Doppelklick ein Shellskript, wovor Nautilus schon seit gefüllt immer umständlich warnt. Weil man dann nicht sieht, was passiert, daher mit Rechtsklick Terminal aufmachen und richtiger Weise im Terminal ausführen.
Einzig und allein nervige Java-Anwendung kommen oft nur mit Wrapperscripten und ohne .desktop-Datei. Die werden jetzt umständlicher zu starten sein oder man legt wie oben beschrieben eine .desktop-Datei an. Habe ich vor einiger Zeit schon getan für eine (nervige) eigene Javaanwendung, seit dem hat sie auch einen hübsches Icon und kann bequemer gestartet werden oder im Dateibrowser ins Verzeichnis zu navigieren.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Mai 2018 um 11:38.Abgesehen davon, dass diese nervigen Wrapperscripte meistens sowieso nicht funktionieren...
Nur das .desktop Dateien sich zukünftig auch nicht mehr in Nautilus ausführen lassen. Bleibt dann nur der Weg über das Hauptmenü.
Die .desktop-Dateien können sinnvoller Weise nur in drei Verzeichnissen liegen:
/usr/share/applications, /usr/local/share/applications oder ~/.local/share/applications
Zu Testzwecken fände ich eine direkte Ausführbarkeit aus Nautilus bequem, die Hauptaufgabe von Nautilus ist jedoch den Anwender in diesen Verzeichnissen die Dateien anlegen, ändern oder löschen zu lassen.
Womit du vollkommen Recht hast.
Normalerweise kritisiere ich oft den Desktopwildwuchs bei Linux... aber seit Gnome3 bin ich auch froh das diese Vielfalt existiert ^^
Niemand muss Gnome3 nutzen.
Eine Sache nicht vergessen!
Die Entkernung in Gnome3 dient dem Platzmachen für "Flatpaks", denn darauf wird sich Gnome fokussieren.
Einige Nutzer orakeln hier mit java -jar usw., was zwar belustigend ist, aber letztendlich so unwahr garnicht ist.
Auch wenn du künftig einen anderen Desktop nutzen kannst, wirst du langfristig wohl damit konfrontiert, dass klassische Pakete wie deb oder rpm verschwinden werden und Programme wie Gimp, Libreoffice, Firefox (und denken wir an die ganzen proritären Programme) nur noch als Flatpaks angeboten werden.
Das heisst dann für dich:
Du wirst gezwungen werden, eine vorcompilierte binäre Laufzeitumgebung von flathub herunterzuladen. Diese wird dann in dein /var/lib/flatpak Verzeichnis installiert und darauf werden dann deine Programme laufen gelassen.
Weder du noch deine Distribution werden Einfluss auf diese vorcompilierten Binär"blobs" haben.
Das wird die Zukunft sein.
Ähm .... nein.
OSS ist nicht OSS wenn die Sourcen nicht offen vorliegen. Die neuen "Packs" sind letztendlich nur das Endprodukt, die du auch selbst Herstellen kannst.
CSS wird sich diese "Packs" auch zu nutze machen können und einfach ausliefern können.
Eigentlich ändert sich nur die Installationsart.
> Eigentlich ändert sich nur die Installationsart.
Das ist bedingt richtig.
Bei der Verwendung von Flatpaks wird eine neue Laufzeitumgebung bei dir auf dem Rechner ins /var/lib/flatpak installiert.
Der Sinn von Flatpaks war ja, die Einhaltung von Binärkompatibilität. Diese kann nur auf Grundlage einer gemeinsamen binären Laufzeitumgebung garantiert werden.
Wenn z.B. nun Debian ihr eigenes Flatpak runntime kompiliert, Arch ihr eigenes, Fedora ihr eigenes, Gentoo ihr eigenes usw. dann ist doch das, was Flatpaks ausmacht dahin.
Sobald du mittels
flatpak install org.whatever.blah
auführst, wird automatisch getestet, ob eine signierte Laufzeitumgebung auf deinem Rechner installiert ist. Ist dies nicht der Fall, wird diese binäre Laufzeitumgebung von flathub heruntergeladen und auf deinem System installiert.
Es ändert sich daher was, da man dir eine 250mb Laufzeitumgebung auf dein Debian oder was auch immer System unterjubelt, damit deine Flatpaks dann auch laufen.
Historisch hab ich mich mal für KDE/Plasma als UI entschieden. Ich habe manchmal daran gezweifelt, ob die Macher noch wissen, was sie tun aber irgendwann hat sich auch das größte Chaos in Wohlgefallen aufgelöst.
Plasma 'heute' mag optisch nicht meinem Geschmack entsprechen aber es entwickelt sich funktional weiter und wird Schritt für Schritt stabilisiert. Man spürt an den Diskussionen, dass die Entwicklergemeine versucht, die Interessen des Benutzers im Auge zu haben. Die decken sich selten mit meine persönlichen aber das wäre ja auch ein Wunder ..
Wenn ich mir andere DE ansehe denk ich vielfach: ganz nett aber ich hab ja Plasma.
Wenn ich Gnome sehe denk ich nur: noch ein Jahr und die haben sich selbst abgeschafft.
Gestern standen wir am Abgrund. Heute haben wir einen großen Schritt nach vorne gemacht ............
Bedenkt man in diesem Kontext, dass selbst der Gründer und Initiator des Gnome Projekts letztendlich resigniert aufgegeben hat.
Niemand gibt ein Lebenswerk einfach so auf, es sei denn:
- Das Projekt geht in eine vollkommene falsche Richtug! (was jetzt der Fall ist)
- Man hat das Projekt aus der Hand gegeben bzw. sich wegnehmen lassen (damit meine ich die Projektkoordination, so wie sie Linus Torvalds inne hat)
- Interne Zerrissenheit
Der Nautilus-Dateimanager ist schon lange nur noch ein einziger Krampf. Als ich mit Ubuntu im Oktober 2007 anfing, gab es noch echte Fortschritte bei der Entwicklung des Nautilus. Man konnte mit der Maus über eine Musikdatei fahren und der Titel wurde angespielt - sehr praktisch. Heute gibt es nicht mal mehr vernünftige Dateioperationen. Daher verwende ich weitgehend nur noch Nemo - der ist um Klassen besser, nur leider etwas instabil.
Ohnehin ist der Gnome-3-Desktop zwar hübsch, aber nicht komfortabel. Wer denkt sich aus, dass der Aktivitäten-Knopf links, die Auswahl der einzelnen Desktops dann aber rechts liegt? Das kann nur jemand, der mit der Oberfläche rumspielt, aber nicht produktiv arbeitet.
Die Entwicklung von Gnome ist schlicht zum Heulen. Meine Meinung.
> Der Nautilus-Dateimanager ist schon lange nur
> noch ein einziger Krampf.
Wann war er das schonmal nicht ? Ich kann mich noch erinnern, als Eazel (die Firma dahinter) Nautilus bei Gnome einführte und somit das gmc (Midnight Commander mit Gtk+ Frontend) ersetzte. Nautilus war so derbe lahm und langsam, dass es niemand wirklich nutzen konnte.
Selbst damals wollte man bereits einen Gnome-Store ettablieren. Halt durch Nautilus und dem Support den Eazel verticken wollte. Die haben irgendwie 10-20 mio an Fördergelder verbrannt, für eine Software, die damals schon nicht wirklich zu gebrauchen war.
"Daher verwende ich weitgehend nur noch Nemo - der ist um Klassen besser, nur leider etwas instabil."
Sehe ich genau so. Bin wegen der Stabilität von Nemo auf Caja umgeschwenkt und habe es bisher nicht bereut.