Sobald FW5 und Plasma 2 Final verfügbar sind, wird es wohl noch viele nicht portierte KDE 4 Anwendungen geben. Sind also "alte" KDE 4 Anwendungen unter FW5 und Plasma 2 noch lauffähig oder müssen dann parallel dazu noch sätmliche KDE4 und Qt4 Libs installiert sein?
Angeblich ist der Portierungsaufwand für Qt4 Anwendungen auf Qt5 typischerweise gering. Ausnahmen gibt es aber natürlich (z.B. KWin war eine laut Martin Gräßlin). Ich könnte mir gut vorstellen, dass bei der Porierung der Anwendungen auf KF5 ein großer Teil darauf gehen wird das Buildsystem (CMake) anzupassen, so dass die einzelnen Bausteine gesucht und verwendet werden statt KDELibs o.ä. Aber fürs erste muss man natürlich KDE4 und Qt4 installieren, darauf wurde aber schon die Alpha angepasst, so dass man die parallel installieren kann.
Bei manchen Programmen kann es natürlich Probleme geben, wie z.B. hier beschrieben: http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
Aber solche Probleme werden halt (hoffentlich ;)) gefunden und behoben und zumindest bei Wayland ist das bei so einigen Programmen ja schon der Fall.
Angeblich ist der Portierungsaufwand für Qt4 Anwendungen auf Qt5 typischerweise gering.
Positives Beispiel: Konqueror hab ich am Freitag/Samstag in zusammen etwa einem Arbeitstag portiert. Das ist dann schon eine etwas größere und komplexe, historisch gewachsene Anwendenung. Und viele der Probleme auf die ich gestoßen bin, bin ich gerade dabei zu beheben, so dass andere Projekte weniger Arbeit in der Portierung haben.
Bei manchen Programmen kann es natürlich Probleme geben, wie z.B. hier beschrieben:
Der Blogpost bezog sich aber ausschließlich auf die Portierung nach Wayland, nicht auf frameworks.
Der Blogpost bezog sich aber ausschließlich auf die Portierung nach Wayland, nicht auf frameworks.
Das stimmt natürlich, allerdings verbinde ich – wie viele – mit KF5 eben auch die Portierung auf Wayland, sprich: Damit wird das Thema erst wirklich relevant, aus Sicht eines Users. Unter anderem ging es ja auch genau um dieses Thema, d.h. KDE4 Programme unter KF5/Plasma 2 und damit potentiell auch Wayland.
wirklich? Aus Sicht der Nutzer sollte doch Wayland ziemlich uninteressant sein. Das ist ein technisches Detail. Um es klar zu machen: ich will nicht, dass Nutzer merken ob sie unter X11 oder unter Wayland sind. Wenn sie es merken, haben wir die Umstellung verkackt.
Schon klar, so war das auch nicht gemeint. Aber ein Nutzer sieht eben, wenn – wie in dem Blogpost gezeigt – eine Anwendung crasht und das kann eben mit Wayland zusammenhängen. Wobei ja eben diese Probleme ja schon gefunden und bis dahin vermutlich fast komplett behoben sein werden.
Mir ging es nur darum, dass bei solch einem Wechsel eben auch Probleme auftreten können und das war eben nur ein Beispiel. Ich hoffe natürlich (wie du vermutlich auch), dass wir Nutzer den Wechsel nie bemerken werden.
Aus Sicht der Nutzer sollte doch Wayland ziemlich uninteressant sein.
Das verstehe ich nicht. Ich denke, dass gerade Wayland die Grundlage bilden soll, dem Nutzer ein gutes grafisches Erlebnis zu präsentieren. Bei X11 flackerts und flimmerts doch an allen Ecken und Kanten. Wieso sollte die Umstellung auf Wayland für den gemeinen Nutzer also uninteressant sein? Spätestens beim Wechseln zwischen Vollbildmodus und Desktop sollte man dann was merken.
Hier was von Phoronix: Facts about Wayland
V) Composition is mandatory under Wayland. That isn't to say that everything has to have 3D effects or wobbly windows. By composition we mean that everything is tear-free, flicker-free and flash-free. Wayland's motto is “Every frame is perfect.” Every pixel is exactly WHAT it should be, WHERE it should be, and be there WHEN its supposed to be there-- as dictated by the clients.
Sollte Wayland also richtig implementiert werden, müsste es der Nutzer doch merken. Somit wäre Deiner Aussage nach bereits bewiesen, dass ihr "Zitat:verkackt" habt. Richtig oder falsch?
Das stimmt aber nicht. Allein das Umschalten in einen Vollbildmodus ist grausam, beim Videoabspielen und zudem die Flackerei und das Umschalten während des Bootprozesses.
Eines der Designziele von Hogsberg bzgl. Wayland war:
"...that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker."
Sollte Wayland also richtig implementiert werden, müsste es der Nutzer doch merken.
Dem Nutzer fällt es auf wenn es flackert. Es fällt aber nicht auf wenn es nicht flackert. Oder schaust du ein Video und sagst danach: wow das hat jetzt aber gar nicht geflackert?
Dem Nutzer fällt es auf wenn es flackert. Es fällt aber nicht auf wenn es nicht flackert. Oder schaust du ein Video und sagst danach: wow das hat jetzt aber gar nicht geflackert?
Und genau das würde ich als KDE-User machen, denn momentan flackert es. Würde es also nicht mehr flackern, würde ich sagen: Wow, mit dem neuen KF5, Wayland und Plasma 2 ist es jetzt aber viel besser, denn es flackert ja nichts mehr und alles ist smooth. Ich glaube, wenn ein User von einem anderen System zu KDE wechseln würden, würde auch er bemerken, dass es ab und zu ruckelt, was es bei seinem alten System nicht tat. Ein Anwender weiss vielleicht nicht von der Existenz von Wayland (technisches Detail), aber er spürt die Auswirkungen.
Das ist genauso wie bei Android und IOS. Bei Android ruckelts immer noch beim Scrolling, fast egal bei welcher Hardware. Ich würde es merken, wenn es bei Samsungs Galaxy Modellen z.B. nicht mehr so wäre. Auch wenn ich nicht den Namen der Technik dahinter kenne, die für die Verbesserung verantwortlich ist.
Schön wär's Leider kann ich aus Erfahrung sagen, dass das kaum einem Nutzer auffällt. Entwicklern ja, da bekomme ich schon manchmal die Rückmeldung "habt ihr was geändert, fühlt sich schneller an", aber von Nutzern hört man das normalerweise nicht. Kannst mal schauen bei pro-linux Kommentaren wie selten man das sieht im Vergleich zu "funktioniert nicht".
Ja, das ich Dir gut nachempfinden und bedauere das auch. Auch das immer wieder alte Kamellen (4.0...) bei jeder News ausgegraben werden und die Leute nicht bemerken oder ignorieren, wenn sich was zum Positiven verändert. Aber es gibt sicher auch genug Leute, die sich freuen, obwohl sie nicht mit Lob um sich werfen. Ich zumindest freue mich schon sehr auf die kommende neue Plattform. Aber Stänkerer sollten auch nicht pauschal unbeachtet bleiben, denn so manche berechtigte Kritik müsste vielleicht auch aufgenommen werden. Nicht zu vergessen: Der Ton macht die Musik.
KDE Entwickler könnten nicht schwupps mal an einer anderen KDE App entwickeln.
Da du doch KWin Entwickler bist und nun Konqueror so schnell portieren kannst, dann könntest du ja auch gleich noch Ark erweitern, wie ich es hier vor ein paar Tagen angemerkt habe. Und wenn du schon dabei bist, dann sorge auch bitte dafür, dass Konqueror & Dolphin out of the Box auch gleich mit einer "Komprimieren nach 7z mit Passwort" Unterstützung im Kontextmenü defaultmäßig mit ausgeliefert wird, damit man sich hier nicht auf die Distributionen verlassen muss, die das oftmals vergessen. Zumal das auch zu redundanter Arbeit führen würde.
Da du doch KWin Entwickler bist und nun Konqueror so schnell portieren kannst, dann könntest du ja auch gleich noch Ark erweitern
Martin sprach im Zusammenhang von Konqueror über die Portierung auf Qt5 btw. KF5. Da er als Maintainer an der Portierung von KWin arbeitet, wollte er vielleicht testen, wie hoch der Aufwand bei anderen Applikationen ist. Konquerer zu portieren ist demnach einfacher als KWin, wo viele weitere tiefgreifende Dinge angepasst werden mussten. Natürlich hat er besseres zu tun, als alle Anwendungen für irgendwelche User nach deren Wünschen zu erweitern. Hau mich, wenn ich da falsch liege. Ich denke, mit Kwin macht er für uns alle schon einen sehr guten Job, wozu nur wenige Leute in der Lage wären. Ark können auch andere Leute anpassen. Das gilt nicht Dir persönlich, aber meiner Meinung nach sollte man sich etwas dankbarer für seine Arbeit zeigen, statt immer wieder zu meckern.
dass Konqueror & Dolphin out of the Box auch gleich mit einer "Komprimieren nach 7z mit Passwort" Unterstützung im Kontextmenü defaultmäßig mit ausgeliefert wird, damit man sich hier nicht auf die Distributionen verlassen muss
Für Dolpin kannst Du ohne Probleme ganz fix ein Konvolut an Zusatz-Kontextmenüs installieren, wo auch 7z bei ist, inkl. GUI für Passtwort etc... Es ist doch von Vorteil, dass Dolphin nicht total überladen ist. Benötigte Funktionen, wie z.B. 7z-Komprimierung, was eben nicht jeder braucht, lässt sich so einfach nachrüsten. Das wäre ein guter Workaround für die fehlende Funktionalität in Ark und ich finde, es ist nicht Sache der Distributoren, Dolphin defaultmäßig aufzublasen. Das kannst Du als User selbst machen, auch wenn wir hier nur von Kontextmenüs sprechen.
Konquerer zu portieren ist demnach einfacher als KWin, wo viele weitere tiefgreifende Dinge angepasst werden mussten. Natürlich hat er besseres zu tun, als alle Anwendungen für irgendwelche User nach deren Wünschen zu erweitern. Hau mich, wenn ich da falsch liege. Ich denke, mit Kwin macht er für uns alle schon einen sehr guten Job, wozu nur wenige Leute in der Lage wären. Ark können auch andere Leute anpassen.
Ja, das ist mir schon klar, ich habe nicht ernsthaft erwartet dass er sich jetzt an Ark dransetzt. Mir ging es nur um unsere letzte Diskussion und das im Zusammenhang mit dem schwupps mal Konqueror portieren, da konnte ich natürlich nicht widerstehen. ;) Mit seiner Arbeit an KWin bin ich sehr zufrieden.
Für Dolpin kannst Du ohne Probleme ganz fix ein Konvolut an Zusatz-Kontextmenüs installieren, wo auch 7z bei ist, inkl. GUI für Passtwort etc...
Schon, es wäre dennoch schön wenn sich die KDE Entwickler darum kümmern würden, denn die Distributionen tun leider nicht immer eine Lösung mitliefern. OpenSuse macht das ganze zwar passabel, aber es ist trotzdem redunante Arbeit wenn das jede Distri für sich alleine machen soll und manche es einfach vergessen und man das genauso gut auch gleich von KDE aus mitliefern könnte.
Das wäre ein guter Workaround für die fehlende Funktionalität in Ark und ich finde, es ist nicht Sache der Distributoren, Dolphin defaultmäßig aufzublasen. Das kannst Du als User selbst machen,
Ich vielleicht, mein Onkel und mein Opa ganz sicherlich nicht. Es gibt kein Paket in Kubuntu, dass diese Funktionalität einfach mal so zur Verfügung stellt, man müsste also dieses Erweiterungskript selber schreiben oder von irgendwo downloaden und das kann weder mein Opa noch mein Onkel. Es sollte bei Dolphin defaultmäßig im Paket welches Dolphin enthält, mitgeliefert werden, es sind nur ein paar KByte und bläst Dolphin in keinster Weise auf.
Einfach mal versuchen das rpm in ein deb Paket zu konvertieren. Auf meiner openSUSE kiste musste ich dazu die beiden Pakete alien und debhelper installieren.
Folgendes Shell-Kommando führt die Konvertierung durch:
Nun hast Du ein deb Paket was Du unter Kubuntu installieren kannst. Und Du als Enkel-Admin könntest das doch für Deinen Opa mal kurz in die Shell hacken. Ist zwar nicht unbedingt das, was Du Dir wünscht, aber als Workaround kannst Du es so zumindest installieren. Schreib doch mal, ob es geklappt hat, falls Du es versuchen möchtest.
Da du doch KWin Entwickler bist und nun Konqueror so schnell portieren kannst,
Nun portieren ist nicht entwickeln. Portieren ist das mir bereits bekannte Schema einsetzen und die Anwendung zum Kompilieren zu bringen. Und ja ich bin da auf domainspezifische Probleme gestoßen, die ich nicht beheben kann, weil mir das Wissen fehlt.
- KDE 4 Programme laufen nicht automatisch mit den Framework 5 Bibliotheken, da ist etwas Portierungsaufwand notwendig. Das kann sich allerdings auf wenige Stunden beschränken, da sich die APIs, wenn überhaupt, nur geringfügig geändert haben. Es gibt auch ein Portability-Layer, KDE4Support genannt, was den Aufwand weiter verringert (obwohl man irgendwann auch von KDE4Support wegportieren sollte), so geht's in recht kleinen Schritten, was auch heisst, dass man Patches relativ leicht von einer KDE4-basierten Branch auf eine Frameworks5-Branch forward-portieren kann.
- KDE4 Programma laufen problemlos auf einem Plasma2 Desktop. Desktop und Anwendungen kann man mischen, wie man mag, und oft auch beide Versionen installieren, und hin und herschalten, wenn man merkt, dass die neue Version doch noch nicht alles kann, was man erwartet.
So sollte sich ein Migrationsprozess relativ schmerzfrei gestalten lassen.
Aber auch nur so lange die Distributoren nicht denselben Bockmist bauen, wie beim KDE4 Release. Soweit ich mich erinnere ist nur Debian damals nicht auf den KDE4 Zug aufgesprungen und hat Lenny noch mit 3.5 ausgeliefert.
Für KDE 4 wurde versprochen, dass mit dieser Serie Programme plattformunabhängig werden. Gehalten wurde das nicht. Heute sind relativ viele Programme mit QT unter MAC und WIN verfügbar, außer alles das was unter KDE 4 läuft, das ist nur experimentell portiert. Jetzt gibt es also die KDE 5 Serie und wieder wird was von Portierbarkeit gefaselt, ich glaube da gar nichts mehr.
Deshalb liebe ich reine Qt-Programme ohne diesen ganzen überflüssigen KDE-Bloat. Razor und LXDE Qt machen es vor, wie Qt basierter Desktop wirklich aussehen muss.
Da gibt es keinen wesentlichen Unterschied, auch Razor bzw. LXQt haben eigene Bibliotheken.
Qt ist zwar ein ziemlich umfangreiches Application Framework, deckt aber nicht alles ab, was eine Desktopumgebung oder spezialisertere Programme brauchen.
Rein logisch gibt es für mich auch einfach einen klaren Widerspruch zwischen einer umfassenden, wirklich gut integrierten Desktopumgebung + Programme, wie KDE SC es ist und problemlos portierbaren Programmen.
Ich behaupte mal die meisten KDE Anwender schätzen ersteres an ihrer Desktopumgebung, ansonsten würden ja alle razor-qt etc. verwenden.
Der Grund warum nicht noch mehr razor qt verwenden, könnte auch einfach daran liegen, dass es noch nicht fertig ist, weil es leider nicht so viele Entwickler hat.
Viele Entwickler wollen wohl auch lieber ihren Egotrip ausleben, statt was Brauchbares für den Nutzer zu entwickeln. Und ein paar Anwender lassen sich auch mit billigen Eyecandy und sinnlosen Spielereien blenden.
Viele Entwickler wollen wohl auch lieber ihren Egotrip ausleben, statt was Brauchbares für den Nutzer zu entwickeln. Und ein paar Anwender lassen sich auch mit billigen Eyecandy und sinnlosen Spielereien blenden.
Viele Benutzer verlangen einfach nach super Software, ohne selber zu entwickeln, ordentliche Fehlermeldungen einzustellen oder sonst etwas zurückzugeben.
Ja und? Das müssen die Entwickler vorher wissen. Niemand zwingt sie schließlich irgendwelche freie Software zu entwickeln. Das beste was sie zu erwarten haben ist Lob und Anerkennung, wenn es funktioniert oder Verträge mit irgendwelchen Firmen, wo man durchaus auch Geld verdienen kann.
Außerdem sind die meisten Anwender eben überfordert mit den Fehlermeldungen, da würde ein automatisches Tool was bringen, geschweige denn selber was zu programmieren. Was erwarten die Entwickler da? Das sich die Anwender neben Job und Familie noch weiterbilden, nur um was zu Recht zu biegen, was selbst die Entwickler nicht besser hinkriegen?
Nicht notwendigerweise. Im Grunde hängt es davon ab, an welcher Stelle die Integration erfolgt.
Zum Beispiel kann eine Applikation auf unterschiedliche Plattformen mit unterschiedlichen Optionen gebaut werden oder es werden unterschiedliche Plugins geladen.
Im Falle von KDE Anwendungen ist selbst die erste Möglichkeit oft nicht direkt in den Applikationen sondern in den verwendeten Bibliotheken, also quasi ähnlich den Plugins "unsichtbar" für Anwendungsentwickler und Benutzer.
Die Anwendungen sind damit portiertbar und integriert, wobei der Integrationsgrad je nach Plattform schwanken kann. Die Integration auf einen FOSS System wird vermutlich immer am besten sein.
Für KDE 4 wurde versprochen, dass mit dieser Serie Programme plattformunabhängig werden.
Die meiste Applikationen sind das auch, siehe zum Beispiel KDE on Windows:
"Users can test this release by using the KDEWin Installer to try out all the software available. Included in this release are kdebase (both the applications and the workspace), kdeedu, kdegames, kdegraphics, kdemultimedia, kdenetwork, kdesdk, kdetoys, kdeutils, and several stuff from extragear like amarok, konversation, kile and quassel."
Manchmal kommen allerdings Technologien oder APIs zum Einsatz, die nicht auf allen Plattformen verfügbar sind. Konsole, zum Beispiel, benötigt eine Plattform mit Pseudoterminals (soweit ich weiß), kann daher nur auf unixartigen System gebaut werden (also nicht unter Windows).
Ist es nicht hauptsächlich deswegen "experimentell", weil es weniger entwickelt und genutzt wird?
Ich nutze diverse Programme auch unter Windows (z.B. Kile) und es funktioniert soweit problemlos. Insofern verstehe ich die Kritik nicht wirklich. Das was gemacht werden konnte wurde im Prinzip auch gemacht.
Sobald FW5 und Plasma 2 Final verfügbar sind, wird es wohl noch viele nicht portierte KDE 4 Anwendungen geben. Sind also "alte" KDE 4 Anwendungen unter FW5 und Plasma 2 noch lauffähig oder müssen dann parallel dazu noch sätmliche KDE4 und Qt4 Libs installiert sein?
Angeblich ist der Portierungsaufwand für Qt4 Anwendungen auf Qt5 typischerweise gering. Ausnahmen gibt es aber natürlich (z.B. KWin war eine laut Martin Gräßlin). Ich könnte mir gut vorstellen, dass bei der Porierung der Anwendungen auf KF5 ein großer Teil darauf gehen wird das Buildsystem (CMake) anzupassen, so dass die einzelnen Bausteine gesucht und verwendet werden statt KDELibs o.ä.
Aber fürs erste muss man natürlich KDE4 und Qt4 installieren, darauf wurde aber schon die Alpha angepasst, so dass man die parallel installieren kann.
Bei manchen Programmen kann es natürlich Probleme geben, wie z.B. hier beschrieben:
http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
Aber solche Probleme werden halt (hoffentlich ;)) gefunden und behoben und zumindest bei Wayland ist das bei so einigen Programmen ja schon der Fall.
Positives Beispiel: Konqueror hab ich am Freitag/Samstag in zusammen etwa einem Arbeitstag portiert. Das ist dann schon eine etwas größere und komplexe, historisch gewachsene Anwendenung. Und viele der Probleme auf die ich gestoßen bin, bin ich gerade dabei zu beheben, so dass andere Projekte weniger Arbeit in der Portierung haben.
Der Blogpost bezog sich aber ausschließlich auf die Portierung nach Wayland, nicht auf frameworks.Unter anderem ging es ja auch genau um dieses Thema, d.h. KDE4 Programme unter KF5/Plasma 2 und damit potentiell auch Wayland.
wirklich? Aus Sicht der Nutzer sollte doch Wayland ziemlich uninteressant sein. Das ist ein technisches Detail. Um es klar zu machen: ich will nicht, dass Nutzer merken ob sie unter X11 oder unter Wayland sind. Wenn sie es merken, haben wir die Umstellung verkackt.
Schon klar, so war das auch nicht gemeint. Aber ein Nutzer sieht eben, wenn – wie in dem Blogpost gezeigt – eine Anwendung crasht und das kann eben mit Wayland zusammenhängen.
Wobei ja eben diese Probleme ja schon gefunden und bis dahin vermutlich fast komplett behoben sein werden.
Mir ging es nur darum, dass bei solch einem Wechsel eben auch Probleme auftreten können und das war eben nur ein Beispiel. Ich hoffe natürlich (wie du vermutlich auch), dass wir Nutzer den Wechsel nie bemerken werden.
Hier was von Phoronix: Facts about Wayland
Quelle: http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=2Sollte Wayland also richtig implementiert werden, müsste es der Nutzer doch merken. Somit wäre Deiner Aussage nach bereits bewiesen, dass ihr "Zitat:verkackt" habt. Richtig oder falsch?
Naja, realistisch betrachtet kommt "Flickern" o.ä. beim heutigen X11 nicht gerade häufig vor, daher sollte der User davon nicht viel bemerken.
Das stimmt aber nicht. Allein das Umschalten in einen Vollbildmodus ist grausam, beim Videoabspielen und zudem die Flackerei und das Umschalten während des Bootprozesses.
Eines der Designziele von Hogsberg bzgl. Wayland war:
"...that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker."
Dem Nutzer fällt es auf wenn es flackert. Es fällt aber nicht auf wenn es nicht flackert. Oder schaust du ein Video und sagst danach: wow das hat jetzt aber gar nicht geflackert?
Ich glaube, wenn ein User von einem anderen System zu KDE wechseln würden, würde auch er bemerken, dass es ab und zu ruckelt, was es bei seinem alten System nicht tat. Ein Anwender weiss vielleicht nicht von der Existenz von Wayland (technisches Detail), aber er spürt die Auswirkungen.
Das ist genauso wie bei Android und IOS. Bei Android ruckelts immer noch beim Scrolling, fast egal bei welcher Hardware. Ich würde es merken, wenn es bei Samsungs Galaxy Modellen z.B. nicht mehr so wäre. Auch wenn ich nicht den Namen der Technik dahinter kenne, die für die Verbesserung verantwortlich ist.
Schön wär's
Leider kann ich aus Erfahrung sagen, dass das kaum einem Nutzer auffällt. Entwicklern ja, da bekomme ich schon manchmal die Rückmeldung "habt ihr was geändert, fühlt sich schneller an", aber von Nutzern hört man das normalerweise nicht. Kannst mal schauen bei pro-linux Kommentaren wie selten man das sieht im Vergleich zu "funktioniert nicht".
Ja, das ich Dir gut nachempfinden und bedauere das auch. Auch das immer wieder alte Kamellen (4.0...) bei jeder News ausgegraben werden und die Leute nicht bemerken oder ignorieren, wenn sich was zum Positiven verändert. Aber es gibt sicher auch genug Leute, die sich freuen, obwohl sie nicht mit Lob um sich werfen. Ich zumindest freue mich schon sehr auf die kommende neue Plattform. Aber Stänkerer sollten auch nicht pauschal unbeachtet bleiben, denn so manche berechtigte Kritik müsste vielleicht auch aufgenommen werden. Nicht zu vergessen: Der Ton macht die Musik.
Komisch, neulich hieß es hier noch ganz groß:
KDE Entwickler könnten nicht schwupps mal an einer anderen KDE App entwickeln.
Da du doch KWin Entwickler bist und nun Konqueror so schnell portieren kannst,
dann könntest du ja auch gleich noch Ark erweitern, wie ich es hier vor ein paar Tagen angemerkt habe.
Und wenn du schon dabei bist, dann sorge auch bitte dafür, dass Konqueror & Dolphin out of the Box auch gleich mit einer "Komprimieren nach 7z mit Passwort" Unterstützung im Kontextmenü defaultmäßig mit ausgeliefert wird, damit man sich hier nicht auf die Distributionen verlassen muss, die das oftmals vergessen. Zumal das auch zu redundanter Arbeit führen würde.
Ja, das ist mir schon klar, ich habe nicht ernsthaft erwartet dass er sich jetzt an Ark dransetzt. Mir ging es nur um unsere letzte Diskussion und das im Zusammenhang mit dem schwupps mal Konqueror portieren, da konnte ich natürlich nicht widerstehen. ;)
Schon, es wäre dennoch schön wenn sich die KDE Entwickler darum kümmern würden, denn die Distributionen tun leider nicht immer eine Lösung mitliefern. OpenSuse macht das ganze zwar passabel, aber es ist trotzdem redunante Arbeit wenn das jede Distri für sich alleine machen soll und manche es einfach vergessen und man das genauso gut auch gleich von KDE aus mitliefern könnte.Ich vielleicht, mein Onkel und mein Opa ganz sicherlich nicht. Es gibt kein Paket in Kubuntu, dass diese Funktionalität einfach mal so zur Verfügung stellt, man müsste also dieses Erweiterungskript selber schreiben oder von irgendwo downloaden und das kann weder mein Opa noch mein Onkel.Mit seiner Arbeit an KWin bin ich sehr zufrieden.
Es sollte bei Dolphin defaultmäßig im Paket welches Dolphin enthält, mitgeliefert werden, es sind nur ein paar KByte und bläst Dolphin in keinster Weise auf.
Hätte da vielleicht noch eine Idee für Dich und Dein Kubuntu:
Das kde-service Menü für Dolphin kannst Du hier z.B. als Fedora-RPM ziehen:
Einfach mal versuchen das rpm in ein deb Paket zu konvertieren. Auf meiner openSUSE kiste musste ich dazu die beiden Pakete alien und debhelper installieren.
Folgendes Shell-Kommando führt die Konvertierung durch:
Nun hast Du ein deb Paket was Du unter Kubuntu installieren kannst. Und Du als Enkel-Admin könntest das doch für Deinen Opa mal kurz in die Shell hacken. Ist zwar nicht unbedingt das, was Du Dir wünscht, aber als Workaround kannst Du es so zumindest installieren. Schreib doch mal, ob es geklappt hat, falls Du es versuchen möchtest.
Danke für den Hinweis.
Ich werde es mir mal ansehen, aber momentan komme ich nicht dazu,
Nun portieren ist nicht entwickeln. Portieren ist das mir bereits bekannte Schema einsetzen und die Anwendung zum Kompilieren zu bringen. Und ja ich bin da auf domainspezifische Probleme gestoßen, die ich nicht beheben kann, weil mir das Wissen fehlt.
Dazu gibt's eigentlich 2 Antworten:
- KDE 4 Programme laufen nicht automatisch mit den Framework 5 Bibliotheken, da ist etwas Portierungsaufwand notwendig. Das kann sich allerdings auf wenige Stunden beschränken, da sich die APIs, wenn überhaupt, nur geringfügig geändert haben. Es gibt auch ein Portability-Layer, KDE4Support genannt, was den Aufwand weiter verringert (obwohl man irgendwann auch von KDE4Support wegportieren sollte), so geht's in recht kleinen Schritten, was auch heisst, dass man Patches relativ leicht von einer KDE4-basierten Branch auf eine Frameworks5-Branch forward-portieren kann.
- KDE4 Programma laufen problemlos auf einem Plasma2 Desktop. Desktop und Anwendungen kann man mischen, wie man mag, und oft auch beide Versionen installieren, und hin und herschalten, wenn man merkt, dass die neue Version doch noch nicht alles kann, was man erwartet.
So sollte sich ein Migrationsprozess relativ schmerzfrei gestalten lassen.
Aber auch nur so lange die Distributoren nicht denselben Bockmist bauen, wie beim KDE4 Release. Soweit ich mich erinnere ist nur Debian damals nicht auf den KDE4 Zug aufgesprungen und hat Lenny noch mit 3.5 ausgeliefert.
Für KDE 4 wurde versprochen, dass mit dieser Serie Programme plattformunabhängig werden. Gehalten wurde das nicht. Heute sind relativ viele Programme mit QT unter MAC und WIN verfügbar, außer alles das was unter KDE 4 läuft, das ist nur experimentell portiert. Jetzt gibt es also die KDE 5 Serie und wieder wird was von Portierbarkeit gefaselt, ich glaube da gar nichts mehr.
Deshalb liebe ich reine Qt-Programme ohne diesen ganzen überflüssigen KDE-Bloat. Razor und LXDE Qt machen es vor, wie Qt basierter Desktop wirklich aussehen muss.
Da gibt es keinen wesentlichen Unterschied, auch Razor bzw. LXQt haben eigene Bibliotheken.
Qt ist zwar ein ziemlich umfangreiches Application Framework, deckt aber nicht alles ab, was eine Desktopumgebung oder spezialisertere Programme brauchen.
Rein logisch gibt es für mich auch einfach einen klaren Widerspruch zwischen einer umfassenden, wirklich gut integrierten Desktopumgebung + Programme, wie KDE SC es ist und problemlos portierbaren Programmen.
Ich behaupte mal die meisten KDE Anwender schätzen ersteres an ihrer Desktopumgebung, ansonsten würden ja alle razor-qt etc. verwenden.
Der Grund warum nicht noch mehr razor qt verwenden, könnte auch einfach daran liegen, dass es noch nicht fertig ist, weil es leider nicht so viele Entwickler hat.
Viele Entwickler wollen wohl auch lieber ihren Egotrip ausleben, statt was Brauchbares für den Nutzer zu entwickeln. Und ein paar Anwender lassen sich auch mit billigen Eyecandy und sinnlosen Spielereien blenden.
Viele Benutzer verlangen einfach nach super Software, ohne selber zu entwickeln, ordentliche Fehlermeldungen einzustellen oder sonst etwas zurückzugeben.
++
Es fehlt noch "umsonst". Schließlich soll die super Software ja auch nichts Kosten.
Ja und? Das müssen die Entwickler vorher wissen. Niemand zwingt sie schließlich irgendwelche freie Software zu entwickeln. Das beste was sie zu erwarten haben ist Lob und Anerkennung, wenn es funktioniert oder Verträge mit irgendwelchen Firmen, wo man durchaus auch Geld verdienen kann.
Außerdem sind die meisten Anwender eben überfordert mit den Fehlermeldungen, da würde ein automatisches Tool was bringen, geschweige denn selber was zu programmieren. Was erwarten die Entwickler da? Das sich die Anwender neben Job und Familie noch weiterbilden, nur um was zu Recht zu biegen, was selbst die Entwickler nicht besser hinkriegen?
Nicht notwendigerweise.
Im Grunde hängt es davon ab, an welcher Stelle die Integration erfolgt.
Zum Beispiel kann eine Applikation auf unterschiedliche Plattformen mit unterschiedlichen Optionen gebaut werden oder es werden unterschiedliche Plugins geladen.
Im Falle von KDE Anwendungen ist selbst die erste Möglichkeit oft nicht direkt in den Applikationen sondern in den verwendeten Bibliotheken, also quasi ähnlich den Plugins "unsichtbar" für Anwendungsentwickler und Benutzer.
Die Anwendungen sind damit portiertbar und integriert, wobei der Integrationsgrad je nach Plattform schwanken kann.
Die Integration auf einen FOSS System wird vermutlich immer am besten sein.
Die meiste Applikationen sind das auch, siehe zum Beispiel KDE on Windows:
"Users can test this release by using the KDEWin Installer to try out all the software available. Included in this release are kdebase (both the applications and the workspace), kdeedu, kdegames, kdegraphics, kdemultimedia, kdenetwork, kdesdk, kdetoys, kdeutils, and several stuff from extragear like amarok, konversation, kile and quassel."
Manchmal kommen allerdings Technologien oder APIs zum Einsatz, die nicht auf allen Plattformen verfügbar sind. Konsole, zum Beispiel, benötigt eine Plattform mit Pseudoterminals (soweit ich weiß), kann daher nur auf unixartigen System gebaut werden (also nicht unter Windows).
Ist es nicht hauptsächlich deswegen "experimentell", weil es weniger entwickelt und genutzt wird?
Ich nutze diverse Programme auch unter Windows (z.B. Kile) und es funktioniert soweit problemlos. Insofern verstehe ich die Kritik nicht wirklich.
Das was gemacht werden konnte wurde im Prinzip auch gemacht.