Aktuelle Entwicklung GTA.NET 4.5.1.7

Zitat von blackwilli

Hmmm ..

Eigentlich hätte ich richtig schreiben müssen:

"Die Version ist für Euch noch nicht verfügbar! - Bei mir läuft es ja schon.

Ist das jetzt ein Aufruf zur Online-Durchsuchung deiner Festplatte..

Gruss Joern Weber

Zitat von Joern_Weber

Ist das jetzt ein Aufruf zur Online-Durchsuchung deiner Festplatte..

Gruss Joern Weber

Nix da. Ich wohne doch nicht in Bayern.

Startbeitrag #1 aktualisiert.

Zitat von blackwilli

Startbeitrag #1 aktualisiert.

Fast dieselbe Feature-Spannung wie beim Garmin Colorado!
Wie ich dich kenne, Dietmar, wirst du die letzten 3 Worte im ersten Satz deines Ausgangspostings in einer Nacht und Nebel Aktion heimlich rausnehmen, damit es deinen Server nicht zerreißt, sondern die aufmerksameren Leser so nach und nach zum runterladen beginnen.

Ich bin neugierig, wer dann als erster sich nicht beherrschen kann, und hier in dicken roten Lettern postet: "Es ist verfügbar!"

LG, bp

Zitat von blackpanther

...letzten 3 Worte...

Hoffentlich entfernt er nur die beiden Worte vor dem letzten.....^_^

Zitat von blackpanther

... wirst du die letzten 3 Worte im ersten Satz deines Ausgangspostings in einer Nacht und Nebel Aktion heimlich rausnehmen, damit es deinen Server nicht zerreißt, .....

Na ja, sooo schlimm wird es nicht kommen.
GTA hat natürlich gerade hier im Board eine recht große und vor allem treue Fangemeinde, aber bei mittlerweile 30.000 Downloads von .NET und geschätzten 10.000-15.000 Usern weltweit, relativiert sich das wieder etwas. Und bis die User in Kanada oder Australien das mit bekommen ....

So, jetzt hab' ich mal wieder ein Problem und hatte die letzten Tage schon mehrmals diesen Zustand:

Es wurde da mal der Wunsch geäußert, dass es eigentlich möglich sein sollte, die Einstellungen im Exportfenster z.B. für ein Projekt komplett zu speichern, um nicht alle Einstellungen und Auswahlen wieder vornehmen zu müssen, wenn man das Projekt noch mal etwas überarbeiten will.

Grundsätzlich nicht verkehrt, nur werden schon sämtliche Export-Einstellungen von der Anwendung selbst gesichert und verwaltet, halt nicht trackbezogen.
Und da ist das Problem, ein Zugriff auf die Einstellungen von zwei Seiten aus wird zu Problemen führen. Und ein Entfernen der autom. Verwaltung durch die Anwendung, kann ich den anderen Usern nicht unterjubeln, die nur komplette Projekte exportieren.

Wie wird das allgemein gesehen?
Wie groß ist der Nutzen eines solchen Features?
Was sollte man beim Export in einer Config ablegen?
Dateibezogen oder sogar trackbezogen?

Ich mache erst mal eine Denkpause.

Da ich mich darauf speziell Freue...

Also für mich gibts da zwei Dinge:

• Eine Art Vorlage: Ich kann mir bspw. eine Einstellungsvorlag abspeichern für html-Exporte, die zur Seite x passen. Bei einem neuen Track lade ich einfach dies Vorlage und mache noch ein paar wenige Einstellungen, wie Namen, Pfad und ähnliches. Dann natürlich die ganzen Fotos, etc. Und nach dem Export kommt...
• Ich kann die ganzen Einstellungen Abspeichern, so wie das ganze Exportiert wurde. Dann also mit der genauen Auswahl der Fotos, etc. Denn in GTA.net verwalte ich alle gemachten Fotos Trackbezogen. Auf die Homepage kommt aber nur eine bestimmte Auswahl. Und diese müssen dann in der GE-Datei verlinkt werden.

Und das ganze sollte nicht nur ein mal pro Track möglich sein. Denn theoretisch ist es möglich ein und den selben Track für verschiedene Anwendungen aufzubereiten (unterschiedliche Homepages, unterschiedlich GE-Projekte, MS).

Noch mal aus einer anderen Richtung betrachtet: Die Aufbereitung des Tracks in GTA.net sollte wie bis an hin möglich und abspeicherbar bleiben. Damit Verwalte ich den Track oder das Trackprojekt. Die oben beschriebenen Dinge betreffen dann die möglichen Exports (bewusst Mehrzahl!) die mit diesem Track gemacht werden können. Vorlagen also für die unterschiedlichen Export-Sets nach meinem Gusto. Und dann die Einstellungen wie Exportiert wurde.

Ein Beispiel: Will ich das Layout für meine Homepage anpassen, kann ich heute dank der eigenen http-Vorlage sehr einfach auch die Exports anpassen. Jedoch muss ich dann ja auch jeden Track erneut exportieren. Die zum Track exportierten Fotos muss ich aber mühsam heraussuchen und wieder einzeln einbinden... Gäbe es nun die Möglichkeit den Export (resp. die Einstellungen) zurück zu laden, wäre die Anpassung nur noch eine Frage der Zeit die für die Generierung des Exports benötigt wird. Das ganze gilt auch, wenn ich später ein Foto zum Export hinzufügen möchte, oder eines rausnehmen möchte... Letzten Export laden, Hacken rein oder raus, erneut exportieren und fertig. Und wenn dann ein neuer Track hinzukommt: Track aufbereiten, Exportvorlage laden, trackbezogene Einstellungen vornehmen, exportieren, und Exporteinstellungen speichern. Und schon ist bspw. meine Homepage mit einem Track mehr ausgestattet und das beste es sieht alles einheitlich aus!

Unterm Strich müssen also sicher alle Einstellungen der drei Register unter Export in der Vorlage rein, die nicht wirklich trackbezogen sind (Namen und ähnliches). Sehe im Moment keine Einstellungen, die noch von wo anders mit einbezogen werden müssten. Das würde für mich zu einer erneuten Bearbeitung des Tracks und damit einem neuen Projekt führen.

Für mich ist es klar, aber vielleicht habe ich mich zu kompliziert ausgedrückt... Ich weis Du bekommst das hin, denn Du bist einfach genial. Und darauf warte ich gerne noch zwei Wochen, dafür ist das dann drinn.

Hallo,

und wer schreibt nachher das 1000-seitige "Fucking Manual" für die eierlegende Wollmilchsau?

Gruß Jürgen

@ webGandalf:[Blockierte Grafik: http://www.hardcoreboard.org/images/smilies/schilder/bahnhof.gif]

Dieter,
wenn ich mal in das Hemd eines Programmierers schlüpfen darf: Ich versuche immer, jene Dinge zu realisieren, die den meisten Funktionalitätsgewinn mit dem wenigsten Aufwand bringen.

Wenn ich mir deine Wünsche oben durchlese:

Wie wäre es, wenn man alle Einstellungen im Exportfenster (aber nur aus dem aktiven Export-Tab) in dem Moment in einer eigenen Konfigurationsdatei abspeichern würde, in dem das Export durchgeführt wird ?
Dann bräuchte sich der User selbst nicht um die Sicherung der Config kümmern.
Als Namen der Config könnte man den Namen des Tracks nehmen plus einen Bindestrich plus der Bezeichnung des Export-Typs, als Extension könnte man "xml" nehmen und das Ganze auch als XML Format speichern.
Also wenn z.B. ein "test.kml" exportiert wird, gäbe es auch automatisch ein "test-kml.xml" mit allen Einstellungen, bei mapsource ein "test-mapsource.xml", und bei Projekt/ordner ein "test-html.xml" (weil letzteres Export ja meistens Richtung Web-Seiten geht).

Wenn man nun einen neuen oder aber auch einen bereits vorher exportierten GPX oder GTABIN Track öffnet, könnte man im Exportfenster einen Button einführen mit "Vorlage laden", wo man dann als Auswahl alle bisher generierten xml-Vorlagen bekommt.
Nun kann man eine beliebige Vorlage auswählen, und diese wird auf den geöffneten Track angewandt, egal ob dieser schon mal exportiert wurde oder nicht, und das Exportfenster wird auch gleich auf den richtigen Tab geschalten (z.B. auf den Google Earth Tab beim laden eines z.B. "test-kml.xml" files).

Das heißt, man hätte die Möglichkeit, für jeden Export-Typ beliebig viele Config-Files anzulegen, egal ob vom selben Track ausgehend oder von verschiedenen, und man könnte auch für jeden Track beliebige Exportvorlagen laden.

Das Tool sollte nur eine Warnung ausgeben, wenn es einen Vorlagenfile schon gibt (also wenn z.B. ein neuer Track eingelesen wird, und dieser soll wieder als "test.kml" exportiert werden, soll man vor dem Überschreiben der "test-kml.xml" gewarnt werden und mit Ja oder Nein antworten können).

Ich glaub das wäre für Dietmar zu realisieren, und würde deine Anforderungen abdecken, wenn ich dich richtig verstanden habe.
Es wäre auch glaube ich für den Endanwender von der Logik her leicht zu verstehen, wenn er das Ganze mal vor sich sieht.

@Dietmar: Ich trau mich sowas übrigens nur vorschlagen, weil du nach Vorschlägen gefragt hast, sonst würd ich mich vor der Peitsche fürchten, wegen der doch vielen Arbeit, die damit verbunden ist.:)

LG, bp

Ist ja egal was Du verstehts, hauptsache blackwilli versteht. Wenns dann im Progi drin ist, dann kommst auch Du nach und findest es gut...

Hallo plackpanter

Du bist auf der richtigen Schiene. Irgenwie so stelle ich mir das vor

Schönen Abend noch

Zitat von webGandalf

Ist ja egal was Du verstehts, hauptsache blackwilli versteht. Wenns dann im Progi drin ist, dann kommst auch Du nach und findest es gut...

Ich schäme mich ja auch, ob meiner Schlichtheit....[Blockierte Grafik: http://www.hardcoreboard.org/images/smilies/schilder/doof.gif]


Nichsdestotrotz....[Blockierte Grafik: http://www.hardcoreboard.org/images/smilies/normale/bingespannt.gif]

@Dieter

das habe ich befürchtet, dass Du das tatsächlich so meintest.

Zitat

Ich weis Du bekommst das hin, denn Du bist einfach genial.

So schleimt man sich ein. :p

Zitat

Und darauf warte ich gerne noch zwei Wochen, dafür ist das dann drinn.

Zwei Wochen warten ist ja auch nicht so schlimm ....
Wenn die neue Version deswegen jetzt aber erst im September kommt, dann weist Du ja, was da auf Dich zukommt ....

@blackpanther

Du hast das Scenario ziemlich gut beschrieben. So in der Art habe ich mir das auch schon überlegt gehabt. Nur tendiere ich eher dahin,

• ... für jeden Track eine config zu erstellen, die alle Exporteinstellungen aller drei Register beinhaltet,
• ... diese configs autom. beim Exportieren im gleichen Ordner erstellt werden, in dem die Trackdatei liegt,
• ... die passende config autom. geladen wird, wenn auf Export gegangen wird.

Die Grundeinstellungen in den Exportregistern werden ja schon in der Anwendungsconfig verwaltet und können so weiterhin für alle ihren Dienst tun, die dies Feature nicht nutzen wollen. Ein echtes Problem sind halt die Überschneidungen mit dieser config.
Vorteil der vollautom. Verwaltung der configs wäre, dass sie kein zusätzlichen Wissen darum benötigen und den DAU nicht ungemäß belasten.

Wichtelchen

Die Standardeinstellungen werden von GTA schon verwaltet (siehe oben).

@bigbiker

Auch und gerade deswegen favorisiere ich eher eine vollautom. Lösung. Da brauche ich nichts zu erklären, was dann sowieso keiner liest.

------------------

Na gut, dann werde ich mir das noch mal gaaanz in Ruhe ansehen. Aufgrund der bisher vorhandenen, verknüpften Strukturen, wird es dann aber eventuell darauf hinaus laufen, die Exportoberfläche komplett umzubauen.

Hi blackwilli,

DAS nenne ich einschleimen:

Du bekommst bestimmt bald das verliehen!

Ääähhhmmmm.....

Also ganz verstehe ich Dein Problem nicht.... Eigentlich musst Du ja nur die einzelnen Werte (alle Einstellungen im Exportbereich) in eine Datei abspeichern (eine serialisierte einfach Strucktur als XML - so als Vorschlag...) und nach dem Namen für die Datei fragen. Und umgekehrt einen Button um die früher abgespeicherte Exporteinstellungen wieder zu laden - also all dies Werte im Formular wieder einstellen.
Das selbe für die Vorlagen. Da fehlen dann einfach diejenigen Werte drin, die wirklich Trackabhängig sind. Also bspw. welche Fotos im Detail exportiert wurden und welche nicht.

Habe ja keine Ahnung, wie Du das ganze aufgebaut hast, aber deshalb gerade die ganzen Register neu aufbauen zu müssen, verstehe ich nicht. Ich will ja nur die eingestellten Wert sichern und wieder laden... Ich sehe da nur gerade vier Buttons (Vorlage laden, als Vorlage speichern, Exporteinstellungen speichern, vorhandene Exporteinstellungen laden). Und ich persönlich würde das ganze über XML abspeichern. Eine serialisierbare Struktur oder Klasse mit allen einstellbaren Werten. In den Vorlagen bleiben da einfach einige Werte leer oder auf vorgabewerten. Thats it - zumindest in meiner Vorstellung....

Das dürfte auch nicht viel Erklärungsaufwand bei den Benutzern ergeben... Ach ja, und flexibel wärs auch...

@Klaus

Ne, lieber nicht. Wenn ich so sehe, wer das schon alles bekommen hat und für was.

@Dieter

Das ich "ja nur die einzelnen Werte ... in eine Datei abspeichern" muß, ist mir schon klar. GTA ist aber so programmiert, dass auch fast alle diese Einstellungen auch autom. über my.settings in der Anwendungskonfiguration verwaltet werden. Da kannst Du die nicht einfach noch von einer anderen Seite aus verwalten, das führt mit Sicherheit zu Konflikten, nicht unbedingt zu Systemkonflikten, aber zumindest zu nicht nachvollziehbaren Ergebnissen im Exportablauf.

Bin aber gerade dabei, das zu analysieren, da ich auch nicht jederzeit genau weiß, was ich in jeder der nun ca. 40.000 Codezeilen gemacht habe.
Wie es im Moment aussieht, komme ich um eine Neustrukturierung der Oberfläche wohl herum, wenn ich alle bisherigen exportbezogenen Konfigurationseinstellungen anpasse und sie auf alle Objekte ausweite, so dass ich sie mit den geplanten Export-Configfiles synchronisieren kann.
Wo ich nicht drumrum komme, ist eine umfassende Änderung der Programmierung der TreeNode-Struktur.

Irgendwie muß ich Dir ja ein schlechtes Gewissen machen.

*ganztiefverckrichindiehintesteeckewonichtmalmehrmäusezufindensindundtiefrotwerdvorscham*

Würde Dir ja gerne helfen, wenn ich könnte. Das mit den my.settings kenne ich offen gestanden noch nicht so genau...