Skip navigation.

Around the Planet

PlanetGNOME
PlanetGNOME

Happenings from the past week broadcast on PlanetGNOME...

Rodney Dawes shows a new VU Meter widget he has written as well as an idea for an IM contact list as well as some other mockups.

Jordi Mallach talks about the recent GNOME Hispano meeting.

Michael Meeks releases a new version of ooo-build, a system that makes it considerable easier for the the average person to build OpenOffice.org.

Colin Walters talks about some recent Rhythmbox hacking.

Marc Maurer talks about the upcoming release of AbiWord 2.2 and the attention being given to stability.

Damien Sandras talks about recent GNOME Meeting developments including support for ZeroConf.

Murray Cumming has released a new version of gtkmm.

Ronald Bultje fixes (S)VCD support in GStreamer.

Christopher Blizzard shows of his efforts with mozilla/pango integration.

Bryan Forbes releases another version of Coaster.

Jordi Mallach writes about GNOME 2.8 making it's way into Debian unstable.

Jonathan Blandford has been working on a re-write of the GNOME Screen Shooter utility.

Rodney Dawes shares a mockup for the alarm dialog in Evolution.

Owen Taylor shares some information on his work to add support for rotated text in GDK/GTK.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I read it all before you ...

on planet.gnome.org

=).

Around the Planet

"Around the Planet" is great piece of info,
summarisation I needed

Thanks a lot!

Instant Messenger Updates

Is gaim the instant messenger they are talking about? If so, I can't wait to see some of the changes they have. Gaim is awesome, but there's many things that could make it even more great.

senility

No, this are senility mockups, look at:
http://web.subpop.net/text/gnome/IM.html

Wacky text

That rotated text thing is cool, but the examples look, well, not so good. The text isn't even on a straight line.

Wacky text - looks o.k to me.

I guess you mean the 'Rotated' text string. I guess this is in Italic so it should be slightly slanted anyhow. 'Hello world' and 'me' look fine.

Uhm.. no, they look terrible.

Uhm.. no, they look terrible. For example, look at the two L:s in "Hello".

Rotated text. Good!

Rotated text support in GTK/TDK. This is very useful for schedule labeling!

Can't wait until this is impl

Can't wait until this is implemented in Gnumeric charts! :)

You got that right.

You got that right! =)

Strange no one have thought of this before!

*cough*

You mean, of course, "Too bad nobody (like me) took the time to implement it."

lots of cool stuff

The current evolution alarm is an abomination. The new mockup looks great however.

RB? WTFDIC?

Rotational text looks cool too.

Why does each app need to do so much to include gnome-vfs support? I'm not a gnome-developer but it really seems like all gnome and even gtk apps should just be able to use a set a file access functions provided by gtk that, if available, gets all apps all the gnome-vfs functionality without any extra coding or effort. And a the author of the screenshooter dialog is having to hack a transfer dialog for himself? Again, shouldn't that just come for free with a standard set of gtk/gnome file interaction functions? It sort of sounded like the guy talking about the screenshooter was hacking some of this stuff for generic inclusion in gnome but very often there are items about how this app or that app need to implement vfs support. Seems pretty strange to me.

Technical details

All apps can have a "standard set of /../ file interaction functions", it's called gnome-vfs. By linking to that, you get instant access to everything gnome-vfs can handle by using the methods provided by it.

There is no need to integrate that in GTK+, since you can *choose* if you want it or not by linking to gnome-vfs. Not all apps handles files so forcing everything into GTK wouldn't be a good idea IMHO.

Also, gnome-vfs needs a daemon running for file monitoring and stuff, this isn't something that all GTK+-apps want or need.

Stack

Gnome is a platform and at least all the standard apps in the platform should be Gnome apps. Making gnome-vfs a systemwide requirement is a good idea.

Technical details

Then why doesn't every single gnome app support it? Like I said, I'm not a gnome developer. All I know is that an aweful lot of apps don't do this and that seems strange.

Because it's different

Gnome-VFS isn't particularly harder than standard POSIX file accessing. In many somewhat more advanced ways, it's even easier (think device monitoring, mounting, ...).

However, in programming classes, you will always learn POSIX file accessing, so monkey-see-monkey-do, you use that in your first try as well. Later on, you'll port it to Gnome-VFS. It's not hard, it just needs doing, that's all.

Gnome-VFS really is a piece of art. It definately has bugs and it's somewhat awkward in some ways, but that's all fixeable. I like the general way in which it works.

lame

That is lame. Not pointing any fingers, it just sucks. Don't gnome apps get file handles from the file open dialog? Developers don't do a fopen themselves do they? So I still don't see why people are not all using gnome-vfs by default. Even gtk apps should be *trying* to use gnome-vfs and only falling back to normal file operations if gnome-vfs can't be found.

Like I said, again, I'm not a gnome developer so I could be totally off but I'm imagining a file open situation like:

file_handle = gnome_file_open_dialog(blah blah blah);

Right? So why doesn't this "just work"? I'm seriously curious.

You get a filename

The filechooser only gives you a filename. This is good, since you may not want to open the file (hence the name filechooser and not fileopener ;-))

But I agree that all apps that is targetting GNOME should try to use gnome-vfs for file access. However, there are some things that must be considered when using gnome-vfs. For instance, most applications just fopen("filename") and expect a filedescriptor within a couple of milliseconds. On the other hand, if you're working with remote files, every access to the file may take seconds (even minutes if the server is unavailable). This must be taken into consideration if you don't want long lock-ups in the GUI.

Another point is that not all things are possible on remote files. For instance, you can't seek in some filetypes (meaning that you can't tell it to open file X at position Y and start reading/writing there). This is not a show-stopper, but it's a thing that a developer needs to think of.

This (and perhaps some more things i can't come up with) is why it doesn't "just work"...

keep them coming

I never have time to read planet gnome anymore, so this style of weekly summary is much appreciated. Keep up the good work, stro.

a-men

These are like the Gnome Summaries of olde, but make a lot more sense in this day and age of the blog.

Thanks for taking the time to cull through all the entries and giving us lazy folk the creme of the week.

I would like to say thank you

I would like to say thank you for them as well.

Yes.

Yes yes yes! Please do! =)

Seconded

Planet Gnome is one of the coolest places on the web if you're into this sort of thing, but it can be a little overwhelming at times. After a long day at school I can sometimes come home to 25+ postings! Weekly summaries are definitely appreciated.

Re: keep them coming

Yes. I appreciate the weekly summaries to.