Skip to content
  • 0 Votes
    4 Posts
    Chris KawaC

    @Saviz Sorry, I don't know such article. But basically create a settings object and store the settings in it instead of in widgets classes.

  • 0 Votes
    3 Posts

    @dynobo Starting a reply with " I am in same boat" is a cliche and it does not help (you) .
    I have half a dozen "objects" passing messages - both directions and using "emit" and "connect".

    I am using GUI / tab to keep track and of course QDebug.
    It is not ideal ....

    I was going to add old fashioned flowchart ( text or GUI ) , but got sidetracked....

  • 1 Votes
    2 Posts


    You can open a feature request to discuss that matter.

  • 0 Votes
    2 Posts


    First, you should understand the basics of C++ and object-oriented programming in general. Without it's really hard to get a satisfying result and you will spend most of your time looking for things or trying to figure out how things work (or why they don't).

    Qt also has Model-View based classes.

    You can communicate with your GUI or other QObject classes using the Qt signal&slot system or using events.
    For example if you press a button, you will emit the clicked signal. Then, if you connect a slot (= function) to this signal, the function will be called to perform some actions.

    A (simple) snake game in Qt might be a practice to start with. Think about what classes / structure you will need, design your GUI and start writing your code :)

    Might be helpful:

    According the "GUI Code vs Designer" thing:
    It's mostly a mix of both. Some things just can't be done using the QtDesigner, but it helps a lot creating your basic widgets and your basic design.

  • 0 Votes
    3 Posts

    @SGaist said in Qt and next Apple generation:

    You are 14 years late, Apple has ditched PowerPC for Intel in 2006.

    I mentioned the previous technology to describe the current Apple architecture, please forgive me. I wrote this question just before going to weekend, and I was quite tired. What I mention above is described in the following article:

    I also corrected my post, thank you very much

  • 0 Votes
    7 Posts

    You can create custom views if you want. See the Chart Example

  • 2 Votes
    2 Posts

    Waiting for guide "How to avoid JavaScript models in Qt and why should you care" (performance, memory usage)

  • 1 Votes
    7 Posts

    The controller concept is not specific to the MVC. MVC uses one of its incarnation.

    You can have a controller class that does the abstraction and handling of the lower level bits of you application while your GUI connects directly to it happily ignoring the gory details. No model required.

  • 0 Votes
    6 Posts

    Technically you have a two-level tree.

    You can still use that example as a base. In place of their custom TreeViewItem you have your Parent and Child.

    Those the abstract model would be a wrapper around your Parent/Child combo.

  • 0 Votes
    2 Posts

    Hi there,

    I have some experience in software development (about 30+ years or so), and never ever was your question leading...

    First choose what devices your app should be running on
    Then decide if your app has enough "reusable" things to even start thinking about models
    If not, don't use any model at all! It will only cost you more time. Don't let the "hype" trick you!

    However, if ur app is supposed to work on several different devices, and the output of your app may be in different kinds of forms, THEN, and only THEN, start thinking about how to generalize the view of ur app to the different kinds of users...

    And also ofcourse, If you plan to make many apps, some parts may be common. And Yes, in that case you start worying about reusability.

    But NEVER!!!
    Worry about UI, before u have thought about ur app first:

    What it should do

    How it should do it

    What UI should be the LAST of ur problems...

    Now, having sayd that, there is always "Prototyping" to engage the end users in the look and feel of the app in as early a stage as possible of course, but it NEVER should be leading to a change of architecture.