Windows 7 Ultimate 64x. I hope it’s not an issue with 32x with 64x…
Watermonkey: I think in these situations Vista = 7, what he probably needs is either someone with XP or someone with Windows 7 who can run XPMode.
I’ve just finished importing my collection, and I’ve noticed one thing: Grotesque fetches cover art from IFDB, but some titles have a cover in the blorb file, but which is not in IFDB (like recent entries from competitions).
Is it planned to use the embeded cover art? There is no Linux program that does so.
(but let me be perfectly clear that I’m in my knees for what you’ve done so far)
Hmm I think like Peter said, Vista == Win7. Are you able to run Grotesque out-of-the-box?
I built it in 64 bit but I don’t think that’s the problem. When I run the packaging script, it fetches most of the important .dll files, like the GTK libraries, but at the end it lists some Windows ones that it didn’t include. I’m 99% sure it’s one of these that is the problem. Anyway, they’re all in the system32 folder, so they’re 32-bit libraries.
Here’s the list, for reference:
advapi32.dll
comctl32.dll
comdlg32.dll
gdi32.dll
imm32.dll
kernel32.dll
kernelbase.dll
msvcrt.dll
ntdll.dll
ole32.dll
shell32.dll
shlwapi.dll
user32.dll
winspool.drv
WS2_32.dll
kernelbase.dll is the likely culprit, it seems.
Yes, it’s planned. I’ve already implemented some stuff under-the-hood to accomodate it but I need to get blorb metadata extraction working well first. I’ll also support coverart files stored in the same folder as the game file, in case it’s not embedded but was distributed with the game in a zip file.
Nope. 
I unzipped the package and ran grotesque.exe. It crashed and referred me to a log file:
[rant]Traceback (most recent call last):
File “grotesque”, line 3, in
File “grotesque\main.pyc”, line 31, in
File “gtk_init_.pyc”, line 40, in
File “gtk_gtk.pyc”, line 12, in
File “gtk_gtk.pyc”, line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.[/rant]
I’m running Windows Vista 32-bit. I’ll see if I can find what version of Python I have, as some of the Python files are identified as such by Vista.
Edit: I have Python 2.5.2, release date Feb 21 2008. I also seem to have a GUI for Python named IDLE, but it also won’t run (it thinks maybe my firewall is interfering).
Ok that’s the same problem someone else raised with Windows XP.
hmmmmmmmmmm
Since I see a whole swarm of “Compiled Python Files”, would clicking on one of those do anything useful?
(Apologies for the stupid-ish question; I never really figured out Python. I actually found myself typing “l” in the command-line to try to figure out the documentation command. 
)
Ok, I’ve confirmed that even after completely removing the GTK libraries from the Win7 computer, I can still run Grotesque. So I think it’s pretty clearly related to the Windows version that it was built under. I’ll do some research to see if anyone else has encountered this when packaging Python programs for Windows…tomorrow though. It’s bedtime for me.
@ WaterMonkey, unfortunately Python 2.5 won’t run it. The way I did it, though, grotesque.exe has Python 2.7 built into it (which is why it’s so big compared to the Linux one). So, technically, you shouldn’t have to touch any of the Python files or have Python installed on your computer to run it (fyi .pyc files are compiled python files, meaning they’ve already been translated from human-readable Python code to machine-readable code…you shouldn’t have to worry about any of those).
Thanks for your patience with me, everyone. We’ll get this working for sure…
Sorry but I can’t log bugs without registering in Sourceforge and I have no reason to register…
This may or may not be connected to the issues that other people are having, but I’ve noticed - about three or four days ago, just haven’t said it yet because I’m a bad and lazy person - that if a game file has extensions all in caps, Grotesque will not automatically recognize it when “importing entire directory”, and if selected individuall that file with be imported as type “Unknown”.
So, for instance, “BVENT.d64” (for Panks’ B-Venture) will be allright, but not “BVENT.D64”.
Another thing, so many games in IFDB have no IFID. But they all have TUID. What if we could use Grotesque to look up a game via its TUID as well as its IFID? Or hey, drop IFDB altogether, since its only benefit is to browse IFDB for entries, and since not every entry has an IFID…
And regarding that (low-priority) idea of having the option to open the folder of the game, I noticed how D-Fender does it, and if you could do it it would be super (and if you can’t it’s quite allright). D-Fender opens a separate pane with lots of tabs, for Screenshots, Sound captures, Video captures, et all, and Data folder. In this case only the data folder would be relevant - it shows the folder set as the “data” folder for the selected game, in an Explorer sort of way.
If it’s too hard/impossible to implement then never mind, but I thought I might as well mention it.
That phrase was kinda funny :-/ It states the reason right there: logging bugs…
I guess it was. I’ll rephrase a bit - I don’t want to register on yet another site, especially such a site as SourceForge which houses all sorts of different projects, when all I want to do is comment on another couple of things. If this thread didn’t exist, I wouldn’t bother at all - someone was bound to pick up on the CAPS thing, and I could live without my other two suggestions - wasn’t worth the hassle of registering somewhere else. I’m tired of that. Looks like everything wants you to be registered. One day I’ll need to be registered to use a search engine.
Duly noted. I’ll try to fix that for the next release but right now I’m working to make the underlying treaty of babel code to be much more robust (and to expand it to include all the formats that the ToB software handles, like Adam and Magic Scrolls).
For the data folder, at least for now, I have to see what easy options are available to me that are cross-platform before I decide which way to do it. It may be easiest to just have it pop up a new Explorer/Nautilus/Whatever window showing the folder’s contents. Otherwise, I’ll be forced to do it kind of how you describe D-Fender to do it. I hadn’t thought of doing it that way, and it might be easier to do in the end. Thanks for the suggestion!
Now, back to the Treaty of Babel. 
Oh and re the TUID, yes I’ve thought of that but I haven’t checked if I can search the IFDB by it the way I can with the IFID (I’m pretty sure I’ll be able to). It’s on my to-do list!
Can anyone point me in the direction of some TADS stories that have a cover embedded in them? I don’t seem to have any in my collection and I’m not sure how I’d specifically search for such a thing.
Just to keep everyone updated, I spent the whole weekend coding. Using a fairly robust set of test cases, I can verify that my code exactly replicates the output of the official Treaty of Babel software for adrift, agt, alan, blorbed anything, DOS executables, glulx, hugo, level 9, magnetic scrolls, tads and zcode. That means no more funky, mis-generated IFIDs, more autodetection of a larger part of your library, etc. I’m putting the finishing touches on that now by adding coverart extraction for blorbs and tads games. The next release will mostly consist of this and some bugs related to import and not much cosmetic. Hopefully it’ll come some time this week…
Return to Ditch Day, Dead Like Ants and Macrocosm come to mind. To see if a TADS game has cover art, you can open it in QTads (at least v2.1.1) and select “Game->View Metadata”. It will also show you other metadata entries, not just cover art.
Cool, thanks for the links. I don’t have QTads but I do have Babel, for CLI goodness 
I don’t know if all TADS games conform to Babel though. TADS has its own metadata standard and not all of it maps to Babel.
Babel is able to read tads metadata well, from what I can tell. It’s the ifiction specification with which tads is certainly…eh, not incompatible…supercompatible? Anyway, the Babel source code has functions for extracting tads coverart but according to that program, the games you listed don’t have coverart (well, still waiting for Macrocosm to download; it’s either slow or huge). If this is a problem that is inherent to Babel, I don’t forsee myself including tads coverart extraction, at least not now. The Babel sourcecode gives me ample insight into how to unpack these binary files, but if I have to figure out how to extract the cover art myself, it will take a lot more research and time to implement…
Nevermind, it found coverart in Macrocosm. Thanks!
I’ve exposed the Babel record in v5 TAFs in the latest version as raw text. I’ll update the Babel code to extract if I get time, but it should be pretty self explanatory.