On Monday, August 16, 2010, Stefan Majewsky wrote: > I would like to invite you to thinking about, discussing and designing a > general set of interface components for games which can be used on mobile > devices instead of the usual WIMP controls. The ultimate goal is a UI
random thoughts: * what kind of role could gluon play? * is most of the issue about menubars / toolbars, along with alternative input systems for games like kgoldrunner? for menubars/toolbars, then yes, something like XMLGUI could be good, and it would probably be easier to make it game specific as the requirements are simpler / more straightforward than trying to generalize it to "all possible applications" for input, i think gluon has been working on that. on touch devices, games like kpat or mahjong play well. games like kgoldrunner not so much, but a virtual joystick or even using the accelerometers would be an option. to keep it generic enough to work on different devices, i can see the need for: * a "show the management chrome" event. this may be a special hardware button on some devices (while the game will play full screen the rest of the time), or a hotspot on screen, or a key combo or ... by keeping that a platform detail, the games can work without caring about it and just using that generic facility * chrome manager: give a list of actions and some structure for them, display them in a platform relevant manner. i really don't have much insight into what the needs will be here, specifically, but looking at the games it seems like it's mostly a fairly stock set of things like "new game", "configuration", "set up network play", "give me a hint". things like hints may appear on- screen in a standard location all the time even on touch devices, while the others may only be shown when the "show the chrome" event occurs * abstracting out input. this is something that i'd suggest borrowing from gluon as a lot of work has been done here. other than that, laying down some basic ground rules for game UI would be helpful: all items must be scalable; density of items that must be controlled by touch must not exceed a certain threshold (so that they can scaled up large enough on smalls screens), right / middle clicking are not allowed as valid input mechanisms, etc. > Not only am I interested in your thoughts on how such interfaces (or > library classes) might look like, I'd also like to know whether there are > existing components which might be reused. From what I know about Plasma > (and that's admittedly not as much as I would like), Plasma is too > high-level for what I need. It's not about creating applets for different > services, but about arranging buttons and score displays. But please, > correct me if I'm wrong. as Marco noted, while some parts are indeed not relevant for games, some parts such as the Svg painting and caching system or the DataEngine/Service framework are generally useful. it's also possible to write games as plasmoids and run them in a window. bonus is that we'd get the ability to house all games in a plasma shell, which could be nice on mobile/touch devices for integration purposes. for games that are already QGraphicsView based, this should be relatively trivial. for others, it could be a lot of work. the benefit of this would be that all kdegames would be able to use things like the Svg theming system and the Plasma themable versions of pushbuttons and what not for free. i'm not sure if there's enough value there to do this, but there could be. if a DataEngine/Service was written for the highscores thing, then it would also be possible to provide regular plasmoids that show top ten lists or alert the user of people looking for games to play without having a game actually loaded. a little "looking for games" plasmoid that sits in my panel which i could turn on and say "tell me when someone wants to play BattleShip" would be awesome, for instance. this really wouldn't help the primary purpose of "making and displaying a game" but it could improve the overall experience for the user while giving access to some nice bits and nobbles in libplasma to kde games. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
