Generic Gui/menu/file Selector

[cosam]

A lot of full-screen framebuffer/SDL apps require some kind of dpad-driven gui for menus, file selectors, etc. Is there some kind of generic library which can be used to achieve this without starting from scratch every time? If not, would developers find this useful and would there be interest in building such a library?

 

[dflemstr]

A lot of full-screen framebuffer/SDL apps require some kind of dpad-driven gui for menus, file selectors, etc. Is there some kind of generic library which can be used to achieve this without starting from scratch every time? If not, would developers find this useful and would there be interest in building such a library?

Qt ;P

But seriously: if you choose to use something as low-level as SDL (relatively speaking), you can't expect to get features that are available in e.g. Qt. If you want higher-level features, you have to use higher-level libraries. And all SDL's features are available in Qt so it is a possibility.

 

[cosam]

I'm thinking higher level than Qt, more like "here are my menu items: make me a menu" or "get me a file name". I guess a bit like zenity, but then as a library and with fewer dialogs but more features (e.g. nested menus, customisation, etc.).

 

[dflemstr]

I'm thinking higher level than Qt, more like "here are my menu items: make me a menu" or "get me a file name". I guess a bit like zenity, but then as a library and with fewer dialogs but more features (e.g. nested menus, customisation, etc.).

#include <QtGui/QApplication>
#include <QtGui/QMainWindow>
#include <QtGui/QMenu>
#include <QtGui/QMenuBar>
#include <QtGui/QFileDialog>
#include <QtGui/QMessageBox>

QStringList hereAreMyMenuItems()
{
    QStringList result;
    result << "Item 1" << "Item 2" << "Item 3";
    return result;
}

void makeMeAMenu(const QString &title, const QStringList &menuItems, QMenuBar *menuHolder)
{
    QMenu *menu = new QMenu(title, menuHolder);
    foreach(const QString &item, menuItems)
    {
        menu->addAction(item);
    }
    menuHolder->addMenu(menu);
}

QString getMeAFileName(QWidget *parent = 0) {
    return QFileDialog::getOpenFileName(parent, "Get me a file name", QDir::homePath(), "Any file (*.*)");
}

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMainWindow w;
    QMenuBar *mb = new QMenuBar(&w);

    QStringList menuItems = hereAreMyMenuItems();
    makeMeAMenu("My menu", menuItems, mb);

    QString fileName = getMeAFileName(&w);
    QMessageBox::information(&w, "Got a file name", fileName);

    w.setMenuBar(mb);
    w.show();
    return a.exec();
}

 

[cosam]

Nice. Can that run on a raw frame buffer? By menu I mean something like (for example) the one you get in MAME when you hit tab. And not a clicky file selector, just dpad a controlled list of files/directories you can navigate through.

 

[dflemstr]

Nice. Can that run on a raw frame buffer? By menu I mean something like (for example) the one you get in MAME when you hit tab. And not a clicky file selector, just dpad a controlled list of files/directories you can navigate through.

Qt embedded runs on the frame buffer, yes.

The appearance of the menu is controlled by Qt style sheets. The default, when you have a normal window, is to make a menu bar (à la "File, Edit, View..." in a normal application), but you can apply CSS-like style sheets that control exactly how menus show up. And if you use a QGraphicsView and a QGraphicsScene, you can extend the QMenu class and display it however you want, or use another setup entirely (QMenus don't have to be added to QMenuBars; you can use your own class that extends QWidget or QGraphicsItem).

The file dialog can be used with the mouse and with the D-Pad. You can control the appearance with optional options, e.g. whether you just want a file tree, or a full file dialog with previews and "Go up one folder" and a shortcuts sidebar etc... Check out the documentation at http://doc.qt.nokia.com/4.6/qfiledialog.html (remember: this is Desktop Qt, not Qt Embedded, documentation)

EDIT: BTW, this is a personal preference, but: you should always prefer 'standard dialogs' to self-made dialogs.

E.g. if you want a file list that you can scroll through and select a file from *only*, or if you don't want a menu bar for your application but instead a centered list of options to choose from, and intend to make one of your own, then reconsider; because if you don't use standard widgets and the like, your app becomes inaccessible. Standard widgets adapt to the environment, support internationalization, right-to-left layouts, external customization, etc, etc. So as long as you don't have a *very* good reason for not using plain and standard widgets, then you *should* use plain and standard widgets.

 

[cosam]

Cool, I will look into this. If it's that good though, it kinda makes me wonder why no-one seems to be using it for emulator menus and such.

 

[dflemstr]

Cool, I will look into this. If it's that good though, it kinda makes me wonder why no-one seems to be using it for emulator menus and such.

Many developers want to make their apps look "barebone" i.e. "Look here, I made a file browser that is incredibly basic so that I'll save 0.1 kiB of resources!"; never mind that those file browsers are nothing more than a list of files with a white arrow at one side, and scroll faster the more FPS your application runs at...

</rant>

People are starting to learn, though; look at visualboyadvance for example; it uses an "ordinary" menu system which I think is a great step in the right direction.

 

[skeezix]

We've been debaqting it around a bit.

The zenity concept is not bad -- give it a 'class' of app ("emu"), and whethor you want to pick direcotries or files, and how many, and so on and so forth, and let it pick; if youwant higher level like copy-paste with other systems, for sure go QT or GTK (QT, GTK is ugly -- but low level just do SDL or framebuffer along with the rest of the app. (QT/GTK will get you theming and such with ease and standards though, which is nice.)

The problem for it is -- an emu only needs a 'generic file picker' in its infancy; a suffidiently advanced piece of work will no doubt have its own fully integrated GUI and file picker; so spending a lot of time making a 'generic' one isn't really worth it -- after awhile, no one will need it. And spending a lot of time on it really suggests just reusing whats there.

Its trivial to throw together a basic file picker (really, about 10 minutes work with SDL, and we've all done itbefore so there are lots we could leverage from the past) .. but in the end seems to me .. go QT/GTK/wxWidgets/whatever, or roll your own that integrates with the rest of your app.

(Otherwise, any sufficiently advanced emu will have its own UI, and a different generic file picker? it'd clash.)

There is a niche of use though -- some app classes need a generic file picker, but do not need any other UI.

*shrug*

I thought about working on something, but not sure its worth it in the end, since .. for my emus, I'd start with it, then swithc away as soon as I had enough time.

jeff

 

[skeezix]

zenity provides the GK file picker; thats why no one uses QT's -- theres on handy QT file picker

It is pretty easy -- QT supplies some convenience functions - static non-class function; like 'open file, heres the list of extensions to allow', and poof, shows the file picker. Could wrap it up into a generic zenity like thing with a short app that just uses the command line.

Fire up Kronos and hit 'load story file' or whatever, and you'll see the generic static function QT file picker.

You know, the GTK file picker (or at least zenities use of it) is really slow too, and buggy; ie: 1) it prescans a lot of directories, so a big SD card will take seconds to minutes to come up(!!), and 2) we've found out if you switch it to Details mode, it gets confused and doesn't always work (!!)

So really your qustion is -- is the rest of your app a custom GUI, or a standard one; if a standards one, _use that_

jeff

 

[mindlord]

/me looks at Thunar and looks at Mime types, takes them both by the hand and leads them into the discussion.

 

[cosam]

The problem for it is -- an emu only needs a 'generic file picker' in its infancy; a suffidiently advanced piece of work will no doubt have its own fully integrated GUI and file picker; so spending a lot of time making a 'generic' one isn't really worth it -- after awhile, no one will need it. And spending a lot of time on it really suggests just reusing whats there.

I'm just wondering if a generic picker/menu/GUI of sufficient quality and configurability would be good enough to stick. Might be good for all those apps out there which have either minimal or full-blown, desktop-like GUIs and would benefit from a bolt-on SDL (or whatever) GUI system.

 

[cosam]

OK, so I went ahead and started trying some stuff out. I've built Yet Another[sup]TM[/sup] simple SDL menu system which I've bolted onto Handy to play around with. Consider it a proof of concept at best ;-) The menu/GUI stuff is built as a shared library (working title "Goomba"... the result of thinking "GUI" after playing too many Mario games). The API is a bit like that of libxml2 in that you create items and append objects to others as children to construct your menu. Pass it an SDL surface to draw on and let 'er rip. Items have a pointer to the variable they twiddle and can have a callback which is run when the value changes or you select the item, depending on what kind of item it is. I currently have:

• Integer: set min/max and increment step, then flip through the values.
• Enumerations: set a bunch of name/value pairs and cycle through them.
• String: Not working yet as I've not made the string input routine.
• Action: For navigation/quitting the menu, or other stuff if a callback is used.
• Control: For capturing button presses or joystick/mouse events.
• File selector: A simple file picker which generates menus for directories to navigate through.
• Menu: Container for a bunch of other items (may be nested menus) which can be scrolled through.

Pandora owners can give it a test drive by installing the new Handy package (linked above). It can also be built pretty easily on a PC using the sources in Subversion:

Goomba: svn checkout http://sources.cosam.org/svn/goomba
Handy: svn checkout http://sources.cosam.org/svn/pandy (not a typo)

Goomba has a little test app which gets built along with the library (src/test.c). Both have different makefiles for PC/Pandora which should get you going although some minor editing is likely to be required.

All a bit rough around the edges, but you get the idea. Even if it doesn't go anywhere, Handy gained a nice little menu for the time being ;-)

 

[DaveC]

Nice and simple but need a few options:

BIG ONE: Needs to have a "save as default directory". If you don't have the ROMs where coder expects it, it is a royal pain to have to navigate to them everytime especially for non-linux users. What is mmbkl01, media, etc. and all of that crap?


Since there is allot of dead space everywhere you could put instruction text in smaller font along the bottom like : "press Y,X to page, B to select" Press "S" to save current dir as default", etc.

It is nice if it doesn't require any external libs or resources. That way it will work for stuff that runs in minimal setups.

 

[God Ginrai]

Nice and simple but need a few options:

BIG ONE: Needs to have a "save as default directory". If you don't have the ROMs where coder expects it, it is a royal pain to have to navigate to them everytime especially for non-linux users. What is mmbkl01, media, etc. and all of that crap?


Since there is allot of dead space everywhere you could put instruction text in smaller font along the bottom like : "press Y,X to page, B to select" Press "S" to save current dir as default", etc.

It is nice if it doesn't require any external libs or resources. That way it will work for stuff that runs in minimal setups.

Due to the way the Pandora works right now, a save as default directory function is actually really hard to do. The functionality would be broken whenever the sd card is mounted to a new folder. (Which happens often enough with pulling and reinserting your SDs.

-God Ginrai

 

[Creature XL]

Nice and simple but need a few options:

BIG ONE: Needs to have a "save as default directory". If you don't have the ROMs where coder expects it, it is a royal pain to have to navigate to them everytime especially for non-linux users. What is mmbkl01, media, etc. and all of that crap?


Since there is allot of dead space everywhere you could put instruction text in smaller font along the bottom like : "press Y,X to page, B to select" Press "S" to save current dir as default", etc.

It is nice if it doesn't require any external libs or resources. That way it will work for stuff that runs in minimal setups.

Due to the way the Pandora works right now, a save as default directory function is actually really hard to do. The functionality would be broken whenever the sd card is mounted to a new folder. (Which happens often enough with pulling and reinserting your SDs.

-God Ginrai

Not an expert on that topic, however, I *think* when you use ext2 you can give the volumes labels and use those.
I stumbled across them with the Fedora distribution and found them annoying. But I had a fixed HDD with fixed partitions os I was comfortable with /dev/sdb and such.

Can someone with a better understanding of volume labels shed some light on this?

OK, that doesn't solve the general problem (for win users), though. Isn't there a something similar on FAT?

 

[Prometheus]

Not an expert on that topic, however, I *think* when you use ext2 you can give the volumes labels and use those.
I stumbled across them with the Fedora distribution and found them annoying. But I had a fixed HDD with fixed partitions os I was comfortable with /dev/sdb and such.

Can someone with a better understanding of volume labels shed some light on this?

As far as I can tell, volume labels aren't being shown when browsing right now (though Thunar does recognise them). Almost all of my cards are ext2, and have such labels.

OK, that doesn't solve the general problem (for win users), though. Isn't there a something similar on FAT?

I can't speak for Windows users (I don't use it myself, so I don't know), but Linux and Mac OS X let you give a label to a FAT/FAT32 device, when formatting.

What is mmbkl01, media, etc. and all of that crap?

Equivalent to the "A:"/"B:"/"C:"/"D:"/"E:"/"F:"/"G:"/"H:"/"I:"/"J:"/"K:"/"L:"/"M:"/"N:"/"O:"/"P:"/"Q:"/"R:"/"S:"/"T:"/"U:"/"V:"/"W:"/"X:"/"Y:"/"Z:" that you may be familiar with.

 

[cosam]

Nice and simple but need a few options:

BIG ONE: Needs to have a "save as default directory". If you don't have the ROMs where coder expects it, it is a royal pain to have to navigate to them everytime especially for non-linux users. What is mmbkl01, media, etc. and all of that crap?

I think that's more something for the calling app but yes, as others have said, the current mount point set-up doesn't lend itself to saving paths anyway. I believe ED is working on something with volume labels (I sent him a tip on how this could be done quite easily).

Since there is allot of dead space everywhere you could put instruction text in smaller font along the bottom like : "press Y,X to page, B to select" Press "S" to save current dir as default", etc.

Certainly doable.

It is nice if it doesn't require any external libs or resources. That way it will work for stuff that runs in minimal setups.

Yes, I've tried to keep the dependencies down. It only uses SDL and SDL_ttf for the font.

 

[EvilDragon]

Nice and simple but need a few options:

BIG ONE: Needs to have a "save as default directory". If you don't have the ROMs where coder expects it, it is a royal pain to have to navigate to them everytime especially for non-linux users. What is mmbkl01, media, etc. and all of that crap?

I think that's more something for the calling app but yes, as others have said, the current mount point set-up doesn't lend itself to saving paths anyway. I believe ED is working on something with volume labels (I sent him a tip on how this could be done quite easily).

Indeed, I am. Hopefully ready for the next Hotfix by next week