Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
I think maybe both would be good. Show it as packages, but then say how many apps are in each package, and allow individual likes and comments on them.
ible
professional vim user
not sure i understand either poll choice, even though i'm an exclusive linux user, which is why i didn't vote...
probably games, then programs/utilities, then library-like stuff (i suppose that's what you mean by packages). but we should be able to switch between any/all views... is that too much to ask
probably games, then programs/utilities, then library-like stuff (i suppose that's what you mean by packages). but we should be able to switch between any/all views... is that too much to ask
levi
Still fresh, damnit!
Yeah, the poll's not really about that. A DBP file (which is like a PND but for the Pyra) is a package, and each DBP package can contain multiple apps. That's the terms the poll is talking about. And see https://www.pyra-handheld.com/repo/apps
One thing I'd not grasped until I just checked, packages can have no apps, and KETM is an example of one. You can only see if it you click on the dependency out of any KETM-based game, and from there you can navigate to the list of all packages. It's the same as the apps list at present, just with one extra entry - the package with no apps that is the KETM engine. If a package gets uploaded with multiple apps in, that'll appear as multiple entries in the app list, but only one in the package view.
Your suggestions for how categories should work is a good one, and thankfully something the repo already seems to cover pretty well.
The link above should show you all of the apps that have currently been submitted as dbps for the Pyra. Click on 'categories' to get a drop down populated with all of the currently used categories. Click on Emulators and it'll only show Emulators. To get back to the list of everything, click Apps in the top bar.
But as I see the poll the pros and cons of each option are:
Apps focused:
Pros:
- Shows you everything you might want to actually run on the homepage
- Screenshots are tidier if associated with apps
Cons:
- Download button will download full package which will include the app, but also any other apps in that package.
- Engine-only packages are hidden behind three or more clicks, if you want to download those manually
Package focused:
Pros:
- Download button downloads exactly what you see (all the apps shown on the page)
- Everything you can download is two clicks away.
Cons:
- Screenshots from multiple apps can get mixed together. Bit nasty
- Shows you engines which you probably never want to explicitly download anyway - just let the dependency engine handle that for you.
That's how I see it today anyway.
One thing I'd not grasped until I just checked, packages can have no apps, and KETM is an example of one. You can only see if it you click on the dependency out of any KETM-based game, and from there you can navigate to the list of all packages. It's the same as the apps list at present, just with one extra entry - the package with no apps that is the KETM engine. If a package gets uploaded with multiple apps in, that'll appear as multiple entries in the app list, but only one in the package view.
Your suggestions for how categories should work is a good one, and thankfully something the repo already seems to cover pretty well.
The link above should show you all of the apps that have currently been submitted as dbps for the Pyra. Click on 'categories' to get a drop down populated with all of the currently used categories. Click on Emulators and it'll only show Emulators. To get back to the list of everything, click Apps in the top bar.
But as I see the poll the pros and cons of each option are:
Apps focused:
Pros:
- Shows you everything you might want to actually run on the homepage
- Screenshots are tidier if associated with apps
Cons:
- Download button will download full package which will include the app, but also any other apps in that package.
- Engine-only packages are hidden behind three or more clicks, if you want to download those manually
Package focused:
Pros:
- Download button downloads exactly what you see (all the apps shown on the page)
- Everything you can download is two clicks away.
Cons:
- Screenshots from multiple apps can get mixed together. Bit nasty
- Shows you engines which you probably never want to explicitly download anyway - just let the dependency engine handle that for you.
That's how I see it today anyway.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
That's why I think it should show packages, and then when you click a package it should then show the apps, which you can then look at individually as well.
Caine
Hardcore Member
Indeed, some sort of mixed view might be the best approach:
- a package with 0 applications: show as a package
- a package with 1 application: show as an application
- a package with 2 or more applications: show as a package, clicking into it shows view with applications
sebt3
homebrew player (P. & C.)
Wouldnt this be even more confusing than what's currently live ? At least there's some consistency in my solution
Caine
Hardcore Member
Depends on what metric of consistency you focus on. The real complexity of your problem, is that you are distributing packages with zero or more applications.
I still feel that you are attempting to simplify your solution beyond the inherent complexity of your problem.
You could basically be providing a file-system like view on everything in the repository. Start with categories and searches at the top (all, games, applications, recently updated, newly added, etc...), dive down into packages and then down into applications. Anyway, just my two cents. Currently the majority in the poll agrees with you and prefers an application view.
- Each application can have screenshots, comments, likes, etc...
- Each package can have comments, likes, and perhaps also screenshots.
I still feel that you are attempting to simplify your solution beyond the inherent complexity of your problem.
You could basically be providing a file-system like view on everything in the repository. Start with categories and searches at the top (all, games, applications, recently updated, newly added, etc...), dive down into packages and then down into applications. Anyway, just my two cents. Currently the majority in the poll agrees with you and prefers an application view.
sebt3
homebrew player (P. & C.)
I dont think so. If I was, I would do like the playstore :
- forbid package without apps (that save half of the trouble)
- Consider that packages contain only one app (no matter if there's more than one or not, so it's hidding you how many apps you'll have installed. But it solve all the screenshot/likes/comments belong to ? questions)
- Make a package view that simulate an app view since now 1 package = 1 app
Maybe the pool options should have been :
- apps view by default
- package view by default
- plz lie to me and pretend 1 package = 1 app
Well package are in no categories... apps are
So a tree of apps sorted by categories is possible (and exist) but a categories/packages/apps tree isnt possible.I'm looking at a presentation of the data contained by the repo that is accurate (aka not lying to you). But sure the data model isnt simple, so the presentation wont be simple either. Somehow part of the complexity have to be pushed on the repo users if one want the presentation to be accurate
The trend is going in your direction, though, and the "package" vision have all the required time to take over the "apps" view in this pool, until the pool end.
Either way dont worry, this discussion gave me a few ideas on how to make things bearable for everyone sharing your opinion in case the apps vision "win"
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Why not have packages with no apps show a dummy app so that they still show up in the list?
levi
Still fresh, damnit!
Hmm, looking back you suggested that on the first page but nobody picked up on it. That would mean you can see everything you can download on the apps page, but it wouldn't be a 1:1 mapping, as some apps could be from the same package (although they'd at lest be consecutive).
But provided everyone uses a mechanism that supports dependencies you should never need to explicitly download those engine packages - they'll just come when they're needed to run an app. You're not one of those weirdos that downloads stuff ahead of time on their PC and then transfers it to their device in this day and age of appstores still, are you?
But provided everyone uses a mechanism that supports dependencies you should never need to explicitly download those engine packages - they'll just come when they're needed to run an app. You're not one of those weirdos that downloads stuff ahead of time on their PC and then transfers it to their device in this day and age of appstores still, are you?
Caine
Hardcore Member
Oh right. That makes sense. It is never really easy, is it.Well package are in no categories... apps are
I really don't experience this as a my-camp vs. your-camp thing. I just think that arguing both sides leads to better understanding of all use-cases.
A sort of virtual application, that could work too.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
No, I'm not, but what if I'm making something that uses that engine myself? Then I would have to download it by itself.
levi
Still fresh, damnit!
Maybe a view (perhaps a psuedo-cateogory) could show you only packages with no apps. If you know a game that runs in the engine you want to use, it's a click further on to find the depended engine, but if you're not sure and you want to see what engines are available, maybe a view like that would have some merit?
Not sure if I understand the discussion but as far as presentation go, as an end user, I would like to see apps/games only in the main view.
Behind the scene packages that are engines, libraries, etc that I never interact with but are dependencies should still be downloadable just in case. But they could be presented in a simple searchable list of html links for example.
Behind the scene packages that are engines, libraries, etc that I never interact with but are dependencies should still be downloadable just in case. But they could be presented in a simple searchable list of html links for example.
sebt3
homebrew player (P. & C.)
which you certainly can : https://pyra-handheld.com/repo/packages/ketm_engine_sebt3
A list of engines is definatly doable. Engine with an apps (like : https://pyra-handheld.com/repo/packages/dosbox) included ?
slaeshjag
¯\_(ツ)_/¯
Adding repo-specific keys to aid in presentation of app-less packages is not out of the question, there's already plenty of keys in the package data that the dbp system ignores
levi
Still fresh, damnit!
Wouldn't that be difficult to code though? As I see it you could either identify likely pure engines by looking at packages that don't have apps, or alternatively look at things that are depended upon by something else, or as a refinement of that, that also don't have any dependencies of their own. But those last two options would also catch games which have separate editor packages, if the editor depends on the game, but the game is native so has no extra dependencies.
I was thinking along the lines of just identifying packages without any apps. They are as I see it very likely to be engines (game engines, midi engines what have you). It means we'll miss any engines that also have demo apps included, but you could argue they're not pure engines anyway.
ptitSeb
Serial Porter
On the Pandora, even "bare" engine (like zdoom, easyrpgplayer, löve runtime...) have an app entry (and so a menu entry): a simple dialog (yeah, zenity FTW ) to choose data to launch, or a more sofisticate program (in case of zdoom).
I'm more in favor of a "package" centric vue. My feeling is the dbp system, like the pnd system, is more of a cartridge choice of a console. You pick a title, and plug it. It may be a compilation (or it may download other stuff, like engine and so), but basicaly you pick a package based on it's content.
In the case of the game+editor, the simplest way is to package both in the same dbp, and create 2 separate entries. Most of the time, the editor just add a binary, all the resources are already the one of the game. Of course, there are a few specific cases of corses (like a doom level editor, or the circuit editor for cannonball) where it make more sense to have a separate package because the dependancies are widely different from the game or because it is a separate editor.
TL;DR: I prefer to have a package centric vision on the repo, as it's what I "download". The app centric vision will be handled by the launch menu of the Pyra.
) to choose data to launch, or a more sofisticate program (in case of zdoom).I'm more in favor of a "package" centric vue. My feeling is the dbp system, like the pnd system, is more of a cartridge choice of a console. You pick a title, and plug it. It may be a compilation (or it may download other stuff, like engine and so), but basicaly you pick a package based on it's content.
In the case of the game+editor, the simplest way is to package both in the same dbp, and create 2 separate entries. Most of the time, the editor just add a binary, all the resources are already the one of the game. Of course, there are a few specific cases of corses (like a doom level editor, or the circuit editor for cannonball) where it make more sense to have a separate package because the dependancies are widely different from the game or because it is a separate editor.
TL;DR: I prefer to have a package centric vision on the repo, as it's what I "download". The app centric vision will be handled by the launch menu of the Pyra.
Last edited:
levi
Still fresh, damnit!
Won't the dependency system simplfy things so there's less need to include a launcher like that? The engine will come down if you download one if it's games. If you somehow managed to download the engine without a game, the dbp runner would identify that it's got no apps and inform you. If you manually download the game without its engine, the dbp runner should tell you it's missing the engine package. Then you don't even need to go to the effort of writing a zenity script to handle these conditions. If you were going down that route, I reckon it would make more sense to hide pure engines from the main view, and one way to do that is to list apps on the front page.
If you wanted to go to the effort of writing a small zenity app that would inform the user more specifically about the types of game packages they should be looking to download, you can still do that, but it wouldn't need to ask the user what game to load, so it could be simpler. For the case of Love games and perhaps others you still want a way that end users can download games from the web and try them out. In some ways it's more like an emulator that loads a rom image when it starts up.
I don't think the number of different depended libraries is a valid reason for not splitting an editor from its game. If there's not a lot on content in the game and it's best that user's get the editor if they want to get the most out of the game is a reason, I think, but the transparency of the package dependency system should mean if it makes sense it's easy for the user to get the game without the editor, and at the very least keep their menu system tidier. It may only mean one small binary is missing from their system, if it shares all the backend libs with the game, but for most users I'd suggest items in the menu (or elsewhere) is more visible than the exact number of binaries on their system.
If you wanted to go to the effort of writing a small zenity app that would inform the user more specifically about the types of game packages they should be looking to download, you can still do that, but it wouldn't need to ask the user what game to load, so it could be simpler. For the case of Love games and perhaps others you still want a way that end users can download games from the web and try them out. In some ways it's more like an emulator that loads a rom image when it starts up.
I don't think the number of different depended libraries is a valid reason for not splitting an editor from its game. If there's not a lot on content in the game and it's best that user's get the editor if they want to get the most out of the game is a reason, I think, but the transparency of the package dependency system should mean if it makes sense it's easy for the user to get the game without the editor, and at the very least keep their menu system tidier. It may only mean one small binary is missing from their system, if it shares all the backend libs with the game, but for most users I'd suggest items in the menu (or elsewhere) is more visible than the exact number of binaries on their system.
kuru
Who the heck is Stephan Kramer?
Thinking about definitions - package is the one thing that agregates stuff.
Could the other thing be [anything that can be put in a package - be it an app or engine] which both can be rated individually??
Maybe packages could show an average of the contents ratings per default?
Edit
Or if package contents don't have individual ratings, could they inherit a rating from the package?
Could the other thing be [anything that can be put in a package - be it an app or engine] which both can be rated individually??
Maybe packages could show an average of the contents ratings per default?
Edit
Or if package contents don't have individual ratings, could they inherit a rating from the package?
