* Cinnamon version: 4.2.4 and 4.3.0
- Please specify if you are using the daily builds PPA (https://launchpad.net/~linuxmint-daily-build-team/+archive/ubuntu/daily-builds): both tested.
* Distribution: Mint 19.2
* Graphics hardware *and* driver used: no matters
* 64 bit
* Attach /home/<username>/.xsession-errors, or /var/log/syslog: no error reported.
```
**Issue**
When the "dependency" option is used in "list" settings, the list does not appear.
**Steps to reproduce**
Sample (extract from vpnLookOut@claudiux):
"manageClients": {
"type": "switch",
"default": false,
"description": "Manage VPN-related Apps",
"tooltip": "This option allows this applet to manage the VPN-related applications you listed above."
},
"clientsList": {
"type": "list",
"description": "Managed applications",
"tooltip": "Name: What you want.\nCommand: The command to run the application, without its path.\nRestart: Set to TRUE if you want to restart this application as soon as the VPN link becomes active again.\nShutdown: Set to TRUE if you want to close the application as soon as the VPN link is stopped.\nVPN only: Set to TRUE if you want to quickly stop this application if it is started while the VPN is idle.",
"columns": [
{
"id": "name",
"title": "Name",
"type": "string"
},
{
"id": "command",
"title": "Command",
"type": "string"
},
{
"id": "restart",
"title": "Restart",
"type": "boolean"
},
{
"id": "shutdown",
"title": "Shut down",
"type": "boolean"
},
{
"id": "vpnOnly",
"title": "VPN only",
"type": "boolean"
}
],
"default": [
{
"name": "Transmission",
"command": "transmission-gtk",
"restart": false,
"shutdown": true,
"vpnOnly": false
}
],
"dependency": "manageClients"
}
```
Expected behaviour
That "dependency" option in "list"-types acts, in Cinnamon 4.2 and 4.3, as in Cinnamon 3.8 and 4.0.
Other information
Maybe related to #8311?
@claudiux any suggestions/thoughts on a best possible solution for this?
@icarter09 Unfortunately not.
I can't reproduce this in current master. The dependency property works for me exactly like it does for other settings types. @claudiux if you're still getting this issue, could you please try running it from the command line and see if it outputs anything?
Hello, everybody.
Cinnamon version: 4.2.4 (no PPA)
Distribution: Mint 19.2
@collinss: I can reproduce the issue reported by @claudiux consistently. The test xlet attached to this message works out of the box (toggling the switch called manageClients toggles the visibility of the list called clientsList). But if you remove the extraSwitch from the section called sectionT2, the manageClients switch becomes non functional.
The best way that I can describe the issue is as follows. If a section with one or more widgets whose dependencies are commanded by a switch that it's inserted in a different section, the revealer becomes non functional. Except if the section contains one of more widgets that aren't controlled by the dependency widget.
I didn't test other widget types used as dependencies nor the use of operands. Neither did I looked into the Python side of the settings system.
I would also like to mention that I tested claudiux's applet on Cinnamon version 4.0.10 and this particular issue that we are discussing didn't exist there.
Edit: I forgot to mention that there aren't any errors logged into the terminal nor on the .xsession-errors file when toggling a _non functional switch_ on the settings window.
@claudiux: To fix your problem you could simple move both widgets (the switch and the list that the switch toggles the visibility of) into a unique section. Or even set the dependency to the section, not the widget. In my tests both ways worked.
Off topic @claudiux: I found a minor error when testing your applet. Around line 1275 you set a label for the this.menuitemInfo2 menu item, but that item is created only when the dependencies for the applet are met. While the main update function is executed and until the dependencies are installed, the .xsession-errors file is spamed with error messages of the kind this.menuitemInfo2 is undefined.
Thanks for the extra info @Odyseus ! I'm able to reproduce it now. I've tracked down the issue, and it's not just a problem with the list widget, or even just xlet-settings. It looks like the behavior was semi-intentional, though the implementation has some serious issues.
Basically, the idea is that there's a frame around the widgets of every section, but it doesn't add the frame to the container until a row is added, because otherwise it would look bad. The problem comes in when you don't have a normal row, but only revealer rows (which is what gets used when you specify a dependency). In that case the frame never gets added to the container, so none of the settings in that section are ever going to be visible - even if you have 100 widgets in there with dependencies. I'm still trying to decode on the best way to fix it, but in the mean time, it's probably better to put the dependency on the section rather than the widget anyway.
Many thanks, @Odyseus and @collinss ! All your info will allow me to solve a lot of problems!
(I think to completely rewrite the code of this applet, became too foggy.)
Most helpful comment
Thanks for the extra info @Odyseus ! I'm able to reproduce it now. I've tracked down the issue, and it's not just a problem with the list widget, or even just xlet-settings. It looks like the behavior was semi-intentional, though the implementation has some serious issues.
Basically, the idea is that there's a frame around the widgets of every section, but it doesn't add the frame to the container until a row is added, because otherwise it would look bad. The problem comes in when you don't have a normal row, but only revealer rows (which is what gets used when you specify a dependency). In that case the frame never gets added to the container, so none of the settings in that section are ever going to be visible - even if you have 100 widgets in there with dependencies. I'm still trying to decode on the best way to fix it, but in the mean time, it's probably better to put the dependency on the section rather than the widget anyway.