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:
[email protected]: [email protected]
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: [email protected]
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: [email protected]
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
