Pocket Plane Group
Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: Wisp on February 26, 2017, 10:05:03 AM
The source code is now available: link (https://github.com/WeiDUorg/zeitgeist).
32-bit Windows build with dependencies: link (https://www.dropbox.com/s/9oww1og9kpjj6fr/zeitgeist-winx86-170227.7z?dl=0)
64-bit Linux build without dependencies: link (https://www.dropbox.com/s/e3tbpo7f765l7qz/zeitgeist-amd64-170227.zip?dl=0)
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:
- 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
- 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
- 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
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.
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.
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).
On the basis of a quick, provisional test...:
Current head depends on on WeiDU's devel branch.
After a bit of work, the component-selection window looks a bit like this (https://www.dropbox.com/s/zf2mjqfakadomdm/zeitgeist3.png?dl=0). The nested components are subcomponents. The intention is that these should use radio buttons (https://en.wikipedia.org/wiki/Radio_button) 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).
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.
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 , 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 (https://zamjad.files.wordpress.com/2009/10/combointree_thumb.gif?w=400&h=300); 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 (https://www.codeproject.com/KB/tree/treeviewadv/treeviewadv4.png)'s your stuff of nightmares.
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.
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.
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.
Now the component-selection view looks a bit like this: link (https://www.dropbox.com/s/hj12qjrqoaxvk2k/zeitgeist4.png?dl=0). 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.