Panorama


Finally got around to checking this out and it seems to work great + I love the ability to have moving effects in the background without it slowing the system down to a crawl.

Maybe you could give Mr_Gonzo a shout and see if he can do something like this to run in the background. I can imagine this guy trying to walk left while stuff keeps flying past and then you move right to the next screen and the wind blows him all the way across to join you. Press to go back to the other screen and the wind changes direction. Awesome :D
 
Jan-Nik said:
Works fine here. But the Magma theme takes quite some time to load and takes up 439 MB RAM. Also the scrolling has vertical tearing (could be caused by my ATI driver).

But the kinetic scrolling is very nice! Good job! Overall the menu seems already pretty usable and the theme engine is awesome.
RAM usage: Qt 4.6.1 really eats up RAM when loaded for one single application. I really wish that all distributions would use Qt nightly so that I wouldn't have to include my build of it... ;)
The Pandora version won't have this issue of course, since I can do a much more optimized build on it, and since Qt 4.6 will be included per default IIRC (in which case I'll just have to include a custom version of QtDeclarative.so.4).

Vertical tearing: Are you sure it's vertical, and not horizontal? Well, anyways, it's because Qt doesn't vsync its drawing, and since you presumably don't use a compositing window manager (e.g. Compiz), the tearing becomes visible.

Kinetic scrolling: The scrolling itself was not made by me; I just use a ListView component and the original code is in a QML module called "Flickable".

Mr_Gonzo's video: I could do that, but if he makes a video I won't be able to use it. Videos are far too performance-craving to be used as backgrounds, because:
  1. If you put things in front of them, everything that is 'above' the video needs to be redrawn every frame
  2. They use up a lot of RAM
  3. You can't have random events in videos, you can just loop them
If someone would give me the background and the individual sprites (as animated .gif images or whatever) along with a demo video how it *should* look, I might be able to recreate it using animations in QML.

Other stuff: Remember that there's a file called "settings.cfg" that contains loads of options that can be modified. You can even modify it while Panorama is running (changes are applied immediately)! It's had some problems in the past, so I'd really like to get reports of any errors with the settings system. Anyways, thanks for the input, these comments you (and others) have been giving have been really helpful when developing; I'm a technical guy and don't know what you guys (who probably are more aesthetic people) want (and before you mention it: yes, I'm still considering adding a media player)

BTW: I urge everyone who's able to create themes for Panorama (now that there are builds available); I am really interested in hearing about how accessible the theming system is, and my own artistic skills are limited!
 
Last edited by a moderator:
Wow, works great! The qml files look so simple. How much of the API used to execute them is in Qt 4.6 and how much is yours? Wouldn't mind having something like this on my n900 either ;). I'll have to try and mess around with this some more when I finally get this damn thesis ready :D
 
B-ZaR said:
Wow, works great! The qml files look so simple. How much of the API used to execute them is in Qt 4.6 and how much is yours? Wouldn't mind having something like this on my n900 either ;) . I'll have to try and mess around with this some more when I finally get this damn thesis ready :D
Most of the visual stuff and the state machinery is Qt 4.6 (It's basically a 1:1 mapping to QGraphicsView and QPropertyAnimation + subclasses), I added data sources (available applications, system information, ways to access settings and ways to read files from the file system) and the actual GUI with a QGraphicsView and a rudimentary sandbox so that GUIs get access to direct rendering while still being restrained (In earlier versions, UIs were able to resize the view and to "scroll" like a HTML page with contents outside of the view which isn't something we want of course). In other words: my work is mostly back end stuff, and I'm abusing Qt Declarative to hell to get the visual effects that I'm craving :p

Oh, and this does work on N900 (Panorama itself runs on N900 - I know without having tried it - and Qt Declarative itself does, too) and Nokia is trying to push this fact as much as possible, of course. The Qt YouTube channel is filled with videos showcasing QML on the N900 or other embedded devices. This technology is really exciting: to load a basic QML component, you need only ~10 lines of C++, and you can even write pure QML apps and launch them using a tool called "qmlviewer" that works kinda like the Adobe Flash Player (but QML obviously doesn't work in a web browser).
 
Last edited by a moderator:
dflemstr said:
Most of the visual stuff and the state machinery is Qt 4.6 (It's basically a 1:1 mapping to QGraphicsView and QPropertyAnimation + subclasses), I added data sources (available applications, system information, ways to access settings and ways to read files from the file system) and the actual GUI with a QGraphicsView and a rudimentary sandbox so that GUIs get access to direct rendering while still being restrained (In earlier versions, UIs were able to resize the view and to "scroll" like a HTML page with contents outside of the view which isn't something we want of course). In other words: my work is mostly back end stuff, and I'm abusing Qt Declarative to hell to get the visual effects that I'm craving :p
Ok, I knew about the state machine thingy but haven't ever gotten around to check the declarative architecture. On my list though :p

dflemstr said:
Oh, and this does work on N900 (Panorama itself runs on N900 - I know without having tried it - and Qt Declarative itself does, too) and Nokia is trying to push this fact as much as possible, of course. The Qt YouTube channel is filled with videos showcasing QML on the N900 or other embedded devices. This technology is really exciting: to load a basic QML component, you need only ~10 lines of C++, and you can even write pure QML apps and launch them using a tool called "qmlviewer" that works kinda like the Adobe Flash Player (but QML obviously doesn't work in a web browser).
Yeah, I know, I've been hearing a lot of this lately for some reason ;). I'll give it a spin... you guessed it: when my thesis is ready (I'm in a hurry with it) :D. Oh, and you might be interested in a project my university has with Sun. It's kinda toyish but has some nice aspects. Linky
 
Last edited by a moderator:
B-ZaR said:
Oh, and you might be interested in a project my university has with Sun. It's kinda toyish but has some nice aspects. Linky
<ot>
Had heard about Lively before via Sun (I usually program in Java/Scala and used to read everything that Sun announced back when they were working on the Java platform more than what they are now). Looks really cool, but I see a lot of things that overlap with KDE Plasma. It might be a viable alternative for situations when you don't have access to KDE, however, and I'd really like to see what would happen if this was put on the Google NaCl platform. An alternative to Flash, perhaps?
</ot>
 
Last edited by a moderator:
I just tried your menu.
Sometimes I open apps without wanting it…
But your menu is really great to use. It can be a killer app :)
Edit : just tried playing with the config file. Your menu looks definitely solid.
 
hells_dark said:
I just tried your menu.
Sometimes I open apps without wanting it…
But your menu is really great to use. It can be a killer app :)
You can change the application launch trigger by changing "interfaces/Magma/qml/ApplicationViewer.qml", line 39 from "onClicked: {" to "onDoubleClicked: {". The changes will be applied next time that you start Panorama.

EDIT: and I should totally stop spamming this thread; I wrote like 40% of the posts.
 
Last edited by a moderator:
I like it. Its a little choppy on my ATI video card but all in all a good experience can't wait to see it running on my Pandora.
 
Looks cool man!
Now I just need to scrounge up some cash to get a Pandora :p
I am new to this console btw.. I've been out of the game loop for a while due to being ridiculously busy.
This little handheld that could looks amazing!
 
dflemstr said:
EDIT: I might as well mention CPU usage... PMenu takes 100% CPU all of the time, Panorama uses 1% CPU when something is being animated, 8% CPU when application folders are scanned, and ~0% CPU when everything is static.

Pmenu uses 100% CPU at all times even on idle? Is this true??
 
Last edited by a moderator:
dflemstr said:
Status update:
  • Link applications from .desktop files with applications from libpnd. Provide a "preview" role (etc) via the ApplicationModel somehow. (0)
  • Add methods that change CPU speed, maybe that interface LEDs (probably not doing that last one), get CPU usage, battery levels, memory usage, etc, etc, so that UIs gain more freedom. (1)
  • Finish PMenu emulation (needs to be 100% feature complete, *except* for the "Media" tab which I think doesn't belong in a menu/launcher, but anyone can come with patches of course) (2)
  • Work on some decent default UIs that are more moddable (3)
  • Optimize

(0)Done. I needed only about 200 LOC for this, so it was easy (git diff --stat tells me:
Code:
  lib/pandora-libraries          |    2 +-
  panorama.pro                   |   17 +++++++++++++++--
  src/appaccumulator.cpp         |    8 ++++++++
  src/appaccumulator.h           |    2 ++
  src/application.h              |    6 ++++++
  src/applicationfiltermethods.h |    4 ++++
  src/applicationmodel.cpp       |    8 ++++++++
  src/applicationmodel.h         |    4 +++-
  src/desktopfile.cpp            |   12 ++++++++++++
  src/desktopfile.h              |    3 +++
  src/iconfinder.h               |    3 +++
  src/pnd.cpp                    |    6 ++++++
  src/pnd.h                      |   15 +++++++++++++++
  src/pndscanner.cpp             |   73 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  src/pndscanner.h               |   27 +++++++++++++++++++++++++++
  15 files changed, 186 insertions(+), 4 deletions(-)
)
I haven't actually *tested* this addition though, since I haven't bothered to set up an environment with PNDs etc.

(1)Can anyone tell me if libpnd wil assist with this in the future, or if I should start working on it from scratch?

(2)Depends on me testing (0), so can't do that yet. I'm pretty close already, though.

(3)Doing this next, while I wait on the Pandora so that I can test (0) properly.

During Xmas I was more or less away from a PC (fear!) so I missed most of this :)

I'll catch up on the thread but heres a quickie in case it didn't get covered already -- there are some libpnd util functions you're probably already aware of, and theres a bunch of scripts on the device to do thigns as well, such as set screen brightness; so one can open the /dev or /proc to do some things, or use a script which provides some edge case controls, or use libpnd API (so you can not worry about changing the device name if it changes), etc. Lots of ways. I probably should get it all into libpnd for consistency.

Setting cpu is in libpnd already. Let me know what you need and I'll slap it in there. Just trying ot catch up, so PM me :)

jeff
 
Last edited by a moderator:
intense_mc said:
dflemstr said:
EDIT: I might as well mention CPU usage... PMenu takes 100% CPU all of the time, Panorama uses 1% CPU when something is being animated, 8% CPU when application folders are scanned, and ~0% CPU when everything is static.

Pmenu uses 100% CPU at all times even on idle? Is this true??
The following is the main loop of pmenu:
Code:
	while( ! gui_done )
	{

        check_rediscover();

		gui_draw();
        GLES2D_DrawFont( small, 750, 0, GLES2D_GetFpsChar() );

		handle_dpad();

        GLES2D_SwapBuffers();

        GLES2D_FpsCounterUpdate();

		if(do_quit) gui_done = 1;

	}
It never yields its process' tread, but instead tries to draw as many FPS per seconds as possible, which is a good way to build an application like a game, because a game usually needs to redraw the whole screen every frame anyways, so it's not worth pausing the application until a redraw is actually needed. It consumes a lot of often redundantly used CPU cycles, however.

PMenu *will* use VSync, which means that if it reaches a constant 60 FPS, it will not go above that, which is something I guess.

Panorama, which uses Qt, does things differently. When nothing moves in Panorama, nothing is redrawn and so, the application uses close to 0% CPU, and when there is some code that gets executed that wants to draw something to the screen (e.g. during a screen transition), only that part of the screen that was changed is redrawn (e.g. only the small sliver of space that appeared during the transition and not the rest of the screen that remained largely static). This reduces CPU usage too, of course. I still have some optimizations to do in that area however, especially related to z-ordering and the like, so Panorama will use even less CPU in the future once I get to that point in my TODO.

Speaking of which...
skeezix said:
During Xmas I was more or less away from a PC (fear!) so I missed most of this :)

I'll catch up on the thread but heres a quickie in case it didn't get covered already -- there are some libpnd util functions you're probably already aware of, and theres a bunch of scripts on the device to do thigns as well, such as set screen brightness; so one can open the /dev or /proc to do some things, or use a script which provides some edge case controls, or use libpnd API (so you can not worry about changing the device name if it changes), etc. Lots of ways. I probably should get it all into libpnd for consistency.

Setting cpu is in libpnd already. Let me know what you need and I'll slap it in there. Just trying ot catch up, so PM me :)

jeff
I do CPU usage, swap, RAM, SD1 usage and SD2 usage already and am working on changing clock speed (I'll finish that up once I have a Pandora which should be in two months or so, so that's not a problem). Backlight... that's an interesting one, might want to add that in.

Also, the code I use for CPU, RAM, etc is currently not-so-optimized so I'd love to see that in libpnd in a more optimized C-style function. I don't use char * in Panorama since I'll have to cast that to QString every time I use it anyways, and so I'm using QString all the way down to even the systeminformation.cpp file (BTW, you might want to look in that file to see how the system info I'm currently reading is being extracted)

I don't think it's a good idea to include the analog nubs (and such devices) in libpnd unless a callback function is used; event polling doesn't fit with a low CPU usage model but lazy event transmission does.
 
Last edited by a moderator:
Strikes me it'd be a pretty easy alteration to pmenu; hell could just drop a usleep(100) or select() in there to relieve the CPU quite a bit, but shouldn't (Without ever having looked at the code ;) be too hard to do a better job of it. *Shrug*

Pass the word to cpasjuste; he's as overworked as the rest of us, but feedback is probably welcome, and god knows we all dont' see every forum post :)

For setting CPU, there is a libpnd call, and you can use a script (I forget the name right now .. we have a bunch of utility scripts like op_cpuclock (?) and op_backlight that can do things. pndevmapperd will be calling those scripts based on events, to do things like lower clock or backlight when lids close, device goes to low power mode, etc.

For clock: unsigned char pnd_device_set_clock ( unsigned int c ) {
(in pnd_device.[ch])

Ah, looks like I already added backlight:
unsigned char pnd_device_set_backlight ( unsigned int c ) {

So you're covered there :)

Let me know if you want the sh-names and I'll dig them up; I think thew standard script path was /usr/pandora/scripts and it has a few goodies in there.

jeff
 
/mnt/sd[12] are not used.

The SDs automount to their device name; /mnt/sd[12] was only used in my test confs way back, as I didn't know how we were going to end up a few months later. Or else its your own thing, so ignore this :)

ie: /media/mmcblk0p1 and /media/mmcblk1p1 (say)

Consider the searchpath in /etc/pandora/conf from the git for deployment:

5 [desktop]

6 searchpath /media/*/pandora/desktop:/media/*/pandora/apps:/usr/pandora/apps

Perhaps I posted /mnt/sd[12] in a wiki somewhere? Let me know, maybe I shoudl correct it :)

jeff
 
About the pmenu thing: I've already told him, but the thing is that it's already struggling with rendering a constant 30 FPS (albeit with GL ES emulation, but my GPU is pretty darn fast so that shouldn't be the issue) so there's a bottleneck somewhere in the app that a thread yield/sleep cannot eliminate... I should run valgrind on it some day...
skeezix said:
Perhaps I posted /mnt/sd[12] in a wiki somewhere? Let me know, maybe I shoudl correct it :)
No, no, I actually tested pandora-libraries with those paths and just started using them in Panorama too. I'll create a patch for Panorama immediately that uses the correct mount points, np (I'm already opening /proc/mounts anyways as you can see).

The clock: I just use Qt for that, and it does its magic to generate an accurate clock source for me. Setting the clock... well, that may be useful too, we'll see.

Scripts: Actual method calls or even opening files are faster than any script invocation, so I'll stick with those, but maybe I will copy some of the code from the scripts to see how some of the more obscure information is being extracted ;) But I know the pandora-libraries repository's contents by heart by now from all the hacking, so I'll find them on my own, you don't have to bother.

And yes, I'm also aware of pnd_device.c, so I know what's there, don't worry!

Btw, I'll probably be forking pandora-libraries in the future, not to add custom crazy features, but to do some maintenance work, fix the Makefile (so that it generates the correct symlinks for libpnd.so.1 - because LD can't find it in its current form! - and also so that it respects the CC and CXX env variables, things like that), and I will also do some code clean-up because gcc 4.4.2 spits out warnings at me every time I compile pandora-libraries. I might also reorganize the dir layout a little bit so that I can compile it using qmake which is useful for cross-compiling Panorama - I currently have to change the Makefile manually to include "-m32 -march=..." flags when compiling for i686 which is cumbersome.

All in all: I'll make changes to the repo that fix some basic stuff, but I don't know if the changes will be worth pulling into the main repo, because you might have some secret purpose behind putting source files in a folder called "lib" etc (maybe for bitbaking scripts, I don't know), so it might be best if I maintain an external fork that I pull changes into from time to time from the main repo.
 
Last edited by a moderator:
As I've always said .. its not perfect, submit away! I'm also fully willing (post launch?) to share or hand over the reins to anyone/team, fine by me ;) The code as is works pretty well, but I've always intended to make each piece easily replaced. A lot of it was hacked up very early on and tried 5 different ways and the one that stuck the most, kept. We were winging where we were going, and time was tight, and when you've got barely no OS to stand on while hacking on such things .. and it turned out okay. I'm no superhero, though I do alright, and I've been coding a long time.. well long enough not to worry about criticism or refuse patches ;) So patch or let me know your hates, and we can do what we can.

Certainly, no one ever did anythign worse by having a second pair of eyes on work; being quiet merely means a mistake or odd decision or out of date idea may get left in through accident (rather than because I'm beat up which is fine ;)

(Heck, I'd have done it all differently, but I really wanted a plain-C implementation that is obvious and easy to use, to make it widely acceptible. If I was just doing it for me, I'd have done it all very differently .. python or lisp and just a few command line tools, but the way I did it was to be easier, and admittedly.. easier to maintain on my hectic shedule :)

The Makefile does have a few requirements to make baking easy, but a few changes would be easy enough. The recipies for libpnd are up in the GIT somewhere or other (not in the pandora-libraries git, since its a Ansgtrom thing per se.) ie: "CROSSCOMPILE" env vars have to be handled, as you can see in the Makefile.

Why I chose lib/include -- why not, twas as good as any other and simialr to how many other systems are packaged in source (ie: CPAN type perl modules and so on.)

Anyway, headache today, I'm off :)

jeff
 
First of all, this is utter genius. God bless you for the time you've put into this project thus far. I was just wondering (as are many others, I'm sure) if you will be posting this as freeware on the pandora "papp" store, or be charging for it? If you will put a price on this, what will be the price range? Thanks for your time... once again. Panorama will be another project that will transform the Pandora into a one-of-a-kind console.
 
aesir911 said:
First of all, this is utter genius. God bless you for the time you've put into this project thus far. I was just wondering (as are many others, I'm sure) if you will be posting this as freeware on the pandora "papp" store, or be charging for it? If you will put a price on this, what will be the price range? Thanks for your time... once again. Panorama will be another project that will transform the Pandora into a one-of-a-kind console.
It's free and open source under the Creative Commons Attribution Share-Alike 3.0 license (GNU GPLv3 compatible). This means that I *could* put a price tag on it, but I will have to distribute the source code for it for free, so *if* I were to put a price tag on it, some one else could just take the source code, compile it, and release it for free.

In other words: Panorama will always be free for any use, and you can modify it and try to sell it yourself if you want (but you probably won't be able to since you have to distribute the modified source code)

License abbreviation:
http://creativecommons.org/licenses/by-sa/3.0/

Full license:
http://creativecommons.org/licenses/by-sa/3.0/legalcode
 
Last edited by a moderator:
Back
Top