The only issue I have is that the game window is fully the depth of the screen and therefore I cannot resize it vertically by dragging the bottom edge.
Is it not the characteristic of Windows that every window has to have its own menus? On the Mac there’s a global menu bar at the top of the screen, but that’s what Windows doesn’t have.
And back when I was using GUI Linux, it followed that model.
No. For one thing, you can build an entire Windows app without menus; most games don’t have menus. For another, the whole point of menus per-window is that each window can have its own different menu, or, optionally, none at all.
Actually Microsoft is phasing out application menus in favor of “ribbons” in their own first-party apps, and they’re not really part of the UI guidelines for Windows any more. I think the current best practice on Windows (And also effectively on Linux, where Gnome is also in the process of ridding itself of application menus) is to think long and hard about whether your app really needs one.
The main window can have menus. Although as of late, new applications have done away with menus altogether; Microsoft with their “ribbons” and KDE/Linux with their whatever-it’s-called equivalent.
Sub-windows don’t have menus though. Unless it’s a work-window, like when your main window spawns an editor window; in that case, there should be menus like “Edit->Copy” and such, or a “View” menu for an image view window, etc. Preferences windows also don’t have menus.
Not that it’s the end of the world if every window has menus. It’s just that it feels weird as hell due to it looking like the odd man out.
Here’s the question: on Windows (with 0.1.1) you can drop a glulx file onto the app and it will launch. (It’s more of a nuisance to set up a file association, I haven’t found the docs on how to make that automatic.)
Does that work on Linux? If so, which version of Linux? (Gnome?)
Just don’t forget to make that opt-in instead of opt-out, okay? When a program hijacks file associations without asking, it sometimes causes me more hassle than it’s worth. I’ve got it set up so that I can right-click a Glulx game and choose get both the “Open with Git” (default) and “Open with WinGlulxe” (for some Spanish games). I also have nice icons for each ZMachine format. When I installed nitfol, it overrode them all without asking. I immediately deleted nitfol (well, not immediately, I tried it out first and couldn’t get it to work) and spent the next fifteen minutes restoring the associations one by one.
It works on all desktop systems that follow the XDG standard (which includes all the relevant ones, at least.) You need to install a .desktop file and an .xml file for your application. You do that with xdg-desktop-menu and xdg-mime. If you want to also register icons for the file types, you can do that with xdg-icon-resource.
Familiarity with the command line is irrelevant here. Someone without a desktop would not be trying to install a desktop application, since it wouldn’t even run.
That’s a confusion about what “desktop environment” means. In Linux speak, a desktop environment is a complete integrated desktop shell (with a file manager, task manager, notifications, and so on) similar to what on Windows or OS X is considered part of the OS. It should be pointed out that desktop environments on modern distributions are all mostly compatible when it comes to things like window generation, notifications, and so on, and it is possible to write desktop-agnostic apps, though it might require more knowledge of the guts of Linux desktop environments than is comfortable.
However, you’re not obligated to run them to have a graphical interface; you can run a naked X server (X being the old-fashioned Unix GUI stack that Linux inexplicably still runs), or X with just a window manager, and still run whatever graphical apps you want; a lot of people choose to do that.
However, when it comes to drag-and-drop, you don’t actually need a desktop environment installed for that to work; you can run a file manager by itself, either one designed to be run standalone or one that is part of a desktop environment, and drag-and-drop will work for file types that have the appropriate file associations set up in the “usual” way…
As for the menu thing: I’ve adapted the Win/Linux version to omit the “View” menu on the two static windows (About and Postcard). I’d do the same on MacOS, but it’s currently not possible to adjust the contents of the global menu bar.
I’m leaving the rest of the menus on the static windows. It may look strange, but you want to be able to do the stuff that’s in the menus. Electron doesn’t have a “ribbon” UI feature so that’s not in the cards.
To clarify…for me, it wasn’t so much the presence of menu bars that threw me–it was more that there was no visual distinction between available options and unavailable options. I’m used to this sort of thing
so it feels as though non-grayed-out items are supposed to have some obvious effect.