[de-discuss] Per Makro nicht zugängliche Funktionen, relative Pfade Bug 128216, "Update image" funktion fehlt.

html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial, helvetica, 
sans-serif;;}
 




-------- Original Nachricht --------Betreff: Re: [de-discuss] Per Makro nicht zugängliche 
FunktionenDatum: 07.01.2025 21:12 (GMT +01:00)Von: 9876@vishia.deAn: robert@familiegrosskopf.de


Hallo Robert und Community


Meine Aussage war genereller Natur, nicht direkt auf die fehlende Makrozugänglichkeit bezogen. 
Freilich, wenn eine Funktion schonmal eigentlich vorhanden ist aber nicht zugänglich, dann ist das 
doof, vereinfacht gesagt. Aber ich habe spätestens auf ein paar Vorträgen auf der LOffc Konferenz 
in Luxemburg mitbekommen, und weiß es durch eigene Programmierarbeiten, dass manche Dinge eben nur 
einfach getan werden müssen, mehr nicht, andere Dinge aber auch, Software ist verzwickt. manchmal, 
und die schnelle Hand um die Funktion Makrozugänglichkeit einzubauen, ist oft verbrannt, wenn es zu 
schnell (aus Ressourcengründen) gemacht wird. Also wird es erst mal priorisiert, etwas niedriger. 
So ist das, nicht trivial. Wichtig wäre schon, dass die Makrozugänglichkeit vorhandener Funktionen 
immer GLEICH MIT bedacht wird. Im nachhinein nochmal hinfassen ist eben auch mal nicht ganz 
einfach. Diese Worte wären jetzt an den Entwickler zu richten, der das einbauen kann. Wer ist es, 
bitte ganz schnell mal melden (Sorry bin heute polemisch).


Genau um diese Notwendigkeiten zu entzerren, wollte ich darauf hinweisen, dass für manche 
Funktionen entweder gleich auf externe Tools gesetzt wird, oder sie vom Nutzer alternativ genutzt 
werden können. Wenn der Nutzer aber der Entwickler ist und die eigentlichen Nutzer dann überfordert 
sind, weil sie womöglich Lizenzen für externe Tools XY brauchen oder diese selbst installieren 
müssen und das nicht wollen oder können, nunja, ich bin heilfroh dass dies nicht mein Problem ist. 
Ist schon nicht einfach. Es muss dann passend endnutzerfreundlich im Installationspaket eingebunden 
sein.


Diejenigen Tools, die keine eigene Installation brauchen sondern quasi nur auf Festplatte kopiert 
werden brauchen (oft als portable Version bezeichnet, ein Kollege hat das mal treffender als 
"copy-Deployment" bezeichnet), sind dabei WESENTLICH NETTER. Weil man nicht noch einen extra 
Installationsprozess braucht und diverse Abhängigkeiten usw. usf. Habe letztlich Eclipse auf Linux 
auf diese Weise installiert. Einfach tar.gz auspacken und läuft. Es gibt immer wieder 
Gegnerschaften dieser Herangehensweise. Als die Registry in Windows eingeführt wurde, war es 
zunächst verboten bis verpönt, etwas einfach direkt zu kopieren und aufzurufen. Aber von vielen 
wird copy-Deployment bzw. "portable Version" auch favorisiert und auch angeboten. Kurzer Schwank 
aus der Arbeit in der Vergangenheit (schon länger her). Ich hatte Visual Studio 6 seinerzeit 
einfach kopiert, geschaut welche dlls fehlen, und die auch kopiert, läuft. Ein anderer Kollege 
braucht auch Visual Studio, hat sich an die "Installationsvorschrift" gehalten, ihm ist aber auf 
die Füße gefallen, dass er immer alles mögliche bei jedem PC-Wechsel mitgeschleppt hat 
(Messie-Typ). Dann kam dauern "cannot spawn..." und wir haben gesucht was den "spawn" auf deutsch 
heißt, was er meinen könnte, der Installateur. Dabei sind wir darauf gekommen, dass das Laichen 
eines Froschs spawn heißt, also ok er konnte was nicht ablegen. Das hat dann den ganzen vormittag 
gedauert. mein Copy-Deployment mit einer Liste notwendiger dlls wäre in 10 min erledigt gewesen. 
Wollte er aber nicht.


Anderes Problem: Relative Pfade anzeigen, Bugzilla 128216:


Ich habe mich eben über ein anderes Problem geärgert was so seit 2018 mit einer Fehlermeldung 
dahinwabert: Bug128216. Obwohl ich relative Paths angewählt habe (Tools-Options - Load/Save - 
General - "Save URLs relative to Filesystem") macht er manchmal zunächst einen absoluten Pfad 
sichtbar im content.xml. Möglicherweise liegt das daran weil ich in Windows über Netzwerkgrenzen 
einen symbolic link verwende (MKLINK /J name path/to/dst). Das funktioniert und nach guten Zureden 
(immer mal wieder eingeben) war der Path auch dann relativ. Man kann sich offensichtlich nicht 
darauf verlassen. Im ersten Moment fällt es nicht auf, wenn der link-Path auf ein externes Image 
absolut ist, wenn man nicht ins content.xml schaut. Es fällt erst dann auf und ist dann 
möglicherweise prekär, weil mehrere Image-paths nicht stimmen, wenn das File.odt auf einem andern 
PC geöffnet wird, vorher kopiert usw.


Als generelles Statement: Relative Pfade funktionieren IMMER wenn sie richtig gepflegt werden. 
Absolute Pfade funktionieren NICHT, wenn es verschiedene Strategien der Dateiablage gibt (entweder 
/home/user/img/... oder irgendwo anders). Ist der PC nicht für nur einen Zweck, dann passiert das 
ganz schnell mal. Deshalb setze ich seit Jahrzehnten erfolgreich auf relative Pfade. Auch hierbei 
gibt es manchmal Gegnerschaften. Aber deshalb muss es diskutiert werden.


Deshalb wäre es gut, die relativen Pfade im Dialog anzuzeigen, das steht in Bug128216. Dann würde 
man auch einfacher kontrollieren können ob und dass der Pfad relativ ist und wie er faktisch 
aussieht. Zusätzlich muss der sich daraus ergebende absolute Pfad angezeigt werden, und eine Info 
ob das File sichtbar ist. Das wäre schön. Das ist eines meiner Probleme, immer mal wieder, bin 
schon gewöhnt daran.;


Fehlende Funktion "Update image":


Außerdem fehlt die Funktion "update image". "update field" gibt es, aber das nützt dort nichts. 
"update image" ist wichtig, wenn das image nochmal gespeichert wird (bei mir ist das oft z.B. ein 
Modell aus Simulink als Screenshot, nach ein paar Korrekturen nochmal geschossen und gespeichert, 
evtl. mit modifizierter Größe). Ich kann dann nur "Update all" aufrufen, mir vorher die Seite 
merken und wieder dahinscrollen. - Für diese Sache habe ich aber noch nicht geschaut, ob es ein 
Bugzilla-Eintrag gibt.


... es gibt noch ein paar Dinge mehr. Aber ich habe keine ungeduldigen Kunden, sondern nur ein paar 
Kollegen, die einsehen dass nicht alles absolut immer gleich gut ist. Mit Kunden im Rücken ist es 
natürlich nerviger. Schon verständlich.


Herzliche Grüße, Hartmut Schorrig


Robert Großkopf schrieb am 07.01.2025 08:38 (GMT +01:00):
Hallo Hartmut,


Danke für die Rückmeldung. Mir scheint aber, dass Du 2 wesentliche 
Punkte bei diesem Thema außer acht lässt:


Beide Funktionen (Datei in PDF einbinden, Girocode erzeugen) kann 
LibreOffice. Nur fehlt beim QRcode der Makrozugang, bei der Einbindung 
von Dateien in PDF die Einbindung einer externen Datei.


Ich erstelle da eine Datenbanklösung für XRechnungen, die ich selbst gar 
nicht nutze. Da mit Beginn des Jahres 2025 diese Rechnungsform Pflicht 
für Firmen untereinander ist nahmen in den letzten Wochen die 
Mailanfragen bei mir beständig zu.


Für mich selbst ein externes Tool zu nutzen - kein Problem. Aber für 
irgendwelche Firmen, die die Software herunter laden ist das Fehlen des 
Girocodes oder die fehlende Ausgabe von ZUGFeRD-Rechnungen (PDF mit 
eingebundener XML-Datei) schnell so etwas wie ein Bug.


Gruß


Robert
-- 
Homepage:https://www.familiegrosskopf.de/robert-- 
Liste abmelden mit E-Mail an: discuss+unsubscribe@de.libreoffice.org
Probleme?https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/Tipps zu 
Listenmails:https://wiki.documentfoundation.org/Netiquette/deListenarchiv:https://listarchives.libreoffice.org/de/discuss/Datenschutzerklärung:https://www.documentfoundation.org/privacy
-- 
Liste abmelden mit E-Mail an: discuss+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/discuss/
Datenschutzerklärung: https://www.documentfoundation.org/privacy