Bilder-Beschriftung

[Rolli]

AW: Bilder-Beschriftung

ich möchte hier einmal eine etwas andere sicht der dinge vertreten -- und sei es vielleicht auch nur, weil ich aus anderen foren, in denen entwickler entsprechender freier software gemeinsam an ihren ideen arbeiten, einen weitaus rauheren, letztlich aber doch 'kritisch-konstruktiven' umgang mit derartigen ansätzen gewohnt bin.

um es kurz zu machen: ich halte den gewählten umsetzungsweg in vielerlei hinsicht für eine relativ problematische 'einbahnstraße' -- od., mit ganz böser zunge gesprochen: so etwas wie einen in software gegossenen 'klettersteig'

einerseits erlaubt es dein programm zwar sicher, auf den ersten blick beeindruckende resultate zu produzieren, gleichzeitig aber werden die tatsächlichen handwerklichen fragestellungen (spätere nachbearbeitung, kompatibilität, verwendung von vektor- vs. pixelformat etc.) in wahrheit nur weiter aufgeschoben und dem benutzer auch weiterhin gar nicht erst bewusst.

wie problematisch sich derartige entwicklungen äußern können, ist ja sicher auch dir nicht unbekannt -- schließlich kennt jeder von uns diesen typus des computeranwenders, der vermutlich auch zur beschriftung von panoramabildern mit größter selbstverständlichkeit wieder auf das ihm vertraute ms-word zurückgreift und alleine dort sein glück versucht (ja, ich bin mir wirklich sicher, dass man selbst damit im gegegeben anwendungsfall mit dem nötigen maß an kaltblütigkeit subjektiv 'befriedigende' resultate zusammenzubringen vermag!)

also -- um wieder ein wenig auf den konstruktiven boden entsprechender kritik zurückzukommen --, in einigen punkten glaube ich doch, dass du dein programm wirklich grundsätzlich anders ausrichten/gestalten solltest.

freie software funktioniert erfahrungsgemäß dort am besten, wo sie nicht so sehr ein geschlossenes fertiges produkt bereitstellt, sondern vielmehr das möglichst offene und reibungslose zusammenspiel verschiedener einzelprogramme und hilfsmittel im größeren arbeitsfluß begünstigt. ich denke also, dass es auch hier vermutlich wesentlich zielführender, professionelle und befriedigender erscheinen könnte, wenn du statt irgendwelcher properitären .ini-dateien und fertig gerenderte bildausgaben, die daten auch in weiterverabeitbaren formaten -- bsp. SVG basierenden vektor-grafiken -- bereitstellen könntest!

(ich glaube, ich habe hier im forum schon einmal vor sehr langer zeit ausführlich zu erklären versucht, warum es in diesem falle wirklich sinn machen dürfte, zwischen bild- und vektorgrafik bzw. entsprechenen bearbeitungsschritten und austauschformaten zu unterscheiden!)

ich persönlich würde ja fast noch ein wenig weiter gehen, und schlichtweg behaupten, dass es oftmals zweckmäßiger sein kann, computeranwender zu einem bewussten umgang mit geigeneten werkzeugen bzw. arbeitstechniken zu erziehen, statt letztlich doch nur wieder den kurzsichtigen konsum entsprechender oberflächlicher hilfestellungen bzw. tendenziellen aufschub zu befördern. wenn hier nun plötzlich bspw. das ersuchen an dich herangetragen wird, auch wege-skizzen etc. mit deinem programm zu bewerkstelligen, werte ich das eindeutig als indikator für genau diese problematik. würdest du nämlich all diesen wünschen tatsächlich nachzukommen versuchen, dürfte sich vermutlich sehr bald schon herausstellen, dass sich dein programm immer mehr einem der ohnehin bereits verfügbaren grafikprogramme a la inkscape etc. anzunähern beginnt. deshalb würde ich es fast lieber sehen, wenn das ganze viel eher als plugin/extension/macro in einem zu diesem zweck geschaffenen framework angelegt worden worden wäre od. wenigstens eine sanfte heranführung an die damit verbunden handwerkliche mittel befördern könnte.

naja -- und über die umsetztung in java bzw. die damit verbunden unnötige ressourcenverschwendung, könnte ich hier vielleicht auch noch ein klein wenig mitleid heucheln -- aber damit würde das ganze vermutlich entgültig zu sehr ins technokratische abdriften...

trotzdem finde ich es natürlich weiterhin äußerst toll von dir, dass du dir überhaupt die mühe machst, einen entsprechenden gestalterischen versuch in die welt zu setzten! ich würde es sogar begrüßen, wenn du in diesem sinne auch die quellen deines programms regelmäßig zugänglich machen könntest -- schließlich enthält ja das ausführbare programm, so weit ich es von außen durchleuchten kann, ohnehin ein reiches maß an GPL und LGPL lizensierten komponenten.

ich hoffe, du nimmst mir diese nicht ganz so forums-konformen worte hier nicht all zu übel -- vielleicht kannst du ja auch darin die eine oder andere anregung oder herausforderung für dich entdecken.

So einen hochtrabenden Schwachsinn habe ich selten gelesen....

[tch]

AW: Bilder-Beschriftung

wie gesagt, auch ich finde es weiterhin höchst vorbildlich, dass du dich hier in dieser konstruktiven weise praktisch betätigst... es ist mir nur einfach ein gewisses bedürfniss, in dieser angelegeheit einmal das spektrum der möglichen sichtweisen und positionen hier im forum ein wenig zu erweitern.

liebe grüße
martin

Hallo Martin

Stell doch bitte zum vergleichen Dein Bildbeschriftungsprogramm zur kostenlosen Verfügung.
Im direkten Vergleich kann der Ahnungslose Anwender die Vor und Nachteile des jeweiligen Programms herausfilterm.
Im Anschluss daran kann eine Umfrage gestartet werden...

tch

[deconstruct]

AW: Bilder-Beschriftung

um den umstand hervorzuheben, dass es dafür keine allgemein verfügbare geregelte definition gibt und daher jedes andere programm, das sich auf entsprechende intuitive einfühlung bzw. reverse-engeneering der gegenwärtigen funtionsweise verlässt, jederzeit durch änderungen seitens des ursprünglichen programms/herstellers etc. als hinfällig erweisen kann!

Toll, wenn du mir jetzt ein RFC oder eine ISO Norm für ein Dateiformat zeigst, dass Berge in einem Bild identifiziert, dann wäre deine Kritik berechtigt. Nur gibt es kein solches Format, also habe ich zwei Möglichkeiten:
a) Ich erstelle ein eigenes Format. Auch wenn das XML basiert ist, kann ich das Format jederzeit ändern. Die Art des Formates spielt also keine Rolle diesbezüglich.
b) Ich benutze ein bereits vorhandenes Format und interpretiere es so, dass es für die Semantik meines Programmes passt. Nur kann ich diese Interpretation auch jederzeit ändern, so dass du im Prinzip die gleichen Probleme hast wie mit einem eigenen Format.

und um hier gleich auch noch ein paar weitere details anzusprechen..

Die INI-Datei ist eine temporäre Lösung. Es war am schnellsten umsetzbar. Auch wenn dir anscheinend anderes im Kopf vorschwebt:
Ich habe nicht unendlich viel Zeit. Ich habe nebenbei noch für meinen Job was zu programmieren und soll außerdem auch noch ab und zu was für die Uni tun. Aja, und eigentlich wollte ich meine Freizeit ja auch noch irgendwie in den Bergen verbringen, zumindest hab ich da dunkel etwas im Hinterkopf, wieso wir uns hier in einem Bergforum befinden...

Nur zu deiner Information:
Ich habe auch keine Spezifikation, Entwurf, UML-Modell für das Programm gemacht. Ich habe auch keine Pflichtenhefte geschrieben und Testfälle ausimplementiert. Ich habe versucht, mit meiner begrenzten Freizeit eine schnelle Lösung für meine Problematik zu bekommen. Hätte ich auf all die von dir genannten Dinge Rücksicht genommen, dann wäre das Programm jetzt noch nicht fertig.
Dass ich dieses Programm hier ins Forum gestellt habe, war eine reine Gefälligkeit von mir, da ich weiß, dass hier sicher mehrere andere Leute das gleiche Problem mit der Beschriftung ihrer Panoramen haben. Nichts desto trotz ist das ein rein privates Programm von mir, und das Programm hat bisher keinerlei Ambitionen, in irgendeiner Weise sich zu einem Standard-Programm zur Bildbeschriftung empor zu arbeiten.

Deshalb gibt es logischerweise keine Programmversion und Format-Version in der Ini-Datei... wozu auch? Das Programm wird von gerade mal einer Handvoll Forumsbenutzer hier benutzt, von denen dies keinen interessiert. So what? Wozu der Aufwand??

man diverse probleme nicht einfach gelich von grund auf vermeiden kann, wenn man den ganz allgemein sinnvollen maßstab der interoperabilität nicht völlig aus den augen verliert.

Interoperabilität war kein Kriterium, dass ich an das Programm bis jetzt gestellt habe. Also kann ich es auch nicht aus dem Auge verlieren. Die Tatsache, dass die Daten in leicht verarbeitbarer Form für mich in einer Text-Datei vorliegen, reicht mir erstmal aus.

würde sich dein programm tatsächlich darauf konzentrieren, entsprechende zurdnungen (position des gipfels im bild, benennung, zusatzangaben...) zu erfassen und in seinen datensätzen festzuhalten, würde es sich doch meines erachtens nach geradezu aufdrängen, sich darauf zu konzentrieren, die entsprechenden -- von mir aus, an ganz spezifischen semantischen gesichtspunkten ausgerichteten -- datenstruktur in ihrer grafische entsprechung zu übersetzten.

*räusper* Die Daten sind bewußt nicht in ihrer grafischen Entsprechung gehalten, da ich diese Daten auch in anderer Form nutzen will, z.B. als Grundlage für JavaScript-Webseiten.

die das ursprüngliche vorliegende bild gar nicht erst antasten und verändern verändern müssen, sondern quasi wie eine darüber liegende transparente schicht (=overlay) zu beschriften vermögen(!), darüber hinaus aber auch in ihrer darstellung im web eine weitaus bessere optische umsetztung bieten

*nochmal räusper*
Vielleicht solltest du dir erstmal eine neue Programmversion besorgen. Der Export eines Beschriftungsoverlays im PNG Format ist längst möglich und es ist daher längt möglich, die PNG Datei als Overlay für Webseiten zu benutzen. Außerdem tastet das Programm so oder so die Original-Version des Bildes überhaupt nicht an. Das Originalbild wird NIE verändert. Es wird nur eine INI-Datei mit den Beschriftungsinformationen erstellt, auf grund derer dann ein gerendertes beschriftetes Panorama erzeugt wird oder lediglich ein PNG-Overlay.
Wenn du schon vermeintliche Fehler aufzeigen willst, dann bleib bitte auf dem Boden der Tatsachen.

trotzdem: weder will ich dich hier unnötig belehren, noch dir meine überzeugungen aufdrängen! -- ich finde es nur immer wieder recht schade, wenn derartige ganz grundsätzliche überlegungen bzw. entwicklungsmöglichkeiten in der praxis durch unnötig vereinfachenden zugangsweisen gar nicht erst als sinnvolle möglichkeit erkannt od. angedacht werden.

Ich bin mir schon bewußt, dass man vieles besser machen kann. Nur habe ich keinerlei Ambitionen, das Programm als Musterbeispiel für gelungenen Softwareentwurf zu etablieren, sondern es ist ein Lösung für eines meiner Probleme. Nicht mehr, und nicht weniger.

wobei ich durchaus nicht verschweigen möchte, dass ich natürlich auch z.b. am inkscape einiges auszusetzen habe oder für zumindest für höchst verbesserungswürdig erachte! -- nur scheint mir dort ein entsprechendes engagement zeiführender zu sein, als wenn jeder sein kleines suppchen kocht und das rad hundertmal neu erfunden wird!

Sorry, aber deine Ansichten klingen für mich wie die von jemanden, der von der Realität keine Ahnung hat. Natürlich wäre das besser. Aber bis ich mich überhaupt in Inkscape einlese und überhaupt rausgefunden habe, wie man dafür Plugins schreibt, ist mein Programm schon längst fertig. Derartiger Aufwand steht in keinem Verhältnis zu dem, was ich mit dem Programm erreichen will.
Und nochmal: Ich wollte extra kein Zeichenprogramm benutzen, sondern einfach nur ins Bild klicken, Namen, Höhe und Entfernung eingeben, und das wars.

nun -- dann würde ich dir ganz dringend an herz legen, dass du die datei:
-rw-r--r-- 1 mash mash 18009 2003-10-09 23:28 PanoLab/LICENSE
wie sie sich im
-rw-r--r-- 1 mash mash 1800896 2007-04-28 14:05 PanoLab.jar

Sorry, aber diese Datei gibt es seit rund drei Wochen nicht mehr. Die aktuelle Datei hat keine 1,8 MB sondern nur noch 700kb. Die damals verwendete Image-API ist schon längst durch die Java ImageIO Library ersetzt worden.
Wie gesagt: Besorg dir erstmal eine neue Version, bevor du mir Dinge unter die Nase reibst, die schon längst erledigt sind.

Und wie gesagt: Es steht dir ja jederzeit frei, ein Plugin für Inkscape zu schreiben, dass das ganze deinen Wünschen nach macht. Dass es du es nicht machst, zeigt mir, dass dir der Aufwand es nicht wert ist. Wieso sollte er es also mir wert sein?

[mash]

AW: Bilder-Beschriftung

lieber deconstruct,

ich danke dir natürlich für deine ausführliche reaktion und all die sachliche aufklärung bzgl. der angesprochen punkte. es geht mir ja mit meiner 'kritik' keineswegs darum, deine tatsächlichen leistungen zu mindern, sondern einfach nur deutlich herauszuarbeiten, worin sich meine persönliche unzufriedenheit mit der gegenwärtigen lösung gründet -- obwohl ich es natürlich genaus gut einfach dabei belassen könnte, still und heimlich für mich selbst zu beschließen, dieses programm gar nicht erst zu verwenden und daher alle damit verbunden debatten schlichtweg zu ignorieren.

zum gegenwärtigen format der der konfigurations-/daten-speicherung bzw. meiner charakterisierung als 'proprietäres' format:

Die .ini-Datei ist nicht proprietär, sondern plain-text und "human readable". Proprietäre Formate sind so definiert, dass sie entweder durch Patente, Lizenzen oder durch Nicht-Freigabe der Format-Definition so geschützt werden, dass sie von anderen Programmen nicht genutzt werden können. Das derzeitige Format ist aber eine fast selbsterklärende Plaintext-Datei mit einer Zeile pro Punkt, deren genauen Aufbau du gerne erklärt bekommst, falls du nicht durchsteigst.

ich spreche hier von 'proprietär' -- obwohl sich dieser gebrauch evtl. nicht wörtlich mit dem zu decken scheint, was man unter diesem stuichwort in lehr- u. gesetzbüchern od. gar im wikipädia finden mag --, um den umstand hervorzuheben, dass es dafür keine allgemein verfügbare geregelte definition gibt und daher jedes andere programm, das sich auf entsprechende intuitive einfühlung bzw. reverse-engeneering der gegenwärtigen funtionsweise verlässt, jederzeit durch änderungen seitens des ursprünglichen programms/herstellers etc. als hinfällig erweisen kann!

und um hier gleich auch noch ein paar weitere details anzusprechen, die mir beim entsprechenden studium relativ rasch ins auge gefallen sind, und möglicher weise im rahmen div. verbesserungsbemühungen berücksichtigt werden könnten, sei als anregung noch stichwortartig ergänzt:

• magic-cookies, um trotz der inflationär genutzten file-endung ".INI" eine klare zuordnung der benutzten daten zu gewährleisten.
• explizite angabe der programm- bzw. format-VERSION, um entsprechende änderungen beim einlesen berücksichtigen zu können.
• uneinheitlichkeit der delimiter ('|' vs '###') und evtl. sogar dadurch bedingte side-effects.
• nützlich wäre evtl. auch ein abspeichern der bildgröße in px-angaben, weil sich gerade das auffinden dieser werte u.u. bei späteren transformationen relativ umständlich gestalten kann.
• unter linux erfolgt das update der entsprechenden daten-änderungen offenbar tlw. erst beim schließen/beenden -- zusätzliches flush() od. close() könnte hier hilfreich sein um die entsprechenden JDK-eigeheiten auszubügeln...

trotzdem -- so schrecklich kompliziert ist das ganze im vorliegenden falle nun auch wieder nicht -- es geht mir hier vielmehr ganz prinzipiell darum, ob man diverse probleme nicht einfach gelich von grund auf vermeiden kann, wenn man den ganz allgemein sinnvollen maßstab der interoperabilität nicht völlig aus den augen verliert.

eine umstellung auf XML oder JSON bringt hier sicher gewisse vorteile mit sich, trotzdem hoffe ich, dass wir über derartige nebensächlichkeiten wirklich nicht lange streiten müssen!

was die rolle bzw. möglichkeiten und kompatibilität von SVG anbelangt, liegt die sache allerdings meiner ansicht nach nicht mehr ganz so einfach, wie du es hier darzustellst versuchst:

Die .ini-Dateien von mir SIND Vektordaten. Sie beinhalten lediglich Daten über die Position im Bild, Farbe, Drehung etc. SVG macht da prinzipiell auch nichts anderes, da stehen auch nur Koordinaten, Farben u.ä. drin. Allerdings kann man die SVG-Daten natürlich in anderen Programmen sofort weiterverarbeiten. Auf der anderen Hand fehlt SVG aber jeder semantische Bezug zu den Daten (=Position von Bergen innerhalb eines Bildes) weshalb SVG sicher nicht das Standard-Format der Speicherung werden wird, weil dann eine semantische Weiterverarbeitung der Daten (z.B. für HTML-Seiten) erschwert wird.

würde sich dein programm tatsächlich darauf konzentrieren, entsprechende zurdnungen (position des gipfels im bild, benennung, zusatzangaben...) zu erfassen und in seinen datensätzen festzuhalten, würde es sich doch meines erachtens nach geradezu aufdrängen, sich darauf zu konzentrieren, die entsprechenden -- von mir aus, an ganz spezifischen semantischen gesichtspunkten ausgerichteten -- datenstruktur in ihrer grafische entsprechung zu übersetzten. sollten die ausgangsdaten dafür tatsächlich bereits in XML-format vorliegen, ließe sich das hier vermutlich mustergültig mit einer XSL-transformation gewährleisten.

wirklich spannend bzw. auch für die praktische anwendung von interesse wird die ganze sache hier aber gerade erst deshalb, weil sich auf diesem wege beschriftungen realisieren lassen, die das ursprüngliche vorliegende bild gar nicht erst antasten und verändern verändern müssen, sondern quasi wie eine darüber liegende transparente schicht (=overlay) zu beschriften vermögen(!), darüber hinaus aber auch in ihrer darstellung im web eine weitaus bessere optische umsetztung bieten (schriften und stark kontrastierende linien müssen in einem hoch komprmierten JPEG immer unangenehm überschwingen) und -- aber, da wird's dann vermutlich den meisten wieder ein wenig zu kompliziert -- durch die verwendung von CSS den darstellungsstil (bsp. schriftgöße...) von der ursprünglichen angabe der zuordnungspunkte weitestgehend lösen und einem später leicht abzuänderndem einheitlichen web-design überantworten, darüber hinaus aber auch noch von sich aus div. scriptbasierende interaktion vorsehen!

lauter dinge also, von denen ich doch denke, dass sie ganz deutlich über jenen status quo hinausweisen, den du hier so nachdrücklich zu verteidigen versuchst.

ich halte daher SVG weniger für ein zusätzliches feature, dass man ggf. noch zusätzlich über externe konverter etc. abdecken könnte, sondern vielmehr für eine höchst interessantes arbeits- und austauschformat, dass man höchstens mit rücksichtnahme auf veraltete webbrowsere u.ä. unter umständen durch parallele ausgabe in einem traditionellen pixmap-format als fall-back-lösung ergänzen sollte, prinzipell aber als absolut ideale und zukunftsweisende basis für ein derartiges projekt verstehen könnte.

trotzdem: weder will ich dich hier unnötig belehren, noch dir meine überzeugungen aufdrängen! -- ich finde es nur immer wieder recht schade, wenn derartige ganz grundsätzliche überlegungen bzw. entwicklungsmöglichkeiten in der praxis durch unnötig vereinfachenden zugangsweisen gar nicht erst als sinnvolle möglichkeit erkannt od. angedacht werden.

Ein Plugin für eine andere Anwendung halte ich für unsinnig. Ich will ein kleines und leichtgewichtiges Tool zum Benennen von Bergen schaffen, und gerade weg, von großen Zeichenprogrammen, die für diese Aufgabe viel zu sehr mit nicht relevanten Funktionen überladen sind.

haltst es den wirklich für so viel zweckmäßiger, wenn man in dieser schonen neuen/simplen nett-2.0-welt für jede neue sich stellende aufgabe tatsächlich wieder ein neues programm benötigt und die dadurch gegeben vorgaben mehr oder weniger widerspruchslos hinzunehmen hat?

ich persönlich halte es hier wirklich für weit sinnvoller, wenn sich die leute ein klein wenig zusammenraufen und die bestehenden ansätze und frei verfügbaren produktionsmittel gemäß ihren ganz spezifischen bedürfnissen ständig noch ein klein wenig besser werden lassen!

deshalb auch mein verweis auf andere leistungsfähigere programme, die es auch für praktisch alle platformen in frei verfügbarer und einfachst zu installierenden bzw. zu erlernen versionen gibt, mit denen man durchaus auch einigermaßen effizient einen paar wörter und einen geraden strich über ein beliebiges bild drüberzusetzen vermag. (wobei ich durchaus nicht verschweigen möchte, dass ich natürlich auch z.b. am inkscape einiges auszusetzen habe oder für zumindest für höchst verbesserungswürdig erachte! -- nur scheint mir dort ein entsprechendes engagement zeiführender zu sein, als wenn jeder sein kleines suppchen kocht und das rad hundertmal neu erfunden wird!)

Ob ich die Quellen zugänglich mache, muß ich mir noch überlegen. Eine kommerzielle Nutzung des Programms ist zwar nicht angedacht und dazu ist das Programm auch noch zu unausgereift, aber ich möchte mir den Weg zumindest erstmal offen halten. Außerdem beinhaltet mein Programm keine GPL-Software. Das Aussehen der Anwendung (Tiny Look-and-Feel) steht unter der LGPL und hat keine funktionale Bedeutung, ansonsten benutzt das Programm nur die diversen Java-Frameworks von SUN selbst. Das Java ImageIO Framework steht dabei als Sonderfall unter der BSD Lizenz.

nun -- dann würde ich dir ganz dringend an herz legen, dass du die datei:

-rw-r--r-- 1 mash mash 18009 2003-10-09 23:28 PanoLab/LICENSE

wie sie sich im

-rw-r--r-- 1 mash mash 1800896 2007-04-28 14:05 PanoLab.jar

findet, dringend entfernen solltest -- um nicht versehentlich in konflikt mit irgendwelchem 'linken gesindel' zu geraten, wo man gerade in derartigen fragen relativ empfindsam zu reagieren pflegt

aber wie gesagt, auch ich finde es weiterhin höchst vorbildlich, dass du dich hier in dieser konstruktiven weise praktisch betätigst... es ist mir nur einfach ein gewisses bedürfniss, in dieser angelegeheit einmal das spektrum der möglichen sichtweisen und positionen hier im forum ein wenig zu erweitern.

liebe grüße
martin

[deconstruct]

AW: Bilder-Beschriftung

Kritik ist ja auch wichtig, daher halte ich meshs Einwürfe z.T. durchaus für legitim.

einerseits erlaubt es dein programm zwar sicher, auf den ersten blick beeindruckende resultate zu produzieren, gleichzeitig aber werden die tatsächlichen handwerklichen fragestellungen (spätere nachbearbeitung, kompatibilität, verwendung von vektor- vs. pixelformat etc.) in wahrheit nur weiter aufgeschoben und dem benutzer auch weiterhin gar nicht erst bewusst.

Nein, das tut es nicht, denn die Daten werden nicht in einem Pixelformat gespeichert, sondern sind im Moment in einer Plain-Text-Datei gesichert und können jederzeit verändert, in andere Formate etc verwandelt werden. Außerdem ist der Plan für die nächste Version eine Speicherung im XML-Format zu benutzen, was zwar prinzipiell nichts ändert, aber dafür die Weiterverarbeitung der Daten noch weiter erleichtert.
Du kannst z.B. die Daten aus der Daten-Datei nutzen, um z.B. in einer Webseite ähnlich wie bei http://www.alpen-panoramen.de/panorama.php?pid=1659 ein JavaScript einzubinden, dass die Bergnamen z.B. bei Mouseover-Events einblendet. An einem HTML-Export der solche HTML-Seiten erzeugt, arbeite ich derzeit. Es steht dir absolut frei, die Daten in ähnlicher Weise weiter zu verarbeiten. Dazu sind sie ja gerade in einem sehr einfachem Format gehalten, was durch XML noch weiter vereinfacht wird.

freie software funktioniert erfahrungsgemäß dort am besten, wo sie nicht so sehr ein geschlossenes fertiges produkt bereitstellt, sondern vielmehr das möglichst offene und reibungslose zusammenspiel verschiedener einzelprogramme und hilfsmittel im größeren arbeitsfluß begünstigt.

Ich glaube, du verkennst etwas die Intention dieses Programmes. Ich habe bisher nicht geplant, ein möglichst perfektes Programm zu erzeugen, dass allen Wünschen von allen Leuten gerecht wird, sondern der Sinn des Programms ist es, die Beschriftung von Panorama-Bildern zu erleichtern. Das tut es zumindest bei mir sehr gut, die Zeiten die ich für die Beschriftung eines Panoramas brauche, sind inzwischen um ein vielfaches geringer.
Die eingegebenen Daten sind auch nicht in einem proprietären Format verloren, sondern stehen dem Benutzer jederzeit zur Weiterverwendung zur Verfügung. Er muss sie nur in ein Format seiner Wahl konvertieren.

ich denke also, dass es auch hier vermutlich wesentlich zielführender, professionelle und befriedigender erscheinen könnte, wenn du statt irgendwelcher properitären .ini-dateien und fertig gerenderte bildausgaben, die daten auch in weiterverabeitbaren formaten (SVG rausgekürzt a.d.V) bereitstellen könntest!

Zunächst einmal:
Die .ini-Datei ist nicht proprietär, sondern plain-text und "human readable". Proprietäre Formate sind so definiert, dass sie entweder durch Patente, Lizenzen oder durch Nicht-Freigabe der Format-Definition so geschützt werden, dass sie von anderen Programmen nicht genutzt werden können. Das derzeitige Format ist aber eine fast selbsterklärende Plaintext-Datei mit einer Zeile pro Punkt, deren genauen Aufbau du gerne erklärt bekommst, falls du nicht durchsteigst.
Und natürlich ist eine Ausgabe als gerendertes Bild nötig, schließlich will ich das Ergebnis auch mal ansehen und nicht nur weiterverarbeiten und auch an andere Personen weitergeben. Dazu ist JPEG nunmal das Format der Wahl, da es jeder lesen kann und die Dateigrößen überschaubar bleiben.

-- bsp. SVG basierenden vektor-grafiken --

Natürlich ist ein SVG-Export eine nette Sache. Aber ich habe nunmal nur begrenzt Zeit und ich selbst benötige ihn derzeit nicht, weshalb das Programm deshalb derzeit auch keinen SVG-Export kann. Prinzipiell wäre ein SVG-Export aber eine gute Idee, da stimme ich dir zu, v.a. in Anbetracht der Anfrage bezüglich der Eintragung von Routen.
Allerdings: Dies ist eine Wunsch, der bis dato nur von einer Person geäußert wurde. Wenn viele Leute einen SVG Export möchten, dann kann man sowas sicher einbauen. Wegen einer Person werde ich dies aber nicht machen, denn dazu habe ich schlicht und einfach zu wenig Zeit, da ich den SVG-Export selbst nicht benötige.

(ich glaube, ich habe hier im forum schon einmal vor sehr langer zeit ausführlich zu erklären versucht, warum es in diesem falle wirklich sinn machen dürfte, zwischen bild- und vektorgrafik bzw. entsprechenen bearbeitungsschritten und austauschformaten zu unterscheiden!)

Die .ini-Dateien von mir SIND Vektordaten. Sie beinhalten lediglich Daten über die Position im Bild, Farbe, Drehung etc. SVG macht da prinzipiell auch nichts anderes, da stehen auch nur Koordinaten, Farben u.ä. drin. Allerdings kann man die SVG-Daten natürlich in anderen Programmen sofort weiterverarbeiten. Auf der anderen Hand fehlt SVG aber jeder semantische Bezug zu den Daten (=Position von Bergen innerhalb eines Bildes) weshalb SVG sicher nicht das Standard-Format der Speicherung werden wird, weil dann eine semantische Weiterverarbeitung der Daten (z.B. für HTML-Seiten) erschwert wird.

deshalb würde ich es fast lieber sehen, wenn das ganze viel eher als plugin/extension/macro in einem zu diesem zweck geschaffenen framework angelegt worden worden wäre od. wenigstens eine sanfte heranführung an die damit verbunden handwerkliche mittel befördern könnte.

Ein Plugin/Extension zu einer bestehenden Anwendung lebt und stirbt aber dann eben mit dieser. Dadurch beseitig man die Probleme ja nicht, sondern im Gegenteil schafft man neue, da dann alle Nutzer sich dieses Programm anschaffen müssten. Und weder ich (noch der große Rest der User AFAIK) wollen hier ein Zeichenprogramm mit Plugin benutzen. Der Sinn von PanoLab ist ja gerade, dass man zur Panorama-Beschrifung eben KEIN solches Programm mehr braucht, sondern einfach mit wenigen Klicks ein Panorama innerhalb von kürzester Zeit beschriften kann.

naja -- und über die umsetztung in java bzw. die damit verbunden unnötige ressourcenverschwendung, könnte ich hier vielleicht auch noch ein klein wenig mitleid heucheln -- aber damit würde das ganze vermutlich entgültig zu sehr ins technokratische abdriften...

Lol, sorry, aber das ist totaler Unsinn. Java ist nicht resourcenverschwenderischer als C# oder ähnliche Sprachen. Jeder Performance-Vergleich von Algorithmen zeigt dies. Mit PanoLab bearbeite ich Panoramen mit mehr als 40 Megapixeln (z.T. bis zu 20000x3000px), und das ohne dass beim Scrollen des Bildes was ruckelt und ohne dass ich bei der Entwicklung überhaupt auf hohe Performance bisher Wert gelegt habe. Da ist sicher noch einiges verbesserbar, nur besteht dafür kein Bedarf, da das Programm schnell genug läuft.
Ich kenne dagegen dutzende ImageViewer, die alle nativ laufen, die bei solchen Bildgrößen absolut in die Knie gehen und um ein mehrfaches langsamer sind. Und diese ImageViewer sind nicht in Java geschrieben! Wäre Java so langsam, würde es auch in der J2EE-Sparte kaum solche Erfolge feiern, v.a. im hoch skalierbaren und anspruchsvollem Bereich.
Besides: Java ist - egal was man davon hält - für diese Aufgabenstellung mehr als ausreichend performant. Also ist die Performanz für diese Aufgabenstellung ohnehin kein Entscheidungsgrund für oder gegen eine Programmiersprache, sondern eher so Dinge wie Wartbarkeit, Entwicklungszeit, Umgang mit Bilddaten usw. Und da schneidet Java im Gegensatz zu vielen anderen Sprachen deutlich besser ab.

trotzdem finde ich es natürlich weiterhin äußerst toll von dir, dass du dir überhaupt die mühe machst, einen entsprechenden gestalterischen versuch in die welt zu setzten! ich würde es sogar begrüßen, wenn du in diesem sinne auch die quellen deines programms regelmäßig zugänglich machen könntest -- schließlich enthält ja das ausführbare programm, so weit ich es von außen durchleuchten kann, ohnehin ein reiches maß an GPL und LGPL lizensierten komponenten.

Ob ich die Quellen zugänglich mache, muß ich mir noch überlegen. Eine kommerzielle Nutzung des Programms ist zwar nicht angedacht und dazu ist das Programm auch noch zu unausgereift, aber ich möchte mir den Weg zumindest erstmal offen halten. Außerdem beinhaltet mein Programm keine GPL-Software. Das Aussehen der Anwendung (Tiny Look-and-Feel) steht unter der LGPL und hat keine funktionale Bedeutung, ansonsten benutzt das Programm nur die diversen Java-Frameworks von SUN selbst. Das Java ImageIO Framework steht dabei als Sonderfall unter der BSD Lizenz.

Desweiteren ist mein Programm kein "gestalterischer Versuch", sondern das Programm setze ich "produktiv" ein, will heißen ich habe damit schon dutzende Panoramen beschriftet und das deutlich schneller, als mit der bisherigen Methode über Bildbarbeitungs- oder Vektorzeichenprogramme. Damit habe ich mein primäres Ziel erreicht, alles andere ist jetzt eigentlich for fun.

Im Gegenteil frage ich jetzt dich:
Wenn dir soviel an einem SVG-Export liegt, wieso schreibst du nicht einfach einen Konverter, der aus der INI-Datei eine SVG-Datei erzeugt. Damit wäre das Problem der Weiterverarbeitbarkeit in Vektorzeichenprogrammen ja auch gelöst... Du musst das auch nicht mal in Java schreiben und das Format der INI-Datei kann ich dir bei Fragen auch bis ins Detail erklären.

ich hoffe, du nimmst mir diese nicht ganz so forums-konformen worte hier nicht all zu übel -- vielleicht kannst du ja auch darin die eine oder andere anregung oder herausforderung für dich entdecken.

Ich nehme dir deine Worte überhaupt nicht übel, kann dir aber nur bedingt zustimmen

Zusammenfassend:

- Die INI-Datei ist nicht proprietär, sondern offen und sogar "human-readable".

- Eine Weiterverarbeitung - egal wozu - steht jedem offen. Eine Konvertierung der INI-Datei in das SVG-Format sollte nicht besonders problematisch sein. Da könntest du zur Abwechslung ja sogar selbst ein Tool dafür schreiben.

- Ein Plugin für eine andere Anwendung halte ich für unsinnig. Ich will ein kleines und leichtgewichtiges Tool zum Benennen von Bergen schaffen, und gerade weg, von großen Zeichenprogrammen, die für diese Aufgabe viel zu sehr mit nicht relevanten Funktionen überladen sind.

- Der Export in SVG ist trotzdem eine gute Idee. Wenn ich die Zeit finde, werde ich einen SVG-Export sicher einbauen. Wann das ist, kann ich allerdings nicht sagen. In erster Linie stelle ich jetzt erstmal den XML-Export fertig, den ich dann für die Erzeugung von HTML-Seiten der Panoramen benutze. Dass man das dann kann, zeigt ja allein schon die Weiterverarbeitbarkeit der Daten.

- Java ist für mich persönlich die geeigneteste Sprache, das Programm zu schreiben. Es ist absolut ausreichend performant für die Anforderung die das Programm hat und es lässt sich schnell entwickeln. Zudem kann ich es sowohl auf meinem Mac und auch unter Linux betreiben, was für mich zwei sehr wichtige Punkte sind, da ich viel unter diesen Systemen arbeite. Und merke: Es gibt keine Programmiersprache, die für alle Zwecke geschaffen ist. Für diesen Zweck erfüllt Java alles, was ich benötige. Ein 3D-Spiel würde ich dagegen nicht in Java schreiben. Java-Flames kannst du gerne in einschlägigen Foren führen, wenn du daran Spaß hast.

[strauchdieb]

AW: Bilder-Beschriftung

Hallo mash,

wie du ja richtig erkannt hast, bewegen wir uns hier in einem Alpin-Forum. Nicht in einem für Software-Entwickler. Das schließt nicht aus, dass es solche hier gibt. Aber ....

Wenn du der Meinung bist, dass Computeranweder zum bewußten Umgang mit Arbeitstechniken etc. erzogen werden sollten, dann geht das schlicht und ergreifend an den Bedürfnissen der User vorbei. Genausowenig wie die Masse der Autofahrer an ihrem Vehikel herumschraubt (das überlässt unsereins besser jemandem, der sich mit sowas auskennt), will die Masse der EDV-User zum 'bewußten Umgang' damit erzogen werden. Klar sind wir Konsumenten. Was ist daran verwerflich? Den "bewußten" und "aufgeklärten" Konsumenten wünscht sich so mancher, mindestens genausoviele fürchten ihn. Ihn aber zu fordern, halte ich für schlichtweg elitär.


Dass alles anders und besser gemacht werden kann: Natürlich. Dass im nachhinein oftmals ein anderer Weg der bessere gewesen wäre: Alltäglich. Dass es einfacher ist Kritik zu üben, als es selber besser zu machen: Der Vorwurf an jeden Kritiker.

Die Lösung von deconstruct als "Versuch" abzuqualifizieren ("Trotzdem finde ich es (...) dass du dir überhaupt die Mühe machst (...)" - das wäre in Schulnoten ausgesprochen sowas wie mangelhaft = 5 ("Hat sich bemüht"), halte ich jedoch für absolut unangemessen. Sorry - aber die Aussagen der User sind doch wohl eindeutig. Und das ist es, was zählt!

Gruß, Strauchdieb

[derpeter]

AW: Bilder-Beschriftung

Also erst mal viele dank für die kleine Einführung, ich denke ich werde mal ne Nacht opfern und mich mit dem Programm auseinander setzten (Turorials gibts ja genug im Netz).

Die Sache mit dem Pfad müßte doch eigentlich relativ einfach zu lösen sein. Ich beziehe mich jetzt zwar auf Flash (in Fortran ist das ähnlich) aber ich denke von der Logik her ist das das gleiche. Einfach zwei Buttons erstellen die jeweils die Zeichenfunktion "ein" bzw. "aus" schalten. Die Zeichenfunktion läuft ja wahrscheinlich in einer Schleife ab, die könnte man doch dann so wieder unterbrechen.


Die "Kritik" (sofern das als solche gemeint war) vom Vorredner kann ich nicht ganz verstehen, schließlich ist hier ein Programm entworfen worden, was vieles erleichtert. Normalerweise werden solche Sachen, umständlich mit einem Grafikprogramm gelöst...d.h. jede Linie von Hand zeichnen, Texte eingeben und alles ausrichten....ich finde das dieses Programm einem einiges an Arbeit abnimmt

[mash]

AW: Bilder-Beschriftung

ich möchte hier einmal eine etwas andere sicht der dinge vertreten -- und sei es vielleicht auch nur, weil ich aus anderen foren, in denen entwickler entsprechender freier software gemeinsam an ihren ideen arbeiten, einen weitaus rauheren, letztlich aber doch 'kritisch-konstruktiven' umgang mit derartigen ansätzen gewohnt bin.

um es kurz zu machen: ich halte den gewählten umsetzungsweg in vielerlei hinsicht für eine relativ problematische 'einbahnstraße' -- od., mit ganz böser zunge gesprochen: so etwas wie einen in software gegossenen 'klettersteig'

einerseits erlaubt es dein programm zwar sicher, auf den ersten blick beeindruckende resultate zu produzieren, gleichzeitig aber werden die tatsächlichen handwerklichen fragestellungen (spätere nachbearbeitung, kompatibilität, verwendung von vektor- vs. pixelformat etc.) in wahrheit nur weiter aufgeschoben und dem benutzer auch weiterhin gar nicht erst bewusst.

wie problematisch sich derartige entwicklungen äußern können, ist ja sicher auch dir nicht unbekannt -- schließlich kennt jeder von uns diesen typus des computeranwenders, der vermutlich auch zur beschriftung von panoramabildern mit größter selbstverständlichkeit wieder auf das ihm vertraute ms-word zurückgreift und alleine dort sein glück versucht (ja, ich bin mir wirklich sicher, dass man selbst damit im gegegeben anwendungsfall mit dem nötigen maß an kaltblütigkeit subjektiv 'befriedigende' resultate zusammenzubringen vermag!)

also -- um wieder ein wenig auf den konstruktiven boden entsprechender kritik zurückzukommen --, in einigen punkten glaube ich doch, dass du dein programm wirklich grundsätzlich anders ausrichten/gestalten solltest.

freie software funktioniert erfahrungsgemäß dort am besten, wo sie nicht so sehr ein geschlossenes fertiges produkt bereitstellt, sondern vielmehr das möglichst offene und reibungslose zusammenspiel verschiedener einzelprogramme und hilfsmittel im größeren arbeitsfluß begünstigt. ich denke also, dass es auch hier vermutlich wesentlich zielführender, professionelle und befriedigender erscheinen könnte, wenn du statt irgendwelcher properitären .ini-dateien und fertig gerenderte bildausgaben, die daten auch in weiterverabeitbaren formaten -- bsp. SVG basierenden vektor-grafiken -- bereitstellen könntest!

(ich glaube, ich habe hier im forum schon einmal vor sehr langer zeit ausführlich zu erklären versucht, warum es in diesem falle wirklich sinn machen dürfte, zwischen bild- und vektorgrafik bzw. entsprechenen bearbeitungsschritten und austauschformaten zu unterscheiden!)

ich persönlich würde ja fast noch ein wenig weiter gehen, und schlichtweg behaupten, dass es oftmals zweckmäßiger sein kann, computeranwender zu einem bewussten umgang mit geigeneten werkzeugen bzw. arbeitstechniken zu erziehen, statt letztlich doch nur wieder den kurzsichtigen konsum entsprechender oberflächlicher hilfestellungen bzw. tendenziellen aufschub zu befördern. wenn hier nun plötzlich bspw. das ersuchen an dich herangetragen wird, auch wege-skizzen etc. mit deinem programm zu bewerkstelligen, werte ich das eindeutig als indikator für genau diese problematik. würdest du nämlich all diesen wünschen tatsächlich nachzukommen versuchen, dürfte sich vermutlich sehr bald schon herausstellen, dass sich dein programm immer mehr einem der ohnehin bereits verfügbaren grafikprogramme a la inkscape etc. anzunähern beginnt. deshalb würde ich es fast lieber sehen, wenn das ganze viel eher als plugin/extension/macro in einem zu diesem zweck geschaffenen framework angelegt worden worden wäre od. wenigstens eine sanfte heranführung an die damit verbunden handwerkliche mittel befördern könnte.

naja -- und über die umsetztung in java bzw. die damit verbunden unnötige ressourcenverschwendung, könnte ich hier vielleicht auch noch ein klein wenig mitleid heucheln -- aber damit würde das ganze vermutlich entgültig zu sehr ins technokratische abdriften...

trotzdem finde ich es natürlich weiterhin äußerst toll von dir, dass du dir überhaupt die mühe machst, einen entsprechenden gestalterischen versuch in die welt zu setzten! ich würde es sogar begrüßen, wenn du in diesem sinne auch die quellen deines programms regelmäßig zugänglich machen könntest -- schließlich enthält ja das ausführbare programm, so weit ich es von außen durchleuchten kann, ohnehin ein reiches maß an GPL und LGPL lizensierten komponenten.

ich hoffe, du nimmst mir diese nicht ganz so forums-konformen worte hier nicht all zu übel -- vielleicht kannst du ja auch darin die eine oder andere anregung oder herausforderung für dich entdecken.

[geofix]

AW: Bilder-Beschriftung

Wie immer: Vielen Dank für das ganze Lob
Ich vermute den Fehler nämlich nun eher in der Webstart-Konfiguration, vielleicht sogar bei mir auf dem Server. Ich hab mit Webstart noch nicht soviel gemacht, daher kann es gut sein, dass ich da was übersehen habe.

herzlichen Dank Deconstruct für den spezial support - es läuft super
hier in diesem forum können alle stolz sein auf leute wie dich- hut ab
lg geo

ideale anwendung auch für schweren rateberg :-)

beschrift_test.jpg

[deconstruct]

AW: Bilder-Beschriftung

Ist das Programm leicht zu bedienen, evtl. durch drag and drop von Objekten steuerbar oder muß ich alles von Hand aus programmieren (kenne das nur von C her, da mußte man alles selber eingeben).

Das Programm ist IMO schon sehr einfach zu bedienen, aber das sage ich halt aus der Sicht von jemandem, der weiß, wie Entwicklungsumgebungen normalerweise funktionieren
Für jemanden ohne Programmierkenntnisse in einer objektorientierten Programmiersprache ist es wahrscheinlich eher schwierig, aber nicht, weil Eclipse so schwierig ist, sondern weil einem einfach die Kentnisse fehlen, mit den ganzen Begriffen und Funktionen umzugehen.

Zur Bedienung ganz kurz:
Ich schreibe im Prinzip alles mit der Hand, wobei man dadurch durch die Code-Vervollständigung u.ä. Tools sehr stark unterstützt wird und man nicht die Eigenschaften aller Objekte und Klassen auswendig kennen muss. Es reicht, einen gewissen Überblick zu haben. Wichtig ist IMO v.a. dass man weiß, wie eine objektorientierte Sprache funktioniert.
Einfach nur ein bißchen rumklicken und dann hat man ein Programm, das funktioniert nicht, dazu ist Software viel zu komplex. Wenn man sich aber ein gewisses Grundwissen aneignet, dann kann man mit Eclipse sehr leicht einfache Programme erstellen. Als Einstieg wäre da erst mal eine vernünftige Lektüre das geeignetste, z.B. das freie Buch "Java ist auch eine Insel". Das kann man sich frei herunterladen und ist verständlich und gut geschrieben. Damit lernt man erstmal das Objektorientierte Programmierkonzept kennen und dessen Umsetzung durch Java (Syntax sowie Java-Framework). Eclipse beinhaltet darüber hinaus einfache Tutorials für "Hello-World-Anwendungen", wo man Schritt für Schritt sieht, wie man ein Hello-World-Programm mit Eclipse erstellt.

Aber wie gesagt: Es ist schon mit einem gewissen Aufwand verbunden, wenn man Programmieren erst mal erlernen will. Für jemanden der bereits objektorientiert mit einer IDE programmiert hat (z.B. C# mit VisualStudio) für den ist das Einarbeiten in Eclipse in ein Kinderspiel.

Zur Programmierung der Oberfläche bietet Eclipse auch OberflächenDesigner an, allerdings stoßen diese wie bei jeder Entwicklungsumgebung ab einer bestimmten Komplexität an ihre Grenzen, so dass man doch am Ende mehr per Hand schreibt, als mit dem Oberflächen-Designer "malt". Und: Ein Oberflächendesigner erstellt ja nur die Oberfläche, sprich Buttons u.ä. Aber dier Funktionalität der Software muss man logischerweise auch da per Hand programmieren.

Fazit: wie lange braucht ein Gelegenheitsprogrammierer um sich dort einzuarbeiten oder macht das keinen Sinn für mich ?

Das kann man so pauschal nicht sagen. Das hängt wie gesagt von deinen Vorkenntnissen ab. Jemand, der z.B. schon mit C# programmiert hat, findet sich vielleicht schon innerhalb weniger Stunden zurecht. Jemand der sich auch Grundwissen erst aneignen muss, der braucht wahrscheinlich 2-3 Wochen, bis er einigermaßen soweit ist, dass er ein Programm mit einer gewissen Komplexität schreiben kann.
Ob das Sinn macht, hängt ebenfalls von dir ab, ob dir der Aufwand, etwas Neues zu erlernen, es wert ist.

Die Sache mit dem Verbesserungsvorschlag: ich stelle mir das so vor wie z.B. bei google-earth, wo man einen Pfad erstellen kann.

Das Erstellen wäre nicht das Problem. Da würd ich oben ein Pfad-Icon reinmachen, und wenn man da draufklickt, könnte man den Pfad zeichnen, in dem ein Linksklick ins Bild z.B. einen Pfad-Punkt setzt.
Aber wie komme ich aus dem "Pfad-Modus" raus, wenn ich dann z.B. einen Berg benennen will. Da muss ich ja auch ins Bild reinklicken. Diese Details sind das schwierige. Bei Google-Earth ist das ja so gelöst das ein Fenster eingeblendet wird, wo der Name des Pfades drin steht. Erst durch schließen dieses Fensters kommt man aus dem Pfad-Modus raus. Allerdings finde ich diese Lösung ehrlich gesagt eher unschön, weil das Pfad-Fenster ständig auch die Karte verdeckt.

[derpeter]

AW: Bilder-Beschriftung

ich geh mal davon aus das du in Sachen Programmierung recht fit bist. Ich habe zwar html und Flash Kenntnisse und auch C habe ich beim Studium für ein Semester gehabt (sowie Fortran), das liegt aber schon etwas weiter zurück.

Ist das Programm leicht zu bedienen, evtl. durch drag and drop von Objekten steuerbar oder muß ich alles von Hand aus programmieren (kenne das nur von C her, da mußte man alles selber eingeben).

Fazit: wie lange braucht ein Gelegenheitsprogrammierer um sich dort einzuarbeiten oder macht das keinen Sinn für mich ?


Die Sache mit dem Verbesserungsvorschlag: ich stelle mir das so vor wie z.B. bei google-earth, wo man einen Pfad erstellen kann.

[deconstruct]

AW: Bilder-Beschriftung

Als Anregung:
evtl. wäre das Einzeichnen von einer Tour möglich, anstatt der Gipfel könnte man so den Wegverlauf einer begangenen Tour so ebenfalls einzeichnen und Beschriften.

Gute Idee. Muss ich mal schauen, wie ich das umsetzen könnte und wie man es v.a. bedientechnisch ins Programm einbaut. Schwebt dir da schon ein Bedienkonzept vor? Ein interessantes Feature wäre es schon.

Mit welcher Entwicklungsumgebung hast du das Programm eigentlich erstellt ? Ich hätte da auch ein paar Ideen die ich so oder ähnlich gerne umsetzten würde.

Mit Eclipse. Das ist eine freie und kostenlose Entwicklungsumgebung, die zwar primär auf Java ausgerichtet ist, die man aber auch für einige andere Sprachen benutzen kann. Ich selbst nutze es z.B. auch für PHP, HTML und XML-Dokumente, da es eine super Codevervollständigung und Fehlerprüfung dafür hat. Für Java ist es IMO die derzeit mit Abstand beste Entwicklungsumgebung, noch weit vor sämtlicher kommerzieller Konkurrenz. Vor allem gibt es soviele Plugins für Eclipse (WebDAV, CVS, SVN, Tomcat, JUnit, UML, XML/HTML-Tools, etc...) die noch dazu super gut in Eclipse mit integriert sind.

Verbesserungsvorschläge: ... öhmm... vielleicht sounds in Abhängigkeit von der eingegeben Höhe korrelierend mit der aktuellen Hitparade.

Ich werd darüber nachdenken

[deconstruct]

AW: Bilder-Beschriftung

Wie immer: Vielen Dank für das ganze Lob

danke - hat auch nicht geholfen, irgendwie findet das panolab die java umgebung bei mir nicht, andere applicationen tun dies aber sehr wohl

Schick mir mal deine eMail-Adresse als PN. Ich schicke dir dann eine spezielle Version des Programms, wo man sehen kann, an was es liegen könnte. Vielleicht gehts mit der anderen Version dann auch gleich

Ich vermute den Fehler nämlich nun eher in der Webstart-Konfiguration, vielleicht sogar bei mir auf dem Server. Ich hab mit Webstart noch nicht soviel gemacht, daher kann es gut sein, dass ich da was übersehen habe.

[derpeter]

AW: Bilder-Beschriftung

ich hatte mal Probleme mit Java-Anwendungen im Internet, evtl. hilft ja eine eine Standart-Zurückstellung des IE.

[geofix]

AW: Bilder-Beschriftung

wenns dann immer noch nicht geht auf java 1.5 runter bei anderen anwendungen funktioniert es mit java 1.6 auch nicht.

danke - hat auch nicht geholfen, irgendwie findet das panolab die java umgebung bei mir nicht, andere applicationen tun dies aber sehr wohl