Adding a directory structure to ScummVM?
Moderator: ScummVM Team
- spookypeanut
- ScummVM Developer
- Posts: 159
- Joined: Tue Sep 12, 2006 9:35 am
- Location: St Albans, UK
- Contact:
Adding a directory structure to ScummVM?
I'm interested as to whether people think this would be useful: the ability to divide games up into "directories" within ScummVM. I feel that it would be useful. I have 15 games, and ridiculous numbers of demos (I like to collect them...), so I have two separate config files, one for games and one for demos. It would be nice though, to be able to jump between the two.
I've been trying to think of a mechanism by which it would work, without being too hard to implement. It could be a menu item (not one that can be created from the gui, only by entering it into a config file), which jumps you to a different config file. That way, if people wanted to have a (fake) directory like structure, they could set one up.
Does this sound like something that would be useful?
I've been trying to think of a mechanism by which it would work, without being too hard to implement. It could be a menu item (not one that can be created from the gui, only by entering it into a config file), which jumps you to a different config file. That way, if people wanted to have a (fake) directory like structure, they could set one up.
Does this sound like something that would be useful?
My view is that this extra complexity in the user interface would be a no improvement for the majority (95+%) of all users (or even a *drawback* considering it makes the interfaces more complex). On the other hand, the "improvement" it grants to the remaining few users is rather small. For this reason, I have rejected similar requests in the past. But in the end, feel free to post such a request on our feature request tracker -- but be warned, it's unlikely to be fulfilled.
I had a similar idea once, how about something like "sections" or "groups", as in this mockup:
Would that be feasible? Or also too complex? Of course there'd be the need for more config options ("configure groups", probably as a tab in the "options" menu), and an additional dropdown box ("put game into which group?") for the game config. But IMHO it's not as complex (UI-wise) than a tree- or directory- structure....
Would that be feasible? Or also too complex? Of course there'd be the need for more config options ("configure groups", probably as a tab in the "options" menu), and an additional dropdown box ("put game into which group?") for the game config. But IMHO it's not as complex (UI-wise) than a tree- or directory- structure....
As for me, it looks nice and not that complex. I myself could suffer from it, owning more than hundred just HE games, all 27 variants of ITE, etc. Just I don't use launcher to start ScummVM .Dark-Star wrote: Would that be feasible? Or also too complex?
However, separate ini file per category is wrong approach. Feasible approach would be this:
Code: Select all
[ite-demo]
gameid=ite
group=demos
# Groups are numbered in order of appearance
[groups]
group1=bass
group1desc=Beneath a Steel Sky
group1state=closed
group2=demos
group2desc=Demos and Previews
group2state=opened
Eugene
The main complexity as I see it lies in the code / UI design needed to *manage* those groups. I.e. we either end up with a system where it's difficult to add things to groups, resp. move it; or we end up spending a lot of time implementing drag&drop between groups, etc.
We'd also have to implement a (simple) tree view, and various other things.
It certainly *is* possible, but personally I'd really prefer if we put all that man power required for this to fix some of the more essential problems we have, like bugs, the lack of a user manual, existing UI flaws, etc.
But of course, if somebody is willing to spend days and weeks on this, we can discuss it. But I have some strong views on how this should *not* be done, interface wise, so that person would have to cope with those...
We'd also have to implement a (simple) tree view, and various other things.
It certainly *is* possible, but personally I'd really prefer if we put all that man power required for this to fix some of the more essential problems we have, like bugs, the lack of a user manual, existing UI flaws, etc.
But of course, if somebody is willing to spend days and weeks on this, we can discuss it. But I have some strong views on how this should *not* be done, interface wise, so that person would have to cope with those...
About the last two: the "+" on the left of the bar usually means that new items will pop out BELOW it (like a tree). It doesn't make sense to click on something with a "+" next to it and have new information displayed to you on another pane. A more intuitive way to display this would be to show some kind of arrow to the right of the bar, which will point to the right, or some sort of icon to make it different from the other expanding nodes
Thanks a lot for your suggestion, a friend will help me to making the mockup less sucky and bettermd5 wrote:About the last two: the "+" on the left of the bar usually means that new items will pop out BELOW it (like a tree). It doesn't make sense to click on something with a "+" next to it and have new information displayed to you on another pane. A more intuitive way to display this would be to show some kind of arrow to the right of the bar, which will point to the right, or some sort of icon to make it different from the other expanding nodes
I'd like to throw in a vote saying that this seems like a lot of extra work for something that only makes it look messier in my opinion.
I agree with Fingolfin that 95 percent of the users out there wont benefit from this. I doubt many people care what engine runs the game, let alone want to sort by engine.
I did like the aspect of each game being listed once however, with a plus to expand multiple versions/languages/os's etc for each game. That at least cleans the list up a bit. So far i have avoided adding other versions of each game to my ini file simply to avoid this double listing.
I agree with Fingolfin that 95 percent of the users out there wont benefit from this. I doubt many people care what engine runs the game, let alone want to sort by engine.
I did like the aspect of each game being listed once however, with a plus to expand multiple versions/languages/os's etc for each game. That at least cleans the list up a bit. So far i have avoided adding other versions of each game to my ini file simply to avoid this double listing.
To repeat and emphasize what exofreeze said:
"I doubt many people care what engine runs the game, let alone want to sort by engine."
That's it! I believe that only geeks (=crazy collections) want to do that -- think about it, when you want to play a game, do you go about it like this: "Hm, should I play a SCUMM or an AGOS game now..."? I strongly doubt that many people do that, if any at all. I certainly don't. So, IMO, sorting by engine makes no sense when you think about it for a bit.
The only kind of grouping suggested here so far that in my eyes has at least some merit is the idea of grouping variants of a game (if you have multiple versions of Monkey Island, for instance).
But even that only affects a relatively small percentage of users -- mostly collectors, some nerds and ScummVM devs will have many different versions of a single game.
To sum it up, what I have seen here so far seems to me like a bad solution for a problem the majority of our users does not even have... . But of course, that's just my two cents, I might be wrong.
"I doubt many people care what engine runs the game, let alone want to sort by engine."
That's it! I believe that only geeks (=crazy collections) want to do that -- think about it, when you want to play a game, do you go about it like this: "Hm, should I play a SCUMM or an AGOS game now..."? I strongly doubt that many people do that, if any at all. I certainly don't. So, IMO, sorting by engine makes no sense when you think about it for a bit.
The only kind of grouping suggested here so far that in my eyes has at least some merit is the idea of grouping variants of a game (if you have multiple versions of Monkey Island, for instance).
But even that only affects a relatively small percentage of users -- mostly collectors, some nerds and ScummVM devs will have many different versions of a single game.
To sum it up, what I have seen here so far seems to me like a bad solution for a problem the majority of our users does not even have... . But of course, that's just my two cents, I might be wrong.
Maybe the latest mockup is nice, but changing engines by companies. Optionally, it can be given some flexibility to users making it's own custom themes with all the nerdy & geeky stuff on it
Geeks and nerds seems to be important in the ScummVM user percecentage (at least they seems to collabore more sending bugs), I think. Are developers into the geek/nerd category?
Please don't ignore the geeks/nerds! I myself think sometimes about what engine uses the game to run before the name, must I be afraid?
Here is another try to expressing a concept for GUI:
Geeks and nerds seems to be important in the ScummVM user percecentage (at least they seems to collabore more sending bugs), I think. Are developers into the geek/nerd category?
Please don't ignore the geeks/nerds! I myself think sometimes about what engine uses the game to run before the name, must I be afraid?
Here is another try to expressing a concept for GUI: