Installation System / Game Marketplace?

[Monk]

Would that be "help" as in the rest of us bickering about how it ought to work and look and what you ought to change, or actual REAL help doing some of the work?

IMHO it'd still be great to get some actual feedback from OP - and/or ED. Without back-end participation I feel only half a job could be done (for example maybe updates would not be possible/practical, or we would end up with two or more "file archives", with the "better" one not run by an OP member).

 

[Vorporeal]

Actual "real" help haha. You guys would be good help too - the more people are involved on something of this nature, the better the result. When design is a big factor, it's best to have a group of people going over designs, throwing some out, revising others, etc. Too many's not great, neither is too few, but there's a sweet spot in the middle.

 

[dflemstr]

Actual "real" help haha. You guys would be good help too - the more people are involved on something of this nature, the better the result. When design is a big factor, it's best to have a group of people going over designs, throwing some out, revising others, etc. Too many's not great, neither is too few, but there's a sweet spot in the middle.

I can program Qt4 (I'm no expert however), C(++) in general of course, and interact with my own repository API/structure, so I could help with this, but I won't be leading anything; it'd be too time consuming for me.

Also, I could provide some mockups for interfaces but dunno how valuable those will be since anyone can create mockups.

It would be really neat if this could be integrated with some of the menu systems for the Pandora. For example, you could add a check box to Cpasjuste's launcher that reveals installable apps. The installable apps would be shown among the already installed apps, but clicking one that isn't installed would seamlessly download the app before launching it. Etc. There should of course be a primary interface too à la the AppStore that some of you have mentioned, but the menu interface would be a neat addition.

The most practical solution would be to create a library that downloads PNDs and checks for upgrades etc; then you can create GUIs and CLI-apps for it without code duplication.

Oh well, step 1 for all of this to happen is to create a server-side system, so I need to start working on the PND Manager again some time soon.

 

[Vorporeal]

I wouldn't be able to put in massive amounts of time either - I'm still a college student, and I'm taking some seriously hard classes this semester. If we could find another person or two to put in some time though, we'd definitely be able to produce something. We could probably get together a team of 4 people each putting in 1/4 the work required if one person did it alone.

Also, the seamless idea sounds interesting. It would require some work to keep it all from getting too cluttered - maybe it could use a suggestive algorithm to show some apps that aren't installed, but might be of interest based on the apps you do have installed. It's definitely not high on the priority list though.

 

[GizmoTheGreen]

I wouldn't be able to put in massive amounts of time either - I'm still a college student, and I'm taking some seriously hard classes this semester. If we could find another person or two to put in some time though, we'd definitely be able to produce something. We could probably get together a team of 4 people each putting in 1/4 the work required if one person did it alone.

Also, the seamless idea sounds interesting. It would require some work to keep it all from getting too cluttered - maybe it could use a suggestive algorithm to show some apps that aren't installed, but might be of interest based on the apps you do have installed. It's definitely not high on the priority list though.

I'm in if you wouldn't mind teaching me some stuff, I've done basic classes in programming with c++, but that's about it, (console apps only, and for some reason classes didn't cover object oriented stuff)

I'm a quick learner otherwise.

 

[Drack]

The real argument for a standalone app: Ability to see what's already installed.

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

It will let you uninstall apps using the same interface. A webpage can't do that (Granted, a simple delete will).

I am not versed in how PNDs do dependency management, but the killer feature of debian's (and of course *buntu's) aptitude is marking which apps and libs were installed as dependencies, and when you remove an app it checks for unused deps and uninstalls them too. No website can do that.

"Easy" and "Pretty" are not the right arguments here. Functionality is the real reason for a standalone app.

 

[Aninhumer]

There's a difference between an app to install things and an app to manage what's already installed.
I think using the website to get new PNDs, and then using a local app to update/remove them would be much simpler.

It just occured to me actually, this could be integrated directly into the main menu system.
Items which have a new version available could show an emblem, and there could be a delete option in a menu, or something.
No need for a full blown interface, and it would be much more natural to use.

 

[Vorporeal]

There's a difference between an app to install things and an app to manage what's already installed.
I think using the website to get new PNDs, and then using a local app to update/remove them would be much simpler.

It just occured to me actually, this could be integrated directly into the main menu system.
Items which have a new version available could show an emblem, and there could be a delete option in a menu, or something.
No need for a full blown interface, and it would be much more natural to use.

You could only really do the integration for a "homebrew" GUI like the ones cpasjuste and Efegea are making. If people use Ubuntu (Gnome) or KDE4 or E17 or Matchbox, it's MUCH harder to integrate that with the environment.

 

[Aninhumer]

You could only really do the integration for a "homebrew" GUI like the ones cpasjuste and Efegea are making. If people use Ubuntu (Gnome) or KDE4 or E17 or Matchbox, it's MUCH harder to integrate that with the environment.

Just off the top of my head.

You could have a script to scan for updates and add an emblem (this can be done in gnome and I'd assume KDE, dunno about other stuff) and remove it again when you update.

Deleting is harder, but you could have a script that lets you select a menu item, and deletes its target?
I'm not sure if that would work, but I'm pretty sure the emblems would, and it would be a nice touch.

 

[lulzfish]

No, the standard workflow is more like:

"Updates are available for: program1, program2. Update?"
User selects "Yes"
"Updating..."

The emblem thing is really complicated and I don't think most users want to update anything one at time, or only think about updating when they're looking at the icon. They want it to be automatic, and update as much stuff as possible, then leave.

 

[WizardStan]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.
2) It can track deleted packages. Suppose you download an incomplete game demo. You play it, and what's there is awesome, but there's just not much to it now. You delete the PND, freeing the space, and vowing to check back later. Months go by and you've forgotten, but LO! you log in and it says there's an update! "Do you want to be reminded of these updates in the future?" and you click "HECK YEAH!". You then download, play it some more, and delete it, because it's still just a demo. But still awesome. The game should be done in 2 months. Honest.
3) With a complete list of every package you've ever downloaded and updated (or not), you can do some simple logic to suggest other things. "You've downloaded three different poker games. Would you like to try this other one?" "Recommend me something" would actually be a pretty cool feature. Many a time I've sat bored in front of my computer and just wanted to play a quick and random game. Maybe this would be more suited to a separate web page where you could enter a bunch of criteria and just get a random PND file to play.

 

[greendots]

http://www.getdeb.net/ has a nice interface and its web code is licensed under gpl. It could be perfect for the pandora.

 

[Aninhumer]

No, the standard workflow is more like:

"Updates are available for: program1, program2. Update?"
User selects "Yes"
"Updating..."

The emblem thing is really complicated and I don't think most users want to update anything one at time, or only think about updating when they're looking at the icon. They want it to be automatic, and update as much stuff as possible, then leave.

Well a single click update was still my intention, just that the emblems would make people more aware of when something gets an update.

I still think a local application only needs to be an update manager anyway.
The website already offers basically what an installer interface would.

 

[dflemstr]

http://www.getdeb.net/ has a nice interface and its web code is licensed under gpl. It could be perfect for the pandora.

I used that site for inspiration for the PND Manager; go check it out if you haven't.

Also, I don't know what all this fuss is about regarding how installs/updates will happen...
Let's say there's a repository somewhere, that contains PND packages. The repository has a standardized structure so that many different tools can read from it.
Now, I've created the PND Manager, which allows you to *add and remove* things from that *repository*; it's the developer-side interface to the repository. I have also added an online browser for that repository, to allow users to download packages. That's an online user-side interface for the repository, and it's similar to getdeb. The PND Manager will also serve packages for you in an efficient way, so it takes care of logistics too.
So, basically, with the PND Manager, everything is covered when it comes to the server side of things.

Then, someone can write a library for the Pandora, that will download the list of packages that a repository contains (because there's such a list; a list of package names, versions, descriptions, etc) and perform various actions based on that list. So, you can have a local package installer for downloading packages, because you have a list of all packages available with URLs so it's not a problem. Or you can have an update tool, because you have the names and versions of all local packages (you scan folders, use libpnd to extract name info, and there you go) and the names and versions of remote packages (the downloaded list) so updates are easy to implement.

Then you write various user interfaces for that library and go wild.

So what's the problem? There's no reason to only have one interface, especially when adding a new one involves maybe 200 lines of code.

 

[Monk]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.

There are problems too.

1) Say, for some silly reason (WHY users do thing sisn't as important as the fact that they do) I restored my SD card back to how it was last month. If the web page kept track of all my updates, surely it would assume my updates were still installed, even when they were not and I ACTUALLY still need to isntall them?
2) It can track updates to SD cards that aren't inserted, true, but it can't update them because they aren't inserted... it doesn't make that aspect entirely reduindant but does, IMHO, reduce the benefit that this aspect offers.

 

[dflemstr]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.

There are problems too.

1) Say, for some silly reason (WHY users do thing sisn't as important as the fact that they do) I restored my SD card back to how it was last month. If the web page kept track of all my updates, surely it would assume my updates were still installed, even when they were not and I ACTUALLY still need to isntall them?
2) It can track updates to SD cards that aren't inserted, true, but it can't update them because they aren't inserted... it doesn't make that aspect entirely reduindant but does, IMHO, reduce the benefit that this aspect offers.

1. Wait... why would a web page keep track of what you have installed? Why can't it be done locally (see my last post)?
2. I agree with Monk here; let the update program deal with packages it finds, and not with packages that a remote web server tells it it is supposed to find. If you want to update packages on an SD card, you insert that SD card.

 

[Monk]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.

There are problems too.

1) Say, for some silly reason (WHY users do thing sisn't as important as the fact that they do) I restored my SD card back to how it was last month. If the web page kept track of all my updates, surely it would assume my updates were still installed, even when they were not and I ACTUALLY still need to isntall them?
2) It can track updates to SD cards that aren't inserted, true, but it can't update them because they aren't inserted... it doesn't make that aspect entirely reduindant but does, IMHO, reduce the benefit that this aspect offers.

1. Wait... why would a web page keep track of what you have installed? Why can't it be done locally (see my last post)?

1. The resistance to a specific local (client-side) program is strong in this one.

 

[Sphinxter]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.

There are problems too.

1) Say, for some silly reason (WHY users do thing sisn't as important as the fact that they do) I restored my SD card back to how it was last month. If the web page kept track of all my updates, surely it would assume my updates were still installed, even when they were not and I ACTUALLY still need to isntall them?
2) It can track updates to SD cards that aren't inserted, true, but it can't update them because they aren't inserted... it doesn't make that aspect entirely reduindant but does, IMHO, reduce the benefit that this aspect offers.

1. Wait... why would a web page keep track of what you have installed? Why can't it be done locally (see my last post)?

1. The resistance to a specific local (client-side) program is strong in this one.

Aye, second that.

 

[dflemstr]

Take any distro's package manager for example. It will TELL you when there are updated versions of installed apps. A webpage can't do that.

Theoretically it can. You need to have a unique way of identifying users first; some kind of login ID, password protected perhaps. Then, when you download a package, it marks in a database somewhere that that package has been downloaded. Next time you log in, it scans for updates to previously downloaded packages and informs you. You can then proceed to download the update, or remove it from your watch list and never be reminded again.
There are several benefits to this that a stand alone app can't have (unless it secretly connects to this same database in the back end)
1) It can track updates belonging to SD cards you don't have inserted. A standalone app can only check for updates for packages it knows about, and it can only check those that are immediately available, like on inserted SD cards. Unless you're writing "installed packages" to the NAND, which I think would be a bad idea, but that's just me.

There are problems too.

1) Say, for some silly reason (WHY users do thing sisn't as important as the fact that they do) I restored my SD card back to how it was last month. If the web page kept track of all my updates, surely it would assume my updates were still installed, even when they were not and I ACTUALLY still need to isntall them?
2) It can track updates to SD cards that aren't inserted, true, but it can't update them because they aren't inserted... it doesn't make that aspect entirely reduindant but does, IMHO, reduce the benefit that this aspect offers.

1. Wait... why would a web page keep track of what you have installed? Why can't it be done locally (see my last post)?

1. The resistance to a specific local (client-side) program is strong in this one.

Aye, second that.

And the reason for that is...?

 

[Sphinxter]

Because feature creep is already killing what was a great simple idea.