Kategoria: SharpOffice

    Korzystanie z innych projektów

    Mój projekt nie jest wielką innowacją. Istnieje już całkiem sporo narzędzi do pisania tekstu, ale dzięki temu mam na czym się wzorować. Jest MS Office, OpenOffice, AbiWord, WPS Office i wiele innych.

    Skoro istnieją aplikacje podobne do mojej to czemu nie miałbym trochę z tego skorzystać? Korzystając z dobrodziejstw projektów open-source’owych, mogę zobaczyć jak dana funkcjonalność została zaimplementowana.

    Czytaj dalej Korzystanie z innych projektów

    Testy z F#

    Już od jakiegoś czasu miałem oko na spróbowanie F#. Połączenie szybkiego programowania funkcyjnego wraz z potężną biblioteką .NET brzmi bardzo fajnie i takie jest w rzeczywistości.

    Zobaczyłem, że NUnit ma w swoich przykładach projekt w F#, więc postanowiłem przepisać moje obecne testy na F#. Nie przewidziałem jednak trudności wynikających z nieznajomości tego języka…

    Czytaj dalej Testy z F#

    Testy jednostkowe z NUnit i Moq

    Dotychczas nie pisałem testów (jakoś kod testowałem ręcznie) i odkrywam jak bardzo są pożyteczne. Po pierwsze i najważniejsze, umożliwiają wykrycie błędów w implementacji klas zanim zaczniemy ich używać.

    Tworząc nowy projekt testów w Visual Studio dostajemy MSTest, który nie działa pod Linuxem. W związku z tym sięgnąłem po NUnit.

    Czytaj dalej Testy jednostkowe z NUnit i Moq

    Logi z NLog

    Jest wiele sposobów na znajdowanie błędów w aplikacji: dowody matematyczne, testy jednostkowe, ręczne testowanie i debugowanie. Niestety debugowanie może być bardzo czasochłonne jeśli nie wiemy, w którym miejscu znajduje się problem. Tworzenie logów może nam pomóc zlokalizować ten problem.

    Istnieje kilka .NETowych frameworków do logowania, m.in. log4net, WisdomCloud.Log i NLog, który postanowiłem użyć w moim projekcie. Można go pobrać z NuGet:NLog.

    Czytaj dalej Logi z NLog

    Continuous Integration

    Piszemy kod, commitujemy, pushujemy. I jesteśmy potem zajęci, zapominamy o kodzie. W tym czasie ktoś stwierdza, że ściągnie sobie nasze repo. Więc klonuje, pobiera paczki, odpala build i … nie działa.

    Powyższe spowodowane jest tym, że programista nie zawsze pamięta by skompilować, uruchomić, przetestować kod po wprowadzeniu zmian. Powinien pamiętać, ale zdarza się, trudno. To jest jeden ze scenariuszy gdzie CI, czyli Continuous Integration, może pomóc.

    Czytaj dalej Continuous Integration

    IRegistrationModule - porządki w kontenerze

    Jakiś czas temu pisałem o DI i IoC oraz o tym, że będę używał kontenera do automatycznego ładowania wielu modułów podczas startu aplikacji. Początkowo zrobiłem metodę ContainerWrapper.AutoRegister(), która iterowała po wszystkich bibliotekach związanych z SharpOfficem i rejestrowała odpowiednie klasy. Ale było to dość zagmatwane, więc postanowiłem trochę to uprzątnąć.

    Czytaj dalej IRegistrationModule - porządki w kontenerze

    Menu - podejście nr2

    Dlaczego podejście drugie? Ponieważ już raz pisałem o generowaniu Menu, ale trochę w inny sposób i w innym środowisku. Wtedy po prostu tworzyłem obiekty Xwt.MenuItem. Teraz zmieniłem podejście. Interfejs IMenuElement określa minimalny wspólny interfejs obiektów menu w dowolnym frameworku jakiego będę używał. I na podstawie definicji menu złożenej z obiektów IMenuElement będę generował odpowiednią strukturę obiektów.

    Czytaj dalej Menu - podejście nr2

    WPF – zaczynamy zabawę! – metoda Main()

    Prawdę mówiąc dotychczas stworzyłem jedną aplikację w WPF-ie. Prosta gra w kamień-papier-nożyce po LAN-ie. Nie wymagała ode mnie żadnej wiedzy o tym jak się tworzy aplikacje okienkowe w XAMLu, bo miała minimalny interfejs, który wyklikałem.

    Z SharpOffice’m sprawa będzie wyglądała zupełnie inaczej. Po pierwsze ograniczę ilość XAMLa do minimum, ponieważ będę chciał dynamicznie generować zawartość okna. Jestem jednak prawie przekonany, że będę musiał napisać swoją kontrolkę (albo kilka) i tam XAML okaże się niezbędny. Będę miał również okazję pobawić się stylami, które, z tego co czytałem, potrafią zdziałać cuda.

    Ale zanim to wszytko się ogarnę, trzeba jakoś tę aplikację uruchomić.

    Czytaj dalej WPF – zaczynamy zabawę! – metoda Main()

    Cross-Platform App != Cross-Platform GUI

    W pogoni za idealnym frameworkiem do GUI, zapomniałem o bardzo ważnej rzeczy:

    Wielofunkcyjny scyzoryk nie zastąpi zestawu kluczy

    Podobnie jest z wieloma innymi wielofunkcyjnymi rzeczami (np. smartfony nie zastąpią nigdy lustrzanek), więc również z frameworkami do GUI. Zarówno Xwt jak i Eto nie mogą w pełni wykorzystywać wszystkich obsługiwanych platform, ponieważ ich celem jest zapewnienie wspólnego API do tworzenia aplikacji na wiele platform. Zamiast tego należy zrobić to co ludzie robili od dawna: oddzielić interfejs użytkownika od logiki i wyodrębnić po jednym projekcie na każdą platformę.

    Czytaj dalej Cross-Platform App != Cross-Platform GUI

    Architektura rozszerzeń

    Patrząc na aplikacje takie jak Visual Studio, czy Adobe Creative Suite, zauważyłem, że rozszerzenia mają zazwyczaj kilka wejść do programu. Podstawowym jest menu. Może to być dodatkowa pozycja w menu ,,Narzędzia”, może to być osobne menu. Jest to dosyć wygodne, ponieważ nie musimy się martwić gdzie ustawić nasz przycisk i jak powinien wyglądać.

    Kolejne punkty wejścia to toolbar (pasek narzędzi), menu kontekstowe (pod prawym przyciskiem myszy) i magiczne skróty klawiszowe (które moim zdaniem powinny mieć odpowiedniki w menu). Jak do tego podejść od strony kodu? Oczywiście przez interfejsy 😉

    Czytaj dalej Architektura rozszerzeń

    Cross-Platform GUI Toolkit

    Zacząłem mój projekt z myślą:

    ,,Napiszę darmowy, open-sourcowy, cross-platformowy pakiet Office.”

    Swego czasu zrobiłem kilka kontrybucji do TrueCrafta, który do swojego launchera używa Mono Xwt. Nie zastanawiałem się zbytnio i postanowiłem na nim oprzeć mój projekt. Okazuje się jednak, że jest on bardzo ograniczony i istnieją lepsze frameworki.

    Poszukując przykładów aplikacji, które używają Xwt (btw, nie znalazłem żadnej), natrafiłem na dyskusję. na forum .Net Foundation na temat istnienia cross-platformowego WPFu. Kilka osób przedstawiło alternatywne frameworki, które przedstawię poniżej.

    Czytaj dalej Cross-Platform GUI Toolkit

    SharpNote - pierwszy krok

    Ponieważ bardzo ciężko pisać kod ,,na sucho”, postanowiłem rozpocząć tworzenie pierwszej aplikacji. W trakcie jej pisania wyjdą na jaw prawie wszystkie elementy mojego projektu, które muszą być zdefiniowane i po części zaimplementowane. Dodatkowo będę mógł odpalić mój Runtime bez wyjątków mówiących, że czegoś mi brakuje.

    Czytaj dalej SharpNote - pierwszy krok

    Konfiguracja

    Każda większa aplikacja potrzebuje zapisywać sobie jakieś ustawienia. Aby to ułatwić wymyśliłem interfejs IConfiguration. Stwierdziłem, że niezależnie od implementacji tego interfejsu, będzie potrzebowali dwóch metod:

    Czytaj dalej Konfiguracja

    Struktura projektu

    SharpOffice to mój pierwszy duży projekt. Oraz mój pierwszy projekt open-source’owy, co oznacza, że jeśli ktoś będzie chciał mi pomóc, będzie musiał być w stanie mój kod przeczytać. Czytałem całkiem sporo o przypadkach brzydkiego, zawiłego kodu i chciałbym uniknąć tego w moich projektach. Dodatkowo mój projekt ma być zmodularyzowany, co wymusza pewne wzorce projektowe oraz powinno pomóc utrzymać fajną strukturę projektu.

    Czytaj dalej Struktura projektu

    SharpOffice - Daj Się Poznać

    Odkładam na jakiś czas pracę nad systemem operacyjnym, o którym pisałem jakiś czas temu. Takie projekty są bardzo czasochłonne i potrzebują dużego doświadczenia. Aby to doświadczenie zdobyć, postanowiłem rozpocząć drugi projekt SharpOffice. Moim zamiarem jest napisanie open-source’owego pakietu Office w C#, oraz zmodularyzowanie go w taki sposób aby łatwo było tworzyć kolejne aplikacje do pakietu, a istniejące rozszerzać wtyczkami. Biorę również udział w konkursie Daj Się Poznać, i przez następne 10 tygodni będę opisywał kolejne postępy w pisaniu SharpOffice’a. Jego kod źródłowy można zobaczyć na GitHubie

    DajSiePoznac2016

    Czytaj dalej SharpOffice - Daj Się Poznać