Opened 7 years ago

Closed 7 years ago

#8768 closed bug (fixed)

[ProcessController] Does not react to mouse clicks, when Deskbar is being debugged with Debugger.

Reported by: x-ist Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications/ProcessController Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

  1. Removed the ProcessController from Deskbar.
  2. Installed it as desktop applet.
  3. In Terminal launched "Debugger ./Deskbar" where ./Deskbar is my currently built debugee.
  4. Installed a breakpoint within Deskbar source code.
  5. Triggered an action to hit the breakpoint.
  6. Observed that ProcessController does not react to mouse clicks (no menu), although the applet seems to remain alive.

Attachments (1)

Screenshot.png (133.8 KB) - added by x-ist 7 years ago.
ProcessController as Desktop applet. Sorry, I wasn't sure about the correct terminology.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by anevilyak

What do you mean by "installed it as a desktop applet"?

Changed 7 years ago by x-ist

Attachment: Screenshot.png added

ProcessController as Desktop applet. Sorry, I wasn't sure about the correct terminology.

comment:2 Changed 7 years ago by anevilyak

Resolution: invalid
Status: newclosed

That's actually expected behavior in this case ; there are various places where ProcessController makes calls to Deskbar to see if it's currently installed there or not, and those will block if you currently have Deskbar in the debugger, since the same thread that's trapped in the debugger is the one responsible for responding to those messages.

comment:3 in reply to:  2 ; Changed 7 years ago by x-ist

Replying to anevilyak:

That's actually expected behavior in this case ; there are various places where ProcessController makes calls to Deskbar to see if it's currently installed there or not, and those will block if you currently have Deskbar in the debugger, since the same thread that's trapped in the debugger is the one responsible for responding to those messages.

Well, but to me it looks a bit odd since the ProcessController actually does not sit in the Deskbar but is dependent on it. I'm not familiar with desktop applets, but shouldn't such an information be stored within the ProcessController instance instead of the Deskbar, and why is it necessary to poll the Deskbar constantly with requests? What if I wanted to use ProcessController to kill an unresponsive Deskbar?

comment:4 in reply to:  3 ; Changed 7 years ago by anevilyak

Replying to x-ist:

Well, but to me it looks a bit odd since the ProcessController actually does not sit in the Deskbar but is dependent on it. I'm not familiar with desktop applets, but shouldn't such an information be stored within the ProcessController instance instead of the Deskbar, and why is it necessary to poll the Deskbar constantly with requests? What if I wanted to use ProcessController to kill an unresponsive Deskbar?

The problem arises primarily because what you currently have blocked is the application thread. Under normal circumstances that one does very little besides watch for teams starting/quitting and managing settings. Most deskbar lockups actually happen in the window thread. Furthemore, at the end of the day, Deskbar is a system component which has API calls tied into it, so by embedding it in Tracker instead you're not really avoiding the problem, since the latter's quite likely to call into Deskbar to see what its current position is for e.g. icon positioning purposes. In general, when you're embedding an app as a replicant you're going to be dependent on whatever its host needs, since you run in the same thread.

Just out of interest though, does the issue occur if you have ProcessController just running in its own window, without embedding it anywhere else?

comment:5 Changed 7 years ago by axeld

Resolution: invalid
Status: closedreopened

When you install ProcessController on the desktop, I see no reason why it has to make any calls to the Deskbar. So unless that is really confirmed to be necessary, I would keep this bug open.

comment:6 in reply to:  5 Changed 7 years ago by anevilyak

Replying to axeld:

When you install ProcessController on the desktop, I see no reason why it has to make any calls to the Deskbar. So unless that is really confirmed to be necessary, I would keep this bug open.

For what it's worth, I've tracked it down. When constructing its menu, it queries deskbar to see if it's currently living there or not in order to know how it should present the "Live in Deskbar" menu item. It has a global that's set to indicate that the current instance is living in Deskbar which short-circuits the check immediately, otherwise it asks BDeskbar if it has an item, so that the menu can present the checked state correctly regardless of where the current instance is running from.

comment:7 in reply to:  4 Changed 7 years ago by x-ist

Replying to anevilyak:

Just out of interest though, does the issue occur if you have ProcessController just running in its own window, without embedding it anywhere else?

Yes, same issue in that case too.

comment:8 Changed 7 years ago by axeld

Thanks Rene! Maybe only show that menu item when you have it open in a window? At least it's not very likely that one decides to move it into the Deskbar from a replicant.

Otherwise, we'd indeed have to close this bug as invalid (even though "wontfix" would be more appropriate then).

comment:9 in reply to:  8 ; Changed 7 years ago by anevilyak

Owner: changed from nobody to anevilyak
Status: reopenedassigned

Replying to axeld:

Thanks Rene! Maybe only show that menu item when you have it open in a window? At least it's not very likely that one decides to move it into the Deskbar from a replicant.

That'd be a possibility, though that'd also remove the ability to uninstall it from Deskbar, since that item allows both operations depending on the current state ; might not be a big deal for just the non-Deskbar replicant case though. If that's acceptable, I'll go that route.

Otherwise, we'd indeed have to close this bug as invalid (even though "wontfix" would be more appropriate then).

I've taken the liberty of adding a wontfix resolution state for future use, just realized we didn't have one.

Last edited 7 years ago by anevilyak (previous) (diff)

comment:10 in reply to:  9 ; Changed 7 years ago by axeld

Replying to anevilyak:

That'd be a possibility, though that'd also remove the ability to uninstall it from Deskbar, since that item allows both operations depending on the current state ; might not be a big deal for just the non-Deskbar replicant case though. If that's acceptable, I'll go that route.

I thought it knows after start if it's living in the Deskbar? How does this then affect the ability to uninstall it from there?

I've taken the liberty of adding a wontfix resolution state for future use, just realized we didn't have one.

I guess this was based on some serious thinking by Niels, but I think that "invalid" sometimes sounds as if it would not acknowledge a valid reason for a report.

comment:11 in reply to:  10 Changed 7 years ago by anevilyak

Replying to axeld:

I thought it knows after start if it's living in the Deskbar? How does this then affect the ability to uninstall it from there?

I meant the general replicant case, i.e. if embedded in Tracker's desktop or any other random replicant container. The whole reason it's performing the deskbar query in question is to see if the item should be shown checked or not, which in turn determines if its function is to install or uninstall from Deskbar. Removing the item entirely in the non-Deskbar replicant case would also remove the latter functionality.

I guess this was based on some serious thinking by Niels, but I think that "invalid" sometimes sounds as if it would not acknowledge a valid reason for a report.

Agreed.

comment:12 Changed 7 years ago by anevilyak

Resolution: fixed
Status: assignedclosed
Version: R1/alpha3R1/Development

Fixed as delineated above in hrev44403.

Note: See TracTickets for help on using tickets.