Ideas/suggestions for Barrel

[HiPhish]

Hello

I don't know what your exact goals and guidelines for Barrel are, so I'm just going to throw in some ideas. Please let me know what you think of them.

The way I see it I would like something like a "wine cellar" or a "wine rack"; a place to store your various "wines" and have them all in one place. Then you pick what you want and when you're done it gets put back. I would design Barrel around the idea that it should manage all your various Wineskin setups and store them away from the user, but still accessible through the interface.

Let me elaborate: the user has a Wineskin wrapped game and drag&drops it into Barrel's window. Barrel then recognizes it as a Wineskin wrapper and starts taking it apart. The Wine engine is put in a folder for engines (except if there is already an engine with that name, then nothing happens). The hard drive of the wrapper is stored in its own folder and then Barrel associates that folder with the engine and the wrapper settings, icon, registry hacks and so on.

The idea is to strip out the boilerplate stuff every Wineskin wrapper includes by default. I know it's needed to make sure the wrappers can run on their own and I agree with that design decision, but if we centralize it then there is no more point to it. If you have been using Boxer you'll know what i mean, all Boxer gameboxes rely on the main application for the emulation and only contain the game files.

By making it possible to drag&drop existing wrappers into barrel it will also be possible to disassemble commercial games, like Wineskin ports sold on GoG.com

If a user drag&drops a game out of Barrel's windows the wrapper would be re-assembled again with its current settings and engine. If a game gets deleted and its engine is not used by any other game the user should be asked whether he or she wants to delete or keep it. This also means there should be a list of imported engines and what games use them.

The "custom EXE" tool of Wineskin could be integrated into the contextual menu. Let's say I want to play Icewind Dale, the configuration is handled outside the game by a different EXE. I would use the custome EXE creator to create a shortcut to config.exe and then if I want to play the game I double-click it and if i want to use config I right-click it and choose Config (or whatever I named it). This would also be very useful if I wanted to put more than one game into the same wrapper.

Similarly all other tools (winecfg, console, regedit) should be accessible through right-click. Maybe they could be under a common menu entry like "Tools". It should be possible to include extras like manuals as well.

And finally there is the name. I like "Barrel", but it doesn't really convey what the app is about. A barrel is a container that holds only one liquid or a mix of liquids, like a bottle. It made sense to name Wineskin after a wine skin, it's something you use to carry one Wine setup around. However, for your app something that can hold many different containers of liquid would sound more appropriate. How about WineRack or WineCellar?

I don't know if you want to support more than just Wine. CXEx and its precursors shouldn't be supported, they don't run on Lion and Barel needs at least Lion, so it wouldn't be worth the effort. Unless you want to make it possible to automatically convert them to Wine, that would be neat. Cider is proprietary, so it would be rather messy to deal with it. Maybe later. Native apps are too specific, the only thing I can see working is to just copy the whole thing over and disable all the Wine specific functionality. Barrel wouldn't do anything other than just present a shortcut to the full app.

That's all I can think of for now. Even if you disagree with me, please let me know what your plans for Barrel are, I would really like to see a Wine port manager on OS X.

cheers, HiPhish

PS: I made a quick mockup of what I described above, if you can't quite follow my writing: http://i39.tinypic.com/2narzaw.png

[ThanosSiopoudis]

Hi, before proceeding with your suggestions, let me elaborate first on exactly what I have in mind for Barrel.

The whole point of Barrel and the main idea behind it is to create a library for wine ports and to make it as easy as possible to install a game, for a user that has no idea what wine is, or how it works. Barrel, should be able to handle all games in its library function, whether it's wrapped in a Barrel bundle, a Wineskin bundle, Cider, native, or anything else that can run in 10.7+ So it's got a double purpose: a library manager, and a bundler. The structure of the library files is the following:

1. Barrel stores everything in its own library path. It has a default path inside the user's Library folder, or it can be manually set by the user.
2. The library holds the database file, where all information is stored in a managed data model (.storedata - basically an SQLite db)
3. The game bundles (.app) reside in the "games" directory in the library folder, organised accordingly in their genre directory (i.e. all adventure games in the "adventure" folder, strategy games in the "strategy" folder etc)
4. When the user runs a game, Barrel simply launches the .app. Having an .app bundle is good for two reasons: it is ready and already there for launching, therefore no time waiting for Barrel to create an .app in order to start it, and it is easy to move around and share. If you ever get bored with Barrel, all you'd have to do to get rid of it, would be as simple as moving the bundles away to the location where you want them.
5. Barrel can handle everything by context menus, as you show in your mockup. Take a look at this screenshot:

So now, moving on to your remarks:

1. While I like the idea of deconstructing the wrapper quite a lot, and it's something I thought of myself, too, it unfortunately adds too much overhead, and makes the app less snappy. It does have the potential to save you a lot of space, by only keeping one copy of the engine, but it would require that the .app bundle would be reconstructed before running the bundle. This means that it would need to fetch the engine, and deflate it, initialise the wine prefix, then run the game, keep monitoring it and remove the files again when the game quits. However, we can still offer the functionality that you describe, without having to deconstruct the wrapper. We only need to detect what kind of wrapper it is, and offer the relevant options in the context menus. I've thought about support for GOG games too, either as a wrapper, or by auto-creating the wrapper from its .exe installer for windows. It's quite easy to do, and most games run perfectly in wine, because they're old enough.
2. I gave it the name "Barrel" because wine is, well, wine, then you have glasses of wine (bundles) and all these "glasses of wine" are created by pouring "wine" from a "Barrel" :) Moreover, you can pour "Wine" in a "Wineskin", the "Barrel" could hold "Cider", too! It's just a matter of perspective I think!

Finally, thank you for your comments and suggestions. I'm not 100% negative on the idea of deconstructed wrappers, I was thinking that we could maybe include it as an option? Would you be able to develop the code to add support for that? If you're willing to do it, I'll give you full write access to the repository.

cheers, Thanos

P.S.: If I left out any of your suggestions / remarks, please let me know!

[HiPhish]

I think the bottleneck is that you are treating games as individual apps. Take a look at Boxer, there is only one app that does the emulation and all the gameboxes do is provide the emulator with what to emulate. Crossover does it the same way, the Windows application is stored in its own folder in the user's library as a "bottle" and the "emulation" is done via the cetral Crossover app.

I don't know if such an approach would be technically possible, but creating an app for every game looks like overkill to me. My idea was to rip out everything from the wrappers until you are only left with the absolute basic game files and engine and only one app, Barrel. Barel would then, when you launch a game, connect the engine and the game files and make Wine run. it would not be just a manager, it would be what's is running the game.

I'm afraid I'm not much of a programer, I know my way around Unity very well (built my own commercial framework for it), but I've never worked on a standalone application nor have I worked with Objective C before.

[ThanosSiopoudis]

What's running the game is basically Wine. Sure, you can invoke wine directly and keep your files separately, but what you need in order to do that is a wine prefix. The wine prefix is where the "drive_c" folder and the "windows" folder reside, along with your registry files. So if Barrel were to manage those separately from the bundle (the .app) you would need:

1. A base engine(s): this is fine, since you can bundle those separately.
2. Every game should have its own prefix, bound to a specific engine (the game bundle?). This is where you store the game, the windows folder with the overridden dll's and the user directories (usually for saves)
3. The registry settings, in .reg files (again inside the bundle?)

So on run, Barrel launches wine from the bundle associated with the game, after mapping the folders first from inside the bundle. It is possible, but as I said I'd like to include it as an option, as this method makes it harder to share games amongst people. And requires that user B has the engine that user A had installed in his Barrel. And that gets even more complicated when you take custom engines into account.

Finally, Boxer uses a custom version of DosBox, which redirects its output to Boxer. This could be done with Barrel, too, by modifying the winemac driver, but it would be VERY complicated, and would need tracking the changes of wine itself, which is a massive project compared to DosBox. So, unfortunately, we will have to stick with bundles.

[HiPhish]

About sharing, that was why I wanted the option to export as a Wineskin wrapper. My idea was that when you get a game (Wineskin wrapped) Barrel would take the wine prefix, engine and registry and store them somewhere, as you described above, and throw the rest away. When you want to share your games with someone you would click "export game" and then Barrel would take the engine, wine prefix and registry and bundle it up as a regular standalone Wineskin app again. The receiver could either play it that way or import into his own Barrel library.

Basically, my idea of barrel was a sort of manager: you double-click the game, then barrel looks up the setting and goes "let's see, I need this prefix, this engine and those registry settings. OK, Wine version from here, take the files from there and get running!".

[ThanosSiopoudis]

Yep, that sounds possible, too. I guess this functionality could go in if the deconstructed option is selected by the user

[ThanosSiopoudis]

Ok, so here is a task list in order to implement the deconstructed wrapper functionality

• [ ] Add an option in the preferences pane
• [ ] On import, detect if we have a known type of wrapper, of if it's a new import
• [ ] If it's a new import, offer to create a new Barrel wrapper
• [ ] If it's a Wineskin, or other known wrapper, start deconstructing it to its components: The engine, the bundle and the Wine prefix (drive_c, reg files and the user folders if they're included)
• [ ] Same for other types (Cider, Barrel)
• [ ] For native, just move the game and map it, add it to the library
• [ ] The bundle should only include the bundle binaries and the prefix. The engines should reside in a centralised place, like Barrel's library folder
• [ ] Offer a feature to export (reconstruct) the wrapper

[ThanosSiopoudis]

So, @HiPhish I've decided to go with a hybrid solution here. The Barrel - created wrappers will be uploaded to the server as "recipes" rather than the whole thing. When a user installs a game, and a recipe is found on the server, the recipe is downloaded (as in - a deconstructed list of things) and the wrapper is recreated locally. This should make downloading almost instant, and will be able to easily support Wineskin in the future! Any thoughts / objections are welcome

[HiPhish]

Recepies sound certainly faster and, more importantly, more flexible than actual wrappers. When the 10.8.2 update broke Wine doh quickly fixed Wineskin, but all the ports over at portingteam had to be manually and individually upggraded by the porters. If all that was hosted were just recepies everythign would have been fine.

[ThanosSiopoudis]

First beta version is finally out, with barrel recipes support. Next step is deconstruction and support for wineskin. I'm also planning to offer a one click convert from Wineskin to Barrel, but I'll have to look into that a little more to make sure it is technically possible. Please give it a try @HiPhish and let me know what you think, download links are available on the main site.

[HiPhish]

I tried installign the GoG version of Fallout, worked flawlessly (of course the game itself didn't, but that's Wine's problem, not yours). However, now Fallout appears under FPS instead of RPG. I don't know how exactly your genre detection works, but I don' think it's good idea to sort games like this anyway. What about games that belong into several genres? What about say Deus Ex, is it an RPG or an FPS? I'd say RPG and I'd put it under RPG, but anther user would expect it to be under FPS. Who is to decide who of us is wrong? Or what if I want Deus Ex to be both under RPG and FPS? I believe genres should be left to the user. I don't know what else to use instead, maybe "Wine", "Cider" and "Native"?

EDIT: Where are the Wine engines stored? There should be a way to delete them as well.

[ThanosSiopoudis]

The genres are managed by you, the games are not automatically assigned a genre. It pretty much shows up where you dropped it. There is, though, something missing here, and it's the fact that once you've imported a game you can't move it between genres. Todo for next update.. The genres exist to give a basic structure to the library. If you don't like it, or don't find it useful, you can always collapse it and use the collections instead, whatever suits you.

The wine engines are not stored by default. There is an option to cache them locally, but it's not implemented in the first beta. It is going to be included in the final version, though. All files are stored around your library folder. You can find this by going to preferences, in the "Library" section. The default location is ~/Library/Application Support/Barrel