"Schöne Maus"-App in OpenSource und speziell FreeBSD?

pit234a

Well-Known Member
Nachdem ich einige Zeit täglich viel unter einem Win10 arbeite, habe ich die einfachen und vielfältigen Möglichkeiten schätzen gelernt, womit hier mittels GUI Anpassungen für Verhalten und Aussehen der Maus bzw des Mauscursors gemacht werden können.
Dem will ich gar nicht erst nacheifern, aber die Möglichkeiten, die ich kenne, lxinput, lxappeareance und "manuelles friemeln" sind jedoch vergleichsweise unbefriedigend und nachdem ich nichts besseres gefunden habe, frage ich mich natürlich, ob es nichts gibt oder ich nur zu blind war.

Ähm, vielleicht noch ergänzend: unter Win10 habe ich auch kaum Tastenkombinationen im Einsatz und benutze die Maus viel intensiver, als ich das auf meinem Desktop tue. Vielleicht braucht deshalb die Freie Welt keine besseren GUIs für diese Einstellungen?
 

Andy_m4

Well-Known Member
habe ich die einfachen und vielfältigen Möglichkeiten schätzen gelernt, womit hier mittels GUI Anpassungen für Verhalten und Aussehen der Maus bzw des Mauscursors gemacht werden können.
Du solltest beschreiben, was für Möglichkeiten Du genau meinst. Sonst wirds tendenziell schwer dazu etwas zu sagen.
Unter "Aussehen" der Maus kann ich mir ja noch was vorstellen. Beim "Verhalten" wirds schwieriger. Da kann ich mir ne Menge vorstellen aber es ist nicht klar, was Du meinst.
 

pit234a

Well-Known Member
Beim "Verhalten" wirds schwieriger.
zugegeben.

Wir haben ja alle nur noch USB und optische Mäuse, aber die haben unterschiedliche "Auflösung" und das trifft auf unterschiedliche Auflösung in X.
Die "Auflösung" der Maus ist nicht identisch zu einer Auflösung und Größe der Bildschirme.
Mäuse senden da unintelligent irgendwie Impulse und die sind relativ zur Bewegung der Maus und HW-mäßig fest. Diese Impulse müssen nun in eine Bewegung des Mauscursors/pointers auf dem Bildschirm umgesetzt werden und dann spricht man meist von "Beschleunigung" und "Empfindlichkeit".
Diese ist aber in X festgeschrieben und kann hierüber manipuliert werden, so weit ich das verstehe.
Ebenso die Tasten, wie viele, welche wo mit welcher Funktion und ebenso das Mausrad in seiner Auswirkung.

Was ich suche/wünsche wäre also eine Art App, die all diese Eigenschaften für einen User grafisch möglich macht und dann an X weiter reicht, on the fly sozusagen und ohne dass erst X neu konfiguriert und gestartet werden muss. Dynamisch und doch speicherbar.

Am ehesten also vielleicht etwas wie dies: https://github.com/libratbag/piper

Aber das geht ja noch weiter.
Unterschiedliche Geschwindigkeiten und Größen für Cursor oder Pointer, unterschiedliches Verhalten (automatusche Auswahl des Fensters unter Mauszeiger oder nicht, automatisches Platzieren über aktiver Kontroll-Fläche..) bis hin zu den eher lapidaren Dingen, wie Anzeigen der Position des Cursors/Pointers durch eine bewegte Grafik auf Tastendruck und unterschiedliche Farben des Zeigers.

Und ich erinnere mich daran, dass das alte KDE so etwas konnte (also integriert in das DE), zumindest rudimentär.
 

Andy_m4

Well-Known Member
Was ich suche/wünsche wäre also eine Art App, die all diese Eigenschaften für einen User grafisch möglich macht und dann an X weiter reicht, on the fly sozusagen und ohne dass erst X neu konfiguriert und gestartet werden muss. Dynamisch und doch speicherbar.
Prinzipiell geht das mit xinput. Sozusagen das xrandr für Eingabegeräte. :-)
Da könnte man "on-top" sich auch ein kleines GUI-Tool drauf schreiben. Möglicherweise findet man auch etwas Fertiges wenn man nach GUI for xinput sucht.

wie Anzeigen der Position des Cursors/Pointers durch eine bewegte Grafik auf Tastendruck und unterschiedliche Farben des Zeigers.
Auch solch ein Tool kriegt man eigentlich recht schnell gebaut. Das verbindet man dann einfach mit der lokalen Keyboard-Shortcut Funktion seiner Desktop-Umgebung.
Weils so einfach ist, gibts da bestimmt auch was Fertiges.
 

pit234a

Well-Known Member
Weils so einfach ist, gibts da bestimmt auch was Fertiges.
das dachte ich mir auch.
Nur habe ich nicht so viel Zeit und programmieren kann ich schon gar nicht. Deshalb die Frage, denn gefunden habe ich bisher nichts, also lxinput, was vermutlich ein Frontend zu xinput ist? und eben lxappearance, was ich ja schon lange nutze.
Aber das ist nur eine Teilmenge dessen, was möglich ist und heute sicher auch von einem Desktop-Nutzer gewünscht wird. Deshalb sollte es was geben, aber such mal in den Paketen nach mouse...
 

Andy_m4

Well-Known Member
Deshalb die Frage, denn gefunden habe ich bisher nichts, also lxinput, was vermutlich ein Frontend zu xinput ist?
Bestimmt. Also zumindest zu den entsprechenden X-Bibliotheken für die xinput ja auch nur ein (Commandline-)Frontend ist.
Wie vollständig lxinput ist, kann ich jetzt aber nicht beurteilen.

Aber das ist nur eine Teilmenge dessen, was möglich ist und heute sicher auch von einem Desktop-Nutzer gewünscht wird.
Weiß nicht. Ich selbst brauch nicht viel. Und die meisten Leute die ich sonst so kenne die fummeln eigentlich nicht großartig in den Einstellungen drin rum. Ich glaub die Zielgruppe für solche Einstellungen bzw. die GUIs dazu sind die sogenannten Power-User. :-)
 

Azazyel

Well-Known Member
Was ich suche/wünsche wäre also eine Art App, die all diese Eigenschaften für einen User grafisch möglich macht und dann an X weiter reicht, on the fly sozusagen und ohne dass erst X neu konfiguriert und gestartet werden muss. Dynamisch und doch speicherbar.

Jede vernünftige Desktop-Umgebung hat doch inzwischen allein schon aus Gründen der Barrierefreiheit genug Einstellungsmöglichkeiten, um den besseren Teil deiner Anforderungen zu erfüllen?! :confused:

Ebenso die Tasten, wie viele, welche wo mit welcher Funktion und ebenso das Mausrad in seiner Auswirkung.

Das keine 6 Monate alte Key Mapper könnte ein Kandidat sein. Als Python-Anwendung steht die Chance ganz gut, dass es auch unter FreeBSD läuft.

Und ich erinnere mich daran, dass das alte KDE so etwas konnte (also integriert in das DE), zumindest rudimentär.

Ich habe mal kurz das aktuelle GNOME gestartet, das erfüllt (in Verbindung mit besagtem Key Mapper für die Maustasten) auf den ersten Blick ausnahmslos all deine Anforderungen, inklusive Mausbeschleunigung und Mausfokus samt Konfigurierbarkeit via GUI.
 

pit234a

Well-Known Member
Jede vernünftige Desktop-Umgebung
ich habe halt eine unvernünftige.
Das ist ja so ein Problem, dass ich mir nicht gerne ein DE aufzwingen lasse, nur um eine bestimmte Funktion daraus zu erhalten. Da ist LXDE(LXQt) vorbildlich. Die Komponenten bekommt man einzeln und kann sie in seiner eigenen Umgebung nutzen.

Wenn GNOME, KDE, PLASMA, wie sie alle heißen, Lösungen dafür haben, wieso gibt es die nicht als gesondertes Paket, das alle nutzen können?
Natürlich bliebe die Frage nach den Abhängigkeiten (evtl), denn es macht ja nicht so viel Sinn, sich ein komplettes DE zu installieren und ungenutzt zu lassen, um nur eine einzige Anwendung daraus zu aktivieren.
Aber derzeit geht das ja ohnehin nicht. Es gibt nur ganz oder gar nicht, was mir nicht gefällt.
die Zielgruppe für solche Einstellungen bzw. die GUIs dazu sind die sogenannten Power-User. :-)
ja, und die nutzen vermutlich dann eh GNOME oder KDE...
 

Andy_m4

Well-Known Member
Wenn GNOME, KDE, PLASMA, wie sie alle heißen, Lösungen dafür haben, wieso gibt es die nicht als gesondertes Paket, das alle nutzen können?
Ich vermute mal, weil die Programme auch wieder auf die entsprechenden Libs und Funktionen der jeweiligen Desktop-Umgebung zurückgreifen.
Aber klar. Schön wärs natürlich, wenn solche Programme einfach als Output einen xinput-Aufruf erzeugen könnten, den man dann in seiner xinitrc einbauen kann.
Die sind halt irgendwie leider nicht dafür gedacht als Modulbaukasten verwendet zu werden. So wie man es auch von den Kommandozeilentools schon gefühlt ewig kennt.
 

Azazyel

Well-Known Member
Wenn GNOME, KDE, PLASMA, wie sie alle heißen, Lösungen dafür haben, wieso gibt es die nicht als gesondertes Paket, das alle nutzen können?

Wie Andy_m4 korrekterweise festgestellt hat, verringert das den Entwicklungs-, Integrations- und Wartungsaufwand enorm.

Natürlich bliebe die Frage nach den Abhängigkeiten (evtl), denn es macht ja nicht so viel Sinn, sich ein komplettes DE zu installieren und ungenutzt zu lassen, um nur eine einzige Anwendung daraus zu aktivieren.

Speicherplatz ist billig.

Aber klar. Schön wärs natürlich, wenn solche Programme einfach als Output einen xinput-Aufruf erzeugen könnten, den man dann in seiner xinitrc einbauen kann.

In Anbetracht des faktischen Ablebens von X.Org wird die Zielgruppe für dieses Feature sehr klein.

Die sind halt irgendwie leider nicht dafür gedacht als Modulbaukasten verwendet zu werden. So wie man es auch von den Kommandozeilentools schon gefühlt ewig kennt.

Dafür reicht die Entwicklerkapazität der Unix-DEs bei weitem nicht aus.
 

Andy_m4

Well-Known Member
In Anbetracht des faktischen Ablebens von X.Org wird die Zielgruppe für dieses Feature sehr klein.
Ja. Weiß nicht wie es unter Wayland ist. Aber da wirds ja vielleicht etwas Ähnliches geben.
Gibt ja durchaus Programme die können nicht nur das, was man in der GUI (oder wie auch immer) einstellt direkt ausführen, sondern auch ein Commandline-Aufruf draus machen. Das finde ich ne ganz praktische Sache. Weil man das dann auch einfach in Skripte einbauen kann.

Dafür reicht die Entwicklerkapazität der Unix-DEs bei weitem nicht aus.
Das ist richtig. Das war auch weniger als Kritik gemeint, sondern eher als Feststellung.
Und man muss ja auch klar sagen, das sich im Bereich "Desktopübergreifende Funktionalitäten" (z.B.: freedesktop.org) schon einiges getan hat.
 

pit234a

Well-Known Member
Dafür reicht die Entwicklerkapazität der Unix-DEs bei weitem nicht aus.
naja, ich glaube nicht, dass die LXDE Entwickler da eine Sonderrolle haben.
So ein wenig ist das schon eine Frage, wie man sein DE konstruiert. Will man überhaupt unabhängige Tools, die auch unter anderen DEs genutzt werden können?
Und der Aufwand ist sicher ziemlich genau gleich, wenn ich das grundlegend mache, also Mauseinstellungen in einem Tool zusammen fasse. Es gibt ja schon alles, nur keine zusammenfassende GUI.

Und vielleicht noch nicht das "Pseudo-Device", das dann zu X oder Wayland durchgereicht wird und über die GUI konfiguriert werden kann.
Falls man das braucht, aber ich denke, das würde die Sache vereinfachen. Nicht die Maus direkt, sondern Maus -> HW-System(Kernel) -> WUNSCH-APP -> Pseudo-Device -> X (oder Wayland oder andere). WUNSCH-APP würde alles konfigurieren und einstellen und direkt an Pseudo-Device übergeben und in X oder Wayland hängt das Pseudo-device und nicht direkt die Maus selbst.

Ich sehe das nicht als X-Problem und wenn X so schnell verschwindet, wie manch andere tote Ratte (oder wie sagt man da?), dann erlebe ich das vermutlich nicht mehr.
 

Andy_m4

Well-Known Member
So ein wenig ist das schon eine Frage, wie man sein DE konstruiert. Will man überhaupt unabhängige Tools, die auch unter anderen DEs genutzt werden können?
Wie gesagt. Das gibts ja durchaus schon. Beispielhaft hatte ich ja freedesktop.org genannt. Dort sind schon bestimmte Dinge vereinheitlicht. Zum Beispiel das globale Programmmenü oder auch Dateizuordnungen (also welche Datei mit welchem Programm geöffnet wird). Das führt dann tatsächlich dazu, das wenn Du bei solchen Sachen Tools der Konkurrenz nutzt das auch in "Deinen" Desktop-Umgebungen wirksam wird.
Damit sind wir schon weiter gegenüber früher, wo Desktop-Umgebungen tatsächlich geschlossene Umgebungen waren, in der jeder wirklich alles selbst gemacht hat und nichts mit dem jeweilig anderen kompatibel war.

Das das ausbaufähig wäre, das kann man sicher so sagen. Aber selbst wenn man übereinkommt das man da was ändern müsste, ist ja immer noch die Frage, welche Lösung man nimmt. Jeder hat ja für das jeweilige Problem schon seine Lösung gebastelt. Da was umzubauen nur damit die eigene Software quasi (auch noch) mit der Konkurrenz kompatibel ist, dazu hat wohl nicht jeder Lust (oder will auch die Ressourcen aufwenden selbst wenn er einsieht, das das praktisch wäre; womit wir wieder beim angesprochenen Entwicklerkapazitätsproblem wären).

Warum man nicht gleich seine Software interoperabel gestaltet hat hat mehrere Gründe. Wenn man ein neues Feature einführt was kein anderer hat ist die Frage leicht zu beantworten: Gibt halt keinen an den man sich hätte halten können.
Aber selbst wenn es ein Feature schon gibt: An so einer Desktop-Umgebung hängt ne Menge dran. Framework, Libs usw. Man hat sich ja schon grundlegendere Sachen geschaffen um bestimmte Dinge zu implementieren. Man versucht dann auch für weitere Funktionen darauf aufzusetzen (schlussendlich auch, weils einfacher ist).

Kompatibel zu sein bedeutet dann eben doch Mehrarbeit, womit wir wieder bei den Entwicklerkapazitäten wären.
Die Sachen sind eben nicht immer so einfach, wie es auf den ersten Blick scheint.

Ich hoffe, ich konnte einigermaßen klar machen wo das Problem liegt.
 
Oben