staging.inyokaproject.org

Bin gerade auf ein Problem beim Codeblock gestoßen.

Bei Python Code verändert InyokaEdit den Code.

Original

1
2
3

with open(myfile, 'w') as f:
    f.write('\n'.join(playlist))
    f.close()

InyokaEdit macht daraus

with open(myfile, 'w') as f:
    f.write('%%NO_TRANSLATE_2%%'.join(playlist))
    f.close()

Hallo Axel-Erfurt

danke für das Melden des Fehlers! Dass InyokaEdit noch Problemchen mit maskierten Zeichen hat, war mir bewusst - aber das von Dir gezeigte Szenario (maskiertes Zeichen innerhalb eines Codeblocks) ist mir neu! Der Inhalt von Codeblöcken sollte eigentlich vom Parser komplett ausgeschlossen sein und mein schlechter Workaround maskierte Zeichen vor dem Parsen temporär zu entfernen und anschließend wieder einzufügen, hat in diesem Fall offensichtlich auch nicht funktioniert ☺

Das muss ich mir im Detail genauer anschauen! Damit es nicht vergessen geht, habe ich es in den Bugtracker 🇬🇧 aufgenommen.

Hej,

also dann hier

→ [post:9210839]

zu dem dort gesagten

• der Versuch, Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD in den Editor zu laden klappt nur, wenn ich bei 'Bilder auch laden' auf "abbrechen" klicke

• dort ist besagter Fehler (https://media-cdn.ubuntu-de.org/forum/thumbnails/265952-9210839-fehler.png)

• ferner gibt es unter Textbaustein keine "Anlage" (gehört in die Rubrik "was man weiß, was man wissen sollte" *grins*)

Gruß black tencate

Hallo black_tencate

vielen Dank für die Rückmeldungen! Zu Deinen Punkten hier:

• Download des Artiekls/der Bilder: Bei mir tauchen da auch ein paar Fehlermeldungen auf "Das Protokoll \"\" ist unbekannt". Das ist mir die Tage nicht nur bei dem von Dir genannten Artikel aufgefallen sondern auch bei anderen. Hierzu muss ich mal forschen, ob sich seitens Inyoka etwas geändert hat oder seitens Qt. Evtl. hängt es auch mit den Anhängen des Artikels zusammen, aber scheinbar kommt die Meldung auch bei PNG Bildern. Damit es nicht vergessen geht Issue 102 🇬🇧

• Die Fehlermeldung vom Syntaxcheck kommt von der Tabelle, in der mit <(> Text linksbündig ausgerichtet werden soll (gleiche Fehlermeldung würde auch bei Verwendung von <)> für rechtsbündig kommen). Da sieht man mal wieder, dass der Autor einer Software nie alleiniger Tester sein sollte 😉. An diese Tabellenformatierung habe ich bei der Erstellung des Syntaxchecks nicht gedacht! Ist notiert und wird in absehbarer Zeit korrigiert: Issue 103 🇬🇧

• Bzgl. Anlage-Macro: Da gibt es noch weitere Macros und Formatierungen, die ich nicht in die Menüs und Werkzeugleisten eingebaut habe, um es nicht zu überfrachten (Anker, Datum, mark, size, color, Fußnote, Zitat, Zeilenumbruch). Die Sachen ins Menü einbauen, ist kein Problem, nur stellt sich die Frage des Nutzens für den Großteil der Nutzer. Ich lasse mich da gerne umstimmen, verweise aber auch gerne auf den Wikiartikel, der beschreibt wie man eigene Menü-/Werkzeugleisten für InyokaEdit erstellen kann.

Beitrag 9210839 ist ungünstig platziert, da es dort eigentlich nur um den Wikiartikel an sich geht und nicht um die Funktionen & Fehler des Programms. Daher antworte ich hier:

auf die Schnelle keine Möglichkeit der farblichen Unterscheidung der beiden Fenster

[...] ich meine schon einen farblichen Unterschied zwischen den Hintergründen des Editorbereiches und der Vorschau

Das hängt vermutlich mit der von Dir verwendeten Fensterfarbe (Systemeinstellungen) und ggf. auch welche Syntaxhervorhebung eingestellt ist, zusammen. Wenn Du als Editorhintergrund weiß eingestellt hast und eine helle Fensterfarbe nutzt, kann der Kontrast schlecht sein. Welche Desktopumgebung nutzt Du? Schick bitte mal einen Screenshot.

man kann die Balken "verkoppeln", aber nicht die Inhalte der beiden Fenster "laufen" parallel

Ja, das ist nicht optimal. Es passt je nach Artikel und verwendeten Vorlagen nur halbwegs oder auch gar nicht. Wenn es stört, einfach in den Einstellungen ausschalten. Eine andere oder bessere Lösung kann ich aktuell dafür nicht liefern.

ähem, ich füge ein: Bild. Dann hätte ich jetzt erwartet, eine Auswahl für Größe, Position, etc, Hilfstext und was es da so alles gibt

Da gehen die Erwartungen auseinander 😉 Mich persönlich würde es stören, wenn bei einem Bild-Maco immer Fenster aufpoppen würden, die alle möglichen Optionen abfragen.

ich setze {{{ und fange an zu schreiben, mitten drin poppt die Fehlermeldung "Syntaxfehler entdeckt – offene Klammer!" auf.

Das hängt damit zusammen, wie schnell Du die automatische Vorschau erstellen lässt (Standard sind nach einer Neuinstallation alle 15sek). Bei zu kurzer Zeit oder langsamen Tippen, kann die Syntaxprüfung leider zwischenrein krätschen. Eine mögliche Verbesserung wurde weiter oben schon diskutiert. In der nächsten Version erscheint keine Messagebox mehr, sondern ein nicht so penetranter Tooltip.

Da hätte ich jetzt erwartet, daß nach den {{{ gleich die }}} gesetzt würden, der cursor automatisch in die Mitte geht und der Text geschrieben werden kann.

Das sollte auch funktionieren - die einzige Ausnahme ist glaube ich wirklich der Codeblock 😛 (ob es einen Grund dafür gab/gibt, muss ich nochmal nachschauen)

Hej Shakesbier,

Shakesbier schrieb:

...

• Die Fehlermeldung vom Syntaxcheck kommt von der Tabelle, in der mit <(> Text linksbündig ausgerichtet werden soll...

hmm, markiert wird aber eine ganz andere Zeile nach Ende der Tabelle

[...] ich meine schon einen farblichen Unterschied zwischen den Hintergründen des Editorbereiches und der Vorschau

Das hängt vermutlich mit der von Dir verwendeten Fensterfarbe (Systemeinstellungen) und ggf. auch welche Syntaxhervorhebung eingestellt ist, zusammen.

ja, mal sehen… ist alles Gewöhnung.

ähem, ich füge ein: Bild. Dann hätte ich jetzt erwartet, eine Auswahl für Größe, Position, etc, Hilfstext und was es da so alles gibt

Da gehen die Erwartungen auseinander 😉 Mich persönlich würde es stören, wenn bei einem Bild-Maco immer Fenster aufpoppen würden, die alle möglichen Optionen abfragen.

und es ist ja doch vorhanden (<Textbausteine> → <Bilder> → <Bilder mit Unterschrift>), man muß nur → s. meine Signatur (und ich muß mir dringend abgewöhnen, gleich so los zu poltern – mein Auslöser/Anstoß war ja eigentlich dieser post 9210547)

ich setze {{{ und fange an zu schreiben, mitten drin poppt die Fehlermeldung "Syntaxfehler entdeckt – offene Klammer!" auf.

Das hängt damit zusammen, wie schnell Du die automatische Vorschau erstellen lässt (Standard sind nach einer Neuinstallation alle 15sek). Bei zu kurzer Zeit oder langsamen Tippen,

nö, ist ja auch vorhanden, die ganze Palette.

Wird schon *thumbup*

Gruß black tencate

Shakesbier schrieb:

Das muss ich mir im Detail genauer anschauen! Damit es nicht vergessen geht, habe ich es in den Bugtracker 🇬🇧 aufgenommen.

Vermutlich selbe Baustelle: {{{#!vorlage befehl program --option}}} wird zu

program -option 

Hallo,

der Editor ist wirklich toll. Die Syntaxkontrolle fand ich immer nervig, aber das ist ja jetzt gelöst.

Eine Idee für die Schreibfaulen hätte ich aber noch (keine Ahnung, ob und wie man das umsetzen kann ... ): Wäre es vielleicht möglich, die Benutzerdaten abzuspeichern und dadurch bei dem Herunter- bzw. Hochladen von Artikeln nicht immer neu eingeben zu müssen? Dadurch spart man sich circa 20 Anschläge. 😈

LG

tuxifreund

tuxifreund schrieb:

Eine Idee für die Schreibfaulen hätte ich aber noch (keine Ahnung, ob und wie man das umsetzen kann ... ): Wäre es vielleicht möglich, die Benutzerdaten abzuspeichern und dadurch bei dem Herunter- bzw. Hochladen von Artikeln nicht immer neu eingeben zu müssen? Dadurch spart man sich circa 20 Anschläge. 😈

Der Nutzername ist kein Problem, das hatte ich mir beim Rumspielen mit dem SourceCode schon mal eingebaut, weil mir das auch bequemer vorkommt 😉 Problematisch wird das Inyoka-Passwort (also das zur Anmeldng bei UU.de). Da muss man dann irgendwie eine Schnittstelle zu drölfzig Passwortmanagern (KWallet, gnome-keyring, KeepassXC,…) anbieten, aber vielleicht weiß der Entwickler dazu mehr beizutragen.

Ich hatte dabei einfach an zwei Zeilen in einer Konfigurationsdatei gedacht, aber das ist von der Sicherheit her nicht so optimal, weil man ja lesend auf andere Homeverzeichnisse zugreifen kann.

Ich würde ja gerne mithelfen, aber C(++) steht mit mir irgendwie auf Kriegsfuß. (Vielleicht sollte ich mich nochmal intensiver damit beschäftigen...)

tuxifreund schrieb:

Ich hatte dabei einfach an zwei Zeilen in einer Konfigurationsdatei gedacht, aber das ist von der Sicherheit her nicht so optimal, weil man ja lesend auf andere Homeverzeichnisse zugreifen kann.

Vielleicht kann man ja auch den SSL-verschlüsselten Key speichern. K.A. Es gibt noch frankosterfeld/qtkeychain als optionale Möglichkeit. Aber wie gesagt, das soll der Chef kundtun 😉

Ich würde ja gerne mithelfen, aber C(++) steht mit mir irgendwie auf Kriegsfuß.

Ich stehe mit allen Programmiersprachen auf Kriegsfuß — aber auch wenn ich den Krieg am Ende verliere, so manche Schlacht gewinne ich dann doch :þ

Hallo zusammen

black_tencate schrieb:

hmm, markiert wird aber eine ganz andere Zeile nach Ende der Tabelle

Guter/wichtiger Hinweis! Dadurch habe ich einen weiteren Fehler beim Syntaxcheck finden können. Das Problem, das die Fehlermeldung unter gewissen Umständen nicht richtig positioniert wurde und das Problem mit <(> (bzw. <)>) in Tabellen ist in der nächsten Version von InyokaEdit korrigiert.

ChickenLipsRfun2eat schrieb:

Vermutlich selbe Baustelle: {{{#!vorlage befehl program --option}}} wird zu

program -option 

Das ist leider ein anderer/weiterer Fehler. Inyoka macht aus "--" das hier: "–", jedoch scheinbar nicht, wenn es in einer Vorlage benutzt wird.

tuxifreund schrieb:

Eine Idee für die Schreibfaulen hätte ich aber noch (keine Ahnung, ob und wie man das umsetzen kann ... ): Wäre es vielleicht möglich, die Benutzerdaten abzuspeichern und dadurch bei dem Herunter- bzw. Hochladen von Artikeln nicht immer neu eingeben zu müssen? Dadurch spart man sich circa 20 Anschläge. 😈

ChickenLipsRfun2eat schrieb:

tuxifreund schrieb:

Ich hatte dabei einfach an zwei Zeilen in einer Konfigurationsdatei gedacht, aber das ist von der Sicherheit her nicht so optimal, weil man ja lesend auf andere Homeverzeichnisse zugreifen kann.

Vielleicht kann man ja auch den SSL-verschlüsselten Key speichern. K.A. Es gibt noch frankosterfeld/qtkeychain als optionale Möglichkeit. Aber wie gesagt, das soll der Chef kundtun 😉

Die Zugangsdaten zu speichern ist an sich eine gute Idee, jedoch das ganze "sicher" zu gestalten, ist sehr schwierig! QtKeychain kannte ich noch nicht, danke für den Hinweis. Das scheint auf den ersten Blick eine gute Lösung zu sein, aber auf der anderen Seite auch ein riesiges Softwaremodul "nur" um ein einziges Passwort zu speichern. Ich schaue mich die kommenden Tage nochmal um, welche Lösungen es noch gibt, die sich mit vertretbarem Aufwand umsetzen lassen.

Hallo,

danke für die Rückmeldung. Das mit der Sicherheit war ja auch ein Teil meines Bedenkens.

Ein paar marginale Sachen hätte ich aber noch.

• Es hat sich ein Rechtschriebfehler eingeschlichen unter: InterWiki-Links → Canonical & Ubuntu → Canonical Voices, da steht "Canonical Voises"

• Der Link im "About InyokaEdit"-Fenster zum Tango-Projekt liefert eine Fehlermeldung aus. Freedesktop.org selbst verweist hier auf http://www.tango-project.org/, aber auch hier findet sich nur eine Fehlermeldung. Vielleicht ist ja im "About InyokaEdit"-Fenster ein Link zu dem Wikipediaartikel besser?

• In den InterWiki-Links gibt es Vorlagen für Trac und behind.ubuntuusers.de. Das ist auch in der Linkmap drin (es gibt ja genug Forenpost, in denen die verwendet sind), beide Dienste gibt es meines Wissens nach aber nicht mehr. Sollte man dann beide aus dem Menü entfernen, aber im Parser natürlich drin lassen od. ist das aneinandergekoppelt?

Das klang jetzt ein bisschen klein kariert...

LG

tuxifreund

Shakesbier schrieb:

…QtKeychain kannte ich noch nicht, danke für den Hinweis…

Ja, funktioniert zumindest für Linuxe tadellos. Ich finde es auch etwas überdimenstioniert für diesen Zweck, andererseits muss das wohl, wenn man portabel bleiben will. Alternativ gäbe es noch https://pypi.org/project/keyring/ (python3-keyring) als Python-Alternative. Das dürfte auch eher vorinstalliert sein und müsste nicht „mitgeliefert“ werden, aber keine Ahnung wie sowas unter Win/MacOS unterstützt wird.

Hallo,

tuxifreund schrieb:

Das klang jetzt ein bisschen klein kariert...

Ist alles legitim und konstruktiv ☺ Korrekturen für alle drei Punkte werden in der nächsten Version enthalten sein. Ich verlinke statt zum Tango-Projekt nun zum Mutterprojekt https://www.freedesktop.org 🇬🇧. Bzgl. der IWLs hast Du vollkommen Recht, ich habe sie aus dem Menü entfernt (parsen der Links funktioniert nachwievor).

ChickenLipsRfun2eat schrieb:

…QtKeychain kannte ich noch nicht, danke für den Hinweis…

Ja, funktioniert zumindest für Linuxe tadellos. Ich finde es auch etwas überdimenstioniert für diesen Zweck, andererseits muss das wohl, wenn man portabel bleiben will.

Mit dem Speichern der Zugangsdaten bin ich immer noch unschlüssig. Aktuell bietet InyokaEdit auch schon die Option Proxyzugangsdaten komplett unverschlüsselt zu speichern, was mir auch nicht wirklich gefällt (wobei ich vermute, dass 99,9999% der Nutzer diese Option sowieso nie benötigen). Hatte auch schon daran gedacht, wenigstens alles in Base64 zu kodieren, damit es nicht in Klartext gespeichert ist, aber sicherer wird es dadurch auch nicht.

Shakesbier schrieb:

Mit dem Speichern der Zugangsdaten bin ich immer noch unschlüssig…

Du kannst ja auch SimpleCrypt nehmen, das wäre dann ohne den Keyring in Eigenregie und natürlich keine starke Verschlüsselung. Dafür hast du nur eine weitere Klasse per copy&paste einzubinden.