Generisches Keep Display On

[SuperPCFan]

Ich schreibe eine Java Application bei der das Display sich nicht sperren soll (Bildschirmschoner, Energiesparmodus, usw.). Im Prinzip wie bei einem Mediaplayer wenn ein Video läuft. Aktuell teste ich die Anwendung auf einem Win10 System und auf einem RPi4 mit Linux. Es muss also Plattform-übergreifend funktionieren.

Ich habe natürlich schon nach Lösungen gegoogelt und war sehr verwundert das alle Lösungsvorschläge mehr oder weniger "Hacks" oder "Workarounds" sind. Mit so Vorschlägen wie "simuliere doch einen Klick alle 3 Minuten"....

Ich kann nicht glauben glauben, dass das der "intended Way" ist. Jede "popelige" Mediaplayer Software bekommt diese Funktion hin.
Gibt es in all den hochentwickelten Java Bibliotheken kein Plattform-unabhängiges Interface um egal welchem Betriebssystem zu sagen das der Bildschirm an bleiben soll?

 

[Oneixee5]

Da Java im Grunddesign Plattformunabhängig ist wirst du dich um dieses Problem selbst kümmern müssen. Versuche doch mal die Uhr deines PC mit Java zu ändern! Für solche Probleme steht das JNI zur Verfügung. Du kannst also für jede Plattform eine native plattformabhängige Bibliothek schreiben und diese dynamisch einbinden. Codebeispiele dafür gibt es ja genügend.

 

[SuperPCFan]

Die "Paths" Klasse übernimmt für mich die betriebssystemabhängige Verkettung von Ordnerpfaden.
"LookAndFeel" übernimmt für mich die betriebssystemabhängige Auswahl der Standard-Fensteroptik.

Ich verstehe trotz deiner Ausführung nicht, weshalb es nichts für die Bildschirmsperrung standardmäßig "out of the Box" gibt. (wie auch für das ändern der Uhr )

 

[Oneixee5]

Path ist aus dem Package java.nio - jemand hat dafür native plattformabhängige Bibliotheken geschrieben.

Swing-Komponenten werden direkt von Java gerendert und sind nicht von nativen Betriebssystemkomponenten abhängig. Dadurch funktionieren alle Swing-Komponenten auf allen Plattformen gleich, unabhängig davon, ob die entsprechende Plattform eine Komponente zur Verfügung stellt oder nicht. Der Nachteil ist, dass eine Swing-Anwendung nicht wie eine für das Betriebssystem entwickelte Anwendung aussieht. Das kann aber durch eine Auswahl an entsprechenden Pluggable Look-and-Feels kompensiert werden. Diese Eigenschaft wird mit dem englischen Wort Lightweight UI beschrieben (lightweight = all-Java language).

Es ist aber egal ob du das verstehen möchtest oder nicht es ist einfach so.

 

[SuperPCFan]

Ich möchte ziemlich viel verstehen. Zum Verstehen gehört es aber Fragen zu stellen.

Ich habe bei meiner Swing Anwendung gar nichts ausgewählt oder eingestellt. Sie sieht vorn herein aus als wenn sie für das jeweilige Betriebssystem entwickelt wurde. Was bedeutet, dass "jemand" so nett war Standardisierung zu betreiben.

Dass "Jemand" dafür eine Bibliothek geschrieben haben muss (wie auch für das native input output), hab ich verstanden.

Neben der eigentlichen Lösung für mein Problem würde ich gerne verstehen, warum die Abdeckung der Funktionalitäten derart inhomogen ist.
"Jemand" hat eine Bibliothek für die "typischen" Input/Output Anwendungen geschrieben. (java.nio)
"Jemand anderes" hat eine Bibliothek für die "typischen" Display Anwendungen geschrieben. (java.awt.GraphicsEnvironment)

Wieso ist das für andere "typische" Funktionsbereiche nicht der Fall?

Ich weiß nicht wie lange es Java schon gibt, aber die Bildschirmsperrung gibt es schon "ewig".
Ich halte die Annahme nicht für abwegig, dass für diese Funktion auch schon ein paar Codezeilen den Weg in eine native Standardbibliothek gefunden haben müssten.

Was mich dazu führt das diese Funktion eine spezielle Problemstellung beinhalten müsste.......Was natürlich interessant zu wissen wäre gerade wenn ich so eine Bibliothek selber schreiben will.

 

[Oneixee5]

Wieso ist das für andere "typische" Funktionsbereiche nicht der Fall?

"typische" Funktionsbereiche" für Java-Anwendungen dürfte Server-Software sein, Desktop-Software ist eher die Ausnahme. In grauen Vorzeiten gab es noch Applets, die liefen aber im Browser - also auch kein Bedarf.

 

[kneitzel]

Neben der eigentlichen Lösung für mein Problem würde ich gerne verstehen, warum die Abdeckung der Funktionalitäten derart inhomogen ist.

Das Thema ist doch sehr einfach: Es gab Entwickler und die haben sich überlegt: Was wird an Features benötigt. Das, was dann an Features sinnvoll schien wurde nach und nach umgesetzt (bzw. wird immer noch umgesetzt - es kommen ja regelmäßig neue Versionen raus).

Das Feature "Bildschirm soll nicht mehr sperren" ist etwas, das für die Entwickler bisher aber ganz offensichtlich so uninteressant war, dass sie dieses bisher nicht angegangen sind (und wohl auch nicht planen, es anzugehen).

Und das Du keine Library dafür gefunden hast, zeigt: Das Problem scheint so speziell zu sein, so dass es bisher niemanden wirklich interessiert hat. Sonst gäbe es wohl schon eine entsprechende Library.

Hinzu kommt, dass diese Funktionalität komplett aus der Java VM heraus geht. Java möchte halt in erster Linie innerhalb seiner VM spielen. Alles, was Native erfolgen muss, wird da eher abgelehnt, da es dem Konzept entgegen steht. Und natürlich ebenso: Du bist in einem Bereich, in dem Java kaum eine Rolle spielt. Der massive Teil der Java Entwicklung findet auf dem Server statt würde ich behaupten.

Und nur um die Komplexität zu verdeutlichen: Das ist eben nichts so triviales: Darf eine Applikation den Bildschirmschoner / die Sperre des Bildschirms deaktivieren? Das sehe ich aus Sicherheitsgründen als kritisch an! Und bei Linux ist die Frage: Gibt es da überhaupt einen einheitlichen Weg? Also wirst Du diverse Umgebungen unterstützen und manch eine andere Lösung wird Deine Lösung nicht funktionieren!

 

[SuperPCFan]

Vielen Dank für die Erläuterung.

Jeder Mediaplayer umgeht ja auch einfach so ohne den Bediener zu fragen die Sicherheitsaspekte der Bildschirmsperre.
Daher werde ich mir die Karten legen, wie ich dieses Feature am Besten implementieren kann.

 

[SuperPCFan]

Was mir gerade noch in den Sinn kommt...

Das Feature "Bildschirm soll nicht mehr sperren" ist etwas, das für die Entwickler bisher aber ganz offensichtlich so uninteressant...

Ich habe mal in Java eine App für Android entwickelt. Da hatte Java eine Bibliothek/Befehl für dieses Feature....also so ganz unbekannt kann den Java-Entwicklern das Thema nicht sein.

 

[kneitzel]

Was mir gerade noch in den Sinn kommt...

Ich habe mal in Java eine App für Android entwickelt. Da hatte Java eine Bibliothek/Befehl für dieses Feature....also so ganz unbekannt kann den Java-Entwicklern das Thema nicht sein.

Das sind zwei paar Schuhe. Nur weil Google auch die Sprache Java verwendet hat und viel von der API übernommen hat, ist es eben doch kein Java im Sinne des Java Frameworks.

 

[SuperPCFan]

Man darf doch noch träumen!

 

[kneitzel]

Man darf doch noch träumen!

Auf jeden Fall. Und Dein Ansatz ist ja auch vollkommen korrekt und ich rechne es Dir auch hoch an, dass Du nicht anfängst wild irgendwelche Hacks zu probieren sondern erst kritisch recherchierst und nachfragst, ob und wie denn der richtig Weg hier ist! Das ist genau das richtige Vorgehen!

Das es nicht immer zum Ziel führt und das man sich manchmal fragt, was da Verantwortliche zig Jahre gedacht und gemacht haben könnten, ist ein anderes Thema

Und ich würde mich auch sehr freuen, wenn ich mich irren würde ... denn auch ich weiss ja nicht alles.