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]
Podobne postybeta
OpenOffice.org2GoogleDocs na Apple - pierwsze podejście ;-)
Swing i GUI znów "przeszkadzają" ;-)
Google Spreadsheest :-)
Przeszacowany Linux, Niedoszacowany Windows i Ukryty MacOS ;-) czyli o tym na jakich systemach używa się głównie OOo2GD
Soft lepszy niż dobry zwykle nie jest lepszy ;-)
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:
OdpowiedzUsuńThread.currentThread().setContextClassLoader(getClass().getClassLoader());
ale tylko wtedy (jak nie jest null, zostawiamy w spokoju).
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.
OdpowiedzUsuń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 ;-)
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.
OdpowiedzUsuń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.
Fajnie by było gdyby Sun odebrał Apple prawo używania znaku Java ;-)
OdpowiedzUsuń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 ;-(