Author Topic: Graphical frontend  (Read 1145 times)

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Graphical frontend
« on: February 26, 2017, 10:05:03 AM »
I seem to be in a latent phase, there have been some improvements made earlier during the year and it looks like it might be a while before any more are made, so I thought I'd release a new build in case someone has use for it.

Source code: Link.
Windows package: Link.

If you are on GNU/Linux, you are probably better off building from source. I can't build for macOS. Sorry.

WeiDU 241 or later is required.

Changes since last:
  • Duplicates are not added to the uninstall queue
  • The uninstall queue is sorted/optimised before being processed
  • Better handling of EE game language; now done from the game window
  • Subcomponents and a few other things in the enqueue window are handled better
  • The terminal window cannot be closed until it is safe to do so, and it is also shown for uninstalls
  • The enqueue window has a check box for selecting or deselecting all components
  • Various small fixes and tweaks

Notable issues still unresolved:
Still no way of telling if a component or combination of components can be uninstalled beforehand.


Original post:

Quote
The source code is now available: link.
32-bit Windows build with dependencies: link
64-bit Linux build without dependencies: link

Windows XP does not appear to be supported.

The program has basic functionality and not too many rough edges. I apparently need to port it over to Qt 5 before I can provide any Windows builds (+the no doubt gruelling experience of awful Windows installers).

If you do tread, here are the issues I'm aware of:

Sharp edges:
  • It's possible, but advised against, to close the GUI widget you need to enter input should the mod ask for some; if you do so, and the mod does, the install will block indefinitely, possibly leaving your game in an inconsistent state; maybe it should not be possible to close the widget

Rough edges:
  • WeiDU needs to be configured manually (point the program to a valid copy of WeiDU and you're good to go)
  • Functions that need WeiDU are shown as enabled even with no WeiDU; eventually the functions that require WeiDU will be unavailable until a valid WeiDU is present
  • Uninstallation is done in some order that need not be optimal; the intention is that is will eventually always be done automatically in reverse installation order
  • EE language is configured from program settings and defaults to English; the intention is that it will eventually be done from the game list (which will make it look even more like a donkey's behind)
  • You can add the same components to the uninstallation queue more than once; WeiDU doesn't mind; eventually already-present components will be filtered out if you try to add them more than once
  • Maybe there should be some sort of thing happening to let the user know it's a long-running uninstall; currently it just happens transparently in the background (and will block other requests to WeiDU)
  • Probably some smaller stuff

Known issues:
  • Subcomponents, deprecated components, components that can't be installed on this game, etc., are all shown equally in the component list; fixes to WeiDU will be required
  • Translated component names will not be displayed correctly unless they are encoded in something compatible with UTF8; fixes to mods will be required; the good news is that UTF8 is fully supported and will work for all platforms
[/size]
« Last Edit: September 24, 2017, 11:00:14 AM by Wisp »

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #1 on: February 27, 2017, 07:11:20 AM »
Windows build is available. I'm uncertain how to package this up for Linux. It's easy enough to provide a binary and your distribution might already come with the required libraries, and they might even be in the "right" directories. There's one uploaded at any rate. It requires Qt5.
« Last Edit: February 27, 2017, 07:21:36 AM by Wisp »

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 226
  • Gender: Male
Re: Graphical frontend
« Reply #2 on: February 27, 2017, 02:07:09 PM »
32-bit Windows build with dependencies: link doesn't work

And no need for Windows installers - you can provide simple exe file. If you need any operation for first time usage, execute it at the first start of the application.
« Last Edit: February 27, 2017, 02:08:32 PM by AL|EN »
You cannot have progress without changes...

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #3 on: February 27, 2017, 02:52:11 PM »
Doh, I missed/cut off the file extension. Though apparently Dropbox can serve up an error #500, whatever that means. If it becomes a problem I'll try to arrange a mirror.

And no need for Windows installers - you can provide simple exe file. If you need any operation for first time usage, execute it at the first start of the application.
Oh, don't worry. I'd never inflict something like that on you guys. The archive is an executable and a gaggle of dlls. It can run from anywhere with no setup and you can move it freely (so long as the files stay together).
« Last Edit: February 27, 2017, 02:54:30 PM by Wisp »

Offline DavidW

  • Planewalker
  • *****
  • Posts: 218
Re: Graphical frontend
« Reply #4 on: February 28, 2017, 01:19:37 AM »
On the basis of a quick, provisional test...:


Awesome.

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #5 on: March 12, 2017, 04:23:44 PM »
Current head depends on on WeiDU's devel branch.

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #6 on: March 18, 2017, 12:16:04 PM »
After a bit of work, the component-selection window looks a bit like this. The nested components are subcomponents. The intention is that these should use radio buttons rather than checkboxes, but that's not done yet.

Question: should GROUPed components be nested as well? Subcomponents that are also part of a GROUP would be nested one level further in, under the GROUP. I don't find scrolling the list for cdtweaks to be particularly laborious, and most mods are smaller. Nesting GROUPs could help with selecting components (since you could select the entire GROUP with one click; selecting every component of cdtweaks IS laborious), but is that something people do and is it better than some kind of "Select All" button? Given the radio-buttonness of subcomponents, not nesting GROUPs would help subcomponents stand out (selecting all components in a set that included subcomponents would select the first subcomponent of the grouping).

Offline Galactygon

  • Modding since 2002
  • Planewalker
  • *****
  • Posts: 369
  • Gender: Male
  • Not an AD&D rules lawyer.
Re: Graphical frontend
« Reply #7 on: March 18, 2017, 03:14:00 PM »
I'd say yes ideally with an expandable tree menu. Atm I cannot imagine a solution for components that are part of multiple GROUPs. For subcomponents, it feels more intuitive to have drop down menus or something visually distinctive to prevent the user from confusing them with GROUPs. As most of us know subcomponents are mutually exclusive while GROUPed components aren't.

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #8 on: March 18, 2017, 09:14:23 PM »
I'm not sold on combo boxes for this. First, there's no way of displaying the SUBCOMPONENT common name. Second, there's no natural way of not choosing one of the subcomponents (I mean, you probably can have an empty row or something, but it's a complete hack). Third, aside from probably looking eye-wateringly ugly [1], it's going to clash with the check boxes, with both very different looks and modes of interaction, whereas radio buttons blend in, in both of these regards (I'll grant you that whether this is good or bad is probably subjective). Lastly, the longer the subcomponent name, the worse the aesthetics are going to be assaulted (to say nothing of the possibility of combo boxes of different lengths).

1. Don't look without goggles or something: link; I think it's telling that it is outright difficult to find screenshots of this combination, with most of the hits you do find being horror shows from Windows XP, I mean there's your stuff of nightmares.

Offline Galactygon

  • Modding since 2002
  • Planewalker
  • *****
  • Posts: 369
  • Gender: Male
  • Not an AD&D rules lawyer.
Re: Graphical frontend
« Reply #9 on: March 19, 2017, 02:17:15 AM »
Yes, I see now. I have no other qualms about radio buttons.

Do you think drop-down boxes can be used in READLN-type of commands with a fixed range of values? I get the gist READLN ought to be something we should do away with in favor of .ini files.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 226
  • Gender: Male
Re: Graphical frontend
« Reply #10 on: March 19, 2017, 01:10:58 PM »
Quote
It's possible, but advised against, to close the GUI widget you need to enter input should the mod ask for some; if you do so, and the mod does, the install will block indefinitely, possibly leaving your game in an inconsistent state; maybe it should not be possible to close the widget

Definitely should be impossible, if someone doesn't want such component, installation of the components should be finished and uninstalled. People will close it in the middle, repeat installation and the whole installation will go crazy.

Quote
Maybe there should be some sort of thing happening to let the user know it's a long-running uninstall; currently it just happens transparently in the background (and will block other requests to WeiDU)

Definitely user should know that something is going on under the hood. Long uninstallation/reinstallation could take some time and who knows what people will try to do (rur the game?) before it will finish.



You cannot have progress without changes...

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #11 on: March 25, 2017, 04:47:45 PM »
Now the component-selection view looks a bit like this: link. FORCED_SUBCOMPONENTs are handled by having the first subcomponent starting out already selected and making it impossible to deselect all subcomponents in the grouping. I shall hold off on introducing GROUPs, in favour of putting a Select-All tristate checkbox up by the Components label. AL|EN's concerns have been addressed by popping up the something-is-a-happening window that is used for component-installations for uninstallations, as well. It is also not possible to close it while things are a-happening.

Now I'm off to tame the wild beast of component requirements. I may have to resort to boolean algebra. If you don't hear from me within a month, I have most likely perished in the attempt.
« Last Edit: March 25, 2017, 04:58:27 PM by Wisp »

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 76
Re: Graphical frontend
« Reply #12 on: June 01, 2017, 10:12:23 PM »
I'd love to try to build this for macOS... but I don't really know how to "build" things.  I can probably learn - I learned Weidu! - but I probably need some nudging in the right direction.

I just downloaded Xcode 5.1.1, which the interwebs tells me supports C++ 11.  I'm looking into what Qt is and whether/how I can get v5 onto my system.

Anyone want to provide some guidance?  (Feel free to PM me here or on G3 to avoid polluting this thread with my ineptitude...)

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #13 on: June 03, 2017, 03:56:54 AM »
I'd first check if a package manager like Homebrew has Qt.
Otherwise, you can download something from qt.io, here.

Regardless, you may also want to read this, which deals with integration with XCode and various things specific for macOS.

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 76
Re: Graphical frontend
« Reply #14 on: June 03, 2017, 09:20:28 AM »
Thanks. I have Xcode 5.1.1 installed (the most recent version that supports 10.8 ), which has support for C++ 11. And I installed Qt 5.3.2 (also the most recent which supports 10.8 ), which also installed "Qt Creator" or whatever it's called. I can open the .pro file in either app, but not sure what to do then...
« Last Edit: June 03, 2017, 01:24:54 PM by subtledoctor »

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #15 on: June 03, 2017, 09:39:05 AM »
I use qmake on Linux, where you run the qmake binary to create the Makefile and then run make to build the program.
On Windows, the path of least resistance was using Creator. Creator is essentially an IDE by/for Qt. You open the .pro file and (IIRC) in the bottom left corner, there're some buttons for running the program (which will first build it).
As per the second link I posted, there's supposedly some way of creating an Xcode project, which I guess allows you to build the program that way.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 226
  • Gender: Male
Re: Graphical frontend
« Reply #16 on: June 05, 2017, 02:21:21 PM »
Quote
Translated component names will not be displayed correctly unless they are encoded in something compatible with UTF8; fixes to mods will be required; the good news is that UTF8 is fully supported and will work for all platforms


To fix this issue, you have to:
1. Implement this request: http://forums.pocketplane.net/index.php/topic,29492.msg337542.html#msg337542
Quote
I don't know if this would be an in-demand feature, but how hard would it be to create an inverted version of HANDLE_CHARSETS, i.e. distribute .tra files in UTF-8 encoding and convert at install to Windows codepages?
UTF-8 is the default encoding for many modern text editors, and when mod authors receive translations via email or PM, the translated lines will usually be in UTF-8 (unless the translated files is a CP-encoded attachment). So, this could be a handy feature.
as it will allow for having language-specific characters properly displayed at the console. And it will allow for direct modification of the files at "popular code hosting sites"
2. Ask modders/mod hosting maintainers to adapt mods.
3. If there will be complains by the Windows user, tell them to use Windows 10 Creators Update to not see strange encoding issue for text displayed during installation in the text console.
« Last Edit: June 05, 2017, 02:22:10 PM by AL|EN »
You cannot have progress without changes...

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #17 on: June 09, 2017, 04:10:25 PM »
Setup strings are loaded before any TP2 code runs and there is no existing mechanism for having them reloaded. As such, HANDLE_CHARSETS is of no use here. Additionally, a feature for converting from UTF8 to local 8-bit encodings would be nearly obsolete as soon as the shell menus got their voyage to out behind the shed, so I'm not expending any non-trivial effort on it.

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 902
Re: Graphical frontend
« Reply #18 on: September 24, 2017, 11:00:45 AM »
Original post has been updated with a new build.

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?: