Hacker News Reader

Comment by rer | Hacker News Reader

Here's what I want.

- The UI to look as good or better than the UI on Mac OS X. I'm not willing to compromise on looks.

- The library to be cross-platform. I want to deploy the software on Mac OS X, Windows, and Linux. I don't care about mobile right now.

- I want it to be possible and easy to (a) develop new features on my own and (b) change existing features. I'd rather reimplement a textbox from scratch if it's the only way to change a control. If this means I need something more like GLib instead of GTK+, so be it.

- I won't use the web. No HTML, no CSS, no Javascript. Sorry.

The end goal is to build the best, easiest UI environment to write software with. If it's not possible to build this with existing UIs and I have to write one from scratch, so be it.

View on HN

Pretty sure that C++ and Qt is what you want. Maybe not perfect in every sense, but widely used and battle-tested.

If you don't want to deal with Windows, you can cross-compile for Windows from Linux using the mingw-* packages (eg https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).

Or you can use preconfigured cross-compilation toolchain like MXE[1]. If you have clean codebase and use CMake it's usually enough to just pass one extra argument to get working binary out. And it's also work on OS X.

[1] http://mxe.cc/

MXE has an ok reputation. Not everything seems to play well with it though. :(

For example, we (sqlitebrowser.org) compile our window nightly releases from Linux, using MXE. But, SQLCipher (an encryption library) doesn't build with MXE. So the nightlies don't support encryption.

Meanwhile, we've figured out how to do full Windows dev setup and builds. eg:

  https://github.com/sqlitebrowser/sqlitebrowser/wiki/Setting-up-a-Win64-development-environment-for-DB4S

We're building our releases natively now, and the nightlies will be built natively too in (hopefully near) future.

Guess we just outgrew MXE?

Yes, I'm compiling for Windows using mingw64. I gave up with VC because, it worked, but since Windows 10, the MS dynamic runtime contains parts of the OS. This doesn't always install properly on windows 7 & 8. Mingw worked.

> - The UI to look as good or better than the UI on Mac OS X. I'm not willing to compromise on looks.

Just remember that the UI kit is only part of having a good UI. Apple's historical success with good UI is based on their long standing guidelines for designing good UIs.

I doubt I need to tell you this (although Google seems to recently have forgotten it), you app needs to use the patterns of the platform it is on. Users respond well when the app looks like it is "native" and not a port.

> I doubt I need to tell you this (although Google seems to recently have forgotten it), you app needs to use the patterns of the platform it is on

Not that I agree with it, but I am fairly certain Google has not forgotten - they have just remapped the definition of "platform" from "the operating system" to "Google's app constellation & sites". The pattern commonality is no longer with other apps on the OS you are currently on, but with other Google property.

The current YouTube app for Android still uses the iOS share icon rather than the Android one.

- do you need to support high DPI monitors? If "yes" then you need a) something capable to render on GPU and b) to use scalable vector image formats like SVG and others.

- Do you need adjustable styling? Like today it is a flat UI and tomorrow they will return back to skeumorphism. Material design for example is step in that direction. What about UI branding, when the same UI is used for different brands with their own color schemes, etc? What is expectation for the lifetime of your application? Just for the note: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on...

- What about UI accessibility? "Section 508" and the like.

- So called "richtext" WYSIWYG editing - yes/no?

- Printing and print preview?

- Dynamic UI composition? When UI is composed from actual data structure. In some cases simple flat property lists may work but not always.

- UI animations and transitions ?

- What about UI internationalization?

As of "No HTML, no CSS"...

HTML is just a serialization form of tree of UI elements. Not more not less. Any library has this (serialization) in one form or another.

CSS is simply the way to define things like: "this element in that state has to be rendered te following way". Any good library has that in one form or another.

You do not need full scale browser for HTML/CSS, and actually should not use solutions based on browsers for the UI. Primary goal of a browser is to provide safe browsing experience, UI rendering is only next function after the first...

Also check out Qt's QML: http://qmlbook.github.io/

Before you start to roll your own consider that there have been many attempts to do this already and they have all failed to varying degrees. The reason for this is that it's much harder to get right than it seems.

QT is what I've used when a client is determined to go down this path, but if a web app doesn't make sense the best option is almost always to spend extra time making sure that most of your code is portable and then write a native UI that uses it for each platform that you care about.

> 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.

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.

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

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.

Reply on news.ycombinator.com