apps vs packages focus of the repo

[sebt3]

Hi there,

Up to now, my focus on the repository was to highlight what one can do with a pyra. So I put the focus on the apps instead of the packages.
Most of the time, the package only contain one app. In this case, either way is the same since one is the other one.
But there's 2 cases where that distinction have an impact :

1. Package with no apps (think engines, like the mono.pnd)
2. Package with several apps (think bundles, or games with an editor)

If the focus is put on the apps (aka the menu entries you'll get on your pyra, like it is now), then engines wont be displayed in the main list but will only been seen depedencies for the apps that required it. Bundles, on the other hand, will as many times in the list as they have apps.
If the focus is on packages, each of these case will always have a single entry in the main list.

An other side to consider, with the current focus on apps, "likes", "comments" and "screenshots" belong to the apps. the only things that belong to package is the download count.
If I migrate the repo to a focus on packages, should the "likes", "comments" and "screenshots" be attached to the package instead of the apps ?
This mean you would be able to "like" an engine directly (I was thinking to count all the likes for the apps depending on the engine as like count for the engine), but wont be able to like a single app in a bundle.
This also mean you'll be able to comment the package but not a specific app in that bundle.
Imho, screenshot have to belong to the apps and not the package since each shots present the apps. But if screenshot are presented at package level, how the f**k should I allow to select for the apps connected to the shots.

Your though on theses question bellow please

 

[Pickle]

i think the app should get the user inputs (votes), but couldnt there be a view in the repo that shows 'depends on' or 'provides' package?

So if i look at an app and then i expand a hidden section that shows a 'depends on' list then i can navigate to the engine package.
In the reverse from the package (engine) section I can expand a hidden 'provides' view, which shows all the apps that use this package. This view could also show the rating, that way the user can associate the the rating with the base package.

 

[sebt3]

So if i look at an app and then i expand a hidden section that shows a 'depends on' list then i can navigate to the engine package.
In the reverse from the package (engine) section I can expand a hidden 'provides' view, which shows all the apps that use this package. This view could also show the rating, that way the user can associate the the rating with the base package.

That was my plan and the reason why I splitted ketm in several packages so I could experient with that and make something cool out of this.

 

[Linux-SWAT]

I think single package with multi apps should be voted for as one.

 

[Silent-Hunter]

If you do focus on apps, it should be made very clear which apps are part of the same package. And engines and other things should show up as a single app, even if they don't contain any.

 

[levi]

Yes, I think on balance I agree that apps should be the focus to the website, unlike how it was with the pandora repo (that focused on packages). We'll have to revisit this question again when it comes to a dbpmanager app (like pndmanager was for the pandora). On linux if I'm looking for a utility that's bundled in something like unix_utils (but I don't know this when trying to install it) I have to google the utility name and hope someone also on arch has written a question about it on stackoverflow or somewhere, or guess based on how debian people do it or something.

Does your getdbp script let us see the apps for an already downloaded package? That's the only problem I sometimes have with the Pandora way of doing things - esp with things like Hooka's ginge packs, I downloaded two of them to start with, and I don't know which in the menu came from which package.

 

[sebt3]

Does your getdbp script let us see the apps for an already downloaded package? That's the only problem I sometimes have with the Pandora way of doing things - esp with things like Hooka's ginge packs, I downloaded two of them to start with, and I don't know which in the menu came from which package.

My script doesnt provide such features... yet
But my script is all temporary. a dbp-get command should replace it at some point. That command will interact with dbpd which clearly knows what app belong to what dbp. And the repo can already reply that question (even if cant show you since there's no bundle dbp yet, but I have some in my testing environement)
Beside, I dont expect as much bundles on the pyra as there is on the pandora. The dbp system make dependencies a breath. You have no ide what kind of machinery ptitSeb had to build for java.pnd, mono.pnd and a like. The ketm packages didnt needed anything fancy all was provided by dbpd
Hooka included ginge in all his bundles, but if there's a ginge engine dbp, each gp2x game just have to depend on ginge without including it. so there's no need for bundles anymore

 

[levi]

Yeah, he did bundle ginge with his packs, but the packs still contained multiple apps that were visible in the menu. And if someone comes up with a pinge (or whatever it's called) to do the same thing but targetting pandora pnds then someone could do that. Maybe ptitseb's games that come with an editor (another common use for this I can remember) could be handled via dependencies - the editor depends on the game, but you can get the game sans editor if you like (apologies for the frenglish). But stuff analogous to hooka's packs would still end up as bundles.

I guess he could go to the effort of uploading each pnd as a separate dbp and then linking to sets of those to make up his packs, but that sounds like more fuss to me, and I wouldn't blame anyone if they didn't do that. Like on Linux, small things tend to get lumped together.

 

[sebt3]

I'm a bit disapointed by the number of casted votes (11) regarding the number of thread reads (nearly 300). Dont be shy, state your opinion !

A little back-story : I made that thread because some IRC member told me that the "apps" focus would confuse many :
- all the previous solutions we used (the file-archive, the pandora repo) were package oriented
- we are all geeks and geeks tend to like collecting stuff, so the package view is more connected to the way we are.
- expecting that the user understand the distinction between apps and package was too much, as all the appstore and playstore are package oriented too...

But since I disagree, and was doing my way, I want to know how you feel the most confortable. Either way is fine, changing is some work for sure, but not that hard work since most of the UI would be reused anyway

BTW, as I posted on the other thread, the dependencies are now live on the repo. You'll be able to test

 

[Eight Bit]

Is this like libre office which has different apps in one package? Then yes, I like to be able to start each individualy and not see just a libre office icon and choose after which app I want to use but it would only have to show up as libre office on the repo.

 

[levi]

At the moment, it's more about how it should be presented in the repo - should there be a 'libreoffice' package, that will likely give you menu shortcuts for librewriter and librecalc and so on in your menu, or should you like to see separate entries for each app target on the website. On top of that thanks to the magic of dependencies you can have the option just to download the desktop entry for that app, and thanks to dependencies it'll probably end up pulling down the majority of the libreoffice backend in order to be able to work. But the question in the poll at the top if just how you'd like it presented on the website. If the libreoffice package ends up bundling all of the desktop shortcuts and doesn't use the dependency structure, then when you hit the download link on say, libreoffice writer you'll get the whole damn libreoffice-everything package. If the libreoffice maintainer did make full use of dependencies and break everything out so one package has one app target, then it'll be exactly the same regardless of if the repo has an app focus or a package focus, do it's only actually a question if people don't break things down that fine and you end up with packages which contain multiple apps, as they were always designed to accomodate. Personally, I think Hooka's ginge bundles are about the only example of where it definitely makes sense to bundle things together, so if that situation occurs again then it will make a difference.

 

[benoitb]

I'm a bit disapointed by the number of casted votes (11) regarding the number of thread reads (nearly 300). Dont be shy, state your opinion !

I didn't state my opinion because I honnestly have no idea about which is the better solution. When not decided, I tend to trust those who are.

 

[levi]

Also, I've probably checked on this thread around a dozen times as I've checked on new posts, but I could only vote once. That alone doesn't explain the difference in numbers though, of course.

 

[Caine]

I think you are ignoring the complexity of your domain by posing this as an either/or question.

Your initial analysis of the challenges is accurate, but neither of your posted solutions solve that problem.
It is a choice to ignore one or the other thus attempting to simplify the original problem.

I have not chosen because I think both options are inadequate. I had not posted yet because I do not have a solution.
If you force a choice out of me right now, then I will opt for packages because that is currently an indivisible unit.

 

[sebt3]

I didnt though my question is that complex. I'm not looking forward complete analysis of the question. I'm asking everyone' opinion. (as in : I'm not talking to your mind, I'm talking to your guts)
The "feel safe" choice is clearly package as it's what we're used to.

But it feel wrong to me. I dont want to move files around, I want to play my pyra. I will use dbp-get (or any gui built on top) I wont download from the repo, then copy to a card, making sure I've not forgot a dependency or anything.
And since the space for dbps is cheap, all I care about is what I can do not the technical details. Hence my will to change the paradigm.

I dont want to force anything on anyone. Actually hence the question I'm asking here. If giving you the choice is forcing then I dont know what to do

Actually, the package list is still available (https://pyra-handheld.com/repo/packages) and it's not even hidden as it's available in the breadcrumb for every package pages.
The distinction is :
- changing the "apps" link on top to a "dbps" link,
- changing the search results to be displayed as dbps (aka changing a sql query a bit and changing render template to the (existing) package list template)
- changing contributor app list to a contributor dbps list (I mean this page https://pyra-handheld.com/repo/contributors/sebt3)
- moving likes to package instead of apps (tables & codes pretty much already exist for that)
and some odd changes (at least to me) :
- make the screenshots available on the package page (odd because then the app page and package page would too much a-like)
- move the technical details the package page currently display somewhere else so it's not in the way

In the end of the day, the data stay more or less the same. It's a matter of presentation and what metaphor/paradigm you're the most easy with

 

[Caine]

As said, my gut feeling says packages. But my brain says to think this through.

I do not see why providing a package view avoids you from liking, commenting, etc... individual applications. You can have nested application views in a package view, can you not?

As an end user I interact with packages. I do not experience a level editor as a standalone thing from the game it is packaged with, but perhaps that is just me. If there is a malicious application in a package, then I want to reflect that on ALL applications in that package even though the other ones might be great.

Most of the time multiple applications in a single package are strongly related anyway, hence they share a package. How does a package view then detract from highlighting what the Pyra can do? Especially since most applications & packages will correspond one-to-one.

I also think that in the rare case of a bundled package which offers many applications, it would severely clutter the repository top-level view. Let us assume for argument sake that legal issues would not play a role and someone would bundle an atari emulator with all of its roms and since they are in one package you always download all of them. Would you like to see each ROM as an application or would you want to have the application "ATARI bundle" as the top-level entry-point (possibly with application sub-screens accessible from there)?

 

[sebt3]

As an end user I interact with packages.

Nope : you're interacting with the apps you use. Or do you mean you just copy files around ?

If there is a malicious application in a package

... the package *will* be pulled from the repo. The repo have the ability to hide a package, and there's will be moderators

Most of the time multiple applications in a single package are strongly related anyway, hence they share a package.

The libreOffice example is a good one. If that bundle is made, it will be a single package for all the apps as it's a pain in the harse to split it correctly in sub package.
I dont want libreOffice, I want a good word processor. There's a high change I pick libreOfficeWriter as my word processor. Sure libreofficeCalc will be installed too... But I dont care, should I ?

it would severely clutter the repository top-level view.

Which will change : it's on my todo list since a few "release" !
Beside is there a real difference clutter wise between a 700 packages list and a 800 apps list ? Nope both are unusably long. You need a better way into what's possible than these long lists. And Imho "Word processor" is a better description of what I want than "libreOffice"...

Let us assume for argument sake that legal issues would not play a role and someone would bundle an atari emulator with all of its roms and since they are in one package you always download all of them. Would you like to see each ROM as an application or would you want to have the application "ATARI bundle" as the top-level entry-point (possibly with application sub-screens accessible from there)?

That's just broken and stupid. It would probably be pulled out of the repo by some way.

 

[Caine]

Nope : you're interacting with the apps you use. Or do you mean you just copy files around ?

Yes. Installing and managing data on SD cards etc... The things I visit the repo for.

... the package *will* be pulled from the repo. The repo have the ability to hide a package, and there's will be moderators

I suppose the more general gist was that there can be properties of the aggregate package that may be relevant. Good that this example is a poor one. I am mostly thinking out loud here.

I dont want libreOffice, I want a good word processor. There's a high change I pick libreOfficeWriter as my word processor. Sure libreofficeCalc will be installed too... But I dont care, should I ?

Really? I would look for an office suite, not just the writer part of it. Even if it could be easily split, I would still install all of them, regardless if I actively use them or not. That is one thing that I always disliked about "gnome office" the fact that I needed to scavenge for individual applications instead of having an integrated suite.

Beside is there a real difference clutter wise between a 700 packages list and a 800 apps list ?

No, not really. I also do not think that in general packages will have so many applications that it would really be noticeable. Perhaps the whole discussion is mostly theoretical.

And Imho "Word processor" is a better description of what I want than "libreOffice"...

I am probably not the typical user, but I would look for libreOffice, openOffice, Office, Office Suite and Calligra Suite before looking for Word processor.

That's just broken and stupid. It would probably be pulled out of the repo by some way.

No argument here

 

[sebt3]

Yes. Installing and managing data on SD cards etc... The things I visit the repo for.

Then, maybe, I'm the one that is not the typical user.
I browse the repo to know what's available. Then I take my pyra and just type : dbp-get.sh install <package_id> (notice that I may browse the repo *from* the pyra)
To have the package id i've been to the package page of my app, so I know if it's a bundle or not already. Yet no fuss, no cards moving around for no good reason.

I am mostly thinking out loud here.

no issue. If this discussion help others find "their side" and vote, all the better

 

[levi]

Yeah, I did overthink this into other domains on trying to find my own opinion (then posted it here) so I could perhaps apologise for that, but that's a common failure of mine I suspect.

I also don't use package view on my Pandora most of the time - most of the time I run apps from the menu, and that's 100% app view. I mainly interact with package view when using pndmanager and checking for new packages, and only rarely actually visit the repo web site these days, and all the recent uses of it I can remember have been for single app packages.

I tend to think it makes more sense to attach screenshots to apps rather than packages, and if so then apps should be the 'front end' view. You can still easily find the package for any app on the pyra repo as is, and from there find a list of packages if it makes you happy, but I won't be doing that as it looks kinda bare without images.