Kylix for Delphi programmers - X11 and "window managers"
The very lowest level GUI services a Kylix application would normally ask for like "create a window, with an event loop" are about the highest level of services that X provides. X doesn't provide even trivial UI elements like buttons and scrollbars; it leaves that to you and your choice of X toolkit. An X toolkit is a library that builds standard widgets from X primitives, and is thus responsible for the application's "look and feel."
Just as X doesn't provide user interface widgets, so it doesn't offer any prescriptions about how the various windows should look or act. The catch phrase here is "mechanism, not policy". [RFC 1013.] Basic user interface ("policy") decisions - which window has the focus, what window frames look like, and what widgets should be on those frames and what those widgets should do - are usually made by the window manager.
The window manager is a perfectly ordinary application you can write one in Kylix that has a special relationship with X. The window manager doesn't put windows on the screen, the way other applications do; it tells X how those other application's windows should look and act. While X doesn't require a window manager and can run sans window manager in a trivial, single window way, X will only talk to one window manager at a time.
The X jargon gets a little strange in the neighborhood of window managers. A window manager is really a sort of policy server to the X server's policy client, but speaking of the same piece of software as both client and server is an obviously dangerous source of ambiguity. Since a window manager is an independent process (that may even be running on a different machine) that talks to the X server over a socket, just like your Kylix GUI apps are, window managers are described as special sorts of X clients. Weird but true.
This reliance on a policy server to provide look and feel is the key to X's survival since the mid '80's. X provides only the GUI version of stdin and stdout - mouse and keyboard services, and bitblt and font services and it got these basic abstractions close enough to right that no one ever felt compelled to replace it. By not taking a stand on content, X permitted user interfaces to evolve. By sleeping with anyone, X survived the fragmentation of the Unix world in the late '80's and early '90's.
In the 21st Century, in a specifically Linux context, window managers provide the big benefit of allowing users to make choices both functional and cosmetic for themselves. On the other hand, the basic window manager API was defined a long time ago, and there are an awful lot of things it doesn't cover. It's been extended in various ways over the years, but "the great thing about standards, [is that] there are so many to choose from."
No matter how broken or stripped down the window manager, you can count on at least one of your users using it, unless you're working in a standardized corporate environment. (For that matter, the more broken or stripped down the window manager, the more they will resist changing. They already know it's old and crufty, or flashy but incomplete, but there's something about it that they like, or they would already have switched.) Every window manager your apps will run under may or may not implement all the basic and extended protocols properly: Your app can "hint" that a given window shouldn't be resizable or that it shouldn't have a maximize button, but you can't know whether the user's window manager actually takes the hint.