This is equivalent to requiring you to run MySQL in order to use the "mkdir" command.
The fact that Qt (or MySQL) is free is no excuse. Both are so large and complex that for the average programmer the source code provides no more information than a closed-source toolkit.
If you look below Qt you will find Xlib (and the XRender extension). These supposely low-level interfaces are obscenely baroque with thousands of calls that nobody can remember, and are in fact too low level, requiring all modern systems to provide an interface that matches hardware designed in the 1980's. The interface is nowhere near abstract enough, either, which can be easily seen in that no toolkit attempts to emulate Xlib on another system such as Windows, instead the toolkit code itself is rewritten for that system.
Y is an attempt to solve this, by making a low-level library that is easy to program and powerful enough that Qt can become a true portable toolkit, rather than a huge programming system.
I want to try very hard to make Y do everything it should, and perhaps more importantly: not do anything it shouldn't.
The number one criteria for the Y interface is that it be easy to program for. The number two criteria is that it be easy to program for. This is also the number three, four, etc criteria. All other considerations including efficiency are secondary to this. But in my experience simple interfaces actually are far more efficient in the long run, because they don't lock the implementation the way complex ones do. I think the simple Unix file interface (open, close, seek, read, write) is a good example, it handles phenominally fast throughput and disks and networks of a size that was unimagined when it was designed, and only tiny additions (like copyfile) are needed. Compare this with the baroque Unix tty interface, which is useless nowadays except in simplified raw mode.
The initial version runs atop Xlib and Xft and lpr. Later versions of Y will completely replace Xlib and Xft. After that portions of Y can be migrated to the X server. An "emulate Xlib atop Y" library will be written at that time so that new servers that only serve Y clients will be possible.
A version of Y also works on MicroSoft Windows, to allow programs using Y to be ported easily between Unix and Windows platforms. This version uses Win32 GDI much like Xlib is used. There is no plan to make Windows Y use any lower-level interface. It may be desirable to make Y libraries for other platforms such as Macintosh.
Y is a C library, to allow easy linking to many languages. Also at the level of Y "objects" serve no useful purpose and actually make things harder for the user.
Y provides three basic services: graphics, events, and shell.
The graphics state will contain the device, window, transformation, clipping, current color, current font, and other state. There are calls to duplicate a graphics state, to set the current one, and to destroy one.
Graphics calls greatly resemble PostScript's base set of functions. Paths are constructed and then filled/stroked. The set of graphics calls will be made as small as possible. Y graphics are designed to by non-synchronous: few functions (except obvious library local functions) have return values. This allows very efficient buffered pipelines to a server running in a different process or on a different machine.
The creation, mapping, moving, and destruction of windows are considered graphics calls.
The library will have redirection tables built in, to easily allow the graphics calls to be sent to different implementations. The current version can direct calls to an Xlib implementation, an Xrender/Xft implementation, to write PostScript to a file descriptor, and to an OpenGL implementation.
The only form of text accepted is UTF-8, Y will handle encoding errors such that the vast majority of ISO-8859-1 and Windows encoded text will display correctly.
On Unix this could be a totally seperate library. It is part of Y to allow Y to be portable to Windows and perhaps other systems where the GUI events do not trigger a file descriptor.
Like X, damage is reported as rectangles. A program may accumulate these and send the region back as a clip region, like current X programs. Or a program may set the clip directly to the the current damage, perhaps getting a larger or more complex area, but unable to know what it is and thus forced to draw the entire window.
Typing on the keyboard is translated to UTF-8. Y may support complex character composing services, each keystroke will be reported as a set of bytes to delete and replace so that preview of partially-composed letters is trivial for the application.
All possible knobs (like pressure and angle on a stylus) on a machine will produce events without any setup by the user program. It is much easier to ignore the events that to arrange them initially.
Drag and drop is supported in a very simple and clean way. All windows are potential drop targets. The only form of data is URL.
A program that may be exec'd called "start" which takes a URL and does the proper action when a user double-clicks a URL. A switch to "start" will make it instead print to stdout a list of possible actions so an interface can provide a menu. The initial version will use KDE's kdelnk files but I think a nicer design can be made.
A well defined location (~/.start?) will provide a hierarchy of URL's that an interface can display as a list of useful things the user may want to select and send to "start".
A list of all "tasks" for each graphics device. Each task is created by and belongs to one process. For each entry a name, host, pid, and "start" URL are provided, and a (possibly zero-length) list of windows belonging to that task, and a parent task. A program may create as many tasks as it wants and change the window list for them. Tasks will receive events when the user runs the "start" program and should respond by opening the provided URL and making a new task.
A list of all "windows" for each graphics device. Each has a name and a (possibly null) task.
An interface to cause a logout. An interface to logout and login as another user (requires program to have the new user's privledges). An interface to cause the calling program to replace the window manager.