Wanted To Talk About The Gui Backend

[AnonymousTipster]

Currently, we've got plenty of people designing mock-ups for how they want the user interface to look and feel, but there's only been implied discussion of what we want the UI to actually do.
It's likely that the first iteration of the UI will be quite simple, in order to actually get something functioning properly on the Pandora. Creating a fully-fledged UI will require a dedicated developer.

I'm going to start listing a few things and their relative importance out of 10, adding any of your ideas that seem relevant.

1. Multitasking (9/10) - lots of people are expecting this from the Pandora, as it is such a powerful machine, but it could be difficult to implement properly. The backend will require the ability to keep as many applications concurrently running in memory as possible and swap in and out those that aren't as important. This will to an extent be handled by the linux OS that the UI is based on, but to what extent I am unsure.

2. Modularity (10/10) - For me, this is very important to the core design of the UI. Where possible, any features of the UI that can be made into a separate executable should be. Example: Navigating through the file browser in the UI, you open an MP3 file. Instead of using a hard-coded MP3 player in the UI, it runs an executable which plays the MP3 file. This way, the MP3 player can be upgraded or replaced completely independently of the UI. I'm hoping that linux will allow invisible windows, so that we can have a separate MP3 executable control panel (play, pause, stop etc) rendering on top of the UI and other applications. Being able to bring up one application on top of another would be a great feature.

3. Overclocking (5/10) - Being able to tweak clock speeds from the UI would be nice, but is of course not essential.

4. Speed of use (8/10) - Making a flashy interface is useless if it takes you too long to find what you want. It needs to be designed to have icons organized logically and reachable in a minimum of key presses. Cursing through directories should be done in the background while the user can view what has already been loaded. Show default icons where no icon has been loaded yet.

5. RSS Feeds (2/10) - Lots of people seem to want RSS feeds. Not a big deal for myself, but it would be easy to implement any RSS/Weather/News widgets if executables could share screen space together, meaning any widget is just another application, but one which the UI has control of where and when it is displayed.


That's all from me for the moment, feel free to add some to this list so that whoever ends up working on the GUI has some idea of what needs to be achieved before the prettyness is added.

 

[hessiess]

hi, new here. I would want a simple, eye candy free UI, and be able to navigate it quickly. Or just a Terminal emulator would be adequate. This is one reason why i hate commercial products, they always have tons of ugly eye candy.

 

[impreziv]

hi, new here. I would want a simple, eye candy free UI, and be able to navigate it quickly. Or just a Terminal emulator would be adequate. This is one reason why i hate commercial products, they always have tons of ugly eye candy.

im sure the skinning of the UI will include some basic 1-colour themes.

having just a Terminal would be ghey. relying too much on a tiny qwerty is annoying as hell. touch screen is going to be what will make this thing a pleasure to use.

if it came out with just a terminal, there would be a very unorganized array of homebrew UIs out there. by releasing a UI with the device, it standardizes the interface. this makes development, use, and support much easier for the whole community.

 

[Pleng]

hi, new here. I would want a simple, eye candy free UI, and be able to navigate it quickly. Or just a Terminal emulator would be adequate. This is one reason why i hate commercial products, they always have tons of ugly eye candy.

Em yuk!

If you simply want a terminal then there'll surely be a way of replacing the default gui with one, but I like eye-candy, though not at expense of functionality.

I think everybody here expects a graphical GUI, and most people are inspired by Chad's designs, which are simply georgous.

So, a graphical GUI is a given, but as you can boot from SD there's no reason you couldn't make a little boot disk that jumps straigh into a teminal. Best of both worlds!

 

[sindbad]

xterm is fine, no need for special boot things

 

[Karel Jansens]

You know the Rapture is near when people start calling the GUI the "backend"... :rolleyes:

 

[AnonymousTipster]

You know the Rapture is near when people start calling the GUI the "backend"... :rolleyes:

Heh, not the backend of the system, just the backend of the GUI.

 

[Sphinxter]

Swap?

 

[lubidog]

hi, new here. I would want a simple, eye candy free UI, and be able to navigate it quickly. Or just a Terminal emulator would be adequate. This is one reason why i hate commercial products, they always have tons of ugly eye candy.

yeah, just use a terminal! Then watch the sales just fly.....


(I want eye candy, dammit!!!)

 

[DaveC]

Yeah but I don't want so much eye candy that it takes forever to load and eats up so much RAM that doing everything would be cumbersome and slow. The PSP UI is a good example, eye candy but horrid layout and poor useability.

I still say it should default with a PDA/Gmenu2X type launcher. If you want all of that other happy crap you could replace it by changing the startup sequence.

 

[Holokauston]

You know the Rapture is near when people start calling the GUI the "backend"... :rolleyes:

Heh, not the backend of the system, just the backend of the GUI.


http://en.wikipedia.org/wiki/Front-end_and_back-end




On topic:
I agree that eye-candy at the cost of usability is wrong but thinking a terminal is a good UI for a system like this is just dumb, a UI should be easy to understand, clean and productive but that doesn't necessarily go against "eye-candy" solutions (as long as they don't "hump" the system resources). I would prefer a system that has a more or less clean "desktop" where you can add widgets or likewise so you could personalize it after your own needs and desktop navigation should mainly be via touchscreen, an easy to configure menu system would also be helpful in making it more productive.

As easy to use as possible should be the first goal, just because something is easy to use doesn't make it bad, an xterm should exist but should not be the main input for usage.

 

[Vorporeal]

Currently, we've got plenty of people designing mock-ups for how they want the user interface to look and feel, but there's only been implied discussion of what we want the UI to actually do.
It's likely that the first iteration of the UI will be quite simple, in order to actually get something functioning properly on the Pandora. Creating a fully-fledged UI will require a dedicated developer.

I'm going to start listing a few things and their relative importance out of 10, adding any of your ideas that seem relevant.

1. Multitasking (9/10) - lots of people are expecting this from the Pandora, as it is such a powerful machine, but it could be difficult to implement properly. The backend will require the ability to keep as many applications concurrently running in memory as possible and swap in and out those that aren't as important. This will to an extent be handled by the linux OS that the UI is based on, but to what extent I am unsure.

2. Modularity (10/10) - For me, this is very important to the core design of the UI. Where possible, any features of the UI that can be made into a separate executable should be. Example: Navigating through the file browser in the UI, you open an MP3 file. Instead of using a hard-coded MP3 player in the UI, it runs an executable which plays the MP3 file. This way, the MP3 player can be upgraded or replaced completely independently of the UI. I'm hoping that linux will allow invisible windows, so that we can have a separate MP3 executable control panel (play, pause, stop etc) rendering on top of the UI and other applications. Being able to bring up one application on top of another would be a great feature.

3. Overclocking (5/10) - Being able to tweak clock speeds from the UI would be nice, but is of course not essential.

4. Speed of use (8/10) - Making a flashy interface is useless if it takes you too long to find what you want. It needs to be designed to have icons organized logically and reachable in a minimum of key presses. Cursing through directories should be done in the background while the user can view what has already been loaded. Show default icons where no icon has been loaded yet.

5. RSS Feeds (2/10) - Lots of people seem to want RSS feeds. Not a big deal for myself, but it would be easy to implement any RSS/Weather/News widgets if executables could share screen space together, meaning any widget is just another application, but one which the UI has control of where and when it is displayed.

That's all from me for the moment, feel free to add some to this list so that whoever ends up working on the GUI has some idea of what needs to be achieved before the prettyness is added.



Couple of notes:

• AFAIK, there is a dedicated GUI developer who is currently experimenting with GUI implementations and is the person creating the GUI that will be shipped pre-installed on the Pandora. (DJWillis?)
• In terms of modularity, something like MPD would do exactly what you're thinking. It is a music-player library from which you write a front-end (in this case, directly into the GUI). The MP3 player would still be MPD, but you would be writing your own code to interface with MPD. I don't know if other music players have this functionality - I'm sure some do, but MPD was the one that came to mind.
• I agree with the speed of use being quite important. Some of the speed of use will come from finding a balance between an eye-candy heavy GUI and a purely functional GUI. This is where GMenu2X excelled. It got the job done, and looked good. Much of this will also come from good programming practices - it is important to code the GUI so that it doesn't hog system resources and also so that it uses as little memory as possible (to help with the suspending of the GUI when a large application like an emulator is run). This is also a balance that needs to be made, as the interface will function faster if the graphics are pre-loaded into RAM, but will take up more resources.

 

[Gilrad]

About overclocking...

...Are you sure overclocking at any level would be okay on the Pandora? Sure, it may draw more power, but the real issue I would think is heat. Since there's no cooling (that I know of), I would think it would be much more at risk of overheating and possibly damaging the hardware.

 

[Chip]

About overclocking...

...Are you sure overclocking at any level would be okay on the Pandora? Sure, it may draw more power, but the real issue I would think is heat. Since there's no cooling (that I know of), I would think it would be much more at risk of overheating and possibly damaging the hardware.

The SoC uses very little power compared to a desktop CPU and generates almost no heat. I think the thermal load is something like .25W. You could overclock to the point of total system lock up, but I doubt the chip would get more than warm to the touch. It is specifically designed for MIDs and cell phones that have no active cooling and rarely even have holes in the case for air circulation. If heat was an issue, it would not be suitable for those applications.

Perhaps one of the devs could take a temperature reading while the chip is under full load just to settle these concerns once and for all.

 

[cb88]

QUOTE
Perhaps one of the devs


could overclock the liveing daylights out of one of them and give us thermal readings .......after they come out and he/she has the change to buy another(in case it explodes...(not likely(at least i thinks its not likely(but then again i did use a lot of parentheses))))