[sugar] #1560 NORM Trial-2: Activity launch not detected

[Marco Pesenti Gritti]

Bert Freudenberg wrote:
> On Jun 3, 2007, at 18:01 , Zarro Boogs per Child wrote:
>
>> #1560: Activity launch not detected
>> ---------------------+------------------------------------------------------ 
>>
>>   Reporter:  bert    |       Owner:  dcbw
>>       Type:  defect  |      Status:  reopened
>>   Priority:  normal  |   Milestone:  Trial-2
>>  Component:  sugar   |     Version:
>> Resolution:          |    Keywords:
>>   Verified:  0       |
>> ---------------------+------------------------------------------------------ 
>>
>> Comment (by marco):
>>
>>  This should be fixed again in the latest git. Activity id and bundle id
>>  should now be provided by two properties of the toplevel X window.
>>
>>  _SUGAR_ACTIVITY_ID (utf8 string)
>>  _SUGAR_BUNDLE_ID (utf8 string)
>>
>>  sugar/lib/sugar-x11-util.c has the code which we use to set those
>>  properties for python activities.
>
> This only complicates matters. Not only for Etoys (which does not have 
> a way to set X properties currently), but I see you had to resort to C 
> code even for Python activities. I'd much prefer if the only thing 
> Sugar cares about an activity X-wise is its window ID (and we're 
> working on a way to make that accessible in Squeak). Everything else 
> should be handled by DBus, and this is how it actually was before your 
> refactoring. If anything I'd shift communication *towards" DBus, not 
> away from it towards X by introducing arbitrary and unnecessary 
> properties.

[ CCing Dan, since he wrote the original startup notification and  I'm 
interested in his opinion ]

We decided a while ago to use X  for window management and I don't see a 
reason to revisit that decision. Etoys should respect the multiple 
windows semantic (which I know you are working on, thanks).

To reassure you, we are not going to use X as an IPC (as people have 
done in the past), since that gets unbelievably ugly: that's where dbus 
has his role in the shell -> activity instance communication.

> Besides, it does not address the original problem - that if an 
> activity X window is opened and detected by the Sugar shell, but it 
> has not created its DBus service yet, the shell will mistake it for a 
> raw X app (creating a
> "raw" icon in the donut next to the still flashing activity icon). 

If there is a _SUGAR_ACTIVITY_ID property the window is an activity, 
otherwise it's a raw X window. So I think it actually solves the problem.

The shell must know the activity and the bundle id as soon as an 
activity window is displayed, otherwise it can't represent it properly 
in the home. Relying on the dbus service for this was very fragile and 
introduced races which was hard or impossible to solve properly.

Window management should work using X communication. Mixing dbus and X 
there just introduce races and confusion. If we was going down the "dbus 
for window management" route then I'd agree with you, but we aren't.

> This can easily be fixed up later by detecting the DBus service 
> creation and removing the raw icon - this is how my fix worked.
>

Now, that's really a bad hack. I don't want to show a random icon on the 
screen and than replace it when the DBUS service appear... it just suck.

The startup phase is completed when the window appear on the screen, not 
when the dbus service appear. That's also exactly how startup 
notification is implemented in GNOME btw.

Marco