LXQt ist KDE im ursprünglichen Sinne. Endlich gibt es wieder eine Desktop-Umgebung mit Qt. Mit LXQt ist man auch kein Versuchstier in Sachen semantischer Desktop. Die Nutzer müssen hier auch keine Angst haben, dass der Versuchsaufbau nach Ende des Experiments abgebaut wird.
setzt die leichte Desktopumgebung Teile der KDE Frameworks 5 ein ...
Ich versteh die meisten Aussagen im Text nicht, da ich die beiden Umgebungen, LxQT u. KDE nicht kenne, somit auch nicht die angesprochenen Komponenten.
Aber ist das wirklich schlau, sich an KDE ranzuhängen und sich von deren Ideen abhängig zu machen?
Und ist mit dem Einbau von KDE-Zeug nicht das Attribut "leichtgewichtig" bei LxQT in Gefahr?
Aber ist das wirklich schlau, sich an KDE ranzuhängen und sich von deren Ideen abhängig zu machen?
Es ist schlau Bibliotheken zu benutzen, um so nicht viele triviale Dinge programmieren zu müssen, die es bereits gibt.
Und ist mit dem Einbau von KDE-Zeug nicht das Attribut "leichtgewichtig" bei LxQT in Gefahr?
Durch die starke Modularisierung von KDE Frameworks 5 ist es möglich, gezielt das zu verwenden, was man für LXQt benötigt, ohne Tonnen von unnötigen Abhängigkeiten. Ich bin mir sicher, dass das LXQt-Team nach wie vor ein leichtgewichtiges DE als Ziel hat.
Durch die Aufsplittung der Kdelibs in einzelne Bibliotheken/Frameworks sind die jeweils mitgebrachten Abhängigkeiten minimal und die Leichtgewichtigkeit nicht in Gefahr. Bei KDE Platform 4 war das alles monolithisch und so für andere Projekte kaum einsetzbar.
Aber ist das wirklich schlau, sich an KDE ranzuhängen und sich von deren Ideen abhängig zu machen?
In der Softwareentwicklung ist es sehr üblich, Bibliotheken einzusetzen, die man nicht selbst entwickelt hat.
Das erlaubt einem, sich auf die eigentlichen Ziele zu konzentrieren, im Falle von LXQt eben auf das Entwickeln einer Desktopshell und verwandter Dienstprogramme.
Die hier eingesetzten Bibliotheken von KDE entstammen der selben Zielsetzung, sie sind für LXQt daher praktisch perfekte Bausteine.
Leider macht Software mit dutzend schicken Bibliotheken auch immer wieder wegen diesen Probleme, wenn man sie auf einer anderen Plattform als der Entwickler verwenden möchte. Dann wir wieder damit angefangen Dinge statisch dazu zupacken, aber das hat dann auch wieder Nachteile.
Man könnte alles ab dem Kernel Interface direkt in die Applikation packen, oder System Bibliotheken benutzen, oder Bibliotheken für graphische Benutzerschnittstellen, usw.
Aber nachdem es Möglichkeiten wie statisches und dynamisches Linken gibt, wird man sich meistens darauf konzentrieren, die Entwicklungsressourcen für die eigentlichen Zwecke der Applikation zu verwenden.
Es ist sehr oft eine Frage äußerer Parameter: ein System mit fixer Hardware/Softwarekombination kann die Benutzung derselben viel simpler und konkreter realisieren, wenn das System einer dynamischen Umwelt ausgesetzt wird, ist das Selbstentwickeln von Hardwareerkennung usw. schnell außerhalb der verfügbaren Mittel.
Aber ist das wirklich schlau, sich an KDE ranzuhängen und sich von deren Ideen abhängig zu machen?
Der Artikel erwähnt KWindowSystem. Das ist eine Bibliothek die in KDE seit etwa 15 Jahren eingesetzt wird, Qt und X11 only ist. Sie ist sehr gut getestet und es hängt die ganze X11 Erfahrung drinnen von KWin und Plasma. Sie nicht einzusetzen bedeutet den Code selber zu schreiben mit großer Gefahr das falsch zu machen. Als offizieller Maintainer von KWindowSystem kann ich nur sagen: sehr venünftige Entscheidung darauf zu setzen.
Und ist mit dem Einbau von KDE-Zeug nicht das Attribut "leichtgewichtig" bei LxQT in Gefahr?
Ach wir haben jetzt auch schon Kommentare gehört, dass Plasma 5.2 weniger RAM benötigt als die so genannten "leichtgewichtigen" DEs.
Von Thomas Schuetz am Mo, 9. Februar 2015 um 09:42 #
Warum behaupten eigentlich alle Seiten, dass es dazu Pakete in Archlinux gibt? Es gibt in Arch gar keine LxQT-Pakete, lediglich im AUR Skripte dafür. Und die sind noch auf dem Stand 0.8: https://aur.archlinux.org/packages/lxqt/
Lediglich die GIT-AUR-Skripte können 0.9 kompilieren...
Verstehe ich eigentlich eh' nicht, warum es keine Pakete dafür in Arch gibt, eigentlich ist das doch für Archer genau die richtige Desktop-Umgebung...
Archer sind selbständig denkende Menschen, die sich aus der Vielfalt das aussuchen, was ihren Bedürfnissen entspricht. In meinem Fall ist das KDE/Plasma 5.
Archer sind selbständig denkende Menschen, die sich aus der Vielfalt das aussuchen, was ihren Bedürfnissen entspricht. In meinem Fall ist das KDE/Plasma 5.
Die Systemeinstellungen könnte man auch 1 mal für alle DTE realisieren. -> YaST auch mit Funktionen für den user.
Bei DBus und Wayland kommen mir Bedenken. Ich möchte gerne "ssh -X user@remote" machen können und remote Anwendungen auf meinem lokalen System bedienen können. Aber: - Wenn ich "ssh -X" mache wird remote kein DBus hochgefahren (z.B. auf einem Server). Das hat zur Folge, dass Anwendungen, die auf DBus setzen nicht nutzbar sind. - Wenn x11 durch Wayland ersetzt wird, erwarte ich Probleme mit "ssh -X". Ich hoffe, dass wenigstens noch "xterm&" funktioniert, d.h. die Kompatibilität so weit geht.
... Bleibt einem nur noch Curses auf remote Rechnern.
Wenn ich "ssh -X" mache wird remote kein DBus hochgefahren (z.B. auf einem Server). Das hat zur Folge, dass Anwendungen, die auf DBus setzen nicht nutzbar sind.
Ich muss sagen, mich wundert immer, wie lange es dauert, bis ssh entsprechende Forwarding Möglichkeiten anbietet. D-Bus wird jetzt sicher schon ein Jahrzehnt massiv benutzt, aber eingebautes Forwarding wie für X11 gibt es immer noch nicht.
Man muss sich dann mittels generischem Unix Socket Forwarding und manuellem (bzw. gescripteten) Setzen von Umgebungsvariablen auseinandersetzen.
Von da-real-lala am Do, 19. Februar 2015 um 07:17 #
Die Wayland Leute sagen ja immer, dass die Netzwerktransparenz jetzt auf die Toolkits ausgelagert wird. Daher sollte man da wahrscheinlich bei GTK, KDE usw. anfragen.
Ich vermute mal das nächste was sie von KDE übernehmen werden wird der kwin sein, wenn dadurch nicht zu viele Abhängigkeiten eingeschleppt werden, um sich beim Wayland-Support eine Menge Arbeit ersparen zu können.
Oder gibt es bei Openbox irgendwelche Bestrebungen hinsichtlich Wayland?
Soweit ich weiß, kann KWin mit sehr wenigen Abhängigkeiten auskommen. Das hängt immer von der Distro ab. Martin Gräßlin kann da aber sicher mehr dazu sagen. Bei RazorQt konnte man problemlos zwischen Openbox und KWin wechseln. Mit Kwin machte RazorQt dann richtig Laune.
Ich kann aus eigener Erfahrung sagen, dass sich KWin auch problemlos mit Xfce benutzen lässt (ich gebe zu, das ist nicht ganz naheliegend). Für LXQt bietet es sich natürlich um so mehr an...
Hm, das Verwenden eines Qt-Fenstermanagers in einem GTK-Environment scheint für manche ein Sakrileg zu sein, oder wie darf ich das negative Voting verstehen?
Da gibt es schon einen feinen Unterschied: Man wird auch in Zukunft GTK+ ODER Qt ODER beides benutzen können. Bei Systemd haben manche ihre Zweifel, ob man da künftig die freie Wahl hat. Das Ziel der Systemd-Entwickler ist jedenfalls klar: Kein Linux OHNE Systemd und kein Kernel außer Linux MIT Systemd. Ich habe zum Beispiel kein Problem mit Systemd als Initsystem(!) und benutze es bereits, habe aber ein Problem mit dieser Zukunftsperspektive, da es ja ganz offensichtlich nicht bei dem Thema Initsystem bleibt.
Also ich verfolge das Projekt jetzt schon seit längerem interessiert und freue mich zu sehen wie es immer weiter reift. Etwas das sich zu KDE verhält wie XFCE zu Gnome habe ich mir schon lange gewünscht. Auch die Entwicklungsentscheidungen, die getroffen werden, finde ich top. Allein schon, dass razorQt und LXDE sich zusammen getan haben, aber auch, dass man jetzt da, wo es sinnvoll ist, auf kde frameworks setzt! So muss die Entwicklung freier Software laufen Dann gäb's auch z.B. keine drei oder mehr verschiedene freie Videoschnittprogramme ...
Ich kann das alles unterschreiben, nur eine Frage: Was ist schlecht an drei oder mehr verschiedenen Videoschnittprogrammen? Ich bin froh, dass es mehrere gibt und der Meinung, dass es gar nicht genug geben kann. Ich alleine benutze schon regelmäßig, neben zahlreichen anderen Videotools, 4 verschiedene Videoschnittprogramme (KDEnlive, Kino, Avidemux, DVBCut) und jedes hat für bestimmte Tätigkeiten seine Vorzüge. Kein einziges dieser Programme möchte ich missen.
Habe zwar bisher LXQt noch nicht selbst getestet, aber das was ich über LXQt so lese und sehe, macht mich immer neugieriger! Aber leider gibt es LXQt derzeit unter Arch nur über das AUR. Hoffe, dass sich das vielleicht mal ändert.
Ich selber nutze seit Jahren KDE und habe meinen Arch Rechner erst am letzten Freitag KDE Plasma 4 auf Plasma 5 migriert. Es gibt natürlich noch viele Kleinigkeiten, die noch nicht so recht wollen oder wo es noch Bugs gibt, oder wo einfach der aktuelle Entwicklungsprozess noch nicht so weit fortgeschritten ist, aber dennoch muss ich bereits jetzt sagen, dass Plasma 5 selbst bereits relativ stabil und problemlos zu nutzen ist.
Ein Bug der aber wirklich nervt, betrifft "kbookmarks" und macht den Dateimanager Dolphin (egal ob als Qt4 oder Qt5 Version) derzeit nur begrenzt nutzbar (das ist natürlich auch abhängig von den eigenen Bedürfnissen, aber ich arbeite sehr viel mit den Bookmarks bzw. Orten in Dolphin). Hier mal der Bug-Report:
Habe gestern aus dem AUR LXQt 0.9.0 gezogen und wunderte mich wieso mein VLC komisch aussieht. siehe hier http://media.cdn.ubuntu-de.org/forum/attachments/19/06/7344388-VLC.png, wie kann ich das fixen?
Habe inzwischen Problem gelöst: laut einer Empfehlung aus #LXDE qtconfig-qt4 in der Konsole aufgerufen, auf GKT+ umgestellt, und schwups habe ich einen schöneren VLC!
LXQt ist KDE im ursprünglichen Sinne. Endlich gibt es wieder eine Desktop-Umgebung mit Qt.
Mit LXQt ist man auch kein Versuchstier in Sachen semantischer Desktop. Die Nutzer müssen hier auch keine Angst haben, dass der Versuchsaufbau nach Ende des Experiments abgebaut wird.
Wenn der Nutzer keine Angst hätte, müsste er nicht posten.
... ist das jetzt eine gute Nachricht oder nicht?
Ich versteh die meisten Aussagen im Text nicht, da ich die beiden Umgebungen, LxQT u. KDE nicht kenne, somit auch nicht die angesprochenen Komponenten.
Aber ist das wirklich schlau, sich an KDE ranzuhängen und sich von deren Ideen abhängig zu machen?
Und ist mit dem Einbau von KDE-Zeug nicht das Attribut "leichtgewichtig" bei LxQT in Gefahr?
Durch die Aufsplittung der Kdelibs in einzelne Bibliotheken/Frameworks sind die jeweils mitgebrachten Abhängigkeiten minimal und die Leichtgewichtigkeit nicht in Gefahr. Bei KDE Platform 4 war das alles monolithisch und so für andere Projekte kaum einsetzbar.
In der Softwareentwicklung ist es sehr üblich, Bibliotheken einzusetzen, die man nicht selbst entwickelt hat.
Das erlaubt einem, sich auf die eigentlichen Ziele zu konzentrieren, im Falle von LXQt eben auf das Entwickeln einer Desktopshell und verwandter Dienstprogramme.
Die hier eingesetzten Bibliotheken von KDE entstammen der selben Zielsetzung, sie sind für LXQt daher praktisch perfekte Bausteine.
Leider macht Software mit dutzend schicken Bibliotheken auch immer wieder wegen diesen Probleme, wenn man sie auf einer anderen Plattform als der Entwickler verwenden möchte. Dann wir wieder damit angefangen Dinge statisch dazu zupacken, aber das hat dann auch wieder Nachteile.
Das ist halt alles eine Frage der Wertigkeiten.
Man könnte alles ab dem Kernel Interface direkt in die Applikation packen, oder System Bibliotheken benutzen, oder Bibliotheken für graphische Benutzerschnittstellen, usw.
Aber nachdem es Möglichkeiten wie statisches und dynamisches Linken gibt, wird man sich meistens darauf konzentrieren, die Entwicklungsressourcen für die eigentlichen Zwecke der Applikation zu verwenden.
Es ist sehr oft eine Frage äußerer Parameter: ein System mit fixer Hardware/Softwarekombination kann die Benutzung derselben viel simpler und konkreter realisieren, wenn das System einer dynamischen Umwelt ausgesetzt wird, ist das Selbstentwickeln von Hardwareerkennung usw. schnell außerhalb der verfügbaren Mittel.
Der Artikel erwähnt KWindowSystem. Das ist eine Bibliothek die in KDE seit etwa 15 Jahren eingesetzt wird, Qt und X11 only ist. Sie ist sehr gut getestet und es hängt die ganze X11 Erfahrung drinnen von KWin und Plasma. Sie nicht einzusetzen bedeutet den Code selber zu schreiben mit großer Gefahr das falsch zu machen. Als offizieller Maintainer von KWindowSystem kann ich nur sagen: sehr venünftige Entscheidung darauf zu setzen.
Ach wir haben jetzt auch schon Kommentare gehört, dass Plasma 5.2 weniger RAM benötigt als die so genannten "leichtgewichtigen" DEs.
Warum behaupten eigentlich alle Seiten, dass es dazu Pakete in Archlinux gibt?
Es gibt in Arch gar keine LxQT-Pakete, lediglich im AUR Skripte dafür.
Und die sind noch auf dem Stand 0.8: https://aur.archlinux.org/packages/lxqt/
Lediglich die GIT-AUR-Skripte können 0.9 kompilieren...
Verstehe ich eigentlich eh' nicht, warum es keine Pakete dafür in Arch gibt, eigentlich ist das doch für Archer genau die richtige Desktop-Umgebung...
Pakete für Arch soll es demnächst geben. Also ist Dein Einwand berechtigt, ich hätte das differenzieren können.
Archer nutzen i3...die koennen arbeiten. Verschieben keine fensterlein mit desktopsymbolen und "startmenues"
PS: Auch besser fuer die zumeist rechte Schulter
Archer sind selbständig denkende Menschen, die sich aus der Vielfalt das aussuchen, was ihren Bedürfnissen entspricht. In meinem Fall ist das KDE/Plasma 5.
Archer sind selbständig denkende Menschen, die sich aus der Vielfalt das aussuchen, was ihren Bedürfnissen entspricht. In meinem Fall ist das KDE/Plasma 5.
Neben dem reinen Fenstermanager und einem Panel
- Systemeinstellungen
- Netzwerk Manager
- DBus
Die Systemeinstellungen könnte man auch 1 mal für alle DTE realisieren. -> YaST auch mit Funktionen für den user.
Bei DBus und Wayland kommen mir Bedenken.
Ich möchte gerne "ssh -X user@remote" machen können und remote Anwendungen auf meinem lokalen System bedienen können.
Aber:
- Wenn ich "ssh -X" mache wird remote kein DBus hochgefahren (z.B. auf einem Server). Das hat zur Folge, dass Anwendungen, die auf DBus setzen nicht nutzbar sind.
- Wenn x11 durch Wayland ersetzt wird, erwarte ich Probleme mit "ssh -X". Ich hoffe, dass wenigstens noch "xterm&" funktioniert, d.h. die Kompatibilität so weit geht.
... Bleibt einem nur noch Curses auf remote Rechnern.
Ich muss sagen, mich wundert immer, wie lange es dauert, bis ssh entsprechende Forwarding Möglichkeiten anbietet.
D-Bus wird jetzt sicher schon ein Jahrzehnt massiv benutzt, aber eingebautes Forwarding wie für X11 gibt es immer noch nicht.
Man muss sich dann mittels generischem Unix Socket Forwarding und manuellem (bzw. gescripteten) Setzen von Umgebungsvariablen auseinandersetzen.
Die Wayland Leute sagen ja immer, dass die Netzwerktransparenz jetzt auf die Toolkits ausgelagert wird.
Daher sollte man da wahrscheinlich bei GTK, KDE usw. anfragen.
Ich vermute mal das nächste was sie von KDE übernehmen werden wird der kwin sein, wenn dadurch nicht zu viele Abhängigkeiten eingeschleppt werden, um sich beim Wayland-Support eine Menge Arbeit ersparen zu können.
Oder gibt es bei Openbox irgendwelche Bestrebungen hinsichtlich Wayland?
Soweit ich weiß, kann KWin mit sehr wenigen Abhängigkeiten auskommen. Das hängt immer von der Distro ab.
Martin Gräßlin kann da aber sicher mehr dazu sagen. Bei RazorQt konnte man problemlos zwischen Openbox und KWin wechseln. Mit Kwin machte RazorQt dann richtig Laune.
Ich kann aus eigener Erfahrung sagen, dass sich KWin auch problemlos mit Xfce benutzen lässt (ich gebe zu, das ist nicht ganz naheliegend). Für LXQt bietet es sich natürlich um so mehr an...
Hm, das Verwenden eines Qt-Fenstermanagers in einem GTK-Environment scheint für manche ein Sakrileg zu sein, oder wie darf ich das negative Voting verstehen?
Ich vermute mal das die zwei Lager GTK+ und Qt stellenweise ähnlich übereinander Denken wie pro- und contra-systemd.
Oder noch schlimmer:
Wie vim- und emacs-user
Da gibt es schon einen feinen Unterschied: Man wird auch in Zukunft GTK+ ODER Qt ODER beides benutzen können. Bei Systemd haben manche ihre Zweifel, ob man da künftig die freie Wahl hat. Das Ziel der Systemd-Entwickler ist jedenfalls klar: Kein Linux OHNE Systemd und kein Kernel außer Linux MIT Systemd. Ich habe zum Beispiel kein Problem mit Systemd als Initsystem(!) und benutze es bereits, habe aber ein Problem mit dieser Zukunftsperspektive, da es ja ganz offensichtlich nicht bei dem Thema Initsystem bleibt.
Aber das ist jetzt arg off topic
Also ich verfolge das Projekt jetzt schon seit längerem interessiert und freue mich zu sehen wie es immer weiter reift. Etwas das sich zu KDE verhält wie XFCE zu Gnome habe ich mir schon lange gewünscht. Auch die Entwicklungsentscheidungen, die getroffen werden, finde ich top. Allein schon, dass razorQt und LXDE sich zusammen getan haben, aber auch, dass man jetzt da, wo es sinnvoll ist, auf kde frameworks setzt! So muss die Entwicklung freier Software laufen
Dann gäb's auch z.B. keine drei oder mehr verschiedene freie Videoschnittprogramme ...
(Aber damit ist imho am meisten gewonnen, da es eine gute Weiterentwicklung in einer Monokultur kaum gibt!)
Ich kann das alles unterschreiben, nur eine Frage: Was ist schlecht an drei oder mehr verschiedenen Videoschnittprogrammen? Ich bin froh, dass es mehrere gibt und der Meinung, dass es gar nicht genug geben kann. Ich alleine benutze schon regelmäßig, neben zahlreichen anderen Videotools, 4 verschiedene Videoschnittprogramme (KDEnlive, Kino, Avidemux, DVBCut) und jedes hat für bestimmte Tätigkeiten seine Vorzüge. Kein einziges dieser Programme möchte ich missen.
Habe zwar bisher LXQt noch nicht selbst getestet, aber das was ich über LXQt so lese und sehe, macht mich immer neugieriger! Aber leider gibt es LXQt derzeit unter Arch nur über das AUR. Hoffe, dass sich das vielleicht mal ändert.
Ich selber nutze seit Jahren KDE und habe meinen Arch Rechner erst am letzten Freitag KDE Plasma 4 auf Plasma 5 migriert. Es gibt natürlich noch viele Kleinigkeiten, die noch nicht so recht wollen oder wo es noch Bugs gibt, oder wo einfach der aktuelle Entwicklungsprozess noch nicht so weit fortgeschritten ist, aber dennoch muss ich bereits jetzt sagen, dass Plasma 5 selbst bereits relativ stabil und problemlos zu nutzen ist.
Ein Bug der aber wirklich nervt, betrifft "kbookmarks" und macht den Dateimanager Dolphin (egal ob als Qt4 oder Qt5 Version) derzeit nur begrenzt nutzbar (das ist natürlich auch abhängig von den eigenen Bedürfnissen, aber ich arbeite sehr viel mit den Bookmarks bzw. Orten in Dolphin). Hier mal der Bug-Report:
https://bugs.kde.org/show_bug.cgi?id=342685
Habe gestern aus dem AUR LXQt 0.9.0 gezogen und wunderte mich wieso mein VLC komisch aussieht. siehe hier http://media.cdn.ubuntu-de.org/forum/attachments/19/06/7344388-VLC.png, wie kann ich das fixen?
Ich glaube LXQt basiert auf Qt5 und VLC auf Qt4. Du brauchst Themes/Styles für alle Toolkits. Möglicherweise hilft das hier weiter:
https://wiki.archlinux.org/index.php/Uniform_Look_for_Qt_and_GTK_Applications
Habe inzwischen Problem gelöst: laut einer Empfehlung aus #LXDE qtconfig-qt4 in der Konsole aufgerufen, auf GKT+ umgestellt, und schwups habe ich einen schöneren VLC!