well, shit
As I decided to continue working on the new cheat system for melonDS, I devised a simple binary file format that melonDS will use to store cheat codes and associated metadata. Nothing terribly difficult.

Except then I need to properly design my basic blocks (AR code list parser thing, AR engine, etc) so that they can be interconnected nicely.

Which is where I began thinking about the kind of interface I would need for entering cheat codes.

And...

Uh oh.

libui doesn't support the kind of controls I want to use.

Generic has been thinking of a kickass debugger UI and running into the same issue.

So... it's time to take a decision here.

We haven't taken a decision yet. Basically we need a good UI toolkit, that, ideally, is lightweight yet well-featured, modular (so you don't need to embed a complete behemoth if you aren't using everything), uses native UI controls, supports drawing areas and OpenGL...

This is going to be another great moment of 'fuck technology'.

If you have any ideas that aren't Qt, your input is welcome.
autofire372 says:
Feb 27th 2020
> This may be my naivete, but if I may ask, why is Qt out of the question?

I think Qt fails Arisotura's "modular" requirement.
MelonMan says:
Feb 27th 2020
Pillow: I think melonDS is going to be merged into regular melonDS in 0.9.
Also, this emulator is also meant to run on Linux as well so you can't just use the native Windows apis. There are some frameworks that utilise native widgets on different platforms though.
poudink says:
Feb 27th 2020
as far as Qt goes, something about not being a fan of their growing monopoly I believe
Ammako says:
Feb 27th 2020
https://i.imgur.com/UGfStIk.png
Arisotura_ says:
Mar 1st 2020
considering the whole shitshow about UI toolkits and build systems and cross-platform development in general, I can only say the opposite: fuck technology. burn all computers, turn off all power plants, let's just meet our neighbors and do shit together.

also this is the real Arisotura, I'm just too lazy to log in again.
DoublePoint says:
Mar 1st 2020
>let's just meet our neighbors and do shit together.
Just did this, was very boring. Emulator development is still more exciting
kevincrans says:
Mar 9th 2020
I agree that build tools (and android/linux developent) is a hell.

For theory, this is how I would do it: all java .class-es are in a .dex (Android's .jar) file which is again inside a .apk installer/shortcut creator. Execution of .dex makes Java cast the c++ program to Android's native Linux kernel. If you can master this, first port it to Windows on ARM, then to Chrome OS x86_64, enable it on Android, optimise and finally, Android ARM64.

Or don't go trough all that, fuck Android and just port it to Windows32 and make us buy an Imperion Nebulus Phone which emulates both Windows 10 x86 and Android on ARM64 Hooray!

Let's just hope mobile development will be more portable in the future.
kevincrans says:
Mar 9th 2020
You're btw emulating Arm on x86 on Arm, emulate-ception lol.
Just fooling around.
toastUnlimited says:
Mar 14th 2020
I would suggest taking a look at Glade (thus GTK+) if you haven't already. Not exactly sure how well it fits into your requirements, but it worked well for my C application.
Marck says:
Mar 16th 2020
Miss your posts and news about your work. Hope you're alright with this pandemic context. Hugs from Brazil!
Post a comment
Name:
DO NOT FILL