Release PND management suite


Released version 1.1.3.0. Now with threaded syncing and bugfixes. There's still a short pause after syncing while the PND list is being populated, but it's a lot better than before.

I didn't followed all the posts, but is it normal that sometimes the touch is unresponsive ? I mean, the "kinetic" sliding works ok, and always, but when I select an item from the list I have to click it many times
In installed view you need to tap an item twice to open it, since the first tap selects an item. Do you have these issues in other views as well? Do they occur if you use the stylus (it may interpret your finger tap as a scroll)?

With the pen:


- perfectly perpendicular to the screen and with a very firm hand, it works always, in every menu


- used in a normal "drawing" position it works most of the time, but not always


With the finger:


- in every menu sometime I have to click 4/5 times an item to select it, in the installed view I was able to select every single elements from top to bottom (of the screen) different times, but suddenly I wasn't able to select anything for 3/4 second of trials


- even double clicking on an already selected item in the installed view very oftem don't work

This could be to do with which OS version you are using as touch screen responsiveness was improved with hf7b2 I think.
 
This is one of those PNDs you read about and think "who needs this?", then you try it and think "how could I live without it??". At least that's how it was for me. I think it should replace the PNDstore, soon! It could start up a bit faster (or show something to say it does load) for my taste, and sometimes it feels a bit slow in general (did not test todays version yet, but at least the previous one seemed to freeze a bit after choosing to install something. I guess it did not, so probably again some more immediate sign on-screen, ensuring the user "I know you clicked, I'm on it", is all it takes to make it feel more responsive).


On the Pandora it beats checking the repo in a browser in my opinion, and I have never been a fan of such programs.


Does it just browse the repo, or also the old appstore (like PNDstore) by the way?
 
I'm playing with the idea of asking you to design a complete package management UI which I would then implement after PNDManager is somewhat mature. Making new UIs based on the same package management plugin is quite fast, it's the low level feature implementation that takes time. It would probably be faster to realize your vision this way than start hacking on PNDManager. For the current UI I'd probably enjoy our current arrangement more.
That wouldn't make sense. If would be orders of magnitudes more efficient if I just implemented it myself -- except that what I had in mind with beauty-get would have been a great thing several years ago. Now that there already are a repository specification along with several PND managers in the Pandora universe, they have resulted in unique problems that Yet Another PND Management Interface won't be able to solve very easily.


I do think that better PND management interfaces are a very good thing and very important to the whole Pandora universe (and I do still think that something like bauty-get would be a very useful thing to have), but I also think that they are unlikely to be the next fundamental thing that will elevate the open handhelds universe to the next level. To reiterate: I'm not interested in things which are only high-end in the context of the Pandora universe (or open handhelds universe, for that matter). beauty-get itself is a by-product of an idea from before there were "Appstores".
 
Does it just browse the repo, or also the old appstore (like PNDstore) by the way?
PNDstore doesn't browse the old appstore. Craig never implemented the repo specification on the appstore, so it's not browsable from any client (unless you use this old hack of mine, which I don't recommend). Anything that PNDstore can access should also be accessible with PNDManager
 
Last edited by a moderator:
That wouldn't make sense. If would be orders of magnitudes more efficient if I just implemented it myself -- except that what I had in mind with beauty-get would have been a great thing several years ago. Now that there already are a repository specification along with several PND managers in the Pandora universe, they have resulted in unique problems that Yet Another PND Management Interface won't be able to solve very easily.


I do think that better PND management interfaces are a very good thing and very important to the whole Pandora universe (and I do still think that something like bauty-get would be a very useful thing to have), but I also think that they are unlikely to be the next fundamental thing that will elevate the open handhelds universe to the next level. To reiterate: I'm not interested in things which are only high-end in the context of the Pandora universe (or open handhelds universe, for that matter). beauty-get itself is a by-product of an idea from before there were "Appstores".
OK, never hurts to ask :)
 
Last edited by a moderator:
Does it just browse the repo, or also the old appstore (like PNDstore) by the way?
PNDstore doesn't browse the old appstore. Craig never implemented the repo specification on the appstore, so it's not browsable from any client (unless you use this old hack of mine, which I don't recommend). Anything that PNDstore can access should also be accessible with PNDManager
Yeah, it is really time to bring all the missing apps in the Repo, freom the App Store and also from ED's Archive. :) There are MANY Pandora programs that are not in the Repo.
 
if the people who made those apps are around then ask them to put them in the repo, it is their choice after all.
 
I hope they will do it by themselves, IF they are still around here. Everybody knows the Repo Site so actualy this shouldn't be a problem. :)
 
Cool.


I tried to run it under Slack , but i get this error :/ :



Code:
[ START ]--- Starting the application (scripts/panorama.sh ) ----------

./panorama: symbol lookup error: /usr/lib/libQtSql.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEv
 
Ah ok, i thought it was something inside the pnd.


Seems i can't do much about it :/.


Are the sources of PNDManager available ?
 
Cool.


I tried to run it under Slack , but i get this error :/ :



Code:
[ START ]--- Starting the application (scripts/panorama.sh ) ----------

./panorama: symbol lookup error: /usr/lib/libQtSql.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEv

My first question is why does it even try to open libQtSql, since I don't use it? I dropped any unused .so's from the PND to reduce its size. Now it's trying to supplement the provided libs with system ones which apparently are different version (my build is latest from 4.8 branch). Confusing.


Sources for PNDManager are in consolidation-ui branch of my panorama fork, but you should be able to make it work with the entire Qt build.
 
Last edited by a moderator:
Well, it doesn't show up in plain SuperZaxxon. It has more to do with the running environment than PNDManager itself. It's weird since if the libraries were actually different version it should give error on wrong library version. Does your slackware have Qt 4.8? It could be the linking fails because of being from different builds. In that case it would probably work if you either stripped the PND from the partial Qt build (which is required for SuperZaxxon) or added the rest of the Qt build in there (so it wouldn't touch the system one). Either way if I correct this in the repo PND it either gets quite a bit larger (having the entire Qt build in it) or becomes incompatible with the default OS until Yars (by not having the a partial Qt build).
 
It's 4.7 for 13.37 and my current -current.


The next -current will be 4.8


I talked to Exophase about a mixed .pnd system, which can embed versions for different OS. May be very cool for system programs like yours. Also, the pnd will not be a lot bigger because i embed all libs.


Of course this is a bit more work, but gives more openness.


Detecting Slackware is pretty easy:


$ cat /etc/slackware-version


Slackware 13.37.0
 
PNDManager uses a few 4.8 specific tweaks in the QtDeclarative module, so for that version the PND embedded libs are needed. I'm still confused why it even tries using the system libs, since the startup script should point it to all the Qt libs it needs. For some reason I can't think of right now it tries to use libQtSql, which it doesn't do on SuperZaxxon.


EDIT: Also it should give a different error if a wrong version lib is tried to be used. It probably isn't even trying to use the libs in the PND.
 
Last edited by a moderator:
Back
Top