Skóra na zawołanie

Wszystko, co w Longhornie będzie związane z wyświetlaniem obrazu, ma się istotnie różnić od tego, co znamy dziś. Działanie odpowiedzialnych za wyświetlanie komponentów Avalon przypomina potoki wykorzystywane w DirectX czy OpenGL. Na różnych etapach renderowania programista możne nakładać na obraz "filtry" lub definiować funkcje. Przykładowo, aby obrócić obiekt, wystarczy "dodać" odpowiednią transformację, a nie zmieniać jego współrzędne. Będzie to o tyle łatwe, że Avalon niemal wyłącznie wykorzystuje grafikę wektorową. Założenia są takie, że Longhorn nie będzie działał na komputerach bez akceleratora graficznego. Aplikacje Windows Forms niejako automatycznie mogą wykorzystywać możliwości Avalon.

Interfejs aplikacji mającej działać na platformie Longhorn będzie można zdefiniować na dwa sposoby: tradycyjnie, oprogramowując zdarzenia związane z zestawem obiektów, lub za pomocą XAML specjalnego języka. XAML będzie pełnić rolę podobną do kodu HTML osadzonego na stronie ASPX (ASP .Net). Określa on wygląd interfejsu, a równocześnie definiuje obiekty dostępne dla kodu działającego "w tle", który określa zachowanie się okna.

Kod XAML to jedynie prostszy sposób opisu wyglądu interfejsu. Wyglądu, lecz niekoniecznie zachowania. XAML pozwala bowiem całkowicie oddzielić projektowanie wyglądu interfejsu od opisu jego działania. Projektant i programista nie muszą się więc nawzajem ograniczać. Pomiędzy konstruowaniem obiektów UI w kodzie (jak dotychczas) a zapisaniem ich w XAML ma nie być różnic w wydajności - XAML będzie można kompilować. Poza tym schemat obiektowy znaczników w XAML dokładnie odpowiada temu, który jest wykorzystywany w WinFX.

Microsoft zapowiada wprowadzenie w Longhornie wielu nowych standardowych kontrolek wizualnych. W nowym systemie pojawią się także elastyczne mechanizmy automatycznego rozkładania elementów w formatce. Oprócz znanego z Javy mechanizmu "pojemników", w których elementy są automatycznie rozkładane zgodnie z określonym algorytmem, w Longhornie pojawią się rozwiązania pozwalające precyzyjnie sterować rozkładem obiektów. Przykładowo, budowa interfejsu z trzema kolumnami sprowadza się do kilku przewidzianych w tym celu znaczników w XAML. Praktycznie wszystkie kontrolki Avalon będą dostosowane do pracy asynchronicznej. Dzięki temu (i przy odrobinie wysiłku ze strony programisty) interfejs nie będzie "zamrażany" np. w momencie wypełniania kontrolki danymi.

Dzięki architekturze zorganizowanej w potok Avalon pozwala, by praktycznie każdy element interfejsu mógł być zdalnie "przygotowywany". Komputer zdalny wygeneruje ciąg poleceń, które Avalon zrealizuje lokalnie. Zestaw takich poleceń jest bardzo bogaty i niewiele różni się od tego, jaki jest zawarty w XAML. Wśród operacji "zdalnych" znajdą się m.in. manipulacje kolorem, uruchomienie wyświetlania strumienia wideo i wiele innych.

Kontrolka w dobrej roli

W system Longhorn po raz pierwszy Microsoft wbudował specjalny framework upraszczający definiowanie ogólnej struktury okna aplikacji. Programista może np. określić, w jakich miejscach mają się pojawiać kontrolki o ustalonych "rolach", a dopiero w kolejnym etapie definiować ich wygląd.

Przykładowo, może ustalić, że w danym miejscu użytkownik wprowadza datę, a potem zdecydować, czy data ma być wprowadzana w polu tekstowym, czy wybierana z rozwijanej listy. Wspomniany framework pozwala także określać domyślne zachowania kontrolek o określonych "rolach". Przykładowo, wszystkie elementy służące do wprowadzania danych w momencie najechania na nie wskaźnikiem myszy mają zmienić wygląd i nie trzeba będzie tego określać oddzielnie dla każdej kontrolki jak w Win32.

Uproszczono nawigację po elementach okna/dokumentu. Zamiast znanej z Win32 płaskiej struktury, w WinFX jest w pełni hierarchiczna struktura obiektów. W Avalon występuje nowy typ okna/dokumentu będący czymś pomiędzy kreatorem a oknem przeglądarki internetowej. Użytkownik porusza się po interfejsie za pomocą przycisków następny/poprzedni (tak jak w przeglądarce). System automatycznie dba o zapisanie stanu poszczególnych etapów, toteż od strony programisty taki interfejs nie wymaga wiele pracy. W obecnie dostępnej wersji Whidbey nie ma narzędzia, które pozwoliłoby "ułożyć" takie okna w odpowiedniej kolejności. Z różnych wypowiedzi przedstawicieli Microsoftu wynika jednak, że może ono pojawić się w kolejnych wersjach beta Visual Studio.

O ile w API Win32 większość wymiarów była określana w pikselach, o tyle w Longhorn są stosowane "normalne" wymiary - centymetry czy cale, co zapewnia taki sam rozmiar obiektów bez względu na rozdzielczość urządzenia. Avalon pozwala także w ogóle zrezygnować z określania wymiarów obiektów. Oprócz wspomnianych klas automatycznie "rozkładających" elementy w oknie, w ramach dokumentu można zdefiniować tzw. text reflow, czyli zasady prezentowania tylko obiektów tekstowych. Co więcej, można łączyć elementy tekstowe np. z grafiką. Wraz z wprowadzeniem czcionek OpenType maję się pojawić nowe elementy typograficzne, w tym ligatury (zbitki literowe).