Bei mi ist es nano und Xed. Die beiden zum "schnellen Editieren". Zum Coden Geany und Sublime Text. Alles unter KDE. Kein Widerspruch. Ich mag Plasma5 als Desktop, und ich mag "einfache" Editoren; die sind "leider" alle mit Gtk. Macht aber nix, sind gut integriert. Von den insgesamt sieben GUI-Editoren ist Xed mein liebster. Und was das Terminal angeht: eigentlich gibt es noch einen. Nämlich den Editor von mc (mcedit). Aber den konfiguriere ich immer raus und ersetze ihn durch nano. Das reicht fürs Terminal. Wenn die Dinge komplexer werden, geht's in die GUI. Verlangt die GUI einen Editor, poppt bei mir unter KDE Plasma der Sublime Text Editor auf. Da kann man dann wunderbar am Rand lange Texte überblicken, durch die Vorschau. Sozusagen spielt sich bei mir das Thema Editor zwischen nano und Sublime Text eher fleißend ab. Je nachdem, was in der Situation am Besten passt. Ich bin da nicht wirklich festgelegt.
KDE hat mit Kate einen sehr leistungsstarken Editor und man spart sich die Ladezeiten und den Speicherverbrauch für das GTK Toolkit, wenn man Kate anstatt irgendwelche GTK basierten Editoren einsetzt.
Warum sollte man als GUI Editor unter KDE dann etwas anderes als Kate einsetzen wollen? IDEs jetzt mal ausgenommen.
Warum sollte man als GUI Editor unter KDE dann etwas anderes als Kate einsetzen wollen? IDEs jetzt mal ausgenommen.
Eben. Und Geany geht schon ziemlich Richtung IDE. Und ob Kate (welcher wirklich ein guter, solider Editor ist) mit Sublime Text mithalten kann, weiß ich jetzt nicht.
Ansonsten kann man auch gegenfragen: Warum nicht? Selbst wenn es nur nach dem persönlichen Geschmack geht rechtfertigt es das doch.
Und als Begründung Ladezeiten und Speicherverbrauch anzuführen. Auf nem halbwegs modernen Rechner? Wirklich? Ich hoffe, Du nimmst dann auch als Browser kein Chrome oder Mozilla, sondern Falkon (welcher, nebenbeibemerkt, auch gar nicht mal so schlecht ist).
Und als Begründung Ladezeiten und Speicherverbrauch anzuführen. Auf nem halbwegs modernen Rechner? Wirklich?
Ja, dieser Punkt gerät nach und nach ins Hintertreffen. Aber mir ist bei so etwas wie einem Editor, dem Dateimanager und der Konsole es eben sehr wichtig, dass diese Programme unter einem Desktop Environment sofort in einem Augenblick verfügbar sind. Das erreicht man am besten, in dem man eben Programme nimmt, die das gleiche Toolkit wie das Desktop Environment verwenden.
Bei einem Browser ist der der Support bezüglich Sicherheitslücken viel wichtiger als die Ladezeiten oder der Speicherverbrauch. Da kann bzw. sollte man keinen Nischenbrowser einsetzen, sondern einen, der ein großes Entwicklerteam hinter sich hat und aktiv täglich oder noch besser stündlich supported wird. Das wird von Firefox gewährleistet.
[...]Das erreicht man am besten, in dem man eben Programme nimmt, die das gleiche Toolkit wie das Desktop Environment verwenden.
Bei einem Browser ist der der Support bezüglich Sicherheitslücken viel wichtiger als die Ladezeiten oder der Speicherverbrauch.[...]
Nichtsdestotrotz ist ers eben so, wenn Du Firefox verwendest, verwendest Du auch Gtk. Und dann machen weitere Gtk-Programme dementsprechend auch nix aus.
Das kommt ganz darauf an, wie Firefox ausgeliefert wird. Verwendet es die libs der Distro oder kommt es als so ne Art Flatpack mit eigenen Libs daher? Die Frage ist insbesondere im Hinblick auf die ESR Version interessant.
Gib daher mal in einer Konsole folgenden Befehl ein:
Gewöhnungssache? Jemand, der viel auf der Shell vor sich hineditiert will die gewohnten Werkzeuge auch unter KDE/Gnome/wasauchimmer nutzen? Irgendwie entwickelt ja jeder seinen eigenen "Workflow".
Ich weiß auch nicht, worin der Widerspruch liegen sollte. Bzw. kann ich nicht nachvollziehen, warum man unter KDE nur KDE/QT-Programme benutzen sollte und unter nem Gtk-Desktop nur Gtk-Programme.
Bzw. kann ich nicht nachvollziehen, warum man unter KDE nur KDE/QT-Programme benutzen sollte und unter nem Gtk-Desktop nur Gtk-Programme.
Verfügbarkeit und Resourcenverbrauch wären hier die Argumente.
Die QT Libs sind unter KDE ja schon geladen, eine QT Anwendung startet also ratz fatz, die Bibliotheken müssen nicht erst geladen werden, denn die sind schon im Speicher, weil das KDE diese braucht und schon geladen hat.
Lädst du jetzt eine GTK Anwendung, dann muss die GTK Lib geladen werden, das dauert, zugegeben mit einer SSD ist das heute nicht mehr so schlimm, aber früher, als man noch Festplatten auf dem Desktop verwendee hat, hat man das deutlich gemerkt. Neben der zusätzlichen Ladezeit kommt dann noch ein zusätzlichen Speicherverbrauch dazu. Und ja, auch das Argument gerät heutzutage nach und nach auf einem PC ins hintertreffen, aber auf einem Rechner mit wenig RAM, z.b. einem Einplatinencomputer, wird das auch heute noch eine Rolle spielen.
Nicht wirklich. Gtk-Applikationen unter Plasma5 sehen kaum anders aus. Manchmal stört es, wenn Knöpfe anders herum sind (OK-Knopf und Abbrechen-Knopf z.B.) Aber da halten sich noch nicht einmal alle Gtk-Programmierer dran, Knöpfe gleichartig anzuordnen. Das ist dann der Nachteil von Open Source. Aber auch das nicht wirklich. Vor jedem anklicken sollte man nochmal nachdenken. Selbst bei MacOSX.
Und Fenstergestaltung - das ist ja das Gute, wenn man integrierte Gtk-Applikationen in der Qt-Umgebung von KDE Plasma hat. Sie sehen eben gleich aus. Auch hier sind es nur einzelne Ausnahmen wie Vivaldi und Opera, die aus der Art schlagen. Zim und Claws Mail machen ein wenig Arbeit und die Ikonisierung ist anders. Aber immerhin gibt es zahlreiche Themes, um Claws Mail an Plasma anzugleichen. Mich stören Differenzen nicht mehr, aber das Tool ist mir eben um vieles lieber als KMail. Claws hat soviele Besonderheiten, dass man sich sowieso einarbeiten muss. Dafür ist es leichter konfigurierbar, wenn man nicht den Standard-Weg geht. Der Hauptgrund ist für mich natürlich, dass man bei KMail richtig alt aussehen kann, wenn das Datenbank-Backend mal wieder austickt. Dann nützt mir supergutes Look&Feel überhaupt nichts.
Der Hauptgrund ist für mich natürlich, dass man bei KMail richtig alt aussehen kann, wenn das Datenbank-Backend mal wieder austickt.
Akonadi ist nur ein Caching-Dienst. Wenn der mal 'austickt' (habe ich personönlich aber schon lange nicht mehr gehabt), dann löscht man einfach seine Datenbank und startet den Dienst neu. Der erstellt die Datenbank dann neu und baut den Cache wieder auf. Da geht nichts an Daten verloren, daher sehe ich auch nicht, warum man da 'alt aussehen' sollte.
Falsch. Akonadi ist ein Storage-Framework. Eine Funktionalität davon ist die Möglichkeit, Daten zu indizieren damit man schneller suchen kann. So braucht muss z.B. Kmail nicht alle Maildateien durchsuchen, wenn man z.B. alle Mails von einem bestimmten Empfänger sucht, sondern kann sich des Indizes bedienen, wodurch die Suche dann natürlich um ein Vielfaches schneller geht.
Das Suchen und Indizieren (nicht nur von E-Mails) macht unter KDE/Plasma der Indizierungsdienst Baloo, nicht Akonadi.
Jaein. Wenn BalooAkonadi vorfindet und das auch für Mails verwenden wird, dann benutzt es Akonadi.
Du kannst es übrigens selbst überprüfen, was Akonadi speichert. Entweder Du gehst direkt auf die Datenbank (meist ne mysql-Instanz) oder mit dem Programm akonadiconsole
Außerdem gibts auch ne Webseite dazu: https://community.kde.org/KDE_PIM/Akonadi
> Gtk-Applikationen unter Plasma5 sehen kaum anders aus.
Oh doch! Zum einen fühlen sich die Anwendungen selbst schon anders an (Pluma !!!= Okular) – und dann geh mal in den Datei-Öffnen-Dialog! Dann starte mal Simple Scan – das sieht aber sowas von nicht nach Plasma aus (selbst, wenn es in grafischen Details etwas angeglichen ist). (Dennoch ein feines Programm, für einfache Scans ziehe ich das Skanlite vor.)
Oh doch! Zum einen fühlen sich die Anwendungen selbst schon anders an (Pluma !!!= Okular) – und dann geh mal in den Datei-Öffnen-Dialog!
Ja. Gtk-Programme sind anders vom Look&Feel als KDE/QT-Programme. Aber mal ehrlich: Wenn interessierts? Also wirklich?
Ich ich ein Programm als nützlich empfinde, dann nehme ich es und guck nicht nach dem Toolkit. Und es irritiert mich auch jetzt nicht so sehr, das es an die Unbenutzbarkeit geht.
Man kann ja drüber nachdenken zu einem Programm zu wechseln, wenn es gleich gut ist wie die Alternative, damit es sich besser ins Look&Feel integriert. Aber höher würde ich das Thema auch nicht aufhängen.
Mate würde ich auf einem Odroid C2 einsetzen. Insofern, Ja.
Und ja, Mate ist ein fuill-featured-Desktop, immerhin war das mal Gnome 2.
Der Odroid C2 kommt allerdings schon mit 2 GB RAM.
KDE würde ich auch in seiner neusten Inkarnation auf einem Rechner mit 2 GB RAM durchaus auch laufen lassen. Das Problem ist hier aber eher meistens die fehlende 3d Beschleunigung für OpenGL, weswegen es momentan eher Mate wäre, welches noch in einem althergebrachten 2d Betrieb zufriedenstellend arbeitet.
nano und mcedit.
Bei mi ist es nano und Xed. Die beiden zum "schnellen Editieren". Zum Coden Geany und Sublime Text. Alles unter KDE. Kein Widerspruch. Ich mag Plasma5 als Desktop, und ich mag "einfache" Editoren; die sind "leider" alle mit Gtk. Macht aber nix, sind gut integriert. Von den insgesamt sieben GUI-Editoren ist Xed mein liebster. Und was das Terminal angeht: eigentlich gibt es noch einen. Nämlich den Editor von mc (mcedit). Aber den konfiguriere ich immer raus und ersetze ihn durch nano. Das reicht fürs Terminal. Wenn die Dinge komplexer werden, geht's in die GUI. Verlangt die GUI einen Editor, poppt bei mir unter KDE Plasma der Sublime Text Editor auf. Da kann man dann wunderbar am Rand lange Texte überblicken, durch die Vorschau. Sozusagen spielt sich bei mir das Thema Editor zwischen nano und Sublime Text eher fleißend ab. Je nachdem, was in der Situation am Besten passt. Ich bin da nicht wirklich festgelegt.
KDE hat mit Kate einen sehr leistungsstarken Editor und man spart sich die Ladezeiten und den Speicherverbrauch für das GTK Toolkit, wenn man Kate anstatt irgendwelche GTK basierten Editoren einsetzt.
Warum sollte man als GUI Editor unter KDE dann etwas anderes als Kate einsetzen wollen?
IDEs jetzt mal ausgenommen.
Und ob Kate (welcher wirklich ein guter, solider Editor ist) mit Sublime Text mithalten kann, weiß ich jetzt nicht.
Ansonsten kann man auch gegenfragen: Warum nicht?
Selbst wenn es nur nach dem persönlichen Geschmack geht rechtfertigt es das doch.
Und als Begründung Ladezeiten und Speicherverbrauch anzuführen. Auf nem halbwegs modernen Rechner? Wirklich?
Ich hoffe, Du nimmst dann auch als Browser kein Chrome oder Mozilla, sondern Falkon (welcher, nebenbeibemerkt, auch gar nicht mal so schlecht ist).
Ja, dieser Punkt gerät nach und nach ins Hintertreffen.
Aber mir ist bei so etwas wie einem Editor, dem Dateimanager und der Konsole es eben sehr wichtig, dass diese Programme unter einem Desktop Environment sofort in einem Augenblick verfügbar sind.
Das erreicht man am besten, in dem man eben Programme nimmt, die das gleiche Toolkit wie das Desktop Environment verwenden.
Bei einem Browser ist der der Support bezüglich Sicherheitslücken viel wichtiger als die Ladezeiten oder der Speicherverbrauch.
Da kann bzw. sollte man keinen Nischenbrowser einsetzen, sondern einen, der ein großes Entwicklerteam hinter sich hat und aktiv täglich oder noch besser stündlich supported wird. Das wird von Firefox gewährleistet.
Das kommt ganz darauf an, wie Firefox ausgeliefert wird.
Verwendet es die libs der Distro oder kommt es als so ne Art Flatpack mit eigenen Libs daher?
Die Frage ist insbesondere im Hinblick auf die ESR Version interessant.
Gib daher mal in einer Konsole folgenden Befehl ein:
https://packages.debian.org/stretch/firefox-esr
Die Antwort ist also ziemlich eindeutig.
Gewöhnungssache? Jemand, der viel auf der Shell vor sich hineditiert will die gewohnten Werkzeuge auch unter KDE/Gnome/wasauchimmer nutzen? Irgendwie entwickelt ja jeder seinen eigenen "Workflow".
Insofern muss ich Dir der zustimmen.
Verfügbarkeit und Resourcenverbrauch wären hier die Argumente.
Die QT Libs sind unter KDE ja schon geladen, eine QT Anwendung startet also ratz fatz, die Bibliotheken müssen nicht erst geladen werden, denn die sind schon im Speicher, weil das KDE diese braucht und schon geladen hat.
Lädst du jetzt eine GTK Anwendung, dann muss die GTK Lib geladen werden, das dauert, zugegeben mit einer SSD ist das heute nicht mehr so schlimm, aber früher, als man noch Festplatten auf dem Desktop verwendee hat, hat man das deutlich gemerkt.
Neben der zusätzlichen Ladezeit kommt dann noch ein zusätzlichen Speicherverbrauch dazu.
Und ja, auch das Argument gerät heutzutage nach und nach auf einem PC ins hintertreffen, aber auf einem Rechner mit wenig RAM, z.b. einem Einplatinencomputer, wird das auch heute noch eine Rolle spielen.
Und immer noch ein anderes Look'n'Feel.
Nicht wirklich. Gtk-Applikationen unter Plasma5 sehen kaum anders aus. Manchmal stört es, wenn Knöpfe anders herum sind (OK-Knopf und Abbrechen-Knopf z.B.) Aber da halten sich noch nicht einmal alle Gtk-Programmierer dran, Knöpfe gleichartig anzuordnen. Das ist dann der Nachteil von Open Source. Aber auch das nicht wirklich. Vor jedem anklicken sollte man nochmal nachdenken. Selbst bei MacOSX.
Und Fenstergestaltung - das ist ja das Gute, wenn man integrierte Gtk-Applikationen in der Qt-Umgebung von KDE Plasma hat. Sie sehen eben gleich aus. Auch hier sind es nur einzelne Ausnahmen wie Vivaldi und Opera, die aus der Art schlagen. Zim und Claws Mail machen ein wenig Arbeit und die Ikonisierung ist anders. Aber immerhin gibt es zahlreiche Themes, um Claws Mail an Plasma anzugleichen. Mich stören Differenzen nicht mehr, aber das Tool ist mir eben um vieles lieber als KMail. Claws hat soviele Besonderheiten, dass man sich sowieso einarbeiten muss. Dafür ist es leichter konfigurierbar, wenn man nicht den Standard-Weg geht. Der Hauptgrund ist für mich natürlich, dass man bei KMail richtig alt aussehen kann, wenn das Datenbank-Backend mal wieder austickt. Dann nützt mir supergutes Look&Feel überhaupt nichts.
Akonadi ist nur ein Caching-Dienst. Wenn der mal 'austickt' (habe ich personönlich aber schon lange nicht mehr gehabt), dann löscht man einfach seine Datenbank und startet den Dienst neu. Der erstellt die Datenbank dann neu und baut den Cache wieder auf. Da geht nichts an Daten verloren, daher sehe ich auch nicht, warum man da 'alt aussehen' sollte.
Eine Funktionalität davon ist die Möglichkeit, Daten zu indizieren damit man schneller suchen kann.
So braucht muss z.B. Kmail nicht alle Maildateien durchsuchen, wenn man z.B. alle Mails von einem bestimmten Empfänger sucht, sondern kann sich des Indizes bedienen, wodurch die Suche dann natürlich um ein Vielfaches schneller geht.
Das Suchen und Indizieren (nicht nur von E-Mails) macht unter KDE/Plasma der Indizierungsdienst Baloo, nicht Akonadi.
Du kannst es übrigens selbst überprüfen, was Akonadi speichert.
Entweder Du gehst direkt auf die Datenbank (meist ne mysql-Instanz) oder mit dem Programm
akonadiconsoleAußerdem gibts auch ne Webseite dazu:
https://community.kde.org/KDE_PIM/Akonadi
> Gtk-Applikationen unter Plasma5 sehen kaum anders aus.
Oh doch! Zum einen fühlen sich die Anwendungen selbst schon anders an (Pluma !!!= Okular) – und dann geh mal in den Datei-Öffnen-Dialog!
Dann starte mal Simple Scan – das sieht aber sowas von nicht nach Plasma aus (selbst, wenn es in grafischen Details etwas angeglichen ist). (Dennoch ein feines Programm, für einfache Scans ziehe ich das Skanlite vor.)
Aber mal ehrlich: Wenn interessierts? Also wirklich?
Ich ich ein Programm als nützlich empfinde, dann nehme ich es und guck nicht nach dem Toolkit. Und es irritiert mich auch jetzt nicht so sehr, das es an die Unbenutzbarkeit geht.
Man kann ja drüber nachdenken zu einem Programm zu wechseln, wenn es gleich gut ist wie die Alternative, damit es sich besser ins Look&Feel integriert.
Aber höher würde ich das Thema auch nicht aufhängen.
Interessant.
Mate würde ich auf einem Odroid C2 einsetzen.
Insofern, Ja.
Und ja, Mate ist ein fuill-featured-Desktop, immerhin war das mal Gnome 2.
Der Odroid C2 kommt allerdings schon mit 2 GB RAM.
KDE würde ich auch in seiner neusten Inkarnation auf einem Rechner mit 2 GB RAM durchaus auch laufen lassen.
Das Problem ist hier aber eher meistens die fehlende 3d Beschleunigung für OpenGL, weswegen es momentan eher Mate wäre, welches noch in einem althergebrachten 2d Betrieb zufriedenstellend arbeitet.