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

Sa Jul 9 01:49:58 UTC 2016

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]  
>  [...]  
> >>
> >> 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.

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...

> > 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?

Jein... Es ist ein totgelegtes Features, da die Menüleisten über DBUS
implementiert werden und das noch nicht stabil läuft mit Qt. Lässt sich
wohl zur Compile-Time aktivieren. Damit kann man die Menüleiste dann
entweder in einen Knopf in der Titelleiste verbannen oder als
Aufklappleiste an den Bildschirmrand. Das mit dem Knopf in der
Titelleiste fand ich recht unpraktisch, da wäre mir lieber, das ganze
Menü in der Titelleiste zu haben - der Fenster-/Dokumenttitel muss da
eh nicht wirklich sein - der darf zur Not weichen. Gnome ist da
deutlich weiter.

> > 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.

Ja, vermutlich waren die alten Ideen vielleicht nicht so schlecht, nur
damals falsch implementiert. Es fehlten Suchfunktionen und es war als
Fenster implementiert. 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,
und eine Quickstartleiste, kein Dock. Beides schlechte Umsetzungen einer
eventuell guten Idee.

> >> 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.

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.

> > 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, denn ich bemerke immer wieder, wie
ich das sehr schnell nicht mehr nutze, wenn ich wirklich damit arbeite.
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. 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.

> 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.

> 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. Wobei ich jetzt spontan
nicht wüsste, warum man Dateirechte in-place editieren möchte... ;-)

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

> 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 glaube, der Ansatz ist verkehrt herum. Dateien sollten aus einem
Dateimanager heraus geöffnet werden, nicht aus den Anwendungen heraus.
Der Dateimanager kann dann auch nachverfolgen, was wohin verschoben
wurde und merkt sich die Historie pro Anwendung. 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.

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. 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.

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. 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. 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).

> 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.

-- 
Regards,
Kai

Replies to list-only preferred.