151–160 of 230 posts
None, abstract the functionality of your app into a cross-platform library and build a native GUI for each platform you support using that platform's native SDK.
Shouldn't this be a solved problem?
"The best" is subjective. I have played around with libui ( https://github.com/andlabs/libui ), which runs on Windows, Linux, and macOS. A nice thing about it is that it is written in C, and therefore has bindings with several programming languages. I have experimented using it from Java (via JNA) and it works quite nicely.
libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In other words, is GTK+ bad enough that the easiest way to use it is to wrap around it?
Personally I implement the UI in as thin a layer as can be architected and reimplement for every platform. It's the best way, and probably cheaper for most apps than trying to force some lowest common denominator library to express what you want in high fidelity.
SWT rarely gets any love in desktop UI threads around here, but I recently wrote a small desktop program using SWT and Java and found it to be a reasonably pleasant experience. The main purpose of the program was to allow the user to view a couple of database tables, and using a tree view widget with columns was a key requirement. SWT is the widget toolkit used by Eclipse and is mostly native, using GTK on Linux, Coc…
I want it to look great, especially on the Mac.
No SWT.
Earlier quoted context omitted.
Why many and not all? Emulating sounds like an extra layer one could do with out.
Because one platform supports more options and when using that control on a different platform there are exactly two choices: break cross compatibility or reimplement the control. Add evolution of controls and idioms over time, and it's literally impossible to always unify: not all platforms evolve their non-trivial components in the same direction.
What do you think is the right thing to do? To have a common denominator kind of approach where a control works on all platforms but with fewer features, or to reimplement the control?
Do you have an example handy of a control/idiom that caused this problem?
It sounds like reimplementing (emulation) is a good thing.
Earlier quoted context omitted.
How hard can it be to build a toolkit that supports a textbox on Mac OS X, Windows, and Linux? For a moment I thought you proposed a solution a thread up: > have it translate into the correct API calls on each platform under the hood. What if instead of writing controls for applications, the applications had low level access to create controls on their own?
Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are. For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing. Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the…
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
Earlier quoted context omitted.
libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In other words, is GTK+ bad enough that the easiest way to use it is to wrap around it?
GTK+ is dreadful on Windows. I'd stay away. Personally I implement the UI in as thin a layer as can be architected and reimplement for every platform. It's the best way, and probably cheaper for most apps than trying to force some lowest common denominator library to express what you want in high fidelity.
I didn't understand this. When you say you implement the UI as a thin layer do you mean you wrap only the few controls you need?
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 th…
> - 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.…
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.
Why isn't anyone here mentioning Xamarin + GTK#?
(well last beta release of gtk3 binding was released 2014-06-04, but lot of APIs are missing and buggy)
(Xamarin said that they would not going to port xamarin studio to gtk3)
since gtk2 doesn't support hi-dpi scaling, I would not recommend it.
I work on a cross-platform application that runs on both Windows and Mac. We have a cross-platform library for business logic, and native Windows and Mac UIs. The problem is that cross-platform UI libraries don't really let you fine-tune the UI. They're great for very rapid development with a basic, functional, UI. If you get an "artiste" in product management, or you need to plug into Windows-specific and Mac-specif…
> cross-platform UI libraries don't really let you fine-tune the UI I want to be able to fine-tune the UI.