Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 18 Sep 2011, at 21:59, Marco Pesenti Gritti wrote: > Trying to answer your initial email more clearly... > > 2011/9/15 Daniel Drake : >> The transparency option seems rather simple, but is perhaps nasty in >> that it basically decides to mess around with core window stuff when >> GTK+ has its back turned. > > Without having tested, I don't think it's nasty in GTK3, it seems like > a legitimate, supported use case. > >> Also, when icons are overlapping, it seems >> like the on-top window would receive the mouse event, even if the >> mouse is physically closer to the centre of an icon that is sitting on >> a lower layer. > > Wouldn't solving this issue generally require to test if the mouse > event is contained in the widget shape? Anyway I'm not sure this is > something we need to solve now, I can't think of cases in our UI where > it's important and it would not be a regression compared to hippo. Also worth noting that, in the case of potential touch, or touch only UIs, the design needs to avoid such close overlaps between finger sized targets. Accurate masks are great for Asteroid game type collision detection but not a good requirement for fat fingered, or poor motor controlled cursor interactions. Finger and cursor click target noise are fat and round, I love to hear there are some low level 'where statistically did the user really intend to hit' type events, am I dreaming? This obviously also causes issues for targets at the screen edge, but that's another issue... --Gary > Just my $0.01. > > Marco > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
Trying to answer your initial email more clearly... 2011/9/15 Daniel Drake : > The transparency option seems rather simple, but is perhaps nasty in > that it basically decides to mess around with core window stuff when > GTK+ has its back turned. Without having tested, I don't think it's nasty in GTK3, it seems like a legitimate, supported use case. > Also, when icons are overlapping, it seems > like the on-top window would receive the mouse event, even if the > mouse is physically closer to the centre of an icon that is sitting on > a lower layer. Wouldn't solving this issue generally require to test if the mouse event is contained in the widget shape? Anyway I'm not sure this is something we need to solve now, I can't think of cases in our UI where it's important and it would not be a regression compared to hippo. Just my $0.01. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 18 September 2011 18:19, Daniel Drake wrote: > So even though one of the lower levels has changed internally, the > problem is still the same. > However, with GTK3's change to directly pass in a cairo context to the > expose/draw handler, it doesn't feel as hacky to set an alpha channel > on it. If my understanding is correct (I haven't tested) in GTK3 you should be able to get transparency by using either cairo_set_source_rgba in expose, gdk_window_set_background_rgba on a GdkWindow, or by specifying it in a theme css. None of these is an hack. At lower level what we get should be pretty much the same as hippo. I'm not sure about GTK2. I suppose it might work if X supports composite, you set an rgba colormap on the widget and you use cairo_set_source_rgba. I'm not quite sure it's worth to spend time on it because the results might vary depending on X/graphics hardware and we are going to use the client side path very soon anyway with the GTK3 port. So getting back to your question, I think we should go with the transparency option because it's not nasty but properly supported in GTK3. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Analyze]: what is translatable in ". ..."
IMHO this is a bug. Log file entries should not be translated. How would the developer make sense of a log file incomprehensible to him? - Bert - On 17.09.2011, at 16:05, Chris Leonard wrote: > On Sat, Sep 17, 2011 at 6:04 PM, samy boutayeb wrote: >> Hi again, >> >> In the activity Analyze, I wanted to localize a few mixed strings, where >> it is difficult to decide where is the translatable text and the >> untranslatable variable. >> >> For instance, in [1]: >> >> Calling .GetJoinedActivities() >> >> or in [2]: >> >> .GetProperties() -> %(props)r >> >> My guess is that in [1] one should translate "Calling" and "Buddy", and >> in [2], one should only translate "Buddy". >> >> could someone confirm what is translatable in those strings? >> > > Samy, > > The context in code is fairly easy to look up in git by using the > location string as a reference can often shed some light on strings > like this: > > From the location string: > > /home/garycmartin/Activities/Analyze.activity/ps_watcher.py:261 > > > Calling .GetJoinedActivities() > http://git.sugarlabs.org/analyze/mainline/blobs/master/ps_watcher.py#line261 > > .GetProperties() -> %(props)r > http://git.sugarlabs.org/analyze/mainline/blobs/master/ps_watcher.py#line370 > > I'm not really a Python programmer, but I think your interpretation is > correct from the overall context surrounding those lines, take a look > and judge for yourself. > > cjl > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove hippo from the frame
On Sun, Sep 18, 2011 at 6:14 PM, Marco Pesenti Gritti wrote: > On 18 Sep 2011, at 13:47, Daniel Drake wrote: >> + # ask not to be collapsed if possible >> + self.set_size_request(4 * style.GRID_CELL_SIZE, -1) > > This sucks a bit. Doesn't packing the toolbar with expand true work? If expand=True, the zoom toolbar gets given one half of the frame space, with the other half used by the activity icon list. This results in the zoom toolbar being shown in the top left, followed by a big uncomfortable gap, then the activity icon list mid way through the frame. This matches the GTK+ documentation which says: expand :TRUE if the new child is to be given extra space allocated to box. The extra space will be divided evenly between all children of box that use this option In this case we don't want even division. GTK3 may indeed be better, with widgets now able to provide both a "natural" and a "minimum" size in size requests, rather than just the single measurement they have now. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 9:38 PM, Marco Pesenti Gritti wrote: > Hey, > > isn't the problem going away with GTK 3.0? From the release notes > > "GDK has been rewritten to use ‘client-side windows’. This means that > GDK maintains its own window hierarchy and only uses X windows where > it is necessary or explicitly requested. " > > Of course it would be nice to decouple de-hippo from the gtk 3 port, > but I'm not sure there is a good solution for this with gtk 2. Interesting, thanks for pointing that out. But I wonder how much this affects my question. Just ran some experiments. Regardless of the underlying implementation (X11 window or not), some widgets still have a GdkWindow associated with them, and some do not. In order to receive clicks and mouse movement events, you need to use a widget with an underlying GdkWindow. When painted on top of each other, GdkWindow-based widgets seem to continue to occupy a rectangular region and clip overlapping widgets with their background colour. So even though one of the lower levels has changed internally, the problem is still the same. However, with GTK3's change to directly pass in a cairo context to the expose/draw handler, it doesn't feel as hacky to set an alpha channel on it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove hippo from the frame
On 18 Sep 2011, at 13:47, Daniel Drake wrote: > +# ask not to be collapsed if possible > +self.set_size_request(4 * style.GRID_CELL_SIZE, -1) This sucks a bit. Doesn't packing the toolbar with expand true work? Not a big deal anyway, hopefully we can improve things with the gtk3 layout stuff. Rest looks cool to me. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Add style for naming alert
On Sat, 2011-09-17 at 18:37 +0100, Daniel Drake wrote: > Apply a white background to the naming alert window and the entry widget. > The textbuffer widgets require a grey background still, as that is used > to draw their borders. > +# Naming alert needs white background for main window and for entry widget, > +# but other backgrounds must be left grey as they are used for drawing > borders > +widget_class "*" style "white-bg" > +widget_class "**" style "white-bg-child" > + It might be a bit better to do: widget_class "**" style "white-bg-child" and revert that again for the correct widgets. But I am fine with keeping it as is. Benjamin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Enforce white background on intro screen
On Sat, 2011-09-17 at 12:27 +0100, Daniel Drake wrote: > As part of the hippocanvas removal process, we can move intro window > theming details into the theme. The intro window has a white background > for itself and its children. Looks good. Benjamin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Thank you alsroot
On Sat, Sep 17, 2011 at 5:39 AM, Chris Leonard wrote: > Dear Translation Team Members and Developers, > > Please join me in thanking Aleksey Lim (alsroot) for giving generously > of his time and expertise to work on a number of long standing issues > we've had with our Pootle infrastructure. Thats great news, thanks a lot Aleksey! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Remove hippo from the frame
Based on earlier work by Raul Gutierrez and Walter Bender.
The tricky part here is not placing frame elements in the corners of the
screen, where grid-cell-sized squares are reserved, and also drawing
the little grey border around the inner edges of the frame.
Both of these issues are tackled with a custom container (FrameContainer)
class which provides the frame's child elements with a precisely defined
box to work in (which leaves the screen corners blank), and (like hippo)
uses cairo to draw the border on the appropriate edge.
---
src/jarabe/frame/clipboardpanelwindow.py |5 +-
src/jarabe/frame/frame.py| 16 +--
src/jarabe/frame/framewindow.py | 188 +-
src/jarabe/frame/zoomtoolbar.py |4 +
4 files changed, 140 insertions(+), 73 deletions(-)
diff --git a/src/jarabe/frame/clipboardpanelwindow.py
b/src/jarabe/frame/clipboardpanelwindow.py
index f5d537c..aefec7b 100644
--- a/src/jarabe/frame/clipboardpanelwindow.py
+++ b/src/jarabe/frame/clipboardpanelwindow.py
@@ -18,7 +18,6 @@ import logging
from urlparse import urlparse
import gtk
-import hippo
from jarabe.frame.framewindow import FrameWindow
from jarabe.frame.clipboardtray import ClipboardTray
@@ -39,8 +38,8 @@ class ClipboardPanelWindow(FrameWindow):
self._clipboard.connect('owner-change', self._owner_change_cb)
self._clipboard_tray = ClipboardTray()
-canvas_widget = hippo.CanvasWidget(widget=self._clipboard_tray)
-self.append(canvas_widget, hippo.PACK_EXPAND)
+self._clipboard_tray.show()
+self.append(self._clipboard_tray)
# Receiving dnd drops
self.drag_dest_set(0, [], 0)
diff --git a/src/jarabe/frame/frame.py b/src/jarabe/frame/frame.py
index 079eeeb..7407e18 100644
--- a/src/jarabe/frame/frame.py
+++ b/src/jarabe/frame/frame.py
@@ -18,7 +18,6 @@ import logging
import gtk
import gobject
-import hippo
from sugar.graphics import animator
from sugar.graphics import style
@@ -178,17 +177,12 @@ class Frame(object):
def _create_top_panel(self):
panel = self._create_panel(gtk.POS_TOP)
-# TODO: setting box_width and hippo.PACK_EXPAND looks like a hack to
-# me. Why hippo isn't respecting the request size of these controls?
-
zoom_toolbar = ZoomToolbar()
-panel.append(hippo.CanvasWidget(widget=zoom_toolbar,
-box_width=4 * style.GRID_CELL_SIZE))
+panel.append(zoom_toolbar, expand=False)
zoom_toolbar.show()
activities_tray = ActivitiesTray()
-panel.append(hippo.CanvasWidget(widget=activities_tray),
-hippo.PACK_EXPAND)
+panel.append(activities_tray)
activities_tray.show()
return panel
@@ -196,10 +190,8 @@ class Frame(object):
def _create_bottom_panel(self):
panel = self._create_panel(gtk.POS_BOTTOM)
-# TODO: same issue as in _create_top_panel()
devices_tray = DevicesTray()
-panel.append(hippo.CanvasWidget(widget=devices_tray),
- hippo.PACK_EXPAND)
+panel.append(devices_tray)
devices_tray.show()
return panel
@@ -208,7 +200,7 @@ class Frame(object):
panel = self._create_panel(gtk.POS_RIGHT)
tray = FriendsTray()
-panel.append(hippo.CanvasWidget(widget=tray), hippo.PACK_EXPAND)
+panel.append(tray)
tray.show()
return panel
diff --git a/src/jarabe/frame/framewindow.py b/src/jarabe/frame/framewindow.py
index c77e76c..b15b87e 100644
--- a/src/jarabe/frame/framewindow.py
+++ b/src/jarabe/frame/framewindow.py
@@ -15,11 +15,129 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import gtk
-import hippo
+from gtk import gdk
+import gobject
from sugar.graphics import style
+class FrameContainer(gtk.Container):
+"""A container class for frame panel rendering. Hosts a child 'box' where
+frame elements can be added. Excludes grid-sized squares at each end
+of the frame panel, and a space alongside the inside of the screen where
+a border is drawn."""
+
+__gtype_name__ = 'SugarFrameContainer'
+
+def __init__(self, position):
+gtk.Container.__init__(self)
+self._position = position
+
+if self.is_vertical():
+self._box = gtk.VBox()
+else:
+self._box = gtk.HBox()
+self._box.set_parent(self)
+self._box.show()
+
+def is_vertical(self):
+return self._position in (gtk.POS_LEFT, gtk.POS_RIGHT)
+
+@gobject.property
+def box(self):
+return self._box
+
+def do_realize(self):
+self.set_flags(gtk.REALIZED)
+
+self.window = gdk.Window(
+self.get_parent_window(),
+window_type=gdk.WINDOW_CHILD,
+x=self.allocation.x,
+y=self.allocation.y,
+width=self.allocation.width,
+height=self.allocation.heig
