[04:30] <ccheney> erm why does totem no longer show the time for files?
[04:30]  * ccheney hopes he doesn't get its a gnome thing as an answer
[04:43]  * ccheney takes a look at kubuntu again, i never thought gnome would get to the point of driving users away from dumbing itself down that much :-\
[04:48]  * hyperair hasn't used totem in a long time
[04:48] <hyperair> gstreamer sucks rather grandly at rendering hi-res videos on machines that can barely handle it
[04:49] <ccheney> i use it to play various media files, it appears in lucid they decided knowing where you are in the file is too advanced for their users and removed the time display
[04:49] <hyperair> er that can't be right. are you sure it's not a bug?
[04:49] <ccheney> crazy stuff like that when i file it as a bug it almost always turns out to be a 'feature'
[04:49] <ccheney> so i will file a bug but won't expect much
[04:50] <hyperair> ccheney: could i see a screenshot?
[04:50] <ccheney> pretty much every release there is some insanity going on where gnome removes features i want
[04:50] <ccheney> hyperair: in a couple minutes i will move back over to the lucid machine
[04:50] <hyperair> okay
[04:51] <hyperair> switching to KDE would be much easier if it actually played well with my ~/.config/autostart
[04:51] <hyperair> it runs every damn thing there even stuff that i've disabled in gnome
[04:51] <hyperair> and when i tell KDE to not run it, GNOME borks up and doesn't find the stuff any more
[04:51] <hyperair> so i have to manually edit those desktop files
[04:51] <hyperair> seriously..
[04:54] <ccheney> http://people.canonical.com/~ccheney/totem.png
[04:54] <ccheney> by playing there should be a current time / total time
[04:56] <hyperair> ah that
[04:56] <hyperair> i see
[04:58] <ccheney> filed a bugs 514619
[04:58]  * ccheney brb
[05:03] <ccheney> back
[05:03] <hyperair> ccheney: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/495269
[05:04] <hyperair> ccheney: looks like you filed a duplicate bug
[05:04] <ccheney> yea perhaps my lucid is out of date i thought it was newer than 1-27
[05:04]  * ccheney will update and verify then close it out
[05:06] <ccheney> kde is looking pretty nice though and konq seems much faster than firefox, might just be an illusion though
[05:08]  * hyperair likes chromium
[05:08] <hyperair> but firefox has been rather bloated and laggy lately
[05:09] <hyperair> might be that i have too many extensions though
[05:11] <ccheney> firefox without any extensions seems slower than konq, probably chromium as well
[05:11] <ccheney> hmm my ubuntu image was out of date apparently, upgrading now to verify the totem bug is gone
[05:13] <ccheney> hmm yea totem updates
[05:21] <ccheney> yep its fixed :)
[05:29] <hyperair> =)
[05:29] <hyperair> ccheney: did you mean firefox slower than chromium or chromium slower than konq?
[05:30] <ccheney> firefox is slower than konq and probably firefox slower than chromium too
[05:31] <ccheney> from what i recall chromium is supposed to be very fast
[05:32] <hyperair> yeah it is
[05:32] <hyperair> it just loves eating memory
[05:32] <hyperair> unsurprising since it opens up a crapton of processes
[05:34] <ccheney> oh anything that eats more ram than firefox isn't that great :-\
[05:34] <ccheney> firefox usually ends up taking several gb on my machines
[05:36] <hyperair> ..
[05:36] <hyperair> several GB..
[05:36] <hyperair> how?!
[05:36] <hyperair> the most i've ever seen firefox eat on my machine is.. 9%
[05:37] <hyperair> of 2G
[05:37] <hyperair> which is... 200M?
[05:37] <hyperair> my firefoxes are generally shortlived anyhow
[05:37] <hyperair> i think chromium shouldn't escalate too high, since it ditches its processes so frequently
[05:38] <hyperair> exception being the flash plugin.
[05:38] <hyperair> but you can force it to terminate as well
[05:38] <hyperair> and then there are certain sites that makes flash eat up 2GB of RAM in 10 seconds.
[05:39] <hyperair> first it begins swapping furiously, and the next thing i know, X has been OOM-killed
[05:42] <ccheney> firefox with nothing open just launched takes this on my box
[05:42] <ccheney> ccheney   2556  7.8  1.3 448100 54936 ?        Sl   23:41   0:00 /usr/lib/firefox-3.6/firefox-bin
[05:42] <ccheney> so looks like 55MB with 448MB virt
[05:42] <ccheney> if i am reading that correctly
[05:43] <ccheney> with 3 pages open already at 113MB
[05:43] <ccheney> close 2 of them it only goes down to 109MB
[05:44] <ccheney> revert first page back to ubuntu home page still at 82MB
[05:44] <ccheney> so seems to be a bit leaky, and with long lived firefox instances can easily eat a lot of ram
[05:47] <hyperair> firefox and its damned leaks
[07:09] <Amaranth> hyperair: firefox doesn't leak, it takes your RAM hostage
[07:10] <hyperair> Amaranth: i suppose you could say that.
[07:10] <Amaranth> it actually does
[07:10] <Amaranth> run it on a machine with less RAM and it uses less RAM
[07:10] <hyperair> Amaranth: no actually i think it leaks. you can end up with eventually 200M usage with one tab open.
[07:10] <Amaranth> I think they notice if they were leaking that much :/
[07:11] <Amaranth> That's not "it leaks in this odd corner case" that's "it never frees _anything_"
[07:11] <Amaranth> Actually it basically never does free anything, it keeps a certain numbers of pages in your history completely loaded so the back button works instantly
[07:12] <Amaranth> But it only up to a certain percentage of system memory usage or until only a certain amount is left free or something
[07:17] <hyperair> is that so?
[07:17] <hyperair> i use the firefox daily packages
[07:17] <hyperair> and it seems that the upper limit is 9-10% of my memory
[07:17] <hyperair> my firefox processes are generally short-lived though
[07:18] <hyperair> but like ccheney said, his could easily take a few GB
[10:23] <kklimonda> good morning
[12:36] <kklimonda> chrisccoulson, ping?
[12:36] <kklimonda> or anyone familiar with gnome? :)
[12:38] <chrisccoulson> hey kklimonda
[12:38] <chrisccoulson> wassup?
[12:39] <chrisccoulson> you're going to ask me about broken gconf default settings?
[12:41] <kklimonda> chrisccoulson, I was wondering - I keep some of my music on a second partition which isn't automatically mounted on boot. Now when I run rhythmbox I'd expect it to mount this partition so it can access music but it doesn't and I have to do it by hand. I'm wondering whenever it's a limitation of the gio/gvfs itself or does rhythmbox shouldn't store real paths to files and something like disk://id/path instead (as smb:// or ssh://)
[12:42] <kklimonda> chrisccoulson, no - I just assume that gconf is broken by design ;)
[12:42] <kklimonda> chrisccoulson, but if you have time you can take a look at bug 512391 - initial reports about 1.83 are pretty positive.
[12:43] <chrisccoulson> kklimonda - your dilemma has been discussed before. it's a limitation in gvfs at the moment, because you have to access the files using the file:/// URI
[12:43] <chrisccoulson> and so there is information about the filesystem structure there (ie, you need to mount the disk before accessing the files on it)
[12:44] <chrisccoulson> i actually did think about writing a new backend to handle cases like this, but I don't have enough experience with gvfs, and i don't know if its something that upstream would want
[12:44] <kklimonda> chrisccoulson, heh - so much thought went into gio/gvfs but this thing is pretty basic for people with dual boot :/
[12:44] <kklimonda> (that's actually how I've found out about it - by testing windows 7 ;) )
[12:45] <chrisccoulson> well, maybe i should invest some time to try and figure out how that could work
[12:45] <chrisccoulson> anyway, i'll have a look at your transmission update later. i'm taking my daughter out shopping now :)
[12:45] <kklimonda> chrisccoulson, and is there any automount built-in into GNOME so people don't have to mess with /etc/fstab ?
[12:45] <kklimonda> sure
[12:45] <chrisccoulson> the update looks fairly trivial :)
[12:45] <kklimonda> it is
[12:46] <chrisccoulson> kklimonda - no, there is no way of automatically mounting stuff in GNOME when you log in, without editting /etc/fstab
[12:46] <kklimonda> I was afraid of that :/
[12:46] <chrisccoulson> but it has been discussed before that dk-disks (or now, udisks) may grow a D-Bus API in the future for editting /etc/fstab
[12:46] <chrisccoulson> which will then make it possible to do this from graphical front-ends
[12:47] <chrisccoulson> so, it may happen one day ;)
[12:47] <kklimonda> I guess we need something like this anyway - not all apps are going to be ported to gvfs/gio anyway :/
[23:36] <chrisccoulson> kklimonda, i'll sponsor your transmission update now :)