D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
Moin, ich habe das Script mit dmenu nun nochmal umgebaut. Die Apps können jetzt gelesen werden aus einer File oder aus dem Skript selbst; wenn keine Auswahl passt, kann die App in dmenu auch einfach eingegeben werden. Das wmctrl -ax klappt bei mir irgendwie nicht immer, und ein xdotool search --class "$app" windowactivate --sync funktioniert leider auch nicht. Fehlermeldung: XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) . Darum bin ich bei der Kombination geblieben. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | # auskommentieren oder leer lassen
app_file=~/tmp/app_file
# $app_file gilt vor $app_var
app_var="thunar firefox thunderbird claws-mail keepassx qupzilla geany"
# 1. Falls File existiert und leer ist, exit; wenn nicht-leer, File lesen.
# 2. Wenn File nicht angegeben oder File selbst nicht existent, Var lesen.
# 3. App in dmenu auswählen oder neue App eingeben (Groß- und Kleinschreibung möglich).
if [[ -n "$app_file" ]] && [[ -f "$app_file" ]] && [[ $(stat -c %s "$app_file" 2>/dev/null) -lt 2 ]]
then
{ echo 'Empty App File exists!' >&2 ; exit 1 ; }
else
app=$( { cat "$app_file" 2>/dev/null || echo "$app_var" ; } | tr ' ' '\n' | sort -g | dmenu -i -b -p "GO" -l 15 -nf "#DCDCCC" -nb "#2C2C2C" -sf "#2C2C2C" -sb "#DCDCCC" -fn 'Droid Sans Mono-9' | sed -re 's#^(\<.)#\L\1#g')
fi
if [[ $(pgrep -cf "$app") -gt 0 ]]
then
$(xdotool windowactivate --sync "$(wmctrl -lx | awk -v app_name="$app" 'BEGIN{IGNORECASE=1;} $0 ~ app_name {print $1}')" 2>/dev/null) || { echo 'Could not activate Window!' >&2 ; exit 2 ; }
else
shopt -s execfail
exec "$app" || { echo 'Could not run App!' >&2 ; exit 3 ; }
fi
|
|
HaCeMei
Anmeldungsdatum: 2. August 2010
Beiträge: 2262
|
D630 schrieb:
ich habe das Script mit dmenu nun nochmal umgebaut.
Das gewünschte Menü erscheint, noch nicht gestartete Programme lassen sich starten. Bei bereits geöffneten Fenstern erscheint bei mir jedoch "Could not activate Window!" .
|
D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
Probier mal diesen Befehl | awk -v app_name="$app" 'BEGIN{IGNORECASE=1;} $0 ~ app_name {print $1}'
|
mit diesem auszutauschen | grep -i "$app" | awk '{print $1}'
|
|
Grek336
Anmeldungsdatum: 28. November 2007
Beiträge: 408
|
Es gibt für die .desktop-Datei einen Parameter StartupWMClass= . Wenn also [Desktop Entry]
Name=Firefox Web Browser
Comment=Im Internet surfen
Exec=firefox
Icon=/usr/share/pixmaps/firefox.png
Terminal=false
Type=Application
Categories=Application;
StartupNotify=false
StartupWMClass=Firefox benutzt wird sollte beim starten geprüft werden ob es ein Fenster mit der WM_Class Firefox existiert und statt ein neues zu starten in dieses gewechselt werden. Mit im Terminal kann man prüfen welche WM_CLASS ein Fenster hat. Es erscheint ein Cursor und mit Klick auf ein Fenster werden die Eingenschaften im Terminal angezeigt. Ein Fenster kann mehrere WM_ClASS haben. Bei mir unter UNity liefert xprop | grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "Firefox" für ein Fenster von Firefox. Allerdings habe ich das nur ein Unity mit Java und Wine Anwendungen erfolgreich durchgeführt. LXDE benutze ich nicht. Die StartupWMClass ist aber nichts Unity spezifisches sondern gehört zu den allgemeinen Eigenschaften einer .desktop Datei und sollte von jeder Benutzeroberfläche verstanden werden http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html. Vielleicht funktioniert es ja unter LXDE genauso wie unter GNOME und Unity.
|
D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
Grek336 schrieb: Es gibt für die .desktop-Datei einen Parameter StartupWMClass= . Wenn also [Desktop Entry]
Name=Firefox Web Browser
Comment=Im Internet surfen
Exec=firefox
Icon=/usr/share/pixmaps/firefox.png
Terminal=false
Type=Application
Categories=Application;
StartupNotify=false
StartupWMClass=Firefox benutzt wird sollte beim starten geprüft werden ob es ein Fenster mit der WM_Class Firefox existiert und statt ein neues zu starten in dieses gewechselt werden.
Ja, das ist dann wohl die einfachste und schnellste Lösung! 😀 Blöd ist nur, dass dann so viele Starter bearbeitet werden müssten. WM_Class und WM_Name werden auch von wmctrl und xdotool ermittelt, wenn ich mich nicht irre. Die Scripte von oben matchen dagegen, sezieren die Window-ID und bringen dann die Fenster hervor.
|
HaCeMei
Anmeldungsdatum: 2. August 2010
Beiträge: 2262
|
D630 schrieb:
... sollte beim starten geprüft werden ob es ein Fenster mit der WM_Class Firefox existiert und statt ein neues zu starten in dieses gewechselt werden.
Ja, das ist dann wohl die einfachste und schnellste Lösung! 😀
Funktioniert nur leider (bei mir) nicht 😢 , es wird auf Klick jeweils eine neue Instanz von FF geöffnet.
|
sitronen-
Anmeldungsdatum: 17. August 2012
Beiträge: 651
|
Wenn du anstatt mehrerer Starter einen Dock (oder auch mehrere Docks) platzierst, das sich dann unter den Fenstern versteckt und nur sichtbar ist, wenn man alle Fenster minimiert und den Desktop aufruft, bzw. per Intellihide über die Bildschirmkante aufrufbar ist und sich auch auf dem leeren Desktop zeigt? Deren Starter erfüllen deine Ansprüche ohne Scriptmagic. Nachteil ist, dass die Icons nicht frei auf dem Bildschirm verteilt werden können.
|
Neuromatic
Anmeldungsdatum: 2. April 2012
Beiträge: 291
Wohnort: Rendsburg, SH
|
Okay, wir haben drei verschiedene Möglichkeiten den gewünschen Effekt zu erzielen. Wir haben ein Script mit nur zehn Zeilen, dass aus den Desktopdateien ausgeführt wird.
Wir haben ein Script mit 23 Zeilen, dass von dmenu Abhängt, eine ähnliche Technik verwendet wie das hierüber; nur mit einem etwas komplizierteren Aufbau.
Und wir haben eine Lösung die, lediglich eine Zeile in den jeweiligen Desktopdateien benötigt und in ein Unterlay-Dock einfügt werden kann. Ich halte es für Sinnvoll, wenn wir den Thread an dieser Stelle pausieren und einfach Abwarten bis sich der Thread-Starter wieder meldet und sich für eine Möglichkeit entscheidet, vorausgesetzt eine der angebotenen Lösungen enspricht seiner Vorstellung.
Jetzt muss er sich nur noch eine herauspicken ☺
|
HaCeMei
Anmeldungsdatum: 2. August 2010
Beiträge: 2262
|
Neuromatic schrieb:
Ich halte es für Sinnvoll, wenn wir den Thread an dieser Stelle pausieren und einfach Abwarten bis sich der Thread-Starter wieder meldet
Och nö, wo's gerade so schön ist 😉 Also, ich glaube, dass die ursprüngliche Anfrage am besten mit Neuromatics Vorschlag in diesem Post beantwortet ist. Das Skript läuft jetzt bei mir problemlos durch. Wenn man das per *.desktop-Datei auf dem Desktop(!) oder im Panel aufruft, hat man eine schöne Möglichkeit für einen "seniorengerechten" Computer. Nämlich: "Hier klicken, wenn du ins Internet willst". Man landet immer bei der bereits geöffneten Instanz, oder das Programm wird überhaupt gestartet. Im Grunde braucht man dann keine Fensterleiste mehr im Panel, eigentlich braucht man auch kein Panel. Allerdings würde ich den Starter nicht auf dem Desktop ablegen, sondern ein Lxpanel Launcher-artig als Seitenleiste gestalten, und dort die Starter mit der Handvoll Anwendungen ablegen, die die Seniorin braucht (Internet/ EMail/ Textverarbeitung/ ...). Damit wären die Symbol immer sichtbar, was die Orientierung für nicht-computer-affine Senioren erleichtern dürfte. Ich stelle mir das optisch vor wie im Unity-ohne-Unity Thread abgebildet. Der Aufwand scheint mir vertretbar, wenn man nur für wenige Programme Skripts und Starter anlegen will. Das Skript von D630 geht ja über die ursprüngliche Anfrage hinaus, (und ermöglicht auch eine größere Zahl von Programmen einzubeziehen). Mit der Korrektur von hier läuft es jetzt auch bei mir durch. Ich hänge mal einen Screenshot an. (Das hilft vielleicht aus dem Threadstarter bei der Auswahl 😀 )
Und wir haben eine Lösung die, lediglich eine Zeile in den jeweiligen Desktopdateien benötigt und in ein Unterlay-Dock einfügt werden kann.
Diese Lösung sehe ich nicht, bei mir funktioniert das weder unter Lubuntu noch unter Unity. Ich verstehe auch die freedesktop.org-Spezifikationen nicht. Kommt jemand anders damit klar?
- Bilder
|
D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
Wobei sich vllt noch sagen lässt: Beide Skripte aktivieren die Fenster in den Desktops, in denen sie bestehen. D.h, aktivieren wir die Skripte in Desktop 1 und ein Fenster liegt auf Desktop 2, ist der default Weg: switch Desktop 2 > aktiviere Fenster und bleibe in Desktop 2. Ansonsten müssen die Kommandos xdotool windowfocus oder wmctrl -R benutzt werden. Falls unter Openbox spezifische Einstellungen gemacht worden sind, die dazwischen funken, kann das natürlich anders sein. HaCeMei schrieb: Ich hänge mal einen Screenshot an. (Das hilft vielleicht aus dem Threadstarter bei der Auswahl 😀 )
Soweit ich sehe, benutzt du hier keine voll gepatchte Version von dmenu. Dann würde dmenu nämlich die Anzahl der Zeilen erkennen; falls diese kleiner ist als die maximale Darstellungszahl (im Skript definiert mit -l 15 ), würde die Höhe des Menüs dynamisch angepasst werden. Aber auch ohne Patch ließe sich das durch Erweiterung des Skripts regeln. Dann würde es allerdings noch komplexer. Oder: Statt vertikaler Ausrichtung ginge auch eine horizontale mit nur einer Zeile. Vllt noch ein Tipp: Wer dmenu auf der Konsole haben möchte, kann auch den Fork slmenu benutzen. [Edit] Ich hänge das Skript in neuer Form hier an.
|
D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
- activate.sh (2.2 KiB)
- Download activate.sh
|
Neuromatic
Anmeldungsdatum: 2. April 2012
Beiträge: 291
Wohnort: Rendsburg, SH
|
Wobei sich vllt noch sagen lässt: Beide Skripte aktivieren die Fenster in den Desktops, in denen sie bestehen. D.h, >aktivieren wir die Skripte in Desktop 1 und ein Fenster liegt auf Desktop 2, ist der default Weg: switch Desktop 2 > >aktiviere Fenster und bleibe in Desktop 2. Ansonsten müssen die Kommandos xdotool windowfocus oder wmctrl -R benutzt >werden. Falls unter Openbox spezifische Einstellungen gemacht worden sind, die dazwischen funken, kann das natürlich >anders sein.
Dabei sehe ich allerdings kein Problem, denn genau das ist ein Verhalten, dass ich sehr begrüßenswert finde.
Man will ein Fenster aktivieren, dass sich auf einem anderen Desktop befindet und wird zur Anwendung auf dem jeweiligen Desktop geschickt. Möchte man dann ein anderes Fenter aktivieren wird exakt das gleiche getan. Auf diese Weise muss man sich nicht mit den virtuellen Desktop beschäftigen, da dieses Feature nebenbei und unbemerkt für Ordnung sorgt.
Sollte man ausversehen auf einem anderen Desktop landen muss man einfach das ensprechende Programm aktivieren und ist wieder auf dem richtigen Desktop, ohne die Anwendung suchen zu müssen. Möglicherweise bin ich der einzige der das so sieht, aber ich finde dieses Verhalten wirkt sich sehr positiv auf die Ordnung auf dem Dekstop aus.
|
D630
Anmeldungsdatum: 24. Juli 2013
Beiträge: 329
|
Neuromatic schrieb:
Dabei sehe ich allerdings kein Problem, denn genau das ist ein Verhalten, dass ich sehr begrüßenswert finde.
Ja, ich finde das auch so besser. Ich wollte es nur nochmal erwähnt haben. Eine andere Sache ist mir noch aufgefallen: Die pgrep-Zeile matcht auch Apps, die als daemon gestartet sind, sich aber nicht aktivieren lassen, zB thunar, den ich im Openbox-Autostart eingetragen habe. Daher habe ich mir überlegt, die Zeile mit [[ $(pgrep -cf "$app") -gt 0 ]] && [[ $(pgrep -cf "$app.+[-d|-D|--daemon]+") = 0 ]] zu erweitern oder pgrep wegzulassen und stattdessen mit [[ $(wmctrl -lx | grep -ci "$app") -gt 0 ]] zu testen. Ich habe letzteres aufgenommen. Um doppelte Befehle zu vermeiden, musste ich das ganze nochmals umbauen. So, jetzt sollte aber grillparzer wieder zu Wort kommen.
- activate.sh (2.6 KiB)
- Download activate.sh
|
grillparzer
(Themenstarter)
Anmeldungsdatum: 7. März 2010
Beiträge: 873
|
Hallo, danke für eure Beiträge und die drei Lösungsvorschläge! War die letzten Tage unterwegs. Ich muss mir Eure Beiträge nochmal ganz in Ruhe ansehen und meld mich dann am Wochenende... Liebe Grüße, grillparzer
|
Neuromatic
Anmeldungsdatum: 2. April 2012
Beiträge: 291
Wohnort: Rendsburg, SH
|
Ich habe das Script noch ein wenig Unix-typischer gestaltet. Anwendungs- und Fensterklassenname werden nun als Argumante entgegengenommen und so in das Array geschrieben. Desweiterern wird nun die Datei
$HOME/.config/wmignore
genutzt, um bestimmte Anwendungen von der Funktionalität ausgeschlossen; also kontrolliert ignoriert Als nächstes ist geplant die wmignore Datei als Vollwertige Konfigurationsdatei zu intetrieren, um auch andere Einstellungen vornehmen zu können. Ein großer Aufwand für ein Script, dass keine 100 Zeilen aufweist, allerdings die Mühe wert wie ich finde 😛 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 | #!/bin/bash
#focus.sh
#requires: wmctrl
#app > focus appname windowclass
conf_file=$HOME/.config/wmignore
function usage() {
echo -e "\n $0: focus.sh appname windowclass \n"
}
case $# in
2)
app=( "$1" "$2" )
if [[ -n $(grep ${app[0]} $conf_file) ]]; then
echo -e "\n $0: Application is ignored by $USER \n"
elif [[ -n $(pgrep ${app[0]}) ]]; then
$(wmctrl -ax ${app[1]})
else
exec ${app[0]}
fi
;;
esac
|
|