I am coding a pyGTK application, and I'd like to change an input based on the user's selection from a ComboBox. For example, a user could select truck/car/van, and the input parameters would change corresponding to the type of vehicle.
Is there a way one can define the different sub-panels using Glade? It would be easy to just define a new class for each different sub-panel, but is it possible to also do this in Glade?
In glade (at least for glade-3 that uses GtkBuilder), you can have any widget as a top-level widget so you can design those panels and then insert them into appropriate container.
Related
I'm writing a GUI using QT for embedded system with linux. This device has no mouse. Only display and specific keyboard with keys: up, down, return and 7 number keys.
The software will be used to set some parameters of device and read them (some charts also).
Example of how menu could look:
after OPTION 1 selected
After SUBOPTION 1 selected some table with data is loaded.
Sometimes after selecting option i need to load specific widget and sometimes just another set of options.
I think it is possible to implement custom labels and kind of list widget that aligns them.
I guess it is also possible to use Qt's MVC classes for it. They are highly customizable, but i never made custom views and delegates.
Maybe i just need to create QtListView with stringlist model and apply stylesheet to it so it gets look more like buttons. And based on selection in list load next widget.
Which way is better and why?
Is there any easier ways to accomplish this?
Any ideas would be appreciated.
I may be bordering on a discussion type question here so I apologise if the question is not specific enough.
I would like to know if I my current application design is inherently weak/flawed. My background is C so I am not using clever c++ patterns to their fullest extent, of this I am sure.
My application is similar to a 3D modelling package, without geometry creation (e.g setting up animations using existing models). The user imports a geometry and can set various parameters on pre existing geometry, and there are time dependent values that relate to the whole system. The output is a text file to be processed by another application.
I am using a QTreeview to render a QStandardItemModel. I simply store pointers to my core classes in the model's items. These have specific UI for each class type, and are all descended from a common base class. They all have a QWidget which is their "mainwidget"
When the user clicks on part of the treeview, the stored class is retrieved and its mainwidget is displayed on a pane on the UI. So - treeview on the left, pane to the right with the current item's contents, and a 3D view showing the geometry.
Most of my data is stored in the classes UI elements themselves; I don't have a central database which stores anything, and when it's time to save the project, I traverse the tree and let every item write itself to a QSettings file. This feels quite naive but it does work, and the reverse happens on project load. The project class generates new classes based on the type information in the settings file and they then read the contents out of the file themselves.
Similarly when writing the output file, each item knows how to write itself and does so. Where other classes can influence the output of others (for example, start and end times), higher level classes process the children and will set start and end times based on the order and duration of each child.
Should I be storing more data in the QStandardItemModel itself, or defining my own model perhaps? Does it sound like I have set myself up for future problems?
At the moment I have modified this system a couple of times to provide customised applications, but I am about to try and make it more generic. I welcome suggestions for improving my design. Go easy, please!
You should try to avoid creating god objects. Split your tasks and duties into smaller chunks. It makes it much easier to maintain and also much easier to extend if you need to.
Your specific use-case would benefit a lot from a more complete use of the Model-View-Controller pattern.
What doesn't make sense in your design is that your data objects hold a UI element. Since only one item can be shown in the right pane, this seems like a waste of resources. It makes more sense to have a single object that then gets passed a data object to display.
What I suggest for your program is the following:
Splitting your data into classes that only have functions for reporting and modifying values. There should be no knowledge of how to display data or store to a file.
Create separate class that handles the reading and writing from a file. If your model is very simple, you could just use single functions to do this using the method shown in the documentation for QDataStream or QTextStream.
Use your QTreeView and QStandardItemModel as Adaptor class between your data objects and the left pannel.
Create a controller class that gets informed by the QTreeView if data needs to be displayed in the right panel. The controller will then retrieve the data item and pass it to the right panel in order to be displayed.
The right panel should act like another View class with the sole responsibility of graphically displaying the data passed in from the controller class.
One advantage of doing it this way is that, if there are different categories of data that get displayed differently in the right panel, the controller could examine the selected data item, determine what the category is, create a view widget to put in the right panel, and then pass it the data to display.
This pattern is open-ended as far as extendability is concerned because you do not need to change your data classes if you need a new display, you merely need to create a new right-panel widget, and then teach your controller class how to determine when the new view should be used.
Another advantage of this pattern is that you only ever need to have a single widget created to display data in your right panel. If you change your selected item, you can just pass it to the view class that already exists and get it to refresh its display with the newly selected data. You only need to distroy the right-panel view widget if a different category of data object is selected and its data needs to be drawn in a different way. The controller class can determine whether a right-panel view widget can be re-used or whether it needs to be swapped out for a different widget.
I am using EMF to allow users to create instances of a particular type of model.
An instance of a model can have 0-* Things but I'd like to be able to predefine the available Things that the user can add to the instance so that they can't just create their own.
How would I go about creating the Things using the ecore model?
If a Thing was just a String then it would be fine - I could use Enums. But a Thing is a type of it's own and consists of other stuff (like a name, version etc.) and I don't know how to give a predefined set of these to the user to choose.
Any ideas?
You have the possibility to use constraints or *EOperation*s.
For a better usability you should use a own dialog implementation. An example of a own implementation with given choices you can find here:
How can I control which instances are available as choices when editing a property in the properties view?
You should also implement a own property source to support the properties editor:
Recipe: Create your own property editor in a generated application
I've been reading about Qt's Model/View framework. I find it really helpful on working with tabled data like tables from a database. My question is: will it be useful for non-table data like property list or just some bunch of data of various types? If so, how should I approach it?
The goal is to come up with an editor for some property list like data. The list is constructed at runtime and the elements are of various types (numbers, strings, booleans, and file paths, to name a few). Each element is basically a name-value pair. The name, type, and restrains (limits for example) for each element are defined at compile time. They will be assembled at runtime into different lists depending on user input. And the list of elements can change during the edit session.
The UI will most likely be combination of various pre-designed widgets assembled according to user input. They may not be list or table views.
Some pointer to design pattern or examples are also much appreciated. Thanks.
I don't see a problem with MVC framework in QT for doing that.
Basically the difference between a standard table display and this is that you create a list dynamically akin to a map of:
QMap<QString, QVariant> property_map;
You can do a:
QList<std::pair<QString, QVariant>> property_list;
which you can then use to display in a table the property. The best way would probably be:
struct {
QString prop_name;
int prop_type;
QVariant prop_value;
};
QVariant basically will provide you with a single abstraction class for data storage and it is actually what's being returned by the data() function inside the QAbstractItemModel which you might be reimplementing.
So basically you will take a property list and boil it down to the same table like data as the database.
AMENDED
If you have a Widget that you want to have this widget populated with other predefined widgets you are quite likely to have multiple problems unless widgets are of same or well defined size.
What you can do is in you Display widget define a layout like: QGridLayout or other possible layouts and then add your other widgets to it using some set of parameters, which could be done but can be somewhat of a pain.
The other approach that you may take is to place all property widgets up front on the display UI and simply turn the ones you need on and the rest off, but this only applicable if you have a well defined limited number of pre-designed widgets.
I've been using Model/View framework for quite some time now and I usually implement my own models with a backend based on Qt containers (vectors, list, etc). Even if data eventually comes from a database, working with (e.g.) a vector of database ids can dramatically improve performance (and sometimes is the only way you can do).
This trivial example from Qt docs (see "Creating a Custom Model) is the point where I started and shows how to use a QStringList as a backend for a custom model.
Once defined your model you can define your custom Views, which will draw arranged widgets based on the content of the model underneath.
When the model change, your view will change accordingly rearranging widgets when necessary.
Leveraging QVariant capabilities you should be able to render the proper widget for every datatype (e.g. a QSpinBox for a float a QComboBox for a QStringList, and so on...)
I'm making a game GUI API. It is coming along very nicely except for one aspect. I want themes similar to how GTK works. The way I want it to work is that every GUI element will have a default Windows9X-like way of drawing themselves. If it is found that a theme is set for that type of widget, it will be drawn with those bitmaps.
My original concept was to create a Theme class which would have getters and setters for the bitmaps.
for example:
themeManager.setButtonHover(Bitmap *bitmap);
The problem with this, is that it is not flexable if I want to create new types of Widgets. I may eventually want to create a superButton which would use a different theme than a button. This is the flaw with that concept. The concept I'm thinking of going with is that each widget type has static methods to set the theme for itself and the constructor uses that.
Are there better ways of doing this that I'm not thinking of? Since it is an API, I want to avoid reading text files, so reading the theme from a text document is not an option.
Thanks
May be template the superButton on a policy and then have a default policy which does the default and the user has the option of providing a different policy? The policy could then define the attributes of the button (such as the hover image etc.) - does what I describe make sense?