I am implementing a Desktop Qt application which uses an XMPP library to chat. I am trying to find the best approach in terms of performance, easy to modify, add custom stuff (for instance, show a thumbnain if someone sends me an image)...
I would like to know which approach do you think is the best:
- Each element as a layout or widget and add them one by one (it seems to be slow)
- ListWidget items overloading paint event (problem: don't know item height before painting)
- Use a rich text widget and build the chat as a HTML page (didn't tried it yet)
- ??
Best regards,
QListView would be good for simple IRC chat. If you are planning to implement some advanced text styling (different fonts, etc.) or images (like you said) WebView is the way to go. Additionally, much simpler way than QListView.
There's even an example Qt Google Chat project which uses QtWebKit: http://harmattan-dev.nokia.com/docs/library/html/qt4/webkit-googlechat.html
I would go for QListView with model attached and custom delegates etc..
Related
I have found a really neat custom widget for Qt and managed to incorporate it into Qt Designer. I would now like to create a customer widget in designer by placing 32 of these LEDs into a new widget in Designer, then add some functions to it such as giving it address and passing data into it that will then illuminate patterns in colours according to the passed data.
My questions are:
Can I do this? I have placed 32 LEDs on to a new QFrame widget in designer and named the LEDs 0-31, but am at a loss as to know what to do next.
Is there a tutorial anywhere for this? I have found loads of hits on google for creating custom widgets for designer, but not using designer.
Please bear in mind I am not a good Qt programmer, I write embedded code for micros in C and am really not good at object orientated code; I can just hack together relatively simple programs for test and measurement. I need something that will hand hold me through this.
http://doc.qt.io/qt-5/qtdesigner-worldtimeclockplugin-example.html
This seemed to be the kind of thing I wanted, it seemed to look like someone has placed widgets on a screen to create a new widget, but it seems to keep referring back to Creator.
Maybe I am trying to do something impossible. Maybe I have to place this new LED in creator with code?
Many thanks for any pointers.
Yes, it is. A Designer plugin basically consists of 2 Parts:
The Widget that you want to add to the designer
The plugin itself that provides information about the widget usw.
You can simply create the widget with the designer, add the QDESIGNER_WIDGET_EXPORT macro and thats it. Create your designer plugin to load this widget and it should work.
Note: Since you mentioned your not very experienced, you should try to follow the Custom Widget Plugin Example. Once you understood that one, it's only a small step to your designed plugin.
The question is: Is it a good practice to use SpriteVisualElement instead of UIComponent to create custom components? The reason being I can't add Sprite or FlexSprite as direct children of View and I see that UIComponent is quite heavy then SpriteVisualComponent from code point of view.
I searched extensively to confirm if there are certain examples elsewhere which shows use of this control as the base to create custom controls but could only find this. So actually I was little less confident about weather this is Ok or not.
Below is the supplement information:
Nature of application: Educational game application for children
Target platform: Mobile device (currently only Android platform)
Application environment: Flex SDK4.6 with AIR 3.8. Blank Spark application with spark.components.ViewNavigator. PureMVC framework used. Multiple Views to contain custom components which mostly use graphics package to draw themselves and to draw child controls within them (This is where I actually extend SpriteVisualElement for custom drawing as well as containing and displaying other custom controls).
Please suggest me if what I am doing is a good practice for a mobile app or not.
Thanks in advance and regards,
Sachin.
I use it often as SpriteVisualElement is lighter. I always try to use lighter things if it's fit my needs so I think it's a good practice especially for mobile development.
I am not an expert but I have been using Qt/QtEmbedded for sometime now, for SBC 6845. I have created a few applications and have successfully run them on my device.
Now I want all of those applications to appear on a home screen. I understand that using QML/Qt Quick this might be achieved, but I don't have any idea on how to proceed with it. I have gone through some links and tutorials but most of them show how to create buttons and all that with Qt Quick, but not much than that. I am yet to find some tutorial/docs which can point me how to proceed with all applications on my home-screen. I need some directions, any links, advice on docs/books is welcome.
[While cross-compiling the QtEmbedded 4.6.2 libraries for my SBC I encountered problems with enabling opengl support. And, I am unaware of the other methods for using QtQuick2 without opengl.
The applications (5-6 of them) are QWidgets and linking icons require to stay in the home screen. I want to keep them as simple as possible without any effects for the icons.
Plainly speaking, I am trying to create a bunch of icons displayed on the home screen linked to those applications. The applications if launched in windows style application, (or like a popup QDialog) will also serve my purpose.]
Thanks.
"I have gone through some links and tutorials but most of them show
how to create buttons and all that with Qt Quick, but not much than
that"
For this part of the question, I'd advise you to download QtCreator
and start playing with the demos (using more than just some buttons:
you have demos for ListViews, GridViews, Delegates, Animations,
Particles, QtQuick Layouts (Qt5.1 only), QtQuick Controls (Qt5.1
only).
There's also the rather complete :
http://qt.gitorious.org/qt-labs/qt5-everywhere-demo
I'm completely unfamiliar with all the embedded/cross-compiling
aspects of your question.
About OpenGL/QtQuick2 : http://qt-project.org/forums/viewthread/30483
http://qt-project.org/forums/viewthread/17201
Also note that you can embed QtQuick2 scenes into a QWidget, but not
the other way around (no QtWidget inside the scenegraph).
So maybe the easiest/fastest way to go for you would be to stick with Qt4 or Qt5 declarative/QtQuick1 module (might be deprecated/removed starting with Qt 5.2). In this setup, there is no scenegraph/mandatory need for OpenGL. And you can embed QWidgets into your qml scene (no scenegraph: it uses the QGraphicsView backend) via QGraphicsProxyWidget.
You'd then have some GridView (you also could use some Grid with a Repeater) filled with models and delegates (= a delegate acts as a template item to be filled with the model).
Your delegates would have states/maybe Loader(s) (for on-demand loading) : icon state and when clicked, some maximized state containing a loader, loading your widget through QGraphicsProxyWidget.
You already have half of this presented in this example (a grid + 2 states : small icons grid and maximized view, you only need to implement the delegate/loading/model/QGraphicsProxyWidget things):
http://developer.nokia.com/Community/Wiki/Implementing_parent_change_animation_with_QML
I just wonder what will be the best solution for receiving text input from user in PlayN.
I didn't find anything that i can use to achieve this, i think that the best solution will be to render something like HTML inputs to write a text, but it will be not that simple because we need to be able to use in example virtual keyboard from android (on android platform) and regular keyboard on HTML backend. Even then i think it will be very difficult (or impossible) to evoke android keyboard in game...
I'm thinking about creating a widget in tripleplay UI library (because i will use it), but this will end with rendering virtual keyboard on screen for user inputs.. buttons from a-z etc...
I wonder is there any better solution for this, or i need to implement something like i wrote above (like tripleplay widget)?
There is already a Tripleplay widget for receiving text input called Field.
However, it is very primitive and does not yet work on mobile platforms (it will work on an Android device with a hardware keyboard). We need to provide an API in PlayN to display the virtual keyboard, but until then there's no way for it to trigger the display of the virtual keyboard.
I don't recommend using this for any substantial text input, however. It doesn't (and never will) support cut and paste, or language input methods, or anything of the other extremely complex features that users expect for text input.
I would like to add an API to PlayN like:
Keyboard.requestTextInput(String label, Callback<String> callback)
which would pop up the virtual keyboard, with an attached (native) text box, and allow the user to enter a single line of text using all of the machinery of the platform's native text entry support. This will allow them to cut-and-paste, and use language input methods, and provide an experience with which they are comfortable on the platform in question.
If your game needs more sophisticated text input (like a chat interface, or the ability to take pages of notes), you will probably have to create a separate interface for each platform that you wish to support, using native multiline text editing widgets and then "wire" those into your PlayN game. This will be more complicated than can be described in a simple SO answer, so you'll have to do some research and learn how PlayN manages the display on each of the backends that you wish to support.
I wanted to consult with the sages here regarding Qt and skinning, get your opinion and chart a path for my development. My requirements are as follows:
My Qt/C++ application (cross platform with Mac, Windows and Linux versions) needs to have modular skins.
A skin is defined as a set of one or more elements: - Window background texture - Look/feel of UI controls such as edit boxes, drop down, radio buttons, buttons etc. - Look/feel of window "caption", resize grips etc.
Skins will be installed with the application installer, allowing the user to choose which one he/she wants to use. Users should be able to change skins on the fly.
Can I go the QML route? should this be custom and based on simple resources which are built into the application? Any design advice will be appreciated.
Thanks.
If I understood you correctly then stylesheet is the best way forward. You can create stylesheets similar to CSS and then pass them as command line option to your application or load on invocation to style your application at runtime. That way you can create multiple stylesheets each having a different look and feel and allow user to load them at will. Since its CSS it doesn't need any new learning and you can keep all your styling outside your source code.
Here are a list of resources that can get you up and running quickly:
http://blog.qt.io/blog/2007/11/27/theming-qt-for-fun-and-profit/
http://doc.qt.io/qt-5/stylesheet.html
I haven't played with QML yet, but you could also create a custom QStyle implementation that supports your resource format. Note that you'd lose style sheet support if you went this route.
Changing window captions is a little trickier if you want portability.
QML, if I understand correctly, doesn't really skin the widgets, it mainly deals with GUI layout etc etc.
QStyle is used to change the looks. It is a bit low-level though, and requires programming, so if you want to load different user-created skins (from an XML or so) it might be tricky to support extensive skinning. Chaining colors and a few items are easy enough though. (There might be someone else who've done something you could re-use.. not sure.)
For modifying widgets, use QStyle::polish(). You could use that to change the background picture (if it's a top-level window, or of a certain class). There are numerous repaint method to change almost every part of every widget.
Store/load the style using QSettings, by reading and setting the desired Style just after QApplication but before your main window is constructed.