5 ms·

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

by rer 10y ago

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.

rwmj 10y ago
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 https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).
- SXX 10y ago
  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/ http://mxe.cc/
  - justinclift 10y ago
    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?
- steaminghacker 10y ago
  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.
jeena 10y ago
Also check out Qt's QML: http://qmlbook.github.io/ http://qmlbook.github.io/
bobbytherobot 10y ago
> - 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.
- sangnoir 10y ago
  > 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.
  - wtracy 10y ago
    The current YouTube app for Android still uses the iOS share icon rather than the Android one.
c-smile 10y ago
- 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-one-application/ 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...
yaur 10y ago
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.
- 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

by rer 10y ago

rwmj 10y ago

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 https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).

SXX 10y ago
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/ http://mxe.cc/
- justinclift 10y ago
  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?
steaminghacker 10y ago
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.

jeena 10y ago

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

bobbytherobot 10y ago

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

sangnoir 10y ago
> 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.
- wtracy 10y ago
  The current YouTube app for Android still uses the iOS share icon rather than the Android one.

c-smile 10y ago

- 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-one-application/ 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...

yaur 10y ago

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.

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