Re: Location-aware GNOME Shell: weekly report 8 9
On 07/26/2011 10:37 AM, Stéphane Maniaci wrote: Week 9 I dived into the Shell code, to actually get locations from the GSettings key, but for some reasons, `jhbuild run gnome-shell` doesn't seem to use the gsettings-desktop-schema of JHBuild Are you building from the gnome-shell jhbuild moduleset (as opposed to the main jhbuild moduleset)? The gnome-shell moduleset passes --enable-jhbuild-wrapper-script to autogen.sh, which adds a wrapper around the gnome-shell binary to deal with various paths-to-things like gsettings schemas, but the non-gnome-shell moduleset doesn't, and so will probably have problems like this. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Gnome bugs for 3.0.2 Push
On 05/24/2011 01:45 AM, Jesper Andersen wrote: MUTTER Definitely Want to Have: How about this one: https://bugzilla.gnome.org/show_bug.cgi?id=597190 Window switcher and focus follows mouse It certainly would be useful to me. That patch hasn't even been committed yet, and so has gotten no serious testing, and so is not a candidate for 3.0.2. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME Shell 3.0.1 schedule
On 04/05/2011 02:44 PM, Owen Taylor wrote: So I want to hold off on branching 3.0 until we're pretty much happy with 3.0.1. Yeah, makes sense. Selection of possible 3.0.1 candidate patches I'll also suggest: Bug 646708 - network: fix two warnings when removing a network device https://bugzilla.gnome.org/show_bug.cgi?id=646708 (trivial, cleans up two warnings and a leak) Bug 646451 - lookingGlass: bring back the inspector icon https://bugzilla.gnome.org/show_bug.cgi?id=646451 (trivial, only affects lg, so no danger in pushing it) Bug 646108 - Cursor setting is broken https://bugzilla.gnome.org/show_bug.cgi?id=646108 Bug 646761 - Mutter should not apply the special modal decoration if the parent window is the desktop https://bugzilla.gnome.org/show_bug.cgi?id=646761 Bug 646205 - assignment to undeclared variable format in telepathyClient.js https://bugzilla.gnome.org/show_bug.cgi?id=646205 (uber-trivial, obviously correct) Bug 646395 - WWAN section behaves strangely https://bugzilla.gnome.org/show_bug.cgi?id=646395 (multiple fixes, at least one obviously correct and highly visible) Bug 646246 - dbus: Add connect_sync() method to bus objects https://bugzilla.gnome.org/show_bug.cgi?id=646246 -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: more NM patches
On 03/25/2011 02:31 PM, Giovanni Campagna wrote: 0001: Isn't this calling _reposition for every frame? Every call to _reposition queues a relayout, which in turns result in _allocate, and then to queue a _reposition. No, because if nothing changed, then _reposition will set actor.x and actor.y to the same values they already had, and ClutterActor will just optimize that out and not queue another relayout. 0003: The fix is consistent with current background-image support, and good as a bandaid, until background-position / background-size / background-repeat are supported. But I'm not sure it does fix any of the sizing bug, given that the font size does not change Ah... I hadn't noticed that it was correct under the default font scaling. But anyway, the font size does change if you do Accessibility - Large Text. At Large it's a little bit off. At Larger (which you have to go to the a11y control panel for), it's quite broken. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: NetworkMenu patches (part one)
+GObject.prototype.disconnect.call(this.device, this._carrierChangedId); should be GObject.Object.prototype... (in two places) Otherwise looks fine and seems to work. Note that this is both a code freeze break and a string freeze break. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gjs fails in gnome3 moduleset but doesn't in gnome-shell moduleset
On 03/04/2011 07:45 AM, Marcel wrote: What puzzles me is that its building in the gnome-shell moduleset which is supposed to be the same as in gnome3 according to andre (#gnome3). The gnome3 moduleset builds its own mozilla, while the gnome-shell moduleset uses the system package. Try uninstalling mozilla (make uninstall from the mozilla source tree in your gnome jhbuild checkout directory, although it's possible that that won't work completely, and you'll end up needing to just nuke your jhbuild install directory and start over) and then add to your (gnome) .jhbuildrc: skip = ['mozilla'] -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Clicking on the text of some notifications does nothing
On 01/23/2011 09:48 PM, Jasper St. Pierre wrote: This is a bug with the legacy XEmbed notification icons. I believe Dan Winship was working on something to fix this. https://bugzilla.gnome.org/show_bug.cgi?id=630842 I'm not actively working on it, just sort of occasionally poking at it when it annoys me. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Some issues calling atk methods
On 08/16/2010 07:53 AM, Piñeiro wrote: BTW: you still thinks that this is a problem with ATK, in the sense of a bad name-policy? Yes. Most languages/bindings other than C are going to run into that same problem with one of the two get_name() methods shadowing the other. It would be good to deprecate one of them and rename it to something else. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Bring some KDE / Ubuntu to the System Status Area?
On 06/23/2010 07:41 PM, Giovanni Campagna wrote: After all discussion raised on bug 622451 (the experimental power manager applet). I was thinking if it was appropriate for the shell to implement KDE's and Ubuntu's (Ayatana) protocols for system tray / system status. We like Ubuntu's changes to the KDE protocol, but the KDE protocol itself seemed like a complete lose. And you can't really rebase the Ubuntu stuff on top of the old tray protocol, so... And at any rate, the Ubuntu protocol isn't nearly extensive enough to cover everything in the system status mockups. (It's hard to imagine a protocol that would be, unless it was completely customized to that set of mockups.) -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Bring some KDE / Ubuntu to the System Status Area?
On 06/24/2010 11:04 AM, Giovanni Campagna wrote: Again, I could not find decent documentation, but isn't the protocol able to transfer any GtkMenuItem? No, it scans the menu and constructs an XML serialization of it, sends that over D-Bus, and then the other end converts the XML back into a GtkMenu. The serialization format only supports specific things. Or reversing the question, if the protocol is not enough, how come that Ubuntu is shipping gnome-bluetooth and gnome-power-manager using dbusmenu for transport, and they look pretty like Gtk-based ones? There's nothing unusual in the bluetooth or power-manager applet menus though. The protocol was *designed* to handle simple menus like those. It's stuff like NM-applet and the volume control that make things complicated. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gnome-shell application intergration
On 06/16/2010 11:36 AM, kaddy...@gmail.com wrote: I cannot do what with rhythmbox? use the bottom notifications to skip songs? Yes you can... I was doing it yesterday with the latest gnome-shell packages Oh. well that's neither gnome-shell-specific nor rhythmbox-specific then. Rhythmbox is just using the standard libnotify mechanism for specifying action buttons in the notification. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: JSLint and JavaScript: The Good Parts.
On 03/12/2010 07:04 AM, Lex Hider wrote: I ran the attached perl script to get around errors reported for: let, const, and multiple variable assignment (e.g. [a,b] = callFunc();), which appear to be mozilla specific features. yeah, there's a bug in bugzilla (against gjs) about trying to get jslint working with the moz extensions Would a patch for any of the following be worthwhile? * missing terminal semi-colons. yes * if statement's with single statement but no braces. no, our style allows that (although if there are places where one branch has braces and the other doesn't, you can fix that). * unused variables. yes * changing use of == and != to === and !== . if (foo != null) // should be: if (foo !== null) Crockford is strong on this, referring to == and != as the evil twins to ===/!== . Changing them blindly would break some things. (Eg, I know there are places where people have taken advantage of the fact that 0 != null but undefined == null; changing != to !== would make both 0 and undefined compare as not equal.) You could argue that doing that is bad style and should be written differently. But at any rate, this isn't something you can change without examining the code carefully. //changing this if (fee fi foe fum) //to if (fee fi foe fum) So, I prefer the latter style anyway, but this is a bad example since it wouldn't be valid for the interpreter to put a semicolon in there anyway... -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Some thoughts about Gnome Shell (Keyboard Navigation; more self-explanatory UI; UI obstacles)
On 01/28/2010 03:04 PM, Friedrich Gräter wrote: 5. The sidebar for various reasons: - It is hidden per default, which is bad for newcomers It is currently hidden by default because we're not happy with the current state of it. Perhaps we should hide the option for re-enabling it as well. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions interacting with windows
On 01/25/2010 09:10 PM, Grizzly(Francis Smit) wrote: so are you saying there is a notification area in gnome-shell because the icons don't show there Yes, there's a notification area, at the right side of the panel, next to the user menu. If you run gnome-shell --replace, then some tray icons will not successfully make the transition from the old panel to the gnome-shell panel, because they use a buggy old version of the tray icon code. But restarting the apps in question should make them reappear. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Extensions interacting with windows
On 01/25/2010 02:20 AM, Jon Nettleton wrote: The windows are easily accessible by code under global.window_group. We can add actors to that group and they show up behind windows as they should, temporarily. Within the compositor there is code that syncs the stack of actors with the stack of windows. It is never taken into account that there may be non-window actors within the group, which in turn ends up with all window actors always stacked below non-window actors. There was a little bit of discussion of this in the context of fixing the bugs involving the stacking of the panel relative to other windows. (Eg, https://bugzilla.gnome.org/show_bug.cgi?id=582653, notification area tooltips appear under shell panel.) One problem that comes up in the general case, but not in your lightboxing case, is being able to receive events on the non-MutterWindow actors in window_group. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Telepathy integration plans
On 01/13/2010 07:31 AM, Guillaume Desmottes wrote: Plans regarding Telepathy integrations have recently changed [1]. I'm not sure this is the best approach but, before stating my opinion I'd have few questions: Hey. I did poke a few Collabora people on IRC after filing that bug to make sure it wasn't totally insane. :) - According my understanding of the bug, your plan is to not use the Telepathy API directly but rely on Empathy to push notifications to gnome-shell through the notification API. Is that correct? Right. Given that we planned to depend on empathy for some stuff still anyway (account setup, contact list, the full-featured chat windows, etc), and given that empathy already does all those notifications, it was starting to seem silly to reimplement them all ourselves as well (especially since then we'd have to figure out some way to suppress the duplicate notifications coming from empathy anyway). - What are your requirements regarding IM integration into gnome-shell? Last time I checked the plan was implement something like this mokcup: http://www.gnome.org/~mccann/shell/mockups/20090630-demo/ Is that still accurate? Do you have more documents explaining the user-experience you want to reach regarding IM integration? The latest PDF design doc has more detail than that demo (http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf). This is still a work in progress though, and we haven't figured out exactly how this will work with empathy either. (We're assuming empathy will need some changes to fully support what we want it to do.) The general idea in my head right now though is that we'll add some extensions to the org.freedesktop.Notifications protocol (or add another D-Bus interface alongside it) that would allow empathy to know when it was running under GNOME Shell (eg via notify_get_server_caps()) and then empathy could use notification hints (notify_notification_set_hint_uint32(), etc) to do things like indicate to the shell that it can provide a pop-up mini chat window upon request, and empathy would be the one creating that window seen in the PDF. (Rhythmbox would use the same interface to provide the mini controls/now-playing window seen in the demo.) Again, not totally sure about the specifics, but it definitely makes sense to have empathy providing that window, not GNOME Shell, so that it has access to the existing chat log, and so that it matches your other empathy prefs in terms of things like spell check language, etc, and so it can integrate cleanly with whatever new features you add to empathy in the future. - Do you still plan to implement an Approver [2] in gnome-shell (bug #599193)? We haven't yet figured out the UI for stuff where you have to explicitly accept or reject a request. It's possible we'll want to use an Approver there. (There may be other places where it makes sense for us to use Telepathy as well; we aren't totally rejecting it, just getting rid of the redundancy where Telepathy wasn't really gaining us anything.) -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Recent systray work
On 12/16/2009 11:28 PM, Fabio Berta wrote: Hi Any plans to integrate with this recent work being done on the systray? http://gould.cx/ted/blog/Having_a_tidy_systray What he describes is probably necessary if we want to fix https://bugzilla.gnome.org/show_bug.cgi?id=584651. Although it seems like it would be very hard to make the NetworkManager menu have all the functionality it currently does in such a system. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Clutter vs GTK+
On 11/15/2009 01:46 PM, hills wrote: I wonder when you decide to use Clutter instead of GTK+ for application widgets. Is there a clear guideline for this? For example why user menu seems to be GTK+, but date/calendar applet is Clutter implemented? in general, the shell's own UI is supposed to be entirely clutter-based. The user menu is written in GTK because it was ported from the existing user switch applet menu. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Couple of Suggestions
On 10/19/2009 06:46 AM, Gustavo Noronha Silva wrote: On Sat, 2009-10-17 at 09:29 +1100, William Madden wrote: to the window I want. It would be better if alt-tilde on its own brought up the display and started changing windows of the current app. I don't know what alt-tilde is used for, but it's an awful combination for people who use keyboard layouts with dead-keys. On a US English keyboard, ` and ~ are on the key above Tab, and we were considering using Alt + that key as cycle through windows. (It already works inside the Alt-Tab switcher.) Assuming we stick with this, there will eventually be code to fix it so the binding is always Alt + the key above Tab, not Alt-` (it's actually ` that it checks for now, not ~). Even if that physical key is bound to a dead key in your layout, it wouldn't matter, because deadness is a per-modifier-state thing, so Alt+that key wouldn't be dead just because the unmodified key was. 2) Windows on the current workspace Please. I tend to use a workspace per activity - and I believe this is where shell is (was?) going to try and lead the user. That was never really the intent, that was just a common misinterpretation based on the early mockups. The problem is, since the number of workspaces and windows is big, my alt-tab switcher goes beyond the screen borders There are bugs about that -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Couple of Suggestions
On 10/19/2009 10:57 AM, iain wrote: On Mon, 2009-10-19 at 10:34 -0400, Dan Winship wrote: On 10/19/2009 06:46 AM, Gustavo Noronha Silva wrote: On Sat, 2009-10-17 at 09:29 +1100, William Madden wrote: to the window I want. It would be better if alt-tilde on its own brought up the display and started changing windows of the current app. I don't know what alt-tilde is used for, but it's an awful combination for people who use keyboard layouts with dead-keys. On a US English keyboard, ` and ~ are on the key above Tab, Thats the problem though, key placement: On a UK English keyboard ~ is the shift option on the key beside the return key on the complete opposite side from the tab key and alt-~ would just be awkward to use. Um... ok, so I can't tell if my last message was actually unclear or if you just didn't finish reading it, but: 1. The binding is supposed to be Alt + whatever key is above Tab on *your* keyboard. That is, it is defined in terms of a key that is physically located in a particular position, not in terms of a key that generates a particular keysym. 2. Currently that is not implemented, and the binding is just Alt+` for all users. This is a bug. (Specifically, it's bug 596231.) 3. We haven't bothered to fix the bug yet because it has not been conclusively decided that we're keeping the binding, or that we're keeping it bound to the key above Tab, whatever that may be. -- Dan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
