Re: [sugar] notes on 8.2.0, specifically 767 (was 8.2.1)
greg wrote: Hi Bryan, ... * 767 seems to enforce rainbow more strictly than 703. This has given me major headaches when trying to make our new flash-based activities run properly on 767. GS - I think you submitted the details. Did you get an answer? I believe that Michael is out for Thanksgiving. Can someone comment on this point? http://lists.laptop.org/pipermail/sugar/2008-November/010070.html ... * Firefox 2 and 3 are only slightly sugarized. GS - True. It is what it is and no plans to make big changes here AFAIK. greg -- i think you answered your own question. the issues raised in that linked email are a result of firefox not being fully sugarized. it might be possible to improve their behavior, but this falls squarely under the big make traditional X11 apps work better under sugar umbrella. paul =- paul fox, [EMAIL PROTECTED] give one laptop, get one laptop --- http://www.amazon.com/xo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
tomeu -- excellent! thanks for helping make progress on this. tomeu wrote: http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). the ultimate fallback would simply be a URL, with which Browse could take you to a (hopefully friendly) source browser on the web somewhere -- to browse CVS or git, for instance, or even just to an upstream program-specific website where more information is available. as you implied, flexibility is the key. Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. an addition to activity.info, with sensible defaults, would be the best bet, i think. default behaviors could include going to bundled source, as you've implemented, and/or using the activity_source URL that many activities provide on the download page on the wiki. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Printing support
c. scott ananian wrote: On 10/21/08, Martin Langhoff [EMAIL PROTECTED] wrote: On Sat, Oct 18, 2008 at 9:24 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: *But*, we should be able to: * Print postscript (or pdf, or whatever, just pick *one*) to school server via CUP (IPP?), and install a decent selection of printer drivers on the school server. Control panel for 'default printer name', fixed to 'XS' by default. Ok - adding the XS side of this is something we can do in the 9.1 lifecycle. As I mentioned in my other email, the mechanical part of getting printing done is not the most interesting part of the job. It's the I think we're on the same page here. For 9.1, what's the *least* work we can do to get *something* done on the printing front? Once the basics are out there, hopefully we'll have community motivated to take it the rest of the way, whatever that is. From the comments here, it seems like the no-discovery no-server CUPS client library could work with a fixed server name (or control panel with IP address box to fill in), and we can take it from there gradually. If anyone wants to can's mdns/avahi help with discovery? it'd be a shame to have to manually configure a server address or name. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Dependencies (was [Activities] Tux Typing on OLPC XO)
bert wrote: See http://wiki.laptop.org/go/Activity_bundles#Bundling_Native_Libraries it sure seems like there should be a way for an activity to specify a yum'able rpm, and have the system make sure that's installed, along with any secondary dependencies. seems preferable to having activities drag along possibly redundant, or obsolete, copies of libraries. i guess the activity would need to suggest apt-get'able names as well, for non-fedora-based installations. as an example, older versions of RoadMap used to include libexpat because i think it wasn't in 656. i happened to notice that it was included in later releases, so i dropped it from the activity bundle, but if i hadn't noticed, it would have been a complete waste of space, on disk, and possibly in memory. (actually, i'm not sure how the loader deals with conflicting library versions -- could it perhaps even cause a conflict? not sure about that.) [ hmmm. all this begs the question: what happens to activities when someone ports sugar to an incompatible architecture: a bsd variant, macos, or even non-x86 linux. binary activities (and certainly any libraries they bring along) will cease working -- do we have an versioning mechanism to keep things sane in that scenario? ] paul - Bert - Am 20.10.2008 um 15:20 schrieb Brian Jordan: How should dependencies like TuxType's be handled? (found list at http://sophie.zarb.org/rpm/Momonga,4,x86_64/tuxtype/deps ) Thanks Brian -- Forwarded message -- From: David Bruce [EMAIL PROTECTED] Date: Mon, Oct 20, 2008 at 7:39 AM Subject: [Activities] Tux Typing on OLPC XO To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hello, I maintain two of the Tux4Kids apps, Tux Typing and TuxMath. At the request of the OLPC project, I have been working on getting Tux Typing to run well on the XO. I have completed the most important changes needed for Tux Typing itself, and it is now time to address bundling it as a Sugar activity. Tux Typing is a C program with a number of library dependencies, not all of which are in the XO base setup. Where can I look for info on this topic? David Bruce ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Legacy compatibility.
can we stop referring to anything non-sugary as a legacy app. i'd submit that we all use dozens of such apps every day, most of which are in no danger of going away anytime soon. :-) how about referring to them as existing X11 apps. paul c. scott ananian wrote: I'd like to present a few areas where sugar can play nice with others, including: * replacing the matchbox window manager, to provide better multiple-window support for legacy apps (think of the 'gimp', running as multiple windows without one full-screen activity area aka virtual desktop) * making sugar behave well when run in non-full-screen-mode under metacity. This includes refactoring home/friends/mesh view as operations on root window, so they make sense in a multiwindow setup. (It's been suggested that looking at the xpenguins code is instructive for understanding how nautilus,etc arrange their root window.) * Switch to standard freedesktop.org startup notification mechanism: ticket #5271 * Implement freedesktop.org notifications mechanism for alerts (low battery, low disk space, available software update) * Use standard fd.o notification area in frame -- I think this would also address cjb's desire to put the 'stop' button for recordmydesktop in the frame. I don't think I will actually have time to work on many of these areas in the 9.1 time frame, so I especially encourage interested/motivated parties to make concrete proposals on pieces of this work. (Or suggest other areas we should improve.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
a few random observations that i had today, prompted by scott's talk/demo: - while people don't tend to name their jpegs (today), they do tend to group them into folders (e.g. vacation_pix). the equivalent of this in a tagged world would be bulk tagging. i assume scott has thought about this in his UI, though i don't recall noticing it. - likewise, removing all the files in a directory, or moving half of them elsewhere (imagine rearranging the photos you just pulled off the camera), implies that there should be equivalent tag operations for doing bulk tag removal, and bulk tag editing. (note that this need is independent of the path-component-as-tag feature -- these operations are simply required of any system intended to replace hierarchy with tags.) - jim made the observation that he found himself using tags less and less over time, once he realized that the full-text indexer he was using made traditional filing unnecessary. i've found the same thing (i index my MH mail folders with mairix) -- but i do still use folders (i.e., tag equivalents) to make it easy to retrieve things for which i think i may not remember the right search terms later on. and of course i especially use them when the tags (folders) can be assigned automatically (with sort filters). all of which is to say that i view tagging as an extension of full-text search, not a replacement. - we need to be mindful of erik's concern that if the goal is to solve the problems deployments are reporting, whether with file management or anything else, that we not over-engineer the design in a way that keeps us from finishing the implementation. while our mission may be to build something better, we shouldn't let that get in the way of building something that, while old, is very useful. (e.g., if we haven't made enough progress on the real solution, and kids would be best served in 9.1 by a file manager activity of some sort, then we should provide one.) =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Meeting about the journal
c. scott ananian wrote: Anyway, we can discuss this more tomorrow am. I'll be in at work tomorrow am; poke me or one of the early risers on IRC (pgf, erikg, etc) if I don't remember to log in, tune in, etc. yow. my reputation is shot. :-) =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (very) Little Proposals for 9.1
simon wrote: Carlo Falciola wrote: Giovanna: Why not to enable shut-down from the XO icon of any of the standard view? The icon is always there in the middle of screen but works only in one... (in general, maybe enabling the hoovering menu in all of the views Home, Neighborhood, Group could make sense and could be reasonably easy to do) The idea was that you do not need to shut down, rather suspend the machine :) The palette in the mesh and group view could be used for i realize simon was smiling as he said this, and that giovanna's need is a relatively small one, but this exchange, along with many conversations surrounding the importance of fast boot time, are a perfect example of something Elana Langer said just yesterday: You cannot tell people how to use their computers or what to expect from them. ... All we can do is offer a tool (computer) and help folks think about integrating it into their communities and curriculums but you CANNOT change expectations by simply not meeting them. the fact is that we don't (and may never) consume so little power that the laptop can be used heavily on a daily basis, in a place where power is scarce, and not need to be shut down. simply repeating suspend will take care of that eventually won't solve our users needs today. (again, not picking on simon. elana's observation just happened to strike a chord for me yesterday, and this note gave me an excuse to reiterate it.) paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (very) Little Proposals for 9.1
jerome wrote: I agree with this. I was with my (almost) 7 year old daughter yesterday and she was studying scratch with 767 and after an hour of playing around, she told me that she wants to turn it off (the XO) but she couldn't determine how as there is no obvious way of doing so from the OS unlike what she can do on XP or Gnome, so the first thing she did was press the power button. i've always been surprised that the power button doesn't allow shutdown. i think the button should invoke a menu, which, if left untouched for 5 or 10 seconds, would allow the laptop to sleep as it does now. the menu should have entries for cancel and shutdown. i suppose for completeness there should be one for suspend as well, but reboot is unnecessary, imho. (if this menu were present, there might be no need for those entries in the UI itself.) paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
mikus wrote: Deniz wrote: ... I also think, since this is a significant investment for many people, referring to my original example of a teacher typing up a reading (from a book let's say, or a handout) on a regular computer s/he already has back home, and being able to transfer files back and forth on an Xo so s/he can distribute it to his/her students. One of the regulars on this list mentioned 'copying'. That reminded me that the best current tools I know of for manually transferring files in and out of the XO datastore are copy-from-journal and copy-to-journal (scripts originally written by users). Note that copy-to-journal requires the mime-type of the file to be supplied. can you provide a pointer to these scripts? paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
mikus wrote: Talking about copy-from-journal and copy-to-journal: can you provide a pointer to these scripts? Try 'which'. On my XO they're in /usr/bin. doh! i guess i don't use my XO as much as i thought! when you said written by users i assumed you meant you had obtained them from someone's personal website somewhere -- there's certainly a lot of that kind of stuff out there. thanks for the (rather short) pointer. :-) paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar USB testing
[EMAIL PROTECTED] wrote: ... To get developers eating dog food with the XO you would need the following: 1.) The Develop activity completed so it is usable for writing code ... 2.) An IMAP client Activity and corresponding IMAP server on a school ... actually, i don't think either of these is necessary, though they might be sufficient for some people to get them to use their XO more. i may have been misleading in my earlier mail: i don't use the XO for everything -- not even close. like most professionals i set high standards for my tools, and the XO doesn't meet a lot of those standards (e.g., speed, capacity, UI flexibility -- not to mention the keyboard :-). but it does some things very well, and i use my XO for things that are appropriate to its capabilities: i use it if i want to be connected while in the sun in the backyard. i took it on vacation as my only laptop, because it's so small. i tranfer all the email (and irc logs, and Weekend reports) that appear overnight onto my XO, and read them on the bus or subway on my way to the office in the morning -- where e-book mode is very convenient. i'll bet most people could choose one or two daily tasks and force themselves to use the XO for those activities. the main thing is to get yourself out of the debug/test/reload cycle, and see what it means to actually use the machine. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar USB testing
marco pesenti gritti wrote: On Sun, Oct 5, 2008 at 6:37 PM, Walter Bender [EMAIL PROTECTED] wrote: CCing the Sugar list. and adding devel. It seems that one of the problems we will be encountering with generic spins is footprint. Even a standard Ubuntu without Sugar was seeming too fat to load from a LiveCD on a Pentium 4 with 256K of DRAM. I'm planning to dogfood the Fedora LiveUSB and I'll have a look to memory usage while doing so. In principle, unless there are relevant memory costs given by running on a LiveUSB, I'd expect it to work decently. i've been curious for a while -- can we have a show of hands for how many people dogfood the existing XO s/w? for my part, i don't, to the extent that i yum-install xfce and run that. so there's little memory pressure, and i don't run activities, nor networkmanager. but i'm still running the kernel and most of the system software. i can quickly switch to running sugar, and i do, when i discover something that i think needs investigating on a more real installation. i think even my limited dogfooding has been useful -- the bugs i've found or helped diagnose have tended to be power management issues, and some yum package management issues. i _really_ think we need to make the XO base _and_ sugar be a place that developers are comfortable living in. our needs aren't quite the same as a school kid's, but i think there's a much bigger overlap than we often think. with the advent of the fedora spin we're going to lose xo/sugar mindshare among our g1g1 and development users [1], and i think we need to think seriously about taking up that slack. even if that means adding some poweruser-centric features which a grade-schooler would probably never use, it's worth considering, in return for the increased focus, and yes, discomfort it may cause. paul [1] but i think we'll gain in overall project mindshare, so in net i'm in favor of it. =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
mikus wrote: - First off, every Activity has a 'Name Field' in its top menu. When running any Activity, the user should enter there a short Title to identify the resulting Journal entry from all others. - Then, upon leaving that Activity, the user should reflect on what was done, and update the corresponding Journal entry to make it easier to find later. This is particularly desirable if the Title is not meaningful enough by itself for later locating what the user is looking for: in a traditional system, when a user saves their work, they are pretty much forced to enter the (hopefully) useful name by which that work will be retrieved. if searching is the fundamental retrieval mechanism (which i think is fine), then my first reaction to mikus' advice is that activities and/or sugar should be more emphatic about asking for the descriptive information which be useful later. i.e., adding search tags shouldn't be an optional extra step, but a usual step which must be explicitly skipped by the user. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New system dependency (alsa-lib-devel)
marco pesenti gritti wrote: This is used by the new volume code. I added it to Fedora, not sure what's the right package name for ubuntu. libalsaplayer-dev, if what you mean is the code necessary for doing development. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New system dependency (alsa-lib-devel)
marco pesenti gritti wrote: On Sat, Sep 13, 2008 at 4:31 PM, [EMAIL PROTECTED] wrote: marco pesenti gritti wrote: This is used by the new volume code. I added it to Fedora, not sure what's the right package name for ubuntu. libalsaplayer-dev, if what you mean is the code necessary for doing development. Does it contain asoundlib.h? sorry, no. that would be in: libasound2-dev =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] multiple activities per bundle
[ this isn't related to 8.2 at all. greg, please ignore. :-) ] one missing piece (for me) in sugar is easy user customization of the desktop. in other window managers it's fairly trivial to create menu items (or toolbar buttons or icons...) that invoke personal favorites. under sugar, custom actions are expensive in that you need to create an activity bundle for every little one-line shell script you might want to invoke. thinking about this problem led me to the following pseudo-design, which i think could be useful in other ways as well. basically, i think a single activity bundle should be allowed to represent multiple activities. the activity.info file currently specifies the name, icon, command, etc., for an activity. this file format could be extended to allow a single bundle to expose multiple activities: [Activity] # global information for the bundle. for backward compatiblity, # any name/icon/exec information here would still be honored, # and any key/values pairs not supplied by a later section would # come from here. service_name = com.example.some_multipurpose_activity activity_version = 1 show_launcher = yes mime_types = ...some global types... [Activity someID] # values that are unique for the first sub-activity name = first-subactivity-name icon = clevericon.svg exec = /home/olpc/bin/some-command [Activity anotherIDstring] # values that are unique for the second sub-activity name = second-subactivity-name icon = evenbettericon.svg exec = /home/olpc/bin/some-other-command mime_types = ...some unique types... in addition, the commandline specification for the invoked exec commands could/should be extended with one more standard parameter to the command, which passes the secondary someID/anotherIDstring identifiers: -i activity idstring. that might eliminate the need for per sub-activity exec = lines in some cases. uses for this might be to invoke a single activity in two similar ways (e.g. debug and non-debug modes, during development), or to simply to reduce the overhead involved in creating small utility activities -- in my case i tend to create lots of small shell scripts for myself, all of which could share a bundle. another obvious example would be an ssh activity where each iconic instance on the home screen connected one to a different network host. one more thing to really make this useful would be the ability to pass customization text to the icon being displayed (not sure of the mechanics of this). picture using this to annotate the icons in the ssh activity example: icon-text = host1 and icon-text = host2. like name, this could be subject to localization. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] wireless lights
mikus wrote: What would a concise and accurate definition of the wireless lights (for 8.2) be? To ordinary users, they are 'Meaningless eye candy'. They appear to not be 100% reliable if lit. They certainly are meaningless when blinking. They even appear to not be 100% reliable if not lit. mikus -- i think brian was looking for something that would fit on the picture, as a label. can you be more succinct? ;-) paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity testing on current 8.2 build 759
erik wrote: On Mon, Sep 08, 2008 at 03:18:29AM +0100, Gary C Martin wrote: == Paint-20 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored Note: Very laggy when you try to draw, perhaps 1 to 2 seconds behind mouse movement! Currently quite unusable on XO hardware. I've noticed this on 2263. Perhaps it's a result of mouse driver changes? i don't think so. i tried it a bit with an external mouse -- the performance was similar. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] A few questions.
bert wrote: Am 01.09.2008 um 11:54 schrieb Christopher Sawtell: 3) I am preparing a simplistic little Counting Book for 21st Century Children. So I need to know whether the standard XO file set has a PDF reader as standard? Yes, see http://wiki.laptop.org/go/Read at one time there was a limitation on whether an activity could cause another activity to perform an action (e.g., telling Browse to visit a site, or a file:// url). has that been fixed? (i don't know if this is what christopher needs -- mainly i'm just curious.) paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
eben wrote: ... I hope this clarifies my position on this subject a bit, and paints a it does. thank you. paul picture which is really just a different perspective on the usual trash can metaphor, rather than an abandonment of it. - Eben =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Faster - how do I bypass look, ma - no hands ??
eben wrote: On Mon, Aug 4, 2008 at 2:05 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Tried latest Faster -- is the small 'rodent' supposed to be cute ? ?? i believe mikus is referring to the XFCE, uh, mascot: http://www.xfce.org/images/about/screenshots/4.2-5.jpg =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] current network differentiation?
is it intentional that the currently-connected network is no longer differentiated in the neighborhood view? the outer ring of that network icon used to be white -- it no longer is. it's been pointed out that you can see your current network on the frame, but somehow that's not quite the same (to me). i'm also not sure how to disconnect from that network -- there's no disconnect option in the popup anymore. i'll trac these if they're bugs -- but they might just be misunderstandings on my part. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
eben wrote: On Thu, Jul 31, 2008 at 3:14 PM, [EMAIL PROTECTED] wrote: is it intentional that the currently-connected network is no longer differentiated in the neighborhood view? the outer ring of that network icon used to be white -- it no longer is. This is intentional. The colors of the stroke/fill serve as the visual representation of the identity of the network; changing them effectively strips this identity. The new design does not make any indication of which network is presently associated in the Neighborhood view; perhaps we can find an alternative method. Thoughts? i get the color thing, though those colors are all arbitrary, right? but i guess you can say connect to the green/orange network as a means of identification, and if the ring is white, you can't do that. but it still feels like the connected network should be special in that view. maybe little radio waves emanating from it or something. :-) it's been pointed out that you can see your current network on the frame, but somehow that's not quite the same (to me). Yes, that's the preferred model. The Frame serves as a perpetual status element, and is instantly accessible no matter where you are within the UI. I'm open to improvements on the model. it wasn't until charlie came over and showed me the icon in the frame that i'd had the frame up at all today. but it's certainly a good place to go for status information. i'm also not sure how to disconnect from that network -- there's no disconnect option in the popup anymore. Well, that's a bug, but not really. The problem is that there is no notion of disconnect in network manager at all. The old behavior used to switch into mesh mode, which disassociated with the network itself. However, we now have a more direct means of accomplishing this, via turning the mesh device on or off explicitly. It doesn't make sense to compound i'm not sure what you mean by turning the mesh device on or off explicitly, at least in terms of the current UI. is that the Radio: checkbox in the Network control panel? these. The more conventional option is something like turn wireless off to disassociate with the current network, but that assumes that there is no other potential use for the wireless at all. In our case we still have the mesh to worry about, so that again doesn't map onto our circumstances. i guess i'm thinking of it in traditional terms. if i'm browsing available nets, i might connect to a network by mistake, and want to disconnect without necessarily connecting to something else, and now it feels (rightly or wrongly) like i can't do that. i guess it's not very important, though. paul - Eben =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
marco pesenti gritti wrote: On Thu, Jul 10, 2008 at 8:39 AM, Erik Garrison [EMAIL PROTECTED] wrote: Sugar devs: This is a copy of my bug report for #447. I have completed a first pass of the grab key implementation. Have you considered implementing this at the X level? If so, why did you decide to go for a Sugar specific solution? I have no idea if/how that's possible but I see that the synaptic driver has a TwoFingerScrolling option and I've seen something similar for thinkpads a while ago. for thinkpads? do tell? i'd love to be able to scroll using the eraserhead thing -- along with ALT, maybe. actually, any scrolling accelerator would be welcome. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release Status Report - 8.2.0
c. scott ananian wrote: On Thu, Jun 12, 2008 at 7:40 PM, Chris Ball [EMAIL PROTECTED] wrote: Before we can ship power management, though, we should also fix: * the SD corruption bug (#6532) -- if we can't fix it in time, we can inhibit suspend when an SD card is plugged in. * pushing wakeup decisions to the EC (#6010) -- this will make the wakeup logic more reliable. I'd claim that #6532 is not a *blocker*, it is just a desired feature. I think that we should ship low-power mode in 8.2 even if that means we grey out the option to turn it on when an sd card is mounted. if we can guarantee that we won't corrupt user data, then i agree that it's not a blocker. but if not, i'd say it is. #6010 I'm a little more ambivalent on; I'd need more opinions on whether wakeup is unreliable enough to make an explicit low-power mode unworkable. If it means that sometimes it takes two power button presses to wake up, that's probably not a blocker. If it is so hard to wake up that people regularly think the machine is hung and hard-power-off instead, that's probably a blocker. is there background missing from trac? i don't read anything in #6010 other than we wake up only to go right back to sleep too often, which seems even more benign (leaving power usage aside) than you're describing. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
