Design a Panorama UI


^ Perhaps dbus? I've found it to be very nice for stuff like that. What kind of usage scenarios do you have in mind for such a system?
Yes dbus is a very likely candidate. It's still in an early stage, but let me just share some of my notes on it so far:

The different user interface environments provided currently and in the future on the Pandora have very different interaction styles. XFCE is strongly mouse (nub or stylus) oriented and makes use of a rich variety of widgets, mini-menu is based around the gaming controls, menus and icon grids. XBMC is based on gaming controls, keyboard and hierarchical menus but has rich widget functionality available for plugins.


As a consequence of this diverse running environment no emulator or application ever feels native to the user as they all implement their own user interface. The Pandora camp is split into two types of users: those who regard it ss a portable computer and those who regard it as a handheld gaming console. Especially the later category struggles with the lack of interface/look and feel uniformity on their Pandora console.


This protocol would allow applications to declare the logical structure of their interfaces and it would allow launchers and/or desktop environments to present these options in an as native as possible manner.


Two scenarios are of particular importance:

  • Configuration of the application or emulator.
  • Opening/saving of files/roms



This approach is not without its downsides. Not in the least, each application would need to add support for this interface (most likely dbus based). Many developers will refuse to do so, causing their application to feel unnative in some environments (though still usable).On a related note, if it becomes popular it might cause a psychological barrier to porting applications as it requires actual development to integrate this.


Typical flow of control:



Code:
[launcher interface]   [application]     [dbus intf.thread]

       |                    |                    |

       | start app. --intf  |                    |

       +------------------->|                    |

       |                    |                    |

       |                    +----+               |

       |                    |    |  menu opened  |

       |   menu url         |<---+               |

       |<-------------------+------------------->|

       |                    | listen for cmds    |

       |                    |                    |

       | query(url)         |                    |

       +--------------------.------------------->|

       |  gui description   |                    |

       |<........................................|

       |                    |                    |

       | change_option(url, key, val)            |

       +--------------------.------------------->|

       |  ok                |                    |

       |<........................................|

       |                    |                    |

       | action("resume")                        |

       +--------------------.------------------->|

       |  suspend           |                    |

       |<-------------------.--------------------+

       |                    |  resume            |

       |                    |<-------------------+

                            |


Advantages:

  • Uniform look & feel across applications, easier for non technical users
  • If guis provide rich navigation or config profile features then the individual apps don't need to
  • Framework for app. menu development can simplify new applications


Disadvantages:

  • Needs to be supported per application, likely to face developer resistance
  • Less flexible as entirely hand-coded GUI
  • Overhead



Initial proposal:

  • menu oriented. Each menu can contain menus, options and actions
  • each menu element is a tuple: (id, type, name, data, image?)
  • @id: reference to pass to call
    @type: menu, action, option (widget type hint)
    @name: text to display on screen
    @data: case type of
    menu: submenu url
  • action: ?
  • option: possible values or regexp


@image: optional image to display for entry



Idea: options could be split further into widget hints:


radiobuttons, editbox, pulldown menu, listbox, etc.


Each GUI is free to override the presentation


Callable functions, needs more work:

  • getMenuContent(path) -> description
  • setOption(path, id, value) -> success/reload/path ?
  • doAction(path, id) -> success/reload/path ?


Todo:

  • check interfaces of existing emus for missing reqs.
  • validate validity of interaction & control flow for at least:
    minimenu, XFCE (generic emulator frontend?), Panorama, XBMC
  • Carefully design the API
  • Provide library support for at least C/C++ and python
    probably based on dbus
 
Sorry that I'm not providing the full UI design that you are looking for, at this time, just throwing a few ideas about. Hopefully someone is going to come forward soon with something decent.


One thought I had today, instead of a separate sidebar of tabs, these could be incorporated into the icon/item hierarchy. So at the top level would be the various sections, equivalent of the tabs, so more minimalist visually. There would be an 'up to parent' item (with a key shortcut), within the sub areas to get back up, or better this is the one button always on screen, like Magma's back button. There could be deeper levels if this suited uses i.e. file browsing. I'm thinking game button B to go into stuff/run and A to go up in the hierarchy, with X and Y for scrolling through. When scrolling the page, the cursor would hop to the nearest item on the current page. The control might scroll gradually or it could page a whole display. If flicked with the stylus or finger, as opposed to dragged, the scrolling could keep on moving until stopped with another touch, which would be good when you have a long way to scroll.


The other thought was a UI where the focused item would be a consistent position on the screen, possibly middle, or top centre, and the controls would move the items.


I like the idea of a rotating circle of items, that you mentioned. Might be nice with concentric circles or a spiral. In this case scrolling, would be rotation of course. Makes me think of the Ring Commands menu system in Secret of Mana.


mzleowqwofr480x48075.jpg

This was was TL so I DR, but I love the idea of a ring based menu like in SoM or Evermore. I'd love to help, what to download/make?
 
Making a ring menu in QML (and so in panorama) is really simple using PathView. Take that example and swap the model to the one provided by panorama's application-plugin, then modify the delegate to for example show the icon and application name. For example.


Jourdy, if you want to try making a ring application menu in panorama, I can provide any assistance in QML/panorama you may require. If you have a pandora (don't remember if you do), you can start by getting panorama and creating a directory to the appdata/interfaces for your UI. Then create a file called ui.qml there with the contents



Code:
import Qt 4.7

import Panorama.UI 1.0

PanoramaUI {

  id: ui

  name: "My UI"

  description: "My Awesome UI"

  author: "Jourdy"

  anchors.fill: parent


  Rectangle {

    anchors.fill: parent

    color: "blue"

  }

}


This should get you a blue screen when you change panorama configuration to use your UI and start it. From there on it's importing other panorama plugins and writing the QML to define the UI.


I still intend to make a UIs for panorama myself too. Just not right now :p
 
Last edited by a moderator:
Thanks, I don't have a Pandora ATM but I would like to contribute something while I'm here.
 
All this talk of Android for Pandora 2 has got me thinking, why not implement an Android-style UI for Angstrom/Pandora OS?


A quick search for Pandora UI brought me here, Panorama looks amazing thanks B-Zar and dflemstr, etc :)


I drew up some very basic layouts of how I think it could work.


TfLm3.jpg



6cM8w.jpg



UbOMS.jpg



icwLJ.jpg



Would gestures like swiping work in Panorama? How about something like widgets? Could the Pandora button be mapped to make a sleek little menu pop out the right side of the screen, even mid-game?


Cheers!
 
This looks interesting; is Panorama capable of doing things like this?
 
Also useful, would be:

  1. A media player (maybe a reskinned xbmc that matches the rest of panorama?)
  2. A neat way to auto launch roms in emulators (possible? already implemented?)
 
First: Panorama is a bit on pause again, though I do intend to continue working on it once a few pieces fall into place.


Second: This is the kind of thing I started this thread for, nicely done :)


First impressions on the UI: It seems very much doable. Gestures can be implemented quite easily using the GestureArea element. The browser view is a WebView. Apps and Appstore views would work like in previously shown UIs. RSS/latest uploads etc would require a new C++ plugin, but it's nothing too hard to accomplish. Panorama would be well suited for this kind of UI.


Regarding the overlay mode (shown over a running application): It's a bit harder, as Panorama would need to actually play window manager. Not impossible, but a lot of work.


Media player: Plugin/component not instantly available. Would require a new media player plugin. Possibly doable using gstreamer as a backend or something, but definitely not trivial. Someone was working on a QML media player for GSoC though, haven't looked into the results.


Emulator/rom launcher: Definitely possible. Needs a C++ plugin to crawl/maintain a model of the ROMs for the UI to use, but otherwise it's just like PND launching.
 
Cool, this sounds very exciting!


Regarding emulator preferences windows etc, can Panorama change the way windows display, i.e. not like an xwindow but more like an Android/iOS panel menu? It would be very weird to have a nice sleek UI and all of a sudden the default xwindow pop up (which are often too big for the Pandora screen to display anyways).


@ Binky, I was thinking of an Android-style UI. In my mind media player would be a separate app, you could shortcut it into the right hand menu though.


Which reminds me, I think a file-browser should be a standard option in the menu too.
 
Well, X would probably have to be at the bottom anyway. MiniMenu was IIRC first made to work without X by writing straight to the framebuffer, but is mostly used on X to support running applications that require X. Qt applications like panorama can also run without X (see latest Qt-related Raspberry Pi developments for example), but that would have the same problem. Ultimately, it's the window manager/decorator that has the final say in how X windows are laid out. If panorama were to incorporate a window manager, it would be possible to make what I think you mean.


Anyway, the window manager stuff is quite a bit off my area of expertise and an awful lot of work from what I gather. If such thing comes out, I probably won't be the source :p


Most things are possible. They just take a variable amount of development time. Time, that ultimately is the developer's free time. Which he/she may want to use on something more fun to work on :)
 
What about a small suite of launchers / apps comprising:

  • Package manager/launcher/rom launcher
  • file browser
  • web browser
  • media player
  • universal document viewer
  • media player
  • overall settings/control panel


With a coherent UI and easy switching between them.


It would be a lot of work, but a neat/slick way of doing simple tasks might attract some of the game&web newbs, while appeasing Craig and his simplicity==android campaign.
 
Interesting, thanks for giving me a rundown of how it might work. I myself dabbled in Qt back in 2004, had to code a word processor for a uni project. That was back in the day, I don't touch much code anymore.


Well, I guess I'll get started by brushing up on designing "Web 2.0" style graphics. Gradients and stuff :)
 
I'm not a UI and/or interaction designer either, but I'm interested in it and I do know that it's not a good idea to mix up an interface based on what people say. More often than not, what people say they want in a GUI is not actually what they want in a GUI. Simply following a "most votes win" approach won't yield the desired results (that is, if you desire above-average results). To say it in oversimplified words, you have to find out what people want based on how they actually use software.

This. Anyone who has tried to do software engineering for a reasonable number of users will probably have discovered that using the steps


1. Gather user requirements


2. Draft design


3. Get feedback from users


4. Implement


will not result immediately in a product that everyone finds desirable. Unfortunately you need to iterate over steps 3 and 4 quite a few times.


EDIT: a wild rant appears... now it's gone
 
Last edited by a moderator:
Hey!

How is this proyect going? Looks pretty stopped. 

I want to start doing some stuff in panorama, but I need someone who clarify me some things:

  * Is panorama some kind of official QT way of programming or is just the name of your proyect?

  * How can I star doing things? which tools do I need? Just regular QT dev environment or something else?

  * Is this kind of standard or just made for pandora?

Thanks in advance.
 
All this talk of Android for Pandora 2 has got me thinking, why not implement an Android-style UI for Angstrom/Pandora OS?


A quick search for Pandora UI brought me here, Panorama looks amazing thanks B-Zar and dflemstr, etc :)


I drew up some very basic layouts of how I think it could work.

TfLm3.jpg


6cM8w.jpg


UbOMS.jpg


icwLJ.jpg



Would gestures like swiping work in Panorama? How about something like widgets? Could the Pandora button be mapped to make a sleek little menu pop out the right side of the screen, even mid-game?


Cheers!
This is what pandora needs!! in my opinion, of course.
 
The key would be to reuse existing open source projects. A unifying UI would need:

  1. a pnd launcher - I suggest focussing around a search bar, so you could search for "games" or "gnumeric"
  2. a pnd downloader - extremely similar to above, but showing whats available (but not installed) - this would be very tightly intergrated with (1)
  3. a text editor - perhaps with a sprinkling of note magagement / IDE features
  4. a terminal
  5. a file browser
  6. a web browser
  7. a media player
  8. settings / hardware manager
  9. Universal ROM launcher
These would all have a matching UI, eyecandy and control scheme

Much of the work for 1&2 has already been done

There are loads of text editors to choose from for (3) whichever would be easiest to reskin

ditto for (4)

(5) would need more work, but a simple one shouldn't be too much work

Perhaps use babypanda for (6)? Its fast and (I believe) already uses QT

7 - perhaps rockbox could be persuaded to run in (semi) windowed mode?

8 would need completely new gui - is whoever wrote all the current native settings still around?

9 I believe someone is working on this?

---

Nice gravedig, btw ;)
 
Last edited by a moderator:
Panorama is a QML runtime and a set of QML plugins designed to provide services for the UIs. PNDManager is currently the most/only used example of a Panorama UI.

The UI you propose is possible, though it would require a few new plugins for RSS feeds and settings. Dflemstr (the original author of Panorama) and I started designing a system settings framework that could be used in Panorama UIs but never implemented anything more than a couple of prototypes.

The main problem is dev effort. I've been working on Wars, QMLON and Glhck-related stuff lately because frankly, I've been using my pandora quite little the last few months. It's still awesome whenever I go to a longer trip (played final fantasy 2 through during my christmas trip to see the folks), but day-to-day it's mostly just there. When I'm at home I have a shiny new WiiU to cater to my gaming needs. The motivation to create and *maintain* stuff just isn't there when I wouldn't use the result save for a few occasions to do something current options already provide quite nicely.

The maintaining part is one few take into account when considering the amount of development effort required for something. I wrote PNDManager for a competition, and the entry consisted of the state it was in at release. I did quite a few updates to it afterwards improving performance, fixing bugs and adding features. Currently it does what I need it to do and quite nicely, so there's little motivation for me to work on it. Sure there are still features and fixes people would want, but I'd rather see contributions than requests at this point. I could find other motivation sources like technological (getting a C++11 and Qt5 toolchain for pandora could probably do this), but at the moment I'm getting more out of my other projects.

I'd love to see Panorama take off. The design from an architectural standpoint is awesome. It does however get lonely doing it all by myself. When I started this thread I did it to advertise Panorama by doing a community-designed UI that would show how flexible and fast-to-dev-for Panorama is. I wanted to bring more attention to it to get more devs working on it to avoid the current situation and at the same time provide the community with a UI that is uniquely suited for Pandora.

Sorry for the rant :(
 
heh, thanks for bumping this. I forgot about this thread. I've been considering using Panorama for my new Pyra tool, but couldn't really work out where to start. Must try and read it later if I get some time.
 
             ↑                             ^

"Use ←   →             and <       >  to navigate"                   ties direction to direction quicker.

             ↓                             v

So dpad does mostly whats on the left side, and buttoncluster does what is mostly on the right.

I like the font, colouring and highlighting, but i dont understand what the border does, i think it could be better without.
 
Last edited by a moderator:
Back
Top