One of the pain points when using a touchscreen device is closing applications while in window picker (overview) mode. Why not add a “Trash Can” target to the dash or dock where windows can simply be dragged and dropped to close them? It would only need to be visible while in the window picker overview. Thoughts?
I have been thinking about writing this down for quite a while: my hands-on experiences testing Ubuntu Unity and GNOME Shell on the WeTab tablet. Unity Unity makes a fine netbook interface, but tablet support feels underdeveloped. After configuring auto-login, I was greeted by the standard desktop and launcher. However, launching an application and maximizing it hides the dock launcher entirely, making it awkward to bring back with a finger. Furthermore, scrollbars are difficult to grab, and multi-touch gestures like drag-to-scroll aren’t yet implemented. Aside from those tablet friction points, the interface shows potential. ...
I am heading to FUDCon Pune this year! I hope to present a talk to help newcomers get started with contributing to open source, specifically within the GNOME project. Please check out and vote for my session here: Contributing to Open Source (FUDCon Session)
gnome-power-manager was rewritten for GNOME 3.2 and merged directly into gnome-settings-daemon (g-s-d) as a plugin responsible for system power policy. Most power management is handled by UPower, with backlight brightness being a key exception. Backlight is managed at the session level by gnome-settings-daemon via its power plugin using XRandR or standard sysfs, depending on hardware and driver support. To read screen brightness over D-Bus: gdbus call --session \ --dest org.gnome.SettingsDaemon \ --object-path /org/gnome/SettingsDaemon/Power \ --method org.gnome.SettingsDaemon.Power.Screen.GetPercentage Why bother with this? On a tablet device (such as the WeTab), brightness settings were buried deep in system menus and cumbersome to reach. With the custom GNOME Shell brightness extension (download archive), you can adjust screen brightness directly from the top bar. This requires patching gnome-settings-daemon to emit the Changed signal (GNOME Bug 658493). ...
It’s been a blast—Linux on the desktop never ceases to amaze me.
Why should you migrate to x86_64 over 32-bit? The Year 2038 Problem is not something you want to run into. Do your part: ensure your applications build and run cleanly on 64-bit systems, and move to x86_64. (Looking at you, Flash and Skype: ಠ_ಠ)
To set up 32-bit Flash in 64-bit Chrome on Fedora x86_64: Download and install the adobe-release RPM package from Adobe Flash Player. Install the Flash plugin and 32-bit compatibility wrapper packages: sudo yum install flash-plugin sudo yum install alsa-plugins-pulseaudio.i686 nspluginwrapper.i686 nspluginwrapper.x86_64 Link the wrapped plugin into your 64-bit Mozilla plugins directory: cd /usr/lib64/mozilla/plugins sudo ln -s ../plugins-wrapped/nswrapper_32_64.libflashplayer.so . Restart Chrome, and you are done!
Good news: the Dell ST2220T multi-touch monitor works on Fedora Linux using evdev under Xorg! Special thanks to Gopal for tracing and testing this. Additional hardware diagnostic info is posted in Red Hat Bugzilla 703118.
xchat-gnome 0.26.2 has been tagged, though it hasn’t yet been uploaded to ftp.gnome.org. Instead, I am pushing for an immediate 0.26.3 release—hopefully the final release in the GTK+ 2.x series—followed by xchat-gnome 0.3.0 targeting GNOME 3.
For anyone who prefers to stick with “GNOME Legacy” (Fallback mode) rather than GNOME 3 with GNOME Shell, you can configure your default session by running: cd /usr/share/gnome-session/sessions sudo mv gnome.session gnome-new.session sudo mv gnome-fallback.session gnome.session