Programy Aionela
Solidne, darmowe oprogramowanie dla każdego
www.aionel.net
GłównaMisjaAktualizacjeHistoriaObjaśnieniaPodziękowaniaMapa
Wstęp ProgramyGryWygaszacze CzcionkiWtyczkiSkórkiProgramowanieInne
ArtykułyFilmyD.netPocztówkiKrówki
O mniePublikacjeNagrodyUżytkownicyKontakt
ŁączaKsięgaSonda Kanał RSS
Wizualne Style Windows
Odrobina historii
Przed premierą systemu Windows XP w prasie branżowej zachwycano się jego nową funkcjonalnością. Wspominano o wielu aspektach takich jak: większa stabilność, nowe programy narzędziowe dostarczane wraz z system, zaczerpnięte z rodziny NT elementy - system plików NTFS czy uprawnienia użytkowników. Jedni pisali o jednym, inni o czym innym, ale jeden element nie został pominięty w niemal każdym artykule poświeconym nowemu systemowi operacyjnemu Microsoftu. Chodzi tu niewątpliwie o obsługę tzw. Wizualnych Stylów. Wizualne Style umożliwiają zmianę wyglądu typowych elementów interfejsu uruchamianych aplikacji (przyciski, pola wyboru, pola edycji itd.), podobnie jak "skórki" pojawiające się już dużo wcześniej w wielu popularnych aplikacjach, takich jak np. Winamp. Wizualne Style już przed premierą systemu stały się raczej kontrowersyjnym jego składnikiem. Niektórzy uważali je za element który należało wprowadzić już dawno, aby urozmaicić używany przez ponad sześć lat - w systemie Windows 95, 98, ME, NT4 i 2000, a w rzeczywistości w lekko prostszej formie także w Windows 3.x - interfejs. Inni jednak twierdzili, że to tylko typowy "fajerwerk" jakim światowy potentat chce zachęcić użytkowników innych systemów (o nowocześniej wyglądającym interfejsie) do korzystania z własnego produktu. Takie było także i moje zdanie, dopóki infantylny styl wprowadzony w systemie Windows XP nie został wyparty przez estetyczny i przyjemny dla oka styl dostarczany z Windows Vista. Ale to już zupełnie inna historia...
Aplikacje jedno, a system drugie
W edycjach systemu Windows obsługujących Wizualne Style można spotkać się dosyć często z dziwnym problemem. Kiedy obsługa Wizualnych Stylów jest aktywna, część programów, ba nawet składników systemu, używa klasycznego interfejsu znanego z systemów Windows 95 - 2000. Jedynie obramowanie ich okien, paski przewijania oraz menu główne zmieniają wygląd na pasujący do wybranego stylu. Dlaczego tak się dzieje? Okazuje się, że Microsoft planując wprowadzenie Wizualnych Stylów w Windows XP napotkał pewien problem, a zastosowana metoda jego obejścia skutkuje właśnie obecnym stanem. Aby zrozumieć to dokładnie, należy się zagłębić w mechanikę działania tego elementu systemu. Otóż elementy interfejsu tworzone są poprzez odwoływanie się aplikacji do specjalnej biblioteki zawartej w pliku CommCtrl.dll (wersja dla wstecznej kompatybilności z aplikacjami 16-bitowymi) bądź ComCtl32.dll (wersja dla programów 32-bitowych). Nazwa pliku to skrót od Common Controls. Biblioteka ta udostępnia funkcje umożliwiające tworzenie tzw. kontrolek, czyli elementów interfejsu takich jak np. przyciski czy pola edycji. W takim przypadku za cały proces rysowania utworzonej kontrolki odpowiada system. Niestety starsze systemy z rodziny Windows (m.in. wersja 3.x) nie posiadały wielu kontrolek znanych z równolegle rozwijanych systemów, takich jak paski postępu czy suwaki. Braki te uzupełniono w Windows 95. Niemniej nowe elementy posiadały pewne wady, np. pasek postępu był statyczny i nie nadawał się do informowania użytkownika o postępie procesu, w przypadku którego czas pozostały do jego ukończenia był trudny do przewidzenia. Podobnie systemowe suwaki informowały aplikację o zmianie swojej pozycji co każdy piksel, natomiast niemożliwe było uzyskanie informacji o rozpoczęciu bądź zakończeniu przeciągania. Wymieniać inne, podobne wady można by jeszcze długo. Jak więc widać, twórcy oprogramowania napotkali dwie podstawowe przeszkody w używaniu niektórych systemowych kontrolek - zostały one albo zbyt późno wprowadzone do systemu, a kiedy już nawet je dodano to były mocno wybrakowane. Ale przecież elementy klasycznego interfejsu są bardzo proste - większość kontrolek systemowych składa się z kilku linii, które przy zachowaniu odpowiedniej kolorystyki dają wrażenie głębi. W końcu typowy przycisk to jedynie cztery linie w odpowiednich kolorach. Pobierając więc odpowiednie kolory od systemu i rysując go ręcznie - tak aby wyglądał jak standardowa systemowa kontrolka - omijało się kilka problemów pojawiających się w systemie, zaś użytkownik programu nie widział żadnej różnicy. Z tego względu wielu programistów zaczęło używać własnych kontrolek, za których rysowanie w pełni odpowiadała tylko i wyłącznie dana aplikacja. Zresztą nie tylko programiści byli winni takiemu stanowi rzeczy. Rodzina Windows 9x (95, 98, ME) posiadała jeszcze jeden problem - ograniczoną liczbę tzw. Zasobów Systemowych. System rezerwował pewien, bardzo mały obszar pamięci na przechowywanie tzw. uchwytów - liczb jednoznacznie identyfikujących elementy takie jak okna, kontrolki, otwarte pliki, zainstalowane czcionki itp. Im więcej systemowych kontrolek zawierały aplikacje, tym mniej pozostawało wolnych Zasobów Systemowych. Wyczerpanie limitu Zasobów Systemowych prowadziło do utraty stabilności przez system. Aby ominąć z kolei ten problem, praktykę ręcznego rysowania niektórych kontrolek (kontrolki rysowane ręcznie używają mniej Zasobów Systemowych) stosowały za plecami programistów same środowiska programistyczne zawierające mechanizmy przyspieszające projektowanie interfejsu (np. rodzina Delphi/C++ Builder).
Wyjście z sytuacji
Wróćmy jednak do Microsoftu. Rysowanie ręczne kontrolek rozwiązywało szereg problemów o których wspominałem wcześniej. To co było jednak bardzo wygodne dla autorów oprogramowania stało się przekleństwem dla ludzi projektujących obsługę Wizualnych Stylów w Windows XP. Gdyby Wizualne Style były automatycznie aplikowane wszystkim uruchamianym programom, w części z nich można było by dostrzec dziwaczny problem. Otóż użyte w danej aplikacji prawdziwe kontrolki systemowe były by automatycznie rysowane przez system, a co za tym idzie wyglądem odpowiadały by elementom zawartym w wybranym przez użytkownika stylu. Jednak kontrolki utworzone przez autorów oprogramowania były by dalej ręcznie rysowane przez aplikację i wyraźnie odróżniały by się od innych elementów systemu. Wyobraźmy sobie już przytaczany wcześniej przykład z suwakami. Przy takim rozwiązaniu, można było by napotkać sytuację, w której powiedzmy w pewnym programie w miejsce suwaków których pozycja nie wnosi na bieżąco żadnych zmian zastosowano systemowe kontrolki, jednak w stosunku do suwaków które odpowiadają za zmiany wiążące się z czasochłonnymi obliczeniami przeprowadzanymi w tle, użyto kontrolek specjalnie zaprojektowanych na potrzeby tego programu. W występujących dotąd warunkach (czyli pod starszymi systemami, bądź w nowszych przy wyłączonych Wizualnych Stylach) taki zabieg był by nie do odróżnienia, jednak aplikacja z aktywnymi Wizualnymi Stylami wyglądała by dosyć komicznie. Aby zapobiec takim problemom Microsoft wpadł na ciekawe rozwiązanie. Otóż Wizualne Style (nie licząc przytaczanych już wcześniej obramowań okna) stosowane są automatycznie tylko do tych programów, które "wyraziły na to zgodę". Te programy jednak, które "zgody na to nie wyraziły" pomimo włączonych Wizualnych Stylów używają klasycznego interfejsu, jednak z kolorystyką dostosowaną do wybranego stylu. W efekcie programistyczne sztuczki zastosowane w niektórych starszych programach nie zepsują ich wyglądu, nowsze aplikacje zaś nie będą odbiegać wyglądem od reszty systemu - i wilk syty i owca cała.
Negocjacje z systemem
W jaki jednak sposób dany program "wyraża" bądź "nie wyraża" zgody na użycie Wizualnych Stylów? Otóż założono, że starsze aplikacje pisane były z myślą o systemach zapatrzonych jedynie w styl klasyczny. Z tego względu starsze programy automatycznie "nie wyrażają zgody" bez konieczności żadnej dodatkowej ingerencji. Wystarczy jednak, że w specjalnej sekcji pliku EXE danej aplikacji zwanej Sekcją Zasobów umieści się pewien plik, tzw. Plik Manifestu, posiadający specyficzne instrukcje uznawane za "wyrażenie zgody". Pliki Manifestu zapożyczone zostały z technologii .NET rozwijanej aktywnie przez Microsoft. Nie wchodząc w szczegóły, oprogramowanie tworzone z użyciem tej technologii miało na dobre wyprzeć "tradycyjne" programy tworzone z użyciem technologii Win16/32 API, czyli tej - używanej do dzisiaj - w której to programy odwołują się do bibliotek systemowych udostępniających określone funkcje, tzw. API - Application Programming Interface. Programy korzystające z technologii .NET są silnie izolowane od siebie, ich pamięć zawiera wiele mechanizmów kontroli i automatycznego zwalniania, co ma w efekcie prowadzić do uzyskania większej stabilności systemu. Swego czasu, system ostatecznie wydany jako Windows 2000 a opracowywany pod nazwą kodową Windows .NET, miał posiadać 100 % składników wykonanych w technologii .NET. Jak widać tak się nie stało. Ale wróćmy do tematu - Pliki Manifestu to pliki w formacie tekstowym zawierające instrukcje zapisane w języku XML umożliwiające tej samej aplikacji korzystać z różnych wersji bibliotek systemowych pod różnymi wersjami systemu operacyjnego. Plik ten w odniesieniu do "tradycyjnych" aplikacji interpretowany jest przez systemy Windows XP i nowsze. W praktyce, ów "zgoda" na użycie Wizualnych Stylów to nic innego jak wymuszenie odwoływania się do wspominanego wcześniej pliku ComCtl32.dll w wersji 6.0 lub nowszej, a nie w wersji 5.x dostarczanej ze starszymi systemami. Wersja 6.0 udostępnia funkcje odpowiadające za automatyczne rysowanie kontrolek systemowych z wykorzystaniem wybranego przez użytkownika Wizualnego Stylu.
Zrób to sam
Wiemy już na czym polega problem z niektórymi aplikacjami. Jednak dlaczego nie został on wyeliminowany przez ich autorów, jeżeli to teoretycznie takie proste? Po pierwsze część programów została napisana przed wydaniem systemu Windows XP, bądź gdy system ten jeszcze nie był na tyle rozpowszechniony by uwzględniać jego kaprysy w pisanych aplikacjach. Po drugie Pliki Manifestu nie powinny mieć z założenia żadnego wpływu na systemy starsze niż Windows XP. Swego czasu jednak programy antywirusowe reagowały alergicznie na pliki EXE zaopatrzone w Pliki Manifestu i uruchamiane w systemie Windows 2000, ale tylko wtedy jeśli Sekcja Zasobów pliku wykonywalnego została skompresowana. Dziś ten, oraz wszelkie inne problemy wiążące się z obsługą mechanizmu Wizualnych Stylów nie istnieją. Stąd dzisiaj wiedząc już na czym polega problem i jak działa mechanizm stosowania Wizualnych Stylów w odniesieniu do uruchamianych aplikacji, możecie samemu "naprawić" programy odbiegające wyglądem od reszty systemu. Aby dodać do pliku EXE danej aplikacji Plik Manifestu można by oczywiście użyć edytora Sekcji Zasobów plików wykonywalnych takiego jak np. program Resource Hacker.  Ponieważ jednak z punktu widzenia użytkownika nie jest to zbyt wygodny sposób, a poza tym jak już wspominałem niektóre pliki EXE mają wewnętrznie skompresowaną Sekcję Zasobów co uniemożliwia edycję jej zawartości, można użyć innej - o wiele prostszej - metody (jednak mając na uwadze że nie działa ona w systemie Windows 7 i nowszych). Wystarczy utworzyć plik tekstowy np. z użyciem Notatnika, skopiować poniższą treść, wkleić go do edytora plików tekstowych a następnie zapisać i umieścić go w katalogu zawierającym plik wykonywalny danej aplikacji. Plik Manifestu musi posiadać nazwę w zgodzie ze wzorcem "<nazwa pliku wykonywalnego>.exe.manifest". Czyli np. gdy plik wykonywalny nosi nazwę Program.exe to Plik Manifestu winien nosić nazwę Program.exe.manifest. Przykładowa zawartość pliku powinna wyglądać w sposób następujący:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
       version="1.0.0.0"
       processorArchitecture="X86"
       name="Firma.Produkt.Program"
       type="win32"
    />
    <description>Opis programu</description>
    <dependency>
      <dependentAssembly>
        <assemblyIdentity
           type="win32"
           name="Microsoft.Windows.Common-Controls"
           version="6.0.0.0"
           processorArchitecture="X86"
           publicKeyToken="6595b64144ccf1df"
           language="*"
        />
      </dependentAssembly>
    </dependency>
  </assembly>
Teoretycznie, w zgodzie z wytycznymi Microsoftu, w polu Version należy podać wersję programu, w polu Name nazwę programu w formacie "<nazwa firmy>.<nazwa programu>.<nazwa składnika programu>", zaś w polu Description skrócony (jednozdaniowy) opis roli jaką pełni dany plik wykonywalny w odniesieniu do całego programu. Niemniej na dzień dzisiejszy, informacje te nie są nigdzie wykorzystywane i można spokojnie użyć przytoczonych domyślnych danych. Zauważ, iż aplikacje do których dodasz Plik Manifestu prawdopodobnie nigdy nie były testowane pod względem kompatybilności z Wizualnymi Stylami, stąd opisaną wyżej operację wykonujesz na własną odpowiedzialność - istnieje pewna szansa, że interfejs programu zmodyfikowanego w ten sposób będzie niepoprawnie wyświetlany. Sytuację taką oczywiście łatwo odwrócić, zwyczajnie kasując utworzony wcześniej Plik Manifestu.
Różnice pomiędzy kolejnymi edycjami systemu
System Wizualnych Stylów przeszedł kilka zmian wraz z pojawieniem się kolejnych wersji systemu Windows. Windows XP - wprowadzona zostaje obsługa Wizualnych Stylów, domyślnie z systemem dostarczany jest styl Luna zawierający trzy wariacje kolorystyczne (jak się później wyjaśniło, kolorystyka stylu miała być wybierana przez użytkownika spośród wielu dostępnych kombinacji, które na bieżąco, w pełni automatycznie przekolorowywały by dostarczony szablon, niemniej aby zdążyć z przyspieszoną premierą systemu przygotowano tylko trzy przykładowe kombinacje kolorystyczne, które w przyszłości miały być wyparte przez wcześniej zaprojektowany system). Windows 2003 - serwerowa edycja systemu Windows wykorzystuje dokładnie ten sam styl co Windows XP, jednak domyślnie jest on wyłączony, zaś aktywny jest styl klasyczny (jak widać nawet Microsoft doszedł do wniosku, iż wygląda on znacznie bardziej profesjonalnie niż Luna). Windows Media Center - modyfikacja systemu Windows XP dostarczana jest wraz ze stylem Royale, który jest bardziej gustowną modyfikacją tematu Luna. Windows Vista - Luna zostaje zastąpiona domyślnym stylem Aero Glass, styl ten dostępny jest także w wariancie Basic, który nie zawiera obramowania wykorzystującego wspomagany akceleracją sprzętową efekt Glass - wnętrze okien w obydwu przypadkach jest oparte o tą samą, dopracowaną kompozycję. Windows 2008 - kolejna serwerowa edycja systemu bazująca na systemie Windows Vista dostarczana jest ze stylem Aero, niemniej podobnie jak w Windows 2003 domyślnie używany jest styl klasyczny. Windows 7 - następna edycja systemu wykorzystuje minimalnie zmodyfikowany styl Aero w wariancie Glass i Basic, tym razem jednak Pliki Manifestu umieszczone w katalogu z plikiem wykonywalnym aplikacji są ignorowane, ze względu na potencjalne luki bezpieczeństwa (w systemie Windows Vista Pliki Manifestu zostały istotnie rozbudowane umożliwiając m.in. kontrolę nad wymaganymi do uruchomienia programu uprawnieniami, co rodziło wątpliwości ekspertów do spraw zabezpieczeń). Windows 8 - styl Aero zostaje wyparty przez kompozycję nazywaną Metro a ostatecznie Modern UI, która wzorowana jest na stylu Aero choć większość elementów jest zdecydowanie uproszczona (wręcz "spłaszczona"), brak także efektu Glass. Co ciekawe Windows 8 porzuca styl klasyczny - jego wygląd jest nadal dostępny dla aplikacji pozbawionych Pliku Manifestu, oraz w zmodyfikowanej kolorystyce jako styl o wysokim kontraście znany z poprzednich edycji systemu, niemniej niemożliwe jest wyłączenie obsługi Wizualnych Stylów. Jedyne co można zrobić to zastosować nieoficjalny Wizualny Styl naśladujący wyglądem styl klasyczny. Usunięcie elementu obecnego w systemie od ponad 20 lat (licząc od premiery Windows 3.0) nie dziwi tak bardzo, kiedy zwróci się uwagę na likwidację flagowego elementu systemu jakim było Menu Start...
Zrzuty ekranu
Na koniec kilka interesujących zrzutów ekranu pokazujących zachowanie mechanizmu obsługi Wizualnych Stylów na przykładzie Windows XP oraz kilku moich programów w starszych wersjach. Nowsze wersje moich aplikacji obsługują w pełni Wizualne Style bez żadnych dodatkowych zabiegów.
Powyższe zrzuty ukazują główne okno a także dialog konfiguracji programu MP3 Rename. Pierwsza para obrazów to styl klasyczny przy typowym schemacie kolorystycznym - tak prezentuje się interfejs programu pod każdym systemem z serii Windows 95 - 2000, a także w systemie Windows XP kiedy to Wizualne Style są wyłączone. Druga para obrazów przedstawia te same okna, jednak przy aktywnych Wizualnych Stylach podczas gdy aplikacja nie posiadała Pliku Manifestu. Jak widać zmianie uległo jedynie ich obramowanie. I wreszcie trzeci zestaw zrzutów, to po raz kolejny te same okna, jednak aplikacja została uruchomiona z aktywnymi Wizualnymi Stylami a także z obecnym Plikiem Manifestu. Jak widać wszystkie elementy interfejsu zostały poprawnie zmodyfikowane. Warto zwrócić uwagę, że proporcja między poszczególnymi kontrolkami została zachowana, pomimo zmiany ich gabarytu np. większego nagłówka listy plików.
Kolejna porcja zrzutów ekranu pochodzi z gry Piramidka. Kolejność taka sama jak poprzednio. Interesujące są dwie sprawy. Po pierwsze, jak już wspominałem, pomimo braku Pliku Manifestu włączenie obsługi Wizualnych Stylów powoduje nie tylko zmianę wyglądu obramowania okna, ale także pasków przewijania. Druga sprawa - nawet przy obecnym Pliku Manifestu obramowanie grupujące kontrolki nie zmieniło wyglądu na charakterystyczny dla tego stylu. Wynika to z faktu, iż Piramidka powstała w Delphi 5, podczas gdy MP3 Rename w Delphi 7. Starsze wersje tego środowiska stosowały za plecami programisty sztuczkę z ręcznym rysowaniem niektórych kontrolek, stąd dodanie Pliku Manifestu zmieniło wygląd większości, ale nie wszystkich kontrolek - jest to efekt o jakim wspominałem wcześniej.
Ostatnia grupa obrazów przedstawia główne okno Przypominacza. Jak widać screeny: drugi i trzeci są identyczne. Wynika to z faktu, że program powstał w Delphi 4. Ta wersja zapewniała ręczne rysowanie wszystkich kontrolek w tworzonych aplikacjach (dla oszczędności Zasobów Systemowych), co widać wyraźnie po nietypowym wyglądzie przycisków.

Dziękuję za zapoznanie się z artykułem. Chętnie odpowiem na wszelkie pytania w tym temacie - wystarczy do mnie napisać.

Copyright (c) 2000 - 2014 Piotr Chodziński. Wszelkie prawa zastrzeżone.
Zbudowane z poprawnym wykorzystaniem: XHTML 1.0 Strict, CSS 2.1, RSS 2.01, jQuery 1.52.
Polskie znaki kodowane w standardzie ISO-8859-2. Współpracuje z każdą nowoczesną przeglądarką.