[kde-de] (war: Sperrbildschirm nach einigen Minuten Inaktivität)

Fr Jul 8 22:26:19 UTC 2016

Am 07.07.2016 um 03:16 schrieb Kai Krakow:
> Am Thu, 7 Jul 2016 01:57:56 +0200
> schrieb Markus Grob <markus.grob at gmail.com>:
>
>> Kai Krakow schrieb:
>>
>> [viel wahres]
>>> machen. Der Support-Aufwand übersteigt hier schnell die Kosten, die
>>> eine Windows-Umgebung mit entsprechender Lizenzierung kostet
>>
>> Diese Erfahrung musste ich leider auch machen. Hier merkt man die
>> Man-Power von MS. Dort gibt es Personen, die beschäftigen sich damit,
>> wie man es einfacher macht. Natürlich geht da mal ein Schuss daneben
>> wie Win8, doch das wird dann mit Win10 korrigiert.
>
> Auch wenn mich Leute dafür hassen mögen: Ich mag die flache und
> reduzierte Optik von Win10.

Gut, dass man in unserer Gesellschaft mögen kann, was man will. 
Höchstens bescheuerte Islamisten, Salafisten und sonstige Intolerante, 
denen nichts passt, was sie nicht haarklein vorgeschrieben haben, werden 
sich ein so anstengendes Gefühl wie Hass abnötigen.

> Mein KDE sieht schon lange ähnlich aus. Am
> liebsten hätte ich auch noch die Menüleisten weg, die dürften wie bei
> OSX gern an den oberen Rand wandern

So viel ich weiß, gibt oder gab es das beim KDE3. Auch jetzt noch?

> und bei Bedarf ausklappen - nimmt
> nur Platz weg, und ich mag eh keine Aufklapp-Menüs. Deswegen mag ich
> auch das Win10-Startmenü und habe das KDE-Startmenü durch einen
> Fullscreen-Launcher ersetzt.

Damit bist Du wieder beim guten alten Programm-Manager von Win 3.1 (oder 
noch früher) in voller Bildschirmgröße angekommen. Wer's mag .. ist auch ok.

> Die Suche erfüllt bei beiden Systemen voll
> ihren Zweck und ich lege mir Favoriten. Poweruser heißt nicht, dass ich
> alle Millionen Systemfunktionen mit verschachtelten Klicks direkt
> erreichen muss. Ich will die wichtigsten mit einem oder wenigen Klicks
> erreichen, und sonst die Tastatur nutzen.

ACK.

>> Unter KDE gibt es leider wenige Fortschritte und viele Rückschritte.
>> Kaum jemand will skalier- und drehbare Desktop-Icons, man will
>> funktionsfähige Programme, die einfach laufen.
>> Das ist mühsam unter Linux.

Wie meinst Du das mit mühsam? Bei mir laufen alle Programme und mühsam 
ist für mich unter KDE nichts. Was mich nur nervt, sind nicht 
funktionierenden Features, offensichtlich vorher nicht getestet wurden. 
Man könnte einen Einstellung einbauen, wo der Benutzer selber nicht 
funktionierendes selber stillegen kann (mindestens bis zum nächsten 
Update), damit man sich nicht immer wieder damit herumärgern muss, wenn 
man an den Funktionsmangel nicht mehr denkt.

> Viele sehr gute Tools vermisst man
>> plötzlich, weil sich kein Programmierer darum kümmert, weil die
>> Portierung einfach zu mühsam ist.

ACK. Ich habe auch den Eindruck, dass man ständig den neuen Qt-Versionen 
hinterherläuft anstatt sich mal Gedanken über neue Konzepte oder 
Paradigmen zu machen, die gegenüber den anderen OSes einen echten 
Mehrwert bringen. Ich kann mich noch gut daran erinnern, wie glücklich 
ich war über KDE, das Win von Beginn an weit überlegen war. Dann die 
virtuellen Desktops, da brauchte ich unter Win eine eigene Software, die 
recht hakelig funktionierte.

Ich hoffe, das ist jetzt nicht zu OT, aber ich wüsste da zwei 
Paradigmen, die mir persönlich wichtig wären. Ich gebe auch jeweils 
Beispiele an.

P1) Edit Where You Get It (EWYGI):
---------------------------------
Man sollte alle Dinge bzw. Zustände oder Einstellungen von Objekten 
grundsätzlich da ändern können, wo man sie angezeigt bekommt.
Beispiele:
a) Änderung des Dateinamens, z.B. im Dolphin (gibt es schon)
b) Änderung von Dateirechten (gibt es nicht oder kenne ich nicht;
    hierzu will ich keinen extra Dialog)

P2) Need Not Know a File's Location (or any object's location)
--------------------------------------------------------------
Programme sollten den Pfad zu einer Datei oder den Ort eines beliebigen 
Datenobjekts nicht wissen müssen, sondern es sollte eine Middleware mit 
einer Datenbank (Akonadi geht irgendwie in die Richtung, ist aber nicht 
richtig zu Ende gedacht bzw. unterstützt zu wenige Dateiformate und 
keine Daten, die nicht in einem lokalen Dateisystem liegen) geben, die 
den Anwendungen entweder den aktuellen Pfad mitteilt oder selber auf die 
Datei oder das Objekt zugreift und es der Anwendung übergibt.

Konkretes Negativbeispiel: verschiebe ich eine ODF-Datei (auch 
umbenennen), dann kann z.B. LibreOffice sie nicht öffnen, wenn man sie 
erneut laden möchte, weil der Pfad zur _alten_ Location in LO noch 
gespeichert ist und LO nichts vom _neuen_ Pfad weiß.

Zu anderen Objekten, die nicht lokal vorliegen, sollte die Middleware 
den Anwendungen verhelfen, ohne, dass man die genauen Adressen wissen 
muss. Dazu muss sie natürlich die verschiedensten Protokolle können und 
mithilfe der Datenbank die Adressen in etwas Einprägsameres oder 
Einfacheres übersetzen. Den Normalanwender interessiert nämlich die 
genaue technische Lage (Protokoll, Servername, Pfad u.s.w.) des Objekts 
nicht. Wenn doch, dann könnte man das ja in den objekteigenschaften 
nachlesen. Was das Einprägsamere oder Einfachere ist, habe ich mir noch 
nicht überlegt. Vorschläge dazu?

Beispiele dazu:
a) eine entfernte Datei lese ich über webdav genauso ein, wie eine
    lokale Datei.
b) eine E-Mail lese ich mittels imap genauso ein, wie KMail das tut.
    Will ich antworten, kann das Verfassen-Fenster von KMail starten.
c) eine HTML-Seite lade ich über https. Tut kate das, zeigt es den
    HTML-Text an, tut ein Browser das, rendert er die Seite.

Alle Orte sollten in das lokale Dateisystem (in einem Verzeichnis 
gemeinsam oder selbst als Verzeichnis) transparent eingeblendet werden 
können, aber im Ggs. zu NFS (alle Dateien aus einem Baum unterhalb genau 
eines Verzeichnisses) aus völlig verschiedenen Quellen stammen und 
dynamisch um weitere Orte und Dateien ergänzt werden können.
Weil die Protokolle alle in der Middleware implementiert sind, bzw. von 
ihr genutzt werden, kann ich im Prinzip mit jedem Programm, jede Art von 
Daten anzeigen, vorausgesetzt das Programm ist dafür gemacht. Man könnte 
z.B. einen Dolphin haben, der Dateinamen in einem gemeinsamen 
Verzeichnis als virtuell lokal anzeigt, obwohl jede Datei woanders 
gespeichert ist. Man könnte daher auch einen Okular haben, der 
verschiedenste Datenformate anzeigt, egal ob die Datenobjekte echt oder 
virtuell (jede real woanders) in einem Verzeichnis liegen.
Man könnte auch Datenobjekte in ein (virtuelles, lokales) Verzeichnis 
ziehen, um so eine Recherche zu archivieren.. Das Archiv sollte 
selbständig eine lokale Kopie der Daten anlegen (gut, wenn man die 
entfernten Quellen mal nicht oder gar nicht mehr erreicht).

Ich weiß nicht, ob man Akonadi in die Richtung ausbauen könnte.
Ich finde aber, dass in KDE viele sehr gute Ansätze stecken, die nur 
nicht fertig ausentwickelt sind. Insofern braucht man nicht gleich neue 
Pradigmen (zur Abgrenzung gegen andere Systeme im Wettbewerb schon), 
sondern man könnte Vieles konsequenter ausentwickeln anstatt sich immer 
neuen Designs, experimentellen Features und der Portierung zu widmen. 
Das kostet zu viel der wertvollen Entwicklungsressourcen. Aber ich 
verstehe natürlich, dass immer wieder was Neues einfach mehr Spaß macht, 
geht mir ja auch so :-)  Aber dann bitte nicht an der Oberfläche 
bleiben, sondern in die Tiefe gehen mit der Entwicklung.

Gruß, Tom