Re: [sugar] multiple gtk.Windows hide() and show()
Thanks for replying Dan, much appreciated. Let me explain what I am trying to achieve: I am creating a picture in a picture effect (using XV in a window, amongst other windows). GTK doesn't play well with overlapping widgets, and gtk.Fixed() doesn't guarantee Z-order. So I am using a stack of gtk.Windows without decoration to achieve the desired effect, but the appearance is that everything looks like a nice gtk layout. On 8/27/07, Dan Winship [EMAIL PROTECTED] wrote: Erik Blankinship wrote: A UI I am working on has multiple gtk.Windows, which I would like to hide when they are resizing (to avoid screen flashes). The multiple gtk.Windows are set_transient() for each other, allowing me to stack them, and when I hide() and show(), the flicker is indeed gone! transient_for doesn't mean stack this window above this other window. It means (quoting from the ICCCM) this window is a pop-up on behalf of the named window. Swapping two windows around so that sometimes one of them is transient for the other and other times vice versa makes no sense by this definition, so there's no telling what the WM will do if you do that. I don't care about recalling set_transient, I just want windows to show up consistently in the expected order. I am not changing what is set_transient for what, just trying to get windows to show up again by recalling that method. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] multiple gtk.Windows hide() and show()
Erik Blankinship wrote: Let me explain what I am trying to achieve: I am creating a picture in a picture effect (using XV in a window, amongst other windows). GTK doesn't play well with overlapping widgets, and gtk.Fixed() doesn't guarantee Z-order. So I am using a stack of gtk.Windows without decoration to achieve the desired effect, but the appearance is that everything looks like a nice gtk layout. Sorry, got confused by your description; I thought you were trying to change stacking on the fly by swapping transient-fors around. But anyway, you still have the problem that transient for doesn't actually mean anything having to do with stacking. (In fact, the ICCCM lists a bunch of things a window manager might do differently with transient windows, but stacking order isn't one of them.) So (1) setting transient-for on a window won't necessarily affect its stacking, and (2) it may affect it in ways other than stacking. (Eg, matchbox appears to assume that any window that has WM_TRANSIENT_FOR set is a dialog box.) So your best bet is probably to make your own version of gtk.Fixed that does have a guaranteed Z-order, rather than trying to bend the wm to your will. Marco says I seem to remember blizzard wrote something like that for mozilla gtk2. You *might* also be able to get gtk.Fixed to work just by calling raise()/lower() on the child widgets' GdkWindows to stack them the way you want within the Fixed. (Or just by being sure to show() them in bottom-to-top order.) -- Dan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sharing data between activities.
Installing a bunch of example images with the activity bundle sounds like a really bad idea to me, given our space limitation (independently from the fact that you want them share between multiple activities). Why don't we just make these available separately, as a content bundle (.xol)? That way kids can install and uninstall these when they want through the journal. Well, this seems to ignore the major intention of delivering initial content on the system - getting the kids to learn by example. How should they know they have to install something before they can start learning? I think one difference here is the predominance of the format in question. Images, video, audio, and other primitive types of media will not be in short supply, and in fact the kids will be producing these in great quantity themselves. As such, there is no shortage of images that might be dropped on one of these puzzles. Tutorials and examples, on the other hand, provide us with an unknown format for an activity that may or may not be readily discoverable without them in the first place. This is a different concern, and we definitely need to support this as well. Clicking an icon and getting an empty document was one of the major problems Etoys had before the OLPC version. The current initial Etoys project (our launch screen with the 5 cloud buttons) at least presents a couple of choices, and links to other projects that demonstrate various parts of the system. How would that be done if the examples have to be installed first? Even leaving aside the problem of security concerns forbidding direct linking to objects in the journal, how *do* we provide a seamless introduction? Well, we've talked about this a lot, and the proposal on the table at the moment is to allow instantiating new objects/documents/projects with examples. That is, when opening a new Etoys project, the user may have the option to select an empty project or any from a list of examples. This option should only appear once, upon instantiation, at which point the selected project becomes the object represented by the activity instance; more examples could be launched by creating new instances. The best way to understand this is to consider each running instance as an object itself, ignoring the notion of applications which open a bunch of separate files, perhaps even at the same time. Allowing any form of open functionality that isn't an import function (such as importing an image into the current write document) actually swaps the object represented by the running instance, which we want to avoid. By making this a parameter of the creation of the instance, this dilemma goes away. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Repos branched for trial-3
There are now two branches for the fedora repos, dist-olpc2 and dist-olpc2-trial3. Everyone still build in olpc2 but must request packages to be moved into olpc2-trial3 in order to get it into the build. Please file a bug with the name of the package, version and release along with a detailed changelog. Only bugfixes can get in as feature freeze was today. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] forcing new name and colors
On 8/27/07, Walter Bender [EMAIL PROTECTED] wrote: I cannot recall how to force Sugar to prompt for the name and colors at startup as if from a clean build. I need to do this for Build 542. Delete the /home/olpc/.sugar/config file (where the name and colors are stored) along with the SSH keys in the same directory. Thanks to CJB for the second half of that. : -- Michael Burns * Intern One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] forcing new name and colors
thanks. it was the latter step (SSH keys) that I had forgotten. -walter On 8/27/07, Michael Burns [EMAIL PROTECTED] wrote: On 8/27/07, Walter Bender [EMAIL PROTECTED] wrote: I cannot recall how to force Sugar to prompt for the name and colors at startup as if from a clean build. I need to do this for Build 542. Delete the /home/olpc/.sugar/config file (where the name and colors are stored) along with the SSH keys in the same directory. Thanks to CJB for the second half of that. : -- Michael Burns * Intern One Laptop Per Child -- Walter Bender One Laptop per Child http://laptop.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
