380 likes | 670 Views
제 10 강 : X Windows. X Window. (3) User inputs $ startx command sh creates child (window) process 3 processes are active now parent (sh) is sleeping. Window is running. window. sh a.out. Operator Console Power Up Kernel creates sh (CUI**)
E N D
제10강 : X Windows X Window
(3) User inputs$ startx command sh creates child (window) process 3 processes are active now parent (sh) is sleeping. Window is running window sh a.out • Operator Console Power Up • Kernel creates sh (CUI**) • Now two processes are active kernel a.out (1) Initially only kernel runs ** Character User Interface
Linux Desktop Environments KDE & GNOME
window X window is just a plain application program command (utility) child process of sh sh a.out kernel a.out
commands under /bin Multiple Windows Active process (netscape) Active process (ppt) Active process (Web) - 1 window per client process - local or remote process - iconized or de-iconized
Click mail program window Window process is running (parent sh is sleeping) At windows, user clicks “mail” (Window itself cannot create child process) (Creating child command is sh’s job) Window needs to communicate with sh Window invokes IPC system call Kernel provides IPC service blocks Windows (caller) move data from window to sh wakes up sh (callee) creates mail sh a.out IPC request control & data kernel a.out NOTE – child process can be a remote process, such as web server
editor sh mail Window I P C tell sh to create mail as a child create mail sleep till done create editor sleep till done Wake up. I am done Wake up. I am done Wake up. I am done kernel (IPC)
Root Window Root window (entire screen)
Child Windows Root window (entire screen) Top level windows or Child windows (per each process)
GUI involve a lot of drawing Seoul Local application (Seoul) Tokyo Remote application (Tokyo) Local machine actual drawing Remote applications request drawing Question: Should remote application send all the bitmaps for every graph & character?
***** called “resource” (bitmaps) • widgets • font A AA a a • color Protocol to minimize network traffic • reduce network traffic • place most bitmaps on the tty side a priori • Communication protocol for outputs • Communication protocol for inputs • keyboard (=code 3), • mouse click (=code 4), ….
Application Side Device Side bitmap for widgets code ***** resource “widget 2” “widget 3” A font file font 1 A font filefont 2 A font filefont 3 mapping X - Protocol bitmap for characters [ request by code] [actual drawing]
X-Client Application 2 kind of processes X-Server request drawing hardware deliver event screen keyboard mouse request drawing
Window Managera special client process X-Clients X-Server request drawing Window Manager hardware deliver event screen keyboard mouse
Role of Window Manager X-Clients (child windows) X-Server Window Manager Window library functions hardware Interface with Application Control appearance of windows (arrange, resize, …) Mediate between child windows Interface with Hardware
“move” “minimize” “resize” “full size” Window Manager • Manage window • Decorate with standard look & feel • Control – move, ioconize, resize, …. • Bookkeeping • DB of {N processes, N windows} • Stack, tile windows • hide/expose windows • Mediates application’s competing requests • Just a user level a.out (not kernel) • May have several -- twm fvwm ... • Select your choice
“click” “click” “click” output request arrives in code widget #3 font #7 hello Too big to fit l X-server (Hardware side) • Just a user level a.out (not kernel) • [Input] • event: HW kernel X server (daemon) • forwards to appropriate application process • [Output] • message originates from applications (in X-window-protocol) • decodes the X-window-protocol message (eg draw widget A) • calculates width of character, box, etc • fonts are X-Server owned resource, font files are pre-loaded • call low level functions to draw. (eg curses library)
2 helping processes [out] [in] • X server process (for Display/Input Hardware) Handles display output – manage window hierarchy Handles input (mouse, keyboard) events, forward to appropriate processes (2) Window Manager process (Mediate, Control Processes/Windows) Displays decorative frame around top level window each with title allows users to manipulate top level windows users can (move / resize / iconize / deiconize) windows Windows layout Mediates competing demands from many processes (hide, expose) O Applications (User Program – excel, ppt, ..) Communicate with X server through X library -- create window, get events Communicate with WM through X library -- specify title, … [each] [N]
Root window Window Hierarchy Tree Top Level window Top Level window Top Level window (email) (word) (web) a Internal windows (“widgets”) b c
Widget classes (Internal windows) menu scroll button password 1.Name: a ***** b Your password c 2.Event: click drag click type in char 3.Callback procedure: thread1() thread2() thread3() thread4() (handler)
widget class example • Label Button • Windows are made of widgets • Each widget allows certain input events • Each input events maps to handling function (callback procedure) Text
allowed events on widget classes [widget name] [Description] ------------------------------------------------------------------- Button - select by clicking Scrollbar - user selects the region Textfield - user types text Password - user types text but **** echoes Label - cannot receive input Menu -
Event-driven programming main() /* eg word */ { W=XCreateWidget(); /* text-input */ XAdd_Callback(W, f1(), resource); /* register */ Xrealize_widget(); /* display */ XappMainLoop(); /* wait event*/ } Main_loop() /* handlers */ { case (keyboard_input) f1(); case (mouse_input) f2(); } NOTE -C compiler links with X Window library -library communicates with Window system during run
Window Library X-Clients (child windows) X-Server Window Manager Window library functions hardware Interface with Hardware Interface with Application Qt C++ library (KDE) GTK+ C library (GNOME)
Advanced window programming Graphical front ends automatically generates Qt or GTK codes Kdevelop for Qt programs (KDE) Glade for GTK+ programs (GNOME) main() /* eg word */ { ` W= XCreateWidget(); /* text-input */ XAdd_Callback(W, f1(), resource); /* register */ Xrealize_widget(); /* display */ XappMainLoop(); /* wait event*/ } Main_loop() /* handlers */ { case (keyboard_input) f1(); case (mouse_input) f2(); }
(1) Curses library – low level eg draw a line move cursor create a window (2) Window library – high level library eg draw menu widget resize child window event driven programming
Sample curses functions #include <curses.h> main() { initscr(); /* initialize a screen */ move(5, 15); /* move cursor to (x, y) position*/ printw(“%s”, “Hello!”); /* print a word at cursor position */ Hello!
[Hardware side] [Application side] Window Manager application program (netscape) X-Server (2) wake up X server OS kernel application program (email) HW (3) deliver (1) Mouse click Input
application program (netscape) (3) WM mediates requests Window Manager application program (email) (4) WM requests drawing application program (word) X-Server (2) X library sends (as hints) to WM draw(3) curses application program (vi) write(2) OS kernel (1) generate output data call X library which sends data to WM Bitmap HW Output [Application side] [Hardware side]
[Application Process side] local / remote [Display HW side] application program X protocol is integrated with TCP/IP X-Server X-library OS kernel OS kernel X-Protocol TCP/IP Ethernet HW Hardware
Starting X window • startx command (script) • Automatically during booting (graphic login)
OO can be … my kernel daemon a.out a.out Library Sys-call Process • Kernel function • Slow – system call overhead • Hard to change (OS version) • Library • Fastest (invocation overhead) • My program gets bigger • Separate process (a.out, daemon, server) • Slowest (kernel IPC overhead, invocation overhead) • Flexible • kernel becomes smallest “micro-kernel” • eg OO can be a command or kernel function or daemon OO