Author Topic: GUI Ideas, Skin and Theme handling  (Read 26239 times)

Jesper Hansen

  • Administrator
  • YaBB God
  • *****
  • Posts: 1618
  • ypod? ynot?
GUI Ideas, Skin and Theme handling
« on: 28.02.2007 at 21:59:17 »
Here we can discuss ideas to how we could implement a flexible skin/theme handling.

For a start I have copied ToS's post from another thread below.




As to MICĀ“s less is more approach to the GUI... no lets go wild and crazy...   I would like an implementation where we have a config file at the SD card that describes what text or icons should be used for what info... That way MIC could have his simple gui with text, and I could have my shiny progress bar and funky battery icon 

eg.

config.ini
battery_icon=on
battery_icon_xy=10,10
battery100%=batt_icon100.bmy
battery75%=batt_icon75.bmy
battery50%=batt_icon50.bmy
battery25%=batt_icon25.bmy
battery0%=batt_icon0.bmy
#battery_icon=off
#battery_text="%d.%d Volt",10,10

If electricity comes from electrons, does morality come from morons ?

MIC

  • YaBB God
  • *****
  • Posts: 648
  • Yampp3/USB - THE AUDIENCE IS LISTENING
Re: GUI Ideas, Skin and Theme handling
« Reply #1 on: 01.03.2007 at 13:22:35 »
Some sort of configurqtion file seems to be the only way for skin handling which a user can modify himself.
ToS's approaches looks fine for the beginning.

I would define a simple rule for displaying: "What is NOT configured shouldn't be displayed on LCD"
Some default LCD output is of course necessary, but this could be text mode only.

The configuration file can combine both graphical and text config. This way we can also implement language handling.

Some brainstorming...

For icons and images:

- a tag to identify the config option
- X & Y coordinates
- file name, for multiple icons all file names

For text:

- a tag to identify the config option
- X & Y coordinates
- font size
- font and background color
- text sting to show

Arguments (for iprintf & siprintf) should be fixed in code.


Add your thoughts and ideas here ;)
/Michael

.:: www.mictronics.de ::.

ToS

  • Newbie
  • *
  • Posts: 21
  • Gender: Male
  • :-)
Re: GUI Ideas, Skin and Theme handling
« Reply #2 on: 02.03.2007 at 12:11:00 »
Some unstructured thoughts....

To minimize mem impact, we maybee should just load the GUI configuration and load the bmy's at demand ?

One solution could be, having a array of pointers, and when loading a GUI config, malloc space for each of the GUI component description, storing the pointer in the array.

The allocated memory, that describes:
What the GUI component represents, eg. GUI_PROGRESSBAR, should do with a byte ?
Type of GUI component, Text, graphic, should also do with a byte ?
Position x
Position y
And then a char array, if its a graphical GUI component that requires more than one bmy lets use ; as delimiter and then 0x00 teminated.

And then in the GUI update function,

eg. (Just pseudo code...)

while (g_pGuiComponent[idx] != NULL) {

  pGuiComp = g_pGuiComponent[idx];

  switch (pGuiComp[0]) {
    case GUI_PROGRESSBAR:
      switch (pGuiComp[1]) {
        case GRAPH:
           draw grapic at pGuiComp[2], pGuiComp[3], using bmy with index in delimited string based upon the value...
         break;
       default:
         //Handle it as text...
           draw text at pGuiComp[2], pGuiComp[3], using string with the value added...
       break;
     }
    ...
     break;
    case GUI_BATTERY:
}
}

Ulrich Behrenbeck

  • Sr. Member
  • ****
  • Posts: 400
  • what colour ? red ? blue ? ...
Re: GUI Ideas, Skin and Theme handling
« Reply #3 on: 07.03.2007 at 08:17:14 »
I am not sure about that, just thoughts

I think it's a pity that the covers are fixed downscaled to 64 square pix

I could think (in long terms) of an album selection that just shows the cover on entire display (like the foto browser does) where one can choose entire albums thru their covers, just like flipping thru an LP bunch.
the "wasted" room on flash seems to be acceptable.

so can't we always have 128 pix on disk and scale them down by  50 % fixed in ordinary play view
yes - no  -maybe  -i don't know - can you repeat the question ?

kay1234

  • Jr. Member
  • **
  • Posts: 88
  • Gender: Male
Re: GUI Ideas, Skin and Theme handling
« Reply #4 on: 07.03.2007 at 10:45:25 »
What about having two versions of the cover? That would require a minor amount of extra space on the sd card but we won't have to scale the image. I think that will save us cpu ressources and increase run-time by saving battery power.

Maybe it is even possible to display the large image in play view and display the title of the currently playing song on top of that image...

Botosu

  • Full Member
  • ***
  • Posts: 230
  • Gender: Male
  • Fight Fire With the Fire
Re: GUI Ideas, Skin and Theme handling
« Reply #5 on: 07.03.2007 at 10:57:22 »
What if we remove the cover from Player View, to have some space on display,
in order to show small icon buttons (player buttons)?

Cover graphics can be used like Ulrich sad, they are small (size of memory)  and stored on tFlash,
so is no problem to have bigger cover pictures.

A thought:
If the user does not have a cover picture in mp3 folder,
we must display a generic picture stored somewhere else on tFlash,
but in this case we have to display somehow the name of the album.

MIC

  • YaBB God
  • *****
  • Posts: 648
  • Yampp3/USB - THE AUDIENCE IS LISTENING
Re: GUI Ideas, Skin and Theme handling
« Reply #6 on: 07.03.2007 at 12:57:57 »
Since we already have implemented ID3v2 tags, it is also possible to use the APIC field to store cover pictures within the MP3 file. So there could be covers for all MP3 files, even if they are not from the same album.
/Michael

.:: www.mictronics.de ::.

Ulrich Behrenbeck

  • Sr. Member
  • ****
  • Posts: 400
  • what colour ? red ? blue ? ...
Re: GUI Ideas, Skin and Theme handling
« Reply #7 on: 07.03.2007 at 15:12:40 »
I havent been to deep into ID2, but I guess , decoding and displaying may be quite a mess on such a small system.
I checked my tags and found sizes of up to 50 k - I wouldn't want to read and scale that down to 64*64 with only say 1k of RAM available :)
yes - no  -maybe  -i don't know - can you repeat the question ?

MIC

  • YaBB God
  • *****
  • Posts: 648
  • Yampp3/USB - THE AUDIENCE IS LISTENING
Re: GUI Ideas, Skin and Theme handling
« Reply #8 on: 07.03.2007 at 16:47:26 »
You don't need to read a full ID3v2 tag into memory.

The current code is parsing a full tag in 10 byte portions, searching for field tags/headers. Only valid fields are processed and read into memory.

I wouldn't go the way of scaling.
The APIC tag stores pictures in binary format, not depending on type or size. So it's possible to store any size picture in any format, also YBMP, the special yPod picture format.

---

And my opinion about the GUI:
I mean the target of the yPod is a pocket type player not a desk player.This means I would turn off backlight and LCD as soon as the user has finished handling the GUI.
So I can't see the purpose for funny graphics, big images and other things when the LCD is off and/or the player is hidden in your pocket.
/Michael

.:: www.mictronics.de ::.

kay1234

  • Jr. Member
  • **
  • Posts: 88
  • Gender: Male
Re: GUI Ideas, Skin and Theme handling
« Reply #9 on: 07.03.2007 at 17:11:25 »
When the player is hidden in your pocket there is no purpose for any type of GUI at all since you do not intend to operate anything (except for the volume maybe). I think Botosus intention is to have the main controls and the song/play info visible in play mode at the same time without having to change screens. I agree with him that this might increase the usability while operating the device.

Ulrichs idea is a quite different approach on browsing through the available music and is for sure a matter of taste (ok, maybe the controls thing is a matter of taste, too...). Maybe this will result in a compile time switch to choose from one of the methods...

I do agree with turning off the backlight and lcd. Btw., the lcd is not turned off in the current FW, only the backlight.

MIC

  • YaBB God
  • *****
  • Posts: 648
  • Yampp3/USB - THE AUDIENCE IS LISTENING
Re: GUI Ideas, Skin and Theme handling
« Reply #10 on: 07.03.2007 at 18:01:10 »
Quote
Btw., the lcd is not turned off in the current FW, only the backlight.

Right, but it should be turned off, or put into sleep mode.
But I discovered some problems with sleep mode on another project, so some investigation need to be done for the problem.
/Michael

.:: www.mictronics.de ::.

z80_fr

  • Jr. Member
  • **
  • Posts: 71
  • Gender: Male
Re: GUI Ideas, Skin and Theme handling
« Reply #11 on: 07.03.2007 at 18:30:00 »
Quote
Btw., the lcd is not turned off in the current FW, only the backlight.

Right, but it should be turned off, or put into sleep mode.
But I discovered some problems with sleep mode on another project, so some investigation need to be done for the problem.

What kind of problems? graphics data corrupted? other?

MIC

  • YaBB God
  • *****
  • Posts: 648
  • Yampp3/USB - THE AUDIENCE IS LISTENING
/Michael

.:: www.mictronics.de ::.

Ulrich Behrenbeck

  • Sr. Member
  • ****
  • Posts: 400
  • what colour ? red ? blue ? ...
Re: GUI Ideas, Skin and Theme handling
« Reply #13 on: 08.03.2007 at 08:02:03 »
using a generic thing like APIC for sth yP special looks like a bad idea to me. if you really store images in bmy there, all other player will fail to display them....
yes - no  -maybe  -i don't know - can you repeat the question ?

MIS

  • YaBB God
  • *****
  • Posts: 996
  • yampp firmware creator
Re: GUI Ideas, Skin and Theme handling
« Reply #14 on: 09.03.2007 at 01:28:37 »
I get some idea for graphics playmenu. For now I implament only few functions, but it work.
We can check my concept in last version of code in repository.
For using this code we need additional file "plmenu.bmy" in "/system" folder at tFlash card.
My (bad) example of this file is avaliable at: www.republika.pl/romek_by/plmenu.bmy ... (sorry, I'm poor graphics designer)...
The concept is easy to add some more functions as "FF, REW, Bass, Treble, Balance, ect., and probably have good keyhandling idea.
Please try it.
--MIS--