• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Linux: Icon für CacheWolf gesucht...

snaky

Geowizard
Erstmal danke für die Icons. Ich bin gespannt, um die Umrahmung reicht, dass das Icon auf meinem roten Hintergrund erkennbar ist.

Was Amarok angeht: Die Downloadzahlen und Userkommentare sprechen schon seit Jahren Bände.

Rhythmbox ist prinzipiell auch nicht schlecht und wird immer besser/erweiterbarer. Aber aus irgendeinem Grund stürzt mir das Teil regelmäßig ab. Das ist irgendwie völlig untragbar. Möglichweise liegt es daran, dass ich mehrere tausend Podcasts in meinem Verzeichnis habe, aber trotzdem sollte so etwas nicht vorkommen.
 

pfeffer

Geowizard
1. welches der beiden (hellem oder dunklem Rand) sollen wir nehmen?
2. wie muss es heißen, damit es automatisch als Icon verwendet wird?
3. in welcher Größe sollen wir es nehmen?

4. am besten wäre, man würde herausfinden, warum Ubuntu das svg nicht schluckt.

Gruß,
Pfeffer.
 
Guter Fragen! Ich benutze Ubuntu -> ich bin Linux Dummie! ;)

Hab gerade festgestellt daß ich CW mit dem Starter auch gar nicht starten kann sondern nur mit Rechtsklick auf die .jar und dann "öffnen mit Java" :???:

Vielleicht findet sich ja ein Experte für Gnome! Fraglich ob das dann unter KDE genauso geht.....
 
pfeffer schrieb:
1. welches der beiden (hellem oder dunklem Rand) sollen wir nehmen?
Dunkler Rand ist besser! Auf dem aktuellen Ubuntu Defaulthintergrund ist das Icon sonst fast unsichtbar! ;)


pfeffer schrieb:
4. am besten wäre, man würde herausfinden, warum Ubuntu das svg nicht schluckt.

Ubuntu kann SVG PNG und GIF. Vielleicht ist das SVG zu groß oder nicht quadratisch?
Außerdem sind in dem SVG die beiden Flächen im Zeichen nicht transparent sondern weiß!

Mit der Bearbeitung von SVG kenn ich mcih aber nicht aus, ich hab es nur in GIMP als Bitmap rendern lassen.

pfeffer schrieb:
3. in welcher Größe sollen wir es nehmen?

350x350 passt schon, Linux skaliert da ganz flexibel! Die Beiden Desktopicons auf dem Screenshot sind die selbe Datei mit 350x350 nur unterschiedlcih dargestellt.
SVG wär natürlich noch geschmeidiger!
 

mirabilos

Geocacher
Aktuelle KDE- und GNOME-Versionen können SVG, ältere nicht. Soweit ich weiß
sollte man das Icon als 16x16, 32x32, 48x48 und 64x64 PNG sowie als SVG mit-
liefern und eine irgendwas.desktop-Datei (oder so) erzeugen, damit der die auto-
matisch frißt.

Aber: man muß die Jar-Version ja mit Java™, die Ewe-Version mit Ewe ausführen.
Dazu müssen auch die Pfade in der .desktop-Datei (also Verknüpfung) drinstehen.

Am besten fände ich die Lösung, die Icons mit ins Snapshotverzeichnis zu legen und
das richtige Benennen, Plazieren und Erstellen der Verknüpfung dann dem jeweiligen
Paketierungssystem/Distributor zu überlassen, der dann z.B. RPM-, DEB- und andere
Pakete erzeugt (in der Regel die Distribution selber). Das würd ich auch machen, mit
SVG kenne ich mich ein wenig aus (hab das schon bei FreeWRT mal verhackstük-
kelt).

Ansonsten könnte man vielleicht selber Debian-Pakete aus Ewe und Cachewolf
bauen (die Jar-Version wird nix, weil Java™ selber ja nicht frei lizensiert ist) und
versuchen, diese in Debian und Ubuntu integrieren zu lassen. Falls Interesse be-
steht, tretet mich mal, dann mach ich das für CW 1.0 (aber ich vermute einfach
mal, es werden maximal Anfragen kommen, das für die Jar-Version, nicht die Ewe-
Version, zu machen… sorry Leute, geht lizenzrechtlich nicht). Eventuell krieg ich
das Ganze auch mit RPMs hin (ich kenne durch meine Arbeit an mksh da ein paar
Leute)…
 

snaky

Geowizard
Wie zu erwarten konnte ich bei mir das Icon auf meinem Hintergrund kaum erkennen.

Ich habe deswegen noch einen Drop-Shadow dazugefügt. So lässt sich das Icon ganz gut erkennen. Ich hänge es hier einfach auch mal an. Es ist wohl nicht 100% sauber ausgeschnitten, aber bei normaler Größe sieht man das nicht.
 

Anhänge

  • cwlogohell2.png
    cwlogohell2.png
    45,8 KB · Aufrufe: 149
snaky schrieb:
Wie zu erwarten konnte ich bei mir das Icon auf meinem Hintergrund kaum erkennen.

Ich habe deswegen noch einen Drop-Shadow dazugefügt. So lässt sich das Icon ganz gut erkennen. Ich hänge es hier einfach auch mal an. Es ist wohl nicht 100% sauber ausgeschnitten, aber bei normaler Größe sieht man das nicht.

Der Hintergrund ist aber nicht mehr transparent oder? Das sieht dann IMHO ziemlich ungeschmeidig aus!
 

snaky

Geowizard
Am Hintergrund habe ich nichts geändert. Ich habe das so auch bei mir in der Leiste und der Hintergrund ist transparent. :???:
 

greiol

Geoguru
pfeffer schrieb:
fertige .deb und .rpm das wäre toll!
das würde aber _in meinen augen_ bedingen, dass cw seine config in $HOME statt in seinem programmverzeichnis sucht, bzw. eine entsprechende commandline option vorhanden ist. geht das inzwischen?
 
OP
W

white_rabbit

Geocacher
wallace&gromit schrieb:
Hab gerade festgestellt daß ich CW mit dem Starter auch gar nicht starten kann sondern nur mit Rechtsklick auf die .jar und dann "öffnen mit Java" :???:


Hi. Ich starte den CW unter Linux über ein kleines Script (ebenfalls Ubuntu 8.04):

#! /bin/bash
cd /home/<user>/CacheWolf/bleeding_edge_Version
java -cp CacheWolf.jar ewe.applet.Applet /Xmx CacheWolf.CacheWolf

(das ganze natürlich ausführbar machen mit chmod ...
h.i.h.
 

greiol

Geoguru
pfeffer schrieb:
fertige .deb und .rpm das wäre toll!
white_rabbit schrieb:
Hi. Ich starte den CW unter Linux über ein kleines Script (ebenfalls Ubuntu 8.04):
h.i.h.
nope
mirabilos schrieb:
Na dann lieber so:
nope

das trifft beides nicht den punkt, denn in beiden fällen wird eine lokale installation im homeverzeichnis des users benutzt.

nach meinem verständnis erzeugen .deb und .rpm pakete eine systemweite installation, würden sich also vermutlich irgendwo unter /usr oder /opt einrichten (da kann man wie immer trefflich drüber streiten - wobei ich zu /usr tendiere). dort sollte aber ein "normaler" user keine schreibrechte haben, sondern nur in seinem homeverzeichnis.

nun muss ich dem ganzen system also bebringen, dass die pref.xml nicht mehr in dem vereichnis liegt in dem "der Rest" vom Cachewolf liegt, sondern woanders. blöderweise sucht cachewolf hart verdrahtet in FileBase.getProgramDirectory() und genau das geht dann eben nicht mehr.

frage an die java programmierer: wäre System.getProperties("user.home") da ein weg?

solange das nicht geändert wird, bzw. cw einen commandline parameter bekommt mit dem man den pfad zur pref.xml überschreiben kann, können keine sinnvollen .rpm und .deb pakate für eine zentrale installation erstellt werden und es bleibt bei der lokalen installation irgendwo im homeverzeichnis des users.
 

MiK

Geoguru
Wenn das geändert wird, bräuchten wir auf jeden Fall eine Art Commandline-Parameter. Sonst funktioniert es z.B. nicht mehr CW auf der SD-Karte an jedem beliebigen Rechner zu benutzen.
 

Wortfetzen

Geocacher
MiK schrieb:
Wenn das geändert wird, bräuchten wir auf jeden Fall eine Art Commandline-Parameter. Sonst funktioniert es z.B. nicht mehr CW auf der SD-Karte an jedem beliebigen Rechner zu benutzen.
Man könnte die Änderung zum Zugriff aufs Home-Verzeichnis ( System.getProperties("user.home") ) auch als debian-patch machen. Dann würde NUR für die Erstellung des deb-Archivs lokal diese Änderung vorgenommen (nicht im SVN).

Die Frage die sich mir eher stellt:
gibt es außer diesem
Code:
FileBase.getProgramDirectory()
noch andere Stellen, bei denen CW vorraussetzt, daß die Daten (pref.xml etc..) im Install-Verzeichnis liegen?
 

greiol

Geoguru
MiK schrieb:
Wenn das geändert wird, bräuchten wir auf jeden Fall eine Art Commandline-Parameter. Sonst funktioniert es z.B. nicht mehr CW auf der SD-Karte an jedem beliebigen Rechner zu benutzen.
guter punkt

wobei man das kaskadierend machen könnte:
ist ein -DCacheWolf.Prefs= gesetzt wird (resp. wie auch immer das dann für die ewe bzw. exe version heissen müsste) das genommen, sonst wird im GetProgramDir nach einer _schreibbaren_ prefs.xml gesucht und wenn das nicht geht im user.home. falls alle stricke reissen, könnte man man den user über einen dialog fragen wo die datei liegt, allerdings wäre das dann session spezifisch. cw müsste allerdings auch um die fähigkeit erweitert werden eine prefs.xml datei zu erzeugen falls noch keine existiert.

möglich ist also vieles.

Wortfetzen schrieb:
Dann würde NUR für die Erstellung des deb-Archivs lokal diese Änderung vorgenommen
zum einen hätte ich es ganz gerne für rpm und zum anderen sollte es imho nicht notwendig sein, für den package build zusätzliche patches einzubinden. sonst fängst du für jedes release an zusätzlich am buildprozess zu arebeiten (passen die patches alle noch?) statt einfach nur das neue sourcepaket reinzulegen.
 

Wortfetzen

Geocacher
greiol schrieb:
zum einen hätte ich es ganz gerne für rpm und zum anderen sollte es imho nicht notwendig sein, für den package build zusätzliche patches einzubinden. sonst fängst du für jedes release an zusätzlich am buildprozess zu arebeiten (passen die patches alle noch?) statt einfach nur das neue sourcepaket reinzulegen.
Ich kenne mich mit der Erstellung von RPMs nicht aus, aber ich denke dort sollte es einen ähnlichen Mechanismus geben wie bei debs.
Falls sich die notwendigen Änderungen auf diese eine Zeile beschränken, wäre ein debian-Patch doch kein Problem. Diese eine Zeile wird sich sogut wie nie ändern, also sollte da auch keine Änderung bei jedem Release nötig sein.

Ich denke jedenfalls daß es durchaus gängige Praxis ist, wenn sich die Paket-Ersteller an die Entwickler anpassen und nicht umgekehrt.

Natürlich kann man sagen, daß es - für Linux - besser wäre, wenn der CW sich im $HOME bedient und nicht im Install-Pfad.
Aber den CW gibt es eben auch für viele andere Systeme, und ein Distri-Patch wäre hier die allerschnellste, einfachste Lösung in meinen Augen :???:
 
Oben