Danke an die Entwickler, Dokumentierer, zahlreichen Helfer und einfach jeden der dazu irgendetwas beigetragen hat. Scribus ist definitiv eines der besten DTP-Programme und dazu auch noch frei und quelloffen. Verdammt gute Arbeit!
Außerdem war es das erste Programm, das den PDF X/3 unterstützte - noch vor Adobe Indesign & Co.! Und das obwohl PDF aus deren Hause ist :) Das muss man sich mal überlegen
Wird langsam komisch. Bei OS Projekten traut man sich nicht mehr die ersten Stellen der Versionsnummern zu ändern.
Das findet dann so Blüten wir hier: 1.3.3.x soll man verwenden aber nicht 1.3.4 oder 1.3.5svn.
Wäre nun wirklich einfacher die erste oder die zweite Stelle hochzuzählen als eine 4. Stelle einzuführen um die 3. Stelle als Unterscheidungsmerkmal für Stabil/Unstabil zu verwenden.
Was ist daran so schlimm? Dem "Normalo"-User kann es egal sein, solange es eine bequeme Donwload-Möglichkeit der aktuellen Stable Version gibt. Ein Paket-Maintainer wird mit so einer Versioniereung ebenfalls keine Probleme haben.
"Schwierig" wirds doch erst dann, wenn es zu einem Fehler kommt und man seine exakte Version raussuchen muss - dann muss man sich in der Tat 4 Zahlen merken / aufschreiben. Also idR weniger Ziffern, also bei einer IP-Adresse
Trotzdem! Ich nutze Scribus schon seit vielen Jahre nach dem es halbwegs benutzbar war. Es ist schon etwas komisch das man nach so langer Zeit und einer so erfolgreichen Entwicklung immer noch bei 1.3.x ist. Eigentlich ist es egal und die Entwickler können natürlich machen was sie wollen, aber komisch mutet es schon an. Dessen ungeachtet arbeite ich sehr gerne (wenn auch nur gelegentlich) mit diesem schönen Stück Software.
Ja. Ist schon ein komisches Gefühl, wenn man eine Applikation wie halt Scribus oder K3B Jahre lang nutzt und plötzlich heißt es, dass die Version 1.0 nun erreicht wurde und das Produkt stable ist. Komisch weil ungewohnt, bekommt man doch sonst Software hingehauen die bereits Version 10.x oder so erreicht hat und noch immer nicht richtig funktioniert. Der neuste Clue scheint wohl dahin zu gehen, gar keine Versionsnummern mehr zu nutzen und nur noch alles nach dem aktuell Jahr zu benennen. Und mittlerweile nicht mal mehr das, sondern nur noch irgendeinen tollen klingenden Namen wie Xp, Vista, Jaguar oder CS.
Naja, so ist es auch mit allen anderen Produkten. Man kauft sich ja auch keinen "Opel Auto Nr. 6 Version 8.3.15" sondern einen "Astra" ;-) Meinetwegen mit der Jahreszahl als Zusatz. Versionsnummern sind eher was für EDV Spezialisten.
Falsch! Speziell bei Autos ist das mittlerweile (Variantenmanagement sei Dank!) enorm kompliziert, rauszufinden, welchen Wagen man da genau vor sich stehen hat! Neben Baujahr kommen da ja viele viele Spezifikationen hinzu, die aus einem schnöden "Astra" eben nicht herauslesbar sind! Im Grunde macht es dort noch viel mehr Arbeit, genau zu soezifizieren, welche "Version" man da vor Augen hat.
Bei einer Software wäre es einfach, wenn jedes Release seinen eigenen Namen hätte - aber ob der nun plastisch klingt, ob eben 1.3.3.10 ist doch dabei egal!
Ich würde sogar so weit gehen, dass man schon einiges aus so einer Nummer herauslesen kann: Alles > Version 1 ist eben schon mal eine Version, die auf einem stabilen Kern basiert, der irgend wann mal angestrebt wurde. Klar kann die dann auch unstable sein, aber vom Umfang her eben komplett.
Die vierte Stelle sind lediglich Subnummern um kleinere Aktualisierungen zu visualisieren. Von daher kein Problem. Aber ein einheitliches System wäre da schon schöner: Meist ja so, x.y.z x = Reihe y = Versionsnummer mit geraden Zahlen für stable und ungeraden für unstable z = Aktualisierungen Also wie beim Kernel und einigen anderen wie GNOME und KDE.
Sofern an einer Version 2.8 gearbeitet wird, ja. Welche Versionsnummer die Entwicklerversion für die nächste stabile 2.6 Version hat kann ich Dir aber nicht sagen, bestenfalls vermuten.
Das ist bei Scribus eine ehr ungewollte Situation. Eigentlich war/ist bei Scribus auch wenn die 2. Stelle eine ungerade Zahl ist es eine Entwicklerversion. Also eigentlich ist die 1.2.x die Stabile. Da aber die 1.3.3 sehr viele nützliche Neuerungen hatte und auch noch recht stabile war hatten plötzlich alle Benutzer nur noch die 1.3.3. Da jetzt in der 1.3.4er Version sehr viel geändert werden sollte entschloss man sich kurzerhand die 1.3.3er Version als stabil zu bezeichnen, und auch kleiner Fehler dort zu beheben um die Anwender glücklich zu machen.
Dann hätte man die stabile Version ja auch 1.4.0 nennen können und die Änderungen von 1.3.4 in 1.5.0 übernehmen können. Statt dessen hat man jetzt 4 Stellen.
Mit der Version 1.3.4 habe ich nur insofern Probleme, als sie ab und zu mal abstürzt und sie beim beenden des Programmes eine Fehlermeldung ausgibt, die allerdings falsch zu sein scheint, d.h. sie hat keine Auswirkungen. Gegen Datenverluste beim Absturz hilft es, die automatische Datensicherung anzuwerfen. Sooooo instabil ist das nicht und für die Sachen, die man privat so anstellt, mehr als geeignet.
Die Probleme mit Float-Spinboxes betreffen nicht speziell Ubuntu, sondern grundsätzlich jede Distribution, die SCIM als Eingabemethode verwendet (also z.B. auch SuSE etc). Das Springen der Werte auf 0.00, egal was man eingibt, ist ein inzwischen uralter Bug in Qt, der wohl erst mit Qt4 elimiert werden wird.
Der Workaround funktioniert entsprechend analog auch für andere Distributionen. Trotzdem ist das Mist, weil man mit LC_ALL=C scribus auch die Möglichkeit verliert, deutsche Umlaute einzugeben, und mit dem Deinstallieren von SCIM die Möglichkeit, bspw. japanische Zeichen zu tippen -- alternativ: Statt SCIM kinput2 installieren, ist allerdings etwas komplizierter zu konfigurieren und funktioniert mit bestimmten Windowmanagern nicht so gut (Kandidatenfenster wird manchmal *unter* anderen Fenstern aufgeklappt).
Ich habe den SpinBox-Bug auf folgende Weise behoben: Nach dem Start von Scribus das FontSample-Script aufrufen und einmal durchlaufen lassen. Das erstellte Dokument schließen und voila, nun klappt es! Ich habe allerdings keine Ahnung, wieso das geht ;-) (Ich muss dazu sagen, dass es sich nicht um die aktuellste Version handelte, wohl aber um eine 1.3.3.xer!)
Und das obwohl PDF aus deren Hause ist :)
Das muss man sich mal überlegen
Alo vielen und herzlichen.
Für viele (z.T. professionelle) Einsätze bereits recht brauchbar.
Das findet dann so Blüten wir hier:
1.3.3.x soll man verwenden aber nicht 1.3.4 oder 1.3.5svn.
Wäre nun wirklich einfacher die erste oder die zweite Stelle hochzuzählen als eine 4. Stelle einzuführen um die 3. Stelle als Unterscheidungsmerkmal für Stabil/Unstabil zu verwenden.
Strange world in OS...
"Schwierig" wirds doch erst dann, wenn es zu einem Fehler kommt und man seine exakte Version raussuchen muss - dann muss man sich in der Tat 4 Zahlen merken / aufschreiben. Also idR weniger Ziffern, also bei einer IP-Adresse
Ich nutze Scribus schon seit vielen Jahre nach dem es halbwegs benutzbar war.
Es ist schon etwas komisch das man nach so langer Zeit und einer so erfolgreichen Entwicklung immer noch bei 1.3.x ist.
Eigentlich ist es egal und die Entwickler können natürlich machen was sie wollen, aber komisch mutet es schon an.
Dessen ungeachtet arbeite ich sehr gerne (wenn auch nur gelegentlich) mit diesem schönen Stück Software.
Man kauft sich ja auch keinen "Opel Auto Nr. 6 Version 8.3.15" sondern einen "Astra" ;-)
Meinetwegen mit der Jahreszahl als Zusatz.
Versionsnummern sind eher was für EDV Spezialisten.
Bei einer Software wäre es einfach, wenn jedes Release seinen eigenen Namen hätte - aber ob der nun plastisch klingt, ob eben 1.3.3.10 ist doch dabei egal!
Ich würde sogar so weit gehen, dass man schon einiges aus so einer Nummer herauslesen kann: Alles > Version 1 ist eben schon mal eine Version, die auf einem stabilen Kern basiert, der irgend wann mal angestrebt wurde. Klar kann die dann auch unstable sein, aber vom Umfang her eben komplett.
Aber ein einheitliches System wäre da schon schöner:
Meist ja so, x.y.z
x = Reihe
y = Versionsnummer mit geraden Zahlen für stable und ungeraden für unstable
z = Aktualisierungen
Also wie beim Kernel und einigen anderen wie GNOME und KDE.
Ok, lag etwas falsch. Aber die Kernel-Versionierung hat doch so einen Sinn, oder? Und der ist praktisch.
Welche Versionsnummer die Entwicklerversion für die nächste stabile 2.6 Version hat kann ich Dir aber nicht sagen, bestenfalls vermuten.
Das ist definitv eine zu viel. Auch beim Kernel.
Sooooo instabil ist das nicht und für die Sachen, die man privat so anstellt, mehr als geeignet.
Dank an die Scribushacker.
http://wiki.scribus.net/index.php/Workarounds_for_Qt_bugs
Der Workaround funktioniert entsprechend analog auch für andere Distributionen. Trotzdem ist das Mist, weil man mit LC_ALL=C scribus auch die Möglichkeit verliert, deutsche Umlaute einzugeben, und mit dem Deinstallieren von SCIM die Möglichkeit, bspw. japanische Zeichen zu tippen -- alternativ: Statt SCIM kinput2 installieren, ist allerdings etwas komplizierter zu konfigurieren und funktioniert mit bestimmten Windowmanagern nicht so gut (Kandidatenfenster wird manchmal *unter* anderen Fenstern aufgeklappt).
Nach dem Start von Scribus das FontSample-Script aufrufen und einmal durchlaufen lassen. Das erstellte Dokument schließen und voila, nun klappt es! Ich habe allerdings keine Ahnung, wieso das geht ;-)
(Ich muss dazu sagen, dass es sich nicht um die aktuellste Version handelte, wohl aber um eine 1.3.3.xer!)