Panorama


dflemstr

dflemstr

It's a ball.
Joined
Jul 31, 2008
Messages
2,514
Location
Stockholm, Sweden
Website
Visit site
Before reading this post, PLEASE note that this is beta software. There's a reason why I put this in the Developer's Corner

Introduction
OK, so I have this weird thing that I do.
When I have a problem that I want to solve, I tend to reinvent the wheel, but not in the classical sense. I find that I have the need for tools that solve my problem in a very *specific* way (they have to have a specific feature, or have to suit me perfectly in some way), and thus, when I don't find such tools, I tend to make them myself.

Panorama is one such tool that I developed to suit my own needs (The PND Manager was also such a tool, but I digress). What Panorama is, is that it's an application launcher, or "menu" as some of you would call it, for the Pandora. I wrote it in C++ using Qt 4.6.1.

Now wait a minute, you're all probably thinking, there's already a menu/launcher for the Pandora called "PMenu"; why invent another one? Well, as I said above, I'm picky about the tools I use, and Panorama has quite a slew of features that I didn't find in PMenu.

Panorama currently has the following features:
  • I don't put any restrictions on the themes (called UIs) for Panorama. If you want to write an UI, you'll be using Javascript and a markup language called QML to write the entire user interface (or you just copy someone else's UI and swap the images ;) ). This means that one theme can have a sliding interface, another theme can be tabbed, another can just have a list of applications to launch while another just displays computer information.
  • Themes are made to adapt to you, and not vice versa. You can of course control a Panorama UI using the D-Pad and the action buttons, but if you want to, you can also use the mouse cursor to click your way through the application, or you can use your fingers and the touch screen to drag and slide around things. There are no restrictions there, either.
  • I want it to be possible to extend your theme to do exactly what you want. Want to have an analogue clock in your UI? Panorama does that. Want to show the latest XKCD strip in the background? Panorama can do that. Want to show the number of E-Mails you have relative to how long your "/etc/X11/xorg.conf" file is? Panorama can do that, too.
Some technical stuff:
  • Content is seamlessly rendered using WebKit, so you can use HTML inside text snippets, and everything will still render quickly. This is standard Qt stuff, really.
  • The Qt Kinetic framework supports everything you can throw at it: BMP, PNG, SVG, TTF, OTF, whatever. Inside of UIs, you can transform elements, apply effects, create transitions and animations etc. The amount of freedom you get is astonishing.
  • Contrary to PMenu, Panorama conforms to the FDF menu standard. This means that you won't get previews (screenshots) for your applications, but instead you get access to every application that is installed on your system, compared to just those that are inside of PNDs (you'll even see my Wine applications in the video below! Note that Word 2007 WILL NOT WORK on the Pandora).
  • Qt will use OpenGL, OpenGL ES or just a normal rasterizer automatically, so drawing is hardware accelerated.
  • I put all the files that might change frequently and that Panorama accesses under the eyes of INotify, so files are reloaded instantly when you change them.
  • When you create UIs, you have access to a quite elaborate settings API. You can store custom settings for each UI, or store settings that are shared between UIs. No restrictions apply.
Current themes:
35cismt.png
Magma (default)

104rf2t.png
Simplicity (for those who don't like bloat)

j1348i.png
Colors (via PMenu compatibility layer)
This screenshot shows a bug with the CPU indicator that has been fixed

34snejb.png
Test (first test theme)

Videos:
http://www.vimeo.com/8415450
http://www.vimeo.com/8331408
http://www.vimeo.com/8284733

Test builds:
http://github.com/dflemstr/panorama/downloads

Now, some of you might think that Panorama has no chance of becoming widely used, because there aren't any themes for it yet. Well, fear not: it is possible to take any PMenu theme and turn it into a Panorama theme. You just drop a file and a directory into the directory of the PMenu theme, and it can then be used as a Panorama UI seamlessly.

I took my Colors PMenu theme and did just this to demonstrate:
http://www.vimeo.com/8331408

Note that this feature of course isn't completely production ready yet (There are hangups and the Media tab doesn't work yet (don't ask about Previews, they won't work for a LOONG time)), but then again: Panorama as a whole isn't production ready yet, either.

The purpose of this post
I'd like to hear what people think about this, and that means that you *should* try it out!
You can find the source at http://github.com/dflemstr/panorama along with build instructions. If the interest is great enough, I might even provide binary builds for x86_64 (or even 32-bit if I can be bothered) but it would be kinda pointless as I'd have to rebuild them once for every change that I make.

Patches, bug reports (the GitHub repo has an issue tracker) and so on are of course welcome, especially if they are performance related. Panorama isn't slow; it's relatively fast actually, but it uses small hacks here and there and might have memory leaks that, when removed, might make it even faster. It does currently use about 10 MiB of RAM, which isn't much at all, but that number could also be reduced. And, if you think that some feature should be added, just give me the patch and we'll talk about it!
 
Impressive.

I tried to do something very similar to this awhile back, but instead of reinventing the wheel I started by melting aluminum for the hub, and mixing rubber for the tire. I got bogged down in the scripting language, 2D acceleration, and fiddly bits. If course I was trying to do this outside of X, using framebuffer only, so I didn't have a widget library to build off of, but I digress.

You've managed to clobber QT and webkit into something really slick. I like it a lot. How's the memory footprint compared to Pmenu?
 
mindlord said:
Impressive.

I tried to do something very similar to this awhile back, but instead of reinventing the wheel I started by melting aluminum for the hub, and mixing rubber for the tire. I got bogged down in the scripting language, 2D acceleration, and fiddly bits. If course I was trying to do this outside of X, using framebuffer only, so I didn't have a widget library to build off of, but I digress.

You've managed to clobber QT and webkit into something really slick. I like it a lot. How's the memory footprint compared to Pmenu?
Click to expand...
PMenu uses 12.2 MiB excluding shared libs, Panorama uses between 8 MiB and 14 MiB (depending on the UI loaded) excluding shared libs.

Including shared libs, well... Qt takes quite a bit of RAM to run (about 5 MiB ideally, but I'll do real measurements soon), but you're using Qt for something else most of the time anyways so it's not a big loss. Also, I have no idea how much memory the OpenGL ES libs take (for PMenu's rendering), so I can't really compare the total memory...

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. This is measured on a Pentium 4 3GHz processor.

Another EDIT: May I remind you that Qt runs on the frame buffer, too? Just sayin' :p
 
Last edited by a moderator:
Well, this looks like it suits my insanity just fine. I'll see what I can do with it. Unfortunately, time is not on my side. Christmas and all. Family... bah... there's programming to be done! Heh. It will be some time before I can really dig into this, and javascript isn't one of my well known tounges. Not to mention the fact I already have a major project on the front burner.
 
Didn't look at the video yet; presumably you are pulling PXML from pnds (or using libpnd?) and using pnd_run or pnd_run.sh to invoke pnd files?

(We've recently added pnd_run, which expects a pnd-full-path as arg, and it will parse PXML and launch the pnd; you can do a file-assoc from .pnd to pnd_run and just double-click/whatever on pnd-files to run them, pretty handy for a lot of things.)

If you're not supporting pnds, then get to it :)

I'll go watch your video now :)

jeff

edit: I sort of hate people like you -- 1) free time? and 2) way too talented ;) Very nice preview; I apprecoiate the little touches you put in, such as the sliding panels ripped off from iphone, and the cursor sliding smoothly between items rather than just jumping there. Very nice!
 
btw, if it helps I can easily provide something like .. "pnd_ls" that lists the discovered pnd-files, and then you could use pnd_run to invoke them. I've often thought about making just a few basic tools like that, and pnd_query to pull bits from the PND (PXML, or parts of PXML, and things like icons etc) .. then pndnotifyd just becomes "pnd_ls | pnd_map pnd_dotdesktopemit" type operation, nice and modular.

Anyway, let me know if theres anything you'd need to make your life easier that falls within the bounds. I know you don't care of rhalf of what I've done, but it had to be done so it'd be there day-0, and you can replace all of it as you see fit later :)

jeff
 
skeezix said:
Didn't look at the video yet; presumably you are pulling PXML from pnds (or using libpnd?) and using pnd_run or pnd_run.sh to invoke pnd files?

(We've recently added pnd_run, which expects a pnd-full-path as arg, and it will parse PXML and launch the pnd; you can do a file-assoc from .pnd to pnd_run and just double-click/whatever on pnd-files to run them, pretty handy for a lot of things.)

If you're not supporting pnds, then get to it :)
Click to expand...
EDIT: Wow, you're a fast typer! Anyways, no need for pnd_ls if the patch below is added... Either that, or if you have a better idea on how to link .desktop files to PND files, then I'd be glad to hear about it.

I'm currently scanning "/usr/share/applications" and "~/.local/share/applications" for .desktop files, nothing more advanced than that.

I *do* have pandora-libraries pulled in as a submodule in the Git so I plan on using it eventually, but .desktop files will probably always be the source of application info for panorama, because I really want "normal" apps to also be launchable from within Panorama.

If you'd add the following patch to pandora-libraries I might manage to create some integration with libpnd, however:
Code: 
From 1e91a42e0e411c68e658f575dff7461fc0d8dcc0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Flemstr=C3=B6m?=
Date: Tue, 22 Dec 2009 17:04:16 +0100
Subject: [PATCH] Added pandora unique id to .desktop extractor.

---
 lib/pnd_desktop.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/lib/pnd_desktop.c b/lib/pnd_desktop.c
index f8ea3d7..2e7a713 100644
--- a/lib/pnd_desktop.c
+++ b/lib/pnd_desktop.c
@@ -67,6 +67,11 @@ unsigned char pnd_emit_dotdesktop ( char *targetpath, char *pndrun, pnd_disco_t
     fprintf ( f, "%s", buffer );
   }
 
+  if ( p -> unique_id ) {
+    snprintf ( buffer, 1020, "X-Pandora-Id=%s\n", p -> unique_id );
+    fprintf ( f, "%s", buffer );
+  }
+
 #if 1
   if ( p -> desc_en && p -> desc_en [ 0 ] ) {
     snprintf ( buffer, 1020, "Comment=%s\n", p -> desc_en ); // no [en] needed I suppose, yet
-- 
1.6.5.2
 
Last edited by a moderator:
Fair enough; might be 'better' (?) to use libpnd discovery, since that'd get you multipaths and work the same as other apps, but maybe you don't need to care -- you're already ontop of the fact you're only picking up menu-targeted apps, probably on the assumption people can run desktop targeted apps on their own (as well as random pnd files on their SD cards, etc.) So probably okay.

The pandora-ID is implicit in the .desktop filename, btw, but perhaps that is too tenuous for your liking?

I will add the ID to the .desktop, since it'd survive a rename that way.

You could leverage the libpnd pnd_notify junk to detect when a rescan is needed (ie: SD eject, apps moving around using command line or a dir manip tool, downloading using browser, etc), or hook up any number of alternatives. Just a suggestion though.

jeff
 
skeezix said:
Fair enough; might be 'better' (?) to use libpnd discovery, since that'd get you multipaths and work the same as other apps, but maybe you don't need to care -- you're already ontop of the fact you're only picking up menu-targeted apps, probably on the assumption people can run desktop targeted apps on their own (as well as random pnd files on their SD cards, etc.) So probably okay.
Click to expand...
Well, I really wanted to stay FDF compatible to begin with, but I can always pull in additional scan paths (e.g. ~/Desktop and whatnot, or whatever the pnd config file says) by adding a few lines to the loader, not a problem.
skeezix said:
The pandora-ID is implicit in the .desktop filename, btw, but perhaps that is too tenuous for your liking?
Click to expand...
Well, I'm trying to expand Panorama so that it works network-transparently; you can currently change the Panorama config file so that it loads it's UI from "http://example.com/bla/" and it just works. I've not managed to do the same thing with application sources, but I might later (to e.g. "automatically" (w/ user confirmation) download applications from the Pandora app store etc).
If I bind myself to file names, that becomes rather difficult...

skeezix said:
I will add the ID to the .desktop, since it'd survive a rename that way.

You could leverage the libpnd pnd_notify junk to detect when a rescan is needed (ie: SD eject, apps moving around using command line or a dir manip tool, downloading using browser, etc), or hook up any number of alternatives. Just a suggestion though.
Click to expand...
I use INotify for that already :p
I really want to use as little resources as possible, so I only rescan individual files when they are added, removed etc. The result is that an application shows up milliseconds after its desktop file has been added (It's fun to drag a .desktop file into ~/.local/share/applications: it shows up in Panorama and *after that* in the file manager itself :p). I don't think that's possible with pnd_notify (? haven't checked).
 
Last edited by a moderator:
Wow. I will most definetly try this out. I'm a big fan of Qt and this seems a really great use for QML and the webkit integration.

I kinda know the answer, but I have to ask. Would it be possible to make a UI that has tabs for different emulated systems? The tabs would contain ROM lists (from a file, discovered statically with a script or something). I'm not trying to step on the toes of any emulator frontends, but I'm getting a small grin thinking about what could be done with a "menu" (it really is more like a desktop or dashboard or something) this flexible.
 
Wow, a Pangea ripoff :lol: Well, no, not exactly, just joking. I say that because latest private Pangea versions look similiar to Panorama, and also use QML!! and has similar horizontal kinetic-scrolling. Wow :D Although there are only a few similiarities, they are not identical in any way.

EDIT: wow again, I've read again the first post and, *WOW* you have described exactly my latest intentions for Pangea, except the webkit thing and a few minor things. Just you've beat me.
 
B-ZaR said:
I kinda know the answer, but I have to ask. Would it be possible to make a UI that has tabs for different emulated systems? The tabs would contain ROM lists (from a file, discovered statically with a script or something). I'm not trying to step on the toes of any emulator frontends, but I'm getting a small grin thinking about what could be done with a "menu" (it really is more like a desktop or dashboard or something) this flexible.
Click to expand...
I've created a very VERY simple extension to QML that reads text files called "TextFile" (go figure). Allows you to read any text file on the system. If you have a list somewhere of games, you could just parse it and create a list of the games. Note, however, that this is outside the scope of Panorama because I still want to adhere somewhat to the UNIX model of "one tool per job".

Feel free to fork the code and provide your own QAbstractItemModel for ROMs; you can do that too, with the benefit that the ROM discovery happens in speedy C++. The app discovery code can basically be adopted to do exactly that.

efegea said:
Wow, a Pangea ripoff :lol: Well, no, not exactly, just joking. I say that because latest private Pangea versions look similiar to Panorama, and also use QML!! and has similar horizontal kinetic-scrolling. Wow :D Although there are only a few similiarities, they are not identical in any way.

EDIT: wow again, I've read again the first post and, *WOW* you have described exactly my latest intentions for Pangea, except the webkit thing and a few minor things. Just you've beat me.
Click to expand...

If you had worked publicly I might have known ;) too late for that now.

Would really like to get your input on a few things if you happen to look at the code some time. I know that my code is largely uncommented but it should be understandable; I have been stuck with Java for a couple of years but that experience has at least thought me to name my functions properly :p

------------------------------------------------------------------------------------------

My TODO-list for now, in case anyone is interested:
  • Link applications from .desktop files with applications from libpnd. Provide a "preview" role (etc) via the ApplicationModel somehow.
  • 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.
  • 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)
  • Work on some decent default UIs that are more moddable
  • Optimize
 
Last edited by a moderator:
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.
 
That's a very nice looking menu system there dflemstr, I especially like the N900 style parallax kinetic scrolling and analogue clock, but do I have to wonder if Panorama was conceived as a way of repeatedly stating your displeasure at media being included in PMenu.

I’m not a really Unix guy, but I can see how the ideology of “one tool per job” has an appealing simplicity. However, I can’t really see how picking an application or game from a list and playing it is so very different from picking a film or video clip from a list and playing it from an end users point of view.

You might argue that running a game is a very different process to opening a clip in a media player, but the UI for both tasks is going to be very similar indeed, and if you’ve developed a good system for one of these things, it seems a bit strange not to also use it for the other; for instance the search function you have in Panorama look like it would also work very well with an extensive media list.

There may well be some big reason I don’t understand for your approach, and I intend to try Panorama along with everything else on Pandora to find what I like and what best suits my needs, but it just seems a little bit like ideology over usability to me.
 
Well, part of the reason is of course also that I'm lazy and don't want to create a MediaPlayer component for Panorama. Controlling media streaming is complicated, exposing an API is complicated, and while it can be done with not too much effort, I'm focusing it (my effort) on other things at the moment that are more worthwhile.

I also want to avoid pulling in Phonon as an additional dependency to Panorama (Phonon, with its KDE heritage, works quite well with Qt, at least compared to e.g. mplayer which is a beast in comparison), and Phonon, while being one of the more lightweight multimedia frameworks around, would increase the RAM usage of Panorama quite a bit (say, by 50%) just by loading the libs and a basic player.

My last reason why I don't want to include a media player is performance: currently, when Panorama is idle, it uses 0% CPU time. Streaming video while the rest of the GUI is idle would *not* enable Panorama to use 0% CPU time, but rather something like we see in PMenu, where it uses 100% CPU time on my P4 machine, *constantly*, even when no media is playing, just because you have to keep your GUI in sync with the player so that there are no overdraws or other visual glitches.

I'm not really that much of an ideologist as you seem to be thinking; I can think rationally as well ;)

Also: my main point above wasn't that I wouldn't include a media player in Panorama, ever, but rather that I wouldn't try to emulate PMenu's media player (in order to make Panorama 100% compatible with PMenu skins)

Oh and BTW, that search feature you saw in the first video is just a specific feature of the default UI module. It's not something "built in" in Panorama or anything, it's a thing written in pure Javascript. So don't think too much about that ;)
 
I'm posting in this thread again, to present a new Panorama theme!

It kinda demos what I've been working on since last time I presented a video to you.

The footage:
http://www.vimeo.com/8415450

Some notes:
- This is still a work in progress
- The high CPU usage you saw in the video is generated by my screen capture program; Panorama takes about 12% CPU on my machine normally with the Magma theme.

BTW, if anyone has an idea about how to solve this:
http://github.com/dflemstr/panorama/issues#issue/2
...then please don't hesitate to tell me. I have absolutely no idea why that happens.
 
You must log in or register to reply here.

Similar threads

bzar
Design a Panorama UI
2 3 4
Replies
60
Views
19K
HolySmoke
HolySmoke
bzar
Panorama
17 18 19
Replies
372
Views
44K
CPUnltd
CPUnltd
bzar
Panorama
Replies
17
Views
5K
bzar
bzar
bzar
Release Panorama
5 6 7
Replies
134
Views
28K
gruso
gruso
bzar
Release Panorama
Replies
2
Views
2K
milesy
milesy
Back
Top