Around the Planet

stalin - An extremely aggressive Scheme compiler =)

What may not be very apparent is this: the hostname-nomenklature. Each machine of mine has a hostname that corresponds with the name of a former Soviet Premier or General Secretary (e.g., mobile: Gorbachev; PDA: Khrushchev; iMac: Brezhnev; current machine: Stalin). I just did this for the sake of consistency.

Yes, I will admit that the hostname of Stalin probably comes across poorly without justification; but like the real Iosif Stalin, this machine has been very problematic in so far as it frequently mass-murders its own hardware and data stored within itself (e.g., four harddisk replacements; complete motherboard, CPU, and RAM replacement all within the last two years).

That explains a lot, thanks. Good luck with the poor bastard:)

I did not mean to keep this anonymous; Epiphany forgot my session information.

There's not much point in unifying the UI of, say, the CD player and Cupid, but you have a good point. PiTiVi (the video editor) could, for example, make well use of Cupid's capture backend. Also, Rhythmbox could make well use of some specific tag editing software, which might then again be available separately as well (maybe as nautilus plugin). Rhythmbox Cupid could then be bundled together in a media package, as part of fifth toe (Totem is expected to be accepted in the desktop package).

I think this should be done on a case-by-case basis. There's no point in forcing people to do it, or trying to make one big media UI library that rules them all (imo, that is). I've talked to the PiTiVi people and they currently share code (both integrated in their own tree, though) for capturing.

As for UI integration between the different applications, well, that is what the HIG should do. But some diversity isn't bad. :).

This framework is GStreamer, and all your examples use GStreamer :)

The problem is also in UI integration

http://gnomedesktop.org/node/1478
http://www.pycage.de/software_expocity.html
When it will be in official GNOME is what i don't know...

The expocity homepage is outdated. I read in some old thread that x-expose was the way to go since it utilizes the new X.org extensions (which expocity doesn't).

Link to old thread here

not only is it sweet looking but it is functionaly superior!

Is itme or it is just REALLY slow ? It seems like when hitting the key-combio it firsthas to rasie all windows one per one to make screenshots and after that it shows them in expocity-style :|.

---
http://gnometux.blogspot.com Gnome: T.U.X. - The User's eXperience

contrarily to the real expose, expocity is a hack. It doesn't have the framework nor the streamlining required to make this efficient (yet). But as a user standpoint I have to agree that a functionning Expose is worth a lot in saved time and speeding up switching.

Well, framework exist in Xorg and it's called Composite extension. The very same thing that allows really transparent windows and shadows.
And it is used for Expose-like functions - check Skippy-xd. It is prety fast, don't have to screenshot each window, and thumbnailed windows are live!

--
:wq

If Skippy doesnt work giving you
WARNING: Couldn't load config file '/home/XXX/.skippyrc'.
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 33 (X_GrabKey)
Serial number of failed request: 93
Current serial number in output stream: 93

Try changing F11 to F6 or something else. It kinda sucks that it has to raise all windows.. but its ok. And us debian users cant use Xorg (I compiled it before.. ) thanks to that stupid sarge..

If I understand coorectly XDamage and XComposite requires 3D acceleration? Wouldn't it be a hardcore requirement to have working 3d acceleration on a Linux box?

Don't get me wrong... I am drooling here :)

You got completly wrong information. XRedner and XComposite have nothing to do with 3D! XDamage is an extension which informs applications what regions (regions, the 2d shapes) of window have been modified.
XComposite allows ,,composing'' (nice word for drawing) window and gives possibility to compose given rectangles (windows) with some finesse ways - hence transparency. No 3D involved.

Hmm, I see where you can got wrong impression. XComposite uses RENDER extension. Well, RENDER is a modern way to draw shapes. For example, antialiased text is drew using RENDER. Maybe because ,,rendering'' almost always means ,,creating 3D image'' you got confused. But look into your Latin dictionary what ,,render'' means :)

To reiterate: there's no 3D involved with those extensions. (beware: I'm not X11 expert).

On interesting sidenote: incoming OS from some big company, dubbed Longhorn, will *require* 3D card. And not some simple 3D, but unit with Pixel Shader 2.0 !!
I'm happy that my Matrox G550 is perfectly supported under Free OSes. I don't care it doesn't have any shader units. Within two years it would work even better with Free Desktops, whereas with commercial software it won't even booting OS!

--
:wq

Ok. I think I understand. I am 100% sure, though, that I read some (obscure) place on the net that you needed 3d accel. for this.

To completely clarify this misunderstanding; the answer to the question: "Do I need working 3d-accel. for XCOMP.+RENDER+XDAM.?", would be "no", yes? (pun definitely intended)

EDIT: About Longhorn... If the answer to my above question was "no", then I strongly suggest utilizing them in GNOME 3.0 (no, I don't mean 2.*)

If you don't have 3D acceleration, you don't use XDamage nor XComposite. I wouldn't call it a hardcore requirement. It's like Doom 3: if you don't have a good 3D card (like me), you don't get to play (like me).

What I meant was that Skippy probably never would be default in any distro or ship with GNOME, since a working 3d card is a bit more than you can expect from average Joe User (ATM).

Thinking more about this...

Gnome 3.0 is due approx 2 years I read somewhere on live.gnome.org (very unofficial ofcourse) It might be reasonable to expect hardware acceleration across the board in two years..?

Would be nice anyways :)

You read wrong. Someone took a guess that it'd be a two year project once people decide to work on it. Gnome 3.0 hasn't been started at all, and the starting point isn't even planned. All that has happened so far is to have a few ideas thrown out for what some possible goals for such a thing might be.

Yes. I see now. Let's make it |x| + 2 years from now for some real x. :)

maybe a good module to propose to gnome3.0?

2.6.10, not 3.0.

i obviously got confused there. I meant 2.10; after 2.8 (stable) comes 2.9 (devel) comes 2.10 (stable).

2, 4, 6, 8, 10, 12, 14 etc

release.major.minor.

Thanks to explanation, I already know this, but I said 3.0 cause It seems to be next step after 2.10. They will break compatibility with 2.x series, as done in 1.x -> 2.x transition. Or am I wrong? I'm not sure.

EdCrypt

time when they decide to change to 3.0 does not depend on how many binary-compatible releases they done before that. it depends only on one thing - when number of proposed features that will break binary compatibility reaches some critical mass.

Hum... BTW, they are making some plans:
http://live.gnome.org/ThreePointZero

Its 2.12, followed by 2.14, 2.16, and 2.18. Its possible that if we get to 2.20 without breaking binary compatability, they'll drop the leading number as superflous.