This adds a explicit method for cleaning up the animation. Previously,
animations expected the next_frame to be called where frame=end.
That guarantee was never provided by the api. This resulted in
animations sometimes being in odd states. For example, Browse activity
had an animation that overrode the Gtk "draw" signal. If the signal
was not unbound, the animated object was mistakenly rendered after
the completion of the animation, obstructing the user's view.
This api is explicit and allows cleaner code in the animation
implementation. The clean up code goes in do_stop rather than in a
conditional of next_frame.
Many activities already have the repository url pointing to their GitHub
page - which also serves as a bug tracker for many of the projects. The
repository url is not part of the spec, but the bug tracker url is.
This commit adds the 1st pass generator for these files. It also adds
documentation about the required fields in the "activity.info"
file, as AppStream requires more metadata than most activities currently
include.
When created via "git submodules add", a submodules may have the
"/.git" path be a file rather than a directory. The bundlebuilder
previously thought that all submodules had "/.git" as a directory.
The unversioned import results in the following log noise:
/usr/lib/python2.7/site-packages/sugar3/graphics/window.py:26: PyGIWarning: GdkX11 was imported without specifying a version first. Use gi.require_version('GdkX11', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import GdkX11
Problem #1, buddy menu appears on Sugar startup on physical hardware, or
when mouse is centre of display.
Problem #2, Terminal toolbar steals keyboard focus, when mouse is left
in home view search box at activity start time.
Regressions were introduced in the port from Gtk2 to Gtk3.
Cause is enter-notify-events that arrive because cursor is already
present in widgets as they are realised and mapped.
Fix is to capture cursor position when the widget is being created, and
ignore enter-notify-event if the same position is seen.
The log message "PaletteWindowWidget popup get_visible True" is not
useful, and is removed. It can be made to occur in Terminal by repeated
right-click on any of the first three toolbar button.
Previously there was the concept of having 2 popdowns for a palette.
The first popdown showed the of tooltip the palette, and the 2nd
showed the content of the palette. However, this was confusing
to new users, and made users wait for little reason.
This commit removes the 2nd popdown. An example of this is when you
mouse over an icon to invoke the palette. Previously, it showed
the tooltip, then made you wait, then showed the content of the
palette. With this patch, the whole palette is shown at the
first popdown, making a snappy UX.
Steps to reproduce:
1. Long press on home view favorite icon (an event icon)
Expected: Palette invoker where finger is
Actuall: Palette invokes in top left corner
This is because the long press controller emits coords relative
to the widget's window, and EventIcons sometimes have their own
windows. We can't change the long press controller, as it is a
public api. But we fix this by translating the coords to the
root window coords in the CursorInvoker. Using root coords is
consistent with the right click handleing in the cursor invoker.
Steps to reproduce:
1. Long press activity icon on homeview
Expcected: Palette invokes, icon not activated
Actual: Palette invokes, icon also activated, activity launched
This was because the "activate" signal was emitted before the
palette invoker got it's signal, meaning the palette invoker couldn't
scilence the event.
Steps to reproduce:
1. Long press activity icon on homeview
Expcected: Palette invokes, icon not activated
Actual: Palette invokes, icon also activated, activity launched
This was because the "activate" signal was emitted before the
palette invoker got it's signal, meaning the palette invoker couldn't
scilence the event.
This will allow .desktops for all of the activities to be
packaged. In the future, we could ship a special launcher script
so that the user can choose the jobject to run, but for now
we just open the activity using the command specified in the
activity.info file.
If the user has a "random" telepathy connection manager
installed and running on the system (eg. telepathy idle being
active if they are chatting on irc with GNOME's Polari), activities
will crash on startup.
Steps to reproduce the crash:
1. Run Polari (eg. via the Terminal activity)
2. Join an irc channel in Polari (eg. #sugar on freenode)
3. Try to open an activity from the home view
- notice that opening any sugar3 activity will crash
The issue was caused by importing from activityfactory which caused GObject to be imported. This conflicts with GTK2. (Reported by James Cameron)
The idea is that we should create the sugar profile's activity root if it doesn't exist yet, when running outside Sugar.
