News:

Don't forget to visit the main site! There's lots of helpful docs, patches, and more!

Main Menu

[ALTTP,SNES,Black Magic] Potential Qt5 GUI

Started by kramlat, March 15, 2015, 09:46:53 AM

Previous topic - Next topic

kramlat

Quote from: MathOnNapkins on July 20, 2011, 11:37:43 AM
Libraries are more abstract in that they're just reusable code that's designed to do something useful. In this case, it's designed to take a rom image and extract all the relevant data structures of the game. And then later when you want to save, reassemble it back together into a new rom image. But a library doesn't typically contain any visual elements. So no, it's not an open source editor, but it is a cross platform library that could be used to build editors on multiple platforms. As I am not a whiz at GUI programming, someone else will probably end up doing this step, though I would help if needed. Any editor I make on my own would probably be pretty clunky looking, but functional.
I was hoping to write a GUI in Qt (Qt uses C++).  Any chances that your library can be C++0x friendly as well as use signals and slots? Or must I simply make shims based on QObject to connect the code?

MathOnNapkins

I will have to get the code exported from the private SVN repo for you. Gimme a day or two. Iirc, the code currently actually requires certain c++11 features (uniform initialization). I don't know much about Qt5, still stuck puttering around with Qt4 occasionally.

kramlat

Qt4 code is easily ported to Qt5.  And I have designer for both as well as Creator 3.

MathOnNapkins

Well, cleaned it up and made the source CMake friendly as much as I could. There are some concerns about the overall interface that I am aware of, feel free to leave feedback (anyone):
http://math.arc-nova.org/source/Black_Magic_2015_04_04.7z

What I really need to do at some point is reevaluate how I'm using these Slot<>, Show<> and Ticket<> containers. A colleague of mine (that has helped with a lot of this code) remarked that it's probably unnecessary, but I'm paranoid about changes to shared resources not being propagated. So... a lot of brainstorming is needed. This part of the project hasn't been my focus lately though, so I haven't taken a good hard look at it yet. I've been much more absorbed in making a fully reassemblable version of the disassembly, along with a custom assembler to do that.