Gnome3 for the experienced (FUN Stuff!!!)

[zerozero]

i'm not following gnome-shell actively lately (went back to the roots) but a place that was useful and where i still check the news is http://worldofgnome.org/ (don't know if you know about it already)

[cwwgateway]

I don't know much, but I do know there was lots of complaints about Nautilus 3.6 - Clem forked 3.4 (Nemo), Ikey forked Nautilus too, and (this is when you know there's probably something wrong with it) Ubuntu won't go to Nautilus 3.6 and might even switch to Marlin, Nemo, or their own file manager.

[autocrosser]

Things have been pretty quiet around here too, I was beginning to wonder if I was the only one who noticed that...

Anything we should be looking forward to in GNOME 3.6? (Or, better, would you even happen to know..?)

I've been following 3.6 & it's looking pretty good--lots of apps cleaned up/new features & there will be a couple of new bits also.... Schedule page: https://live.gnome.org/ThreePointFive & there is a quick info on the "new" stuff: http://blogs.gnome.org/mclasen/2012/08/ ... ture-list/ I'll be trying the "new" Nautilus & report back if it's as "bad" as all say it is.....

EDIT: added a couple of other bits of info: http://davidz25.blogspot.com/2012/08/di ... me-36.html & https://afaikblog.wordpress.com/2012/08 ... ext-level/ --this one is saying that Nautilus will be BETTER than worse--depends on what you think better & worse are

So here's to Sept 26!!!!

[GregE]

I'm with Autocrosser. I am looking forward to Gnome 3.6 and the new Nautilus. I have used Gnome Shell as my primary desktop since the first 3.0 release. I have looked at Mate and Cinnamon, and even ran Xfce on my notebook for a while. I see the criticism of Nautilus through the eyes of someone who has looked at the criticism of Gnome Shell and rejected it. Maybe the new Nautilus will be a dud, but probably not. My desktop will be running 3.6 when it hits experimental - bring it on.

[cbowman57]

Anything they do to Nautilus I can deal with, I use thunar with gnome shell anyway.

[autocrosser]

As far as Nautilus goes--This is what I'm interested in: (quote from McCann)

So when you think about adding working search to Nautilus you really want to use the emerging GNOME 3 design pattern for search. Something that has been discussed quite a lot recently. Including most recently at the UX Hackfest last week.

This implies a few things. That searching be: fast, performed as you type, have results ordered by relevance, quickly converge on what you want, and allow quick activation of the top hit. This should hopefully reduce or obviate the need for scrolling, intensive visual scanning, unnecessary navigation. Allowing you to quickly grasp what you want and maintain your focus on your ultimate goal rather than a series of intermediate and tedious tasks. A better time.

From this blog: http://blogs.gnome.org/mccann/2012/08/01/cross-cut/

[karashata]

Just curious, did anyone running Experimental end up with libsoup2.4-1 crashing the Shell when using the weather extension available from WebUpd8's GNOME 3 PPA..? I didn't notice a problem last night (due to no internet connection at home which the extension could use to get the weather data...) but when I got online at the local library the Shell crashed when the extension tried to load (or possibly display) the weather information. Downgrading the packages fixes the problem, thankfully. I imagine I could also disable the extension but that would kind of defeat the purpose of having it...

Just figured I'd throw a heads-up out there for anyone who needs it...

EDIT: Actually, it seems to be a Python problem, upon closer inspection... A similar issue is occurring with Hotot, apparently 'g_pollable_stream_write' is an undefined symbol... Anyone know which Python package needs to be downgraded to fix that..?

EDIT 2: Or maybe it's not Python, I don't know... I downgraded the glib-networking packages to Testing and Hotot is working fine again as well... Something seems screwy here...

[autocrosser]

Just curious, did anyone running Experimental end up with libsoup2.4-1 crashing the Shell when using the weather extension available from WebUpd8's GNOME 3 PPA..? I didn't notice a problem last night (due to no internet connection at home which the extension could use to get the weather data...) but when I got online at the local library the Shell crashed when the extension tried to load (or possibly display) the weather information. Downgrading the packages fixes the problem, thankfully. I imagine I could also disable the extension but that would kind of defeat the purpose of having it...

Just figured I'd throw a heads-up out there for anyone who needs it...

EDIT: Actually, it seems to be a Python problem, upon closer inspection... A similar issue is occurring with Hotot, apparently 'g_pollable_stream_write' is an undefined symbol... Anyone know which Python package needs to be downgraded to fix that..?

EDIT 2: Or maybe it's not Python, I don't know... I downgraded the glib-networking packages to Testing and Hotot is working fine again as well... Something seems screwy here...

Hmmmm---my version of libsoup is 2.4.1 (really 2.39.90-1) & didn't have a problem with the weather applet there---I've got every version of python you can currently install installed on this install (ouch--bad pun!!!) 2.6 - 2.7 - 3.2 & testing 3.3RC--also no problems there..they all co-exist very well & again the weather applet seems to pick the python version it needs....

I got the newest glib-networking libraries last night & didn't have any problems either...

I have "future-proofed" all my extensions by modifying the metadata.json file this way---

"shell-version": [
"3.2",
"3.2.1",
"3.4",
"3.4.1",
"3.4.2",
"3.5.4",
"3.5.5"
],

that way I've been extending their life until 3.6 requires a rewrite of several of them---you "should" modify the metadata file for the weather app & see if that "fixes" it.....Ignore any "Do not edit" info--they were not thinking about things beyond 3.4----

That reminds me that 3.5.90 will need to be added soon!!!!!!!

[karashata]

I'm not sure how updating the metadata will fix Python throwing an undefined symbol error about 'g_pollable_stream_write' in the .so files it complained about with the weather extension and Hotot, but I suppose I could future-proof things for when GNOME 3.6 starts entering Experimental at least...

I'll also try reinstalling Python and whatever other related packages I can think of that might affect those, it could be that one of the updates didn't quite install properly...

EDIT: Ouch, apparently that didn't work... What version(s) are your various Python packages autocrosser..? I may try downgrading Python to an older version and see if that might work, otherwise I'm gonna have to stick with using the testing versions of glib-networking and libsoup2.4-1...

EDIT 2: Nope, only thing that seems to work is downgrading libsoup2.4-1 and glib-networking to Testing versions... Is there some chance something on my system is broken..?

EDIT 3: For clarity, I'll post the full error messages related to both the WebUpd8 weather extension and Hotot.

For the weather extension:

Code: Select all

gnome-shell: symbol lookup error: /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1: undefined symbol: g_pollable_stream_write


For Hotot:

Code: Select all

/usr/bin/python: symbol lookup error: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: undefined symbol: g_pollable_stream_write


So it's not a Python issue like I thought it might be, I forgot that Hotot is a Python-based program... So, the question is now, what would cause those symbol lookup errors, and what do I install/reinstall/update to try to fix them, and why does downgrading the packages containing the problematic .so files fix the problem?

[autocrosser]

It is possible you have something broken Take a look at the python versions you have installed & post them--I'll take a look & see what's up...

Sounds like your default version of python is too old.....

[karashata]

Okay, this is what I've got:

Python (default): 2.7.3-2 (from Unstable)
Python 2.6: 2.6.8-0.2 (from Testing)
Python 2.7: 2.7.3-5 (from Unstable)
Python 3: 3.2.3-5 (from Testing)
Python 3.2: 3.2.3-6 (from Unstable)
Python 3.3: 3.3.0~rc2-2 (from Experimental)

From digging around a bit yesterday I figured out g_pollable_stream_write should be handled by GLib, libglib2.0-0 and its supporting packages are currently at version 2.33.12-really2.32.3-1 from Unstable.

I have libglib2.0-cil held back due to a dependency on libcairo2 1.12 (which still causes some graphical issues I don't really care for and can't seem to eliminate using any supposed fixes I've found...), though I did temporarily update it to see if it may have helped (which it didn't).

gir1.2-glib-2.0 (the introspection data files for GLib and others) is currently at version 1.33.10-1 from Experimental.

python-gi and python-gi-cairo are both at version 3.3.91-1 from Experimental.

I hope something in all that might be useful.

[autocrosser]

Very interesting!!!! I have libglib held right now--it would be a regression on my system... I have 2.33.12-3 for libglib2.0-0. -bin, -data & -dev These were from Experimental a couple of weeks ago & I don't have a reason why the "new" version is a regression back to 2.32.3-1 I have a "gut" feeling is that is where you have your problem..... Other than that, my system has the same installed.... I do still have copies of those libglib debs---in x64 if that's what you are using----I don't have any 32 bit debs.....

[karashata]

I hadn't noticed the version change was a regression, glad you caught that. I'll have to grab the older (actually newer) version again from the snapshot archive then, and hopefully everything will work fine again. Thanks for your assistance!

EDIT 1: And there we go!

Now all that needs doing are Xorg fixing the bugs Cairo 1.12 revealed (the only problem I seem to have is some images or Flash content going greyscale if they're partially out-of-view in Iceweasel, but that's still pretty annoying), and someone fixing GStreamer so Banshee and Rhythmbox don't stall at the beginning of an MP3 track if the previous track was FLAC... (I only recently got around to filing that bug, unfortunately, and I haven't heard or seen anything about it beyond the bug tracker's acknowledgement of receipt... I've also had to hold back certain packages on my Mint 13 install to versions from Ubuntu 11.10 so I could keep the affected GStreamer package and its dependants at the older, properly working versions from Debian, since they're slightly newer than the packages Ubuntu 11.10 provided...) Once those get fixed I can unpin pretty much everything else that I'm holding back currently... Oh, and Mint's Debian artwork package depends on gtk2-engine-clearlooks which doesn't seem to be provided by the latest gtk2-engines package anymore...

[autocrosser]

Glad I could help!!!! I'm not using Iceweasel--running the Alpha branch of Firefox & I haven't seen your flash problem..haven't had any Cairo problems at all of late......

Here's luck to you & waiting for Sept 26!!!!

[GregE]

There is a fix to the libcairo issue, but simple it is not

http://forums.debian.net/viewtopic.php?f=6&t=80382

As I use Chrome and 'real" Firefox I have not had any issue with Cairo. I run a downloaded Firefox 64bit nightly from /home/greg/bin/firefox and it will keep itself updated as it does not need root permissions when run from a home folder. It is, no doubt, not as secure - but then Chrome is my main browser and I only use Firefox for testing and the odd site where I do not want to be logged into my Google account.

http://nightly.mozilla.org/ if you are interested in seeing if it solves any problems.

My Gnome 3.4 Sid Multi-Arch install is so stable at the moment that it is almost boring.

[karashata]

Reading through that thread, the patch seems to be for a different issue from the one I experience with Cairo 1.12, so I'm not sure it would fix the problem. (It seems to be specifically for server-side-gradients, and seems to be mainly for nVidia, which doesn't support such, and ultimately causes lag with the browser. I have Intel integrated graphics, and I'm not experiencing any sort of lag...)

The official builds of Firefox apparently don't even use Cairo so they wouldn't be affected by the bug it reveals in Xorg.

I think for now I'll just hold onto Cairo 1.10 until either a fix is released for Xorg or I just can't hold it back anymore (when nearly everything else I need/want requires it to be upgraded... Right now only Banshee seems to require it to be updated but the last version still using Cairo 1.10 works just fine, and the Banshee Daily Builds PPA for Ubuntu hasn't upped the database version yet...)

[autocrosser]

Cool!!! Glad your issues are "almost" over --are you still leaving all the sources open or only opening the "taps" at intervals?? I also use the nightly alpha builds--I used a custom script to "really" keep it as my main browser--it installs to /opt & I've not had any security issues with the builds....running 18.0a1 (2012-09-17) & couldn't be happier with a alpha build....

[GregE]

Banshee Daily Builds PPA for Ubuntu hasn't upped the database version yet...)

Ubuntu debs on a Debian system. It will end in tears.

Version 2.5.0-1 is in Experimental. I do not have Banshee installed so I cannot say if it is any better.

[karashata]

Naw, I'm not using the Ubuntu buildson my Debian install, I just have Banshee's configuration and cache files linked on my data partition between both my Ubuntu install and my Debian install, mainly so my library stays properly updated between both OSes. Occasionally Banshee updates the database version with a new release, which would cause an older version of Banshee to fail to load the database and not launch unless the database is removed and rebuilt. I'm just glad that, even though the Banshee Daily Builds release is newer than the current version I'm using on my Debian system, the database version is not, so I don't *have* to update to the newer version of Banshee on my Debian system (which would require updating to the new Cairo, which I'd really rather not do just yet...)

(I *do*, on the other hand, have quite a few Debian versions of various things installed on my Ubuntu-based install, since Debian tends to have newer versions of the programs I use, and their dependencies often need to be updated as well...)

I did briefly update Banshee from Debian experimental, it doesn't *look* any different, or work any different as far as I can tell, so I'll just stick with the older version that still works with Cairo 1.10, until Xorg gets fixed so Cairo 1.12 doesn't cause problems...

@autocrosser: I usually leave Experimental enabled, I've gotten better at avoiding potentially problematic updates, and if I do let something by that I shouldn't have, as long as it doesn't completely cripple my system, I can usually revert to the previous version from the Debian Snapshot Archive. I missed the GLib updates (that were actually downgrades) because I had to revert to a month-old backup which had an older version installed, so it didn't appear that the GLib updates were downgrades. I suppose I need to keep on top of my backups a little better so I don't end up so far out-dated if I have to revert to them...

[GregE]

I leave experimental active, but set it's priority lower than Sid. So I can install a package from experimental if I want and it will pull the dependencies, but it will not just automatically update. By using Synaptic I can just use the version option to selectively dip into experimental, or use apt-get -t experimental install packagename. This approach has been pretty safe now for a long time.