Re: [Sugar-devel] USB permissions for educational robots
roughly speaking, we chose the dialout group because a) it's a
traditional group for access to UNIX serial devices, b) many USB
devices that activities need access to are actually serial devices,
and c) the olpc user is already a member of dialout. is it
important that Lego devices be protected by a separate group
membership?
the current udev rule isn't added by Sugar -- it's in the olpc-utils
rpm distributed by OLPC. we can add a modified rule once we agree
on what it should look like.
i can't remember at the moment where the default passwd and group
files come from -- if the rule needs a new group, we'll need to modify
those files as well.
paul
alan jhonn aguiar schwyn wrote:
Hi,
In a few of months, all our High Schools (of Uruguay) will receive and
robotic
kit (Lego).
At Universidad de la República, Facultad de Ingeniería we are
workingwith
it and the XO...
http://www.youtube.com/watch?v=S8HRbDLO7LM
In other parallel road, we are working on a 2.0 version of the Butia Robot
www.fing.edu.uy/inco/proyectos/butia
That uses USB4all IO board which resulted from a thesis given at
ourUniversity
(also will have arduino compatibility)
http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb/
USB4all is based on 18f4550 pic.The vendor is Microchip,
SYSFS{idVendor}==04d8And have: productID=0x000b //bootloader
productID=0x000c //pic18f4550 generic comunication
The actual Sugar image, only have permissions for LEGO WeDo.
If you see in: /etc/udev/rules.d you find the correspondient:
30-olpc-wedo.rules.
The file add this rule:
SYSFS{idVendor}==0694, SYSFS{idProduct}==0003, GROUP=dialout,
MODE=0660
This means: 0694 is LEGO 0003 the model: WeDo
To the NXT we need add: {idProduct}==0002
But, for each model add a new line.. not is a good form..
Exist another way, a generic rule:
BUS==usb, SYSFS{idVendor}==0694, GROUP=lego, MODE=0660
That says: if is USB and fabricated by 0694 (LEGO) lets 0660 (4: read+ 2:
write)
If add this permissions to lego group, we need create it..
But, we don't make it, an use an existing group like root? Or another...
Suggestions?
We can make a generic group robot that have permissions for: lego wedo,
lego
nxt, butia, etc...
Regards!
Alan part 2 text/plain
129
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] USB permissions for educational robots
I think martin_xsa wanted create a group robots too,
as part of http://wiki.laptop.org/go/11.2.0/Robotics_plan
Gonzalo
On Tue, Jan 3, 2012 at 11:12 AM, Paul Fox p...@laptop.org wrote:
roughly speaking, we chose the dialout group because a) it's a
traditional group for access to UNIX serial devices, b) many USB
devices that activities need access to are actually serial devices,
and c) the olpc user is already a member of dialout. is it
important that Lego devices be protected by a separate group
membership?
the current udev rule isn't added by Sugar -- it's in the olpc-utils
rpm distributed by OLPC. we can add a modified rule once we agree
on what it should look like.
i can't remember at the moment where the default passwd and group
files come from -- if the rule needs a new group, we'll need to modify
those files as well.
paul
alan jhonn aguiar schwyn wrote:
Hi,
In a few of months, all our High Schools (of Uruguay) will receive and
robotic
kit (Lego).
At Universidad de la República, Facultad de Ingeniería we are
workingwith
it and the XO...
http://www.youtube.com/watch?v=S8HRbDLO7LM
In other parallel road, we are working on a 2.0 version of the Butia
Robot
www.fing.edu.uy/inco/proyectos/butia
That uses USB4all IO board which resulted from a thesis given at
ourUniversity
(also will have arduino compatibility)
http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb/
USB4all is based on 18f4550 pic.The vendor is Microchip,
SYSFS{idVendor}==04d8And have: productID=0x000b //bootloader
productID=0x000c //pic18f4550 generic comunication
The actual Sugar image, only have permissions for LEGO WeDo.
If you see in: /etc/udev/rules.d you find the correspondient:
30-olpc-wedo.rules.
The file add this rule:
SYSFS{idVendor}==0694, SYSFS{idProduct}==0003, GROUP=dialout,
MODE=0660
This means: 0694 is LEGO 0003 the model: WeDo
To the NXT we need add: {idProduct}==0002
But, for each model add a new line.. not is a good form..
Exist another way, a generic rule:
BUS==usb, SYSFS{idVendor}==0694, GROUP=lego, MODE=0660
That says: if is USB and fabricated by 0694 (LEGO) lets 0660 (4: read+
2: write)
If add this permissions to lego group, we need create it..
But, we don't make it, an use an existing group like root? Or
another...
Suggestions?
We can make a generic group robot that have permissions for: lego
wedo, lego
nxt, butia, etc...
Regards!
Alan part 2 text/plain
129
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] 0.96 schedule, freeze reminders
Hi, I hope everyone had a great start into 2012 and a well deserved rest and accumulated new energy for the upcoming joys, challenges and surprises of the new year. First of all I want to highlight that the API/ABI and Feature freeze of the 0.96 development cycle are approaching, the deadline is the 30th of January 2012. API/ABI OpenJan 30 2012 Feature OpenJan 30 2012 Please see [1] for the full schedule of the 0.96 development cycle. The Feature owners [2] should make sure their code has been submitted early enough so that the maintainers have time to review it. Please keep that in mind when looking at the dates. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List#Accepted_Features_for_0.96 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] 0.96 schedule, freeze reminders
I think the feature needing more work right now is Write_to_journal_anytime [1] Are we waiting design decisions? What can we do now to have this feature in time? Gonzalo 1] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime On Tue, Jan 3, 2012 at 11:19 AM, Simon Schampijer si...@schampijer.dewrote: Hi, I hope everyone had a great start into 2012 and a well deserved rest and accumulated new energy for the upcoming joys, challenges and surprises of the new year. First of all I want to highlight that the API/ABI and Feature freeze of the 0.96 development cycle are approaching, the deadline is the 30th of January 2012. API/ABI OpenJan 30 2012 Feature OpenJan 30 2012 Please see [1] for the full schedule of the 0.96 development cycle. The Feature owners [2] should make sure their code has been submitted early enough so that the maintainers have time to review it. Please keep that in mind when looking at the dates. Regards, Simon [1] http://wiki.sugarlabs.org/go/**0.96/Roadmaphttp://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/**0.96/Feature_List#Accepted_** Features_for_0.96http://wiki.sugarlabs.org/go/0.96/Feature_List#Accepted_Features_for_0.96 __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://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] USB permissions for educational robots
roughly speaking, we chose the dialout group because a) it's a traditional group for access to UNIX serial devices, b) many USB devices that activities need access to are actually serial devices, and c) the olpc user is already a member of dialout. is it important that Lego devices be protected by a separate group membership? No.. was only a idea... Seeing the Wiki appears this: http://wiki.laptop.org/go/Robots/udev_rules In the article: http://wiki.laptop.org/go/11.2.0/Robotics_plan Can be add USB4all in the list? http://wiki.laptop.org/go/11.2.0/Robotics_plan#Dev_and_test_matrix the current udev rule isn't added by Sugar -- it's in the olpc-utils rpm distributed by OLPC. we can add a modified rule once we agree on what it should look like. +1___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] USB permissions for educational robots
Please add it, with the information needed to continue the work. Contact info too if possible. Gonzalo In the article: http://wiki.laptop.org/go/11.2.0/Robotics_plan Can be add USB4all in the list? http://wiki.laptop.org/go/11.2.0/Robotics_plan#Dev_and_test_matrix the current udev rule isn't added by Sugar -- it's in the olpc-utils rpm distributed by OLPC. we can add a modified rule once we agree on what it should look like. +1 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Store and restore session for each tab
On 20/12/11 14:54, Manuel Quiñones wrote:
For going to a specific item in the history, it uses go_back() method
of WebKit.WebView. I tried also with WebKit.WebHistoryItem go_back(),
seemed the proper solution, but the page wouldn't update.
Using webkit_web_view_go_back [1] is the right thing to do here.
Epiphany is doing the same. Tbh, I am not sure I understand what
WebKit.WebHistoryItem go_back() is doing, I was trying to dig into the
Webkit code but stopped after a while of poking around...
I have a counter proposal for your patch (applies on top of your patch)
which does the following things:
* the sessionstore code is moved into Browser, we do have
set_history_index/get_history_index already there, the TabbedView does
use that path for their requests about the history
* I did rename a few bits s/session/history and the return value from
self.get_back_forward_list() I use back_forward_list as variable
* I folded _get_history and _set_history into their appropriate 'mother'
methods
* I tried to make set_history_index a bit cleaner, the API provided by
webkitgtk does not seem to cleanly allow our usage like:
get_current_item_index and go_to_back_forward_item(index) also the API
does seem to miss a back_forward_list.get_length() (see the code we have
to do in _items_history_as_list) there only exist a
back_forward_list.get_back_length() and
back_forward_list.get_forward_length().
That should be pretty much it, let me know what you think,
Simon
Signed-off-by: Manuel Quiñonesma...@laptop.org
---
browser.py | 12
sessionstore.py | 91
---
webactivity.py | 17 --
3 files changed, 66 insertions(+), 54 deletions(-)
diff --git a/browser.py b/browser.py
index 2c3b4f8..69713ca 100644
--- a/browser.py
+++ b/browser.py
@@ -31,8 +31,9 @@ from sugar3.activity import activity
from sugar3.graphics import style
from sugar3.graphics.icon import Icon
+import sessionstore
+
# FIXME
-# import sessionstore
# from palettes import ContentInvoker
# from sessionhistory import HistoryListener
# from progresslistener import ProgressListener
@@ -291,7 +292,8 @@ class TabbedView(BrowserNotebook):
def get_session(self):
tab_sessions = []
for index in xrange(0, self.get_n_pages()):
-browser = self.get_nth_page(index)
+scrolled_window = self.get_nth_page(index)
+browser = scrolled_window.get_child()
tab_sessions.append(sessionstore.get_session(browser))
return tab_sessions
@@ -463,12 +465,10 @@ class Browser(WebKit.WebView):
markupDocumentViewer.fullZoom -= _ZOOM_AMOUNT
def get_history_index(self):
-return self.web_navigation.sessionHistory.index
+return sessionstore.get_history_index(self)
def set_history_index(self, index):
-if index == -1:
-return
-self.web_navigation.gotoIndex(index)
+return sessionstore.set_history_index(self, index)
def open_new_tab(self, url):
self.emit('new-tab', url)
diff --git a/sessionstore.py b/sessionstore.py
index 73edb24..589b44d 100644
--- a/sessionstore.py
+++ b/sessionstore.py
@@ -14,61 +14,76 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
-# Based on
-#
http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore
-
import logging
-from xpcom import components
-from xpcom.components import interfaces
+from gi.repository import WebKit
def get_session(browser):
-session_history = browser.web_navigation.sessionHistory
-
-if session_history.count == 0:
+session_history = browser.get_back_forward_list()
+if session_history.get_back_length() == 0:
return ''
return _get_history(session_history)
def set_session(browser, data):
-_set_history(browser.web_navigation.sessionHistory, data)
-
-if data:
-browser.web_navigation.gotoIndex(len(data) - 1)
-else:
-browser.load_uri('about:blank')
+session_history = browser.get_back_forward_list()
+_set_history(session_history, data)
def _get_history(history):
-logging.debug('%r', history.count)
+items_list = _items_history_as_list(history)
+logging.debug('history count: %r', len(items_list))
entries_dest = []
-for i in range(0, history.count):
-entry_orig = history.getEntryAtIndex(i, False)
-entry_dest = {'url':entry_orig.URI.spec,
- 'title': entry_orig.title}
-
+for item in items_list:
+entry_dest = {'url': item.get_uri(),
+ 'title': item.get_title()}
entries_dest.append(entry_dest)
return entries_dest
def _set_history(history, history_data):
-
[Sugar-devel] [DESIGN] Write to Journal Anytime
Gary, Christian, et al., We are hopefully going to land some variant of the Write to Journal Anytime patch in Sugar 0.96 [1]. I'd like to discuss the details before jumping back into the code. The current plan of record is essentially to make a modal display of the Journal expanded entry (detail view) available on demand from a button on the activity toolbar (grabbing space freed up by the elimination of the Keep button). This is essentially what I mocked up about two years ago. While we may have had Design Team consensus on this plan in January 2011, I remain skeptical. The problems I see with this approach are: (1) the user cannot see their current work while the model window is displayed -- since presumably the goal is to write about what you are working on, this seems problematic; (2) most of the fields in the detail view are irrelevant to the task of taking notes; (3) some of the fields, e.g., title, already have mechanisms for change; (4) many of the fields are not human-editable, e.g., preview image, collabarators For these reasons and my general dislike of modal interfaces, I suggest a simple alternative: a text entry in the toolbar that lets you add notes to the description field directly from the toolbar. Simon (?) mocked this up a few years back and I think it meets the needs of the run-time access to note taking. Editing the notes can be done from the Journal expanded entry, which could be invoked from the currently unused Bulletin Board key (or, naturally, from the Journal itself). Would you have time to discuss this in more detail anytime in the coming week or two? regards. -walter [1] http://wiki.sugar labs.org/go/Features/Talk:Write_to_journal_anytime [2] see numerous links from ^^ -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Free Terminal?
On Tue, Dec 20, 2011 at 1:37 PM, Samuel Klein meta...@gmail.com wrote: Terminal is currently hidden by default on many builds. How about unhiding it or replacing it with an activity that offers more of an intro to the command line? It is an important tool for understanding how your computer works. But it is also an _advanced_ tool, and a dangerous tool. It breaks one of the core principles of Sugar -- it is easy to _break_ stuff. So it is fitting that it sits a bit hidden. Just like your swiss knife has the sharp blades folded in while in your pocket. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Write to Journal Anytime
Hi Walter--yes, I have time to discuss this on the weekend (Sunday?). Let me know if we can use our original timeslot at 10am ET. Christian -- From: Walter Bender Sent: 1/3/2012 11:04 AM To: Walter Bender; Sugar-dev Devel Cc: Gonzalo Odiard; manuel quiñones; Simon Schampijer; Gary C Martin; Christian Marc Schmidt Subject: [DESIGN] Write to Journal Anytime Gary, Christian, et al., We are hopefully going to land some variant of the Write to Journal Anytime patch in Sugar 0.96 [1]. I'd like to discuss the details before jumping back into the code. The current plan of record is essentially to make a modal display of the Journal expanded entry (detail view) available on demand from a button on the activity toolbar (grabbing space freed up by the elimination of the Keep button). This is essentially what I mocked up about two years ago. While we may have had Design Team consensus on this plan in January 2011, I remain skeptical. The problems I see with this approach are: (1) the user cannot see their current work while the model window is displayed -- since presumably the goal is to write about what you are working on, this seems problematic; (2) most of the fields in the detail view are irrelevant to the task of taking notes; (3) some of the fields, e.g., title, already have mechanisms for change; (4) many of the fields are not human-editable, e.g., preview image, collabarators For these reasons and my general dislike of modal interfaces, I suggest a simple alternative: a text entry in the toolbar that lets you add notes to the description field directly from the toolbar. Simon (?) mocked this up a few years back and I think it meets the needs of the run-time access to note taking. Editing the notes can be done from the Journal expanded entry, which could be invoked from the currently unused Bulletin Board key (or, naturally, from the Journal itself). Would you have time to discuss this in more detail anytime in the coming week or two? regards. -walter [1] http://wiki.sugar labs.org/go/Features/Talk:Write_to_journal_anytime [2] see numerous links from ^^ -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Write to Journal Anytime
On Tue, Jan 3, 2012 at 3:04 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Walter--yes, I have time to discuss this on the weekend (Sunday?). Let me know if we can use our original timeslot at 10am ET. Works for me :) -walter Christian From: Walter Bender Sent: 1/3/2012 11:04 AM To: Walter Bender; Sugar-dev Devel Cc: Gonzalo Odiard; manuel quiñones; Simon Schampijer; Gary C Martin; Christian Marc Schmidt Subject: [DESIGN] Write to Journal Anytime Gary, Christian, et al., We are hopefully going to land some variant of the Write to Journal Anytime patch in Sugar 0.96 [1]. I'd like to discuss the details before jumping back into the code. The current plan of record is essentially to make a modal display of the Journal expanded entry (detail view) available on demand from a button on the activity toolbar (grabbing space freed up by the elimination of the Keep button). This is essentially what I mocked up about two years ago. While we may have had Design Team consensus on this plan in January 2011, I remain skeptical. The problems I see with this approach are: (1) the user cannot see their current work while the model window is displayed -- since presumably the goal is to write about what you are working on, this seems problematic; (2) most of the fields in the detail view are irrelevant to the task of taking notes; (3) some of the fields, e.g., title, already have mechanisms for change; (4) many of the fields are not human-editable, e.g., preview image, collabarators For these reasons and my general dislike of modal interfaces, I suggest a simple alternative: a text entry in the toolbar that lets you add notes to the description field directly from the toolbar. Simon (?) mocked this up a few years back and I think it meets the needs of the run-time access to note taking. Editing the notes can be done from the Journal expanded entry, which could be invoked from the currently unused Bulletin Board key (or, naturally, from the Journal itself). Would you have time to discuss this in more detail anytime in the coming week or two? regards. -walter [1] http://wiki.sugar labs.org/go/Features/Talk:Write_to_journal_anytime [2] see numerous links from ^^ -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Abacus-31
Activity Homepage: http://activities.sugarlabs.org/addon/4293 Sugar Platform: 0.96 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/27807/abacus-31.xo Release notes: 31 GTK-3 support NOTE: This version only works on Sugar v0.96+. Please continue to use V30 if you are running an older version of Sugar. (Unless you are a developer, you most likely are *not* running 0.96+ as per this release in January 2012.) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Abacus V31
I've released v31 of Abacus [1]. This is a GTK-3 version of the activity, intended for Sugar 0.96 use only. enjoy. -walter [1] http://download.sugarlabs.org/sources/honey/Abacus/Abacus-31.tar.bz2 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Preferred way to add touch to Sugar apps
What is the preferred API for adding touchscreen (or mouse) support to a Sugar activity ? Ideally it would support multitouch and provide simple gesture support, but I'll settle for much less :-) Fedora 15 or earlier please, this is for ARM. Cheers, wad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Store and restore session for each tab
2012/1/3 Simon Schampijer si...@schampijer.de: On 20/12/11 14:54, Manuel Quiñones wrote: For going to a specific item in the history, it uses go_back() method of WebKit.WebView. I tried also with WebKit.WebHistoryItem go_back(), seemed the proper solution, but the page wouldn't update. Using webkit_web_view_go_back [1] is the right thing to do here. Epiphany is doing the same. Tbh, I am not sure I understand what WebKit.WebHistoryItem go_back() is doing, I was trying to dig into the Webkit code but stopped after a while of poking around... This was a bit confusing for me, I thought webkit would have a better way to iterate over the history of visited pages, but it doesn't. Happy to hear Epiphany does the same. I have a counter proposal for your patch (applies on top of your patch) which does the following things: * the sessionstore code is moved into Browser, we do have set_history_index/get_history_index already there, the TabbedView does use that path for their requests about the history I agree, there is no reason for a separate py file with that code. * I did rename a few bits s/session/history and the return value from self.get_back_forward_list() I use back_forward_list as variable Looks much better now. I was respecting the old code names without a reason. * I folded _get_history and _set_history into their appropriate 'mother' methods I agree. * I tried to make set_history_index a bit cleaner, the API provided by webkitgtk does not seem to cleanly allow our usage like: get_current_item_index and go_to_back_forward_item(index) also the API does seem to miss a back_forward_list.get_length() (see the code we have to do in _items_history_as_list) there only exist a back_forward_list.get_back_length() and back_forward_list.get_forward_length(). This is a much nicer way to set the history index! That should be pretty much it, let me know what you think, Great improvement over my patch, Simon. I only have to remove the import of sessionstore in browse.py to test yours. I will rebase your patch for current Browse code and resend. Cheers, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Preferred way to add touch to Sugar apps
On Jan 3, 2012, at 9:16 PM, Marek Vasut wrote: What is the preferred API for adding touchscreen (or mouse) support to a Sugar activity ? Ideally it would support multitouch and provide simple gesture support, but I'll settle for much less :-) Fedora 15 or earlier please, this is for ARM. Cheers, wad The 1.75 XO has a touchscreen ? No, but the A-prototypes of the XO-3 do. Cheers, wad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Preferred way to add touch to Sugar apps
No, but the A-prototypes of the XO-3 do. I want one! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Preferred way to add touch to Sugar apps
On Jan 3, 2012, at 9:08 PM, Walter Bender wrote: On Tue, Jan 3, 2012 at 9:04 PM, John Watlington w...@laptop.org wrote: What is the preferred API for adding touchscreen (or mouse) support to a Sugar activity ? Should just work. The activity was limited to keyboard input in the past. But it really wants gesture based input, not buttons on the screen. Supporting mouse clicks would be a way of doing it in a backwards compatible way. Cheers, wad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH browse] Improve session store and restore
This is the review from Simon Schampijer of commit
14102bcd65f015dcbf12d1406df8ef7ffb64d13d .
* the sessionstore code is moved into Browser, we do have
set_history_index/get_history_index already there, the TabbedView
does use that path for their requests about the history
* Rename a few bits s/session/history and the return value from
self.get_back_forward_list() Use back_forward_list as variable
* Fold _get_history and _set_history into their appropriate 'mother'
methods
* Make set_history_index a bit cleaner, the API provided by webkitgtk
does not seem to cleanly allow our usage like:
get_current_item_index and go_to_back_forward_item(index) also the
API does seem to miss a back_forward_list.get_length() (see the code
we have to do in _items_history_as_list) there only exist a
back_forward_list.get_back_length() and
back_forward_list.get_forward_length().
Signed-off-by: Manuel Quiñones ma...@laptop.org
---
browser.py | 86 +++-
sessionstore.py | 89 ---
webactivity.py |4 +-
3 files changed, 66 insertions(+), 113 deletions(-)
delete mode 100644 sessionstore.py
diff --git a/browser.py b/browser.py
index 5d5dc98..f6efe26 100644
--- a/browser.py
+++ b/browser.py
@@ -31,8 +31,6 @@ from sugar3.activity import activity
from sugar3.graphics import style
from sugar3.graphics.icon import Icon
-import sessionstore
-
# FIXME
# from palettes import ContentInvoker
# from sessionhistory import HistoryListener
@@ -289,27 +287,27 @@ class TabbedView(BrowserNotebook):
current_browser = GObject.property(type=object,
getter=_get_current_browser)
-def get_session(self):
-tab_sessions = []
+def get_history(self):
+tab_histories = []
for index in xrange(0, self.get_n_pages()):
scrolled_window = self.get_nth_page(index)
browser = scrolled_window.get_child()
-tab_sessions.append(sessionstore.get_session(browser))
-return tab_sessions
+tab_histories.append(browser.get_history())
+return tab_histories
-def set_session(self, tab_sessions):
-if tab_sessions and isinstance(tab_sessions[0], dict):
-# Old format, no tabs
-tab_sessions = [tab_sessions]
+def set_history(self, tab_histories):
+if tab_histories and isinstance(tab_histories[0], dict):
+ # Old format, no tabs
+tab_histories = [tab_histories]
while self.get_n_pages():
self.remove_page(self.get_n_pages() - 1)
-for tab_session in tab_sessions:
+for tab_history in tab_histories:
browser = Browser()
browser.connect('new-tab', self.__new_tab_cb)
self._append_tab(browser)
-sessionstore.set_session(browser, tab_session)
+browser.set_history(tab_history)
Gtk.rc_parse_string('''
@@ -421,11 +419,61 @@ class Browser(WebKit.WebView):
texttosuburi = cls.getService(interfaces.nsITextToSubURI)
return texttosuburi.unEscapeURIForUI(uri.originCharset, uri.spec)
-def get_session(self):
-return sessionstore.get_session(self)
+def get_history(self):
+Return the browsing history of this browser.
+back_forward_list = self.get_back_forward_list()
+if back_forward_list.get_back_length() == 0:
+return ''
+
+items_list = self._items_history_as_list(back_forward_list)
+history = []
+for item in items_list:
+history.append({'url': item.get_uri(),
+'title': item.get_title()})
+
+return history
+
+def set_history(self, history):
+Restore the browsing history for this browser.
+back_forward_list = self.get_back_forward_list()
+back_forward_list.clear()
+for entry in history:
+uri, title = entry['url'], entry['title']
+history_item = WebKit.WebHistoryItem.new_with_data(uri, title)
+back_forward_list.add_item(history_item)
+
+def get_history_index(self):
+Return the index of the current item in the history.
+back_forward_list = self.get_back_forward_list()
+history_list = self._items_history_as_list(back_forward_list)
+current_item = back_forward_list.get_current_item()
+return history_list.index(current_item)
-def set_session(self, data):
-return sessionstore.set_session(self, data)
+def set_history_index(self, index):
+Go to the item in the history specified by the index.
+back_forward_list = self.get_back_forward_list()
+if back_forward_list.get_back_length() != 0:
+current_item = index - back_forward_list.get_back_length()
+item = back_forward_list.get_nth_item(current_item)
+if item is not None:
+
Re: [Sugar-devel] [DESIGN] Write to Journal Anytime
Hi, 2012/1/3 Walter Bender walter.ben...@gmail.com: Gary, Christian, et al., We are hopefully going to land some variant of the Write to Journal Anytime patch in Sugar 0.96 [1]. I'd like to discuss the details before jumping back into the code. The current plan of record is essentially to make a modal display of the Journal expanded entry (detail view) available on demand from a button on the activity toolbar (grabbing space freed up by the elimination of the Keep button). This is essentially what I mocked up about two years ago. While we may have had Design Team consensus on this plan in January 2011, I remain skeptical. The problems I see with this approach are: (1) the user cannot see their current work while the model window is displayed -- since presumably the goal is to write about what you are working on, this seems problematic; (2) most of the fields in the detail view are irrelevant to the task of taking notes; (3) some of the fields, e.g., title, already have mechanisms for change; (4) many of the fields are not human-editable, e.g., preview image, collabarators For these reasons and my general dislike of modal interfaces, I suggest a simple alternative: a text entry in the toolbar that lets you add notes to the description field directly from the toolbar. Simon (?) mocked this up a few years back and I think it meets the needs of the run-time access to note taking. Editing the notes can be done from the Journal expanded entry, which could be invoked from the currently unused Bulletin Board key (or, naturally, from the Journal itself). I agree, the simple text entry pop-up is much better than the modal dialog. This description entry should allow at least 5 lines paragraph and it shouldn't be too thin. And maybe skip the modal dialog when stopping the activity if the description entry has been filled? -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Write to Journal Anytime
2012/1/3 Manuel Quiñones ma...@laptop.org: Hi, 2012/1/3 Walter Bender walter.ben...@gmail.com: Gary, Christian, et al., We are hopefully going to land some variant of the Write to Journal Anytime patch in Sugar 0.96 [1]. I'd like to discuss the details before jumping back into the code. The current plan of record is essentially to make a modal display of the Journal expanded entry (detail view) available on demand from a button on the activity toolbar (grabbing space freed up by the elimination of the Keep button). This is essentially what I mocked up about two years ago. While we may have had Design Team consensus on this plan in January 2011, I remain skeptical. The problems I see with this approach are: (1) the user cannot see their current work while the model window is displayed -- since presumably the goal is to write about what you are working on, this seems problematic; (2) most of the fields in the detail view are irrelevant to the task of taking notes; (3) some of the fields, e.g., title, already have mechanisms for change; (4) many of the fields are not human-editable, e.g., preview image, collabarators For these reasons and my general dislike of modal interfaces, I suggest a simple alternative: a text entry in the toolbar that lets you add notes to the description field directly from the toolbar. Simon (?) mocked this up a few years back and I think it meets the needs of the run-time access to note taking. Editing the notes can be done from the Journal expanded entry, which could be invoked from the currently unused Bulletin Board key (or, naturally, from the Journal itself). I agree, the simple text entry pop-up is much better than the modal dialog. This description entry should allow at least 5 lines paragraph and it shouldn't be too thin. And maybe skip the modal dialog when stopping the activity if the description entry has been filled? I'd concede removing the modal dialog altogether, as long as there is some way to file a commit message from within the activity. -walter -- .. manuq .. -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SugarLabs server - web page
Hi, Many times, I wondered, what activities had to Sugar page SL (SugarLabs). But when you arelooking for, not is easily to find the activities that are not public. Furthermore, when adding anew activity, you do not know if there is already a similar (even the same) on the server.So I started making a list of everything I had in the server: http://download.sugarlabs.org/activities/ Is a simple system: a folder for an activity and after, in the web, with the same number: thepage of the activity.For example: the activity I know America was in the server in: http://download.sugarlabs.org/activities/4464/And in SugarLabs: http://activities.sugarlabs.org/en-US/sugar/addon/4464 When I check all the files, I encountered many interesting things..Activities that did not even have a page on SL... Duplicate activities/files..So we have supplemented the list with that information.In the first column, see the id that is automatically generated on the server. In the second columnshows the name of the activity that is in that folder. In the spaces are blank, because there are nosuch folders on the server. In the column Notes are cases in which there are empty folders.The third column Page indicates the status of that activity in SL. Green means it is public.Orange means it is as Experimental. Red means there is no page for this activity!With the same color, I try to show the duplicate files.. Who is the maintainer of the site / server? File attached: https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dFJjNE9TemZUUGtzLVNEQnF4UlIwQkE Regards Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SugarLabs server - web page
I've added a column for L10n. ther are some uncertainties. tr.sl.o = our Pootle instance pending = awaiting upload to Pootle gnome = Gnome Damned Lies server cjl On Tue, Jan 3, 2012 at 11:20 PM, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Hi, Many times, I wondered, what activities had to Sugar page SL (SugarLabs). But when you are looking for, not is easily to find the activities that are not public. Furthermore, when adding a new activity, you do not know if there is already a similar (even the same) on the server. So I started making a list of everything I had in the server: http://download.sugarlabs.org/activities/ Is a simple system: a folder for an activity and after, in the web, with the same number: the page of the activity. For example: the activity I know America was in the server in: http://download.sugarlabs.org/activities/4464/ And in SugarLabs: http://activities.sugarlabs.org/en-US/sugar/addon/4464 When I check all the files, I encountered many interesting things.. Activities that did not even have a page on SL... Duplicate activities/files.. So we have supplemented the list with that information. In the first column, see the id that is automatically generated on the server. In the second column shows the name of the activity that is in that folder. In the spaces are blank, because there are no such folders on the server. In the column Notes are cases in which there are empty folders. The third column Page indicates the status of that activity in SL. Green means it is public. Orange means it is as Experimental. Red means there is no page for this activity! With the same color, I try to show the duplicate files.. Who is the maintainer of the site / server? File attached: https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dFJjNE9TemZUUGtzLVNEQnF4UlIwQkE Regards Alan ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel SugarLabs - Complete list of activities.ods Description: application/vnd.oasis.opendocument.spreadsheet ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SugarLabs server - web page
Thank you! I updated the document... From: cjlhomeaddr...@gmail.com Date: Wed, 4 Jan 2012 00:57:59 -0500 Subject: Re: SugarLabs server - web page To: alan...@hotmail.com CC: a...@lists.sugarlabs.org; sugar-devel@lists.sugarlabs.org; de...@lists.laptop.org; walter.ben...@gmail.com I've added a column for L10n. ther are some uncertainties. tr.sl.o = our Pootle instance pending = awaiting upload to Pootle gnome = Gnome Damned Lies server cjl On Tue, Jan 3, 2012 at 11:20 PM, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Hi, Many times, I wondered, what activities had to Sugar page SL (SugarLabs). But when you are looking for, not is easily to find the activities that are not public. Furthermore, when adding a new activity, you do not know if there is already a similar (even the same) on the server. So I started making a list of everything I had in the server: http://download.sugarlabs.org/activities/ Is a simple system: a folder for an activity and after, in the web, with the same number: the page of the activity. For example: the activity I know America was in the server in: http://download.sugarlabs.org/activities/4464/ And in SugarLabs: http://activities.sugarlabs.org/en-US/sugar/addon/4464 When I check all the files, I encountered many interesting things.. Activities that did not even have a page on SL... Duplicate activities/files.. So we have supplemented the list with that information. In the first column, see the id that is automatically generated on the server. In the second column shows the name of the activity that is in that folder. In the spaces are blank, because there are no such folders on the server. In the column Notes are cases in which there are empty folders. The third column Page indicates the status of that activity in SL. Green means it is public. Orange means it is as Experimental. Red means there is no page for this activity! With the same color, I try to show the duplicate files.. Who is the maintainer of the site / server? File attached: https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dFJjNE9TemZUUGtzLVNEQnF4UlIwQkE Regards Alan ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
