Datei-Launcher in Python

[snafu]

Ich arbeite derzeit an einer Python-Implementierung zum "Launchen" von Dateien. Als Vorbild nehme ich natürlich dies und das aus den bereits verfügbaren Launcher-Varianten. Wie es sich für ein vernünftiges Programm gehört, habe ich erstmal eine (Vorab-)Version für die Kernfunktionalität geschrieben, auf welcher später die GUI aufsetzen soll. Wenn es Verbesserungsvorschläge hinsichtlich der Strukturierung, des Handlings, der Docstrings, o.ä. gibt, dann immer her damit.

http://bpaste.net/show/13339/

EDIT: Github-Repo

[BlackJack]

@snafu: Zum `is_command()`-Test würde für mich Ausfühbarkeit dazugehören. Eine Datei im ``$PATH`` die man nicht ausführen kann, ist auch kein Kommando. Oder?

In `xdg_open()` leitest Du die Ausgabe des Prozesses um, aber es wird nie davon gelesen. Damit sollten Prozesse blockieren die mehr Ausgaben schreiben als in den Puffer zwischen den beiden Programmen passt.

`launch()` sollte vielleicht auch mit `unicode` klarkommen können.

[snafu]

Das von dir vorgeschlagene Verhalten von "is_command()" hatte ich zunächst auch. Doch dann bemerkte ich, dass die Shell (zumindest zsh und bash) ebenfalls eine Datei grundsätzlich ausführen wollen, wenn sie diese im PATH finden. Ich dachte mir, dass es deshalb besser ist, wenn sich "is_command()" genau so verhält.

Die "launch()"-Funktion kann nicht mit Unicode umgehen, weil "shlex.split()" es nicht kann. Zudem verhält sich "shlex.split()" ungewöhnlich, wenn es mit None umgehen soll. Dann liest es nämlich von STDIN. Daher der explizite Typcheck an dieser Stelle. Das hatte ich erst als Kommentar stehen und dann wieder rausgenommen. Sollte ich vielleicht besser wieder reinpacken.

Zu "xdg-open()": Ehrlich gesagt weiß ich nicht, wie man sonst eine Ausgabe unterdrücken kann und bin immer so vorgegangen. Wie würdest du es denn machen?

[BlackJack]

@snafu: Ich würde statt `STDOUT` eine Datei mit dem Namen aus `os.devnull` öffnen und übergeben. Also im Grunde das was man auf der Shell auch machen würde.

Oder aber die Ausgaben gar nicht umlenken -- machen andere Launcher ja auch nicht und es erschwert die Fehlersuche wenn man nicht sehen kann warum ein Programm vielleicht nicht startet.

[snafu]

Oder aber die Ausgaben gar nicht umlenken -- machen andere Launcher ja auch nicht

Könntest du mal ein Beispiel für so einen Launcher nennen? Ich find's halt kacke, wenn da ständig die xdg-open Ausgabe steht. Meine Implementierung ist ja bewusst darauf ausgelegt, dass Fehler von xdg-open zurückgegeben werden könnten.

und es erschwert die Fehlersuche wenn man nicht sehen kann warum ein Programm vielleicht nicht startet.

Ich werde zwecks Debugging vielleicht eine Option einfügen, die bestimmt, ob die Ausgabe von xdg-open gezeigt werden soll. Generell finde ich es halt besser, wenn Programme nur bei Bedarf gesprächiger werden. Ich habe ja auch eine recht allgemein gehaltene Ausgabe beim LaunchError. Damit will ich aber natürlich nicht bestreiten, dass verbose-Flags mit entsprechender Wirkung auch später mal für's Logging ganz gut sein könnten.

[BlackJack]

@snafu: Ich habe hier jetzt gerade nur `krunner` installiert, erwarte das aber eigentlich von jedem Launcher. Genau wie viele andere GUI-Programme alles mögliche auf die Standardausgabe(n) schreiben. Man sieht diese Ausgaben normalerweise doch gar nicht, oder hast Du ständig das Log offen wo die Textausgaben von GUI-Programmen landen?

[snafu]

Jetzt mit prototypartiger GUI in PyQt: launchit.tar.gz

Wenn man den vorgegebenen Ordner übernimmt, dann lässt sich das Programm aus dem nächsthöheren Verzeichnis via "python -m launchit.gui" starten.

Ich bitte, dies natürlich eher als Proof of Concept anzusehen. Die nächste Hürde wird es sein, die Fragmente markiert anzuzeigen, in etwa so wie man das bei dem Completer vom Firefox kennt (fett und unterstrichen). Ich weiß, dass Qt HTML-Tags in QLabels unterstützt. Die werden allerdings nicht im verwendeten Popup gerendert. Ist mein Ansatz, ein eigenes Delegate auf den zugehörigen View zu legen, der richtige? Muss ich dort das QLabel erstellen oder wie würde es ablaufen?

[The Spirit]

mit welcher python version lauffähig?
wollte gerade mit 2.5.4 testen, aber da geht es nicht.
hier die fehlermeldung:

Code: Alles auswählen

launchit\core.py:146: Warning: 'with' will become a reserved keyword in Python 2.6
Traceback (most recent call last):
  File "C:\Python25\lib\runpy.py", line 85, in run_module
    loader = get_loader(mod_name)
  File "C:\Python25\lib\pkgutil.py", line 456, in get_loader
    return find_loader(fullname)
  File "C:\Python25\lib\pkgutil.py", line 466, in find_loader
    for importer in iter_importers(fullname):
  File "C:\Python25\lib\pkgutil.py", line 422, in iter_importers
    __import__(pkg)
  File "launchit\__init__.py", line 1, in <module>
    from . import core, gui
  File "launchit\core.py", line 146
    with open(os.devnull, 'w') as null:
            ^
SyntaxError: invalid syntax

[snafu]

Ab Python 2.6, du könntest an den Anfang der core.py ein "from __future__ import with_statement" setzen. Allerdings wirst du dann über das neuere String Formatting stolpern. Wenn möglich, installiere dir etwas > 2.5

[BlackJack]

@snafu: Der Import für die ``with``-Anweisung ist bei 2.5 möglich/nötig. Python 2.6 hat die Anweisung schon ohne das man was importieren muss.

[The Spirit]

kann man pyqt4 auch woanders runterladen?
hauptseite scheint gerade down zu sein.
bräuchte es für windows.
thx

[snafu]

@snafu: Der Import für die ``with``-Anweisung ist bei 2.5 möglich/nötig. Python 2.6 hat die Anweisung schon ohne das man was importieren muss.

Das schrieb ich doch? Es ist ein __future__-Import nötig. Trotzdem wird er über str.format() stolpern und in den Genuss der xdg-open Funktionalität wird er wohl auch eher nicht kommen.

Falls das unverständlich rüberkam, erklär ich's aber nochmal: "Mit welcher Python-Version lauffähig?" - "Ab Python 2.6, du könntest [für dein Python 2.5] an den Anfang der core.py ein "from __future__ import with_statement" setzen." Hoffe, jetzt ist es deutlicher.

Übrigens, bei mir geht der Download: http://www.riverbankcomputing.co.uk/sof ... t/download

[snafu]

Da mich das dumpfe Gefühl beschleicht, dass sich kaum einer was von dem Link runterladen wird, habe ich ein Repo angelegt: https://github.com/seblin/launchit

[BlackJack]

@snafu: Sorry, hatte das irgendwie falsch gelesen.

[The Spirit]

kann leider noch immer nicht auf
http://www.riverbankcomputing.co.uk/sof ... t/download
von drei verschiedenen rechner mit unterschiedlichen browsern probiert.
so kann ich es leider nicht testen. :K

[snafu]

Keine Ahnung, was du machst. Ich komme da sofort drauf. Vielleicht blockt deine Firewall irgendwie? Soviel gibt es aber wie gesagt nicht zu testen. Insbesondere zielt das derzeit eher auf Linux-Nutzer ab.

Ich will nur endlich das Problem mit den (nicht vorhandenen) Markierungen im Popup lösen... *grummel*

[snafu]

Für Interessierte: Launchit rendert die Ergebnisse nun mit via HTML-Tags realisierten Markierungen für das jeweils gesuchte "Bruchstück". Es gibt noch Darstellungsprobleme bei Namen, die von der Länge her nicht ins Popup passen (Auslassungspunkte fehlen), but you get the idea.

Der zugehörige Code findet sich in der aktuellen gui.py.

[snafu]

Heyho. Nachdem ich den letzten Monaten immer wieder mal mehr und mal weniger an den Funktionen "unter der Haube" gebastelt habe, ist nun ein weiteres Feature in die grafische Oberfläche implementiert: Launchit unterstützt nun die Anzeige von Icons, wenn ein Eintrag ausgewählt bzw ein Kommando ausgeschrieben wird.

Dabei wird nach Möglichkeit das selbe Programm-Icon angezeigt, wie es auch in den Menüeinträgen des Benutzers genutzt wird. In anderen Fällen (z.B. bei reinen Kommanozeilen-Tools) wird ein allgemein gehaltenes Icon angezeigt, so wie man das von einigen anderen Launchern her kennt. Zur Zeit erfahren hier lediglich ausführbare Programme diese generische Behandlung. Andere Dateitypen werden später noch mit einem zum Mimetype passenden Icon bestückt.

Bitte weiterhin beachten, dass Launchit für mich noch keinen Release-Status hat und daher mit diesem kleinen Zwischenbericht dementsprechend auch nicht zum produktiven Einsatz ermuntert werden soll. Insbesondere Benutzer, die ein anderes DE als KDE oder GNOME verwenden, werden sich wundern, dass viele Icons nicht angezeigt werden, was daran liegt, dass Launchit sich hier noch auf die Theme-Erkennung von Qt verlässt, welche sich leider nur auf die beiden genannten DEs beschränkt. Das ändert sich aber natürlich noch. Und das `gui`-Modul wird in naher Zukunft natürlich auch endlich mit Docstrings versehen.

Noch etwas: Launchit läuft weiterhin nur auf Linux (vielleicht auch Unix) Oberflächen. Abhängigkeiten bestehen zu den Modulen PySide, sowie PyXDG. Letzteres ist leider nicht über PyPi zu bekommen, sodass auf die distributionseigene Paketverwaltung ausgewichen werden sollte (der Name ist meist `python-xdg`), was man im Falle von PySide sicherlich auch schon tut. Der Start selbst wird weiterhin aus dem Wurzelverzeichnis des (heruntergeladenen) Repos mittels `python -m launchit.gui` empfohlen.

Repo-Stand zum Zeitpunkt als dieser Beitrag verfasst wurde: https://github.com/seblin/launchit/tree ... 914f19a6f9

//edit: Seit dem letzten Commit kann wahlweise der zu verwendende Icon-Theme Name in die `launchit.conf` geschrieben werden. Empfiehlt sich eigentlich nur für die o.g. Fälle, wo Qt das nicht schon selber macht.