When minimized lxpanel's 2nd level selection is unselectable [closed]
On Lubuntu 18.04-1 using LXDE default setup initially.
Displaying the panel on left works fine for selecting a VPN Connection under Connections lxpanel.
When I set minimize in Advanced tab, subsequent attempts to select the 2nd level item from an lxpanel fails with the panel tree/vector collapsing as the cursor transitions to the selectable item which is in this case a VPN Connection entry.
Specific dialog is using the nework manager to activate a VPN connection from the list of such connections, i.e.:
Select connections icon
Select VPN Connections -> list appears
Attempt to select item from list -> poof, entire lxpanel vector collapses.
This sequence works fine if minimize panel when not in use on the Advanced tab is not checked.
This raises a philosophical question for me about statefulness of desktop implementations. Should implementations of connected dialog entities (panels in this case) only respond to cursor movement/transition or should the user be able to alternatively set a flag / environmental var to demand sustained presentation of the subsequent panel/list (upon selection of the antecedent) until an entry is selected or an escape action is initiated.
I poked around LXDE and lxpanel stuff for a couple hours and found no flags that could allow the user to configure a change to the mouse transition trigger behavior.
I'd love pointers to discussions of this type of design trade-off,
but more importantly I'd like to change the lxpanel-to-lxpanel transition which is failing in the above instance. I need the screen realestate that the minimize provides.
lubuntu lxde lxpanel
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
closed as unclear what you're asking by DK Bose, Charles Green, karel, Thomas, Eric Carvalho Jan 6 at 21:17
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
On Lubuntu 18.04-1 using LXDE default setup initially.
Displaying the panel on left works fine for selecting a VPN Connection under Connections lxpanel.
When I set minimize in Advanced tab, subsequent attempts to select the 2nd level item from an lxpanel fails with the panel tree/vector collapsing as the cursor transitions to the selectable item which is in this case a VPN Connection entry.
Specific dialog is using the nework manager to activate a VPN connection from the list of such connections, i.e.:
Select connections icon
Select VPN Connections -> list appears
Attempt to select item from list -> poof, entire lxpanel vector collapses.
This sequence works fine if minimize panel when not in use on the Advanced tab is not checked.
This raises a philosophical question for me about statefulness of desktop implementations. Should implementations of connected dialog entities (panels in this case) only respond to cursor movement/transition or should the user be able to alternatively set a flag / environmental var to demand sustained presentation of the subsequent panel/list (upon selection of the antecedent) until an entry is selected or an escape action is initiated.
I poked around LXDE and lxpanel stuff for a couple hours and found no flags that could allow the user to configure a change to the mouse transition trigger behavior.
I'd love pointers to discussions of this type of design trade-off,
but more importantly I'd like to change the lxpanel-to-lxpanel transition which is failing in the above instance. I need the screen realestate that the minimize provides.
lubuntu lxde lxpanel
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
closed as unclear what you're asking by DK Bose, Charles Green, karel, Thomas, Eric Carvalho Jan 6 at 21:17
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
On Lubuntu 18.04-1 using LXDE default setup initially.
Displaying the panel on left works fine for selecting a VPN Connection under Connections lxpanel.
When I set minimize in Advanced tab, subsequent attempts to select the 2nd level item from an lxpanel fails with the panel tree/vector collapsing as the cursor transitions to the selectable item which is in this case a VPN Connection entry.
Specific dialog is using the nework manager to activate a VPN connection from the list of such connections, i.e.:
Select connections icon
Select VPN Connections -> list appears
Attempt to select item from list -> poof, entire lxpanel vector collapses.
This sequence works fine if minimize panel when not in use on the Advanced tab is not checked.
This raises a philosophical question for me about statefulness of desktop implementations. Should implementations of connected dialog entities (panels in this case) only respond to cursor movement/transition or should the user be able to alternatively set a flag / environmental var to demand sustained presentation of the subsequent panel/list (upon selection of the antecedent) until an entry is selected or an escape action is initiated.
I poked around LXDE and lxpanel stuff for a couple hours and found no flags that could allow the user to configure a change to the mouse transition trigger behavior.
I'd love pointers to discussions of this type of design trade-off,
but more importantly I'd like to change the lxpanel-to-lxpanel transition which is failing in the above instance. I need the screen realestate that the minimize provides.
lubuntu lxde lxpanel
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
On Lubuntu 18.04-1 using LXDE default setup initially.
Displaying the panel on left works fine for selecting a VPN Connection under Connections lxpanel.
When I set minimize in Advanced tab, subsequent attempts to select the 2nd level item from an lxpanel fails with the panel tree/vector collapsing as the cursor transitions to the selectable item which is in this case a VPN Connection entry.
Specific dialog is using the nework manager to activate a VPN connection from the list of such connections, i.e.:
Select connections icon
Select VPN Connections -> list appears
Attempt to select item from list -> poof, entire lxpanel vector collapses.
This sequence works fine if minimize panel when not in use on the Advanced tab is not checked.
This raises a philosophical question for me about statefulness of desktop implementations. Should implementations of connected dialog entities (panels in this case) only respond to cursor movement/transition or should the user be able to alternatively set a flag / environmental var to demand sustained presentation of the subsequent panel/list (upon selection of the antecedent) until an entry is selected or an escape action is initiated.
I poked around LXDE and lxpanel stuff for a couple hours and found no flags that could allow the user to configure a change to the mouse transition trigger behavior.
I'd love pointers to discussions of this type of design trade-off,
but more importantly I'd like to change the lxpanel-to-lxpanel transition which is failing in the above instance. I need the screen realestate that the minimize provides.
lubuntu lxde lxpanel
lubuntu lxde lxpanel
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
edited Jan 5 at 19:57
Le Snelson
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
asked Jan 5 at 0:04
Le SnelsonLe Snelson
33
33
closed as unclear what you're asking by DK Bose, Charles Green, karel, Thomas, Eric Carvalho Jan 6 at 21:17
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by DK Bose, Charles Green, karel, Thomas, Eric Carvalho Jan 6 at 21:17
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I asked the Lubuntu Release Manager about this issue (I'm well connected, I know, but I help the Lubuntu team with some of their infrastructure so...), and they indicated this is a known bug already.
However, there is also known that LXDE's team more or less doesn't provide good fixes in a timely manner for LXDE bugs, and that has driven them to move to LXQt for 18.10 and further.
There isn't currently a fix currently stated by their teams at the moment for this issue, nor is there a known workaround. However, it is confirmed that this is a currently unfixed bug.
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I asked the Lubuntu Release Manager about this issue (I'm well connected, I know, but I help the Lubuntu team with some of their infrastructure so...), and they indicated this is a known bug already.
However, there is also known that LXDE's team more or less doesn't provide good fixes in a timely manner for LXDE bugs, and that has driven them to move to LXQt for 18.10 and further.
There isn't currently a fix currently stated by their teams at the moment for this issue, nor is there a known workaround. However, it is confirmed that this is a currently unfixed bug.
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
add a comment |
I asked the Lubuntu Release Manager about this issue (I'm well connected, I know, but I help the Lubuntu team with some of their infrastructure so...), and they indicated this is a known bug already.
However, there is also known that LXDE's team more or less doesn't provide good fixes in a timely manner for LXDE bugs, and that has driven them to move to LXQt for 18.10 and further.
There isn't currently a fix currently stated by their teams at the moment for this issue, nor is there a known workaround. However, it is confirmed that this is a currently unfixed bug.
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
add a comment |
I asked the Lubuntu Release Manager about this issue (I'm well connected, I know, but I help the Lubuntu team with some of their infrastructure so...), and they indicated this is a known bug already.
However, there is also known that LXDE's team more or less doesn't provide good fixes in a timely manner for LXDE bugs, and that has driven them to move to LXQt for 18.10 and further.
There isn't currently a fix currently stated by their teams at the moment for this issue, nor is there a known workaround. However, it is confirmed that this is a currently unfixed bug.
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
I asked the Lubuntu Release Manager about this issue (I'm well connected, I know, but I help the Lubuntu team with some of their infrastructure so...), and they indicated this is a known bug already.
However, there is also known that LXDE's team more or less doesn't provide good fixes in a timely manner for LXDE bugs, and that has driven them to move to LXQt for 18.10 and further.
There isn't currently a fix currently stated by their teams at the moment for this issue, nor is there a known workaround. However, it is confirmed that this is a currently unfixed bug.
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
answered Jan 5 at 20:05
Thomas Ward♦Thomas Ward
43.9k23121174
43.9k23121174
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
add a comment |
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
Thanks so much for the prompt response on both issues. Now I need to evaluate the difference in "weight" between the Gtk vs Qt libraries and related changes in applications. Care to comment on that as well?
– Le Snelson
Jan 6 at 1:10
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
@LeSnelson not with any experience, no. It's a little heavier than LXDE from what I've heard, but a bit prettier and a bit nicer, though I've not used either enough to give you anything other than what i've heard as 'vague rumor' and just unsubstantiated claims from users
– Thomas Ward♦
Jan 6 at 18:11
add a comment |
