4 ms·

> it's much harder to get right than it seems I'm not disputing this but I've yet to see a clear explanation why it's harder to get right than it seems. I wa

by rer 10y ago

> it's much harder to get right than it seems I'm not disputing this but I've yet to see a clear explanation why it's harder to get right than it seems. I want to understand, precisely, what makes this hard.

aninteger 10y ago
It's not necessarily hard but it is a ton of work and requires a lot of low level knowledge of the underlying window system. You need to have a very good understanding of the layer beneath you (xlib, Wayland, win32) and how fonts are rendered on the various systems you want to support. There's also various tradeoffs you need to make. Do you go with custom drawn widgets or use native ones? Native offers a shortcut if you have a greater understanding of the lower system API. Custom drawn requires possibly less knowledge of the various widget API but more knowledge of the underlying window drawing API. Getting basic buttons and labels drawn is not hard. The harder parts are menus, text entry, scroll bars and scrolling. None of the current toolkits were cross platform from initial release. Almost all started with Xlib and then years later were ported to Windows. Some still haven't made the port to OSX (except to rely on x11). It's a lot of work and maybe that's what makes it hard.
- rer 10y ago
  Maybe want I want is to always have access to the layer beneath (xlib, Wayland, win32). Thanks.
yaur 10y ago
Setting aside that most windows client development should probably be done in WPF/C# these days... low level differences: There are differences between GDI and xlib. For instance GDI has a concept of a "combo box" at the API level and in X11 you need to either roll your own or use a higher level GUI toolkit. IIRC, Handling of the non-client area and window scrolling are different between platforms and handling of audio/video is completely different between platforms. There are a LOT of features: Power modes (e.g. suspend, hibernate, low battery), tooltips, the clipboard, drag and drop, maximize, and a bunch of subtly different "must have" features need to work between platforms and you need to know what all those features are. Accessibility should work and touch/gesture support is likely to become important over the next few years. At the point where you start cutting features to make it more manageable you have started down the road of making another crappy "lowest common denominator" GUI toolkit and you are better off just using QT. User expectations are different between platforms: This is mostly a lot of little details, like where the "close" button goes, what a "right click" does, menu layouts, standard icons, and which direction the window scrolls when you move the mouse wheel "up" but it adds up to an application not feeling right. You can see this taken to an extreme with any number of bad ports from console to PC.

by rer 10y ago

aninteger 10y ago

It's not necessarily hard but it is a ton of work and requires a lot of low level knowledge of the underlying window system. You need to have a very good understanding of the layer beneath you (xlib, Wayland, win32) and how fonts are rendered on the various systems you want to support. There's also various tradeoffs you need to make. Do you go with custom drawn widgets or use native ones? Native offers a shortcut if you have a greater understanding of the lower system API. Custom drawn requires possibly less knowledge of the various widget API but more knowledge of the underlying window drawing API. Getting basic buttons and labels drawn is not hard. The harder parts are menus, text entry, scroll bars and scrolling. None of the current toolkits were cross platform from initial release. Almost all started with Xlib and then years later were ported to Windows. Some still haven't made the port to OSX (except to rely on x11). It's a lot of work and maybe that's what makes it hard.

rer 10y ago
Maybe want I want is to always have access to the layer beneath (xlib, Wayland, win32). Thanks.

yaur 10y ago

Setting aside that most windows client development should probably be done in WPF/C# these days... low level differences: There are differences between GDI and xlib. For instance GDI has a concept of a "combo box" at the API level and in X11 you need to either roll your own or use a higher level GUI toolkit. IIRC, Handling of the non-client area and window scrolling are different between platforms and handling of audio/video is completely different between platforms. There are a LOT of features: Power modes (e.g. suspend, hibernate, low battery), tooltips, the clipboard, drag and drop, maximize, and a bunch of subtly different "must have" features need to work between platforms and you need to know what all those features are. Accessibility should work and touch/gesture support is likely to become important over the next few years. At the point where you start cutting features to make it more manageable you have started down the road of making another crappy "lowest common denominator" GUI toolkit and you are better off just using QT. User expectations are different between platforms: This is mostly a lot of little details, like where the "close" button goes, what a "right click" does, menu layouts, standard icons, and which direction the window scrolls when you move the mouse wheel "up" but it adds up to an application not feeling right. You can see this taken to an extreme with any number of bad ports from console to PC.