r52
commented
4 years ago In terms of possibility, of course it's possible 😄 . In fact in terms of feasibility, you probably wouldn't even need to change the backend ItemAPI code too much in order to support something like this, because JSON is used to pass around data most of the time even internally, so adding backend support for a feature like this would be relatively easy.
However, the frontend (UI and such) is a completely different story. (Re)implementing all of the UI elements in C++ to support these features is quite a big undertaking if I were to do this by myself, and I have no motivation right now to do a big rewrite/overhaul of all the UI because I've already stopped playing this league and I hate writing UI code. Those darned C# apps have the benefit of having streamlined UI tooling rolled into their language 🤣 .
Implementation wise, I'd consider one of these 3 options, along with what I think the pros and cons would be for each option:
1. Enhance current StatDialog
One option is to simply copy this Korean app's UI and implement all the corresponding elements into the current StatDialog class as C++.
Pros (not really)
- Keeps classes intact
- Minimal backend changes/support needed
Cons
- Hack job compared to other options
- C++ UI
- Lots of new C++ UI code
- Maintenance nightmare
- Inflexible (must recompile to inspect/change/debug)
2. Re-implement StatDialog as QML
The next option is to rewrite StatDialog (and possibly the price template as well, if we intend to merge simple search into the same dialog to keep uniform UI elements) using Qt's QML markup language that includes these features from the ground up.
Pros
- Dedicated, powerful UI markup language
- Flexible, makes future maintenance and feature additions like these much easier
Cons
- BIG rewrite
- Requires some backend changes and support for data interoperability with QML types
- New/unfamiliar script to learn
3. Re-implement StatDialog and price template as a web app
The third option is to rewrite StatDialog as well as the price template as a web app. Preferably as pure HTML/CSS/JS in order to take advantage of libraries already available to PTA (Qt WebEngine), but adding a node.js/Electron backend to PTA wouldn't be difficult (although I wouldn't recommend this because adding an engine for one piece of UI seems not worth and would probably lead to a lot of extra bloat).
Pros
- Easy code (HTML/JS)
- Easy maintenance and new feature additions
- Minimal/trivial backend changes
Cons
- Still a big rewrite
- HTML/JS. As a local app may run into all sorts of restrictions that may require potentially unsafe/dirty workarounds (for example CORS rules).
Personally, I'd choose option 2 or 3 for this feature as they provide the most flexibility going forward. But like I mentioned, I don't have the motivation to do this right now, even if I'd also like to have something like this ready for next league as well.
If you'd like to take a stab at this yourself, please be my guest as I'd very much welcome extra help on a hefty feature like this. If you do decide to try it, let me know if you have any questions or need any support on my end. Otherwise, maybe I'll have more motivation when GGG announces the details of the next league 🤣
Rottenbeer
I found https://github.com/redSol/PoeTradeSearchEN, which is the english translation of a korean Trade Searcher and has some nice features, like the search being included in the trade window itself:
Price Listings
Do you think it's possible to add this to PTA?