Sista månaden har jag har varit för sjuk för att kunna arbeta särskilt mycket och därmed testa nya LibreOffice 3.4. Det jag kunnat göra visar att det finns flera nya bra funktioner, men att en del inte är färdigbakade, samt att LibO 3.4 har en bra bit kvar innan det är stabilt och faktiskt inte alls borde ha släppts.

Bra saker

Jag har testat LibO 3.4 i en Linuxinstallation med KDE som skrivbordsmiljö. Som vanligt är det främst ordbehandlingsmodulen, Writer, jag använder. LibO 3.4 är något snabbare att starta i Linux än LibO 3.3. Detta beroende på att man slipat uppstarten och rensat i kodbasen.

En mycket bra sak är att nedladdningspaketen på LibO:s hemsida har blivit mindre. Särskilt stor är minskningen för Windows. Det gör att det går snabbare att ladda ner och installera LibO. Jag tror även att programmet mår bra av att man rensat bort död kod. Detta kommer man att ha nytta av framöver.

En bra sak är att man reparerat python som gick sönder i LibO 3.3. Det gör att tillägg som använder python som EuroOffice Clipart fungerar igen.

Halvbra saker

Som jag skrivit om tidigare har sökfunktionen i Writer har gjorts om. När man trycker CTRL+F får man upp den lilla sökraden som introducerades i OOo 3.2. Den poppar upp i nedre vänstra hörnet.

Sökraden i nedre vänstra hörnet. Notera att resten av verktygsraden är tom och sträcker sig längs hela arbetsytan. På en liten skärm tar den lilla sökraden därmed oproportionerligt stort utrymme.

 

För den gamla, mer omfattande sökfunktionen, trycker man CTRL+ALT+F eller hittar den i menyn under Redigera.

I grund och botten är detta en bra förändring. De allra flesta sökningarna klarar man i den enkla sökraden. Problemet är att sökraden inte försvinenr då man sökt färdigt. Man får alltså en permanent extra menyrad med bara den lilla sökraden i botten av arbetsytan. På en liten skärma är detta inte alls lyckat och i slutänden lyckas inte den nya funktionen spara plats. Man kan gömma verktygsraden med knappen längst till höger, men det tar tid och bryter arbetsflödet.

Det enda rimliga är om sökraden försvann med CTRL+F, precis som sökfunktionen försvinner i de flesta webbläsare. En annan variant skulle möjligen vara om man kunde korta ner verktygsraden så att den bara visar sökfönstret och inte en massa tomrum.

Jag har lagt tillbaka sökraden i verktygsraden. Då slipper jag en extra menyrad.

Funktionen är alltså i slutänden bara halvbakad och måste arbetas vidare på innan den är fullt användbar.

Jag har som sagt testat LibO i skrivbordsmiljön KDE i Linux. Man har arbetat vidare med integrationen i KDE som har varit (och är) under all kritik.

Verktygsraderna i KDE LibO 3.3...

Man har lyckats till hälften. Verktygsrader och knappval är tydligare, men grova och fula.

Verktygsraderna i LibO 3.4. De har blivit tydligare, men också grövre och enligt mitt tycke fulare.

Det är nästan bättre att ta bort KDE-integrationen helt, vilket visar på att man måste arbeta vidare på att integrera LibO i KDE.

LibO 3.3 utan KDE-integration. Jag tycker det är snyggare än med...

Den dåliga integrationen påverkar även menyer och dialogrutor.

Dialogrutan Alternativ för autokorrigering i LibO 3.3. Bockarna i valen blir ibland nästan osynliga och hamnar på sniskan...

I LibO 3.4 är bockarna tydligare, men är det snyggt?

Sorgligt nog fungerar alternativet utan integration i KDE bäst. Här finsn saker att jobba med!

Vissa tillägg blir omöjliga att arbeta med i KDE. Ett exempel är Para DTP vars dialogruta är oläsbar.

I LibO 3.3 är dialogfönstret omöjligt att använda

I LibO 3.4 är det nästan omöjligt att använda

Först utan KDE-integration kan man använda tillägget

Den usla integrationen för LibO/OOo i KDE är en av de saker som gör mig fundersam över att använda KDE som skrivbordsmiljö i Linux. För den som inte använder KDE eller Linux är denna diskussion ovidkommande och LibO ser bra ut i Windows och andra OS.

Att man har gjort nedladdningspaketen mindre är inte bara positivt. Man har tagit bort det klassiska temat.

Det klassiska knapptemat finns inte längre i LibO

Det var kanske det mest -80-talsaktiga i OOo, men det finns säkert de som tycker om det.

 

Det dåliga – det riktigt dåliga

LibO 3.4 Writer är stabilt som en tidig betaversion. Det kraschar ständigt, särskilt, om man som jag då och då använder litet mer avancerade funktioner. Det kraschar i alla möjliga och omöjliga lägen. Flera gånger låste Writer datorn och jag fick göra norsk omstart.

Writer kraschar då filer med mer invecklade funktioner sparas. Jag har inte lyckats ringa in krascherna, men det händer med många av mina dokument. Jag får genomgående frågan om jag vill återskapa dokument nästa gång jag öppnar dem, även om det verkar som om sparningen lyckades har alltså LibO kraschat.

Kraschar och att återskapa dokument vardag i LibO3.

Writer kraschar också om man arbetar med flera dokument parallellt och till exempel kopierar och klistrar in text från ett dokument till ett annat. När man sedan stänger ett av dokumenten kraschar LibO utan att de andra dokumenten sparas.

Detta har lett till att jag förlorat arbete. Sådant är oacceptabla i en skarp programversion. Jag har inte testat tillräckligt för att avgöra om problemen finns i Windows eller är Linuxspecifika, men enligt LibO:s buggrapporteringssystem finns det av allt att döma användare som drabbats av liknande problem i Windows.

Förutom detta har LibO 3.4 stora problem med kompatibilitet med MS Office, vilket gör det svårt för mig som fri kontorsslav att samarbeta med ofria kontorsslavar. Filtren har helt enkelt gått sönder och måste lagas.

Det finns dessutom flera något mindre allvarliga buggar som man kanske hade kunnat leva med.

Under gamla SUN/Oracle/OOo regimen var det i alpha och tidigt betastadium av utvecklingscyklerna som man som modig användare/testare kunde förlora data. I LibO tillåter man det i skarpa versioner. Även om hemsidan deklarerar att det finns buggar och att version 3.4 är för tidiga testare, sägs det ingenting om de återkommande krascharna i Writer eller att man kan förlora data.

I LibO har man infört en rullande släppcykel där man rättar buggar efterhand. Jag tycker att oavsett vilken strategi man valt är det oacceptabelt att släppa ett program med så usel kvalitet som LibO 3.4. De enda som bör använda det är utvecklare och betatestare.

Jag tycker detta är ett belägg för att LibO:s släppstrategi inte fungerar. Släpper man program på den här nivån skrämmer man bort användare. Det hade varit bättre att släppa en Releasekandidat till och väntat en eller ett par veckor tills de värsta krascharna hunnit åtgärdas.

LibO3.4 är i praktiken en tidig betaversion. Jag avråder därför alla från att använda det annat än för testning och buggrapportering. Risken att förlora arbete är mycket stor. Jag håller mig till LibO 3.3.3 som visserligen också har buggar (python filtren…), men som på det stora hela är stabilt.

LibO-gänget kommer snart att släppa en buggfixversion till LibO3.4. Vi får se om de lyckats eliminera alla kraschar och kritiska buggar. Jag tror inte att de kommer att hinna. Efter att ha följt med i utvecklingen av OOo under flera år tror jag att man behöver ett par månader innan LibO 3.4 kan användas av andra än betatestare.

En stor skillnad är att det arbetade fler betalda utvecklare med OOo som kunde gneta med buggar. I LibO arbetar fler frivilliga utvecklare på sin fritid. Fokus hamnar då av förklarliga skäl oftare på roliga saker som att utveckla och förbättra funktioner än gnetet med att fixa buggar.

 

 

 

Did you like this? Share it: