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.
Currently, the ToolInvoker code passes the button child in such a
way that the WidgetInvoker queues only the child's draw. In previous
Gtk+ versions, this magically resulted in redrawing the parent as well.
However, Gtk+ 3.20 is probably trying to save power and not randomly
redraw widgets. To fix this, we must queue the redraw of the widget
that we want to redraw explicitly.
- Handle lack of GSettings gracefully.
- Still requires sugar-datastore.
- Supports avoiding X11 docks/panels.
- Provides icons for Activity windows.
Try it outside Sugar. Go to an Activity directory and run 'sugar-activity'.
Tested it with Terminal, Finance, Write, Browse, Memorize under XFCE4.
Tested in Gnome under OLPC-OS.
Also works from Sugar Terminal Activity.
Does not affect regular Sugar operation.
This is patch v.2 -
Addresses most concerns:
- Removed commented code, sorry.
- Changed code to use profile.get_nickname and get_color where possible.
Couldn't the launcher just pass this info?
Maybe the launcher could set the activity root as well?
- It is intended to be usable from the command line also.
Should put sugar version in the environment
- It is intended to work even without Sugar Shell installed.
Why don't we always set the icon?
- On XO it might use some memory. I was concerned to degrade
performance.
Also, imports should be at the top of the file?
- Also a concern about performance on XO.
This way it is only loaded in this use case.
Maybe it is insignificant -moved as requested.
It would be nice if the changes to the POT for sugar-toolkit-gtk3
could be incorporated in this pull request, please.
- There were no changes to POT files as part of this patch. Maybe
it is worth translating low level command line tools, not sure.
Suggest packaged activities might also provide .desktop files.
- Intriguing but not sure within scope of this patch. You mean generate
a .desktop file automatically as an option? Sounds nice!
Suggest sugar-activity might also accept path to unpacked bundle.
- Implemented!
