[Sugar-devel] [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View
From: Simon Schampijer si...@laptop.org
This patch moves the ViewToolbar to the HomeWindow and removes it
from the Views respectively. This ease the transition between the
Views and simplifies the code.
The toolbar is passed as an argument at initialization of the
View in order to connect to the 'query-changed' and 'view-changed'
signals of the toolbar. The buttons to change between the Favorite
and ListView are only available in the HomeView at the moment, they
are hidden and shown when we switch between the Views.
The _FILTERED_ALPHA global is added back again to the MeshView, it
has been dropped accidentally by 13844c18b225f46b1636fc1201e020af53c60fcd.
This patch depends on the previous toolbar simplification patch [1].
Signed-off-by: Simon Schampijer si...@laptop.org
[1] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039328.html
---
src/jarabe/desktop/groupbox.py | 38 +++--
src/jarabe/desktop/homebox.py | 110 +---
src/jarabe/desktop/homewindow.py| 47 ++-
src/jarabe/desktop/meshbox.py | 56 +++---
src/jarabe/desktop/transitionbox.py | 14 +++--
src/jarabe/desktop/viewtoolbar.py | 89 -
6 files changed, 162 insertions(+), 192 deletions(-)
diff --git a/src/jarabe/desktop/groupbox.py b/src/jarabe/desktop/groupbox.py
index e58ac3f..b86cdf2 100644
--- a/src/jarabe/desktop/groupbox.py
+++ b/src/jarabe/desktop/groupbox.py
@@ -16,8 +16,6 @@
import logging
-import gtk
-
from sugar.graphics import style
from jarabe.view.buddyicon import BuddyIcon
@@ -26,13 +24,14 @@ from jarabe.model import friends
from jarabe.desktop.friendview import FriendView
from jarabe.desktop.viewcontainer import ViewContainer
from jarabe.desktop.favoriteslayout import SpreadLayout
-from jarabe.desktop.viewtoolbar import ViewToolbar
-class GroupContainer(ViewContainer):
-__gtype_name__ = 'SugarGroupContainer'
+class GroupBox(ViewContainer):
+__gtype_name__ = 'SugarGroupBox'
+
+def __init__(self, toolbar):
+logging.debug('STARTUP: Loading the group view')
-def __init__(self):
layout = SpreadLayout()
# Round off icon size to an even number to ensure that the icon
@@ -40,24 +39,8 @@ class GroupContainer(ViewContainer):
style.LARGE_ICON_SIZE ~1)
ViewContainer.__init__(self, layout, owner_icon)
-
-class GroupBox(gtk.VBox):
-__gtype_name__ = 'SugarGroupBox'
-
-def __init__(self):
-logging.debug('STARTUP: Loading the group view')
-
-gtk.VBox.__init__(self)
-
self._query = ''
-self._toolbar = ViewToolbar()
-self._toolbar.connect('query-changed', self._toolbar_query_changed_cb)
-self.pack_start(self._toolbar, expand=False)
-self._toolbar.show()
-
-self._group_container = GroupContainer()
-self.add(self._group_container)
-self._group_container.show()
+toolbar.connect('query-changed', self._toolbar_query_changed_cb)
self._friends = {}
@@ -71,7 +54,7 @@ class GroupBox(gtk.VBox):
def add_friend(self, buddy_info):
icon = FriendView(buddy_info)
-self._group_container.add(icon)
+self.add(icon)
self._friends[buddy_info.get_key()] = icon
icon.show()
@@ -80,15 +63,12 @@ class GroupBox(gtk.VBox):
def _friend_removed_cb(self, data_model, key):
icon = self._friends[key]
-self._group_container.remove(icon)
+self.remove(icon)
del self._friends[key]
icon.destroy()
def _toolbar_query_changed_cb(self, toolbar, query):
self._query = query.lower()
-for icon in self._group_container.get_children():
+for icon in self.get_children():
if hasattr(icon, 'set_filter'):
icon.set_filter(self._query)
-
-def focus_search_entry(self):
-self._toolbar.search_entry.grab_focus()
diff --git a/src/jarabe/desktop/homebox.py b/src/jarabe/desktop/homebox.py
index e4dba30..8f3963b 100644
--- a/src/jarabe/desktop/homebox.py
+++ b/src/jarabe/desktop/homebox.py
@@ -22,13 +22,11 @@ import gobject
import gtk
from sugar.graphics import style
-from sugar.graphics.radiotoolbutton import RadioToolButton
from sugar.graphics.alert import Alert
from sugar.graphics.icon import Icon
from jarabe.desktop import favoritesview
from jarabe.desktop.activitieslist import ActivitiesList
-from jarabe.desktop.viewtoolbar import ViewToolbar
_FAVORITES_VIEW = 0
_LIST_VIEW = 1
@@ -37,7 +35,7 @@ _LIST_VIEW = 1
class HomeBox(gtk.VBox):
__gtype_name__ = 'SugarHomeBox'
-def __init__(self):
+def __init__(self, toolbar):
logging.debug('STARTUP: Loading the home view')
gobject.GObject.__init__(self)
@@ -45,11 +43,8 @@ class HomeBox(gtk.VBox):
self._favorites_box = favoritesview.FavoritesBox()
self._list_view = ActivitiesList()
-
Re: [Sugar-devel] [PATCH sugar] Add toolbar to the TransitionBox
On 08/28/2012 07:24 AM, Simon Schampijer wrote: On 08/27/2012 04:29 PM, Manuel Quiñones wrote: With the new frame behaviour the toolbar was appearing and disappearing while the transition took place. this patch adds a toolbar in the transition box with a fake search entry, that is set editable=False to prevent issues. Signed-off-by: Manuel Quiñones ma...@laptop.org Nice idea! Another way of doing it would be to have the toolbar permanent in the HomeWindow. The ViewToolbar only differs in the HomeView at the moment where we add the buttons to change the layout of the icons (long term Gary and myself were discussing to add a list layout in all the Views). We would have to check how to best abstract the ViewToolbar code for that but should be doable in one way. Regards, Simon Hmm, since I had my hands in there already...:) http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039331.html Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Use the new toolbars in the Journal
Great, looking good! Thanks Gonzalo and Manuel.
For the description, maybe:
Sugar has switched to a new toolbar design in 0.86 [1]. In
sugar-toolkit-gtk3 support for the old deprecated toolbar has been
removed in 0.96 [2]. Prior to the shell port we have to use the new
style toolbar
in the Journal as well.
[1] http://wiki.sugarlabs.org/go/0.86/Notes#What.27s_new_for_developers
[2] http://wiki.sugarlabs.org/go/0.96/Notes#API
On 08/27/2012 03:21 PM, Manuel Quiñones wrote:
Initial patch provided by Gonzalo Odiard for the shell port.
Signed-off-by: Manuel Quiñones ma...@laptop.org
---
Two small hickups:
diff --git a/src/jarabe/journal/journaltoolbox.py
b/src/jarabe/journal/journaltoolbox.py
index 70e58ac..21ba9c3 100644
--- a/src/jarabe/journal/journaltoolbox.py
+++ b/src/jarabe/journal/journaltoolbox.py
@@ -38,7 +38,6 @@ from sugar.graphics.icon import Icon
from sugar.graphics.xocolor import XoColor
from sugar.graphics.alert import Alert
from sugar.graphics import iconentry
-from sugar.graphics import style
from sugar import mime
from jarabe.model import bundleregistry
@@ -66,7 +65,6 @@ _ACTION_MY_CLASS = 2
class MainToolbox(ToolbarBox):
-__gtype_name__ = 'SearchToolbar'
__gsignals__ = {
'query-changed': (gobject.SIGNAL_RUN_FIRST, gobject.TYPE_NONE,
All, the rest looks good, acked by me
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
On 08/19/2012 10:05 PM, Ajay Garg wrote:
Hi all.
Just saw Simon's patch at http://patchwork.sugarlabs.org/patch/1670/
Thereby, it's a gentle request ::
* to get this multi-select feature approved (with all the
latest feedback-changes/bug-fixes).
* to get the multi-select patch(es) reviewed.
* to get the multi-select patch(es) pushed (if all ok).
so that any such enhancements (confirmation alert before erasing, currently
in single-mode) can be easily merged (for single- AND batch-mode); and
there is minimal slogging involved that comes in with merging patches :)
Thanks and Regards,
Ajay
Hi Ajay,
first of all thanks for working on this. Yes, Sugar is moving fast those
days, you can apply your patch on top of
3aa88a85143c48b64cf57ab7c79b4531dcfa6e8b (Release 0.97.1). You can keep
working on top of that and rebase later so you don't have to keep up
with master. In any case, you need to port them to gtk3 anyhow later.
First of all, I think it would be good to send the patches directly to
the devel list (as for all I know they are currently only in patchwork)
[1] . If I missed anything, please point me to it.
Please add detailed descriptions to the patch (see how I tried and
hopefully managed to describe a big change we lately landed in [2]). Get
to the point what the patch does. Add items that don't work yet or are
critical or if you have questions or are unsure about the approach.
The good news is, the artwork and toolkit patches are easy to handle.
The icons should be cleaned up and can be landed. For the toolkit patch
I think you can use add_button fine:
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 7ed8b18..060416b 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -132,16 +132,17 @@ class JournalActivity(JournalWindow):
self._editing_mode = False
self._alert = Alert()
-self._error_alert = NButtonAlert()
-self._error_alert._populate_buttons([
-('dialog-ok', gtk.RESPONSE_OK, _('Ok'))
-])
-
-self._confirmation_alert = NButtonAlert()
-self._confirmation_alert._populate_buttons([
-('dialog-cancel', gtk.RESPONSE_CANCEL, _('Stop')),
-('dialog-ok', gtk.RESPONSE_OK, _('Continue'))
- ])
+self._error_alert = Alert()
+icon = Icon(icon_name='dialog-ok')
+self._error_alert.add_button(gtk.RESPONSE_OK, _('Ok'), icon)
+
+self._confirmation_alert = Alert()
+icon = Icon(icon_name='dialog-cancel')
+self._confirmation_alert.add_button(gtk.RESPONSE_CANCEL,
+_('Stop'), icon)
+icon = Icon(icon_name='dialog-ok')
+self._confirmation_alert.add_button(gtk.RESPONSE_OK,
+_('Continue'), icon)
We could argue that the add_button API should allow to pass in an icon
name instead of the icon directly, I don't think there is a case where
this would break. On the other hand not sure changing that now. I would
just go with the above and drop your toolkit patch.
So we are left with the shell patch basically. It is loong and invasive
:) So it will take some time. More review eyes welcome. I wonder as well
if splitting it up in sub-patches would help, but maybe is too hard at
this point.
On the design end, the work flow is good. I guess the 'uifreeze' is
meant to prevent races. Is the first time we do it in the UI. Might make
sense here. I will think about it a bit more.
Cheers,
Simon
[1] http://wiki.sugarlabs.org/go/Development_Team/Code_Review
[2]
http://git.sugarlabs.org/sugar/mainline/commit/d9fbf9db79b9abab2491ebbdc169985e38a59055
PS: something that caught my eye in journalactivity.py:
{{{
def __volume_error_cb(self, gobject, message, severity):
alert = ErrorAlert(title=severity, msg=message)
alert.connect('response', self.__alert_response_cb)
self.add_alert(alert)
alert.show()
def _volume_error_cb(self, gobject, message, severity):
self.update_error_alert(severity, message, None, None)
}}}
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Remove radius between the two sides of the GtkScale trough
On 08/27/2012 05:35 PM, Manuel Quiñones wrote: We had a radius set for all the corners of the trough, and that was making the bar rounded at the two sides of the slider. This was partially hidden below the slider. Also remove the hardcoded number for the radius. The GtkScale still needs love. Signed-off-by: Manuel Quiñones ma...@laptop.org How can I best see this change? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
Hi Simon.
Thanks for the reply !!
Please find my comments inline.
On Tue, Aug 28, 2012 at 3:13 PM, Simon Schampijer si...@schampijer.dewrote:
On 08/19/2012 10:05 PM, Ajay Garg wrote:
Hi all.
Just saw Simon's patch at
http://patchwork.sugarlabs.**org/patch/1670/http://patchwork.sugarlabs.org/patch/1670/
Thereby, it's a gentle request ::
* to get this multi-select feature approved (with all
the
latest feedback-changes/bug-fixes).
* to get the multi-select patch(es) reviewed.
* to get the multi-select patch(es) pushed (if all ok).
so that any such enhancements (confirmation alert before erasing,
currently
in single-mode) can be easily merged (for single- AND batch-mode); and
there is minimal slogging involved that comes in with merging patches :)
Thanks and Regards,
Ajay
Hi Ajay,
first of all thanks for working on this. Yes, Sugar is moving fast those
days, you can apply your patch on top of
3aa88a85143c48b64cf57ab7c79b45**31dcfa6e8b
(Release 0.97.1). You can keep working on top of that and rebase later so
you don't have to keep up with master. In any case, you need to port them
to gtk3 anyhow later.
Okies..
First of all, I think it would be good to send the patches directly to the
devel list (as for all I know they are currently only in patchwork) [1] .
If I missed anything, please point me to it.
I had already sent the patches to sugar-devel earlier :) at ::
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039054.html
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039055.html
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039056.html
As per your suggestion, I will be changing, and soon posting the changed,
version-2 sugar-patch (replying on that same thread), that would do away
with the need of the sugar-toolkit patch :)
Please add detailed descriptions to the patch (see how I tried and
hopefully managed to describe a big change we lately landed in [2]). Get to
the point what the patch does. Add items that don't work yet or are
critical or if you have questions or are unsure about the approach.
Ok, I think the bulk of the work happens in the different, segregated out
stages during a particular metadata-processing. I took care of being
verbose there as far as possible :)
Anyhow, in my version-2 patch (that would do away with the need of the
sugar-tollkit patch, as pointed by you), I will also try my hand to have a
better, unified description :)
The good news is, the artwork and toolkit patches are easy to handle. The
icons should be cleaned up and can be landed. For the toolkit patch I think
you can use add_button fine:
diff --git a/src/jarabe/journal/**journalactivity.py b/src/jarabe/journal/
**journalactivity.py
index 7ed8b18..060416b 100644
--- a/src/jarabe/journal/**journalactivity.py
+++ b/src/jarabe/journal/**journalactivity.py
@@ -132,16 +132,17 @@ class JournalActivity(JournalWindow)**:
self._editing_mode = False
self._alert = Alert()
-self._error_alert = NButtonAlert()
-self._error_alert._populate_**buttons([
-('dialog-ok', gtk.RESPONSE_OK, _('Ok'))
-])
-
-self._confirmation_alert = NButtonAlert()
-self._confirmation_alert._**populate_buttons([
-('dialog-cancel', gtk.RESPONSE_CANCEL, _('Stop')),
-('dialog-ok', gtk.RESPONSE_OK, _('Continue'))
- ])
+self._error_alert = Alert()
+icon = Icon(icon_name='dialog-ok')
+self._error_alert.add_button(**gtk.RESPONSE_OK, _('Ok'), icon)
+
+self._confirmation_alert = Alert()
+icon = Icon(icon_name='dialog-cancel'**)
+self._confirmation_alert.add_**button(gtk.RESPONSE_CANCEL,
+_('Stop'), icon)
+icon = Icon(icon_name='dialog-ok')
+self._confirmation_alert.add_**button(gtk.RESPONSE_OK,
+_('Continue'), icon)
We could argue that the add_button API should allow to pass in an icon
name instead of the icon directly, I don't think there is a case where this
would break. On the other hand not sure changing that now. I would just go
with the above and drop your toolkit patch.
+1.
So we are left with the shell patch basically. It is loong and invasive :)
So it will take some time. More review eyes welcome. I wonder as well if
splitting it up in sub-patches would help, but maybe is too hard at this
point.
Hmm.. Yes, there is a tendency for things to break.
I will be posting with a better, unified description in version-2 patch.
On the design end, the work flow is good. I guess the 'uifreeze' is meant
to prevent races.
+1.
Gary's aggressive testing produced plenty of those :D
So, freezing the UI was the only (and
[Sugar-devel] [DESIGN] Frame, new behavior for revealing/hiding the Frame with the mouse
Hi,
in 238338d4b5d6a065eb81bd118a8c0b7ca83717bf (will be in 0.97.2) we
modified the Frame hide/show with a mouse behavior to some extent:
- you can reveal the Frame by going with the cursor in one of the
hot corners
- you can hide the Frame by going with the cursor in one of the
hot corners (and the Frame is visible)
- the Frame is not hidden on mouse out (leaving the Frame)
- (as before) you can hide/reveal the Frame with the designated keys
- the Frame is hidden when you switch between activities
(todo: hide as well when resume in the Palette is clicked)
- the Frame is hidden when a zoom level is selected
- (as before) you can use 'alt-tab' to cycle through the
running activities
- drag drop is currently not working, SL #3811
One item I was looking at is the resume option in the Palette in the
activity tray in the Frame (patch attached). At current if I click on
one of those icons in the upper Frame it will do the primary action and
the Frame is hidden. Should then do the 'resume' option in the Activity
Palette do the same, when clicked resume and hide the Frame (like in the
patch)?
Regards,
Simon
diff --git a/src/jarabe/frame/activitiestray.py b/src/jarabe/frame/activitiestray.py
index d386b3b..3275186 100644
--- a/src/jarabe/frame/activitiestray.py
+++ b/src/jarabe/frame/activitiestray.py
@@ -83,7 +83,8 @@ class ActivityButton(RadioToolButton):
if self._home_activity.is_journal():
palette = JournalPalette(self._home_activity)
else:
-palette = CurrentActivityPalette(self._home_activity)
+frame = jarabe.frame.get_view()
+palette = CurrentActivityPalette(self._home_activity, frame)
palette.set_group_id('frame')
self.set_palette(palette)
diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 3195c0c..67a5ad5 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -68,9 +68,10 @@ class BasePalette(Palette):
class CurrentActivityPalette(BasePalette):
-def __init__(self, home_activity):
+def __init__(self, home_activity, frame):
self._home_activity = home_activity
BasePalette.__init__(self, home_activity)
+self._frame = frame
def setup_palette(self):
activity_name = self._home_activity.get_activity_name()
@@ -106,6 +107,7 @@ class CurrentActivityPalette(BasePalette):
def __resume_activate_cb(self, menu_item):
self._home_activity.get_window().activate(gtk.get_current_event_time())
+self._frame.hide()
def __view_source__cb(self, menu_item):
setup_view_source(self._home_activity)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View
Great work :)
So now the filtering is shared between the three views. I think this
is worth noting in the commit message.
Please push this and the previous patch (the one that this depends).
2012/8/28 Simon Schampijer si...@schampijer.de:
From: Simon Schampijer si...@laptop.org
This patch moves the ViewToolbar to the HomeWindow and removes it
from the Views respectively. This ease the transition between the
Views and simplifies the code.
The toolbar is passed as an argument at initialization of the
View in order to connect to the 'query-changed' and 'view-changed'
signals of the toolbar. The buttons to change between the Favorite
and ListView are only available in the HomeView at the moment, they
are hidden and shown when we switch between the Views.
The _FILTERED_ALPHA global is added back again to the MeshView, it
has been dropped accidentally by 13844c18b225f46b1636fc1201e020af53c60fcd.
This patch depends on the previous toolbar simplification patch [1].
Signed-off-by: Simon Schampijer si...@laptop.org
[1] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039328.html
---
src/jarabe/desktop/groupbox.py | 38 +++--
src/jarabe/desktop/homebox.py | 110
+---
src/jarabe/desktop/homewindow.py| 47 ++-
src/jarabe/desktop/meshbox.py | 56 +++---
src/jarabe/desktop/transitionbox.py | 14 +++--
src/jarabe/desktop/viewtoolbar.py | 89 -
6 files changed, 162 insertions(+), 192 deletions(-)
diff --git a/src/jarabe/desktop/groupbox.py b/src/jarabe/desktop/groupbox.py
index e58ac3f..b86cdf2 100644
--- a/src/jarabe/desktop/groupbox.py
+++ b/src/jarabe/desktop/groupbox.py
@@ -16,8 +16,6 @@
import logging
-import gtk
-
from sugar.graphics import style
from jarabe.view.buddyicon import BuddyIcon
@@ -26,13 +24,14 @@ from jarabe.model import friends
from jarabe.desktop.friendview import FriendView
from jarabe.desktop.viewcontainer import ViewContainer
from jarabe.desktop.favoriteslayout import SpreadLayout
-from jarabe.desktop.viewtoolbar import ViewToolbar
-class GroupContainer(ViewContainer):
-__gtype_name__ = 'SugarGroupContainer'
+class GroupBox(ViewContainer):
+__gtype_name__ = 'SugarGroupBox'
+
+def __init__(self, toolbar):
+logging.debug('STARTUP: Loading the group view')
-def __init__(self):
layout = SpreadLayout()
# Round off icon size to an even number to ensure that the icon
@@ -40,24 +39,8 @@ class GroupContainer(ViewContainer):
style.LARGE_ICON_SIZE ~1)
ViewContainer.__init__(self, layout, owner_icon)
-
-class GroupBox(gtk.VBox):
-__gtype_name__ = 'SugarGroupBox'
-
-def __init__(self):
-logging.debug('STARTUP: Loading the group view')
-
-gtk.VBox.__init__(self)
-
self._query = ''
-self._toolbar = ViewToolbar()
-self._toolbar.connect('query-changed',
self._toolbar_query_changed_cb)
-self.pack_start(self._toolbar, expand=False)
-self._toolbar.show()
-
-self._group_container = GroupContainer()
-self.add(self._group_container)
-self._group_container.show()
+toolbar.connect('query-changed', self._toolbar_query_changed_cb)
self._friends = {}
@@ -71,7 +54,7 @@ class GroupBox(gtk.VBox):
def add_friend(self, buddy_info):
icon = FriendView(buddy_info)
-self._group_container.add(icon)
+self.add(icon)
self._friends[buddy_info.get_key()] = icon
icon.show()
@@ -80,15 +63,12 @@ class GroupBox(gtk.VBox):
def _friend_removed_cb(self, data_model, key):
icon = self._friends[key]
-self._group_container.remove(icon)
+self.remove(icon)
del self._friends[key]
icon.destroy()
def _toolbar_query_changed_cb(self, toolbar, query):
self._query = query.lower()
-for icon in self._group_container.get_children():
+for icon in self.get_children():
if hasattr(icon, 'set_filter'):
icon.set_filter(self._query)
-
-def focus_search_entry(self):
-self._toolbar.search_entry.grab_focus()
diff --git a/src/jarabe/desktop/homebox.py b/src/jarabe/desktop/homebox.py
index e4dba30..8f3963b 100644
--- a/src/jarabe/desktop/homebox.py
+++ b/src/jarabe/desktop/homebox.py
@@ -22,13 +22,11 @@ import gobject
import gtk
from sugar.graphics import style
-from sugar.graphics.radiotoolbutton import RadioToolButton
from sugar.graphics.alert import Alert
from sugar.graphics.icon import Icon
from jarabe.desktop import favoritesview
from jarabe.desktop.activitieslist import ActivitiesList
-from jarabe.desktop.viewtoolbar import ViewToolbar
_FAVORITES_VIEW = 0
_LIST_VIEW = 1
@@ -37,7 +35,7 @@ _LIST_VIEW = 1
class HomeBox(gtk.VBox):
Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
Simon,
Mailed the (version-2) patch.
Patchwork:
http://patchwork.sugarlabs.org/patch/1707/
Sugar-Devel:
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039338.html
Note that I had sent the patch with --in-reply-to=
1345225428-12572-1-git-send-email-a...@activitycentral.com ( that is, in
continuation with the patch at http://patchwork.sugarlabs.org/patch/1662/ )
but apparently, the effect did not take place :-\
Regards,
Ajay
On Tue, Aug 28, 2012 at 4:38 PM, Ajay Garg a...@activitycentral.com wrote:
Hi Simon.
Thanks for the reply !!
Please find my comments inline.
On Tue, Aug 28, 2012 at 3:13 PM, Simon Schampijer si...@schampijer.dewrote:
On 08/19/2012 10:05 PM, Ajay Garg wrote:
Hi all.
Just saw Simon's patch at
http://patchwork.sugarlabs.**org/patch/1670/http://patchwork.sugarlabs.org/patch/1670/
Thereby, it's a gentle request ::
* to get this multi-select feature approved (with all
the
latest feedback-changes/bug-fixes).
* to get the multi-select patch(es) reviewed.
* to get the multi-select patch(es) pushed (if all
ok).
so that any such enhancements (confirmation alert before erasing,
currently
in single-mode) can be easily merged (for single- AND batch-mode); and
there is minimal slogging involved that comes in with merging patches :)
Thanks and Regards,
Ajay
Hi Ajay,
first of all thanks for working on this. Yes, Sugar is moving fast those
days, you can apply your patch on top of
3aa88a85143c48b64cf57ab7c79b45**31dcfa6e8b
(Release 0.97.1). You can keep working on top of that and rebase later so
you don't have to keep up with master. In any case, you need to port them
to gtk3 anyhow later.
Okies..
First of all, I think it would be good to send the patches directly to
the devel list (as for all I know they are currently only in patchwork) [1]
. If I missed anything, please point me to it.
I had already sent the patches to sugar-devel earlier :) at ::
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039054.html
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039055.html
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039056.html
As per your suggestion, I will be changing, and soon posting the changed,
version-2 sugar-patch (replying on that same thread), that would do away
with the need of the sugar-toolkit patch :)
Please add detailed descriptions to the patch (see how I tried and
hopefully managed to describe a big change we lately landed in [2]). Get to
the point what the patch does. Add items that don't work yet or are
critical or if you have questions or are unsure about the approach.
Ok, I think the bulk of the work happens in the different, segregated out
stages during a particular metadata-processing. I took care of being
verbose there as far as possible :)
Anyhow, in my version-2 patch (that would do away with the need of the
sugar-tollkit patch, as pointed by you), I will also try my hand to have a
better, unified description :)
The good news is, the artwork and toolkit patches are easy to handle. The
icons should be cleaned up and can be landed. For the toolkit patch I think
you can use add_button fine:
diff --git a/src/jarabe/journal/**journalactivity.py
b/src/jarabe/journal/**journalactivity.py
index 7ed8b18..060416b 100644
--- a/src/jarabe/journal/**journalactivity.py
+++ b/src/jarabe/journal/**journalactivity.py
@@ -132,16 +132,17 @@ class JournalActivity(JournalWindow)**:
self._editing_mode = False
self._alert = Alert()
-self._error_alert = NButtonAlert()
-self._error_alert._populate_**buttons([
-('dialog-ok', gtk.RESPONSE_OK, _('Ok'))
-])
-
-self._confirmation_alert = NButtonAlert()
-self._confirmation_alert._**populate_buttons([
-('dialog-cancel', gtk.RESPONSE_CANCEL, _('Stop')),
-('dialog-ok', gtk.RESPONSE_OK, _('Continue'))
- ])
+self._error_alert = Alert()
+icon = Icon(icon_name='dialog-ok')
+self._error_alert.add_button(**gtk.RESPONSE_OK, _('Ok'), icon)
+
+self._confirmation_alert = Alert()
+icon = Icon(icon_name='dialog-cancel'**)
+self._confirmation_alert.add_**button(gtk.RESPONSE_CANCEL,
+_('Stop'), icon)
+icon = Icon(icon_name='dialog-ok')
+self._confirmation_alert.add_**button(gtk.RESPONSE_OK,
+_('Continue'), icon)
We could argue that the add_button API should allow to pass in an icon
name instead of the icon directly, I don't think there is a case where this
would break. On the other hand not sure changing that now. I would just go
with the above and drop your toolkit patch.
+1.
So we are left with
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.97.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.97.1.tar.bz2 == News == * Release 0.97.1 (Manuel Quiñones) * Add testcase for Gtk buttons (Manuel Quiñones) * Generic mime types: add video mime types that are supported by Jukebox (Manuel Kaufmann) * Fix the drawing of ColorToolButton, RadioToolButton and ToggleToolButton (Manuel Quiñones) * Fix the Handle Rsvg get_width() - props.width, get_height() - props.height (Manuel Quiñones) * Use the Sugar Theme in the testsuite (Manuel Quiñones) * Revert Fix the drawing of ColorToolButton, RadioToolButton and ToggleToolButton (Manuel Quiñones) * Bundlebuilder: don't fail to package if git is not installed, OLPC #11341 (Simon Schampijer) * Fix the drawing of ColorToolButton, RadioToolButton and ToggleToolButton (Manuel Quiñones) * Fix the drawing method of _IconWidget, used by IconTray (Manuel Quiñones) * Key grabber: make grab_keys introspectable (Simon Schampijer) * Commit from Sugar Labs: Translation System by user cjl.: 38 of 40 messages translated (0 fuzzy). (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)
On 08/28/2012 02:14 PM, Manuel Quiñones wrote: So now the filtering is shared between the three views. I think this is worth noting in the commit message. Thanks for the review and catching this! I did note it in the commit message before pushing. Gary, we did discuss the following: There seem to be three options how the search now that we have a search entry in each view could work: - if you did a search in View A and then switch to View B the entry will be cleared leaving you with no search applied in B - if you did a search in View A and then switch to View B the search from A will be applied to B (behavior which landed in 0.97.2) - if you did a search in View A and then switch to View B the search from A will not be applied in B, if you switch back to A the search you did before in A has been cached and is still applied (behavior before 0.97.2) Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.97.2
The we like Toolbars - but don't forget the Frame release. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.97.2.tar.bz2 == News == * Release 0.97.2 (Simon Schampijer) * Add src/jarabe/desktop/viewtoolbar.py to POTFILES.in (Simon Schampijer) * Update Sucrose version for upcoming 0.97.2 (Simon Schampijer) * Views: move the ViewToolbar to the HomeWindow instead of having one in each View (Simon Schampijer) * HomeToolbar: reuse the new ViewToolbar implementation (Simon Schampijer) * Use the new toolbars in the Journal (Manuel Quiñones, Gonzalo Odiard) * Group View: add search toolbar (Simon Schampijer) * Frame: Drop support for XdndDirectSave in the clipboard (Daniel Narvaez) * Frame: remove unused _FRAME_HIDING_DELAY (Simon Schampijer) * Launcher: set the standard SPLASHSCREEN hint instead of our own _SUGAR_WINDOW_TYPE hint (Simon Schampijer) * Commit from Sugar Labs: Translation System by user cjl.: 388 of 388 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user aputsiaq.: 388 of 388 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 388 of 388 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 388 of 388 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 388 of 388 messages translated (0 fuzzy). (Pootle daemon) * Remove _MouseListener from the frame and cleanup, v2, SL #3820 (Simon Schampijer) * Journal: add alert to confirm before erasing an entry (Simon Schampijer) * Clipboard, dragdrop: keep notification icon up-to-date, SL #3818 (Simon Schampijer) * Fix drag and drop to the clipboard - SL #3811 (Manuel Quiñones) * Frame: new behavior for revealing/hiding the Frame with the mouse (Simon Schampijer) * Neighborhood View: reveal Palette on left click/touch instead of a primary action (Simon Schampijer) * Making the buddy icons in the Views reveal the Palette on left click or touch (Simon Schampijer) * Frame: reveal Palette on left click for device, friends and clipboard items (Simon Schampijer) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.97.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.97.1.tar.bz2 == News == * Release 0.97.1 (Manuel Quiñones) * Fix the zoom-to-width icon (Manuel Quiñones) * Add icon zoom-to-width (Manuel Quiñones)e ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 0.98 status, today's developer meeting
Hi, I want to skip today's developer meeting as I have been busy with getting 0.97.2 out of the door [1] and have a few more items on my plate I can not skip. Let's do the reporting of the status async. ===touch=== 0.97.2 is a milestone release with the changes discussed in [2] in regards to touch that could be made in advance of the Shell port has been made. Please test once it hits your build/distro/whatever and report back. ===shell port=== Now, I want to freeze the shell for changes that we can rebase the shell-port repo [3]. We are full steam ahead there, every hand that wants to help can chime in. We coordinate on #sugar. ===0.98 Features=== The biggest non-touch and shell-port feature I am aware of for this cycle is Multi-Selection and Batch Operations on Journal entries which is currently under review. That can go on async. Proxy configuration has seen some iterations already and is currently in the review queue. Has to be ported to GTK+ 3 as well. Yesterday, was the final date to accept Features, [4] is the final list. If you have any questions you would have wanted to ask in the meeting you can bring them up here. If you want to report about your progress during the last week, you can do so here as well. Cheers, Simon [1] http://wiki.sugarlabs.org/go/0.98/Roadmap [2] http://wiki.sugarlabs.org/go/Features/Touch [3] http://wiki.sugarlabs.org/go/Features/GTK3/Shell [4] http://wiki.sugarlabs.org/go/0.98/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] activity sandbox
I'd like to use Eclipse with PyDev on Windows to try to build activities. Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a chrome / firefox plugin so that I can use my existing environments without VMWare or VirtualBox? I can't find anything resembling an object model, or class diagram that shows the architectural breakdown of Sugar. Where to look? Thanks, Brad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.98 status, today's developer meeting
===0.98 Features=== The biggest non-touch and shell-port feature I am aware of for this cycle is Multi-Selection and Batch Operations on Journal entries which is currently under review. That can go on async. Proxy configuration has seen some iterations already and is currently in the review queue. Has to be ported to GTK+ 3 as well. Yesterday, was the final date to accept Features, [4] is the final list. . [4] http://wiki.sugarlabs.org/go/**0.98/Feature_List http://wiki.sugarlabs.org/go/0.98/Feature_List In this list is misssing http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support already reviewed by Design Team. Ajay, please add it, and updated the page. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] activity sandbox
On Tue, Aug 28, 2012 at 10:49 AM, blekros sugar blekros.su...@gmail.comwrote: I'd like to use Eclipse with PyDev on Windows to try to build activities. Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a chrome / firefox plugin so that I can use my existing environments without VMWare or VirtualBox? No. Sugar run in a linux os. I can't find anything resembling an object model, or class diagram that shows the architectural breakdown of Sugar. Where to look? Sadly, our documentation is not in a good shape. Today, the best doc is the code itself. Gonzalo Thanks, Brad ___ 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] 0.98 status, today's developer meeting
On Tue, Aug 28, 2012 at 7:21 PM, Gonzalo Odiard gonz...@laptop.org wrote: ===0.98 Features=== The biggest non-touch and shell-port feature I am aware of for this cycle is Multi-Selection and Batch Operations on Journal entries which is currently under review. That can go on async. Proxy configuration has seen some iterations already and is currently in the review queue. Has to be ported to GTK+ 3 as well. Yesterday, was the final date to accept Features, [4] is the final list. . [4] http://wiki.sugarlabs.org/go/**0.98/Feature_List http://wiki.sugarlabs.org/go/0.98/Feature_List In this list is misssing http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support already reviewed by Design Team. Ajay, please add it, and updated the page. Added. Sorry for the delay. I had asked Andres if it would be ok if I could take the ownership on his behalf. He was ok with it, as he was a bit time-strained. Thanks and Regards, Ajay Gonzalo ___ 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] long-press touch actions in Sugar
Hi Sridhar, On 28 Aug 2012, at 03:41, Sridhar Dhanapalan srid...@laptop.org.au wrote: It appears [1] that long-press is becoming part of the Sugar user experience on touchscreens: Touch and hold _should_ trigger full display of palette content (like a right click, no extra delay) I have some reservations [2] about long-press actions. Thanks, I'd seen your comments on the wiki. They don't seem to be very intuitive or discoverable. How are the Sugar Design Team managing this problem? So yes, I agree long press is not immediately discoverable/obvious (a similar situation as we have had with right click), though I'd disagree with you about long press intuitiveness as a gesture. Once it is discovered, I'd say it is more intuitive to use than a right click. Here are some of the UI/UX changes we are undertaking to improve on previous right click interactions, and upcoming touch support (Note: we need to support both trackpad and touch based UI interactions). - Amendment of various widgets in Sugar that only responded to right click or cursor hover (left click or a tap now raises their palettes). - Modification of a number of, but not all, Sugar widgets that have overloaded functionality (e.g. widgets with a primary action and a palette full of sub actions), so that the primary action is removed and replaced with an action to immediately expose the palette on left click or tap (provides safer UI exploration and removes need for some right click , hover, long touch interactions). - Exploratory mockup work and discussion looking at the possibilities of visually marking widgets that contain long press features (not sure if we'll land this cycle). - Long press gesture on widgets that support it will show a timed animation while you hold to provide visual feedback. You should find many of the working patches already on this mail list (if you have the chance to test any and provide feedback), and the links [1], [2], [3], [4] should help provide more background on touch related items being worked on. Feedback/review/suggestions welcome! Regards, --Gary [1] http://wiki.sugarlabs.org/go/Features/Touch/Development [2] http://wiki.sugarlabs.org/go/Design_Team/Sugar_Shell_Touch_Input [3] http://wiki.sugarlabs.org/go/Talk:Design_Team/Sugar_Shell_Touch_Input [4] http://wiki.sugarlabs.org/go/Design_Team/Activity_Touch_Input [1] http://wiki.sugarlabs.org/go/Design_Team/Sugar_Shell_Touch_Input [2] http://ux.stackexchange.com/questions/24460/press-and-hold-or-long-press-gestures-unintuitive Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ 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] [DESIGN] Views: search behavior
Simon Schampijer si...@schampijer.de writes: - if you did a search in View A and then switch to View B the search from A will not be applied in B, if you switch back to A the search you did before in A has been cached and is still applied (behavior before 0.97.2) IMO this makes the most sense to the user. The three screens look similar and it's important to share as much code as possible in the implementation, but they still are separate entities to the user. Think class vs. instance: they all behave in a similar way (class), but they're not the same thing (instance). PS: Thanks for your work on unifying the Zoom Views! Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgp9pf7p1PCTp.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Announce] No official design meeting today
Hi folks, Apologies, I'll not be able to chair a design meeting today. I'll follow up on existing [Design] email threads, and can run a meeting later this week if there is enough demand. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Announce] No official design meeting today
Ack! Please take a look at examples DESIGN thread. On Tue, Aug 28, 2012 at 10:41 AM, Gary C Martin garycmar...@googlemail.comwrote: Hi folks, Apologies, I'll not be able to chair a design meeting today. I'll follow up on existing [Design] email threads, and can run a meeting later this week if there is enough demand. Regards, --Gary ___ 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] [DESIGN] Frame, new behavior for revealing/hiding the Frame with the mouse
Hi Simon, On 28 Aug 2012, at 12:36, Simon Schampijer si...@schampijer.de wrote: Hi, in 238338d4b5d6a065eb81bd118a8c0b7ca83717bf (will be in 0.97.2) we modified the Frame hide/show with a mouse behavior to some extent: - you can reveal the Frame by going with the cursor in one of the hot corners - you can hide the Frame by going with the cursor in one of the hot corners (and the Frame is visible) - the Frame is not hidden on mouse out (leaving the Frame) - (as before) you can hide/reveal the Frame with the designated keys - the Frame is hidden when you switch between activities (todo: hide as well when resume in the Palette is clicked) - the Frame is hidden when a zoom level is selected - (as before) you can use 'alt-tab' to cycle through the running activities - drag drop is currently not working, SL #3811 One item I was looking at is the resume option in the Palette in the activity tray in the Frame (patch attached). At current if I click on one of those icons in the upper Frame it will do the primary action and the Frame is hidden. Should then do the 'resume' option in the Activity Palette do the same, when clicked resume and hide the Frame (like in the patch)? +1 for resume menu item behaviour hiding the frame. Regards, --Gary Regards, Simon frame_activitytray_resume_hide_palette.patch___ 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] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)
Hi Simon, On 28 Aug 2012, at 14:12, Simon Schampijer si...@schampijer.de wrote: On 08/28/2012 02:14 PM, Manuel Quiñones wrote: So now the filtering is shared between the three views. I think this is worth noting in the commit message. Thanks for the review and catching this! I did note it in the commit message before pushing. Gary, we did discuss the following: There seem to be three options how the search now that we have a search entry in each view could work: - if you did a search in View A and then switch to View B the entry will be cleared leaving you with no search applied in B - if you did a search in View A and then switch to View B the search from A will be applied to B (behavior which landed in 0.97.2) - if you did a search in View A and then switch to View B the search from A will not be applied in B, if you switch back to A the search you did before in A has been cached and is still applied (behavior before 0.97.2) Thanks for raising this change! I'll need to give it some more though and test the patches. My gut reaction so far would be for the clearing behaviour, second choice would be the caching behaviour. My reasons against the 0.97.2 behaviour change would be that different views contain dissimilar enough objects that a search in one is not often useful in another (e.g. searching for a buddy or access point, and switching to home), and that will drop the user in an unexpected UI state. A reason for clearing the search when switching views is that it prevents issues for novice users who leave a query in place unintentionally, and return to find a view in an unexpected state without realising they need to clear the old search query manually. Though so far, caching previous search queries in a view is just what we've been doing in the shell. FWIW: home list view is the worst offender as it shows a blank white canvas when a query has no matches, should really behave like the Journal with the 'No matching entries' UI. The 0.97.2 change may well lead to an increase in my icons are all grey/gone type support reports, especially from young users who may randomly press keys and generate a shel query without realising it. Regards, --Gary Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Activity template for HTML5/Enyo
Check the book cover. It is the Read Activity showing the EPUB of the book E-Book Enlightenment being read. Note that the page layout is quite nice and includes fancy dropcaps and art that a Kindle or a Nook would make a mess of or just ignore. So maybe, just maybe, the Read Activity could handle JavaScript in an EPUB as well. If you do Look inside the book you'll see that I had to reformat the book to leave out the art and to use a large first letter instead of the much nicer dropcap. The EPUB from archive.org has the original formatting. Okay, it make sense. So maybe instead of making custom wrappers for Activities that use HTML 5 and JS we could make non-standard EPUBs and accomplish much the same thing. Ok I see. Im going to try to integrate Enyo in an EPUB. Lionel. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar-toolkit-gtk3] Add testcase for Gtk scales
Signed-off-by: Manuel Quiñones ma...@laptop.org --- tests/graphics/scales.py | 43 +++ 1 file changed, 43 insertions(+) create mode 100644 tests/graphics/scales.py diff --git a/tests/graphics/scales.py b/tests/graphics/scales.py new file mode 100644 index 000..42b62e1 --- /dev/null +++ b/tests/graphics/scales.py @@ -0,0 +1,43 @@ +from gi.repository import Gtk + +import common + + +test = common.Test() +test.show() + +hbox = Gtk.HBox() +test.pack_start(hbox, True, True, 0) +hbox.show() + +adjustment = Gtk.Adjustment(0, 0, 10, 1, 32, 0) + +vscale = Gtk.VScale() +vscale.set_adjustment(adjustment) +hbox.pack_start(vscale, False, False, 0) +vscale.show() + +vbox = Gtk.VBox() +hbox.pack_start(vbox, True, True, 0) +vbox.show() + +hscale = Gtk.HScale() +hscale.set_adjustment(adjustment) +vbox.pack_start(hscale, False, False, 0) +hscale.show() + +adjustment_2 = Gtk.Adjustment(0, 0, 10, 1, 32, 0) +hscale_2 = Gtk.HScale() +hscale_2.set_adjustment(adjustment_2) +vbox.pack_start(hscale_2, False, False, 0) +hscale_2.show() + +adjustment_3 = Gtk.Adjustment(0, 0, 10, 1, 32, 0) +hscale_3 = Gtk.HScale() +hscale_3.set_adjustment(adjustment_3) +vbox.pack_start(hscale_3, False, False, 0) +hscale_3.show() + + +if __name__ == '__main__': +common.main(test) -- 1.7.11.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Remove radius between the two sides of the GtkScale trough
2012/8/28 Simon Schampijer si...@schampijer.de: On 08/27/2012 05:35 PM, Manuel Quiñones wrote: We had a radius set for all the corners of the trough, and that was making the bar rounded at the two sides of the slider. This was partially hidden below the slider. Also remove the hardcoded number for the radius. The GtkScale still needs love. Signed-off-by: Manuel Quiñones ma...@laptop.org How can I best see this change? I've sent a patch that adds a testcase for the Gtk sliders. Or you can see in the sliders of the color palette of toolbuttons.py testcase. Basically this changes the sliders bar from: (---)(___) To: (---|___) Removing the rounded corners in the middle. This widget still needs to be styled, the bar (the trough) is getting the height of the slider. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
