LibreOffice 4.0

[Minio]

Jeżeli ktoś nie czyta listy developerskiej LibreOffice, to pewnie umknęła mu dość ważna informacja:
Następna wersja będzie miała numer 4.0, a nie 3.7.
Zmiana pierwszego numeru wersji wiąże się z zerwaniem dotychczasowej kompatybilności API/ABI oraz — co nie nastraja mnie optymistycznie — zmianą polityki dotyczącej API/ABI.

Na anglojęzycznej wersji naszego forum wielokrotnie spotkałem się z opiniami, że LO jest niestabilne i skierowane raczej do użytkowników, którzy oczekują nowych funkcji, niż tych, którzy wymagają stabilności (czyli LO nie sprawdzi się w środowiskach korporacyjnych). Opinie te raczej nie znajdowały poparcia w faktach, co najwyżej jedynie w nieznajomości schematu numeracji wersji LO. Jednak wraz z wprowadzeniem proponowanej zmiany, opinie te mogą niebezpiecznie nabrać mocy. Z wiadomości można bowiem wyczytać, że od teraz każda nowa wersja LO może łamać stabilność API/ABI. Niby autor wiadomości wskazuje, że modyfikacja tej części programu nie będzie zbyt prosta i nie powinniśmy się obawiać, że wymknie się ona spod kontroli. Jednak patrząc na liczbę regresji w kolejnych wydaniach LO, nie jestem przekonany o tym, że faktycznie wszystkie zmiany zostaną wychwycone już w momencie wydania, a programiści wtyczek będą do nich odpowiednio przygotowani. Taka zmiana może więc dodatkowo ograniczyć i tak niewielki rynek rozszerzeń do LO.

Nie mogę się też oprzeć wrażeniu, że TDF przestraszyło się nadchodzącego AOO w wersji 4.0 i tego, że dla części użytkowników mniejszy numer będzie się kojarzył z produktem gorszej jakości.

Gdyby kogoś interesowało, zmianę których fragmentów API rozważają programiści LO, niech zajrzy na tę stronę:
http://wiki.documentfoundation.org/Deve ... breOffice4

Co o tym wszystkim myślicie? Czy faktycznie TDF strzela sobie w stopę i utrudni życie twórcom rozszerzeń oraz administratorom środowisk korporacyjnych, czy też moje obawy są nieuzasadnione, a proponowana zmiana może tylko wszystkim wyjść na dobre (ponieważ umożliwia głębszą ingerencję w strukturę programu)?

[quest-88]

Może zacznę od tego, że hasła zmiany API/ABI oraz złamania wstecznej kompatybilności były głoszone już w 2010 roku podczas pierwszego wydania LibreOffice (3.3 o ile dobrze pamiętam?). Dużo się wtedy mówiło i jeszcze więcej planowało (ktoś jeszcze pamięta http://wiki.documentfoundation.org/Deve ... razy_Ideas)

Nie lubię zachowań w myśl "nie znam się, ale wypowiem się", ale problem dotyczy też konsumpcji produktu, a więc dotyczy również zwykłych użytkowników. Z mojego punktu widzenia ta zmiana nie jest zła. Wszyscy wiemy jakie niesie konsekwencje, ale zadajmy sobie pytanie: dlaczego deweloperzy mają *borykać* się z API z roku 2000? Przeglądam tę listę i widzę tam uproszczenie składni, a to powinno ułatwić i przyśpieszyć pisanie nowych dodatków. Oczywiście stare rozszerzenia trzeba będzie zaktualizować, ale dlaczego to co ktoś, kiedyś napisał (pracując dla StarDivisiona jeszcze w zeszłym milenium) ma dekadę później rzutować na pracę innych? Jeśli ktoś jest taki "pro" że używa wielu rozszerzeń, po prostu będzie zwlekał z aktualizacją pakietu aż do czasu aktualizacji dodatków.

Nie jestem programistą, ale też nie przeszedłem z OpenOffice'a na LibreOffice, aby poświęcać swój czas wielkiemu klocowi bez perspektyw rozwoju. Nie podejrzewam, aby ktokolwiek z ekipy działał na szkodę projektu. Jeśli Meeks, Strba, Michaelsen i paru innych uważa, że zmiany są potrzebne, to kim ja (zwykły użytkownik) jestem, aby negować ich doświadczenie? Znam polskiego programistę OOo (i przedsiębiorcę), który kod Go-OO (z czasów Novella) nazwał śmieciami, ale to była jedna taka opinia i nigdy nie została (przy mnie) skonfrontowana z opinią drugiej strony. Minio, pamiętaj też, że ludzie zwykle nie komplementują pozytywów, bo uważają, że "tak ma być", natomiast do krytyki (a również tej niemerytorycznej i pełnej histerii) jest zawsze wielu chętnych.

Pamiętam też, że w LibreOffice wersja "4.0" od zawsze miała oznaczać złamanie wstecznej kompatybilności. Rozumiem, że w erze "Apache" OpenOffice'a i nadchodzącej wersji 4.0 łatwo jest sugerować celowe działania marketingowe, jednakże może należy pomyśleć, czy czas zmian w API nie nastał właśnie teraz, w tej chwili i konieczne jest postawienie "grubej kreski"? Dla mnie to zwykła koincydencja, a działanie fundacji postrzegam na plus. Nie chciałbym widzieć na forum postów w stylu "w 3.6 wszystko działało, a 3.7 to kupa kupy" Między wersjami 3.6 i 4.0 jest wyraźna separacja, co powinno zmniejszyć liczbę infantylnych pytań.

Zresztą nawet gdyby podciągnąć ich działanie pod marketing, to co z tego? Gdyby złamali kompatybilność, a numeracja byłaby ciągła, czy to by coś dla nas znaczyło? Należy pamiętać, że TDF musi walczyć o użytkowników z IBM-em (pardon, z Apache) tak samo jako z Microsoftem. Rob Weir ostatnio nawet "poniżał" osiągi konkurencji.

Regresja są problemem innego rodzaju. Nie można rozwijać oprogramowania z podejściem "nie ruszać kodu, bo coś się zepsuje", bo to nie jest rozwój. Ciągle powtarzam, że głównym atutem tych produktów jest OpenDocument, więc jeśli ktoś uzna, że nowe wydania LibreOffice mu nie odpowiadają, może spokojnie przejść do Apache OpenOffice a nawet na... MS Office 2013!

Natomiast jak można rozwiązać ten problem? Mam nadzieję, że deweloperzy rozwiążą go już od wydania 4.0. Cedric Bosdonnat zrobił podsumowanie Google Summer of Code, gdzie napisał:

Unit tests improvements from Artur Dorda

Unit tests are extremely important for LibreOffice. They are the tests that are run during the build time, and consequently are run by every developer that builds LibreOffice. Unit tests help you to make sure that the functionality hasn’t regressed over time, and if it does, help you to discover the regression quickly. Artur did great job extending the unit tests mainly in the area of Calc.

[Minio]

quest-88: żebyśmy nie zrozumieli się źle — sama zmiana API, wraz z zerwaniem dotychczasowej kompatybilności, w ogóle mi nie przeszkadza. Wstecznej kompatybilności nie można trzymać w nieskończoność i czasem trzeba ją porzucić, aby móc iść do przodu.

Bardziej martwi mnie zmiana polityki dotyczącej kompatybilności. Teraz każda nowa wersja będzie mogła wprowadzać zmiany w API. Teoretycznie powinniśmy mieć czas na przystosowanie do nich swoich programów (najpierw oznaczenie pewnych funkcji jako przestarzałych, a dopiero potem ich usuwanie, konieczność dokumentowania wszelkich wprowadzanych zmian, liberalna polityka przywracania stanu sprzed zmian), w praktyce… obawiam się, że w praktyce może być inaczej. W skrajnie-skrajnym przypadku dojdzie do tego, że programiści będą musieli modyfikować swój kod wraz z każdym nowym wydaniem LO (czyli co pół roku). Wydaje mi się, że dla LO (jako całego systemu, wliczając w to programistów rozszerzeń oraz firmy wykorzystujące go na stanowiskach komputerowych) byłoby lepiej, gdyby polityka dotycząca zmian w API była bardziej konserwatywna. Np. „możliwość zerwania wstecznej kompatybilności API nie częściej niż raz na dwa lata”. Taka polityka chyba wymuszałaby również bardziej przemyślane podchodzenie do tej kwestii. Być może byłby to dobry kompromis między stabilnością i przewidywalnością a potrzebami programistów, którzy czują się ograniczeni przez konieczność utrzymywania wstecznej kompatybilności.

W żadnym wypadku nie chcę obrzucać LO błotem i wyrokować, że wersja 4.0 będzie początkiem końca tego programu. Pożyjemy, zobaczymy — być może początki będą trudne, ale za jakiś czas sytuacja się ustabilizuje i będzie o wiele lepiej niż było? A może wszystko uda się dograć i cały proces przebiegnie bez zakłóceń?
Chodzi mi raczej o zwrócenie uwagi na samą kwestię (na planecie LO nigdzie nie widziałem informacji o tym, że następną wersją będzie 4.0) oraz rozmowę na temat, co to dla nas wszystkich oznacza. Na wydawanie opinii i dochodzenie do konkluzji jeszcze mamy czas.

Co do Roba Weira — czytałem te jego artykuły, tak samo jak parę wiadomości na listach dyskusyjnych. Dla mnie jego zachowanie nie jest nawet warte komentarza i stanowi podręcznikowy przykład źle rozumianej konkurencji. Zamiast skupiać się na zaletach produktu A, próbuje się zgnoić produkt B. Jest to tym smutniejsze, że Weir został wyróżniony stanowiskiem przewodniczącego komitetu OASIS ds. otwartego formatu plików dla aplikacji biurowych.

[Jactra]

Sorry jestem laikiem.
O co chodzi z tą wsteczną kompatybilnością API/ABI ?

[Minio]

API to interfejs programistyczny udostępniany przez aplikację (LibreOffice), wykorzystywany przez makra oraz rozszerzenia.

Wsteczna kompatybilność to inaczej stabilność API, jego niezmienność. Jeżeli API jest wstecznie kompatybilne, to znaczy że rozszerzenia i makra napisane z myślą o starszej wersji LO/OOo będą nadal działać w wersji aktualnej. Zerwanie wstecznej kompatybilności oznacza, że starsze rozszerzenia mogą przestać działać — trzeba je poprawić zgodnie ze zmienionym API.
Im mniej stabilne API (im częściej się zmienia), tym więcej czasu i energii musi poświęcić twórca na utrzymanie swojego programu.

Dla użytkowników, którzy nie używają żadnych dodatkowych makr ani rozszerzeń (czyli prawdopodobnie przytłaczającej większości), wprowadzana zmiana nie ma absolutnie żadnego znaczenia. Jest ona natomiast ważna dla programistów makr i rozszerzeń oraz firm, które z większym prawdopodobieństwem mają własne makra ułatwiające realizację często wykonywanych czynności.

ABI to interfejs binarny udostępniany przez aplikację. Na dość podstawowym poziomie (na którym się tutaj zatrzymuję) różnice między API a ABI można pominąć. Zmiany ABI będą dotyczyć jeszcze bardziej wąskiej grupy użytkowników niż zmiany API.

[Jactra]

Minio dzięki za odpowiedź.

Czyli wychodzi na to, że "zwykłych" użytkowników tak naprawdę to nie dotknie.
Natomiast może "dotknąć" firmy, które robią własne wydania (jak OpenOffice Softwore lub UX) ?

[Minio]

Tak, dla „zwykłych” użytkowników ta zmiana nie powinna mieć większego znaczenia.
Ma zaś znaczenie dla firm i programistów.

[quest-88]

Nie mogę się też oprzeć wrażeniu, że TDF przestraszyło się nadchodzącego AOO w wersji 4.0 i tego, że dla części użytkowników mniejszy numer będzie się kojarzył z produktem gorszej jakości.

Minio, a skąd wieści o wydaniu 4.0? Czy przypadkiem następna wersja to nie powinno być 3.5?

https://cwiki.apache.org/confluence/dis ... ease+Notes

Wydaje mi się, że w tym przypadku to Apache byłoby w tyle (AOO 3.5 vs Libre 3.7/4.0)

Poza tym wiki informuje, że nowe wydanie powinno zostać spolonizowane, a widzę, że Pootle u nich leży nieruszone przez nikogo.

[Jan_J]

Tak, dla „zwykłych” użytkowników ta zmiana nie powinna mieć większego znaczenia.

Ma znaczenie, jeżeli mają śmiałość pisania i używania własnych makr.

Doceniam skrypty ułatwiające pracę, choć przyznać trzeba, że ich przygotowanie i uruchomienie może co nieco kosztować. Zachęcam też do podejmowania takich działań. Pytanie, czy świadomość horyzontu czasowego rzędu kilku lat dot. bezproblemowego życia skryptu zachęca czy zniechęca do poszukiwania takich usprawnień? w skali np. małej firmy? Mnie by zniechęcała...

Jako niepoprawny marzyciel wolałbym, żeby API było stabilne, “solid as rock”, a tym samym ugruntowane w tradycji i niemal wieczne. Jak POSIX. Tyko że na taki stan trzeba sobie zapracować. I jeszcze mieć trochę szczęścia.

Mimo wszystko nie odżegnywałbym od czci i wiary zespołu, który chce coś sensownie popchnąć do przodu.

[Jan_J]

Poza tym wiki informuje, że nowe wydanie powinno zostać spolonizowane, a widzę, że Pootle u nich leży nieruszone przez nikogo.

Rozumiem to jako wynik inwentaryzacji zasobów...

[Minio]

quest-88: masz rację, następna będzie 3.5. Pisali o tym nawet przy okazji ogłoszenia wydania 3.4.1. Na swoje usprawiedliwienie mam tylko tyle, że rozwoju AOO nie śledzę zbyt dokładnie i w tych informacjach, które do mnie docierały, była mowa wyłącznie o 4.0. Nie padały tam żadne konkretne daty, ale dopowiedziałem sobie, że właśnie ta wersja będzie następna.

Jan_J: ale kto mówi o odżegnywaniu od czci i wiary? W pierwszej wiadomości być może faktycznie nie położyłem na to odpowiedniego nacisku, ale wydawało mi się, że druga już daje pełną jasność jeżeli chodzi o moje stanowisko. Krytykować będę jak LO 4.0 ujrzy światło dzienne, teraz chcę tylko porozmawiać, wymienić się poglądami i puścić wodze fantazji.

[Jan_J]

ale kto mówi o odżegnywaniu od czci i wiary?

wychodzi na to, że ja...
Nie miałem na myśli przypisywania Tobie ani nikomu takich intencji. Zbędna klisza retoryczna.

Chciałem tylko napisać, że trochę ich rozumiem.

[Jactra]

Jednak wszystko wskazuje na to, że Apache OpenOffice w następnej wersji jednak będzie 4.0 http://www.h-online.com/open/news/item/ ... 48413.html

[quest-88]

Co więcej, strona wydania LibreOffice 3.7 jest przekierowana na "4.0".

http://wiki.documentfoundation.org/ReleaseNotes/3.7

A więc czekamy na AOO 4.0 i LibreOffice 4.0.

[Jactra]

Oj żeby nam użytkownikom "nie odbiło się to czkawką"....

[quest-88]

Hej!

Śpieszę poinformować, że od zeszłego weekendu ekipa tłumaczy pracuje nad polonizacją czwórki.

Chętni mogą się zarejestrować w Pootle i słać sugestie (prawo do akceptacji sugestii posiada grupa "nadzorców" w tym ja, raknor i jeszcze paru tłumaczy)

https://translations.documentfoundation.org/pl/libo_ui/

Zachęcam różne mądre głowy do współpracy, bo sami nie jesteśmy omnibusami.

Pomocny może tu okazać się być słownik referencyjny Microsoftu.

http://www.microsoft.com/Language/en-US/Search.aspx

W wyszukiwarce należy wybrać język (polski) oraz produkt (Office System. Uwaga! Nie należy wybierać opcji "Excel"!)

***

I tak przy okazji. @Minio, @Jan_J, @inni. Orientujecie się może co nam daje ta zmiana?

New Widget layout technique for dialog windows introduced, and converted various dialogs; see WidgetLayout. (Caolán McNamara, Gokul)

(It would be nice to have a short and easily understandable explication of the advantages of the Widget layout for the developers, and of possible advantages for the users.)

I tu masa brzydkich zrzutów, która doskonale oddają zmiany: http://wiki.documentfoundation.org/Deve ... dgetLayout

W ogóle nie rozumiem jaki jest sens "zawężania" okien (tj. podejrzewam, że to po prostu efekt zmian, a nie cel sam w sobie), ale ta ich zmiana wymusza ponowne tłumaczenie tych samych dialogów.

[Minio]

I tak przy okazji. @Minio, @Jan_J, @inni. Orientujecie się może co nam daje ta zmiana?

New Widget layout technique for dialog windows introduced, and converted various dialogs; see WidgetLayout. (Caolán McNamara, Gokul)

(It would be nice to have a short and easily understandable explication of the advantages of the Widget layout for the developers, and of possible advantages for the users.)

Z tego co ja rozumiem, podstawowe zalety to:
- odseparowanie wyglądu okienek od interfejsu programistycznego, tzn. aby skonstruować okienko, nie musisz nawet wiedzieć czym jest C++. Dotychczas nie było to możliwe, co znacząco utrudniało pracę designerów (stworzenie działających makiet wymagało umiejętności programowania). Teraz UI okienek będzie zawarte w plikach XML, które można modyfikować przy pomocy glade.
- powyższe jednocześnie oznacza wizualny edytor dla okienek. Dotychczas ostateczny wygląd okienek był znany dopiero po kompilacji programu. Wprowadzanie drobnych poprawek, zwłaszcza metodą prób i błędów, było niezwykle czasochłonne (kompilacja LO nie zajmuje pięciu minut)
- dotychczas miejsce na wszystkie ciągi znaków było ustawione na sztywno. Oczywiście te same frazy w niektórych językach da się wyrazić krócej niż w innych, w związku z czym miejsce trzeba było dopasowywać do „najdłuższych” języków. Traciły na tym języki „krótsze”, takie jak angielski, które miały bardzo dużo światła w okienkach (najwyraźniej wg niektórych za dużo). Być może oznacza to także możliwość ręcznej zmiany rozmiarów okienek (co aktualnie nie jest możliwe).

I to jest chyba najbardziej widoczna zmiana z punktu widzenia użytkowników. Reszta jest widoczna tylko dla programistów oraz designerów, którym teraz będzie łatwiej pracować.

Nawiasem mówiąc, być może dzięki wykorzystaniu XML do opisu okienek możliwe będzie włączenie do Pootle „podglądu” umożliwiającego obejrzenie danego ciągu znaków w jego naturalnym kontekście. Gdzieś (planeta? listy mailingowe?) ostatnio czytałem, że jest to popularny feature request.

[lukjan]

fajne by bylo, aby instalator byl po jednym jezyku

[quest-88]

Te WidgetLayout to straszna lipa. Nie wiem jakim cudem to przeszło, ale już tęsknię za starymi okienkami. Teraz treść jest zbita i mocno nieczytelna.

[lukjan]

na pewno jeszcze poprawia

[Jan_J]

Jak się to dobrze zrobi, będą łatwiejsze do zarządzania i po stronie treści, i stylu.

[quest-88]

Te WidgetLayout to straszna lipa. Nie wiem jakim cudem to przeszło, ale już tęsknię za starymi okienkami. Teraz treść jest zbita i mocno nieczytelna.

Załącznik WidgetLayout.png nie jest już dostępny

Wczoraj wydano stabilną wersję LibreOffice 4.0. Oprócz podobnych artefaktów, można przyuważyć bardzo szerokie okna dialogowe. Przykład to okno edycja stylu Domyślnie lub edycja stylu akapitu, który zajmuje ponad połowę wysokości ekranu i około 90% w szerokości. Winę za to ponosi mechanizm dostosowywania szerokości przycisków do najdłuższej frazy. Więc jeśli "Reset" to "Ustawienia domyślne", to "OK", "Anuluj" i inne będą tak samo szerokie jak szeroki jest najdłuższy przycisk. Efektem tego jest jeden bardzo długi pasek przycisków, który rozwala okno dialogowe. Ku potomności dodam jeszcze, że linia 3.6 i starsza posiada sztywny interfejs z dwoma poziomami przycisków.

Problem zgłosiłem na dobę przed wydaniem RC3, który jak wiemy, jest wersją stabilną. Po lobbingu tu i tam, problem został rozwiązany, jednakże łatka trafi (powinna) dopiero do LO 4.0.1, a więc za miesiąc. Jutro powinno pojawić się pierwsze RC. Oto efekty:

Moja przestroga brzmi: jeśli używasz rozdzielczości ekranu 1024x768 px bądź podobnie niskiej, niektóre okna mogą wystawać poza obrys ekranu. Jeśli uważasz to za zbyt irytujący błąd, wstrzymaj się z aktualizacją jeszcze miesiąc.

Dochodzimy tu też do smutnej konkluzji. Siła rażenia tego błędu jest ogromna. Po prostu nie dało się go przeoczyć. Dlaczego więc łatka nie pojawiła się w wydaniu 4.0? Założyłem, że na pewno ktoś inny zgłosił taki oczywisty bubel (w ostatnim czasie pracuję po 12-15 godzin, więc darowałem sobie "oczywistości"). Jednak po testach kilkudziesięciu dziennych kompilacjach i dwóch RC, zdenerwowany brakiem zmian, sam zgłosiłem błąd. Co się okazało? Nikt go nie zgłosił przede mną. Czy to oznacza, że nie ma innego Polaka prócz mnie, który zająłby się QA LibreOffice? :<

[Minio]

Dochodzimy tu też do smutnej konkluzji. Siła rażenia tego błędu jest ogromna. Po prostu nie dało się go przeoczyć.

To samo dotyczy nowego menedżera szablonów. W ciągu ledwie kilku minut jego używania znalazłem kilka mniej lub bardziej rzucających się w oczy błędów (po wejściu do katalogu nie ma opcji importu; w podglądzie szablonu są widoczne paski narzędziowe edytora; tworzenie nowego katalogu jest trudne, a z okna "Plik → Zapisz jako szablon" niemożliwe; okruszki nie aktualizują się po zmianie karty — pełna lista tutaj: http://goo.gl/mXka0 ). I zacząłem się zastanawiać — czy ktoś w ogóle tego używał w trakcie testów alpha i beta?

Czy to oznacza, że nie ma innego Polaka prócz mnie, który zająłby się QA LibreOffice? :<

Niestety, jest to bardzo możliwe.
Osobiście staram się pomóc, ale wysyłam tylko zgłoszenia tego, co przeszkadza mi na mojej maszynie „produkcyjnej”. Nie mam czasu na testowanie wersji alpha i beta. Miałem na testowym systemie zainstalowane kilka migawek nocnych, ale tam nawet nie instalowałem języka polskiego.


Wracając zaś do głównego wątku: w innym temacie Jan pochwalił obsługę kerningu w fontach OpenType. Ja zaś chciałem pochwalić wprowadzenie nowego silnika wyrażeń regularnych (opis składni). Wreszcie mamy zachłanne i niezachłanne dopasowania oraz (negative|positive) look(ahead|behind). Tworzenie wyrażeń negatywnych („wszystko byle nie X”) stało się faktem. Jak dla mnie to prawdziwy killer-feature nowej wersji.

A żeby zakończyć bardziej refleksyjnie:
Biorąc pod uwagę, jak istotne zmiany są podbierane z AOO (nowy silnik wyrażeń regularnych, nowa implementacja funkcji RAND(), generowanie wykresów wyższej jakości, zakończenia linii o których już na forum rozmawialiśmy), wydaje mi się że odcinanie się LO od kodu AOO byłoby dla tego pierwszego strzałem w stopę.

[Jan_J]

Jan pochwalił obsługę kerningu w fontach OpenType

Brrrr, muszę się odciąć. Pochwaliłem po pobieżnym sprawdzeniu, że szerokość kernowanego tekstu jest nareszcie wyraźnie mniejsza niż niekernowanego.
To znaczy coś drgnęło, ale jest niestabilne. Kerning pojawia się i znika, ale nawet kiedy jest, nie mam pewności czy jego metryka jest zgodna z tablicami fontu.
W logach jest mowa o uwzględnieniu niektórych typów kerningu dla niektórych języków nieeuropejskich. Może zaobserwowałem tylko efekt uboczny?