Search results

btw - http://wiki.gp2x.org/wiki/Emulation

timbobsteve - when are you planning on releasing your toolchain? I've driven myself nuts trying to build one....

That's great news.

e17 for Embedded does look nice.

I don't think a fully programmable interface is a good idea – It needs to be easy to make new interfaces, and skins for those interfaces. What I suggested in my post awhile back I think still stands as the best approach. We need a standard set of “widgets” such as icon areas, select item...

Read through this: http://wiki.gp2x.org/wiki/Current_GP2X_Issues#USB_Problems

It's a balancing act - and I think it should be up to the end user where that balance is set, one size doesn't fit all. As long as the effects are modules to the menu it wouldn't slow things down a bit for people who didn't want them.

I think that's a good idea - and I think a super minimalist text only launcher should be made, and it would be great if it read in it’s input from the same menu.xml file that the “full featured” menu used. However, I think that needs to be a completely different program then a more full...

I think something as “simple” as DrMD’s scrolling background adds a ton of sparkle, and while I personally wouldn’t want sound effects, or background music, I think the capability needs to be there. The important thing is to design the system in such away that user such as yourself could...

One thing I didn’t think through enough when I was making my first suggestion was that all icons should be defined by the in the menu file. I think upon further thought, that it would be best if there was also a icon-theme.xml file that acted as an override to what is in the menu file. This...

That's a good one too, should also be possible to create something like that.

A KDE or Gnome theme won't do anything when it comes to defining layout - and layout needs to be flexible. Both of these themes should be possible with a properly designed menu program:

bah.. it took more then 5 minutes to come up with that post... I just hope your understanding that the freedesktop spec only solves a small part of the problem, but yes I agree that following the spec is a good idea, as it will allow for different menu programs to all read the same file for how...

I think the focus should be on what tools do designers need in terms of widgets, and then we design a spec with the flexibility to do whatever is needed.

Looking at that I don't see anything that couldn't be described by what I said in my purposal, I'm thinking that's a good thing.

eh.. I still don't say it gives us much. A massive amount of what's in the freedesktop spec just doesn't apply - but all the same, it's not that different. Sure ditch what I said for menu.xml and just use their spec - I don't think it makes that much of a difference. What I'm puposing is a...

bah.. o well - just an idea. It would be cool if we had a Karama system ala Slashdot... (runs and tries to find a flame proof suite)

If all your suggesting is using their catagories that's all well and good. I didn't address the issue of how the catagories should be made at all in my post. I think using the "Registered Categories" in the spec you linked would be a good idea. But, the actual format of their menu file...

Because it's not a desktop.

Once the menu program itself is written, then programs to edit it’s xml files could be written. Editing menu.xml, sounds.xml, music.xml, and backgrounds.xml could all be done on a program written natively for the gp2x. However, I think layout.xml would require a desktop computer. Ideally the...