Simple questionL in a program using GTK4, how can I set the limits for a spin button in the template file? The doc does not list a property or attribute that seems related. There is a method set_range() so I can do it programaticly, but I'm sure there has to be a way to do it in the template file - right?
Related
I have bunch of data that has to be displayed continuously on the GUI. I can actually achieve it by setting timer and assigning the new values to the displayed values but I do not want to do in that way. Is there any solution or practical way to do that?
I think you have two options to achieve that:
All your data have a Q_PROPERTY. That means create a get function and a signal
If you want to show them under a list or a treeview, I suggest you gather all the data up, under a QAbstractListModel.
https://doc.qt.io/qt-5/qabstractlistmodel.html
Then implementing the function data, index, ecc., you will have everything already done for the UI
Have you tried using Q_Property? Notify Signal may work for your situation.
You can find the documentation from here.
First, I defined the property and added the notifier called payloadChanged to the signals of my class.
Q_PROPERTY(QList<qreal> PayloadList READ getPayloadList NOTIFY payloadChanged)
Secondly,
qmlRegisterType<<YOUR_CLASS_NAME>>("sample1.sample2", 1, 0, "<QML_ITEM_NAME>");
Finally
QML_ITEM_NAME{
console.log("PROPERTY")
}
When I applied these steps my data is automatically updated without any timer stuff.
I have an existing application that uses MFC for the UI, and I'm trying to migrate to Qt. For the most part the migration is straight forward, but I'm not sure how to manage the enabled state of actions (menu and toolbar items).
In MFC you implement a callback with enable/disable logic, and this is called when the item is displayed. In Qt, you only have access to the setEnabled() method.
Is there a built-in or standardized way of connecting an update callback to an action? or do I need to create my solution using timers and registering actions with it? In a large application such as the one I'm working with, the 'should enable' logic can jump all over the place - i.e. certain files on disk must exist, the main display must have a selection, the application's ProcessManager::isProcessing() must be false, etc. It doesn't seem practical to rely on setEnabled() being called on specific actions when there are so many conditions behind the enable/disable logic.
The most "standard" Qt way would be the use of signals/slots.
In my MDI apps, which are based on the Qt MainWindow/MDI examples, I just connect a single "updateMenus()" function to the signal emitted whenever an MDI subwindow is shown or hidden.
Now that may not be enough granularity for your application. So what you could do is - still have a single "updateMenus()" method - but connect it to each menu's "aboutToShow()/aboutToHide()" signals.
That way you keep the logic from sprawling all over the place, and only update menus right when they are needed (like in MFC's OnCmdUI()).
Here's my mainwindow constructor:
mp_mdiArea = new QMdiArea();
setCentralWidget(mp_mdiArea);
connect(mp_mdiArea, SIGNAL(subWindowActivated(QMdiSubWindow*)), this, SLOT(updateMenus()));
And here's my updateMenus():
void MainWindow::updateMenus()
{
bool hasMdiChild = (activeMdiChild() != nullptr);
mp_actionSave->setEnabled(hasMdiChild);
mp_actionSaveAs->setEnabled(hasMdiChild);
mp_actionClose->setEnabled(hasMdiChild);
}
See Qt 4.8 doc for menu->aboutToShow()/Hide() here
Here is how I create menu on Action item.
QAction * menuHolder = new QAction("Holder");
menuHolder->setMenu(new QMenu());
menuHolder->menu()->addAction(new QAction("Menu item"));
My problem is how to disable menuHolder but keep menu associated to the action enabled(arrow near menuHolder should still be enabled).
I've tried something like this, but this doesn't work:
menuHolder->setEnabled(false);
menuHolder->menu()->setEnabled(true); ?
Edited after comments:
It seems you're looking for a solution for a problem you don't have. You could prefectly handle that scenario as many many others applications do:
If the user click to save and don't have permissions just notify about that, and if you want, you could explain that he/she needs to save the file with another name.
In most of applications the user will look for File -> Save as for doing that.
So, separate the actions, the way you are trying to do alse can confuse the user and never find the action Save as, sice is under a disabled icon.
The requirements is like master detail grid, on load the master gets displayed as a table, on every detail row edit button click , need to open the detail edit form in a Modal window. There could be different templates based on detail/productTypes . For example productType1 will display few set of fields(template 1) , so on.
Have WEBAPI with REST support and understand how to build the initial Master table But not sure on how the details part.
Any direction would be helpful.
Does your HTML/CSS Framework provide mechanism for a dialog? If so you would have to create a directive to wrap it around the script to open the dialog.
On the master grid row ng-click will set a flag on the controller. When this flag is set to true, the code in directive will open the dialog. Within that dialog div you can use ng-include that will be bound to the url of the template (controller variable will store that url).
The template is bound to a child object in the controller scope and has the fields for the details. Setting the flag to false will close the dialog and you will have changes your main controller.
When I add another inline the template have some javascript code...
the code is here : https://github.com/jeremyjbowers/django-autocomplete/blob/master/autocomplete/templates/admin/autocomplete/inline_widget.html
when the user press on the add another inline link on the admin page, the other inline is added but the script tag doesnt apper, in the previous ones created before it work ok.
I'm using https://github.com/jeremyjbowers/django-autocomplete
This is because rendering inline javascript in widgets is a poor practice.
Even if the script tag was added, I don't think that the $(document).ready callback would ever be triggered.
If you want to fix it, you can see how django-autocomplete-light does this:
Instead of initializing the widget on document load, do it in a custom signal callback,
Emit that custom signal on document load,
Emit that custom signal when a widget is created.