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

[x-ist]

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.

[anevilyak]

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

[x-ist]

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

[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.

[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?

[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?

[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.

[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.

[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.

[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).

[anevilyak]

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.

[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.

[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.

[anevilyak]

Fixed as delineated above in hrev44403.