A few design questions...
-
[quote author="mzimmers" date="1301510263"]
any general comment on how this sounds so far?
[/quote]
Sounds as a nice project! Mayby you can check how matlab, spice or other electronic simulations look like.
[quote]in my proof of concept, I created a class for the IC and gave it a widget for the GUI. The widget displays the two output variables for the only component I've put in the simulator for now. Am I going to create a widget for each class that I want to display? (Seems reasonable).
[/quote]
Mayby you can simplify your classes with:
1 class for input, 1 for output, 1 for the internal clocks and 1 for the internal process(whatever that might be). So you have only 4 or 5 "widget arrays" needed and with a switch statement you can use/show the corresponding class functions.[quote]
in my proof of concept, I output the two changed variables within a string. I'd like to make this a little fancier, like putting it into a graphic of some kind. Can someone point me to the documentation that talks about how to do this?
[/quote]
You can just paint or mayby use opengl?[quote]
the main loop in my IC class simulates a single clock cycle, during which every entity will be updated. I don't imagine that I want to be sending signals for hundreds of thousands of items with each clock cycle, especially since my GUI is only going to display a small fraction of the available data at any given time. How does the programmer restrict Qt's updating to those items currently displayed? (I hope I made sense with this question.)
[/quote]
i think you just write it as you're writing your code for the ic. use steps to control en skip 'time' when nothing happens. -
You can just paint or mayby use opengl?
I'm hoping to keep this entirely within Qt, for simplicity's sake. I seem to remember reading about the ability to tie a programmatic variable to a display element using Designer, but...I can't remember where I saw that, and I'm not figuring it out just by looking at Designer.
-
I would seriously take a look at the Qt State Machine framework (QStateMachine, QState, QAbstractTransition etc). We make heavy use of this framework for modelling and controlling hardware devices. The hierarchical nature of the nested states and transitions maps quite nicely onto physical components or behavioural modes of operation.
I am thinking that maybe you could use this framework to model your IC and then maybe hook it up to a QGraphicsView/Scene or QML scene for the visualisation aspects.
-
Hey, Zap -
That does look interesting, and it might be worth a closer look. For my education, though, can we put it aside and go through the same thing we did in the other thread, except making the display of the variables more "graphical?" I'd like to implement something along the lines of what I described above, even if only for the exercise. Besides, this summer, I'll be using Qt for more than a simulator. It will be a genuine GUI, and I need to learn about that.
Thanks.
-
You mean that you just want to learn how to display the results of your existing calculations in a more graphical way?
If so, then I would take a look at QGraphicsView or QML. QGraphicsView is purely C++. QML is a new technology with a lot of promise. It is easy to write custom GUIs using QML but you'll need to be prepared to get to grips with exposing C++ objects to the QML side of things.
NB: QML is actually built on top of QGraphicsView at the moment but this is likely to change in the future.
I suggest that you have a read up on these two technologies.
-
Of course. You can simply use you QML scene as a single widget in your app rather than the entire application GUI. Just add a QDeclarativeView to your form and set it to use the specified QML file:
@
QDeclarativeView *view = new QDeclarativeView;
view->setSource(QUrl::fromLocalFile("myqmlfile.qml"));
view->show();
@ -
Basically it is similar to what we already did in the other thread. The main difference is that instead of simply emitting a signal for your calculated values we declare those values as properties of the QObject (using the Q_PROPERTY() macro) and add a signal that is used to notify interested parties (the QML items) about changes to those property values.
When the QML runtime gets those signals it updates the relevent items in your QML scene that have properties bound to your C++ object's properties in some way.
It's not as hard as it sounds ;-)
-
OK, I'll start on that in a bit. A couple of questions:
- does using QML mean that I'm no longer using my widget.ui file, or do they work together?
- regarding QML: I think I may have mentioned that later this year I'll need to design a genuine GUI (for products based on the ASIC that I'm currently simulating). Is QML appropriate for applications like that as well? I ask now, because I'd like to choose one method of implementation and stick with it for both the simulator and the product GUI.
Thanks!
-
1: depends on your design. If you use a QML file for your whole UI, yes. Otherwise, the QML view is just a part of your UI design, and one that would be part of the actual .ui file.
2: to decide that, you need to tell us about the criteria, and even then it is hard for us to advise you on that. QML may be a candidate, but...
-
Thanks, Andre. Tell you what: I'll spend today playing with QML and doing some reading.
Regarding the upcoming product GUI: think of how you configure a home DSL modem, except we (probably) won't be using a browser to reach the embedded application.
I'll be back later with (I'm sure) some questions.
-
QML or a QWidget based GUI will work fine for that. Depends how much you want in the way of animations or how much you would like it to look native on your target platform. Having said that QML can be made to look native and we may see some native looking QML components coming out in the course of the coming year.
-
Not directly related to the thread, but I've stumbled across an issue that I've been wondering about.
I'm running on a Mac platform. The code that Zap posted above won't work unless I move my QML file into the resource for the binary. I don't like to do this, because 1) it's a minor hassle, and 2) it seems like a maintenance issue that I don't need.
Does Qt have any hooks for setting a default directory, or putting a prefix on files to direct them to somewhere else? I'm trying to avoid any hard-coding here, though some may be necessary.
I did find this thread:
"thread on setSource":http://developer.qt.nokia.com/forums/viewthread/656Which seems related, but not quite the answer.
Any advice on how to handle this?
-
Decisions, decisions. An absolute pathname, and I bet it won't port to other platforms. Relative pathnames seem weird here, too.
I don't suppose Qt supplies a pathname for the project, does it? I can't see how it could, but that would solve the problem.
