From affdf22d0ee1802f8e538032a8729de41aa337af Mon Sep 17 00:00:00 2001
From: xf0r3m <jakubstasinski@protonmail.com>
Date: Thu, 5 Oct 2023 14:33:15 +0200
Subject: [PATCH] =?utf8?q?Rozpocz=C4=99cie=20tworzenia=2013=20rozdzia?=
 =?utf8?q?=C5=82u?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

---
 articles/terminallog/Linux.Podstawy.html | 117 +++++++++++++++++++++++
 1 file changed, 117 insertions(+)

diff --git a/articles/terminallog/Linux.Podstawy.html b/articles/terminallog/Linux.Podstawy.html
index 3205039..d69ef77 100644
--- a/articles/terminallog/Linux.Podstawy.html
+++ b/articles/terminallog/Linux.Podstawy.html
@@ -10433,6 +10433,123 @@ bash
           na kopiowanie i wklejanie przy użyciu innej metody dostępnej bez
           środowiska graficznego, co czyni go dość użytecznym programem.
         </p>
+        <h1 id="13.userinterface">13. Interfejs użytkownika i drukowanie</h1>
+        <p>
+          Jeśli kiedyś przyjdzie nam korzystać z dystrybucji Linuksa poza,
+          serwera, systemami wbudowanymi oraz innymi rozwiązaniami, w których
+          do interakcji z systemem wykorzystujemy wyłącznie powłokę, spotkamy
+          się z <strong>interfejsem graficznym użytkownika</strong>.
+          Najprościej rzecz ujmując jest tak jakby <em>klasyczny</em> pulpit
+          z wyświetlającymi się w okienkach programami. <em>Tak jakby</em>
+          ponieważ na interfejs graficzny składa się bardzo duża ilość
+          różnych elementów, które mogą się między sobą diametralnie różnić.
+        </p>
+        <p>
+          Krótko scharakteryzujemy elementy, z których składa sie interfejs
+          użytkownika. Ten rodział będzie dość mocno teoretyczny, więc jeśli
+          nie interesuje nas czym jest <em>Wayland</em> czy
+          <em>X Window System</em> lub magistrala <em>D-Bus</em> można przejść
+          kolejnego rodziału.
+        </p>
+        <h2 id="13.1.uimajorelements">13.1. Elementy składowe interfejsu graficznego</h2>
+        <p>
+          Jak już wcześniej wspomniałem na interfejs graficzny użytkownika
+          składa się duża ilość elementów. Te elementy moga być zostać
+          pogrupowane na podstawie czym tak na prawdę są. Jesli powiem, że
+          środowisko graficzne uzupełniają <em>widget-y</em>, to tymi
+          <em>widget-ami</em> są po prostu aplikacje dostarczane jako
+          zależności zadania instalacji wybranego środowiska. Środowiska
+          oczywiście mogą się bez nich obejść jednak przyjemnosć korzystania
+          z takiego pulpitu powoduje mieszane uczucia.
+        </p>
+        <h3 id="13.1.1.framebuffer">13.1.1. Bufory ramki</h3>
+        <p>
+          Na samym dole intefejsu użytkownika znajduje się zazwyczaj
+          <strong>bufor ramki</strong> jest to obszar pamięci odczytywany
+          przez układy graficzne i następnie przekazywany do wyświetlenia na 
+          ekranie. Kilka bajtów reprezentuje jeden piksel. Podczas wyświetlania
+          okien procesy na bierząco aktualizują zawartość bufora lub buforów
+          (może ich być kilka, o czym się zaraz przekonamy) pamiętając przy
+          tym aby nie nadpisać elementów innych okien (procesy programów
+          wyświetlających się w oknie).
+        </p>
+        <h3 id="13.1.2.displayingmethods">13.1.2. Mechnizm wyświetlania</h3>
+        <p>
+          Ciężko jest sklasyfikować przedstawione poniżej elementy. Niby służą
+          temu samemu to jednak posiadają wiele zasadniczych różnic, że trzeba
+          się na chwilę zatrzymać i zastanowić na tym jak je sklasyfikować.
+        </p>
+        <h4>X Window System</h4>
+        <p>
+          System <em>X Window</em> bazuje na architekturze klient-serwer,
+          serwer wyświetlania, nazywany również <em>serwerem X</em> jest
+          tak jakby jądrem całego interfejsu użytkownika. <em>Serwer X</em>
+          zarządza wszystkimi elementami związanymi z pulpitem przy czym nie
+          narzucając jak coś powinno działać lub wyglądać. Klientem w tej
+          releacji pozostaja wszelkie aplikacje, które chcą wyświetlić okna
+          w systemie <em>X</em>. Po nawiązaniu połączenia z nim, aplikacja
+          żąda wyświetlenia okna. W odpowiedzi uzyskamy informacje o
+          docelowym położeniu okna oraz zostaniem mu wskazany obszar pamięci
+          przeznaczony na bufor ramki. Czasmi <em>serwer X</em> sam zajmuje
+          się renderowaniem elementów graficznycznych.
+        </p>
+        <p>
+          Ze względu na to, że <em>serwer X</em> bierze udział w tak wielu
+          czynnościach, może stać się <em>wąskim gardłem</em> w pewnym
+          momencie, chociaż <em>X Window System</em> jest aktywnie
+          wykorzystywany od lat 80, okazał się dość elastyczny aby móc
+          obsługiwać elementy współczesnych interfejsów. 
+        </p>
+        <h4>Wayland</h4>
+        <p>
+          Protokół <em>Wayland</em> w przeciwieństwie do <em>X Window</em> jest
+          nastawiony na decentralizację. Żadna centralny serwer nie bierze
+          udziału w renderowaniu elementów graficznych. Każdy klient otrzymuje
+          swój bufor ramki oraz <strong>składnik kompozycji</strong> łączący
+          bufory ramki klienta do postacji akceptowanej przez bufor ramki
+          ekranu, przy czym to zadanie jest wspierane sprzętowo co może
+          podnieść wydajność.
+        </p>
+        <h4>Różnice między Wayland oraz X Window System</h4>
+        <p>
+          Generalnie to nie ma zbyt wielkich różnic między protokołem
+          <em>Wayland</em> a system <em>X Window</em>. Aplikacje w obecnych
+          środowiskach wykorzystując <em>X Window</em> nie oczekuje na
+          wspracie od serwera i same renderują bitmapę (zapisuja elementy
+          graficzne w buforze ramki w postaci bajtów) i przesyłają ja
+          <em>serwerowi X</em>. Serwer łaczy je ze sobą z wykorzystaniem
+          rozszerzenia kompozycji, które jest dostępne w nim od kilku lat.
+          Jedną z faktycznych różnic jest wymaganie biblioteki
+          <strong>libinput</strong> służącej do kierowania danych wejściowych
+          do klientów. Protokół nie wymaga tej biblioteki. Jednak jest ona
+          w każdym dostęp środowisku. O mówimy ją sobie przy okzaji głębszego
+          zapoznania się z system <em>X Window</em>.
+        </p>
+        <h3 id="13.1.3.windowmanager">13.1.3. Mendżery okien</h3>
+        <p>
+          Menedżer okna w interfejsie użytkownika zajmuje się renederowanie
+          elementów dektoracyjnych, obsługuje kierowane do tych elementów
+          zdarzenia wejściowe oraz informuje serwer o położeniu okien. Te
+          zadania są wykonywane kiedy korzystamy z systemu <em>X Window</em>.
+          Inaczej jest w przypadku protokołu <em>Wayland</em> tutaj menedżer
+          okien pełni rolę serwera, składa bufory ramek, aby były zgodne
+          z buforem przeznaczonym do wyświetlania oraz obsługuje przekazywanie
+          urządzeń wejścia na kanale zdarzeń. Jest to główna różnica miedzy
+          opisanymi wcześniej mechanizmami wyświetlania. Każdy z dostępnych
+          interfejsów może mieć swój własny menedżer okien. Niektóre
+          menedżery okien są traktowane jako pełne interfejsy użytkownika.
+          Oczywiście jest błędne założenie, ponieważ takim gołym menedżerom
+          okien, brakuje kilku elementów.
+        </p>
+        <h3 id="13.1.4.graphicalinterfacelibrary">13.1.4. Biblioteki interfejsu graficznego</h3>
+        <p>
+          Elementy interfejsów graficznych są często oparte o jedną z bibliotek,
+          która wspiera tworznie różnego rodzaju przycisków, paneli,
+          elementów dekoracyjnych czy projektowania okien. Wśród środowisk
+          interfejsu użytkownika prym wiodą biblioteki standardu GTK+ oraz
+          standardu Qt. Przyczym GTK+ jest wykorzystywany przez większą ilość
+          środowisk.
+        </p>
        </div>
 			<p style="margin: 15px; padding: 0; outline: 0;">
 				2022; COPYLEFT; ALL RIGHTS REVERSED;
-- 
2.39.5