eine textdate mit dem systemweiten default texteditor öffnen

[Rogdab]

Moin,
ich schreib gerade eine GUI, vornehmlich mit GTK, und habe eine Funktion die eine Textdatei öffnet. Gibt es unter GNOME und/oder KDE eine methode diese textdatei mittels system() aufzurufen?
Google hat mir $EDITOR ausgespuckt, da findet sich bei mir aber nichts(UBUNTU/6.06).

danke

[anda_skoa]

Unter KDE gibt es dazu KRun (KIO lib), unter GNOME gnome_open() und gnome_vfs_irgendwas()

Mittels Commandlinetool wären es
(KDE) kfmclient exec $url
(GNOME) gnome-open $url
(XFCE) exo-open $url

oder allgemeiner

(XDG-UTLIS) xdg-open $url

Ciao,
_

[Rogdab]

cool danke, xdg-open gibs bei mir nicht, daher kann ich nicht davon ausgehen das alle das haben, ich werd mich mal auf die Suche nach ner funktion machen die checkt welches DE gerade läuft, gibs sowas überhaupt?

[anda_skoa]

Die xdg-utils sind derzeit in der dritten Beta verfügbar http://portland.freedesktop.org/xdg-utils-1.0beta3/

Wir streben an, Version 1.0 als Bestandteil des nächsten LSB Standards zu haben, von Seiten der entsprechende Leute gibt es dazu ebenfalls Zustimmung.

Eine Applikation kann bis dorthin bzw auch darüber hinaus die xdg-utils, bzw auch nur die benötigten Scripte selbst mitbringen, solange der Version in PATH der Vorzug gegeben wird.

Es wurde unter anderem berichtet, daß Google Earth eines der Scripte mit dabei hat, allerdings soweit mir bekannt aus unerfindlichen Gründen nicht xdg-open

Es ist zwar möglich den DE Check aus den xdg-utils zu übernehmen, aber ich würde eher davon abraten, die Scripte haben teilweise noch andere Anpassungen für konsistenteres Verhalten

Ciao,
_

[CCCoder]

Also, die Environment Variable $EDITOR ist schon richtig. Wenn da nichts steht ist es eher ein Problem von UBUNTU oder der Konfiguration...

[anda_skoa]

Nur steht in $EDITOR meistens ein Konsoleneditor, nicht die Standard X11 Applikation für text/*

Ciao,
_

[Christoph]

Nur steht in $EDITOR meistens ein Konsoleneditor, nicht die Standard X11 Applikation für text/*

Die Defintion von Applikationen für Dateitypen ist eines der Probleme, die zugegebenermaßen in Linux überhaupt nicht gelöst sind. Eigentlich sollte dazu /etc/mime.types da sein (vergleichbar dem Registry-Zweig für Dateitypen in Windows oder der lLaunchServices Datenbank unter OSX), aber es gibt wegen des Fehlens eines vorgegebenen Standards viele Insellösungen (z.B. gnome, KDE, xfce usw.).



Die xdg-utils sind derzeit in der dritten Beta verfügbar http://portland.freedesktop.org/xdg-utils-1.0beta3/

Allein die Notwendigkeit dieses Projekts ist ja symptomatisch genug.

Ich löse das für meine Anwendungen so, dass ich unter Linux dem Benutzer Konfigurationsoptionen für die wichtigsten Programme anbiete. Als Default für Text empfiehlt sich xedit, der zwar gruselig, aber mit Sicherheit immer installiert ist.

[anda_skoa]

Die Defintion von Applikationen für Dateitypen ist eines der Probleme, die zugegebenermaßen in Linux überhaupt nicht gelöst sind.


Das ist zwar nich Linux spezfisch, aber das Zuordnen von Applikation auf MIME Type wird in der desktop-entry Spezifikation behandlet.
Das Problem ist nur die Reihenfolge, bzw eben welche aller zugeordneten Applikation die "Standardapplikation" für einen MIME Type ist.



Eigentlich sollte dazu /etc/mime.types da sein

Du meinst vermutlich /etc/mailcap
mime.types enthält Informationen wie man bei einer Datei den MIME Type "erkennt"

Gibt es eigentlich kein Commandline Tool das mailcap auswertet?



Ich löse das für meine Anwendungen so, dass ich unter Linux dem Benutzer Konfigurationsoptionen für die wichtigsten Programme anbiete.

Ansich keine schlechte Lösung, immerhin hat man so als Benutzer sogar die Möglichkeit, es pro Applikation einzustellen.
Vermutlich ist für die meisten Anwendungsfälle die Benutzung von xdg-open aber einfacher, selbst wenn erst die nächsten Releases der Betriebsysteme diese standardmäßig installieren, weil man ja ohne Kompatibilitätsproblem (ist ja ein Script) eine eigene Version mitpacken kann.



Als Default für Text empfiehlt sich xedit, der zwar gruselig, aber mit Sicherheit immer installiert ist.
Darauf würde ich mich nicht verlassen, zumindest hier auf CentOS4.2 ist das nicht der Fall.