Grotesque 0.9.3: IF library manager

After a national holiday well spent, I present to you version 0.9.2!
sourceforge.net/projects/grotes … que/0.9.2/

0.9.2 Release Notes

  • The program will no longer crash upon failing to extract metadata from a file
  • Fixed a bug which prevented editing stories in GTK2/Windows
  • Added support for associating file types (extensions) with story formats
  • Added the ability to manually specify the story format in the edit dialog
  • Fixed the bug which prevented TADS3 games from being noticed during import
  • Made file availability during import depend on the file type extensions set by the user (ie whether Grotesque tries to import a file during recursive import or whether a file is visible during individual import)
  • Added automated library backup/recovery
  • Fixed a bug which prevented adding an interpreter
  • Added a button for finding an interpreter via a file dialog when adding/editing interpreters.
  • The Windows version should actually be able to save/load the library now. If you used 0.9.1 and 0.9.2 says that your library is corrupted, don’t try to recover it. It’ll fail. I’m sorry to say that Windows users will have to re-import their library

I’m pretty sure that this one is a lot more stable and solid than 0.9.1, but as always, your thoughts, bugs, ideas, etc are all welcome!

Tutorial: How to add support for a new story format

Out-of-the-box, Grotesque supports zcode, TADS2, TADS3, ADRIFT, and Glulx stories. Of course, there are many more formats out there than just these. Fortunately, it’s easy to add support for other formats in Grotesque. In this tutorial, we’ll add support for old DOS games using DOSBox to launch them.

  1. First, we need to let Grotesque know about the DOS format. Click the Preferences button and switch to the Interpreters tab. Click the Add button. In the dialog that pops up, we have three fields to fill out. The first one is the format, which we will use to identify games. Type in “dos” (without the quotes). In the next field, we enter the extensions of files of this game format. Most DOS games have either .exe or .bat as their extension. Enter “exe,bat” (again without the quotes). But, don’t worry. If you put spaces in there, or you include the leading “.”, Grotesque will clean it up and put it in the format that it wants. Finally, we need to specfy DOSBox as our interpreter. We can click the Open button to try to find it on our filesystem, but say we know that it exists at “/usr/bin/dosbox”, so we can just type it in directly. Click “OK” to finish and close the Preferences dialog

  2. Let’s say you store all of your DOS games in one folder. We’ll import it by clicking the button with the folder on it, finding the folder and clicking OK. Since we told Grotesque that we expect some of our games to have .exe or .bat as their extension, it will now grab those files when it imports. However, it won’t be able to extract any bibliographic information from them, so you will have to manually edit them.

  3. The edit window will show the executable’s name and will show that it’s in the “dos” format. If you’re not sure which game it is from the executable name, click the Play button on the edit dialog to launch the game and figure out what it is. Then, it’s easiest to go to ifdb.tads.org and search for that game. Copy the IFID listed in the game information if it has one and paste it into the appropriate field on the edit dialog. Click the Search button and the rest of the fields will be filled in (and, if there is cover art on IFDB, it will be downloaded as well). If there’s no IFID, sadly you’ll have to fill it in manually. Click OK when you’re finished. If there are more games to edit, you will move on to the next one, otherwise you’re finished and you can play them now! Since .exe files are common and not all of them are IF games, if Grotesque tries to import some non-IF one, just hit cancel on the edit dialog and it’ll skip it.

Please note that this will only work if your interpreter can launch a game from the command line. If you can only open games from within the interpreter’s own graphical user interface, Grotesque won’t be able to work with it.

If you need help with anything, let me know!

Looking seriously good, but I’m sorry to say that Adrift is one of those cases where all Grotesque can do is launch the app… but hey, I thought of something: wouldn’t it make sense for Grotesque to try to run a game with the interpreter the user defines… but if the user defined no interpreter at all then use the usual OS file association?

By the way, in windows double-clicking on a game still doesn’t launch it.

And hey… great work. :slight_smile:

Damnation, I forgot to test the double-clicking.

Ok, I’m also having errors running adrift games. I’ll look into that.

As for using the OS defaults, I’m afraid that’s non-trivial to implement. :frowning: If I do it, that’ll come at a much later time.

These problems aside, I hope that you can at least use it for most cases!

Scratch that. I can run *.taf ADRIFT games with no problem. If I try to run a *.blorb one, it fails, but it’s not Grotesque that’s failing, it’s Gargoyle.

Can you send me a link to an ADRIFT game that’s failing for you?

Oh, I just tested with Adrift 5 (which I haven’t used and don’t plan on using until it allows me to customize fonts and colours and until it plays 3.90 games), and with Adrift 5 it does work.

Pity to hear the OS default thing is not trivial… it would have allowed for every instance where for some reason or other something didn’t quite go as well as planned.

EDIT - Hey, I found a way to use D-Fend with Grotesque. :wink: Things look a log uglier in D-Fend, but I can now load it from Grotesque, so it’s perfectly ok.

BTW, I thought up two suggestions for the future.

1 - the OS thing. It’s always good to have, even if it’s a lowlowlow priority. And that’s it, I won’t ever pester you with it again. :slight_smile:

2 - an option to open the folder of the game. I know it sounds unnecessary, but many games have feelies, manuals, graphics, critical for play. If we could open the folder where the game is located, if we have all our feelies there, we can easily access them.

And that’s it from me. I’m now off to happily export my IF library to a front-end I’ve been dreaming of for years.

:smiley:

EDIT 2 - The only problem I foresee is when I want to play Windows games. Naturally, there’s no emulator for those… I mean, I CAN create an “interpreter” entry for every Windows-only game… like an interpreter called “Adventures in Egypt”, linking to the game, then create the entry for “Adventures in Egypt” and put - you guessed it - “Adventures in Egypt” as the format. THAT works. It’s ugly and hacky but it works. :wink: I might well do that.

phew

Cool! Technically, it’s so flexible now that you can use it with just about anything…got a bunch of old non-IF games? You can now organize them with Grotesque (not that I can support such deviant behavior, of course)

Don’t worry, I’ll keep it in mind. If someone else has already written a library in Python which implements similar behavior, I can just use that rather than re-inventing the wheel. So, I’ll look into it!

Ah good idea! I’ve thought of that too. I’ve been trying to think of the best way to do it though. Right now I like how Grotesque has a fairly minimal interface with few buttons and no menus. I’ve planned to include in each game’s description some hyperlinks to the game’s presence on the web (IFDB site, etc). I think I can also include a Open Game Folder hyperlink that doesn’t link to the web but opens a folder instead. I need to experiment though. This will be in by 1.0 for sure!

Glad to hear that you like it! As you use it more if you think of other ideas that could improve it, just let me know.
I hope your library isn’t so big it’s going to launch a denial-of-service attack on the IFDB site :smiley:
(seriously…we should all probably do it a bit at a time, just out of politeness :stuck_out_tongue:)

I don’t know Python, but if you can call the Windows API from it (is that possible?), it is trivial to do in Windows: Simply call ShellExecute on the filename. Sorry if that’s completely irrelevant (I mainly use C, C++ or ObjectC).

Turns out that the functionality is built-in for Windows. There’s a 3rd party library that implements it for Gnome & KDE, and its license allows me to bundle it with Grotesque!

Ok, so how about this:
In the settings dialog, on the Interpreters tab, at the top there’s a checkbox that says something like “Use Operating System Defaults”. If that’s checked, the interpreters list and the add/edit/remove buttons are all inactive (greyed out). Launching any game will use this method to let the OS figure it out. It’s up to the user to make sure the OS has programs associated with all the filetypes. If the checkbox is unmarked, the user can specify interpreters as he/she wishes.

Alternative, less obvious method:
The user simply leaves the interpreter field blank for any story format that he/she wants the OS to handle. This way, a mixed strategy can be used, with some formats having their interpreters specified and others under OS control.

Which do you prefer?

Honestly? Both. :slight_smile: Have the checkbox and, if the checkbox is unchecked and the interpreter field is empty, launch the OS default.

Got it! I think I can get that in by 1.0 then.

Ok, tomorrow I’m going back to reality (work) after two weeks of hanging out at home so development will slow a little bit comparatively. It’ll give everyone time to use the program a bit and find some rough edges.

The second method won’t be unobvious if you add a small note next to the interpreter field, saying that it can be left blank to try and open the file directly.

Looking good! :wink:

5.0.20 already allows customised fonts and colours, I’ll get working on the 3.90 support… :laughing:

An IF frontend…

Ability to load with my OS defaults…

ADRIFT 5 supporting customization and 3.90…

…is it christmas? Am I dreaming?

Grotesque is able to handle everything I throw at it and more. It’s a wonder. :slight_smile: Just one tiny tiny little thing… every time I open it it defaults to “show the games in the order I’ve added them”. I’d much rather have it default to the last thing I set it to, which is usually alphabetically.

Incidently, I do hope that when the new version comes out I won’t lose any of my settings.

Glad to hear it’s working, especially the Windows one!
I’ve been wanting to implement saving the sort order for a while now, as well as saving the order of the columns themselves (you can rearrange them). I haven’t found a very good way to implement it (until just now an idea hit me, at least for the sorting…column order remains elusive). I’ll keep trying…

Don’t worry, the settings file is not going to change at all, and if I do change things so drastically, I’ll be sure to include functionality to migrate your settings.

I’m thinking about an “Advanced Search” function. Would that be useful? Right now you can only filter/sort/search by one column at a time. Would you want to be able to, say, search for all Zorkian games from 1992 which have coverart?

It would be an interesting search, and I’m all for as much functionality as possible, but I think the “basic” search is already great. :slight_smile:

I’m trying to package this for Gentoo Linux. Now I’ve already did so, but when running it, I get:

Traceback (most recent call last): File "/usr/bin/grotesque", line 2, in <module> from grotesque import main File "/usr/lib64/python2.6/site-packages/grotesque/main.py", line 34, in <module> from library import Library File "/usr/lib64/python2.6/site-packages/grotesque/library.py", line 32, in <module> from filterstore import FilterStore File "/usr/lib64/python2.6/site-packages/grotesque/filterstore.py", line 23, in <module> from collections import Counter ImportError: cannot import name Counter

This is with Python 2.6.7 and PyGTK 2.24.0.

In case it matters, here’s the full build output:

[spoiler][code]>>> Emerging (1 of 1) games-util/grotesque-0.9.2 from Local

  • grotesque-0.9.2-gtk2.tar.gz RMD160 SHA1 SHA256 size :wink: … [ ok ]

Unpacking source…
Unpacking grotesque-0.9.2-gtk2.tar.gz to /var/tmp/portage/games-util/grotesque-0.9.2/work
Source unpacked in /var/tmp/portage/games-util/grotesque-0.9.2/work
Preparing source in /var/tmp/portage/games-util/grotesque-0.9.2/work/grotesque-0.9.2 …
Source prepared.
Configuring source in /var/tmp/portage/games-util/grotesque-0.9.2/work/grotesque-0.9.2 …
Source configured.
Compiling source in /var/tmp/portage/games-util/grotesque-0.9.2/work/grotesque-0.9.2 …
python2.6 setup.py build
running build
running build_py
creating build
creating build/lib
creating build/lib/grotesque
copying src/grotesque/library.py → build/lib/grotesque
copying src/grotesque/settings.py → build/lib/grotesque
copying src/grotesque/storyremovethread.py → build/lib/grotesque
copying src/grotesque/main.py → build/lib/grotesque
copying src/grotesque/infopaned.py → build/lib/grotesque
copying src/grotesque/settingsdialog.py → build/lib/grotesque
copying src/grotesque/settingsassistant.py → build/lib/grotesque
copying src/grotesque/libraryview.py → build/lib/grotesque
copying src/grotesque/filterstore.py → build/lib/grotesque
copying src/grotesque/init.py → build/lib/grotesque
copying src/grotesque/librarypaned.py → build/lib/grotesque
copying src/grotesque/libraryfilterview.py → build/lib/grotesque
copying src/grotesque/infoview.py → build/lib/grotesque
copying src/grotesque/progressdialog.py → build/lib/grotesque
copying src/grotesque/libraryloadthread.py → build/lib/grotesque
copying src/grotesque/updatexmllibrary.py → build/lib/grotesque
copying src/grotesque/storyimportthread.py → build/lib/grotesque
creating build/lib/treatyofbabel
copying src/treatyofbabel/tads.py → build/lib/treatyofbabel
copying src/treatyofbabel/babel.py → build/lib/treatyofbabel
copying src/treatyofbabel/blorb.py → build/lib/treatyofbabel
copying src/treatyofbabel/ifformaterror.py → build/lib/treatyofbabel
copying src/treatyofbabel/zcode.py → build/lib/treatyofbabel
copying src/treatyofbabel/ifdb.py → build/lib/treatyofbabel
copying src/treatyofbabel/init.py → build/lib/treatyofbabel
copying src/treatyofbabel/ifiction.py → build/lib/treatyofbabel
copying src/treatyofbabel/storydata.py → build/lib/treatyofbabel
copying src/treatyofbabel/glulx.py → build/lib/treatyofbabel
copying src/treatyofbabel/adrift.py → build/lib/treatyofbabel
creating build/lib/thirdparty
copying src/thirdparty/which.py → build/lib/thirdparty
copying src/thirdparty/init.py → build/lib/thirdparty
creating build/lib/grotesque/data
copying src/grotesque/data/stars_0-5.png → build/lib/grotesque/data
copying src/grotesque/data/star_empty.png → build/lib/grotesque/data
copying src/grotesque/data/stars_2-5.png → build/lib/grotesque/data
copying src/grotesque/data/stars_0.png → build/lib/grotesque/data
copying src/grotesque/data/stars_1.png → build/lib/grotesque/data
copying src/grotesque/data/star_half.png → build/lib/grotesque/data
copying src/grotesque/data/stars_1-5.png → build/lib/grotesque/data
copying src/grotesque/data/stars_3.png → build/lib/grotesque/data
copying src/grotesque/data/stars_4.png → build/lib/grotesque/data
copying src/grotesque/data/stars_2.png → build/lib/grotesque/data
copying src/grotesque/data/stars_5.png → build/lib/grotesque/data
copying src/grotesque/data/stars_4-5.png → build/lib/grotesque/data
copying src/grotesque/data/star.png → build/lib/grotesque/data
copying src/grotesque/data/grotesque_icon.png → build/lib/grotesque/data
copying src/grotesque/data/stars_3-5.png → build/lib/grotesque/data
warning: build_py: byte-compiling is disabled, skipping.
running build_scripts
creating build/scripts-2.6
copying and adjusting grotesque → build/scripts-2.6
changing mode of build/scripts-2.6/grotesque from 644 to 755
Source compiled.[/code][/spoiler]

Ah, thanks for letting me know! I use a built-in Python module that I guess wasn’t introduced until version 2.7. Fortunately, it’s quite easy for me to work around this. Unfortunately, I can’t work on it at the moment and it will have to wait until the next release.

I guess I need to bump up the Python version requirement.

Ah, OK. That’s easy to fix on my part too. I can simply bump the version req of the Python dependency in the Gentoo ebuild script which will make sure the user installing it will have Python 2.7 installed. (2.7 is in Gentoo for a long time now, it’s just that I didn’t allow the update yet on my system and was actively blocking it; the vast majority of other Gentoo users already have the updated 2.7 Python.)