sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
#!/usr/bin/env python
|
|
|
|
|
|
|
|
# Copyright (C) 2006-2008, Red Hat, Inc.
|
2008-08-27 11:04:54 +02:00
|
|
|
#
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
2008-08-27 11:04:54 +02:00
|
|
|
#
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
# This program is distributed in the hope that it will be useful,
|
2008-08-27 11:04:54 +02:00
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
2008-08-27 11:04:54 +02:00
|
|
|
#
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program; if not, write to the Free Software
|
|
|
|
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2008-08-27 11:04:54 +02:00
|
|
|
|
|
|
|
import os
|
|
|
|
import sys
|
2012-08-27 16:09:23 +02:00
|
|
|
|
|
|
|
# Change the default encoding to avoid UnicodeDecodeError
|
|
|
|
# http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038928.html
|
|
|
|
reload(sys)
|
|
|
|
sys.setdefaultencoding('utf-8')
|
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
import gettext
|
|
|
|
from optparse import OptionParser
|
|
|
|
|
|
|
|
import dbus
|
|
|
|
import dbus.service
|
2013-09-04 21:09:40 +02:00
|
|
|
from dbus.mainloop.glib import DBusGMainLoop
|
|
|
|
DBusGMainLoop(set_as_default=True)
|
2008-08-27 11:04:54 +02:00
|
|
|
|
2011-12-20 18:48:09 +01:00
|
|
|
from sugar3.activity import activityhandle
|
2012-06-04 17:45:30 +02:00
|
|
|
from sugar3.activity import i18n
|
2013-09-10 22:42:48 +02:00
|
|
|
from sugar3 import config
|
2012-06-04 17:45:30 +02:00
|
|
|
import sugar3
|
2011-12-20 18:48:09 +01:00
|
|
|
from sugar3.bundle.activitybundle import ActivityBundle
|
|
|
|
from sugar3 import logger
|
2008-08-27 11:04:54 +02:00
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
def create_activity_instance(constructor, handle):
|
|
|
|
activity = constructor(handle)
|
|
|
|
activity.show()
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
return activity
|
2008-08-27 11:04:54 +02:00
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
def get_single_process_name(bundle_id):
|
|
|
|
return bundle_id
|
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
def get_single_process_path(bundle_id):
|
|
|
|
return '/' + bundle_id.replace('.', '/')
|
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
class SingleProcess(dbus.service.Object):
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
def __init__(self, name_service, constructor):
|
|
|
|
self.constructor = constructor
|
2009-08-25 19:55:48 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
bus = dbus.SessionBus()
|
|
|
|
bus_name = dbus.service.BusName(name_service, bus=bus)
|
|
|
|
object_path = get_single_process_path(name_service)
|
|
|
|
dbus.service.Object.__init__(self, bus_name, object_path)
|
|
|
|
|
2010-10-15 21:14:59 +02:00
|
|
|
@dbus.service.method('org.laptop.SingleProcess', in_signature='a{sv}')
|
2008-08-27 11:04:54 +02:00
|
|
|
def create(self, handle_dict):
|
|
|
|
handle = activityhandle.create_from_dict(handle_dict)
|
|
|
|
create_activity_instance(self.constructor, handle)
|
|
|
|
|
|
|
|
def main():
|
|
|
|
parser = OptionParser()
|
2010-10-15 21:14:59 +02:00
|
|
|
parser.add_option('-b', '--bundle-id', dest='bundle_id',
|
|
|
|
help='identifier of the activity bundle')
|
|
|
|
parser.add_option('-a', '--activity-id', dest='activity_id',
|
|
|
|
help='identifier of the activity instance')
|
|
|
|
parser.add_option('-o', '--object-id', dest='object_id',
|
|
|
|
help='identifier of the associated datastore object')
|
|
|
|
parser.add_option('-u', '--uri', dest='uri',
|
|
|
|
help='URI to load')
|
2008-08-27 11:04:54 +02:00
|
|
|
parser.add_option('-s', '--single-process', dest='single_process',
|
|
|
|
action='store_true',
|
|
|
|
help='start all the instances in the same process')
|
2010-08-16 17:27:10 +02:00
|
|
|
parser.add_option('-i', '--invited', dest='invited',
|
2010-10-05 16:36:13 +02:00
|
|
|
action='store_true', default=False,
|
2010-07-15 10:50:05 +02:00
|
|
|
help='the activity is being launched for handling an '
|
|
|
|
'invite from the network')
|
2008-08-27 11:04:54 +02:00
|
|
|
(options, args) = parser.parse_args()
|
|
|
|
|
|
|
|
logger.start()
|
|
|
|
|
|
|
|
if 'SUGAR_BUNDLE_PATH' not in os.environ:
|
|
|
|
print 'SUGAR_BUNDLE_PATH is not defined in the environment.'
|
|
|
|
sys.exit(1)
|
|
|
|
|
|
|
|
if len(args) == 0:
|
|
|
|
print 'A python class must be specified as first argument.'
|
2009-08-25 19:55:48 +02:00
|
|
|
sys.exit(1)
|
2008-08-27 11:04:54 +02:00
|
|
|
|
|
|
|
bundle_path = os.environ['SUGAR_BUNDLE_PATH']
|
|
|
|
sys.path.append(bundle_path)
|
|
|
|
|
|
|
|
bundle = ActivityBundle(bundle_path)
|
|
|
|
|
|
|
|
os.environ['SUGAR_BUNDLE_ID'] = bundle.get_bundle_id()
|
|
|
|
os.environ['SUGAR_BUNDLE_NAME'] = bundle.get_name()
|
2008-08-27 12:00:18 +02:00
|
|
|
os.environ['SUGAR_BUNDLE_VERSION'] = str(bundle.get_activity_version())
|
2008-08-27 11:04:54 +02:00
|
|
|
|
2012-06-04 17:45:30 +02:00
|
|
|
# must be done early, some activities set translations globally, SL #3654
|
2013-09-10 22:42:48 +02:00
|
|
|
activity_locale_path = os.environ.get("SUGAR_LOCALEDIR",
|
|
|
|
config.locale_path)
|
|
|
|
|
|
|
|
gettext.bindtextdomain(bundle.get_bundle_id(), activity_locale_path)
|
|
|
|
gettext.bindtextdomain('sugar-toolkit', config.locale_path)
|
|
|
|
gettext.textdomain(bundle.get_bundle_id())
|
2012-06-04 17:45:30 +02:00
|
|
|
|
2008-08-27 11:04:54 +02:00
|
|
|
splitted_module = args[0].rsplit('.', 1)
|
|
|
|
module_name = splitted_module[0]
|
|
|
|
class_name = splitted_module[1]
|
|
|
|
|
2009-08-25 19:55:48 +02:00
|
|
|
module = __import__(module_name)
|
2008-08-27 11:04:54 +02:00
|
|
|
for comp in module_name.split('.')[1:]:
|
|
|
|
module = getattr(module, comp)
|
|
|
|
|
|
|
|
activity_constructor = getattr(module, class_name)
|
|
|
|
activity_handle = activityhandle.ActivityHandle(
|
|
|
|
activity_id=options.activity_id,
|
2010-07-15 10:50:05 +02:00
|
|
|
object_id=options.object_id, uri=options.uri,
|
2010-08-16 17:27:10 +02:00
|
|
|
invited=options.invited)
|
2008-08-27 11:04:54 +02:00
|
|
|
|
|
|
|
if options.single_process is True:
|
|
|
|
sessionbus = dbus.SessionBus()
|
|
|
|
|
|
|
|
service_name = get_single_process_name(options.bundle_id)
|
|
|
|
service_path = get_single_process_path(options.bundle_id)
|
|
|
|
|
|
|
|
bus_object = sessionbus.get_object(
|
|
|
|
'org.freedesktop.DBus', '/org/freedesktop/DBus')
|
|
|
|
try:
|
|
|
|
name = bus_object.GetNameOwner(
|
|
|
|
service_name, dbus_interface='org.freedesktop.DBus')
|
|
|
|
except dbus.DBusException:
|
|
|
|
name = None
|
|
|
|
|
|
|
|
if not name:
|
2008-08-27 14:53:59 +02:00
|
|
|
SingleProcess(service_name, activity_constructor)
|
2008-08-27 11:04:54 +02:00
|
|
|
else:
|
|
|
|
single_process = sessionbus.get_object(service_name, service_path)
|
2010-10-05 16:36:13 +02:00
|
|
|
single_process.create(activity_handle.get_dict(),
|
|
|
|
dbus_interface='org.laptop.SingleProcess')
|
2008-08-27 11:04:54 +02:00
|
|
|
|
|
|
|
print 'Created %s in a single process.' % service_name
|
|
|
|
sys.exit(0)
|
|
|
|
|
|
|
|
if hasattr(module, 'start'):
|
|
|
|
module.start()
|
|
|
|
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
instance = create_activity_instance(activity_constructor, activity_handle)
|
|
|
|
|
|
|
|
if hasattr(instance, 'run_main_loop'):
|
|
|
|
instance.run_main_loop()
|
2008-08-27 11:04:54 +02:00
|
|
|
|
sugar-activity: import and make independent of sugar-toolkit GTK versions
As we move to adding support for a second UI toolkit (GTK+ 3.x),
the sugar-activity binary used by all activities must become
backend-toolkit-independent. It would be wasteful to have two backend
toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
(importing both results in an instant crash).
To achieve this, we split the existing sugar-toolkit activity/main.py:main()
functionality into two parts, moving it into the sugar-activity binary and
the Activity class as follows:
1. All toolkit-specific stuff is moved into the Activity class (i.e.
everything that interacts with GTK)
2. Everything that can be reasonably/easily moved into the Activity class
is also moved.
3. What remains is the stuff that is inherently involved with the
construction of the Activity object, not related to UI toolkits. This
is moved into the sugar-activity binary.
main.py is then removed from sugar-toolkit, and sugar-activity is moved
from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
with the toolkit itself.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
2011-12-13 20:47:33 +01:00
|
|
|
main()
|