must specify a service name

[AlbertCahalan]

Sugar seems unable to function without a DBUS service name. I get this:

ERROR - /usr/share/activities/tuxpaint.activity must specify a service name

Neither GNOME nor KDE requires this. (and certainly not twm, fvwm, ctwm, etc.) It appears to be useless bloat. At the very least, it is needless incompatibility. Every other window manager in the two-decade history of X has had no need for DBUS.

It's even mostly undocumented. All I can find is a wiki page that says I have to have a service name. There is no justification. There is no guidance for choosing a name. Merely adding a name does me no good; Sugar then times out when launching the app. There is no mention of how I can use the DBUS library to make this complaint go away.

This makes porting needlessly difficult. Please eliminate the service name requirement.

[dcbw]

Please add a service name to your .info file; it is required by Sugar. Doesn't really matter what it is, try 'org.tuxpaint.TuxPaint' or something like that. If you don't have a serivce name you aren't following the activity bundle spec and your activity won't work.

[AlbertCahalan]

I know it is required by Sugar. That's the bug. No other desktop environment requires this.

If it truly doesn't matter, then Sugar can set it to NULL or similar. Sugar can pull a name out of /dev/urandom if it likes. Sugar can use the time of day. Sugar can use the app's process ID.

I believe Sugar actually requires an app to use the service name in some way, but this isn't documented. No use for the service name is documented. I'd consider the lack of documentation to be a severe bug, except that there isn't any reason to require a service name at all. Every X desktop from twm to GNOME has been able to handle apps without service names, including remote apps.

[marco]

Replying to AlbertCahalan:

I know it is required by Sugar. That's the bug. No other desktop environment requires this. If it truly doesn't matter, then Sugar can set it to NULL or similar. Sugar can pull a name out of /dev/urandom if it likes. Sugar can use the time of day. Sugar can use the app's process ID.

It *does* matter. An activity without a service will simply not work. It just happens to be transparent if you are implementing the activity in python...

I believe Sugar actually requires an app to use the service name in some way, but this isn't documented. No use for the service name is documented. I'd consider the lack of documentation to be a severe bug,

It is, please open a ticket about it.

except that there isn't any reason to require a service name at all. Every X desktop from twm to GNOME has been able to handle apps without service names, including remote apps.

And so...? Sugar is not an X desktop and has different requirements from any other X desktop. We need a way for the shell to communicate with the activities and we are currently using DBus for that. If you have specific proposals about different communication meanings feel free to open a ticket about them.

[gnu]

Here's another example of the arrogance of Sugar and how it makes things needlessly hard for existing applications to run in its environment. "Sugar is not an X desktop".

Indeed, if the service name is a don't care, then Sugar could easily assign a random number or a sequential integer for the service name of any 'activity' that didn't come with one. But it doesn't, and its developer inappropriately closes out bugs like this, even after the affected developer reopens it.

[marco]

The service is **not** a don't care, I already said it but I'll reiterate. It's used to communicate with the activity. To ask it to share itself on the network for example or to associate it with the bundle. At least part of this functionality is required for an activity to be recognized and properly integrated in the shell.

If we want to support normal X applications in the Sugar shell than the user experience needs to be figured out and then we can refactor the system to allow it.

[marco]

Closing this again. If what you want is support for ordinary X applications open a new ticket and assign it to the interface-design component. That's where thinking about new features needs to start.