Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 10:37 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: My feeling is that metacity will be hard to upstream patches to, and it would be more work to get working 'right', since it's pretty much designed *not* to be extensible. I tend to think metacity upstream might take sane patches to address this use case. (I doubt they would add a UI preference to turn the mode on and off, but we don't need that). The netbook Ubuntu guys are trying to go down that way: jdub njpatel: btw, have you considered adding a maximus mode to metacity? njpatel jdub: yep there are some patches, but the initial idea was not to change from stock hardy too much. Anyway, the performance would be better if the maximising were done in Metacity, so I'm going to try and clean those up and get them accepted when I get some time Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. Please say more. Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. But I'll argue the WM is a relatively minor issue in these respects. What legacy applications and activities are you referring to? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Erik introduced the Journal/datastore to this thread about modifying the approach Sugar has taken to WM in order to better support legacy applications, The Gimp being everyone's favorite example. I am simply suggesting that the WM is--while not the least of our problems--less of an issue than resolving incompatibilities between libraries (The Gimp pulls in all sorts of stuff and Inkscape tries to pull in incompatible libraries, such as an old version of poppler), incompatibilities with where we'd like applications to write data (The Gimp will stomp all over the filesystem), moving data to and from the Journal (how do I open an image I took with Record in The Gimp? or use a picture I edited with The Gimp in Memorize)? The fact that The Gimp uses lots of little auxiliary windows is easily dealt with in, for example, the X Activity. Making this seamless in Sugar seems, IMHO, a relatively low priority relative to these other inconsistencies. -walter On Wed, Sep 24, 2008 at 4:26 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. Please say more. Thanks, Michael -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 4:36 PM, Walter Bender [EMAIL PROTECTED] wrote: of an issue than resolving incompatibilities between libraries (The Gimp pulls in all sorts of stuff and Inkscape tries to pull in incompatible libraries, such as an old version of poppler), No longer the case. incompatibilities with where we'd like applications to write data (The Gimp will stomp all over the filesystem), moving data to and from the Journal (how do I open an image I took with Record in The Gimp? or use a picture I edited with The Gimp in Memorize)? The fact that The Gimp See the thread I've started on resolving these issues. uses lots of little auxiliary windows is easily dealt with in, for example, the X Activity. Making this seamless in Sugar seems, IMHO, a relatively low priority relative to these other inconsistencies. In my opinion, fixing the barriers that prevent developers from dogfooding sugar is of high importance. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Could you please elaborate on what the behavior of the Journal has to do with this thread? -walter On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Well. It's off-topic. I guess it came to mind because the Journal and datastore are a point of incompatibility between Sugar and the rest of the Linux desktop world. Erik On Tue, Sep 23, 2008 at 08:16:25AM -0400, Walter Bender wrote: Could you please elaborate on what the behavior of the Journal has to do with this thread? -walter On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Well. It's off-topic. I guess it came to mind because the Journal and datastore are a point of incompatibility between Sugar and the rest of the Linux desktop world. Erik On Tue, Sep 23, 2008 at 08:16:25AM -0400, Walter Bender wrote: Could you please elaborate on what the behavior of the Journal has to do with this thread? -walter On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
feedback about usage of the journal in uruguay (was Re: [sugar] Supporting desktop applications, extending the EWMH spec)
On Mon, Sep 22, 2008 at 8:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Please Erik, would you mind to share that feedback with the rest of the team? I asked you once already: http://lists.laptop.org/pipermail/devel/2008-September/019123.html I'm devoting now my own free time to improve these issues because no resources have been allocated to the DataStore since almost a year ago (so, since before the first formal release of Sugar). I would be very glad if you decided to help this effort with feedback from the field, sincere and constructive criticism of the design goals, feedback on the implementation design and patches. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
IMO, there is no technical reason why we can't support every X application, no matter how baroque. Window manager technology is as old as X. Given that we can, we *should*. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | (I run SKYPE in Bert's X Activity | without a problem.) The principle goal of this discussion is to make the X Activity unnecessary by moving that functionality into Sugar's window management. Possible motivations for this include: more seamless integration with legacy apps, lower overhead when running legacy apps, easier installation of legacy apps. Personally, I have not used the X Activity, and so I don't actually know what its overheads are, how difficult it is to set up with a new application, or how well it integrates with Sugar (e.g. copy/paste, localization, theming). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjWcE8ACgkQUJT6e6HFtqQ0BgCfU7jUQvLwJ1ZLM3QpM1T8aV3O buIAn2nkv5tIoqYuzsL3KSp+phgwE/1W =qs6X -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
The X Activity is pretty straight forward. But it does not integrate the Sugar copy/paste/theming etc. The point of my question was not so much to question those goals as much as to ask if we have data re what percentage of legacy applications are multiwindow? If it is a small percentage, then maybe we shouldn't be so focused on their support at the expense of the simplicity we are striving for in the whole. Again, as useful as The Gimp is, it is a mess with any WM, so we should be wary of it skewing the rest of the discussion. -walter On Sun, Sep 21, 2008 at 12:03 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | (I run SKYPE in Bert's X Activity | without a problem.) The principle goal of this discussion is to make the X Activity unnecessary by moving that functionality into Sugar's window management. Possible motivations for this include: more seamless integration with legacy apps, lower overhead when running legacy apps, easier installation of legacy apps. Personally, I have not used the X Activity, and so I don't actually know what its overheads are, how difficult it is to set up with a new application, or how well it integrates with Sugar (e.g. copy/paste, localization, theming). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjWcE8ACgkQUJT6e6HFtqQ0BgCfU7jUQvLwJ1ZLM3QpM1T8aV3O buIAn2nkv5tIoqYuzsL3KSp+phgwE/1W =qs6X -END PGP SIGNATURE- -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
The principal goal of this discussion is to make the X Activity unnecessary by moving that functionality into Sugar's window management. what percentage of legacy applications are multiwindow? If it is a small percentage, then maybe we shouldn't be so focused on their support at the expense of the simplicity we are striving for in the whole. I believe there are two separate subjects here. One is: _Given_ multiwindows, what is a good (for the Sugar USER) way to support them while keeping Sugar simple? For myself, if I have the facilities to navigate between multiwindows (e.g., with alt-tab), I'm satisfied. [The role Frame plays with multiwindows *does* need to be worked out - at the least, gray circles should not be left behind.] The other is: Provide an easy-for-applications-to-use framework for adapting how non-Sugar APPLICATIONS can run on that simple Sugar core. This transformation may involve sugarization, or the X activity, or the command line, or whatever. [And not just legacy applications will be multiwindow, but also non-Sugar applications yet-to-be-developed.] Just like effort is being devoted towards enhancing Sugar __development__ where a single platform would be limiting, effort ought to be devoted towards emulating application __execution__ requirements -- where Sugar's existing window design would be limiting. I am not familiar with the X activity, but enhancing it to be the intermediary which converts windowing as requested by many types of non-Sugar applications into windowing as provided by Sugar -- that ought to be easier to do than to individually massage each such application to make it fit Sugar directly. [Put any complexity into the intermediary; keep Sugar simple.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
I am curious: do we have a taxonomy of the various applications we are expecting to see. Has there been a characterization of the problem we are trying to solve? The Gimp, which is a mess in any wm, seems to be the only example of a lots of floating little windows application anyone ever mentions. There is the issue of opening multiple documents in Inkscape, as Scott mentioned, but those really could just as well be handled as separate virtual desktops. What are the other cases? I guess there are programs like SKYPE that fall into the Gimp camp. But I wonder if we have any data? (I run SKYPE in Bert's X Activity without a problem.) I'm not a big gamer: is that where all these problem applications are? -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? I just thought of a worst problem with the FULLSCREEN approach. FULLSCREEN windows are always on the top of NORMAL windows. I think the general issue is that the meaning of FULLSCREEN type on the desktop is very different from our needs, sincethe typical use case is a video player. The type is used to mark windows which must be: 1 Always on the top of everything else. 2 Maximized/undecorated. We would need to drop 1. What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) I'm pretty sure it won't handle them as we would like. Also DESKTOP is used for the home/group/mesh view already. It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. It could be done by extending metacity (upstream) to provide an option to enable a different handling of FULLSCREEN windows. But what is the advantage over defining a new type which is more closely tied to our use case? The one I can think of is that existing toolkits has already a way to create fullscreen windows without using low level API. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | Let's keep thinking about this. For example, I wonder what Metacity does | to a window that is both _NET_WM_STATE_FULLSCREEN and | _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is | _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the | Metacity developers that this is a good idea? | | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT7zMACgkQUJT6e6HFtqRNUgCeIEI1prZOLgGWycAdRcGCefq4 LUgAn0jMC1yiHd2LkOAhZ/iPYwoJHyi6 =IHRK -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 2:00 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? I just thought of a worst problem with the FULLSCREEN approach. FULLSCREEN windows are always on the top of NORMAL windows. I think the general issue is that the meaning of FULLSCREEN type on the desktop is very different from our needs, sincethe typical use case is a video player. The type is used to mark windows which must be: 1 Always on the top of everything else. 2 Maximized/undecorated. We would need to drop 1. What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) I'm pretty sure it won't handle them as we would like. Also DESKTOP is used for the home/group/mesh view already. It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. It could be done by extending metacity (upstream) to provide an option to enable a different handling of FULLSCREEN windows. But what is the advantage over defining a new type which is more closely tied to our use case? The one I can think of is that existing toolkits has already a way to create fullscreen windows without using low level API. Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? bobby Marco ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:30 PM, Bobby Powers [EMAIL PROTECTED] wrote: Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? They are common to all standard compliant window manager. To be honest I haven't even looked into the metacity implementation in detail yet. I'm trying to figure out something that make sense on the base of the EWMH specification. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:55 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:30 PM, Bobby Powers [EMAIL PROTECTED] wrote: Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? They are common to all standard compliant window manager. To be honest I haven't even looked into the metacity implementation in detail yet. I'm trying to figure out something that make sense on the base of the EWMH specification. Btw the main reason we are considering metacity is that it uses several of the libraries used for the Sugar UI (gobject, gtk, gconf etc). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:28 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? Oh, I had missed the focused bit of this parth of EWMH: focused windows having state _NET_WM_STATE_FULLSCREEN I'm more convinced about this approach after having played with it in GNOME (with fullscreen applications like terminal, totem and epiphany). As far as I can tell so far the only issue is to keep the frame always on top, but there are ways to deal with that. Sayamindu, what do you think? Should we experiment with this approach? Give it a try in GNOME... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Thu, Sep 18, 2008 at 4:07 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Marco and I have been discussing on how to make a window manager like Metacity fit into the Sugar environment, and based on our current discussions, as well as past discussions, it seems clear that we need changes to the Extended Window Manager Hints spec[1]. For details on I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Ideally, the sugar home view would run on root, like in nautilus. On the XO, we are using a special tiling window manager. You can use a window manager like XMonad on your non-XO if you want that style of window management. That's a window manager property, sugar activities should have nothing to do with it. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Some of the links at the top of http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to window managers we could run on the XO to provide better support of the 'each activity has a full screen' window management mode. Further, they offer better support of 'floating layers', so that an application like the gimp can have a 'full screen' layer all to itself *in which* it can have several different (decorated) windows. Something like having a dedicated virtual desktop per activity. I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. Playing around with the gimp in XMonad may be instructive. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are talking about replacing Matchbox with Metacity in the XO build of Sugar. C. Scott Ananian wrote: | When I run | sugar under metacity, I don't *want* my activities to be full screen. I think you mean When I run Sugar inside a standard desktop environment on a computer with a large monitor... | Some of the links at the top of | http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to | window managers we could run on the XO to provide better support of | the 'each activity has a full screen' window management mode. That is the role for which we are discussing Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT/m4ACgkQUJT6e6HFtqQ2dQCgmcNRf5982XIG3oIMEXaB4pG4 IrEAn3XbUFrVPOuMy0cJ13U7V6l2xvd5 =JLrm -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 9:26 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Yeah, ideally it should work like that. That's the main point I was trying to make about both Sayamindu and Benjamin proposal. Ideally, the sugar home view would run on root, like in nautilus. This should already work fine. I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. That's what the PRIMARY/APPLICATION was meant to be in my proposal... I'm not sure the existing hints are adeguate, but if there are window managers which manage to deal with the gimp correctly, then I guess there are at least ways to make reasonable guesses. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 3:33 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are talking about replacing Matchbox with Metacity in the XO build of Sugar. Right, I think that's where you're going wrong. You should be considering replacing Matchbox with a better window manager. Metacity is the wrong one. | When I run | sugar under metacity, I don't *want* my activities to be full screen. I think you mean When I run Sugar inside a standard desktop environment on a computer with a large monitor... No, I mean what I said. Who says 1200x900 is small? | Some of the links at the top of | http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to | window managers we could run on the XO to provide better support of | the 'each activity has a full screen' window management mode. That is the role for which we are discussing Metacity. again, that's probably not the right window manager to be looking at. Metacity is not designed to do this, and the maintainer does not like to add cruft to it. It is the poster child of the *non*extensible, *do things only one way* window manager. Not the right one for this. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 3:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. That's what the PRIMARY/APPLICATION was meant to be in my proposal... I'm not sure the existing hints are adeguate, but if there are window managers which manage to deal with the gimp correctly, then I guess there are at least ways to make reasonable guesses. Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. I see you mention three window managers on your page (including metacity). It would nice to see a quick analysis of their strengths/weaknesses for our use case... If we go with this approach, Sugar itself is likely to require small or no changes and I can just let you and Sayamindu deal with all of it :) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 12:49 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:28 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? Oh, I had missed the focused bit of this parth of EWMH: focused windows having state _NET_WM_STATE_FULLSCREEN I'm more convinced about this approach after having played with it in GNOME (with fullscreen applications like terminal, totem and epiphany). As far as I can tell so far the only issue is to keep the frame always on top, but there are ways to deal with that. Sayamindu, what do you think? Should we experiment with this approach? Give it a try in GNOME... I took a look, and it does seem promising. However, in this case, we need to figure out how to circumvent our existing fullscreen code. For the frame, setting it to have _NET_WM_STATE_ABOVE might help. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 12:56 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 4:07 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Marco and I have been discussing on how to make a window manager like Metacity fit into the Sugar environment, and based on our current discussions, as well as past discussions, it seems clear that we need changes to the Extended Window Manager Hints spec[1]. For details on I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Ideally, the sugar home view would run on root, like in nautilus. Metacity was provided just as an example. The issue here is that we want to replace Matchbox with something which would let us support normal desktop applications better, ideally without requiring any kind of modification to the applications themselves. (better support, for instance means, not messing up The Gimp) On the XO, we are using a special tiling window manager. You can use a window manager like XMonad on your non-XO if you want that style of window management. That's a window manager property, sugar activities should have nothing to do with it. Agreed. But are sugar activities (or rather, should sugar applications be) the same as normal desktop applications from a window manager peerspective. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Yes, that is why I'm still somewhat opposed to running all our activities with the FULLSCREEN hint permanently on - IMO, we need to differentiate between the two modes of an application or an activity, and the window manager needs to know about that. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:13 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 3:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. That's what the PRIMARY/APPLICATION was meant to be in my proposal... I'm not sure the existing hints are adeguate, but if there are window managers which manage to deal with the gimp correctly, then I guess there are at least ways to make reasonable guesses. Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) GIMP is stretchable. It looks ugly when it is stretched too much, but you can stretch it or even maximize it if you want. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:26 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. I see you mention three window managers on your page (including metacity). It would nice to see a quick analysis of their strengths/weaknesses for our use case... Just a note that Xmonad seems to pull in 35 MBs of RPMs as dependencies. I'm not sure whether that is good for our storage space. Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 4:50 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Metacity was provided just as an example. The issue here is that we want to replace Matchbox with something which would let us support normal desktop applications better, ideally without requiring any kind of modification to the applications themselves. (better support, for instance means, not messing up The Gimp) +1 Agreed. But are sugar activities (or rather, should sugar applications be) the same as normal desktop applications from a window manager peerspective. Yes, for the most part. Inkscape or gnumeric running with one window open should look the same as a sugar activity. Things only start getting interesting when I open two documents simultaneously in inkscape. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Yes, that is why I'm still somewhat opposed to running all our activities with the FULLSCREEN hint permanently on - IMO, we need to differentiate between the two modes of an application or an activity, and the window manager needs to know about that. +1 GIMP is stretchable. It looks ugly when it is stretched too much, but you can stretch it or even maximize it if you want. wow, i never realized this. You're right. I was just trying to illustrate that the layout strategy doesn't have to be very complicated for most applications. Gimp does set reasonable window hints, and simply falling back to floating mode with window decorations when multiple non-dialog windows are mapped is a good first-draft wm policy. Just a note that Xmonad seems to pull in 35 MBs of RPMs as dependencies. I'm not sure whether that is good for our storage space. Wow. I think part of the reason is that Xmonad supports recompiling itself on the fly to allow you to dynamically edit the wm configuration, and so pulls in the entire Haskell compiler and all its libraries. I'm willing to bet that a static configuration could be made much smaller -- but that's clearly one of the issues that should be relevant in the final choice for wm. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Lots of discussion -- but I'm not sure how much benefit the Sugar *user* might receive. I think that everybody agrees (myself included) that the user must be able to call up the Frame anytime. And for typical Activities, the amount of screen real estate they *themselves* obstruct (which the Frame itself doesn't already obstruct) is small. Looks like a general mechanism to free up screen real estate ends up freeing mainly areas that get overlain anyway whenever Frame is called. To me, supporting multiple windows for one Activity is a much more pressing need than supporting full screen for every Activity. In the current Sugar implementation, alt-tab appears to provide an adequate way to navigate among such windows (i.e., screens) - but more discussion is needed about the role of Frame in this situation. I see nothing wrong with what some Activities already implement - by default they run with some areas obstructed by decorations -- but at the option of the user a short-cut removes those decorations. [Now if the discussion were about how to best implement such a facility - go to it. But it seems to me the discussion is leaning too far towards a let's free the Activity's limits crusade.] I think that to a user, gray circles left in Frame are of more immediate concern than shortcomings of using Matchbox with Sugar. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 4:59 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Lots of discussion -- but I'm not sure how much benefit the Sugar *user* might receive. Some users will want to use gimp. Some will want to use metacity. To me, supporting multiple windows for one Activity is a much more pressing need than supporting full screen for every Activity. In the current Sugar implementation, alt-tab appears to provide an adequate way to navigate among such windows (i.e., screens) - but more discussion is needed about the role of Frame in this situation. I envision having one screen with multiple windows. Basically, each activity gets its own virtual desktop. You can either have these windows decorated or not, depending on whether you prefer tiled or overlapping window managers. I think that to a user, gray circles left in Frame are of more immediate concern than shortcomings of using Matchbox with Sugar. That would be my 'we should use the standard X startup notification mechanism' rant. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 10:37 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The main changes required, I think, would actually be to the shell code to make it happy running on a root window. There's some reparenting magic that's done to make that work right; I'm not sure what you mean exactly here... The home/mesh/groups view are all inside a single DESKTOP window, which is the same as the nautilus desktop afaik. All the other windows will be stacked on the top of it. I was pointed to the xpenguins source for information on what that involves, I don't think it's a lot that needs to be done. We might have to tweak the frame implementation so that it speaks the same standard wm-communication language as the window selectors in the gnome panel, if it doesn't already; haven't looked at that. It's not because matchbox doesn't like it. Trivial to change. And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Something else which I think is necessary is to support the standard icon property. Should not be very difficult. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:10 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 7:16 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 1:10 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. I read the spec, it seemed sane. Proof will be in the implementation, though, of course. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:26 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. I read the spec, it seemed sane. Proof will be in the implementation, though, of course. Yeah... Regarding implementation, gtk 2.14 added API to handle the launcher part: http://library.gnome.org/devel/gdk/stable/gdk-Application-launching.html Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Thu, Sep 18, 2008 at 10:07 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: a) applications like firefox will need to be modified so that they set the _NET_WM_WINDOW_TYPE_APPLICATION hint (ideally we would like to run the applications unmodified). The idea would be that applications would just these this hint upstream, if they are designed in a way that makes them compatible with running fullscreen. b) one of the major reasons why we can do away with the decorations in case of sugar activities is that they are designed to work well without decorations (eg: a large close button on the window itself). otoh, most desktop applications do not have this, and the close button is usually somewhere hidden in the menu. In some cases the close button may not be accessible at all (eg: a rogue popup in firefox which somehow circumvents the popup blocker and disables the menubar). Note that this is a problem with the existing Firefox activity as well. We might actually move the close button into the frame in one of the next release... (Don't take this as arguing for the approach _NET_WM_WINDOW_TYPE_APPLICATION, it's tricky, I'm not sure what's better really.) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Sayamindu Dasgupta wrote: The simplest way to do this is mentioned in the draft, namely, to have a new _NET_WM_WINDOW_TYPE hint, called _NET_WM_WINDOW_TYPE_NETBOOK_APP (feel free to suggest a better name :-P). I do not understand at all why _NET_WM_WINDOW_TYPE_FULLSCREEN is insufficient. For example, try (under Metacity) launching Firefox and then pressing F11 to go into Fullscreen mode. This results in a full-screen, undecorated window that seems to behave exactly as we desire full-screen Sugar apps to behave. Here is a quick experiment I did to compare Firefox when Maximized and Fullscreen. $ xprop /tmp/full.txt $ xprop /tmp/max.txt $ diff -u /tmp/max.txt /tmp/full.txt --- /tmp/max.txt2008-09-18 16:38:49.0 -0400 +++ /tmp/full.txt 2008-09-18 16:38:33.0 -0400 @@ -3,10 +3,10 @@ WM_STATE(WM_STATE): window state: Normal icon window: 0x0 -_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 25, 1 +_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0 _NET_WM_DESKTOP(CARDINAL) = 0 -_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW -_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT +_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW +_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | ... _NET_WM_WINDOW_TYPE_FULLSCREEN ... That should be _NET_WM_STATE_FULLSCREEN. Oops, Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSvfMACgkQUJT6e6HFtqRgwQCfaOj++xeB6DNjk3raFu+ZIicp g/oAoImzaINzdSSsaVNtsTyQd1LQc6Yy =p/Mn -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 2:12 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Sayamindu Dasgupta wrote: The simplest way to do this is mentioned in the draft, namely, to have a new _NET_WM_WINDOW_TYPE hint, called _NET_WM_WINDOW_TYPE_NETBOOK_APP (feel free to suggest a better name :-P). I do not understand at all why _NET_WM_WINDOW_TYPE_FULLSCREEN is insufficient. For example, try (under Metacity) launching Firefox and then pressing F11 to go into Fullscreen mode. This results in a full-screen, undecorated window that seems to behave exactly as we desire full-screen Sugar apps to behave. Here is a quick experiment I did to compare Firefox when Maximized and Fullscreen. $ xprop /tmp/full.txt $ xprop /tmp/max.txt $ diff -u /tmp/max.txt /tmp/full.txt --- /tmp/max.txt2008-09-18 16:38:49.0 -0400 +++ /tmp/full.txt 2008-09-18 16:38:33.0 -0400 @@ -3,10 +3,10 @@ WM_STATE(WM_STATE): window state: Normal icon window: 0x0 -_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 25, 1 +_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0 _NET_WM_DESKTOP(CARDINAL) = 0 -_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW -_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT +_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW +_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. Some of our activities have a separate fullscreen mode. Take a look at the two screenshots of record: Fullscreen: http://dev.laptop.org/~sayamindu/sugar_metacity/Captura%20de%20pantalla_1.png Normal: http://dev.laptop.org/~sayamindu/sugar_metacity/Captura%20de%20pantalla_1_2.png Marco suggest that this can be worked around in sugar though. However, though we do not always show frames (or panels), there are some environments which show at least a single panel all the time (eg: Ubuntu Netbook Remix). In those cases, fullscreen might mean that frame may have to be covered as well. Who knows, maybe in the future sugar may also decide to show a single frame permanently on the screen. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Thu, Sep 18, 2008 at 11:02 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Some of our activities have a separate fullscreen mode. Take a look at the two screenshots of record: Fullscreen: http://dev.laptop.org/~sayamindu/sugar_metacity/Captura%20de%20pantalla_1.png Normal: http://dev.laptop.org/~sayamindu/sugar_metacity/Captura%20de%20pantalla_1_2.png Marco suggest that this can be worked around in sugar though. Yeah this could be handled differently in Sugar. However, though we do not always show frames (or panels), there are some environments which show at least a single panel all the time (eg: Ubuntu Netbook Remix). In those cases, fullscreen might mean that frame may have to be covered as well. Who knows, maybe in the future sugar may also decide to show a single frame permanently on the screen. I'm not even sure why it works with the current frame... The wm is supposed fullscreen windows on the top of docks: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER Another point is that Sugar activities would have to be modified to run correctly on a normal desktop (or we would have to come up with some logic to set the fullscreen hint conditionally). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | However, though we do not always show frames (or panels), there are | some environments which show at least a single panel all the time (eg: | Ubuntu Netbook Remix). In those cases, fullscreen might mean that | frame may have to be covered as well. Who knows, maybe in the future | sugar may also decide to show a single frame permanently on the | screen. This is an interesting problem, but it is not relevant for Sugar at this time. I think a discussion with the Ubuntu developers would be wonderful, but since we do not have such a semi-permanent bar in Sugar, we can implement all our desired behaviors using simply the existing EWMH. | | I'm not even sure why it works with the current frame... The wm is | supposed fullscreen windows on the top of docks: | | http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER For usability/security reasons, the Frame must always be on top, regardless of what hints an Activity sets on its windows, so we cannot follow this recommended stacking order. The window manager will have to enforce the ordering, eventually in conjunction with a real X security framework. | Another point is that Sugar activities would have to be modified to | run correctly on a normal desktop (or we would have to come up with | some logic to set the fullscreen hint conditionally). Running Sugar Activities in a standard desktop environment is something that we have not discussed enough. It's important to remember that Activities (e.g. Write) require Sugar's UI to load files, save files, join shared instances, monitor current sharing partners, etc. Activities will never run on a bare desktop; they will always require a launcher shell, even if it is much less comprehensive than a full Sugar shell. This shell can also be responsible for setting window hints appropriately, or for providing Activities with enough information about the environment for them to set appropriate window hints. In summary, I believe we can safely move to a lightly patched Metacity while tagging our windows purely according to the EWMH. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSyWYACgkQUJT6e6HFtqQSfgCfWR0riur6iMJiqxSkRmkY+mu8 3MAAn1iM/D2RX+aivuljZPLyqvFM8ytd =i782 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Thu, Sep 18, 2008 at 11:34 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: In summary, I believe we can safely move to a lightly patched Metacity while tagging our windows purely according to the EWMH. That would mean to make Sugar impossible to use on a standard distribution. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Thu, Sep 18, 2008 at 11:34 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | In summary, I believe we can safely move to a lightly patched Metacity | while tagging our windows purely according to the EWMH. | | That would mean to make Sugar impossible to use on a standard distribution. You mean because it would make Sugar depend on a nonstandard branch of Metacity? I can understand why distributions might be reluctant to carry such a thing. Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) EWMH specifies a _NET_RESTACK_WINDOW message. Could Sugar, acting as a pager, send this message to Metacity at appropriate times to raise the Frame to the top, above FULLSCREEN windows? It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjS0nwACgkQUJT6e6HFtqT9CQCgoNuyrq73SGUwzfvW/E2JHWhN 8sAAn1YDg6ro9fCc3W2E3OiyUXZ8rnYk =/BHQ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Thu, Sep 18, 2008 at 11:34 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | In summary, I believe we can safely move to a lightly patched Metacity | while tagging our windows purely according to the EWMH. | | That would mean to make Sugar impossible to use on a standard distribution. You mean because it would make Sugar depend on a nonstandard branch of Metacity? I can understand why distributions might be reluctant to carry such a thing. Yup. I will look into your proposal/discussion tomorrow. My brain is pretty much dead at the moment :) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
