Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Everyone that dislikes Win32 should program directly with Xlib and Athena, and rejoice of the experience.


Win32 with function signatures that look like this:

  HWND WINAPI CreateWindowEx(
    _In_     DWORD     dwExStyle,
    _In_opt_ LPCTSTR   lpClassName,
    _In_opt_ LPCTSTR   lpWindowName,
    _In_     DWORD     dwStyle,
    _In_     int       x,
    _In_     int       y,
    _In_     int       nWidth,
    _In_     int       nHeight,
    _In_opt_ HWND      hWndParent,
    _In_opt_ HMENU     hMenu,
    _In_opt_ HINSTANCE hInstance,
    _In_opt_ LPVOID    lpParam
  );
The only redeeming feature is the documentation.


Windows doesn't need a bookshelf full with around 15 OReilly books for GUI programming.

Since we are counting arguments:

    Window XCreateWindow(
        Display *display,
        Window parent,
        int x,
        int y,
        unsigned int width,
        unsigned int height,
        unsigned int border_width,
        int depth,
        unsigned int class,
        Visual *visual,
        unsigned long valuemask,
        XSetWindowAttributes *attributes
    );


Yeah, I don't understand the grandparent on that. The Xt API (and the Athena widget set) were hardly a great work of computer science. But they were relatively clean and easy to understand, and basically invented the "widget" (rectangle on the screen that can draw itself and respond to input in an encapsulated way) component model that we're all still thinking in today.


No they did not, Xerox PARC invented the widget.

They never had anything to do with UNIX.


I wouldn't say Xt invented the "widget", and I would never pass up the opportunity to state most emphatically that Xt widgets are neither clean nor easy to understand.

Here's a video tape by Brad Myers called "All the Widgets" [1] that shows demos of widgets from way back, many of them long before Xt. (Over 175 segments, from 30 systems, from 15 companies!)

[1] https://www.youtube.com/watch?v=9qtd8Hc90Hw

All the Widgets, by Brad Myers. This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.

What kicked Xt's and Motif's ass, especially in terms of power and flexibility, as well as being clean and easy to understand, was TCL/Tk.

The reason TCL/Tk was so successful in spite of how lame TCL was as an scripting language, is that TCL was there from day one of Tk's design, not an afterthought.

As a result, there was no need for Tk to invent a bunch of half-assed kludges, and require applications to build complex Rube Goldberg devices on top of those, when Tk could simply call into TCL to do anything the scripting language interpreter could handle, including calling into the application's C code from TCL.

So there was zero overlap between what the scripting language could do, and what the toolkit needed to do. And that made the toolkit vastly simpler and more consistent, and much easier to flexibly program and modify.

Xt based toolkits like Motif [2] had to built on top of all that half assed pseudo-object-oriented crap trying to reimplement programming language level concepts like objects, components, properties, defaults, inheritance, events, handlers, delegation, layout, etc, in brittle C and macros.

[2] http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....

Motif was yet another proof of Greenspun's tenth rule of programming [3]: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

[3] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

So just start with Common Lisp, or at least something in the ballpark like TCL, PostScript, JavaScript, Lua, etc.


"The only redeeming feature is the documentation."

Lmao. That's close to what I said when I first learned it. I was griping about how complicated window creation was vs some tools I had. "The MSDN docs are awesome, though!"


I never get why some people think the Win32 MSDN doc are appropriate. They are typically several order of magnitude less precise than man-pages on function about a similar topic -- if not just containing a few errors!


They helped me a lot. Especially the code examples for various API functions. That simple.


I don't think that at the raw level there is that much of a difference. XCreateWindow() has mostly the same arguments as CreateWindowEx() except that the X11 API only handles creating window and does not mash it together with upper layer concepts like event handling (lpClassName) and widget sets (hMenu).

The X11 model is also easier to reason about because it is clear where the layer boundaries are and what is implemented in your process as opposed in the kernel/display server and what causes some kind of IPC (eg. what happens to lParam when you send message to window with WndProc implemented in different process?).


Why?


I doubt there is any worse UI tooling available.


Than win32!? Are you serious?

Xlib is pretty bad but win32 is absolute bonkers. Or are you saying the opposite?


Of course I am serious.

I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts.

The amount of wasted hours of my life using xlsfonts....

And those bare bones widgets, yet another headache.


And yet Xlib ran happily on machines with 4MB of RAM and would only use 512K of that; mind you that was X11R3. I used to run this very config on Apollo Domain/OS machines in 1990.


The Amiga had 512KB for the whole OS, including a GUI stack way better than X.

For us targeting desktop computing, the network features of X were never relevant, what mattered was GUI toolkits for workstation usage, running on the same computer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: