wtorek, maja 26, 2009

Bardzo testowa wersja OOo2GD 1.7.0, która w porywach działa nawet na MacOS ;-)

Zdecydowałem się dziś wypuścić bardzo wczesną i testową wersję OOo2GD.
Różnice w stosunku do poprzedniej wersji to:
  • przekompilowana do Java 1.5, dzięki czemu można ją uruchomić na zapóźnionych systemach ;-) [użytkownicy MacOS mogą czytać niżej szczegóły]
  • zmieniona metoda wyświetlania okienek z komunikatami [użytkownicy Windows, i prawdopodobnie Linuksa i Solarisa nie powinni odczuć żadnej zmiany]
  • zmieniona lokalizacja pliku z informacją o dostępnych aktualizacjach [z http://www.przemelek.pl/gdcos.update.xml, na http://www.przemelek.pl/gdocs.update.xml]
  • Drobne zmiany w bułgarskiej wersji językowej


Wsparcie dla MacOS:
Bywa.
Testy pokazują, że na niektórych MacOS działa upload [bez konwersji z formatów niewspieranych przez Google Docs/Zoho na wspierane]. Działa pobieranie, ale są problemy z otwieraniem pobranych plików w OO.org.

Możecie spytać po co publikuję taką nie do końca działającą wersję.

Odpowiedź jest prosta ;-) Nie mam Maca [i patrząc na zachowania Apple'owej Java'y zaczynam się z tego powodu cieszyć ;-)] nie mogę więc prowadzić developmentu tak jakbym chciał, stąd konieczne są testy [w których mam pomoc, jednak jeden MacOS to trochę za mało]. Dlatego będę wdzięczny za wszelkie opinie, które najlepiej zostawiać w komentarzach do tego posta :-) [na moim blogu, jeżeli czytacie to przez jakiś agregator]

Download [nie pobieraj tej wersji! Pobierz nową :-)]


Podobne postybeta
OpenOffice.org2GoogleDocs na Apple - pierwsze podejście ;-)
Swing i GUI znów "przeszkadzają" ;-)
Przeszacowany Linux, Niedoszacowany Windows i Ukryty MacOS ;-) czyli o tym na jakich systemach używa się głównie OOo2GD
Google Spreadsheest :-)
OO.org i Google Docs bez konwersji są tuż tuż ;-)

4 komentarze:

  1. Czy Ty czasem nie masz problemów z JAXB itd.? Przeżyłem piekło z Javą z Apple'a, ale udało się w końcu rozwiązać problem - trzeba podrasować classloadera - zdaje się, że w niektórych makowych wersjach Javy 1.5 classloader kontekstowy == null i wtedy trzeba go zmienić tak:

    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());


    ale tylko wtedy (jak nie jest null, zostawiamy w spokoju).

    OdpowiedzUsuń
  2. To już robię, głównie zresztą z powodu architektury OO.org. OO.org ma jedną instancję JVM dla wszystkich rozszerzeń i to sprawia czasem kłopoty, szczególnie ze Swingiem, bo jak Swingowy EDT wystartuje wcześniej niż rozszerzenie [mówiąc inaczej, EDT zostanie uruchomione przez inne rozszerzenie] to bez ustawienie contextu dla ClassLoadera nasz kod wykonywany przez EDT [czyli wszystko wywoływane przez akcje w GUI] nie widzi bibliotek. Dlatego teraz wszystkie operacje uruchamiane z GUI w OOo2GD działają w osobnych wątkach odpalanych z contextem ClasLoadera który był przypisany do wątku odpalającego główną klasę rozszerzenia.

    W moich problemach z MacOS chyba chodzi o coś jeszcze bardziej szalonego.
    Np. gdy JOptionPane.showMessageDialog dostanie null jako rodzica to głupieje na Apple totalnie i potrafi wyświetlić okienko w jakimś dziwnym miejscu, lub go nie wyświetlić.
    Dodatkowo coś źle działa w SDK do OO.org na Mac OS, próba squerowania UnoRuntime o XComponentLoader.class albo [bo już nie pamiętam szczegółów] zawołanie na instancji XComponentLoader metody loadComponentFromURL powoduje totalny zwis OO.org i nie ma przeproś, dlatego jak na razie jedyną działającą metodą otwarcia dokumentu na Mac OS jest exec z Runtime ;-)

    W ogóle piękne jest to, że OO.org na Mac OS pozwala na ustawienie JVM na Java 6, i nawet jakby na początku go używał [w momencie sprawdzania, które menu mają być włączone], ale do wykonywania kodu rozszerzeń używa innej maszyny, tej dla Java 5, bo OO.org jest skompilowany w 32 bitach, a Java 6 jest tylko 64 bitowa.....

    Wiem też, że ostatnia wersja testowa w niektórych systemach nie działa, a w innych działa i nie umiem dopatrzeć się jakiegoś patternu ;-)

    OdpowiedzUsuń
  3. Pewnie, że nie ma patternu, bo Java 1.5 na makach jest za każdym razem inna: pod 10.4 zachowuje się inaczej niż pod 10.5. I nie wiadomo, czemu tak się dzieje.

    Ale takiego kosmosu ze Swingiem to całe szczęście nie mieliśmy. I na razie nikt się nie skarży, tyle że w Javie 5 jest ograniczenie, przez które i tak okienko dla polskiego i francuskiego nie zadziała (mamy za dużo elementów, bo jest na twardo limit 512 ustawiony). W skrajnym wypadku możesz próbować użyć AWT z OOo, to wtedy będziesz miał "native l&f", ale za to połapanie się w tym API do najprzyjemniejszych zadań nie należy. No i nie ma możliwości stworzenia własnych widgetów, przez co dla mnie to odpada.

    OdpowiedzUsuń
  4. Fajnie by było gdyby Sun odebrał Apple prawo używania znaku Java ;-)

    Nie wiem jak wygląda wasz kod, ale z tego co widziałem problem jest wtedy gdy z kodu wykonywanego przez EDT próbuje się pierwszy raz załadować klasy z plików JAR [czyli te, które są na classpath], bo są one wtedy poza kontekstem ClassLoader'a przypisanego do EDT, a nie wypada zmieniać kontekstu wątkowi EDT bo wtedy inne rozszerzenie może przestać działać ;-)
    512 okienek to jednak dość dużo ;-) i trudno mi sobie wyobrazić aplikację która ma aż tyle okienek :-)
    W moim przypadku AWT mnie nie ratuje, bo EDT jest wątkiem AWT ;-(

    OdpowiedzUsuń