Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am constructing a custom UI with Qt 5 an MVC using QML/C++ and I am wondering how to structure the code in regard to what to put in C++ and what to put in QML. The purely visual parts (view) will obviously be put in QML and the data (model) in C++, but what about the parts that aren't that clear? Should I lean towards putting things in C++ and try to reduce the QML code somewhat, or is it better to lean in the other direction, i.e increasing the QML code and reduce the C++ parts? I have not worked enough with Qt/QML to be able to know what is the best way to do this.
Both parts are perfectly feasible imho, but it would take a lot of effort if I need to change this afterwards and therefore I want to get this at least somewhat right before I begin to create a lot of code.
What are your experiences in this when designing QtQuick interfaces? Do you design components mostly in C++ with a thin QML interface on top or the other way around? What are the pros/cons for each solution? What is the preferred way to structure code when designing a UI in QtQuick?
Here's my two cents worth. This applies to Qt version 5.1 (ish)
QML was designed to implement the UI. So I've designed those parts that do the visual implementation in QML. Some UI elements can't be done well in Javascript so I do "helpers" or views in C++.
I'm using model/view for data display. All the models are implemented in C++ (I used sqlite databases for my last application).
QML is still a work in progress so if you stray too far from standard telephone interfaces there isn't much implemented. The standards for UI behavior you expect from desktops aren't present at all.
Good luck!
Ideally make your models and controllers in c++. Use QML for the view.
Inside the QML view you can rather easily incorporate components written in C++ (there is a plug-in system and an API for visual and non-visual C++ components to integrate well within QML)
QML performance has improved a lot in Qt 5.1+ with regards to UI rendering, but you should limit the amount of logic you do in javascript (inside qml).
What QML excels at is declaring what the UI looks like and how it should be connected to signal and slots of the controller, if you end up writing convoluted logic inside your qml files, you are probably doing something wrong.
PS: there are several big open-source project that use QML, you can find them on github. You could use them as style guidelines.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I’m building a maze game in C++ and I’m trying to use shapes to identify characters in the game i.e. walls as squares, triangles as enemies and a star shape as the player. How can I print such elements in the console cmd? I have been researching a lot on http://msdn.microsoft.com/en-us/library/windows/desktop/ms682073%28v=vs.85%29.aspx but I’m not able to figure it out.
If there isn’t a way then is it possible to print an svg?
There are several solutions to this problem, each with its own drawbacks and advantages.
Emoji (or more precisely Unicode)
This is my recommendation for simple games and shapes as it is the most simple to implement and relies on the underlying console to do the heavy lifting. Also how the other program was most likely written (though with other characters than listed here)
Since the windows terminal (and linux/macOS) supports Unicode, it is possible to use unicode characters such as 🔲, ⭐, and 🔺 to represent characters.
Note: you may need to enable utf8 support with setlocale(LC_ALL, "en_US.utf8"); in cpp
Pros
Simple to implement
Doesn't rely on external libraries
Cons
Confined to the standard text alignment
Hard to resize
Need to clear characters manually
What happens if the console is resized or too small?
ConPTY
Similar to the console approach, though this gives the advantage of more colors and the capability to set console size, etc. by the program.
Pros
Color support
Ability to control the terminal more simply
Cons
Still need to choose another method to actually print
Requires Windows 10
Console
This is takes control of the console windows. You should use a library such as https://github.com/Bill-Gray/PDCursesMod to abstract this method.
Pros
Capable of full control without leaving the terminal
Less resource intensive than a full window
Cons
Complex
Windows
You can use frameworks such as Qt and co to implement a window environment. This approach gives the most flexibility, though at the cost of complexity, with at least a couple months of development time (from scratch), though this issue can be overlooked with the proper framework/library.
Pros
More common nowadays
Most control
A number of libraries are available for games already.
Cons
Most resource intensive
Hardest to implement from scratch
Not terminal based (though you can make it seem as though it is)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
(for a custom engine) Just a simple question, I was wondering if there was an advantage adding a child this way:
`myNode.transform.parent = newParent` // unity like
instead of this:
`myNode.transform.AddChild(newChild)`
Or is it just a matter of preference.
For my part I find it weird that a setter will do background stuff for example deleting himself from its previous parent children conteiner.
Thanks !
They may be using an AddChild method in the C++ backend to make the addition.
Unity's core engine is written in C++, C# is merely the scripting layer that they use. Unity registers their backend methods to front end methods and properties. When somebody uses that property or method, the backend implementation is called instead. This isn't the case for all of Unity's stuff, Unity's UI is predominantly C#, and it's open source to, in case you're curious:
https://bitbucket.org/Unity-Technologies/ui/overview.
Here's an article that may clear up some aspects of which would be best to choose, although in practice, it usually comes down to preference:
https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx
In general though:
methods represent an action, properties represent data.
Another user asked a similar question: Properties vs Methods
Take a peak if my answer doesn't clear it up.
Also, in case you're curious about how Unity calls its backend methods, this may clear it up: https://github.com/mono/mono/tree/master/samples/embed
Hopefully this'll help.
The other answer is really good but I just wanted to add a little bit of an explanation to why you would use addChild(...) or .parent = ....
It basically comes down to how you build your code, if you do the parent instance then when it is drawing its location, it can just get its parent and then draw it relative to that parent.
Where as if you did the addChild(...) system then the parent has to tell the child where its location is (or you have to have a link anyway to the parent) to draw it relative.
That is just one reason and I'm sure there is plenty, but it does mostly come down to preference.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am writing a game in Cocos2D-x and I am struggling with feeling like my OO is sloppy. I can't shake the feeling and I can place m finger on why.
Game Scene class
In This a Layer is created
Layer Class
responsible for creating itself
Also calls HUDS when needed
contains std::vectors of objects on the layer
Object Class
hold everything about itself
has a sprite member variable that is on the layer
HUD1
called when the user taps the layer and the touch even occurs in the Object
is a Menu of things that you can do to the Object
When you click a menu item it needs to change values in Object
When you click a menu item it actually runs code in Object (object::doSomething())
What feels sloppy I think is that there is a lot of dependency on these classes together.
I feel like I should abstract this out and create a class that controls all of this happening instead of some code in Object, Layer, HUD, etc.
Can anyone talk to me about how this is laid out and if I am making an OO mistake?
As it turns out graphics and games do not fit into OO designs very well despite being an example in many OO texts. Your instinct is right with respect to decupling the control from the data. A popular design pattern for games these days is to have components, entities, and systems instead of a rigid OO hierarchy.
The idea is that you have Entities or GameObjects that are just collections of components and perhaps some messaging infrastructure. Components store data about the Entity they are attached to, for example you might have a Transform component and a velocity component. Now one approach is to have a messaging system that components can hook into and use that to update their data. For example a Velocity component might hook into the Update message and in the Update handler it could get the transform of the object and move it. By using messages for all communication between components you can decouple them to a large degree.
Systems are a different way to handle updating component data. The idea with Systems is that you have a process that can say "I operate on entities with these components" and then it gets a list of all of the relevant entities when it runs. This decouples data from function even more and can make it easier to manage threading and dependencies
Essentially object oriented design is about capturing "what things are" in the real world, but with a game you don't really want that, all you care about is what things look like and you would like to be able to change the individual facets of something's behavior without pain.
Good resources for Entity-component systems:
http://piemaster.net/2011/07/entity-component-primer/
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Have a think about what you are trying to achieve before trying to dive in to code (even though the urge to do this is very strong!)
Try to decouple your classes by using Dependency Injection. This may involve adding a bunch of extra classes and complexity now, but trust me, it will make your life much easier later on when you will inevitably need to refactor certain parts of your game. Avoid using 'gum and duct tape' solutions as the technical debt you will incur by doing this will come back and bite you later!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just stumbled upon Adobe source libraries, ASL. It is set of templates and functions similar to boost, under MIT license.
Some of the utilities in the library I found quite useful and now I consider using it.
the library seems pretty straightforward, however.
Have you used ASL yourself? if so, what were your impressions? do you recommend it?
does it work well with a range of compilers and platforms e.g. IBM C++, ICC, g++?
have you encountered quirks/unexpected things?
thanks
ASL uses Boost heavily, so it's not such similar to Boost, as (in some cases) a relatively thin wrapper around Boost.
The "big" pieces of ASL are Adam and Eve. Most of the rest appears to be (and if memory serves, really is) little more than support for those.
ASL hasn't been updated in a while, and if I'm not mistaken some of what it provides in wrappers around Boost has now been incorporated into the Boost libraries themselves (most Boost authors have been aware of ASL at least since they featured in Sean Parent's keynote presentation at Boostcon 1).
My own experience with them has been somewhat mixed. At one time, I used a couple of their Boost-wrapper classes a bit, but IIRC, within the next release or two, the bits I cared about were available in Boost without any wrappers (though offhand, I don't remember exactly what those pieces were...)
Adam and Eve are kind of cool for playing around with different UI layouts and such -- but I've never used them for a finished version of a program. At least to me, it appears that they're useful primarily with a relatively complex UI. My impression was that if you find them very useful, your UI probably needs work. If you need Adam and Eve to help understand what's going on, chances are your users can't figure out either.
OTOH, there are probably at least a few cases where a dialog is clear to a user, but the code much less so to a developer. If you do a lot of disabling some controls until values have been entered in other controls, and such, it can make it a lot easier to ensure controls are disabled until all values they depend upon have been entered.
As already noted, thew whole point of ASL is Adam and Eve, the rest are just handy tools.
Adam & Eve work together to describe UI with auto-layout in a cross-platform way.
If this is not what you need, then you should probably not spend much time on ASL.
Eve has the typical collection of vertical/horizontal/other containers for auto-layout.
And scripting with Adam allows you to achieve things difficult (if not impossible) to achieve just with layout containers (things like keeping separate groups of controls the same size, for instance).
True, you implement some of the rules in your C++ code. But it makes sense to store the UI description rules related to UI behavior in the same place where you store the UI to begin with.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Has anyone seriously used Wt?
Did it work well?
Did you experience certain limitations? Or advantages?
Wt is a C++ library for developing web applications.
Please avoid the discussion of whether C++ is a good language for web development. I just want to give Wt a try because it seems like it could be a fun thing to do.
I've been using Wt to build apps that directly link to C++ libraries but don't particularly make a lot of effort to exercise the layout features such as CSS. So far, it works great as a replacement for GTK when building these kind of applications. I'm a Linux user exclusively and I'm also one of the unwashed heathen who actually enjoys programming in C++, and this framework is a perfect way for me to build an application that can actually be used across many platforms.
I have not personally used the framework, but have discussed it with a few people that have. They didn't really have any limitations, but I found it hard to believe they were compiling every time. Their main comment was that it was quite a light load on the server in terms of memory usage. Personally, I think the interpreted languages of php, python, ruby, etc work well with the nature of web development - but that's not the question you asked. Probably the biggest advantage is being able to use your existing skill set to work in a new medium.
There are also a few good comments online discussing pros and cons. Here is one I found http://discuss.joelonsoftware.com/default.asp?biz.5.599655.33
However, I think the main answer here is that without a specific project requirement in mind, it is going to be difficult to evaluate any framework for suitability. If you think it will be fun to try coding a few things with it, then give it a go. That is going to be the best (if not only) way to determine if it suits your needs.
I have tried several C++ embedded web servers. They tend to be a challenge to use, and not Windows friendly.
( You do not mention your platform. If you are on Unix, then I suspect you will find the available servers easier to use, and can probably ignore this answer. If you are on Windows, read on ... )
I have tried Wt, but was defeated by the massive installation, which takes hours to compile and generates page after page of warnings, and the extensive learning curve. Wt is modeled on Qt, so if you are familiar with Qt, the learning curve will be much less of a challenge.
I have tried Webio by John Bartas I liked the concept and it worked well. However, I found it overly complicated to use and the server code hard to understand. A lot of the complexity of Webio is caused by using an “HTML compiler” to hide the HTML pages that control the appearance of the GUI inside a file system embedded inside the application code. I prefer to have the HTML pages outside in plain view where I can adjust the GUI without recompiling the application.
I have also looked at TWS This is by Richard Hipp who is responsible for SQLITE and FOSSIL and of whom I am a great fan. However, TWS has not been maintained since 2001 and is not really WINDOWS, so I reluctantly decided not to pursue it.
In the end I rolled my own, called WEBEM based on a minimally modified version of the boost::asio web server. In concept similar to, but simpler than TWS, it permits html code to execute C++ methods.
To be honest, I had looked on it but I see one significant Wt design flaw -- it modeled after Qt. Trying to make web applications to look and behave like GUI.
I think, this approach is wrong. There should be clear separation between client side and server side.
If you are interested in C++ web programming take a look on CppCMS which has more traditional MVC model.
Note, I have biased opinion, because I'm developer of CppCMS.
Made a todo list app using it. works great, no problems.
I currently use it to develop a GPS measurements processing web application, based on processing algorithms implemented in C. It works well and has a good synergy with legacy C/C++ code.
It's documentation its not so extensive and the lack of learning tutorials and related books makes it somehow hard to learn.