MD Tech Blog

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.

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ć.

Przez ostatnie dwa tygodnie na blogu zapanowała cisza. Spowodowana była ona moim wyjazdem do Włoch na międzynarodowy turniej w Quidditchu. Razem z moją drużyną Warsaw Mermaids pojechaliśmy do Gallipoli aby uczestniczyć w tegorocznej edycji Pucharu Europy.

Nie byliśmy jedyną polską drużyną na turnieju. Oprócz nas przyjechała drużyna Kraków Dragons, która wygrała tegoroczne Mistrzostwa Polski w Quidditchu. Organizatorzy zadbali aby żadne drużyny z tego samego kraju nie walczyły ze sobą w potyczkach grupowych, więc nie mieliśmy okazji się zrewanżować za przegraną na krajowych mistrzostwach. Ale i tak było niesamowicie 😉

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ę.

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 😉

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.

Tak jak napisałem w tym poście, zacząłem pracować nad pierwszą aplikacją pakietu, SharpNote’em. Nie bardzo wiem, z której strony ten wielki program ugryźć, więc zacząłem od czegoś prostego - Menu.

Czasami pisząc kod stwierdzamy, że chcemy w jakiś sposób opisać nasze typy w taki sposób, aby można było się do tego odnieść w kodzie. Z pomocą przychodzą nam dwie funkcjonalności .NETu: Reflection i atrybuty.

Czym są atrybuty?

+

Niedawno brałem udział w hackathonie DevMuster organizowanym w PJATK. Tematyka obejmowała tworzenie rozwiązań w dwóch kategoriach: dla studentów i dla seniorów. Mój team postawił na aplikację łączącą seniorów chcących dzielić się wiedzą z juniorami szukających jakichś informacji.

Początkowo chcieliśmy pracować w Django, ale moja znajomość Pythona jest znikoma, więc po 3 godzinach wywaliliśmy cały projekt i zaczęliśmy od nowa w ASP.NET MVC. Trochę się pomęczyliśmy, ja zdobyłem nowe doświadczenia z Entity Framework, no i wyszło coś takiego.

A gdzie AJAX?

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.