Skip to content
QtWS25 Last Chance
  • 0 Votes
    4 Posts
    589 Views
    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
    545 Views
    A
    @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
    510 Views
    SGaistS
    Hi, You can open a feature request to discuss that matter.
  • 0 Votes
    2 Posts
    2k Views
    Pl45m4P
    @mingvv 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. https://doc.qt.io/qt-5/model-view-programming.html 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. https://doc.qt.io/qt-5/signalsandslots.html 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: https://doc.qt.io/qt-5/graphicsview.html 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
    719 Views
    jeanmilostJ
    @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: https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ I also corrected my post, thank you very much
  • 0 Votes
    7 Posts
    1k Views
    SGaistS
    You can create custom views if you want. See the Chart Example
  • 2 Votes
    2 Posts
    955 Views
    K
    Waiting for guide "How to avoid JavaScript models in Qt and why should you care" (performance, memory usage)
  • How to architect a Qt/C++ Application

    Unsolved Announcements architecture structure
    7
    1 Votes
    7 Posts
    10k Views
    SGaistS
    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.
  • Model View with nested lists

    Solved General and Desktop modelview architecture qlistview
    6
    0 Votes
    6 Posts
    4k Views
    SGaistS
    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
    1k Views
    P
    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!!! NEVER EVER!!! 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.