How can one have smartphone/tablet -like GUI on a Raspberry Pi? - c++

I'm planning of developing an application which will run on a Raspberry Pi 2 equipped with a touch-screen, and it should have the look and feel of a smartphone/tablet application.
This means especially that the list views and other scrollable widgets should scroll via touch gestures, and not by clicking on narrow scroll-bars on their side. Also, a simulation of momentum (widget scrolls a little while longer, with gradually lower speed, if I scrolled it fast enough and let go of the screen) should also be applied to all scrollable items.
I would prefer to develop in C++, and as I'm used to Qt, it would be preferable as well.
However, the Qt widgets are designed with a PC in mind, so they don't scroll with hand gestures and they have no simulation of momentum.
Of course, I could derive my own classes from the Qt classes and implement these features myself, but it would be much simpler if such GUI classes already existed.

You can use QML for build GUI if you want to look like mobile. Here and here you have how to integrate QML with C++ objects, so you can implement your logic by C++. In QML you can use TableView which can be scroll via touch the table.

Related

Are VCL ListViews ListBox DBGrids full touch aware?

Since we have tablets with Windows 10 I have decided to use again Delphi XE7 and VCL to develop for this multitouch devices.
I have found ListView, ListBox and DBGrid seem not have a standard behavior with pan and scroll (just PanUp & PanDown, ScrollUp ScrollDown). DBGrid does not support touching panning. ListBox, seem doesn't control inertial panning like TListview... and ListView react erratically, sometimes "loose" pannings moving scrollbar but not items list.
Have someone tested this controls on Windows 8.1 or Windows 10 using a multitouch tablet ?. Just load components with, let me say 100 items and try to have a simple vertical smooth scroll / pan using fingers.
All together is kind frustrating, and I cannot focus in develop application which is my task.
Question is: Which is the right component or way to use panning (at least vertical panning / Scrolling) with touch screens and working smooth and without problems ? I thought this components should react to standard actions (like PanUp or PanDown) without need to implement the Gesture Manager and control one by one each touch on screen. I would like to receive your kind feedback. Thank You
Conclusion: Many thanks to all who have helped with their comments. My own conclusion is Delphi is not ready to be used as a RAD for touching screens. The touching implementation is poor and need too much work for very standard using. Should not be necessary invent the wheel again for a very common and standard controls. Actually there are more mobile device users, than desktop users. Perhaps Embarcadero should decide to pay attention to this matter, and give well finished tools wich meet the OS touch and feel controls.
Let me add the same in FM using TGrid works fine.

Qt - effects on no-opengl widgets

i wanna make some nice user interface, but still using just classic ui elements from Qt.
For instance i have 2 forms and i wanna make some transition between them. For instance rotate first ui screen and make it disappear. It's possible in some way to use shader? Is any way how to do complex ui animations with classic ui elements?
Qt has a whole animation framework. It works on both the QML widgets and for the classic UI elements that you're using. There's some examples of use here, that should be able to get you started.
The simplest way to do it would be to use the Qt Declarative a.k.a. Qt Quick 1. It's based on QGraphicsScene, with the latter offering a reasonable way of integrating legacy widgets. It'll be likely the simplest way to offer animations with widgets.
You may wish to see an overview of GUI technologies available in Qt 5, to see how Qt Quick 1 fits in.

Simple library to display 2D images in C++ on Linux

I would like to have a tool to debug 2D planar meshes. I would like to be able to display them and debug to be able to debug certain things.
Is there a widget (for any toolkit on Linux - QT, GTK+Cairo, ...) which would display the images, scroll them and zoom it. Is there any widget which would handle it (without need to implement zooming, scrolling etc. by hand)?
Side requirements:
Needs to work on CentOS 6
I need it for C++. Unfortunately changing the build system in my situation is harder then it sounds.
The Qt Graphics View is certainly a useful tool, it gives you scrolling, zooming, rotating easily. You probably want to learn the basics of Qt before. (and Qt is in C++).
Here's an off the wall suggestion.
This would be fairly easy to implement in a web browser. Web browser engines already have the base functionality for resizing and scrolling over images. You may need a little JavaScript to bind it together, of course.
So why not use WebKit? There are bindings for many of the leading toolkits (e.g. QWebView for Qt), so you could take your pick of which one you're most comfortable with.
Yes, it's overkill. But it's code you don't have to write, and time is money.

Common game controls/ User interface libraries or source code?

Sorry for the ackward title, but i don't know what to call it exactly. I'm looking for code or libraries that allow easy creation of commonly used user input devices, and code/libs that make gaming controls easy to set up (i'm using SFML and Box2D at the moment)
I don't want to re-invent things like buttons, arrows being placed wherever the mouse is located, and more game specific items such as "controls settings" or even being able to drag objects around with the mouse.
More specifically i want source code for interfaces that....
Makes Buttons and Textboxes easy to create
allows mouse input to press buttons or drag objects in games
has "Focuses" (like a textbox being able to gain focus and be typed in)
Is compatable with SFML/Box2D
and code for common game mechanics/controls that....
Allows easy setup of controls for a game
Makes events like clicking and holding on an object easy to setup, as so objects can be dragged around afterward
Are there any simple libraries or resources out there that i can use to avoid spending much of my time coding these now standard input devices/tecniques?
I think CEGUI is the type of thing you are looking for:
http://www.cegui.org.uk/wiki/index.php/Main_Page
It is a GUI framework to work with OpenGL. Some others can be found in this list.
Still, if I were you, I would just use a major toolkit, such as GTK, Qt, or wxWidgets combined with SFML instead of dealing with CEGUI.
SFML has guides for Qt and wxWidgets with the rest of them at http://www.sfml-dev.org/tutorials/1.6/.
I have created my own little guide for GTK here: http://lalaland.github.com/gtkGuide.html

Is QML the way to go if designing a game in Qt?

Was looking into making a game with Qt and was wondering if QML has gotten to the point yet where it could be used as a serious tool on the desktop. Have seen some post from Qt stating that they will be transitioning most things to QML eventually, so this seems like it may be the way to go, at least according to Qt.
Edit: I realize that QML probably wouldn't be the best bet for a 3D game with heavy graphics. Was looking more for something that did mostly 2D stuff like a platformer type game.
Seen this http://labs.qt.nokia.com/2010/08/12/a-guide-to-writing-games-with-qml/. So its obviously possible to some extent. I have also seen some impressive games made solely with java script, which I believe is the base of QML. I was just curious as to what would be the best way to go with Qt at the moment since things have been changing lately...
It may depend on "how long" you want to wait before releasing your game.
The Trolls/Qt are re-doing its "graphics stack" right now: Rather than historic "every-widget-renders-itself" (which is the wrong paradigm for games and rich mobile apps), they are re-implementing to a single graphics stack that renders the WHOLE interface, where the "widgets" themselves are mere data-sets that feed into the rendering. In short, the goal is to make desktop/mobile applications with the exact same performance as the high-end games have done for decades (with their own graphics stack that looks nothing like the typical X/Xlib/Motif/Xvt/Win/MFC/Qt applications graphics stack). Further, the Qt5 plans (in planning/development now, they claim a release sometime next year) are reliant upon OpenGL for this graphics stack implementation.
After this work, the pipeline will be: Widgets==>QML==>(C++ Graphics Stack)==>Hardware. Currently (Qt 4 and previous) it is: QML==>Widgets==>(C++ Graphics Stack)==>Hardware.
You can google for various posts/discussions on this, or here's a long-ish presentation that talks about these efforts: http://qt.nokia.com/developer/learning/online/talks/developerdays2010/tech-talks/performance-do-graphics-the-right-way/
IMHO, QML makes more sense for games, since the interface components are "independent actors" (e.g., not tied to each other through layouts). That's also why QML makes so much more sense for mobile (where real estate is a premium), and for very flashy desktop apps (although it is still relatively young and unproven for that).
QML already has lots of rendering/animation options, but they are mostly a very rich 2D (but with which you could simulate 3D pretty well). The QML 3D is undergoing heavy revision right now, but the new stuff looks really good (and sits on OpenGL). So, if you want heavy 3D, it might be experimentation time for the moment, until you see the new Qt5 interfaces and can take advantage of the hardware acceleration (depending on how much 3D you need).
The performance specs I've seen from the new Qt5 stuff with the new graphics stack (in prototype development) are quite impressive, so much so that I've been thinking about writing some games in QML just to play with it. If this were twelve-months-from-now (or so, after the release of Qt5), I'd bet QML would be the best/easiest decision for games (because the components are independent actors, it's so simple to use, and I'd push all the game-specific heavy stuff into C++, which is really easy to do with QML on top).
QML is definitely a viable option for designing 2D games and can save you a lot of time and lines of code.
V-Play (v-play.net) is a cross platform 2D game engine based on Qt/QML with many useful V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
If you are curious about the games made with V-Play, here is a quick selection of them:
Squaby: a tower defense game
Chicken Outbreak: a platformer like Doodle Jump
Blockoban: puzzle game
Crazy Elephant: a game similar to Angry Birds
Snowball Mania: multiplayer action game
Blitzkopf: brain game
Remember that QML is only designed to lay out the UI. Fundamentally, it acts as a QGraphicsView with lots of utility functions (code in QML is at least three times shorter than the Qt/C++ equivalent, at least, that's how I felt it)
The core of the application is still handled by either javascript files (if things are not too complex) or C++/Qt files (if you want the full extent of Qt possibilities)
As Jeremy Salwen said, for a game that looks like a smartphone app game (big sprites that move with nice transitions, with simple logic behind it), then QML is more than sufficient.
But if you want something complex, then you will end up using in QML only QDeclarativeItem classes that you will have previously defined in C++. Not that useful.