Panorama


^ We'll still need to write the configuration plugins that allow changing those things (like cpu freq), currently the work is in creating the framework for those plugins to run in. It should be quick to do plugins once the framework is in place though. I'll package up a PND once we get to 0.2 of course.

I've been working on a plugin for Cloudef's libmilky PND repo client backend to allow integrating PND package management into UIs. Still very much WIP, but is progressing nicely. Branch here.

EDIT: The 0.1.1 PND is in milkshake's repo if that's what you meant.
 
Yes it is. I'll try to put a bugfix release out in the coming days, unless dflemstr has something he'd like to add to it.
 
B-ZaR said:
Yes it is. I'll try to put a bugfix release out in the coming days, unless dflemstr has something he'd like to add to it.

You know, this could quite easily become the "simple, better-than-iPhone" solution that craig is looking for. It's a shame he'll never agree to use it, as it's not been written by him :(

D.
 
Last edited by a moderator:
I think it'd be best if he did use community developed solutions. Right now, with him doing his own thing, I think that he's hiding behind "end users" and "user friendliness" to cover the fact that he's wanting to start building his own walled garden for Pandora applications. I think that he's also hiding the fact that he doesn't want to read the repo spec and pnd documentation. Just wait and see, next there will be constraints for software uploaded to apps.openpandora. Back on track though, Panorama works very well and I hope it becomes a widely used frontend for most users.
 
again, that's the beauty of Linux... if he creates his own walled garden, let him... not only can we create a new repo ANYWHERE, we already have more than a few alternative OSs out there to choose from. And he has no control over the gp32x forums whatsoever (let alone any other forums/communication tools that can easily be recreated elsewhere) so the software community could live a beautiful life outside his walled garden. It's fine if he (leading OPT in the efforts)sets up a Pandora-specific version of everything out there there are only a couple of small things that could be done to cause drama in the Pandora community specifically or the FOSS community as a whole (which if they cross that line, there will be legal reprecussions to deal with... but we're not there yet, so let's not go there) but I won't go into details, as they are not necessary. In the end, I say let him be... as long as he doesn't actually take up actions that would be destructive to the community at large (hardware or software) we shouldn't be all that worried. Hell, even if he DOES do something destructive to the community at large, we can always regroup without him in MANY ways. They have proven that this could be done (many of us have actual units in our hands) so it's not like a new group couldn't branch off and do their own thing (ultimately becoming competition, but there are good and bad things that go along with that... mostly good :p) because the hardware is becoming cheaper and cheaper to obtain, tweak, and make the newest cool device... so in the end, no worries. Let Craig be Craig and we can all move forward with our lives. :D
 
Taking icon smoothing off in Tabbed makes it run a LOT smoother. And I mean A LOT. I'll take out the smoothing for good in the next release. If someone wants to try it, open "interfaces/Tabbed/ui.qml" in your appdata directory with mousepad or your preferred editor, use find to get to the line with "id: iconField" and change the "smooth: true" line a bit below it to "smooth: false". Then try scrolling around your "All"-tab again (kinetic and d-pad).
 
On that note, CPU, I have a suggestion here to help further de-Craigify our community. :)

From the glimpses I understand, might Panorama be working on something similar? Or is it something that could be incorporated into Panorama? I know you guys said something about managing PNDs, but I probably misunderstood.
 
Last edited by a moderator:
The PND format isn't fit for this kind of exchange. It's too difficult to compare two PNDs and say "this one is newer, and should replace that one."

The platform needs a new solution started from scratch before it's possible to extend it to do fun stuff. Two years ago, I experimented with a replacement solution for PND (Called "envelope" fwiw). I told myself that it should be kept as simple as possible, and therefore I wrote a whole package manager, session manager and so on in BASH only. Because it built on simple concepts, it was simple to add new features (For example: one command to install the package permanently "to NAND", one to merge two packages into one, etc...)

Do that, and THEN start talking about nifty features.
 
dflemstr said:
The PND format isn't fit for this kind of exchange. It's too difficult to compare two PNDs and say "this one is newer, and should replace that one."
But that's precisely what PNDstore already does. Not perfectly; sometimes you get things like this, mostly with old pre-repo files.
milkshake said:
the reason this happens id because the PNDs have different unique pkg/app ID's so they are treat as different items.
Tempel said:
Ideally, it would be nice if developers used a consistent package ID schemes. Fortunately, using milkshake's repo will help steer them towards that. So this problem should gradually fix itself. Attempting to heuristically spot duplicates would be messy, though not totally infeasible.

In every case like that that I've seen, the title itself was exactly the same. So it should be possible to create a feature that will just scan for entries with the same title, and ask the user if he wants to update the "suspected duplicate" or not.

If this is the biggest problem, I don't think something as radical as replacing the PND format is a proportionate solution.
 
Last edited by a moderator:
Esn said:
But that's precisely what PNDstore already does. Not perfectly; sometimes you get things like this, mostly with old pre-repo files.
The problem is that this is non-trivial to begin with. Why do you need a whole tool to figure out how two packages are ordered? Because you make it easy for developers to mess up (By letting them fill in 4 fields that contain the same information), they mess up, and in practice, it leads to these problems.
 
Last edited by a moderator:
Well, for me as an normal End-User, I find the PND format very good and easy to use. It's a god foundation to work with. The people who made it had a reason to make it like it is and I guess now it is so or so to late to change it. ^^ Things like PND Store and the Repo Archive are a good way to make PND even better. :)
Like I mentioned before, there are much much more important things to fix onto the Pandora Software base than discussing an already existing file format. I hope our skilled devs focus their power on stuff like new Kernel, better Drivers and so on. After this, it is enough time for playing around with PND-releated stuff. ;)
 
Couldn't PNDstore read the PXML file for package name and version number? I'm under the impression that pacman from Arch Linux essentially does something along those lines so that it knows update this package vs that... it even extends to the AUR repo (where packages are NOT pre-compiled vs the standard, pre-compiled/approved repo)... making the function case insensitive would make life grand as well (so as not to have multiple entries because the dev got lazy and forgot to hit the shift key once or twice when typing the name of the PND in the PXML file. Seems like a more elegant solution to me in the fact that it would eliminate the double entries and such. But that's just my thinking... :) and this would require no change of process for the devs...
 
Custom Processing Unlimite said:
making the function case insensitive would make life grand as well (so as not to have multiple entries because the dev got lazy and forgot to hit the shift key once or twice when typing the name of the PND in the PXML file. Seems like a more elegant solution to me in the fact that it would eliminate the double entries and such. But that's just my thinking... :)
In my experience, that is never the problem; the title (down to the capitalization) is always exactly the same. As milkshake and Tempel say in the quotes in my previous post, it's to do with pkg/app IDs. So doing a search for potential "duplicates" with the same title would likely resolve every issue of this that I've seen. But anyway, this might be better discussed in the PNDstore thread, unless it's applicable to Panorama of course.
 
Last edited by a moderator:
dflemstr said:
The problem is that this is non-trivial to begin with. Why do you need a whole tool to figure out how two packages are ordered? Because you make it easy for developers to mess up (By letting them fill in 4 fields that contain the same information), they mess up, and in practice, it leads to these problems.
I'm not sure what makes you conclude that. When it comes to package ordering, you need only two pieces of information: the package ID, which indicates if two packages are in the same series, and the package version number. After that, ordering just needs to be done by version number, like in any package manager. If your issue is with application IDs and version numbers, I agree they're somewhat redundant, but they're not at all relevant to a package manager.
 
Last edited by a moderator:
Improved Tabbed today. Took out the icon smoothing and made it scale (mostly) nicely. Also added settings for minimum number of columns, maximum icon size and icon spacing.
 
I pointed Craig to this a couple times.. but we know he wouldn't go near this.

QML is totally out of control .. I was really worried for QT for awhile, but seems Nokia is behind QT5 (no idea why .. just to spite their bedbuddy Microsoft?) but I'm glad they are!

jeff
 
Back
Top