That’s already possible in our current CVS setup! It’s possible to create real CVS branches within our “branch” directories. We’ve done it for our early KDE 4 work, for example. But the main problem is that this won’t give you a build target in Koji to actually build your experimental specfiles and git won’t help there at all. Those build targets have to be created by rel-eng and they’re quite costly (extra newRepo tasks running all the time), so they’ll only be created when really needed.

Pedantic note: it’s $3.25, and it’s for two hours of access to the entire system (as many rides as you like within two hours), which isn’t really bad. Trying to run a more granular system lands you with a lot of overhead, which is why most systems don’t do it this days. Regular riders use weekly or monthly passes anyway.

Vancouver’s $2.50 for 90 minutes, so pretty similar. Overall I prefer this to the old-fashioned seventy different fares for specific journeys on each route, it’s just more efficient in the end.

Yes, sure, compositing is the future. But when I’m low on power and need the extra 10 minutes (or am on a 6 hour trip and get an extra hour from full battery) I would get from suspending compositing, there is *no way* to do it without dropping out of gnome-shell. That is my main complaint about it. Windows gets it wrong there too I imagine, but I won’t touch that at all to test first hand.

Yes, it is being heavily developed. What better time to give your thoughts about it? After it’s stable, things won’t change until the next version, bugfix release if you’re lucky.

I do plan on continuing this, but other things have kept me in my KDE install since the last post (projects that have everything set up there for instance), so I haven’t been able to get more data to post with.

I have been using GNOME on Gentoo for a year and I did try KDE4. It was on my system for 1 week, then it was removed. Too bloated, too much eye candy. KDE = bloated with bells and whistles. GNOME = Simple and does what it says on the label. The peeps at GNOME-shell could produce a system that is almost exact to KDE and all the “die hard” KDE users would STILL slate it. AFAIAC it’s a no-win situ for GNOME developers.

Why are we moaning about the transition to 3D Hardware acceleration?
Erm….Vista anyone? Erm…..7 anyone? It seems to me this IS the way forward in computing, and there will be NO turning back. Embrace the future like you embraced KDE4 from KDE3.

What I find totally annoying is the negative posts with regards to GNOME 3 – erm, like you didn’t already know it IS being developed and improved as we speak.

C’mon guys – give them a break.
Gentoo + GNOME = Blazing Bliss

As for the 6pt thing, I usually use 8 for normal text and 6 for small (but for some sites, ctrl++ is needed because they *are* just a blur), but it looks the same as 6pt (visually) with the nvidia driver. No matter which way is correct, there is a difference between nvidia and nouveau and I’m just going to blame nvidia since nouveau looks right to me. At DejaVu Sans 8pt ‘8′, I used a ruler to compare.

Intel (GMA X4500HD):
2.5mm (round about)
nvidia (NVS Quadro 140M)
3.0mm (right on the line)

The odd thing is at 128pt, the bold DejaVu ‘c’ was 1in on the laptop and 1-3/32in on the desktop. Why they switch which is larger, I don’t know.

Since Linux apps use pt as font size unit (even if it is not displayed), and pt is a unit with physical meaning, linked to inches, when dpi increases you need more pixels in a char to make the same pt size.

You’re very lucky to have eyes good enough to read 6pt text, most people can not be comfortable with it.

Anyway your problem is not the 129 dpi, your problem is the people that wrote the size selector didn’t think people with such good eyes as yours exist, so you should open a bug so they stop clamping font sizes at 6pt.

Alternatively if you want a specific pixel size you should open another bug to allow specifying font sizes in pixels and not only in points (a lot of users *really* want them in points so hijacking the pt unit to make it a bastadised pixel unit is no option). Faking dpi to make a pt size translate to a particular pixel value may be what you’re used to, but what you really want is to specify pixel sizes to get pixel sizes (duh)

And faking dpi has the side-effect of making all sizes in your desktop unreliable.

This is quite a high priority before g-s can be shipped.

what using the ‘correct’ DPI setting does is means that the characters are the officially-correct physical size. there’s actually a standard that defines how big, in real-world physical units, any font point size should be, it’s not an arbitrary number. If you use the correct DPI setting for your monitor, fonts are those sizes. Many people tend to find those sizes ‘too big’, because people have been used to using the Windows-alike 96dpi on screens which are actually higher resolution than that for a while. No-one’s going to arrest you if you use the ‘wrong’ DPI setting, but there is a method behind the madness.

the abrt dialog bug has been fixed, I think at least.

Personally I suspect gnome-shell won’t go out to the world at large if it requires a closed source driver on NVIDIA. I guess some kind of software implementation will be done. That’s just me guessing, though. I may be entirely wrong.

@Alexander
Ah, thanks, didn’t know that. Still don’t like having to hit a key for that.

Some comments on the gnome-shell-devel list and desktop-devel-list have brought up the 3D support. The developers are clear that Clutter provides many capabilities (for example, animation and transition) that stock GTK doesn’t have, and they’re not interested in developing a crippled version of the interface. [Yes, Qt has this stuff even without 3D. But GNOME is not built on Qt.]

The general sentiment was that for GNOME to continue to evolve, eventually it must be able to take advantage of new hardware by default, so they are sleeping relatively well over this decision.

After all, OS X wasn’t designed by focusing on the lowest-denominator hardware platform. [Then again OS X has a -standard- hardware platform, but you can't deny that it's a worthy target for desktop polish comparison.]

(Note: I don’t necessary agree with all of this, but in general, if GNOME Shell fails, “forcing you to use 3D” will not be the reason why.)

People need to get used to change font sizes when they need to change font sizes. dpi is not a font size setting. Resolution is not a font size setting. Font size preferences, are, strangely enough, the correct way to specify your preferred font sizes

(and before you claim everyone wants 96dpi you can find on the net advice dating from back when someone had the stupid idea to use 96dpi by default. It says: if your fonts have the wrong size under Linux, lower your screen resolution to 1024*768. Like you the writer was convinced changing font sizes should not be done via the font size preferences).

I’m not sure GNOME 3.0 would go out with gnome-shell not working without 3D acceleration, but I’m not really an insider on that story so it’s just my guess.

The thing that shouts out at me the loudest is the Gnome Team developing a desktop environment that REQUIRES hardware video acceleration! I just can’t believe it!

If what ends up being Gnome 3 requires hardware video acceleration… I’m going to have to deal with all those older machines that I installed Fedora on for family and friends. And my own laptops.

I realize that hardware video acceleration does not necessarily mean a separate video card and also includes IGP graphics chips. But there just isn’t linux drivers ( open or closed ) for many many older ( read a few years old ) IGP’s! and there never will be. Should we all just chuck our 2003 notebooks?

the ’safely remove’ / ‘eject’ thing is one that’s been baffling me lately. Only one of those used to be present for USB drives, and I’m baffled as to why GNOME these days presents both. I have no idea what the heck the difference between them is supposed to be, if anything. It smells like simply a bug to me.

for your advanced window managing needs, it smells like you may want to poke at the preferences that are hidden in gconf, and also perhaps play with devil’s pie: http://burtonini.com/blog/computers/devilspie/ (yes, it’s packaged…there’s a graphical frontend called gdevilspie, also).

I’m going to pass your threads on to the Desktop mailing list to make sure they’re reading them, seems like something they may be interested in.

There’s a yakuake-type thing for GNOME (actually I don’t know which came first) – guake . yum install guake . I’ve no idea if it’s any good or if it even works as I don’t use it (I use multiple tabs in gnome-terminal and keep a gnome-terminal window open the whole time, myself).

The mixer should show an icon in the notification area by default, an obviously sound-ish one. You can mute with a right-click on it. If you didn’t see it you probably had deeper audio issues going on.

You don’t have to install the NVIDIA driver manually if the kernel doesn’t match what rpmfusion has, you can use the akmod package, which works much like DKMS – if there’s no module yet built for the kernel you’re running, it builds one automatically (the implementation is very different from DKMS, but the effect is similar). You may have to futz about with dependencies and possibly use –nodeps to make the deps happy, but it’ll work, and it’s much better than using the upstream installer, which won’t survive a kernel update and can easily leave your X files screwed up if you remove it messily or switch to nouveau without removing it or anything. You don’t need to rebuild initrd for the nouveau issue, just blacklist nouveau with a /etc/modprobe.d file . The rpmfusion package takes care of this for you.

As for gnome-do, the little bit of playing around with it has so far found out that it is not KRunner either. Maybe it’s just first impressions, but it does beat the alt+f2 tool GNOME has by default.