New ship.2 build 647
http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build647/ -olpc-library-common.noarch 0:1-5 +olpc-library-common.noarch 0:1-8 -olpc-library-core.noarch 0:1-5 +olpc-library-core.noarch 0:1-8 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Ar 30/11/2007 am 10:25, ysgrifennodd Eben Eliason: I have been reviewing the code in the chat application and given the abilities of the dbus do not feel that text messages will add all that much complexity to the application. My original query was not as much having a chat window in my activity but more of a Delphi like component that I could drop into the buddy panel weld into my existing tubes and be done with chat. This, I do believe is probably a fantastic thing to work on. What we really need in cases like this is, as you say, a chat widget that is based on the chat activity, having the same look, feel, options, etc. Just as we have an Abiword widget for text which can be used anywhere we should adopt a standard chat widget that can be designed and maintained by OLPC, so that the experience is always consistent and any fixes or improvements are automatically seen within any activity that makes use of it. Do those working on Chat see this as a viable possibility? I don't see any reason why not. Do you envision this as something that might be enabled in every activity automatically, or something that each activity would integrate manually? The former might mean that the chatting UI would be more consistent, but perhaps allows for less flexibility in integrating with different styles of activity UI. (Shared activities are built on top of chat rooms, so there's already a way for all the participants to send messages to each other.) -- Dafydd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New ship.2 build 649
On Nov 30, 2007 5:30 PM, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build649/ This is now our ship.2 candidate. http://download.laptop.org/xo-1/os/official/649/jffs2/ Library cleanups and a Record fix. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updated glibc-2.7 for geode
Rob Savoye wrote:
The geode patch must be in sysdeps/i386/i686, not in i585. For the
Geode support, it only configures correctly if the geode sub directory
is in the i686 directory.
Ok, I got the 2.7 packages to build:
http://www.codewiz.org/pub/glibc-geode-2.7/
These can replace the older glibc-2.6.90-19 after performing the
usual tmpfs dance:
mount -t tmpfs none /usr/lib/locale
rpm -U --ignorearch glibc-2.7-2.geode.rpm glibc-common-2.7-2.i386.rpm
mv /usr/lib/locale/locale-archive /
umount /usr/lib/locale
mv /locale-archive /usr/lib/locale
{one of these days we need to teach build-locale-archive to fall
back to read()/write() whenever mmap() fails}
The system boots normally and I didn't measure a relevant
change in boot time.
Now it would be a good time to perform some application
benchmarking. Feedback welcome.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Gerard, I am properly admonished and shall hold my performance speculations until my machines arrive. I just wanted to mention that it is not conceivable. (I even took a picture but forgot to put a link: http://dev.laptop.org/~yoshiki/pictures/pict0425.jpg ) The performance is probably a less-challenging issue. Giving flexibility to developers and users while proctecting an activity from others is another thing. I thought using another activity as a library in yours in the same address space was something the security people would like to avoid. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Signed 648 (ship.2 release candidate)
A signed copy of build 648, which is our ship.2 release candidate, is now at: http://download.laptop.org/xo-1/os/official/648/jffs2/ This build contains firmware q2d05, available separately at: http://dev.laptop.org/pub/firmware/q2d05/ --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
linkchecker script
Hey! I've just written a simple linkchecker script in python, and thought someone could perhaps use it. It recurses through the links of a given domain and stays inside that domain. For found links it gives you the feedbacks: ok, outside, 404, https http://wiki.laptop.org/go/Linkchecker.py Regards, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
On Fri, 2007-11-30 at 06:51 -0800, Gerard J. Cerchio wrote: I have been reviewing the code in the chat application and given the abilities of the dbus do not feel that text messages will add all that much complexity to the application. My original query was not as much having a chat window in my activity but more of a Delphi like component that I could drop into the buddy panel weld into my existing tubes and be done with chat. I think it wouldn't be hard to provide a set of gtk widgets that provide that functionality so activities can embed. I have now become anxious about whether the 19x19 go board is feasible on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go world considers these less than optimal. There will be quite some time before I get my G1G1's and only have sugar-jhbuild to run on. Is it possible for anyone reading this to download the basic frame and report if the 19x19 grid is usable? You may find it at https://dev.laptop.org/git?p=projects/PlayGo;a=tree https://dev.laptop.org/~tomeu/playgo.png Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Ties Stuij wrote: I must admit I didn't check your code but i found playing on a 19x19 board in Hikaru no go on a GBA quite doable. And that has a 240x160 screen!! I strongly suggest offering a 19x19 option, even if it is a bit less clear. The game gets a lot more interesting with the size-upgrade. /Ties Thanks Ties, It comes up in 19x19. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New ship.2 build 647
Le vendredi 30 novembre 2007 à 04:44 -0500, C. Scott Ananian a écrit : We believe this build also fixes our linksys WDS interoperability problems, and seems to be able to connect to more access points. Still doesn't work for me: http://dev.laptop.org/ticket/4858#comment:13 G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
A signed copy of build 648, which is our ship.2 release candidate, is now at: http://download.laptop.org/xo-1/os/official/648/jffs2/ This build contains firmware q2d05, available separately at: http://dev.laptop.org/pub/firmware/q2d05/ Great! but sorry for my ignorance but what a signed copy means? Shall we test it on our (B4) laptops? Or it'll make it hard for future update? http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ is the same thing but unsigned? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
There are some activities where the chat is an integral part of the participants' experience. In my case, chatter during the Go game may be nonexistent to multiple lines of interactive tutorial per move to razzing and praise from any of the observers. This is why I plan to have a mute button that mutes all chat from observers. Unchecked, the button allows kibitzing from all XO's in the buddy panel that joined the PlayGo activity. Well, the exact implementation isn't well defined at this point. Obviously it's advantageous to be able to chat and work/play at the same time. Doing this generically is hard because the screen is rather small and there is no place where such a chat window can always be positioned such that it isn't in the way. The overlay idea, fullscreen or not, is the best general purpose solution we have so far. Perhaps if we gain compositing support it can work somewhat like growl on OSX; perhaps a global keystroke will initiate a new chat bubble so to speak, so that joining in the conversation doesn't require clicking a button on screen or shifting contexts. We're not sure the details yet, but the more seamless we can make it the better. This is not the functionality that I interpreted from Bert's comment: I thought this was intended to be a feature similar to the frame (and actually summoned by the frame key), layered on top of the activity, so it actually would work for *all* activities, Python or not. - Bert - I may be wrong in interpreting the ubiquitous chat interface as a full screen overlay on top of the application where the child must either chat into the overlay or switch modes to play the game. Are you suggesting that the ubiquitous chat can be relegated to its own panel on the activity's screen so there is no mode switching between chat and the underlayed activity Obviously you gain the most real-estate for the chat this way. However, this also cuts off the activity completely, if only temporarily, which may not be what we want in the end. I think something slightly lighter would be desired. The question remains as to whether or not it is repositionable, since we have yet to introduce the idea of windows. Obviously the push-to-talk method mitigates this problem, since the interface for such a system requires one onscreen button, or even one well known shortcut. Would either of the two (or more) participants in the activity be able to mute observers? I find both of these functionalities fundamental to the activity experience and the tutored activity experience. This is an absolute fundamental requirement to any audio/video chat, in my opinion, for the sake of privacy. This requirement needs to make it into the HIG. Also, being that most of the video processing is offloaded in the Geode, I look forward to morphing the chat panel into a video call to my Go opponent. The PlayGo application takes very little resource, so there is plenty of ommf left over to run the video call. It would be the next best thing to playing in the same room. I think there's something to be said for activities which don't require much oomf. I think the do one thing, do it well mantra is a good one, and one that might apply here. The screen is small, so dedicate as much space as possible to the board, which has a large number of squares. There is very limited RAM and CPU on these machines, so just because your game doesn't eat too much doesn't mean you should assume it will be reasonable to consume a significant amount of these for add-ons, not to mention greatly increase network activity. I'm not sure that a multi-way video conference is even feasible yet. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
On Fri, 30 Nov 2007 at 07:51:38 -0500, Eben Eliason wrote: I'm not sure that a multi-way video conference is even feasible yet. It's certainly not in the short term - the Telepathy and Farsight frameworks, and the underlying protocols they currently use (Jingle), only support 1-1 audio/video calls at this point, and we'd need a lot of API and protocol design work to even start on this. Whenever we've talked about video-conferencing in the office, our VoIP people's opinion has been that in practice we'd probably also need a (fairly hefty) server to multiplex the streams for us, which doesn't work so well in the OLPC use-case anyway. (disclaimer: I might be wrong, opinions might have changed; I'm not a VoIP hacker myself) Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Eben Eliason wrote: There are some activities where the chat is an integral part of the participants' experience. In my case, chatter during the Go game may be nonexistent to multiple lines of interactive tutorial per move to razzing and praise from any of the observers. This is why I plan to have a mute button that mutes all chat from observers. Unchecked, the button allows kibitzing from all XO's in the buddy panel that joined the PlayGo activity. Well, the exact implementation isn't well defined at this point. Obviously it's advantageous to be able to chat and work/play at the same time. Doing this generically is hard because the screen is rather small and there is no place where such a chat window can always be positioned such that it isn't in the way. The overlay idea, fullscreen or not, is the best general purpose solution we have so far. Perhaps if we gain compositing support it can work somewhat like growl on OSX; perhaps a global keystroke will initiate a new chat bubble so to speak, so that joining in the conversation doesn't require clicking a button on screen or shifting contexts. We're not sure the details yet, but the more seamless we can make it the better. Obviously you gain the most real-estate for the chat this way. However, this also cuts off the activity completely, if only temporarily, which may not be what we want in the end. I think something slightly lighter would be desired. The question remains as to whether or not it is repositionable, since we have yet to introduce the idea of windows. Obviously the push-to-talk method mitigates this problem, since the interface for such a system requires one onscreen button, or even one well known shortcut. I would like to see the OLPC retain its non-windowed presentation style. I have run into people that have no idea how many windows are running. When they do not see the browser, they simply start another one, ignoring Z order and minimized applications. Don't laugh, my wife and I are the ISP for our condo complex and we have a few service calls along these lines. Given the OLPC environment, fixed frames and whole screen activity switching makes a lot of sense. So if I am performing an activity that does not require chat and wish to reference a colleague on line, hitting F3 and choosing the chat application is not offensive at all. For those activities that require chat, the interaction should happen in the context of the application's display structure. I am lucky that my particular application is square, this lends the rest of the rectangle to the buddy panel, which has the list of the participants in the upper half with the lower half containing the chat window. I am just finishing the basic game communications and will be moving on to the game player negotiation and setups this weekend. I am resisting tabbing the tool bar for these tasks if at all possible to prevent my square Go board from getting any smaller. I have been reviewing the code in the chat application and given the abilities of the dbus do not feel that text messages will add all that much complexity to the application. My original query was not as much having a chat window in my activity but more of a Delphi like component that I could drop into the buddy panel weld into my existing tubes and be done with chat. I think there's something to be said for activities which don't require much oomf. I think the do one thing, do it well mantra is a good one, and one that might apply here. The screen is small, so dedicate as much space as possible to the board, which has a large number of squares. There is very limited RAM and CPU on these machines, so just because your game doesn't eat too much doesn't mean you should assume it will be reasonable to consume a significant amount of these for add-ons, not to mention greatly increase network activity. I'm not sure that a multi-way video conference is even feasible yet. I have now become anxious about whether the 19x19 go board is feasible on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go world considers these less than optimal. There will be quite some time before I get my G1G1's and only have sugar-jhbuild to run on. Is it possible for anyone reading this to download the basic frame and report if the 19x19 grid is usable? You may find it at https://dev.laptop.org/git?p=projects/PlayGo;a=tree Thanks - Gerard ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
I would like to see the OLPC retain its non-windowed presentation style. I have run into people that have no idea how many windows are running. When they do not see the browser, they simply start another one, ignoring Z order and minimized applications. Don't laugh, my wife and I are the ISP for our condo complex and we have a few service calls along these lines. Given the OLPC environment, fixed frames and whole screen activity switching makes a lot of sense. So if I am performing an activity that does not require chat and wish to reference a colleague on line, hitting F3 and choosing the chat application is not offensive at all. Agreed. We aim to implement some really nice forms of activity switching as well. For those activities that require chat, the interaction should happen in the context of the application's display structure. I am lucky that my particular application is square, this lends the rest of the rectangle to the buddy panel, which has the list of the participants in the upper half with the lower half containing the chat window. I am just finishing the basic game communications and will be moving on to the game player negotiation and setups this weekend. I am resisting tabbing the tool bar for these tasks if at all possible to prevent my square Go board from getting any smaller. I really think that the toolbar should be tabbed, actually, despite the loss of those 45px. You really should have some basic controls like new game, perhaps undo/redo move, a board size selector, etc. Having all of these basic games controls neatly laid out along the top of the screen would be quite appropriate, I think. I have been reviewing the code in the chat application and given the abilities of the dbus do not feel that text messages will add all that much complexity to the application. My original query was not as much having a chat window in my activity but more of a Delphi like component that I could drop into the buddy panel weld into my existing tubes and be done with chat. This, I do believe is probably a fantastic thing to work on. What we really need in cases like this is, as you say, a chat widget that is based on the chat activity, having the same look, feel, options, etc. Just as we have an Abiword widget for text which can be used anywhere we should adopt a standard chat widget that can be designed and maintained by OLPC, so that the experience is always consistent and any fixes or improvements are automatically seen within any activity that makes use of it. Do those working on Chat see this as a viable possibility? I have now become anxious about whether the 19x19 go board is feasible on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go world considers these less than optimal. There will be quite some time before I get my G1G1's and only have sugar-jhbuild to run on. Is it possible for anyone reading this to download the basic frame and report if the 19x19 grid is usable? You may find it at https://dev.laptop.org/git?p=projects/PlayGo;a=tree Even if you tab the toolbar, you'd wind up with a square that's about 41px in size. Our recommended minimum size is 45px square for a clickable area, so it sounds like you'll be fine, albeit on the smaller side. - Eben Thanks - Gerard ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Yoshiki Ohshima wrote: Well, I know that I can make a user document with a running movie clip, real time view-finder of camera, spectrum analysis of audio input, and a user-scripted simulation going at the same time on B4 (4-5 fps is not so great though). These widgets are running in the same address space but that is offset by some facts such as Etoys display model is not optimal, our code for playing movie, copying bits of video frames to make the player a real end-user scriptable object, FFT are not optimized, etc. It should be possible to provide an ok experience for most of the time and I was not talking unrealistic rant, I believe. -- Yoshiki ___ Yoshiki, I am properly admonished and shall hold my performance speculations until my machines arrive. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
--- Yoshiki Ohshima wrote: Great! but sorry for my ignorance but what a signed copy means? Shall we test it on our (B4) laptops? Or it'll make it hard for future update? http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ is the same thing but unsigned? -- Yoshiki --- end of quote --- Signed means that it will work on a write protected machine. If you're laptop is not write protected, the unsigned version will work exactly the same. - AlexL ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
