Views: 231,162 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 07-17-18 11:32 AM
Guest:

0 users reading Cross-platform UI toolkits | 1 bot

Main - Development - Cross-platform UI toolkits New reply


StapleButter
Posted on 03-29-17 11:12 PM (rev. 2 of 03-29-17 11:13 PM) Link | #6
melonDS currently uses wxWidgets, but this is by no means set in stone. I have heard things about wxWidgets that are... less than good.


Ideally, I want something lightweight and straightforward. melonDS should stay fairly simple.

Coding a different UI per platform is a no-no. Directly using the native toolkits would be as straightforward as it can get, but we know how that turned out in DeSmuME.


wxWidgets

:UP: not too heavy
:UP: well-featured
~ people keep saying it's bad
:DOWN: ties the program to a specific library version
:DOWN: requires a billion extra DLLs under Windows (or 6MB executable size when linking statically)


Full-SDL UI

:UP: lightweight, no extra toolkit required (minus file picker dialogs)
:UP: no dealing with interop between two toolkits
~ has its own style instead of using that of the system
:DOWN: more work required


libui

:UP: really lightweight
:UP: small enough that I could hack around its limitations and expand it
~ I couldn't get it to build under Windows. feh



whatever else

CuriousTommy
Posted on 04-02-17 01:22 PM Link | #28
wxWidgets

:UP: not too heavy
:UP: well-featured
~ people keep saying it's bad
:DOWN: ties the program to a specific library version
:DOWN: requires a billion extra DLLs under Windows (or 6MB executable size when linking statically)


I remember Dolphin developers talking about all the weird bug they have to deal with for using wxWidgets. I think that is the reason why they want to use QT in future.

Coding a different UI per platform is a no-no. Directly using the native toolkits would be as straightforward as it can get, but we know how that turned out in DeSmuME.


I am really glad that you are going with this policy. I was so disappointed that the Linux version of DeSumME does not have the same menu options as the windows version.

whatever else

By the way, what is your opinion on QT?

StapleButter
Posted on 04-02-17 01:30 PM Link | #29
1. it's a behemoth
2. why reinvent everything instead of using the native UI
3. it's... corporate

byuu
Posted on 04-04-17 01:59 AM (rev. 2 of 04-04-17 02:04 AM) Link | #40
If I may self-promote for a bit ... ;)

There is always hiro as well.

Basically, hiro's a GUI toolkit wrapper. So if you write a UI in it, you can target Win32, Cocoa, GTK+, or Qt.

The big win is that on Windows and macOS, it'll add about 100KiB onto your final (stripped) binary size. No DLLs at all.

I've also saved you literally hundreds of hours of frustration working around ridiculous bullshit bugs and limitations on each of these APIs. Things like Windows not letting you hide a menu option once it's been created, or macOS trying to make you use Interface Builder to make a GUI, or GTK+ rendering pixbufs in ABGR format (yes, seriously), or Qt's moc.

On the neutral side, the small size is a result of not having every possible control implemented. Basically, if you look at higan's UI, that's basically what's possible at the moment. Way more than enough for an emulator UI, even with a good debugger. But you're not gonna write an open-source Photoshop or something in it.

On the down side, it's not really documented well (best bet is looking at higan, sadly), and the API, although *mostly* stable, isn't 100% stable. You'd want to fork a version of the codebase and stay with that. You *may* experience bugs and have to fix them -- I might not be able to in some cases. But it works for me.

The library is C++11 code. It's very similar to Qt, but without weird language "extensions", and with modern lambdas and things. Also, everything is reference-counted, so you never have to call new/delete on anything.

This is kind of what it looks like to use:

https://gitlab.com/higan/higan/blob/master/higan/target-tomoko/tools/cheat-editor.cpp

https://gitlab.com/higan/higan/blob/master/higan/target-tomoko/presentation/presentation.cpp

Anyway, you won't hurt my feelings if you say no. Just thought I'd offer :)

EDIT: oh and being a single-man project and me being swamped with things, tech support will be rather shit. But, it shouldn't pose many problems.

StapleButter
Posted on 04-04-17 05:03 AM Link | #41
It's something I may well consider. Lack of documentation shouldn't be an issue with a codebase that is small enough, as long as it is sane.

I'm not really into the modern C++11 stuff (I prefer keeping things low-level, I know better what's going on behind the scenes), but hey, there's a start to everything.


It's also cool if it's something small, that I can easily expand and build upon. Something I thought about, since melonDS ended up getting two separate windows, is a list of games with things like their icon, title, etc, maybe whether the ROM hash is known to be good...

byuu
Posted on 04-04-17 01:36 PM Link | #42
> It's something I may well consider.

Cool, thanks :D
And again, no pressure if you don't like it.

> as long as it is sane.

Thankfully the entirety of hiro's API is in a single file.

https://gitlab.com/higan/higan/blob/master/hiro/core/core.hpp

It starts with generic objects that aren't shared, like Color, Gradient, Size, Font, etc.

Then it moves on to static objects like Keyboard, Mouse, Desktop, etc.

Then it moves into the shared Object system, where you derive Window, Action, Sizable.

Action is the base for menu objects, Sizable is the base for Layout and Widget. Widget is the base for all the regular controls.

> It's also cool if it's something small, that I can easily expand and build upon.

It's as small as these things can possibly get, honestly. There's about 50KiB of added code to wrap every core object inside of a shared pointer so that everything is reference counted. But freeing up the developer from new/delete on UI elements is definitely worth it.

But say, the entire Windows port is 160KiB of code. Cocoa is 130KiB. It's ... a good chunk of code, certainly.

The underlying idea behind hiro and keeping the API simple was so that ... let's say 10 years go by and all these APIs are dead. Or some new OS comes out and everyone wants to run apps on that. I wanted to have a codebase with an API where I could write a *new* hiro core as a weekend project.

At this point, it's more like a 1-2 week project to write an entirely new hiro backend. But ... I'd rather spend 1-2 weeks doing that, than 2-4 months rewriting my GUIs for every application I've written.

> a list of games with things like their icon, title, etc, maybe whether the ROM hash is known to be good...

People *really* hated the move to a library in higan, whose goal was similar (didn't quite have the NDS icons to help me out.)

But I think you may have a lot more leeway with the NDS, being a more modern system. It meshes well with the way N64, GC, Wii, DC, etc emulators work with lists of games. I think people are just stubbornly set in their ways when it comes to really old systems with tiny ROMs like the SNES.

Also ... Cydrak came up with this really awesome idea where sie uses standard Windows folders, but adds a desktop.ini file in, and you can see the NDS icon as the folder icon for the game, and double-click the game to play it. Plus a desktop.ini in the parent folder to set the view so the icons are sized well. Obviously that is Windows only. But it's an awesome way to launch games.

Of course, if you want such a browser built into your UI to work against .nds ROM files directly, that's possible as well.


Main - Development - Cross-platform UI toolkits New reply

Page rendered in 0.014 seconds. (2048KB of memory used)
MySQL - queries: 29, rows: 86/86, time: 0.009 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.