[sugar] what matters
It's clear that we aren't all here for the same thing. Some wish to help all kids, or poor kids, or non-Western kids. Some wish to advance freedom of speech, freedom from EULA slavery, or freedom to learn heretical ideas. Some of us are, assuming good intentions, extremely innocent regarding Microsoft. The historical record shows that those who partner with Microsoft will be betrayed in the worst way. Read "The Scorpion and the Frog" to understand Microsoft. To a very limited extent, I agree with the idea that we should not be pedantic about free software. This does not mean giving up the battle in any way. (example: my free wireless firmware) Of particular importance is never letting proprietary software hold your data hostage, run outside of a sandbox, or become a platform (API/ABI) upon which you build. The critical things I see for a kid's laptop are: 1. All security-related code is trustworthy. This of course means an open source OS, from kernel to web browser. It most likely means an open source firmware and boot loader as well. Of course, "trustworthy" is to be interpreted from the view of the user. 2. Storage of user data in open formats is easier than storage in closed formats. The system must not encourage lock-in. 3. The user's files are protected. Untrusted programs may be used, with the user being certain that they can not secretly steal or corrupt his files. 4. The browser provides strong isolation. A new security partition is created when a URL is typed or a bookmark is invoked. A web site in one security partition does not get any awareness of any other security partitions, EVEN IF THEY INVOLVE THE SAME SITE. (Maybe one wishes to have multiple accounts on a web site.) 5. The browser also strongly isolates plug-ins. It is not OK for any random browser plug-in to have full access to the memory or files that the browser would have access to. This sort of thing needs to be enforced at the kernel level, via the browser causing SE Linux to do various role transitions. 6. The user can use any normal Internet connection, anonymously. 7. The user can localize. This means more than adding language strings to an existing locale. It means creating whole new locales and fixing any locale-related bugs which may appear. This obviously requires open source software. 8. There are very few hardware platforms. Ideally there would be exactly one, but it must be expected that multiple hardware generations will be in use. Each hardware platform gets an optimized build that includes hardware-specific image and font sizes. It makes a huge difference to the overall experience when all the software can assume specific hardware. It's so many little things, like the Ruler activity knowing how big to draw itself and the Acoustic Measure activity having correct laptop pictures. In practice, the above pretty much requires GPL-like licensing and widespread hardware availability. It doesn't require flash, python, a mesh, or even sugar. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [patch] corrected Hardy dependencies
On Wed, Apr 23, 2008 at 10:01 PM, Bobby Powers <[EMAIL PROTECTED]> wrote: > I'm running sugar-jhbuild on Ubuntu Hardy, and Tomeu's recent commit to add > dependency files for Ubuntu is great except for 3 packages with the wrong > names (I haven't checked Gutsy - might be the same deal there). I've > attached a patch - I'm new here so let me know if there is anything else I > should do or if there is a better place to post this. I'm still not sure whether we should list the packages we are building as dependencies - but I've applied this to gutsy as well and pushed it. Thanks Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [patch] corrected Hardy dependencies
On Thu, Apr 24, 2008 at 10:17 AM, Morgan Collett <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 10:01 PM, Bobby Powers <[EMAIL PROTECTED]> wrote: > > I'm running sugar-jhbuild on Ubuntu Hardy, and Tomeu's recent commit to add > > dependency files for Ubuntu is great except for 3 packages with the wrong > > names (I haven't checked Gutsy - might be the same deal there). I've > > attached a patch - I'm new here so let me know if there is anything else I > > should do or if there is a better place to post this. > > I'm still not sure whether we should list the packages we are building > as dependencies - but I've applied this to gutsy as well and pushed > it. The idea is that if there is a package good enough dependency in the system, you list it so that the system one is used instead of building it. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 4:24 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > Should I be submitting patches that include the Makefile.am changes? > Or does automake magically figure that out for me somehow? > Nope, you have to do it manually. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar's amorphousness
Hi, as the paragraph below is being repeated and translated in newspapers all around the world, and Nicholas has started sharing his opinions with the community, I would like to ask a clarification about what he really meant with this and how we could address those concerns. He lamented that an overriding insistence on open-source had hampered the XOs, saying Sugar "grew amorphously" and "didn't have a software architect who did it in a crisp way." For instance, the laptops do not support Flash animation, widely used on the Web. >From http://ap.google.com/article/ALeqM5hXa0O9XLMsWfaqt-sI9FqFy2IewgD9074MH82 I guess it's too late now to ask for a rectification. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ad-hoc Networking
On Thu, Apr 24, 2008 at 1:27 AM, John Gilmore <[EMAIL PROTECTED]> wrote: > Take two such laptops. > > Take them way out into the country so they can only communicate with > each other. > > There are no access points. No laptop is acting as an access point, either. > > Can those two laptops communicate? Under 802.11b/g, the answer is yes. > They are communicating in "ad-hoc" mode. Each can transmit packets and > the other one gets the packets. (This works for N laptops, not just two.) > > The IETF "ZeroConf" protocols provide for self-assignment of IP > addresses in such a case. (The same thing happens if you plug two > laptops together with a short Ethernet cable and no DHCP server.) > Once they self-assign IP addresses, the laptops can talk at an IP > level. They can send unicast, multicast, and broadcast packets to > each other. (If you look in the Mac Control Panel, you'll see this > reported as a "self-assigned IP address", with a warning that you > probably aren't connected to the global Internet, since most of the > time that was what you probably expected.) > > Does the OLPC Presence Service work in such a case? Yes, that is exactly what telepathy-salut does, using avahi. You can also take two Nokia N800s and chat between them, or two laptops at a conference running a telepathy-based jabber client like Empathy, and chat between them - all ad-hoc, no infrastructure required. Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] jhbuild changes
Hello, I landed a few sugar-jhbuild changes last weekend. Highlights: * You are better off doing a clean checkout/build. * We are now pulling jhbuild upstream directly instead of using an internal copy. Misc cleanups of the scripts and of the directory structure. * I reworked the sanity check do be distribution specific. It should be much easier to install the missing dependencies now because you will get an actual list of packages to install (Ubuntu and Fedora are supported so far). Also we can reduce the number of packages built by specifying to use system packages for some dependencies in the sysdeps definition. * For distributions which are not supported yet, stuff will work as usual, except you won't get any dependency check. * If you want to support for a new distribution you have to add a little logic to scripts/sysdeps.py to recognize it and a new sysdeps definition in config/sysdeps. Should be very easy. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar's amorphousness
On Thu, Apr 24, 2008 at 1:31 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > Hi, > > as the paragraph below is being repeated and translated in newspapers > all around the world, and Nicholas has started sharing his opinions > with the community, I would like to ask a clarification about what he > really meant with this and how we could address those concerns. Whose fault are these things? Nicholas was in charge, and if he chose not to manage, he cannot be surprised that people used their own judgment. None of this was kept secret from him. > He lamented that an overriding insistence on open-source had hampered > the XOs, saying Sugar "grew amorphously" See The Cathedral and the Bazaar, by Eric Raymond, for the opposite view of Free Software development. > and "didn't have a software > architect who did it in a crisp way." You can't have a crisp architecture for unknown functionality. This was a research project, not the kind of development where you know what to do and how to do it in advance. It would be insane to suggest that somebody could specify the software design when the most basic properties of the hardware were unknown. Such as amounts of RAM and flash, processor speed, and screen resolution. All were changed in the middle of development. Designing a radically new user interface can only be done by trying it and making adjustments. > For instance, the laptops do not > support Flash animation, widely used on the Web. A complete non sequitur. What does omission of non-Free Flash have to do with lack of a crisp architecture? Presumably Nicholas has been concerned about this all through last year, but I haven't heard that he ever communicated his concern to the developers. Walter Bender and Ivan Krstic made their positions on FOSS very clear, and there was no reason for the rest of us to doubt that those were the policies until after Walter was removed from responsibility for software, Ivan resigned, and then Walter resigned. They can run Flash, but are not shipped with Flash pre-installed. Gnash is included, but not the proprietary codecs that are required to play content in specific formats. This has been discussed at length on the devel list. http://wiki.laptop.org/go/Flash_player Adobe makes the official Flash plugin, but OLPC cannot ship it on the XOs because it is legally restricted and doesn't meet the OLPC's standards for open software. As an individual, you can download and install the Adobe Flash plugin to view all Flash content. For details, see Adobe Flash#Installation. http://wiki.laptop.org/go/Gnash The easiest way to get Flash to work with Gnash is to get developers of the Flash content to test with Gnash. For example, a developer might choose an open codec such as Vorbis or Theora. Streaming these format in full screen would be as simple as a five line Gnash script. > From http://ap.google.com/article/ALeqM5hXa0O9XLMsWfaqt-sI9FqFy2IewgD9074MH82 > > I guess it's too late now to ask for a rectification. It's never too late, but it's true that the new message will never catch up with the old one. > Thanks, > > Tomeu > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Cerebro released
On Mon, Apr 21, 2008 at 9:41 AM, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]> wrote: > (sorry for cross-postings) > > The first release of Cerebro is out! > > Cerebro basically offers scalable presence information and a simple > collaboration API. Features currently include: > > - presence information (including distance and route) for all other > users in the network > - dynamic rate of updates based on density of neighborhood: No more than > 1 update every 5 seconds (on average) guaranteed. > - mesh network extended to regular 802.11b/g devices > - extensible user profile including nickname, colors, keys, IP addreses, > picture of arbitrary size, status message etc > - file sharing using an efficient multicast mechanism > - simple collaboration mechanism through 'share', 'join', 'leave' functions > - simple programming API based on dbus (see examples) > > http://wiki.laptop.org/go/Cerebro Hi, what's the plan for putting this on the images? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] This project is rolling, so should OLPC
On Wed, Apr 23, 2008 at 9:58 AM, Bryan Berry <[EMAIL PROTECTED]> wrote: > Our pilots at Bishwamitra and Bashuki schools start this Friday and I > couldn't be more excited. I wish I were there. > I find this discussion about the future of OLPC frankly *annoying* and > tiresome. Ivan and Walter found the reality far more annoying and tiresome than our account of it is. > The future of OLPC isn't at 1CC. It's at pilot schools around > the world. It's in the hands of kids. The software and hardware on the > XO are at mature point where we can really see the impact on education. > Sugar needs a lot of work but it is functional now, thanks to the heroic > efforts of many on the Sugar team. You are exactly right, and Nicholas and the naysayers are dead wrong. I'm looking forward to the time when the kids can take over most of the programming, most of the localization, and pretty much all of the strategy. > The key question about participating in OLPC shouldn't be what > Negroponte or Bender are up to, it should be what Arjun Tamang uses his > XO for on Monday in Nepal or what Marisol Gonzalez does w/ it in rural > Peru. Yes, it should be. But Nicholas doesn't see it that way, and he has interfered quite severely in getting the work done here. > As Bert says, Onward. There is much work to do. Debating the future of > OLPC as an organization does little to advance OLPC as a global movement > - which it very much is. > > Roll up your sleeves folks, let's make this happen. They won't go any higher. This is a work smarter, not harder, moment. If Nicholas is determined to pull resources off Linux development and turn them to Windows, disaster looms for OLPC. But Sugar will be fine, regardless, because most of the volunteers are ignoring the kerfuffle and continuing to code, test, and tweak. I'm still recruiting localizers and thinking about the design possibilities for textbooks and manuals for use on a ubiquitous hardware and software platform. And recruiting artists for one of them that I have mostly worked out. > Edward Cherlin: If OLPC the organization isn't meeting your needs, start > your own. We started our own here in Nepal and it was the best thing we > could have done. That's funny. I thought that's what _I_ said, about forking Sugar. Well, I haven't given up on Nicholas yet, so you're going to have to either put up with it or filter it. We're not stopping the argument until we get answers one way or another. Walter is currently thinking about what to create and how. Mary Lou is in the middle of Pixel Qi's A funding round with the venture capitalists. I don't know what Ivan is doing. But I'm still here, trying to get it through Nicholas's skull that _he_ is the problem here. Right now he is dangerously close to, "When I want to hear _your_ opinion, I'll *tell* it to you." Thank you for your support. > -- > Bryan W. Berry > Systems Engineer > OLE Nepal, http://www.olenepal.org > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Add speaker device and icon by default
Add speaker device and icon by default, as in
http://wiki.laptop.org/go/Designs/Frame#07
---
src/hardware/hardwaremanager.py | 28 +-
src/model/devices/Makefile.am |4 +-
src/model/devices/devicesmodel.py |3 +
src/model/devices/speaker.py | 59 +++
src/view/devices/Makefile.am |4 +-
src/view/devices/speaker.py | 113 +
6 files changed, 207 insertions(+), 4 deletions(-)
create mode 100644 src/model/devices/speaker.py
create mode 100644 src/view/devices/speaker.py
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 29be450..f5bb0e3 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -50,6 +50,13 @@ class HardwareManager(object):
if track.flags & gst.interfaces.MIXER_TRACK_MASTER:
self._master = track
+def get_mute(self):
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return False
+return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \
+ == gst.interfaces.MIXER_TRACK_MUTE
+
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
@@ -57,7 +64,16 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
-volume = self._mixer.get_volume(self._master)[0]
+
+volumes = self._mixer.get_volume(self._master)
+
+#sometimes we get a spurious zero from one/more channel(s)
+nonzero_vols = [v for v in volumes if v > 0.0]
+if len(nonzero_vols) != 0 and len(nonzero_vols) != len(volumes):
+volumes = nonzero_vols
+
+#we could just pick the first channel's volume, but this converges
+volume = sum(volumes) / len(volumes)
return volume * 100.0 / (max_volume - min_volume) + min_volume
@@ -73,10 +89,18 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
+logging.debug("setting volume: %s (%s/%s/%s)" % (volume, min_volume,
max_volume, self._master.num_channels))
volume = volume * (max_volume - min_volume) / 100.0 + min_volume
volume_list = [ volume ] * self._master.num_channels
-self._mixer.set_volume(self._master, tuple(volume_list))
+#sometimes alsa fails to set all channels' volume, so try a few times
+last_volumes_read = [0]
+read_count = 0
+while (0 in last_volumes_read) and (read_count < 3):
+logging.debug("setting volume_list %d: %s" % (read_count,
volume_list))
+self._mixer.set_volume(self._master, tuple(volume_list))
+last_volumes_read = self._mixer.get_volume(self._master)
+read_count += 1
def set_mute(self, mute):
if not self._mixer or not self._master:
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..3124144 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -5,4 +5,6 @@ sugar_PYTHON = \
__init__.py \
device.py \
devicesmodel.py \
- battery.py
+ battery.py \
+ speaker.py
+
diff --git a/src/model/devices/devicesmodel.py
b/src/model/devices/devicesmodel.py
index 691e19e..32c77da 100644
--- a/src/model/devices/devicesmodel.py
+++ b/src/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import speaker
from hardware import hardwaremanager
from hardware import nmclient
@@ -54,6 +55,8 @@ class DevicesModel(gobject.GObject):
for udi in hal_manager.FindDeviceByCapability('battery'):
self.add_device(battery.Device(udi))
+self.add_device(speaker.Device())
+
def _observe_network_manager(self):
network_manager = hardwaremanager.get_network_manager()
if not network_manager:
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
new file mode 100644
index 000..d3b9967
--- /dev/null
+++ b/src/model/devices/speaker.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have
Re: [sugar] This project is rolling, so should OLPC
Bryan Berry wrote: > Our pilots at Bishwamitra and Bashuki schools start this Friday and I > couldn't be more excited. This is great! Are there any blockers left on which you could use remote help on? Did you solve the customized build issues you had? Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] This project is rolling, so should OLPC
simon, thanks for your concern fixed the customized build problems. All ready for tomorrow. You guys should realize that about 80% of my time is taken up by logistics. Testing, organizing XO's, labeling them, etc. I spent 4 hours today packing the XO's for tomorrow. ah the joy. little time left for actual technical stuff. w/in the next few weeks hope to figure out how edit pre-boot image using puritan. Should be fun and under a lot less pressure then ;) On Thu, 2008-04-24 at 15:24 +0200, Simon Schampijer wrote: > Bryan Berry wrote: > > Our pilots at Bishwamitra and Bashuki schools start this Friday and I > > couldn't be more excited. > > This is great! Are there any blockers left on which you could use remote > help on? Did you solve the customized build issues you had? > > Best, > Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] This project is rolling, so should OLPC
Bryan Berry wrote: > simon, thanks for your concern > > fixed the customized build problems. All ready for tomorrow. You guys > should realize that about 80% of my time is taken up by logistics. > Testing, organizing XO's, labeling them, etc. I spent 4 hours today > packing the XO's for tomorrow. ah the joy. little time left for actual > technical stuff. Ok I see. Happy to hear everything is in good shape :) Enjoy the day tomorrow, Simon > w/in the next few weeks hope to figure out how edit pre-boot image using > puritan. Should be fun and under a lot less pressure then ;) > > > On Thu, 2008-04-24 at 15:24 +0200, Simon Schampijer wrote: >> Bryan Berry wrote: >>> Our pilots at Bishwamitra and Bashuki schools start this Friday and I >>> couldn't be more excited. >> This is great! Are there any blockers left on which you could use remote >> help on? Did you solve the customized build issues you had? >> >> Best, >> Simon > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Error when building libabiword-plugins
Hello, I'm building libabiword-plugins on Fedora (soon to be) 9 and I get the following error. libstdc++ version is 4.3.0. Btw, can we update sugar-jhbuild to use 2.6.2? if someone can upload tarballs on sugar.abisource.com I'll be happy to take care of jhbuild modulesets update... Marco g++ -DPACKAGE_NAME=\"abiword-plugins\" -DPACKAGE_TARNAME=\"abiword-plugins\" -DPACKAGE_VERSION=\"2.6.0\" "-DPACKAGE_STRING=\"abiword-plugins 2.6.0\"" -DPACKAGE_BUGREPORT=\"http://bugzilla.abisource.com/\"; -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRINGS_H=1 -DPACKAGE=\"abiword-plugins\" -DVERSION=\"2.6.0\" -DHAVE_DLFCN_H=1 -DHAVE_BOOST= -DHAVE_BOOST_THREAD= -I. -I. -I./../../.. -I./../../../core/packet -DDEBUG -DUT_DEBUG -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/text/ptbl/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/impexp/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/other/spell/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/other/fribidi/xp -I../../../../../../libabiword-2.6.0.svn20071127/src/other/ttftool/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/unix -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/unix -DABI_PLUGIN_VERSION=\"2.6.0\" -DABI_PLUGIN_MAJOR=2 -DABI_PLUGIN_MINOR=6 -DABI_PLUGIN_MICRO=0 -DABI_PLUGIN_SOURCE=1 -DABICOLLAB_RECORD_ALWAYS -I/usr/include/loudmouth-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DABICOLLAB_HANDLER_XMPP -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgsf-1 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/libglade-2.0 -g -O2 -MT XMPPUnixAccountHandler.lo -MD -MP -MF .deps/XMPPUnixAccountHandler.Tpo -c XMPPUnixAccountHandler.cpp -fPIC -DPIC -o .libs/XMPPUnixAccountHandler.o In file included from XMPPUnixAccountHandler.h:24, from XMPPUnixAccountHandler.cpp:20: ./../../../backends/xmpp/xp/XMPPAccountHandler.h:27: error: 'std::string' has not been declared make[5]: *** [XMPPUnixAccountHandler.lo] Error 1 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Community-news] on Sugar
C. Scott Ananian wrote: > On Wed, Apr 23, 2008 at 12:06 PM, Nicholas Negroponte <[EMAIL PROTECTED]> > wrote: >> For this reason, Sugar needs a wider basis, to run on more Linux platforms >> and to run under Windows. We have been engaged in discussions with Microsoft >> for several months, to explore a dual boot version of the XO. Some of you >> have seen what Microsoft developed on their own for the XO. It works well >> and now needs Sugar on top of it (so to speak). > > You have been saying variations of this for a while now, but: > * OLPC has not hired any Windows developers > * OLPC has not adjusted its timeline to allow for time necessary for > such a port. > > What are we to make of this? Are you serious about Sugar on Windows > or not? If you are, then you need to immediately hire *at least* 10 > windows developers to actually perform the port, and inform the > deployment countries that we are placing a hold on new development for > at least 6 months while the port is prepared. And the result, of > course, will be a new version of Sugar which is guaranteed to run *no > better* than the one on Linux. From an IT management perspective, > this is madness. > > If you are not serious about Sugar on Windows within the next year, > please continue to avoid 'now' and use 'might' and 'someday' when you > talk about it, and we'll continue to try to make Sugar-on-Linux > achieve its potential. I approve of keeping OLPC's options open, in > case your current development team (myself included) cannot deliver on > Sugar's potential, but setting vague (and demoralizing) goals for > future development -- without actually devoting the resources to > achieve those goals -- is madness. You have only succeeded in > alienating the developers you need to make Sugar-on-Linux work, > without actually achieving any progress on Sugar-on-Windows. > --scott > The sugar team has accomplished an amazing amount in the time they've spent so far. However, there are so many features, like security, that were not implemented or implemented as well as they should have been. Several people said a lack of manpower was to blame. If more resources are available for porting to windows, why weren't more developers hired for the initial work on sugar? Is there new funding that is making this port possible? What I'm having a hard time with is how this new, much greater commitment can be honored when the initial undertaking was understaffed. Sugar was _already_ an integral part of the XO and it now seems like it was not given the attention it deserved. -Peter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Fwd: {OLPC Nepal} Re: [FOSSNepal] Re: Report: OLPC may eventually switch from Linux to Windows XP
-- Forwarded message --
From: Bibek Paudel <[EMAIL PROTECTED]>
Date: Thu, Apr 24, 2008 at 6:18 PM
Subject: {OLPC Nepal} Re: [FOSSNepal] Re: Report: OLPC may eventually switch
from Linux to Windows XP
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Hi all,
While I personally think it is bad for OLPC to switch to Windows XP,
here a few observations that I have made:
1. Any development/education project meant for third world countries
is best when it is natively grown. A top down approach where some guy
in Boston teaches us how to change things in our neighbourhood is
never likely to understand and respect our situation and problems. He
has other priorities. A bottom-up approach should be devised where
grassroot organizations from different parts of the world collaborate
to form a mother organization that works in their benefit. Compare
this to Nepal's political situation where every other politician/media
claims to represent the people and be working for them. Things won't
that way in technology too.
2. Nicholas Negroponte is a man hungry of some position in history of
business and humanity, both. He thinks increasing the sales of laptops
is more important than the growing impact it is creating. Selling a
qarter of a million of laptops is a success by any means for any
profit-organization. I don't understand how it is not sufficient in
case of a first-of-its-kind project by a non-profit organization.
3. Nicholas Negroponte doesn't care. Using Windows in XOs has many
implications. Besides cost and the performance of the laptops, it
means you are forcing a company's products on all children. Compare
that to a government policy whereby it makes every school going
children mandatory to wear dresses from a certain dress-designing
company or study books from a certain publisher (eg. Ekta publishers).
Thats why we have a government book publisher and curriculum designer
in Nepal and government can't recommend any other books. I don't
understand how someone can impose the monopoly of using a
vendor-specific software on all kids. And why governments all over the
world should abide by that.
4. The issue of "amorphic" development of XO as said by Negroponte is
at best ridiculous. Having the best of the world's technology,
engineers and money at MIT, it shocks me how he allowed a project of
OLPC's scale fall at the hands of people who neither could have a good
architect for the software or the capacity to develop them
"morphically". Had he never heard of the term "software engineering"
before? Why was the decision taken in first place?
5. What are all the people spread all over supposed to make of the
recent developments? At the behest of a single man or a group of such
men, should they be forced to change their working style, philosophy
and way of seeing things?
6. I wish someone starts a fork of Sugar and everything OLPC. Why not
Walter Bender? Start a fork. Or else the people at OLPC, if you have
all the democracy and its powers, why don't you remove such people who
are moving away from the OLPC's original principles? I just hope
something of similar nature happens.
If you agree with me, please forward this message to other mailing
lists of OLPC where people are likely to respond to this issue.
Cheers !
Bibek
On Thu, Apr 24, 2008 at 5:50 PM, sarose <[EMAIL PROTECTED]> wrote:
>
> hey dude! your grandpa is great but you know my uncle Negroponte is
> fool nonsense because he now hate Linux.
>
> About Ubuntu, i don't know how to pronounce it. Please teach me as
> well.
>
> Try a survey with your friends or co-workers around. The answer
> screams cries utterly. Don't forget to submit back to Uncle
> Negroponte.
>
> On Apr 24, 4:12 pm, Zico <[EMAIL PROTECTED]> wrote:
>
>
> > On Thu, Apr 24, 2008 at 3:42 PM, sarose <[EMAIL PROTECTED]> wrote:
> >
> > > yes its bad news and a good lesson for the gnome/kde that has not
come
> > > up with user friendly UI till this date.
> >
> > You are very wrong, brother! Don`t you see the *blinking things* of
> > gnome/kde? And, how do you define "friendly user interface"? What more
do
> > you expect from Gnome/KDE? Please point out, we will be really glad to
hear
> > that.
> >
> > just stop saying linux is ready for desktop.
> >
> > Why should we do that??
> >
> > > neither its ready for my
> > > dad nor its ready for my little brother.
> >
> > I don`t know about your dad or younger brother, but Ubuntu is ready for
my
> > grandfather. Now, i am teaching my grandmother to use computer ( in one
> > word, Ubuntu ).
> >
> > all its ready
> >
> > > for is server only.
> >
> > Very wrong.
> > By the way, which distro do you use?
> >
> > --
> > Best,
> > Z
> >
>
--
Bibek Paudel.
http://blog.bibekpaudel.com.np/
==
--~--~-~--~~~---~--~~
OLPC Nepal
http://olpcnepal.org
http://wiki.olpcnepal.org
-~--~~~~--~~--~--~---
--
Pra
Re: [sugar] Sugar Digest, Vol 22, Issue 85
too. > > 2. Nicholas Negroponte is a man hungry of some position in history of > business and humanity, both. He thinks increasing the sales of laptops > is more important than the growing impact it is creating. Selling a > qarter of a million of laptops is a success by any means for any > profit-organization. I don't understand how it is not sufficient in > case of a first-of-its-kind project by a non-profit organization. > > 3. Nicholas Negroponte doesn't care. Using Windows in XOs has many > implications. Besides cost and the performance of the laptops, it > means you are forcing a company's products on all children. Compare > that to a government policy whereby it makes every school going > children mandatory to wear dresses from a certain dress-designing > company or study books from a certain publisher (eg. Ekta publishers). > Thats why we have a government book publisher and curriculum designer > in Nepal and government can't recommend any other books. I don't > understand how someone can impose the monopoly of using a > vendor-specific software on all kids. And why governments all over the > world should abide by that. > > 4. The issue of "amorphic" development of XO as said by Negroponte is > at best ridiculous. Having the best of the world's technology, > engineers and money at MIT, it shocks me how he allowed a project of > OLPC's scale fall at the hands of people who neither could have a good > architect for the software or the capacity to develop them > "morphically". Had he never heard of the term "software engineering" > before? Why was the decision taken in first place? > > 5. What are all the people spread all over supposed to make of the > recent developments? At the behest of a single man or a group of such > men, should they be forced to change their working style, philosophy > and way of seeing things? > > 6. I wish someone starts a fork of Sugar and everything OLPC. Why not > Walter Bender? Start a fork. Or else the people at OLPC, if you have > all the democracy and its powers, why don't you remove such people who > are moving away from the OLPC's original principles? I just hope > something of similar nature happens. > > If you agree with me, please forward this message to other mailing > lists of OLPC where people are likely to respond to this issue. > > Cheers ! > Bibek > > On Thu, Apr 24, 2008 at 5:50 PM, sarose <[EMAIL PROTECTED]> wrote: >> >> hey dude! your grandpa is great but you know my uncle Negroponte is >> fool nonsense because he now hate Linux. >> >> About Ubuntu, i don't know how to pronounce it. Please teach me as >> well. >> >> Try a survey with your friends or co-workers around. The answer >> screams cries utterly. Don't forget to submit back to Uncle >> Negroponte. >> >> On Apr 24, 4:12 pm, Zico <[EMAIL PROTECTED]> wrote: >> >> >> > On Thu, Apr 24, 2008 at 3:42 PM, sarose <[EMAIL PROTECTED]> wrote: >> > >> > > yes its bad news and a good lesson for the gnome/kde that has not > come >> > > up with user friendly UI till this date. >> > >> > You are very wrong, brother! Don`t you see the *blinking things* of >> > gnome/kde? And, how do you define "friendly user interface"? What more > do >> > you expect from Gnome/KDE? Please point out, we will be really glad to > hear >> > that. >> > >> > just stop saying linux is ready for desktop. >> > >> > Why should we do that?? >> > >> > > neither its ready for my >> > > dad nor its ready for my little brother. >> > >> > I don`t know about your dad or younger brother, but Ubuntu is ready >> for > my >> > grandfather. Now, i am teaching my grandmother to use computer ( in >> one >> > word, Ubuntu ). >> > >> > all its ready >> > >> > > for is server only. >> > >> > Very wrong. >> > By the way, which distro do you use? >> > >> > -- >> > Best, >> > Z >> > >> > > > > -- > Bibek Paudel. > http://blog.bibekpaudel.com.np/ > == > > --~--~-~--~~~---~--~~ > OLPC Nepal > http://olpcnepal.org > http://wiki.olpcnepal.org > -~--~~~~--~~--~--~--- > > > > > -- > Prakhar Agarwal > Technical Head - Library R&D Team > 3rd Year > B.Tech, IT > JIIT University,Noida > "Life is the greatest teacher" > -- next part -- > An HTML attachment was scrubbed... > URL: > http://lists.laptop.org/pipermail/sugar/attachments/20080424/2c192cf8/attachment.htm > > -- > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > > End of Sugar Digest, Vol 22, Issue 85 > * ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] {OLPC Nepal} Re: [FOSSNepal] Re: Report: OLPC may eventually switch from Linux to Windows XP
-- Forwarded message --
From: Bibek Paudel <[EMAIL PROTECTED]>
Date: Thu, Apr 24, 2008 at 6:33 PM
Subject: {OLPC Nepal} Re: [FOSSNepal] Re: Report: OLPC may eventually switch
from Linux to Windows XP
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Hi all,
While I personally think it is bad for OLPC to switch to Windows XP,
here a few observations that I have made:
1. Any development/education project meant for third world countries
is best when it is natively grown. A top down approach where some guy
in Boston teaches us how to change things in our neighbourhood is
never likely to understand and respect our situation and problems. He
has other priorities. A bottom-up approach should be devised where
grassroot organizations from different parts of the world collaborate
to form a mother organization that works in their benefit. Compare
this to Nepal's political situation where every other politician/media
claims to represent the people and be working for them. Things won't
that way in technology too.
2. Nicholas Negroponte is a man hungry of some position in history of
business and humanity, both. He thinks increasing the sales of laptops
is more important than the growing impact it is creating. Selling a
qarter of a million of laptops is a success by any means for any
profit-organization. I don't understand how it is not sufficient in
case of a first-of-its-kind project by a non-profit organization.
3. Nicholas Negroponte doesn't care. Using Windows in XOs has many
implications. Besides cost and the performance of the laptops, it
means you are forcing a company's products on all children. Compare
that to a government policy whereby it makes every school going
children mandatory to wear dresses from a certain dress-designing
company or study books from a certain publisher (eg. Ekta publishers).
Thats why we have a government book publisher and curriculum designer
in Nepal and government can't recommend any other books. I don't
understand how someone can impose the monopoly of using a
vendor-specific software on all kids. And why governments all over the
world should abide by that.
4. The issue of "amorphic" development of XO as said by Negroponte is
at best ridiculous. Having the best of the world's technology,
engineers and money at MIT, it shocks me how he allowed a project of
OLPC's scale fall at the hands of people who neither could have a good
architect for the software or the capacity to develop them
"morphically". Had he never heard of the term "software engineering"
before? Why was the decision taken in first place?
5. What are all the people spread all over supposed to make of the
recent developments? At the behest of a single man or a group of such
men, should they be forced to change their working style, philosophy
and way of seeing things?
6. I wish someone starts a fork of Sugar and everything OLPC. Why not
Walter Bender? Start a fork. Or else the people at OLPC, if you have
all the democracy and its powers, why don't you remove such people who
are moving away from the OLPC's original principles? I just hope
something of similar nature happens.
If you agree with me, please forward this message to other mailing
lists of OLPC where people are likely to respond to this issue.
Cheers !
Bibek
On Thu, Apr 24, 2008 at 5:50 PM, sarose <[EMAIL PROTECTED]> wrote:
>
> hey dude! your grandpa is great but you know my uncle Negroponte is
> fool nonsense because he now hate Linux.
>
> About Ubuntu, i don't know how to pronounce it. Please teach me as
> well.
>
> Try a survey with your friends or co-workers around. The answer
> screams cries utterly. Don't forget to submit back to Uncle
> Negroponte.
>
> On Apr 24, 4:12 pm, Zico <[EMAIL PROTECTED]> wrote:
>
>
> > On Thu, Apr 24, 2008 at 3:42 PM, sarose <[EMAIL PROTECTED]> wrote:
> >
> > > yes its bad news and a good lesson for the gnome/kde that has not
come
> > > up with user friendly UI till this date.
> >
> > You are very wrong, brother! Don`t you see the *blinking things* of
> > gnome/kde? And, how do you define "friendly user interface"? What more
do
> > you expect from Gnome/KDE? Please point out, we will be really glad to
hear
> > that.
> >
> > just stop saying linux is ready for desktop.
> >
> > Why should we do that??
> >
> > > neither its ready for my
> > > dad nor its ready for my little brother.
> >
> > I don`t know about your dad or younger brother, but Ubuntu is ready for
my
> > grandfather. Now, i am teaching my grandmother to use computer ( in one
> > word, Ubuntu ).
> >
> > all its ready
> >
> > > for is server only.
> >
> > Very wrong.
> > By the way, which distro do you use?
> >
> > --
> > Best,
> > Z
> >
>
--
Bibek Paudel.
http://blog.bibekpaudel.com.np/
==
--~--~-~--~~~---~--~~
OLPC Nepal
http://olpcnepal.org
http://wiki.olpcnepal.org
-~--~~~~--~~--~--~---
___
Re: [sugar] [PATCH] Add speaker device and icon by default
I'll /try/ to keep my comments mostly to the UI and leave the code review for others. I'll also fail at that to some extent, since I have curiosities about bits and pieces. On Thu, Apr 24, 2008 at 7:33 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > +return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \ > + == gst.interfaces.MIXER_TRACK_MUTE If MIXER_TRACK_MUTE is a bit mask, isn't the equality check redundant? > +#sometimes we get a spurious zero from one/more channel(s) > +#we could just pick the first channel's volume, but this converges > +#sometimes alsa fails to set all channels' volume, so try a few > times That's all fairly ugly, huh? Oh well. > +badge_name = None ... > +self.icon.props.badge_name = badge_name What's the logic for leaving this in? Is there a circumstance in which you think we may later add a badge, because at the moment this variable is never used. > +def _mute_item_text(self): ... > +return _(mute_item_text) Defining this in a function seems to work OK here, but I think I also want icons on the menu item, which also depends on the current state. As such, it may actually be cleaner to have an _update function of some kind which handles both text and image together, setting them directly instead of returning a value. I suppose you could also have separate functions for _mute_item_text and _mute_item_icon, as wellI'll let the others decide. Let's use the dialog-ok and dialog-cancel icons for now, which will match the current mockups for the mic and camera. We can change them easily later if we need to. > +mute_item_text = self._model.props.muted and 'Unmute' or 'Mute' This is a tricky ternary stand-in. Very clever. Is it clear enough for others? > +mute_item_text += '...' This is a bad habit that everyone seems to get into. Cut this line. Every menu item takes an action when clicked, and that's implicit, making the ellipsis effectively redundant. The ellipsis should only be used when (a) the text represents a "state of flux", eg. in the AP palettes /while/ "Connecting..." (not on the "Connect" menu item itself, which initiates it) or (b) The action of the menu item itself reveals a dialog which requires further feedback before actually initiating a "real" action. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: |> +mute_item_text = self._model.props.muted and 'Unmute' or 'Mute' | | This is a tricky ternary stand-in. Very clever. Is it clear enough for others? If you want it on one line, I would prefer a true ternary expression (new in 2.5): mute_item_text = 'Unmute' if self._model.props.muted else 'Mute' - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIELGfUJT6e6HFtqQRAsmlAJ0UFPQhOLuWvvW7zFwR38ZjaB161ACbBhuc 9JJaPTMpBtNfOOwyzTaFv3g= =Ot34 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On 24.04.2008, at 18:01, Eben Eliason wrote: > >> +mute_item_text = self._model.props.muted and 'Unmute' or >> 'Mute' > > This is a tricky ternary stand-in. Very clever. Is it clear enough > for others? It's an abuse of Python, IMHO. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] what matters
Albert Cahalan wrote: > It's clear that we aren't all here for the same thing. > Some wish to help all kids, or poor kids, or non-Western > kids. Some wish to advance freedom of speech, freedom from > EULA slavery, or freedom to learn heretical ideas. > > Some of us are, assuming good intentions, extremely innocent > regarding Microsoft. The historical record shows that those > who partner with Microsoft will be betrayed in the worst way. > Read "The Scorpion and the Frog" to understand Microsoft. > > To a very limited extent, I agree with the idea that we should > not be pedantic about free software. This does not mean giving > up the battle in any way. (example: my free wireless firmware) > Of particular importance is never letting proprietary software > hold your data hostage, run outside of a sandbox, or become a > platform (API/ABI) upon which you build. > > The critical things I see for a kid's laptop are: > > 1. All security-related code is trustworthy. This of course > means an open source OS, from kernel to web browser. It most > likely means an open source firmware and boot loader as well. > Of course, "trustworthy" is to be interpreted from the view > of the user. > > 2. Storage of user data in open formats is easier than storage > in closed formats. The system must not encourage lock-in. > > 3. The user's files are protected. Untrusted programs may > be used, with the user being certain that they can not secretly > steal or corrupt his files. > > 4. The browser provides strong isolation. A new security partition > is created when a URL is typed or a bookmark is invoked. A web > site in one security partition does not get any awareness of any > other security partitions, EVEN IF THEY INVOLVE THE SAME SITE. > (Maybe one wishes to have multiple accounts on a web site.) > > 5. The browser also strongly isolates plug-ins. It is not OK for > any random browser plug-in to have full access to the memory or > files that the browser would have access to. This sort of thing > needs to be enforced at the kernel level, via the browser causing > SE Linux to do various role transitions. > > 6. The user can use any normal Internet connection, anonymously. > > 7. The user can localize. This means more than adding language > strings to an existing locale. It means creating whole new > locales and fixing any locale-related bugs which may appear. > This obviously requires open source software. > > 8. There are very few hardware platforms. Ideally there would be > exactly one, but it must be expected that multiple hardware > generations will be in use. Each hardware platform gets an optimized > build that includes hardware-specific image and font sizes. > It makes a huge difference to the overall experience when all > the software can assume specific hardware. It's so many little > things, like the Ruler activity knowing how big to draw itself > and the Acoustic Measure activity having correct laptop pictures. > > In practice, the above pretty much requires GPL-like licensing > and widespread hardware availability. It doesn't require flash, > python, a mesh, or even sugar. > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > For what its worth, here's something that might help in analyzing the situation some more. Its an analytical approach called "mission and core competencies (MCC) matrix". I do not have rights to distribute a copy of the paper, so you'll have to look for one in your own libraries. Here's the abstract and a link to details. The MCC decision matrix:: a tool for applying strategic logic to everyday activity Abstract: Proposes the MCC decision matrix as a modern equivalent of the original Boston Consulting Group (BCG) portfolio matrix. Focuses on the key questions of mission and core competences which define the axes of the matrix and give it its name. Unlike the BCG matrix, the MCC matrix can be used to assess the relative merits of any competing claims on resources, not just those associated with product/ market segments or strategic business units. Also the validity of the matrix itself can be challenged and its expression modified. Claims that the matrix can be applied to sub-units at any level of the organization and is therefore a powerful tool for applying strategic logic to all types of resource-allocation decisions throughout an organization, ensuring their optimal contribution to building competitive strength. Presents a nine-cell directional policy matrix as an alternative form. http://www.emeraldinsight.com/Insight/viewContentItem.do;jsessionid=4C2BD0F55E3CB5F4C4F15AD390AB6E62?contentType=Article&hdAction=lnkpdf&contentId=864777 Of course, the key dependencies are that you actually *know* what the mission and core competencies are. Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.s
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 12:14 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > On 24.04.2008, at 18:01, Eben Eliason wrote: > > > >> +mute_item_text = self._model.props.muted and 'Unmute' or > >> 'Mute' > > > > This is a tricky ternary stand-in. Very clever. Is it clear enough > > for others? > > > It's an abuse of Python, IMHO. Tricky and abusive often go hand in hand, and abuses of languages are often the most interesting, though clearly not the most transparent. =) C, for instance, seems to taunt with all of the glorious hacks it is capable of executing as syntactically correct code. Duff's Device [1], anyone? Of course, usually susceptibility to such temptations result in a clean shot through one's own foot, with a sharp segfault bullet or worse. - Eben [1] http://en.wikipedia.org/wiki/Duff's_device ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] today's sugar-dev meeting
Hi everybody, there will be no meeting today. Hope we can make it again next week. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 12:13:19PM -0400, Benjamin M. Schwartz wrote: > I would prefer a true ternary expression (new in 2.5): > mute_item_text = 'Unmute' if self._model.props.muted else 'Mute' Doh -- I forgot we're on 2.5. Of course this is the right thing to do. Thanks. > - --Ben Martin pgp7SSjrlo6ER.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 12:01:52PM -0400, Eben Eliason wrote: > I'll /try/ to keep my comments mostly to the UI and leave the code > review for others. I'll also fail at that to some extent, since I > have curiosities about bits and pieces. > > On Thu, Apr 24, 2008 at 7:33 AM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > > +return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \ > > + == gst.interfaces.MIXER_TRACK_MUTE > > If MIXER_TRACK_MUTE is a bit mask, isn't the equality check redundant? It's not a bitmask, IIUC. So no, it's not redundant AFAICS. But yes, it'd read much more nicely without the equality check if it wasn't. > > +#sometimes we get a spurious zero from one/more channel(s) > > +#we could just pick the first channel's volume, but this converges > > +#sometimes alsa fails to set all channels' volume, so try a few > > times > > That's all fairly ugly, huh? Oh well. I know! > > +badge_name = None > ... > > +self.icon.props.badge_name = badge_name > > What's the logic for leaving this in? Hmmm...I must've missed that pylint warning. The variable goes. > > +def _mute_item_text(self): > ... > > +return _(mute_item_text) > > Defining this in a function seems to work OK here, but I think I also > want icons on the menu item, which also depends on the current state. > As such, it may actually be cleaner to have an _update function of > some kind which handles both text and image together, setting them > directly instead of returning a value. Agree -- I just didn't have any icons, so no use for such a function yet. > Let's use the dialog-ok and dialog-cancel icons for now, which will > match the current mockups for the mic and camera. We can change them > easily later if we need to. dialog-ok to go with the "Unmute" text, and -cancel to go with "Mute"? > > +mute_item_text = self._model.props.muted and 'Unmute' or 'Mute' > > This is a tricky ternary stand-in. Very clever. Is it clear enough for > others? > I'll change to the proper ternary clause as recommended by bemasc. > > +mute_item_text += '...' > > This is a bad habit that everyone seems to get into. Cut this line. Sorry! I know the rule(s) you cite, and must blame lack of sleep for leaving this in. I was cargo-culting "Disconnect..." from network/wireless.py, I think. > - Eben Martin pgpTWPw2nOiy6.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 12:40 PM, Martin Dengler <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 12:01:52PM -0400, Eben Eliason wrote: > > I'll /try/ to keep my comments mostly to the UI and leave the code > > review for others. I'll also fail at that to some extent, since I > > have curiosities about bits and pieces. > > > > On Thu, Apr 24, 2008 at 7:33 AM, Martin Dengler > > <[EMAIL PROTECTED]> wrote: > > > > > +return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \ > > > + == gst.interfaces.MIXER_TRACK_MUTE > > > > If MIXER_TRACK_MUTE is a bit mask, isn't the equality check redundant? > > It's not a bitmask, IIUC. So no, it's not redundant AFAICS. But yes, > it'd read much more nicely without the equality check if it wasn't. Hmmm, but you appear to be using it as such anyway. How else could the boolean & be interpreted logically otherwise? (I may very well be missing something here.) It was pointed out to me that one reason for it would be to return a boolean type, instead of an int, which is a valid assessment (I'm too familiar with C). If that's the core reason, however, I might find simply casting to bool clearer. > > Let's use the dialog-ok and dialog-cancel icons for now, which will > > match the current mockups for the mic and camera. We can change them > > easily later if we need to. > > dialog-ok to go with the "Unmute" text, and -cancel to go with "Mute"? Yup. > > > +mute_item_text += '...' > > > > This is a bad habit that everyone seems to get into. Cut this line. > > Sorry! I know the rule(s) you cite, and must blame lack of sleep for > leaving this in. I was cargo-culting "Disconnect..." from > network/wireless.py, I think. Good! I expect not to have to slap you again for this. :-P - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Community-news] on Sugar
On Thu, Apr 24, 2008 at 10:43 AM, Peter Krenesky <[EMAIL PROTECTED]> wrote: > The sugar team has accomplished an amazing amount in the time they've > spent so far. However, there are so many features, like security, that > were not implemented or implemented as well as they should have been. Mentioning "Windows" and "security" in the same message, nay, the same universe, is something of an oxymoron. When even dyed in the wool Microsoft fanboys and fangirls are abandoning Vista and begging and pleading with Microsoft, it just doesn't seem prudent to say "Let's go with FOSS running on top of Windows". Though I'm a zealous supporter of FOSS, if people were saying something like "Let's run Sugar et al on Mac OS X" I'd be more inclined to say "Well... okay." Before Microsoft, the concept of infecting a document, seemed like complete nonsense. (WordPerfect and other word processors had macros as well. But the macros didn't need to travel embedded in the document.) Put another way: Assuming for a moment, that hell has frozen over, and Microsoft has decided to play nice. When a Fortune 500 company (or two, or 20) calls Bill et al and says "Holy Crap! There's a hole in Vista big enough to fly a starship through!" Do you think the answer will be "Sorry. We're working on Sugar right now." Or is the OLPC project more likely to end up on the back burner? Not that the FOSS crowd are all working on the XO night and day, but my suspicion is that the focus is a wee bit more directed. And as I've already commented, Microsoft is a bit like Lucy Van Pelt: "This time I promise to let you kick the football, Charlie Brown" It's not so much a hatred of M$ as much as it's an incredible lack of trust. They'll need to play nice for a couple of years, minimum before I let my guard down. I think the reason that FOSS has grown so much in the past several years has more to do with dissatisfaction with proprietary software than with cost. (I've bought and paid for FOSS.) -- Kevin Cole | Key ID: 0xE6F332C7 (GPG/PGP) Gallaudet University | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | V/TTY: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 ". ! 1 |" -- Rene Magritte's computer ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Error when building libabiword-plugins
On Thu, 2008-04-24 at 16:34 +0200, Marco Pesenti Gritti wrote: > Hello, > > I'm building libabiword-plugins on Fedora (soon to be) 9 and I get the > following error. libstdc++ version is 4.3.0. > > Btw, can we update sugar-jhbuild to use 2.6.2? if someone can upload > tarballs on sugar.abisource.com I'll be happy to take care of jhbuild > modulesets update... Will do later tonight (I hope it works out of the box, because pyabiword is a bit behind; i think everything sugar uses is up2date though). Marc > Marco > > > g++ -DPACKAGE_NAME=\"abiword-plugins\" > -DPACKAGE_TARNAME=\"abiword-plugins\" -DPACKAGE_VERSION=\"2.6.0\" > "-DPACKAGE_STRING=\"abiword-plugins 2.6.0\"" > -DPACKAGE_BUGREPORT=\"http://bugzilla.abisource.com/\"; > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_STRINGS_H=1 -DPACKAGE=\"abiword-plugins\" > -DVERSION=\"2.6.0\" -DHAVE_DLFCN_H=1 -DHAVE_BOOST= > -DHAVE_BOOST_THREAD= -I. -I. -I./../../.. -I./../../../core/packet > -DDEBUG -DUT_DEBUG > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/ptbl/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/impexp/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/spell/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/fribidi/xp > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/ttftool/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/unix > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/unix > -DABI_PLUGIN_VERSION=\"2.6.0\" -DABI_PLUGIN_MAJOR=2 > -DABI_PLUGIN_MINOR=6 -DABI_PLUGIN_MICRO=0 -DABI_PLUGIN_SOURCE=1 > -DABICOLLAB_RECORD_ALWAYS -I/usr/include/loudmouth-1.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -DABICOLLAB_HANDLER_XMPP -I/usr/include/freetype2 > -I/usr/include/fribidi -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libgsf-1 > -I/usr/include/libxml2 -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/pango-1.0 -I/usr/include/libglade-2.0 -g -O2 -MT > XMPPUnixAccountHandler.lo -MD -MP -MF .deps/XMPPUnixAccountHandler.Tpo > -c XMPPUnixAccountHandler.cpp -fPIC -DPIC -o > .libs/XMPPUnixAccountHandler.o > In file included from XMPPUnixAccountHandler.h:24, > from XMPPUnixAccountHandler.cpp:20: > ./../../../backends/xmpp/xp/XMPPAccountHandler.h:27: error: > 'std::string' has not been declared > make[5]: *** [XMPPUnixAccountHandler.lo] Error 1 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Thu, Apr 24, 2008 at 12:47:11PM -0400, Eben Eliason wrote: > On Thu, Apr 24, 2008 at 12:40 PM, Martin Dengler wrote: > > On Thu, Apr 24, 2008 at 12:01:52PM -0400, Eben Eliason wrote: > > > On Thu, Apr 24, 2008 at 7:33 AM, Martin Dengler wrote: > > > > +return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \ > > > > + == gst.interfaces.MIXER_TRACK_MUTE > > > > > > If MIXER_TRACK_MUTE is a bit mask, isn't the equality check redundant? > > > > It's not a bitmask, IIUC. So no, it's not redundant AFAICS. But yes, > > it'd read much more nicely without the equality check if it wasn't. > > Hmmm, but you appear to be using it as such anyway. How else could > the boolean & be interpreted logically otherwise? (I may very well be > missing something here.) the GFlags class overrides the __and__ method...nice, eh? >>> master.flags >>> gst.interfaces.MIXER_TRACK_MUTE.__and__ >>> type(gst.interfaces.MIXER_TRACK_MUTE) >>> type(gst.interfaces.MIXER_TRACK_MUTE & gst.interfaces.MIXER_TRACK_MUTE) > - Eben Martin pgplSrcTMG9Dw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Add speaker device and icon by default
Add speaker device and icon by default, as in
http://wiki.laptop.org/go/Designs/Frame#07
---
src/hardware/hardwaremanager.py | 26 -
src/model/devices/Makefile.am |4 +-
src/model/devices/devicesmodel.py |3 +
src/model/devices/speaker.py | 59 ++
src/view/devices/Makefile.am |4 +-
src/view/devices/speaker.py | 119 +
6 files changed, 211 insertions(+), 4 deletions(-)
create mode 100644 src/model/devices/speaker.py
create mode 100644 src/view/devices/speaker.py
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 29be450..434f481 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -50,6 +50,13 @@ class HardwareManager(object):
if track.flags & gst.interfaces.MIXER_TRACK_MASTER:
self._master = track
+def get_mute(self):
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return False
+return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \
+ == gst.interfaces.MIXER_TRACK_MUTE
+
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
@@ -57,7 +64,16 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
-volume = self._mixer.get_volume(self._master)[0]
+
+volumes = self._mixer.get_volume(self._master)
+
+#sometimes we get a spurious zero from one/more channel(s)
+nonzero_vols = [v for v in volumes if v > 0.0]
+if len(nonzero_vols) != 0 and len(nonzero_vols) != len(volumes):
+volumes = nonzero_vols
+
+#we could just pick the first channel's volume, but this converges
+volume = sum(volumes) / len(volumes)
return volume * 100.0 / (max_volume - min_volume) + min_volume
@@ -76,7 +92,13 @@ class HardwareManager(object):
volume = volume * (max_volume - min_volume) / 100.0 + min_volume
volume_list = [ volume ] * self._master.num_channels
-self._mixer.set_volume(self._master, tuple(volume_list))
+#sometimes alsa fails to set all channels' volume, so try a few times
+last_volumes_read = [0]
+read_count = 0
+while (0 in last_volumes_read) and (read_count < 3):
+self._mixer.set_volume(self._master, tuple(volume_list))
+last_volumes_read = self._mixer.get_volume(self._master)
+read_count += 1
def set_mute(self, mute):
if not self._mixer or not self._master:
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..3124144 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -5,4 +5,6 @@ sugar_PYTHON = \
__init__.py \
device.py \
devicesmodel.py \
- battery.py
+ battery.py \
+ speaker.py
+
diff --git a/src/model/devices/devicesmodel.py
b/src/model/devices/devicesmodel.py
index 691e19e..32c77da 100644
--- a/src/model/devices/devicesmodel.py
+++ b/src/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import speaker
from hardware import hardwaremanager
from hardware import nmclient
@@ -54,6 +55,8 @@ class DevicesModel(gobject.GObject):
for udi in hal_manager.FindDeviceByCapability('battery'):
self.add_device(battery.Device(udi))
+self.add_device(speaker.Device())
+
def _observe_network_manager(self):
network_manager = hardwaremanager.get_network_manager()
if not network_manager:
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
new file mode 100644
index 000..d3b9967
--- /dev/null
+++ b/src/model/devices/speaker.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gobject
+
+from hardware import hardwaremanager
+from model.devices import device
+
+class Device(dev
[sugar] Recursive Signal Loop.
Hello, my name is Eben Eliason, and I have a problem... Symptom: The keep buttons in the Journal (the stars) take 1 second or so between being clicked and visually reflecting that change. This is, admittedly, a rather minor problem, but as you'll see, it spells out a larger underlying ugliness. I expect the feedback to be instant both because it's better that way, and also because the identical (well, nearly so, as shown below) favorite icons used in the list view of the new Home already function perfectly, and quickly. Diagnosis: Upon inspection, the KeepIcon class used in the Journal differs from the FavoriteIcon class used in Home in one crucial way. The former does not connect to a button-release-event at all, and instead depends on the code which uses it to do so for it, take the necessary actions based on the toggle, and then tell the KeepIcon itself that it has been clicked on in order to update its internal state and reflect that with visual changes. This is obviously the incorrect approach to the problem, as the KeepIcon should abide by all the wonderful properties that makes object oriented programming useful, manage its internal state so that, if nothing else, it remains consistent when clicked (it's basically a checkboxa boolean toggle), and notify anything that may happen to care about its value when it changes. Treatment: Take the object oriented approach above, which works nicely in Home, and should also work nicely in the Journal. This cleans up the code, and allows the KeepIcon to update its internal state immediately before emitting the signal, thus redrawing before anything which wishes to be notified of its state has a chance to waste lots of time, slowing feedback. Side-effects: This is where things get ugly. The above changes were trivial, but they create an ugly signal loop which makes the treatment worthless in its purest state as described above. Here's what goes down: When a KeepIcon is clicked, its button-release-event handler updates its internal state, including its keep property, which thus emits a notify::keep signal. The CollapsedEntry object which contains the KeepIcon connects to this signal in order to update the value of the keep key in the metadata of the associated JObject. So far so good. The DS then emits an updated signal, which includes a reference to the JObject which has been updated. Off in Never-Never-Land, query.py is listening for the update signal from the DS, and the handler for this signal replaces the JObject in its internal dict, and then emits its own modified signal. The listview.py connects to the modified signal, and its handler then calls self._do_scroll, which in turn calls self._refresh_view. The latter of these functions takes it upon itself to loop over all of the CollapsedEntry objects visible on screen, updating a match for the changed JObject by setting its corresponding jobject property. The method responsible for handling the setting of this jobject property within the CollapsedEntry then reads all of the info out of the newly passed JObject, and updates the entry as required. This includes setting the keep property of the KeepIcon within the entry, which cannot assume that it has previously been set, since this is also the function that gets called to initialize the CollapsedEntry in the first place. This, of course, triggers the do_set_property of the KeepIcon, which in turn emits a notify::keep signal. Hooray. Treatment of side-effects: Anyone know the best way to handle this issue? I'm fairly convinced that the fundamental changes to the KeepIcon class suggested above are the correct approach logically and semantically. I'm unsure about the correct way to sever the recursive loop, however. Any thoughts are very much appreciated, since I've now spent considerable time messing with an issue that I thought would have a 10 minute fix. - Eben PS. Thanks for listening! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Recursive Signal Loop.
I may not be understanding this right, but what if the CollapsedEntry, when it got the signal, checked if it was actually going to have to change the jobject, and if it was already kept, it would just abort? This would quash the signal the second time around - one step more than strictly necessary/ideal, but I don't know how to convince gtk not to send the signal if it was already pressed, which is what would be necessary to quash it exactly the first time. Either that or on this step: and updates the entry as required. This includes setting the keep property you check the keep property before you set it, and do not touch it if you are not going to change it. On 4/24/08, Eben Eliason <[EMAIL PROTECTED]> wrote: > > Hello, my name is Eben Eliason, and I have a problem... > > Symptom: The keep buttons in the Journal (the stars) take 1 second or > so between being clicked and visually reflecting that change. This > is, admittedly, a rather minor problem, but as you'll see, it spells > out a larger underlying ugliness. I expect the feedback to be instant > both because it's better that way, and also because the identical > (well, nearly so, as shown below) favorite icons used in the list view > of the new Home already function perfectly, and quickly. > > Diagnosis: Upon inspection, the KeepIcon class used in the Journal > differs from the FavoriteIcon class used in Home in one crucial way. > The former does not connect to a button-release-event at all, and > instead depends on the code which uses it to do so for it, take the > necessary actions based on the toggle, and then tell the KeepIcon > itself that it has been clicked on in order to update its internal > state and reflect that with visual changes. This is obviously the > incorrect approach to the problem, as the KeepIcon should abide by all > the wonderful properties that makes object oriented programming > useful, manage its internal state so that, if nothing else, it remains > consistent when clicked (it's basically a checkboxa boolean > toggle), and notify anything that may happen to care about its value > when it changes. > > Treatment: Take the object oriented approach above, which works nicely > in Home, and should also work nicely in the Journal. This cleans up > the code, and allows the KeepIcon to update its internal state > immediately before emitting the signal, thus redrawing before anything > which wishes to be notified of its state has a chance to waste lots of > time, slowing feedback. > > Side-effects: This is where things get ugly. The above changes were > trivial, but they create an ugly signal loop which makes the treatment > worthless in its purest state as described above. Here's what goes > down: > > When a KeepIcon is clicked, its button-release-event handler updates > its internal state, including its keep property, which thus emits a > notify::keep signal. The CollapsedEntry object which contains the > KeepIcon connects to this signal in order to update the value of the > keep key in the metadata of the associated JObject. So far so good. > The DS then emits an updated signal, which includes a reference to the > JObject which has been updated. Off in Never-Never-Land, query.py is > listening for the update signal from the DS, and the handler for this > signal replaces the JObject in its internal dict, and then emits its > own modified signal. The listview.py connects to the modified signal, > and its handler then calls self._do_scroll, which in turn calls > self._refresh_view. The latter of these functions takes it upon > itself to loop over all of the CollapsedEntry objects visible on > screen, updating a match for the changed JObject by setting its > corresponding jobject property. The method responsible for handling > the setting of this jobject property within the CollapsedEntry then > reads all of the info out of the newly passed JObject, and updates the > entry as required. This includes setting the keep property of the > KeepIcon within the entry, which cannot assume that it has previously > been set, since this is also the function that gets called to > initialize the CollapsedEntry in the first place. This, of course, > triggers the do_set_property of the KeepIcon, which in turn emits a > notify::keep signal. Hooray. > > Treatment of side-effects: Anyone know the best way to handle this > issue? I'm fairly convinced that the fundamental changes to the > KeepIcon class suggested above are the correct approach logically and > semantically. I'm unsure about the correct way to sever the recursive > loop, however. Any thoughts are very much appreciated, since I've now > spent considerable time messing with an issue that I thought would > have a 10 minute fix. > > - Eben > > PS. Thanks for listening! > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing l
Re: [sugar] Recursive Signal Loop.
On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > you check the keep property before you set it, and do not touch it if you > are not going to change it. That does in fact sound like a reasonable way to handle it. It doesn't require an extra time around "the loop"it simply stops it directly at the signal handler for the KeepIcon change event by not overwriting with the same value. Don't I feel stupid now Thanks! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Recursive Signal Loop.
On Thu, Apr 24, 2008 at 04:52:52PM -0400, Eben Eliason wrote: > I guess so, but that sounds like a pretty terrible hack. I guess I'd > have to set a flag within CollapsedEntry upon the notify::keep > callback, and then check for the state of that flag within the > set_jobject method of the same class, skipping the update of the > KeepIcon when true and setting it back to false. This is a roundabout > way of getting at it, though, and it actually *depends* on the > callback loop remaining intact in the future. Yah, that's pretty horrible. I was think more along the lines of passing a "change-owner token" through the API somehow. Maybe you can't do that because the API doesn't offer a slot for user-data. (This might be a good thing to add in the shiny new olpcfs?) Another idea, if you are certain you aren't going to use multiple threads, is to put the change-owner in a global variable. > Otherwise, the flag would get set on the callback, and never unset, > such that the next time a change was indeed performed outside the UI, > it would think that it just took a "long time" for the loop to go > around. > > On Thu, Apr 24, 2008 at 4:45 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > > I'm not sure if I understood the problem, but .. > > > > One way to handle this is to keep track of who made the change. If the > > change was coming from the user then the UI is already updated and does > > not need to be updated. If the change is coming from the DS (not the > > user) then the UI does need to be updated. -- Make April 15 just another day, visit http://fairtax.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Recursive Signal Loop.
On 24.04.2008, at 22:56, Eben Eliason wrote: > On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn > <[EMAIL PROTECTED]> wrote: >> you check the keep property before you set it, and do not touch it >> if you >> are not going to change it. > > That does in fact sound like a reasonable way to handle it. It > doesn't require an extra time around "the loop"it simply stops it > directly at the signal handler for the KeepIcon change event by not > overwriting with the same value. Don't I feel stupid now I'd even consider it a bug if overwriting a property with the same value would emit a change event - but maybe this is how the framework works? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Error when building libabiword-plugins
On Thu, 2008-04-24 at 20:00 +0200, J.M. Maurer wrote: > On Thu, 2008-04-24 at 16:34 +0200, Marco Pesenti Gritti wrote: > > Hello, > > > > I'm building libabiword-plugins on Fedora (soon to be) 9 and I get the > > following error. libstdc++ version is 4.3.0. > > > > Btw, can we update sugar-jhbuild to use 2.6.2? if someone can upload > > tarballs on sugar.abisource.com I'll be happy to take care of jhbuild > > modulesets update... > > Will do later tonight (I hope it works out of the box, because pyabiword > is a bit behind; i think everything sugar uses is up2date though). AbiWord 2.6.2 and pyabiword 0.6.1 pushed to jhbuild, 100% untested ofcourse (well, it compiles :) Marc > Marc > > > > Marco > > > > > > g++ -DPACKAGE_NAME=\"abiword-plugins\" > > -DPACKAGE_TARNAME=\"abiword-plugins\" -DPACKAGE_VERSION=\"2.6.0\" > > "-DPACKAGE_STRING=\"abiword-plugins 2.6.0\"" > > -DPACKAGE_BUGREPORT=\"http://bugzilla.abisource.com/\"; > > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > > -DHAVE_UNISTD_H=1 -DHAVE_STRINGS_H=1 -DPACKAGE=\"abiword-plugins\" > > -DVERSION=\"2.6.0\" -DHAVE_DLFCN_H=1 -DHAVE_BOOST= > > -DHAVE_BOOST_THREAD= -I. -I. -I./../../.. -I./../../../core/packet > > -DDEBUG -DUT_DEBUG > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/util/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/ptbl/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/impexp/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/spell/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/fribidi/xp > > -I../../../../../../libabiword-2.6.0.svn20071127/src/other/ttftool/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/xap/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/ev/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/af/gr/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/text/fmt/unix > > -I../../../../../../libabiword-2.6.0.svn20071127/src/wp/ap/unix > > -DABI_PLUGIN_VERSION=\"2.6.0\" -DABI_PLUGIN_MAJOR=2 > > -DABI_PLUGIN_MINOR=6 -DABI_PLUGIN_MICRO=0 -DABI_PLUGIN_SOURCE=1 > > -DABICOLLAB_RECORD_ALWAYS -I/usr/include/loudmouth-1.0 > > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > > -DABICOLLAB_HANDLER_XMPP -I/usr/include/freetype2 > > -I/usr/include/fribidi -I/usr/include/glib-2.0 > > -I/usr/lib/glib-2.0/include -I/usr/include/libgsf-1 > > -I/usr/include/libxml2 -I/usr/include/gtk-2.0 > > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > > -I/usr/include/pango-1.0 -I/usr/include/libglade-2.0 -g -O2 -MT > > XMPPUnixAccountHandler.lo -MD -MP -MF .deps/XMPPUnixAccountHandler.Tpo > > -c XMPPUnixAccountHandler.cpp -fPIC -DPIC -o > > .libs/XMPPUnixAccountHandler.o > > In file included from XMPPUnixAccountHandler.h:24, > > from XMPPUnixAccountHandler.cpp:20: > > ./../../../backends/xmpp/xp/XMPPAccountHandler.h:27: error: > > 'std::string' has not been declared > > make[5]: *** [XMPPUnixAccountHandler.lo] Error 1 > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Recursive Signal Loop.
On Thu, Apr 24, 2008 at 5:25 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > > On 24.04.2008, at 22:56, Eben Eliason wrote: > > > > On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn > > <[EMAIL PROTECTED]> wrote: > > > > > you check the keep property before you set it, and do not touch it if > you > > > are not going to change it. > > > > > > > That does in fact sound like a reasonable way to handle it. It > > doesn't require an extra time around "the loop"it simply stops it > > directly at the signal handler for the KeepIcon change event by not > > overwriting with the same value. Don't I feel stupid now > > > > > I'd even consider it a bug if overwriting a property with the same value > would emit a change event - but maybe this is how the framework works? Good point. That seems not to be the case. In other news, despite the much cleaner underlying code, my initial treatment fails to alleviate the symptom! It appears that the redraw doesn't happen until after all of the signal handling business has run its course. This includes, as mentioned in my first message, refreshing the entire view. I looked at this again, and there is no check for the particular CollapsedEntry which changed at all. Instead, it loops over each one, refreshing each by setting the jobject property of each, which of course resets the keep icon, resets the object icon, creates a brand new palette from scratch and attaches it to the object icon, looks up and formats the date, reads the list of buddies and creates their associated objects and palettes, and a number of other smaller tasks. That's for /each/ entry shown, all because one toggle button was clicked! This seems like serious overkill, but I'm not sure if there's an obvious way to isolate the changes. It does seem that, if anything, either the query.py or listview.py code should be more intelligent about determining what changes are worth doing such comprehensive updates for. This is not one of them. Tomeu, you worked on the query and list code. Do you have any insight into this? - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Organization was Re: A technical assessment of porting "Sugar" to Windows.)
On Thu, Apr 24, 2008 at 2:21 PM, Mitch Bradley <[EMAIL PROTECTED]> wrote: > A general observation about organizational behavior: > > Organizations do not act coherently to nearly the same extent as > individual humans. Individuals change their minds, act in ways > inconsistent with their stated goals, respond to different external > pressures at different times, etc. With organizations it is even worse, > and the larger the organization, the more complicated it becomes. > Organizational leadership changes, goals and external realities change, > internal groups vie for influence, compete with one another and work at > cross purposes. Different people within the organization make > statements that are attributed to "the organization". > > Expecting an individual to behave coherently over time is dodgy at best; > expecting it of an organization is almost certain to disappoint. > > In the OLPC case, the leadership at the very top hasn't changed, but the > second tier has changed, and the situation and external pressures have > changed drastically. Yes, the middle tier is now supposed to be Kim Quirk (Technology), Robert Fadel (Administration), Charles Kane (Business Development), and whoever replaces Walter in Deployment. Has anybody heard? The failure to announce such things is one of my biggest complaints. Kim and Robert are adamant about not supporting first world deployments, although they sort of allow them. GiveMany is a joke, and the OLPC community isn't permitted to discuss projects like Illinois (100,000 units proposed) with the staff. I haven't talked to Charles. That reminds me. Do we have any idea what the Boards of Director and Advisors think about all of this? http://laptop.org/vision/people/ Does anybody have contact information for them? I have a few e-mail addresses. Well, I'll ask. Dandy, Ed, Joe; Alan, Mako (all bcc) pass it on, please, and read the thread. We think that Nicholas doesn't know what he is talking about with this Sugar on Windows idea and dissing Open Source, that he is and has been dangerously out of touch with staff and volunteers, and that he is now endangering the mission. Problems like this are supposed to be the reason for a Board of Directors to exist in the first place, so we want to hear that Board members are taking the issue seriously, and preferably see evidence that you are listening to what is going on, and understand the issues. Advisors, any assistance you can give will be appreciated. This is the time to advise, if ever there was one. Nicholas's post http://www.olpcnews.com/people/negroponte/nicholas_negroponte_sugar_olpc.html Replies and related posts http://lists.laptop.org/pipermail/devel/2008-April/thread.html#13140 On Sugar (Development) http://lists.laptop.org/pipermail/sugar/2008-April/thread.html#5173 On Sugar (Sugar) http://lists.laptop.org/pipermail/community-news/2008-April/thread.html#112 Where is Walter http://www.olpcnews.com/people/negroponte/open_source_fundamentalists.html http://www.olpcnews.com/people/negroponte/one_laptop_per_child_off_the_track.html http://www.olpcnews.com/people/negroponte/negroponte_is_further_gone.html http://www.olpcnews.com/people/leadership/walter_bender_resigned_from_olpc.html -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
