Re: gsettings org.gnome.desktop.input-sources current alternative
On Sun, Mar 26, 2017 at 3:34 PM, Zan Zellor wrote: > gsettings org.gnome.desktop.input-sources current 1 > > but it doesn't do anything. > > Looking through its description using dconf-editor, I see it says that the > key is deprecated. Is there any alternative for the current key? Right, it doesn't do anything because it's no longer used and that's why it says it's deprecated. This runtime state used to be kept in sync between gnome-settings-daemon and gnome-shell through that gsetting but that had a few drawbacks so the whole functionality was migrated to mutter/gnome-shell and so this is only kept internally now. You can still poke at it through the command line since gnome-shell exposes a JS eval interface on DBus which has access to all its internal objects. Something like: $ gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval "imports.ui.status.keyboard.getInputSourceManager().inputSources[0].activate()" should activate your 0th layout and so forth for other indexes. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: keyboard layout and Super
On Fri, Jun 10, 2016 at 11:06 PM, Alessandro Dentella wrote: > I'd like that too, but some configuration caming from old configuration > prevent this. Windows key is mapped to compose and I can't find a way > to modify it. Settings > Keyboard > Shortcuts > Typing > Compose key > Is there a way to reset all information of the layout to the default? $ gsettings reset-recursively org.gnome.desktop.input-sources Hope that helps, Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: "force quit" dialog popping up during certain activities
On Sun, Sep 13, 2015 at 7:24 PM, Josh Stratton wrote: > I'm going to start investigating what criteria brings this dialog up, The dialog is triggered if the application advertises support for the _NET_WM_PING protocol but then doesn't reply in time, see the wm spec[1] . [1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472543696 > but is > there some way I disable this dialog? There's no supported way to disable it. Mutter uses the zenity command to put up that dialog, so if you can hide that command from mutter or make it non-executable, the dialog won't be launched but be aware that this is an implementation detail and might change without notice so you can't rely on it. Please get the application fixed or file a bug for mutter if you have evidence that mutter isn't complying with the _NET_WM_PING protocol. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Question about locking down access to settings in gnome-shell...
On Wed, Sep 2, 2015 at 11:08 PM, Sean wrote: > gsettings shows that the value is "uint32 300", but dconf-editor just shows > 300. Shouldn't I be able to set the value to 120 in my > /etc/dconf/db/site.d/00-site-settings file? If so, what does that look > like? [org/gnome/desktop/session] idle-delay=120 I haven't actually tried but if that doesn't work please report a bug in bugzilla.gnome.org . Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Question about locking down access to settings in gnome-shell...
On Tue, Sep 1, 2015 at 3:55 PM, Sean wrote: > I am working on locking down various user settings using dconf locks and > applying the config using puppet templates. I'm managing a bunch of > multi-user gnome desktops on Scientific Linux 7.1 with gnome-shell > 3.8.4-45.el7 for a class room environment, but I'm struggling with what > dconf/gsettings key locks access to the Settings / Privacy / Screen Lock / > Automatic Screen Lock toggle. /org/gnome/desktop/screensaver/lock-enabled ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Mutter 3.16.1.1
About mutter Mutter is a window and compositing manager that displays and manages your desktop via OpenGL. Mutter combines a sophisticated display engine using the Clutter toolkit with solid window-management logic inherited from the Metacity window manager. While Mutter can be used stand-alone, it is primarily intended to be used as the display core of a larger system such as GNOME Shell. For this reason, Mutter is very extensible via plugins, which are used both to add fancy visual effects and to rework the window management behaviors to meet the needs of the environment. News * Prevent a crash when switching VTs or adding input devices [Carlos; #747886] Contributors: Carlos Garnacho Download https://download.gnome.org/sources/mutter/3.16/mutter-3.16.1.1.tar.xz (1.5M) sha256sum: 795084f6b642ab45e9f73b82b185949a110f2149bc0bce9f70ff30c8ab4c051c ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: How to use gdk_display_get_default () ? (Mutter related doubt)
On 9 January 2014 15:20, Parin Porecha wrote:
> But, when I write this code in a blank file -
>
> Display *display = GDK_DISPLAY_XDISPLAY (gdk_display_get_default ());
> printf("Name of display is = %s\n",
> gdk_display_get_name(gdk_display_get_default ()));
>
> and run it, I get this error -
>
> Gdk-CRITICAL **: gdk_x11_display_get_xdisplay: assertion `GDK_IS_DISPLAY
> (display)' failed
> Gdk-CRITICAL **: gdk_display_get_name: assertion `GDK_IS_DISPLAY (display)'
> failed
> Name of display is = (null)
>
> Is there something mutter does before calling gdk_display_get_default () ?
Are you calling gdk_init() ?
> (I couldn't find a mailing-list for mutter, so I had to post this here.
> Sorry if this isn't the appropriate list for mutter related questions)
This list or #gnome-shell on IRC is fine.
Rui
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: screen unlocking issues -- gnome 3.8
Hey there, On 19 June 2013 22:50, Pedro Francisco wrote: > I got the screen lock partially unlocked today again, requiring > killall -HUP gnome-shell to login. What is a partially unlocked screen? Can you describe this with more detail? Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: .cache/gdm/session.log is empty
On 17 June 2013 12:30, Pedro Francisco wrote: > My screensaver got in semi-unlocked state again and I have nothing in > session.log . > > Does anyone have any pointers to where shell debug goes now? In F19? It's all in the journal. Try journalctl -b _UID=`id -u` Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Input method options
On 4 May 2013 22:16, Bastien Durel wrote: > Is there no option to recover the old, used-to-be, behavior ? The one I used > for years ? You can force a particular gtk+ IM module by setting the GTK_IM_MODULE environment variable. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Input method options
On 4 May 2013 21:58, Bastien Durel wrote: > No, I'm using "English (US, international with dead keys)", so I can write > é, à, or ÿ characters. But with this layout, [']+[c] produces a ć (LATIN > SMALL LETTER C WITH ACUTE (U+0107)). To get the ç, I need to select the > "cedilla" input method. You can type ç with AltGr+, (AltGr+comma) Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Input method options
On 3 May 2013 19:25, Bastien Durel wrote: >> Why do you need the cedilla IM module? >> > To write proper french with my US keyboard ;) Ok, and I suppose you are using the "English (US)" layout? I suggest you use one of the "English (international AltGr dead keys)" or "English (US, international with dead keys)" instead which will work on all applications regardless of toolkit. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Input method options
On 3 May 2013 17:16, Bastien Durel wrote: > The configuration panel for this option seems to have disappeared from > the keyboard configuration panel. Which configuration panel is this? I don't remember this setting ever being exposed anywhere in the UI. > How to recover it, or configure it ? Why do you need the cedilla IM module? > Thanks, > > [1] Actually, depending of application, the selector displays "System > (cedilla)" (in evolution, for exemple) or "system (simple)" (in gedit); > but cedilla does not work in evo nor gedit, although I select "cedilla" Really? That's very odd. Are these 2 applications running in the same GNOME session? Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Get current key modifiers
On 29 March 2013 19:47, Vadim wrote: > It seems as an easy question, but cannot find the answer: how do you get > in Gjs (writing an extension) all the currently pressed/set key > modifiers (such as Ctrl, Shift keys and/or Caps-Lock etc.)? I know how > you get this in an event, but need to get it just in a method. For gnome-shell you can do it like that: https://git.gnome.org/browse/gnome-shell/tree/js/ui/switcherPopup.js#n153 Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: g-s 3.6.2: notification tray disappeared
Hey Pedro, On 11 February 2013 18:44, Pedro Francisco wrote: > I'm currently in a state where > > $ notify-send test > > does not show anything. I have no extensions installed. > > Pressing Windows key shows no notification tray. > Pressing Windows+M does nothing. > > I can access gnome-shell's looking glass, do you have any tips for a live > debugging now? > > Note: the bug will probably disappear once I do: killall -HUP gnome-shell. > > $ sudo rpm -qa gnome-shell > gnome-shell-3.6.2-6.fc18.i686 I believe this is https://bugzilla.gnome.org/show_bug.cgi?id=683986 which is supposedly fixed. If you have backtraces in your ~/.cache/gdm/session.log you can compare them with the ones reported in that bug to be sure. If it's different please file a new bug with it. For live debugging tips it would be best if you could join #gnome-shell on irc.gimp.net . Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: LOG: IBus version is too old
On 3 October 2012 04:44, Zhuo.M wrote: > but Log still says: > JS LOG: IBus version is too old You need an IBus checkout after https://github.com/ibus/ibus/commit/a78a254715fb410d4c2f7fd274894e51d74bc9bb . Unfortunately, upstream hasn't done an official release yet. There are recent pre-releases[1] though. Rui [1] http://code.google.com/p/ibus/downloads/list?can=2&q=&sort=-uploaded&colspec=Filename%20Summary%20Uploaded%20ReleaseDate%20Size%20DownloadCount ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: About render speed
On 20 May 2012 15:59, Weng Xuetian wrote: > I'm implementing an extension that may need to update a window very > frequenctly, say maybe 10 times per second. (Please don't ask about reducing > the frequency, this is based on an very rapid user input and it need to be > updated in time to give user correct reaction.) > > I'm using 10 St.Text and all of them will be updated, but I found it could not > be updated in time (very obvious delay, say second level). I don't have a ready answer but I'd like to point that there is a lower bound on the achievable latency with the current architecture just due to the various context switches that must occur for you to see stuff on the screen after the user presses a key: X server > App > DBus daemon > Input Method daemon > DBus daemon > gnome-shell > X server So that's 6 context switches per event. Now, there probably is some low hanging fruit that could greatly improve things even with the current architecture but there will be a lower bound which might still be noticeable. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gdk.window set_decorations works in python not javascript bindings (v3.0)
On 6 May 2012 15:17, Amy C wrote: > When I execute this code from the GNOME interactive gjs interpreter > (looking glass), when I execute `curwin.set_decorations(0)` the window > in question closes itself. For example, if the current window is a > terminal and it has a process running in it I'll get the "Running > process in terminal; are you sure you want to quit?" dialog, from > which I can select Cancel (window will be maximised/undecorated as I > wish). If there are no processes running in the terminal, it will > simply quit! You can't use GDK like that form inside the window manager. > However, if execute this using the `gjs` binary (whether running > GNOME-shell or unity+metacity) I get "ERROR: Gdk.Screen.get_default() > is null" -- some environment variable not set up properly?? $DISPLAY > is :0 as normal. Try the following before your code: const Gtk = imports.gi.Gtk; Gtk.init(null); The Gtk.init() and Gdk.init() functions are not currently totally functional when called through gobject-introspection but this should work for your case. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Clipboard and primary selection
On 9 February 2012 15:07, Stefano Ciancio wrote: > is it possible to get primary selection in an extension? Not yet, see https://bugzilla.gnome.org/show_bug.cgi?id=645019. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Gnome 3.2 freezes, then goes 100% CPU
On 5 December 2011 13:25, wrote: > I just unplugged the external monitor attached to my laptop and the problem > seems to be gone (to be confirmed with time). > > Should I use nvidia proprietary driver rather than the open source one? Yeah, this sometimes happens with nouveau, especially with larger framebuffers such as what you get with multiple monitors. Sometimes you see nouveau complaining a lot in the dmesg output. Anyway the nouveau developers are aware of these issues but I'm told they are complex to solve and might take a while. The nvidia blob might work better for you, but it has other problems like missing to implement the latest xrandr APIs. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Alt+F2 doesn't find scripts in ~/bin
On 30 August 2011 04:34, Ralph Hofmann wrote: > @gnome-shell developers: I think there should be a way to setup the PATH for > alt+F2. It works for me. You can check the $PATH that gnome-shell sees with $ strings /proc/`pidof gnome-shell`/environ | grep PATH If what you want is not there you just have to find what session initialization scripts your distro runs and put it there. FWIW, on Fedora, I put that kind of stuff in ~/.bashrc. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Detecting need for fallback
On 6 July 2011 17:18, G. Michael Carter wrote: > How does gnome shell detect it's not compatible on a system and fallback is > needed? Or is it a case of just waiting for gnome-shell to crash? > > The reason I ask, I've built a livecd (PXE booted actually) that is text > based and grabs things like the hardware profile. As a test I wanted to > check if Gnome3 would work on the system, without starting the graphics > server if I can help it. It's gnome-session that checks for it running helper processes[1]. They need and X server to work though. Rui [1] http://git.gnome.org/browse/gnome-session/tree/tools ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: alt-` no longer working?
On 4 July 2011 12:00, Tim Cuthbertson wrote: > Not sure if this is just me, but lately the alt-` (key above tab) is > not working any more. > > I have been patching mutter and messing with keybindings lately also, > so I just wanted to check whether I'm the only one seeing this before > I bother to report a bug. > (fedor 15, g-s version 3.0.2) It's OK here with both 3.0.2 and master. $ gconftool-2 -g /apps/metacity/global_keybindings/switch_group Above_Tab That's what the setting should say. Of course, you might have busted the code ;-) Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Changing how I work in Gnome 3
On 13 June 2011 02:08, Andrew Douglas Pitonyak wrote: >> Although I think when you have a specific workflow and know exactly >> what window you need to switch to next. Maybe assigning a number to >> those windows, then+Tab, then press the number to switch to a >> certain window, would be faster. > > Can you recommend some documentation on assigning a number so that I can use > Alt+Tab and then press a number. That's not implemented currently. > Based on your comments, I started poking around through gconf system > settings. Found some interesting items (such as Alt+Esc). The fact that Alt+Esc and Alt+F6 work is a byproduct of the way that mutter (and thus gnome-shell) uses the metacity configuration schema since it is basically a fork of metacity and still has code implementing those behaviors. But those behaviors haven't been designed for gnome-shell use and are actually bugs IMO (they don't even look correct graphically). They will probably disappear in a future gnome-shell release or at least be re-designed both in looks and/or behavior. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The good, the bad, the insane
On 26 May 2011 01:22, Robert Park wrote: > > For those complaining about the removal of the "power down" option, do > your laptops lack physical power buttons? I have been running Gnome > Shell for months, and I just tap the power button, then the shell asks > me if I want to reboot or power down. Works flawlessly and it's > actually one less click than accessing it from a menu. You have to change the default action for the power button in the Power preferences though, since the default is to suspend on power button press. > I kind of wish people would just stop complaining about this and start > using their physical power buttons. It's been working great for me. I > don't see what the fuss is about. Amen. Some people seem to have endless complaining energy... Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME 3 & nVidia
On 25 May 2011 11:13, Adam Tauno Williams wrote: > There is the statement "Nvidia binary drivers (slow if you have an old > driver)": What is "old"? I think, but I'm not sure, that anything > 270.41 is "good" enough. > I have an odd issue with multi-head. If I connect a second monitor to > my laptop and run nvidia-settings I can enable the external display as > "TwinView" and it comes up available as a second display under GNOME3 > [1]. The primary display - the one with the GNOME3 panel - scrolls as > workspaces while the second display behaves as a workspace unto itself > (it doesn't scroll with the other display). This works really well, it > is fast and smooth. BUT if I lock the display it goes to being actual > Twin-View where the external display is a mirror of the 'internal' > display. If in nvidia-settings I disable the external display and go > back to TwinView I get the two separate displays behaviour. Odd, I > think. This is unexpected and doesn't happen with nouveau. > If I set the display as Separate-X-server [the other option from > Disabled and TwinView] and restart X... I end up in unaccelerated > fall-back mode. Multiple X screens is broken in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=648156 . Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: 3rd party application integration guidelines - how to be a good shell citizen?
On 24 April 2011 23:39, Holger Berndt wrote: > Switching to another application is not exactly what I had in > mind to get rid of the application. I still have the old application > window around, I see it partially occluded behind non-maximized > windows, I have it cluttering the Alt+Tab application switcher, > the application overview and so on. It appears as visual clutter, and > somewhat contradicts the otherwise distration-free design of the shell. The distraction-free design argument kind of makes sense here, yes. > I think it would make sense to have a special design for applications > that users want to keep launched as long as they are logged in > (because they perform some important background task or keep > communication channels open), but only interact with once in a while. But here, I don't think gnome-shell itself can offer you much more. What we actually need is just better designed applications. Applications that don't need to deal with live resources should just serialize their state to storage in such a way that the user can close the window at any time (even by mistake) but quickly launch it again and be at the *exact* same point where they were at the time the window as closed. A good example would be a text editor always coming back with all the files you previously had opened, the correct tab selected, the buffer scrolled to the point where it was left, "unsaved" buffer modifications, etc. For applications that deal with live resources such as mail clients, they could be designed to be run "headless" i.e. when you close the window, the view (as in MVC) process goes away but the model (again, as in MVC) process remains running and able to make notifications, etc. We have GDBus which should make this class of applications easier to make and soon even easier with David Zeuthen's gdbus-codegen tool in glib[1]. Rui [1] http://git.gnome.org/browse/glib/log/?h=gdbus-codegen ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: What happens when Gnome-Shell isn't behaving?
On 14 April 2011 14:55, G. Michael Carter wrote: > Since it seems altering the UI to give that backup is out of the question, > what about a hot-key for fallback mode? or a hot key to restart the gnome > shell, without killing the running apps? I'm open to suggestions here. If a gnome-shell bug was preventing me from getting work done I'd just go to the control center and set the fallback mode On until bugs were fixed. Everything else is just wasting time if you have more important things to do. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: UI Changes
On 25 March 2011 16:49, Robert Park wrote: > I like how in OSX you can grab the dead space within a toolbar and > drag the window from there. I always thought that was a nice touch, > especially for apps like iTunes that don't have much of a titlebar. > > If Gnome is truly moving towards client-side window decorations, then > there's going to have to be some kind of "titlebar" widget included in > applications, which dragging initiates window movements. Once that's > in place, the same window drag logic could be applied to the dead > space in ToolBars and StatusBars nicely. This already works in gtk+ 3.0 for "dead areas" in menu and tool bars at least. Actually I think it works like that since gtk+ 2.22. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Two proposals for Gnome-shell
On 10 March 2011 11:15, Marcel wrote: > Am 10.03.2011 07:45, schrieb Florian Müllner: >> >> On Wed, 2011-03-09 at 22:20 -0500, Jesse Hutton wrote: >>> >>> There should be a default for switch_group in GNOME Shell >> >> Alt+KeyAboveTab (e.g. Alt-` for US keyboard layout) > > This there a way to make that layout independent? I wouldn't want to have to > reconfigure loads of hotkeys because I'm using the Neo layout... It is. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Default Gnome3 Theme.
On 8 March 2011 15:56, Pat Suwalski wrote: > However, the mutter theme really lacks any emphasis or highlight. On a > multi-screen setup, it's really hard to find which window is active. I find > I often assume that it's the top window on the wrong screen. I agree with you here. The slightly bigger shadow of the focused window helps but it's not enough in a multihead setup in my experience. I don't think this is something that can change for 3.0, but I do hope the designers address this problem in later iterations. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: missing workflows with gnome-shell
2011/2/4 Rui Tiago Cação Matos : > That's by design I believe. Workspaces in the shell are going to be > created and removed on demand and the layout is going to be linear > IIUC. But most of that work is still on branch[1]. [1] http://git.gnome.org/browse/gnome-shell/log/?h=workspace-thumbnails ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: missing workflows with gnome-shell
On 4 February 2011 08:49, Sankar P wrote: > Vertical workspace navigation: Currently all workspaces are in only > one row. I want a fixed 3x3 number of workspaces. I keep my terminal > in the centermost workspace where I spend most of the time. I keep > browser, IRC, email client , all one workspace adjacent to the center > workplace. This way, from the terminal, I can go to any workspace with > just one keystroke. Imagine a big + sign, with my most active > workspace in the center. However, with gnome-shell I am not able to > find a way to navigate vertically nor does it remember the number of > workspaces. Is there an alternate to this ? That's by design I believe. Workspaces in the shell are going to be created and removed on demand and the layout is going to be linear IIUC. But most of that work is still on branch[1]. > Keyboard Navigation: When I press the windows (super) key, I get a > Windows, Applications tab. But neither arrow keys nor tab takes me to > navigate across these two tabs. I am forced to use my mouse for > navigating between these two. I have heard that gnome-shell is very > keyboard friendly but I am not able to navigate across these two tabs > via the keyboard. Any solution for this ? Ctrl+Pg[Up|Down] > Hiding the panel: I always hide my gnome-panel using the direction > buttons in the old gnome-panel. I set the panel to auto-hide also. > This way I get maximum screen space for all my applications. However I > am not able to find a way to hide the top panel in gnome-shell. How do > I do it ? Not possible currently. Not sure if that's been considered by the design people. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Gnome Shell
On 1 February 2011 14:00, Calum Benson wrote: > "Flicking the pointer" is easy enough to do with a real mouse, but isn't a > gesture that works very well with touchpads, which I'd guess a lot of our > users will be using most of the time. When I try to flick the pointer with my > touchpad, it just stops halfway :) This is quite true but something that the users can tweak with the touchpad acceleration slider in the control panel. Hmm, now that I think about it, I remember a blog post[1] talking about absolute touchpad menu activation. That would be cool to have, even if just for the hot corner case. Like, if the user leaves his finger on the touchpad's corner for more that a (little) time, the overview is triggered. Don't know if that's actually doable with current X infrastructure though. > From a brief experiment, if my pointer's in the middle of the screen, it > takes me two (on my laptopt screen), sometimes three (on my external monitor) > separate finger movements to hit the corner... But, isn't it the same effort as to reach the bottom of the screen in Gnome 2's default panel configuration? Rui [1] http://blogs.gnome.org/seth/2010/02/26/let-the-wild-rumpus-begin/ - what happened to Seth btw? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Some suggestions
On 26 January 2011 05:49, Peter Slavek wrote: > - The position of the clock looks too much like the title of the entire > screen - it feels slightly intrusive. I think it would look far better tucked > away to the right, along with the user's name and system tray icons, with > adequate spacing in-between. I actually like it better this way. Glancing at the clock is something that many people do unconsciously and I find it quite a lot easier and natural to just look a little bit up instead of all the way to the right. > - The text on the top panel in some screen-shots (*) also seems as if it's > shouting; the weight of the typeface is far too heavy for my liking. I think > it would look more elegant at somewhere just slightly heavier than usual. > (*http://seilo.geekyogre.com/uploads/2010/12/Screenshot1.png) That's addressed already in the latest version if you have installed gnome 3's new default font called Cantarell. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Rendering problems
On 13 January 2011 17:40, Adrian Wyssmann wrote: > I past yesterday I've built the gnome-shell from git repository. It runs, > but the performance is poor and I have rendering problems (artefacts, screen > is mirrored sometime) --> http://vimeo.com/18751005 Nice effects there ;-) > I am running it on Ubuntu 10.10 ( 2.6.35-24-generic #42-Ubuntu SMP Thu Dec > 2 02:41:37 UTC 2010 x86_64 GNU/Linux) with an ATI Mobility Radeon HD 4670 > I'm using the proprietary ATI Driver: Driver Packaging Version = 8.73.3, > Catalyst Control Center V.2.13. Can you try with the ati free driver? Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: notifications (window hints)
On 2 December 2010 01:51, William Jon McCann wrote: > Because we retain and redisplay those notifications. The design > states (though this isn't yet implemented - help needed) that we > should display the message tray when you haven't been using the > computer for an amount of time (well before the screen off interval). > You also have the opportunity to see messages as you switch tasks in > the overview - since this a natural break in your rhythm. FWIW, I think this is a great design. Anyway, maybe we could compromise a little for those who want to be nagged by constantly showing the message tray when there are notifications pending _and_ the user has set his online status as available. For the busy status what you describe here would be OK I think. I would constantly use the busy status for me. Rui ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
