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

[Thomas Michalka]

Hi,

Am 09.07.2016 um 03:49 schrieb Kai Krakow:
> Am Sat, 9 Jul 2016 00:26:19 +0200
> schrieb Thomas Michalka <Thomas.Michalka at gmx.de>:
>
>> 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]
>>   [...]
>>
>> [...]
>
> Leider gibt es aber viele, die alles neue hassen - ist wohl so ein
> menschliches Grundprinzip. Wenn es nach denen ginge, hätten wir noch
> Windows 95 Optik überall...

Die Optik ist für mich nur wichtig, wenn sie Einfluss auf die Ergonomie 
hat. Ich entscheide so gut wie immer erst nach der funktionellen 
Bedienbarkeit, bzw. nach der Frage "Welches Feature bringt mir eine 
Verbesserung?".

> [...] MacOS ist davon nie abgewichen und hat eine
> Suchfunktion und ein Dock implementiert, Microsoft hat uns den
> schizophrenen Startknopf mit Verschachtel-Menü präsentiert - ohne Suche,

Ich finde den praktisch, weil ich mich in Kürze auch in neuen Menüs und 
mit den Verschachtelungen zurechtfinde -- mein Hirn tickt halt so. Daran 
sieht man, wie unterschiedlich die Menschen sind. Deswegewn ist es gut, 
wenn man Desktops möglichst vielseitig (Breite) und detailiert (Tiefe) 
konfigurieren kann.

> [...]
> Inzwischen muss man aber zugeben, dass eigentlich alle präsentierten
> Funktionen auch funktionieren. KDE hat da inzwischen einen sehr guten
> Stand erreicht und einen mehr als steinigen Weg hinter sich.

Ja gut, aber mein "Stilllegen-Knopf" ist halt, dass ich eine neue 
KDE-Hauptnummer erst benutze, wenn nicht mehr so viel unausgegoren ist. 
Bei KDE4 fand ich es schrecklich, dass ich erst ab v4.11 halbwegs 
zufrieden sein konnte.

>>> 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 bin nicht unbedingt ein Freund von mehreren Desktops. Ich finde die
> Idee zwar gut (auch die der Aktivitäten), aber irgendwo fehlt der
> Umsetzung noch der richtige Schliff,

Da muss ich Dir recht geben, denn ich vermisse immer noch ein 
ausgefeiltes Session-Management, mit dem ich auch einzelne Desktops 
wiederherstellen kann. Ich kann die Fenster auf einer Arbeitsfläche oft 
nicht schließen, weil ich weiß, dass ich sie in ein paar Tagen wieder 
brauche.
Außerdem müssten Programme wie Firefox und LibreOffice mit eigener 
Fensterwiederherstellung endlich mal besser in das SM integriert werden. 
Aber das hapert wohl auch an diesen Programmen.

> denn ich bemerke immer wieder, wie
> ich das sehr schnell nicht mehr nutze, wenn ich wirklich damit arbeite.

Also gut, das man sich auch mit einer Arbeitsfläche zufreiden geben kann :-)

> Da landen alle Fenster ganz schnell doch wieder auf dem gleichen,
> virtuellen Desktop - und die Aktivitäten sind leider etwas vergesslich
> und ordnen ihre Fenster auch nur widerwillig oder umständlich der
> Aktivität zu. Dabei mag ich bei letzteren, dass man auch
> Energie-Einstellungen etc zuordnen kann.

Praktisch vor allem für Notebooks in wechselnden Einsatzszenarien.

> Warum man Ordner und Dateien
> einer Aktivität zuordnen kann, ist mir allerdings noch schleierhaft.
> Hier fehlt es irgendwie an einem Konzept, wo man hin will, und dann an
> der Konsequenten Umsetzung dieser Dinge. Da ist m.E. viel Potential
> nach oben - virtuelle Desktops werden damit hinfällig.

Für mich nicht ganz hinfällig, aber ich glaube, wir sehen die Sache mit 
den Aktivitäten ähnlich. Auch ich meine, dass man das Aktivitäten-Design 
deutlich breiter anlegen und im Detail verfeinern kann. Allerdings 
müssten die Entwickler dazu wissen, was die Wünsche der Nutzer sind.
Aber als wesentliche Konzeptänderung und Voraussetzung wäre dazu der 
Wechsel eines Paradigmas nötig: weg von der Programmzentrierung und hin 
zur datenzentrierten Bedienung. Ansätze sieht man: Suche in Alt+F2 u.s.w.

Bevor man aber Anwendungsstarter mit den Programmen abschafft (sollte 
man vielleicht nie ganz, schließlich sind die Nutzer extrem verschieden 
gestrickt), muss man sich dazu mehr auf die Darstellung und den 
Austausch von Daten zwischen Benutzern und Systemen konzentrieren. Ich 
zum Beispiel vermisse sehr, dass man unterschiedlichste Datenformate 
nicht in Programmen wie z.B. Okular (auch hier gute Ansätze) gemeinsam 
und in vielfältigster Präsentation (in Dolphin zu wenige Ansichten) 
darstellen kann. Ich denke da z.B. an eine Darstellung der Dateien in 
voller Fenstergröße, die man nacheinander und inklusive Unterordnern wie 
in einem physischen Aktenordner durchbllättern kann. Natürlich müssen 
die Leistungsmerkmale, die digitale Ordner den physischen überlegen 
machen, implementiert sein. Wenn man das zur Reife gebracht hat, braucht 
es Programme, wie Okular und Dolphin vielleicht nicht mehr, weil das der 
Desktop an sich schon alles beherrscht.

>> 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.
>
> Man könnte das Subject anpassen... Aber mir fällt jetzt spontan keins
> ein.

Sorry, habe ich jetzt nachgeholt.

>> 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)
>
> Grundsätzlich eine nette Idee, aber es muss so umgesetzt sein, dass
> Einsteiger nicht aus Versehen diese Dinge modifizieren - denen ist
> häufig gar nicht bewusst, was sie da ändern.

ACK. Muss man selbstverständlich abschalten können, oder mit 
abschaltbaren Warnungen versehen.

> Wobei ich jetzt spontan
> nicht wüsste, warum man Dateirechte in-place editieren möchte... ;-)

Habe ich immer wieder, z.B. wenn ich einzelne Datei schnell einem 
anderen Benutzer zugänglich machen möchte. Klar: ein chmod in einem 
Terminal tuts auch (bin auch ein Freund der Kommandozeile), aber 
schneller ginge es, wenn ich bei einer Datei mal schnell die ACL ändern 
(hier nerven mich die modalen Dialoge), oder nur das Leserecht für "alle 
anderen" hinzufügen könnte. Cool wäre es, wenn ich in ein kleines Feld 
eine Zeit in Minuten eintragen könnte, bis die Änderung automatisch 
wieder zurückgenommen wird. Dann kann man das getrost vergessen.

> Ich lege mir da lieber Ordner an, die bestimmte Sharing-Eigenschaften
> haben und nutze dann Sticky-Bits.

Viele Wege führen nach Rom -- gut, dass es die Römer gab ;-)

>> P2) Need Not Know a File's Location (or any object's location)
>> --------------------------------------------------------------
>> [weiter oben im Thread nachzulesen]
>
> Ich glaube, der Ansatz ist verkehrt herum. Dateien sollten aus einem
> Dateimanager heraus geöffnet werden, nicht aus den Anwendungen heraus.

Das geht ja auch, aber was, wenn ich gerade ein bildschirmfüllendes 
LO-Fenster offen habe und eine weitere ODF-Datei laden will? Dann möchte 
ich nicht erst nach einem Dolphin o.a. DM suchen und dort erst einmal 
das Verzeichnis wechseln müssen. Außerdem muss ich dann als Benutzer den 
Ort wissen. Das will ich beim produktiven Arbeiten auch nicht mehr. 
Deswegen die Middleware. Dann könnte ich Dateien so benennen, wie es am 
besten z.B. zu einem Projekt passt. Und ich könnte sie, aus welchem 
Programm auch immer, mit diesem Namen, der _nicht_ die 
Dateinamenskonventionen des Dateisystems erfüllen muss, öffnen. Dateien 
könnten dann in verschiedenen Umfeldern (Projekte o.ä.) verschiedene 
Namen tragen. Klar geht das im Prinzip mit den symbolischen und den 
harten Links auch heute schon, aber das wird im Anwendungsbereich nur 
unbefriedigend abgebildet -- das wäre dann 'nur' noch zu tun, denn die 
grundlegenden Konzepte stellt Linux meistens schon zur Verfügung.

> Der Dateimanager kann dann auch nachverfolgen, was wohin verschoben
> wurde und merkt sich die Historie pro Anwendung.

Das wäre technisch unklug, weil ich dann als Anwender immer an diesen 
einen Dateimanager gebunden wäre. Auch deshalb die für den Anwender 
unsichtbare Middleware, die als Dämon im Hintergrund läuft. Übrigens 
gibt es auch hier -- schon wieder mal von Linux, wie könnte es anders 
sein (hier der Kernel) -- schon ein Konzept, nämlich den 
inotify-Mechanismus (bzw. heute fanotify, das aber auch mangelhaft ist, 
wenn es stimmt, dass es nicht über Löschungen und Umbenennungen von 
Dateien informiert, s. https://de.wikipedia.org/wiki/Fanotify). Damit 
müsste weder die Middleware noch eine Anwendung selber Änderungen auf 
Dateisystemebene überprüfen.

> Das Protokoll hier
> sollte nur sein, dass Anwendung und Dateimanager auf die gleiche
> Historie zugreifen - der Dateimanager kann die umschreiben beim
> Verschieben. Die gemeinsame Historie funktioniert ja größtenteils auch
> schon ganz gut - jedenfalls mit KDE-Programmen.

Das verstehe ich nicht, kannst du das mal an einem Beispiel erläutern?

> Außerdem sollte es heute nicht mehr so wichtig sein, wo man seine
> Dateien speichert - die Suche muss sie finden können und gut sein,
> Auflistung nach Kategorien muss möglich sein.

Genau das meine ich! Wir verstehen uns. Ob man das "Suche" nennt oder 
eine Middleware, die als Dämon läuft, ist egal. Ich will nur nicht 
jedesmal neu suchen müssen, wenn ich die Daten eines Projekts wieder 
laden muss. Deshalb muss das Motto lauten "Suchen, sammeln, anzeigen."

Ich will also eine gute _Suche_, die eine ausgefeilte Recherche 
ermöglicht, nicht nur auf dem Desktop, sondern transparent auch im LAN 
und im Internet.
Dann will ich eine hervorragende Möglichkeit der _Sammlung_ von 
Rechercheergebnissen mit Persistenz (gerade von Daten aus entfernten 
Quellen). Aus der Sammlung heraus will ich weiter suchen können. Der 
Sammlung will ich eigene Werke hinzufügen können. In der Sammlung möchte 
ich Metadaten, wie Bookmarks, zu den Dateien anlegen. Am besten wären 
die Metadaten selbst Bestandteil der Dateien, damit man sie gleichzeitig 
weitergeben kann.
Die _Anzeige_ soll auf verschiedenste Arten möglich sein, z.B. alle 
Dateien in Vollanzeige hintereinander (wie im klasischen, physischen 
Ordner), gerne auch in getrennten Fenstern auf einer oder mehreren 
Arbeitsflächen. Von mir aus können die Arbeitsflächen oder eine 
Aktivität über mehrere Arbeitsflächen der Container für ein Projekt sein.

Kurz:
Man muss die Anwendungsparadigmen auf Daten und Benutzer ausrichten.

> KDE/Dolphin können das
> recht gut, ist aber noch weit weg von perfekt. Die Aktivitäten scheinen
> auch so etwas wie eine Datei-Historie zu beherrschen, wie ich sie oben
> angesprochen habe.

ACK, aber alles ist er in kleinen Ansätzen gedacht.

> Ordner sind eigentlich nur für Archivierungszwecke interessant oder
> zum Entscheiden, was in der Cloud liegt (Sync-Ordner), was ich lokal in
> ein Backup speichere, was ich mit git verwalte, ... Eher in die
> Richtung. Inhalte aber sollte die Suche finden, nicht meine
> Ordnerstruktur.

Ich würde deshalb die Ordner in "Sammlung" umbenennen, denn die sollte 
eben nicht vordringlich an einer Ordnerstruktur orientiert sein, sondern 
an dem Zweck, zu dem sie angelegt wurde. Eigentlich ist aber egal, wie 
man das Ding nennt.

> Die Ordnerstruktur gäbe dann auch bestimmte Verhalten
> vor: Cloud-Ordner werden synchronisiert, Archiv-Ordner in der normalen
> Suche nicht berücksichtigt (außer ich suche explizit dort und mache ein
> Häkchen "archivierte Inhalte suchen") und so weiter, der Dateimanager
> könnte pro Ordner-Hierarchie auch andere Ansichten verwenden. Das geht
> zwar alles irgendwie schon, aber ist eher rudimentär umgesetzt oder
> umständlich zu verwenden.

Wir verstehen uns vollkommen :-)

> In einem Dateimanager sucht man ja dann doch
> eher visuell nach Dateien, indem z.B. Vorschaubilder erzeugt werden,
> oder eine Art Zeitstrahl-Ansicht, oder farbige Tags (sehe ich häufig
> bei MacOS-Usern).

So ist es!!!
Dass man sich Verzeichnishierarchien merken muss ist für die meisten 
Menschen eine ungute Belastung. Dass ich das einigermaßen kann, liegt an 
meiner Ausbildung, und vielleicht auch daran, dass mein Hirn so 
gestrickt ist. Ich kenne aber einige Menschen (keine Ingenieure oder 
Naturwissenschaftler), die das echt nicht können. Die fragen mich immer 
wieder, wo diese oder jene Datei denn sei, obwohl ich eine schöne, 
logische Verzeichnisstrukur angelegt habe. Diese Leute geben auch keine 
Web-Adresse manuell ein, sondern suchen mit Google und klicken dann. 
Denen möchte ich aber nicht sagen, sie müssten das eben lernen, weil es 
die Software-Entwickler nicht anders gemacht haben. Software und 
generell Technik soll man an die Menschen anpassen, nicht umgekehrt, 
obwohl der Mensch unglaublich anpassungsfähig ist.

>> 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.
>
> Ich denke, es soll in die Richtung ausgebaut werden im Zusammenspiel
> mit Aktivitäten.

Das klingt gut, ich meine, das sollte man wirklich machen.

Ich habe vor ein paar Monaten unter 
http://www.heise.de/ix/meldung/KDE-Community-Visionen-fuer-eine-bessere-Welt-3162923.html
gelesen, dass man in einem Wiki zu der auf die Vision folgenden Mission 
beitragen können soll. Leider erreicht man den angegebenen Link aktuell 
nicht. Vielleicht ist die Beitragsphase zur Mission auch schon 
abgeschlossen.

https://dot.kde.org/2016/04/05/kde-presents-its-vision-future
ist auch nicht mehr erreichbar.


Gruß, Tom