[Sugar-devel] One instance activity

Bert Freudenberg bert at freudenbergs.de
Wed Dec 10 05:17:44 EST 2008

On 10.12.2008, at 11:56, david at lang.hm wrote:

> On Wed, 10 Dec 2008, Bert Freudenberg wrote:
>> On 10.12.2008, at 03:57, david at lang.hm wrote:
>>> On Tue, 9 Dec 2008, Bert Freudenberg wrote:
>>>> On 09.12.2008, at 18:55, Eben Eliason wrote:
>>>>> Are you sure?  Browse makes use of shared code, but still  
>>>>> presents the
>>>>> user with the appearance of multiple instances.
>>>> Right.
>>>> The way to do it would be to create a unique D-Bus service in your
>>>> activity. When the second instance tries to create that service it
>>>> will notice that it already exists. It could then notify its first
>>>> instance via said D-Bus service.
>>> you don't need to use D-Bus for this, it can be done by X without  
>>> any other communication channels.
>>> I don't know the details for how to do this, but I've seen mozilla/ 
>>> firefox do this for a few years. to see this start firefox on one  
>>> machine, connect to another machine and point the display back to  
>>> the first one. then try and start firefox on that second machine.  
>>> the end result will be a new window opening up, but running on the  
>>> first machine (if you have trouble seeing the difference, make the  
>>> two machines have different bookmarks, or give one network access  
>>> that the other doesn't have)
>>> please don't develop new mechanisms to do things that already exist.
>> It's not a new mechanism. The usage of a named D-Bus service to  
>> ensure unique program instances is documented and not my invention  
>> (though I cannot remember where I saw it first).
>> I should have written "One way to do this would be ...", I give you  
>> that.
>> But you cannot know which way would be preferable for a given  
>> activity. And since it is private to the activity and does not  
>> affect other activities, no harm is done either way.
>> E.g., twiddling X properties is hard in various high-level  
>> languages, in particular when using higher-level UI toolkits. Sugar  
>> currently requires two custom X properties and this is causing  
>> activity authors considerable pain. Even Sugar itself had to resort  
>> to C code, adding a custom native library to manipulate these  
>> properties, it was not easy in pure Python. This is in stark  
>> contrast to the nicely general and easy-to-use Python D-Bus  
>> bindings, which are similarly available in other high-level  
>> languages.
>> So please consider that not all people like having to go down into  
>> the machine room to make new plumbing with a C compiler. Having  
>> done too much of that myself I can relate to them.
> my initial reaction to this is that this sounds like a gap in the  
> python libraries that would be very useful to fill. getting someone  
> to write a python library to better access the X properties would  
> help many areas.
> any idea why nobody has written one yet? Python is much better than  
> many languages at letting you write a library in C and then use it  
> cleanly, so if doing this in python is as hard as you are  
> indicating, why hasn't it been addressed?

I don't know. And this is diverging from the subject at hand.

Even if it was simple to set and read an X property then implementing  
single-instance apps via X properties still would be considerable more  
complex than using D-Bus. You would have to learn a whole lot about  
how X works first, and then design that mechanism on top of it. Having  
done a fair bit of X programming myself (the Squeak VM talks to Xlib  
directly, no toolkit) I would not exactly rate this as trivial. X can  
be abused to do IPC, sure, but it still is abuse. D-Bus is made to do  

- Bert -

More information about the Sugar-devel mailing list