This Gnome 2.3.3 release is a feature-frozen, development series snapshot. It is used by developers and testers as their day-to-day working desktop, and is ready for wider testing by our user community. Full changelog here.
This Gnome 2.3.3 release is a feature-frozen, development series snapshot. It is used by developers and testers as their day-to-day working desktop, and is ready for wider testing by our user community. Full changelog here.
I’v noticed lots of HIG updates in their ChangeLog and some Ximian patches. Anybody care to do a review?
I recently used GAIM and have found that their compliance to the GNOME HIG does improve the usability and integration of an app in the GNOME environment.
-magg
I realize that this is not strictly a GNOME problem, but the feature I’d like best is for GDM to not lock up while logging in a non-root user on FreeBSD 4.8/5.1.
BTW, anyone have any helpful hints here? This particular topic doesn’t seem to have much documentation on the FreeBSD or GNOME web sites.
where i can find binaries for testing?
If this is to become 2.4, will gedit finally have syntax highlighting?
Any speed improvements? (Moving to 2.6 kernel in the future can only do so much).
Yes Gedit will have syntax highlighting. It’s still the case in the last 2.3.x versions.
> Any speed improvements?
I read about speed improvements for nautilius and one other thing .. but not of gnome in general. Speed is really a very important part of useability. Let’s home there’d be some good news in that area.
Have you tried Ximian Gnome already its seems to be
faster and less bloated. OpenOffice (Ximian version) also responds more quickly and the default browser has become Galeon.
What I find strange is the adoption of epiphany as standard browser, while Ximian seems to have chosen for Galeon. I know this has been debated before, but still it feels like galeon gets dumped hard, while in my opinion it doesn’t deserve it, because epiphany isn’t any better at anything.
But in general: why can I pick between so many browsers and not one decent gtk2 audioplayer ?
I mean, rhythmbox is NOT a decent player. Xmms does not skip, while RB will skip, if you just resize a window or open a heavy app. It will crash every 10 minutes and is simply not robust. Furthermore, it seems development is dead on RB, with the maintainer having stepped down.
So when is this audioplayer thing going to happen or do I have to stick with xmms for two or three more years, just like this crazy file-dialog-thing- that-stayed-the-same-for-12-years-why-should-we-innovate ?
I know you asked for an audio player, but if what you’re looking for is simply an mp3/ogg vorbis player, I have something you might enjoy.
I recently found this by accident, and find it to be just what I’ve been looking for…
Hope this takes your headaches away…
http://liteamp.kldp.net/
What is wrong with using XMMS under Gnome?
You could write a gtk2 client yourself that uses
mpg123 or another engine..its not that hard!
Well, about those problems with rhythmbox, it’s an application still being developed. But net-rhythmbox (latest version with latest version of gstreamer) seems to work pretty well (at least the only crash reports it has are related to internet radio).
Totem is able to play audio files, too (the ones supported by gstreamer).
Anyway, gstreamer is the multimedia framework of gnome. Unstability in multimedia apps could mean you are using a gstreamer release with bugs in it, that’s why you should always use the latest version.
I’ve been running 2.3.3 now for awhile and there aren’t anything magical about it, some nice looong awaited Nautilus fixes etc but nothing huge, it still have a looong way to go but I’m staying with Gnome cause I think it’s going in the right direction.
Tree browsing is still a mess (for many, that’s a big issue), file-roller actually made itself slower to use again by removing “Extract to folder”, which I used frequently to avoid having to dig around in some slow GUI, and why can’t it show real progress like any normal unpacker while unpacking? Instead it shows the sliding back-and-forth type progressbar for computations with unknown length.
Tiny issues like this all over, not enough to make me switch to KDE but surely enough to make my desktop feel like most people say, not alot more advanced then something between Windows 3.11 and Windows 95.
file-roller actually made itself slower to use again by removing “Extract to folder”
Are you saying this feature is removed. That is my favourite feature too, it is way faster than using the programs GUI!
>> Have you tried Ximian Gnome already its seems to be
faster and less bloated.
>>
Yeah .. that’s what I’m running here. The menu somewhat cleaner, but there speed difference on my machine isn’t noticeable.
try using gxine or totem. they’re intended mainly as movie players, but they work fine as audio players.
Noatun is great too…oops!
/me ducks
I’m wondering… is the “Extract to…” option still there in the Nautilus context menu?
The changelog states:
“Removed “Extract Here” and “Extract in a Folder” from the Nautilus context menu.”
I really need to know the justification for this. This is one of my most used features.
-G
Fileroller : you can use a nautilus script for “extract-to-folder” instead of fileroller, it’s much easier ( http://g-scripts.sourceforge.net/index.html#archiving )
Musicplayer : Zinf ( http://www.zinf.org ), formerly Freeamp, it’s not gtk2 but it’s pretty good. Never skips on me (not under windows,freebsd OR linux)
I didn’t know about the scripts options in Nautilus but looks like something powerful.
When 2.0 came out I remember there was alot of talk about things things
we had to wait till 2.4 or 2.6 to have. What are some big things we’re waiting for?
was it translucentcy or new dialog boxes? blah i cant remember.
> I realize that this is not strictly a GNOME problem, but the
> feature I’d like best is for GDM to not lock up while
> logging in a non-root user on FreeBSD 4.8/5.1.
>
> BTW, anyone have any helpful hints here? This particular
> topic doesn’t seem to have much documentation on the FreeBSD
> or GNOME web sites.
Yes, try wdm (WING display manager?). It is available in /usr/ports/x11/wdm. It works out of the box with most windows managers as it auto-recognises common ones like GNOME, WindowMaker, Blackbox, .etc (oh, sorry KDE ) and includes other important features that xdm lacks such as the ability to SHUTDOWN and RESTART without resorting to the command line.
It’s been ages since I’ve used WDM or any graphical login manager for that matter (text is soo much more elegant) so forgive me if i’ve slightly miss-quoted anything.
I cannot think how anything could be simpler than right clicking and choosing ‘extract here’.
It is all about defaults people!!!
So if they removed file roller most useful feature what is the default instead.
Also I don’t want to have to add this by a script. I thought GNOME was trying to make it their DE easier than KDE.
KDE archiver has “Extract to here” which is stupid because the files populate a whole folder eg. home folder, that sucks.
Please tell me that is not GNOME’s default too.
First, I gotta congratulate the GNOME guys. The new HIG is awesome. The apps which are HIG complient are very usable — reminds me a lot of BeOS apps in fact. On the other hand, GNOME still feels slower than KDE. I think it might just be on my system though, because a lot of people have the exact opposite experience. I’m thinking the two desktops exercise machines differently — KDE is more CPU bound while GNOME is more disk bound. That might explain why KDE runs faster on my machine (laptop, so fast CPU paired with relatively slow hard-drive) while GNOME runs faster on other machines. Anybody care to chime in with their experience?
The “Extract To” item is still there, which brings up the file-roller extract dialog which more often then not requres one or two options to be changed (they aren’t saved from session to session).
The “Extract to Folder” was a real gem and I don’t know why they removed it, simplicity is going overboard if that was the reason behind it’s removal. I used those naut scripts before and they were awsome just they didn’t give any real indication of progress, then again, file-roller doesn’t do that either so thanks for the script tip Tyr, I’m switching back to them.
>>KDE archiver has “Extract to here” which is stupid because the files populate a whole folder eg. home folder, that sucks.<<
KDE archiever has “Extract Here..” option which then ask “extract to folder..” pointing at curent folder. If you just click OK it will create a folder with the file name. Of course you can add/change folder, just click the folder button. Preference button also provided. What else do you need?
Is the new Gnome going to ship with a menu editor?
I didn’t know about these scripts, they’re really cool. But why does it put a “Scripts” submenu on the popup menu? I mean, a user should not need to know what a “script” is. There’s no need for the “scripts” submenu, IMO.
Victor.
I don’t know if the reasons are as you stated but my experience with kde is the same as yours. Without installing the gnome package, konquer is as fast as windows but yet I keep hearing how great gnome is (which was not my experienc). Mandrake 9.1 is what I got on a dual 733 p3 and 450 p3 computers.
Rhythmbox isn’t dead it’s just sleeping. It has a new maintainer who will be hacking on it again soon and HEAD is actually not that bad. A lot of the problems it has had in the past were gstreamer problems so as gstreamer matures so will rb. Also the new X sound server should be pretty helpful for rb and all sound apps.
As for speed – nautilus is _a lot_ faster and gconf speed is being worked on. There have also been some improvents thqt mqke the whole thing snappier.
There really is a lot new in 2.4 – a web browser and media player are no small aditions – not to mention all the a1y modules.
Is the new Gnome going to ship with a menu editor?
That is indeed an excelent question!
Another question: have they put an easy way of changing the default language?
The best feature of Nautilus to me is the Nautilus scripts. Honestly, I use these scripts on a day to day basis.
Graphic conversion scripts to change around image files from one kind to another. ps2pdf and pdf2ps scripts are very helpful and the scp scripts I use almost daily. I converted my mp3s to ogg using the Naudilus script. The ability to easily wrap commonly used command line utilites for use by the graphical file manager is a great idea. dos2unix and other scripts are real time savers for me.
It’s a little buggy (you can’t create items directly), but I’ve always used starthere:// to edit my menus… you need to create the .desktop somewhere else, and then copy it into where you want it on the menu, but it kinda works.
What is wrong with rightclicking on the menus to edit them?
Example:
Click: Applications->Accessories.
Rightclick on Text Editor. A popup menu will show up which gives you the option to edit or remove the item, or add new items to the menu.
There, it’s so simple. And it’s been there since 2.0.5 or something. Why can’t anybody find it?
What is wrong with rightclicking on the menus to edit them?
Because it isn’t a centralized program to manipulate
You can’t “move” items, renaming folders is impossible from what I remember.
There is a need for a program or a directory structure similar to M$
>I really need to know the justification for this. This is one of my most used features.
I think I have something to do with this.. ๐
Read June’s Nautilus mail archives and seek my emails and its replies. You will see that we discuss there things.
Oh, and GMlogo, you will like the new plan better. ๐
We discuss it to make Nautilus support Tracker style addons on a submenu or an Actions menu. This is why these additional menus were removed from the root context menu. It had to be put in an order, along with more addons in the future (we had to avoid the clutter of KDE and Windows’s context menus with apps adding menu items there without asking you
I like that.
And now Im using scripts and I must say they are better and can do more things.
I don’t really recall any mails from that thread you started, Eugenia, which has had any impact on this. As far as I remember you were told repeatedly that the existing API in Nautilus does exactly what you were calling for. I have to say, I got quite a good giggle when I read the thread. You insisting on implementing “Addons” time and again after the developers told you the code already existed, it just isn’t called “Addons”. To be honest I think you wasted more developer time than you benefited the project by you endless referring to BeOS and Tracker. But ok, so do I probably whenever it is bug day ( http://developer.gnome.org/projects/bugsquad/triage/faq.html#II )
About avoiding clutter… I definitely agree that file-roller sitting permanently in the top-level context menu was bad. I think the current solution is about as good as you can get.
If this is what you think, then, you can’t read correctly my emails there either.
Just looking back in my mailbox I see about a dozen mails from various Gnome developers trying to explain that what you ask for is what the MIME component handlers already do.
One of them even wrote example code to demonstrate how easy it is.
Nothing new there…
Aha, interesting. You wrote nautilus-list and I read desktop-devel. My bad, I’m sorry. But the thread on desktop-devel still made me giggle ๐
All i want in Gnome 2.4.0 is a good menu editor app/applet.
This is not too much to ask for!
Adding an app with nautilus just isn’t the best way, it just
feels like a quick fix.
Gconf dose not help.
And editing xml files is daft.
I’m using Gnome 2.2.x on Redhat 9. And the lack of Gnome-menu-editor is the only let down.
Come on developers make the Gnome-menu-editor.
anyone … ?
Yes, 3rd time lucky – the new menu spec should be the golden one, and gnome 2.4 will have menu editing support.
To those who wonder why some people experience GNOME as faster while other experience KDE as faster… This is most certainly because there are so many things that can be “fast”.
Startup time of the DE, startup time of applications, moving and resizing windows, the file manager, slowdowns due to low RAM, etc. My experience always was that GNOME is ahead in a few areas and KDE is ahead in other areas. All in all, I don’t think they are far away from each other in terms of performance. You also have to consider that they have different featuresets.
In general though, it was always my impression that GNOME is a bit lighter on ressources, while KDE is a bit faster for certain operations (like moving windows) when there are plenty of ressources. Then again, KWin doesn’t have (many) themes as scalable as Metacity, you see?
I definitely hope that Metacity becomes smoother in the future though. Comparing it to XFWM makes me shed tears, but XFWM lacks other important features and scalable themes.
> KWin doesn’t have (many) themes as scalable as Metacity
Excuse my ignorance, but what are “scalable” themes?
Excuse my ignorance, but what are “scalable” themes?
Those which aren’t build of fixed pixmaps but can scale larger or smaller depending on your font size. This way you can choose your favorite size for your resolution. Since I run 1600×1200, this is a must have feature for me.
KWin has only two styles (that I know) which can do this, and those are the Web style and the RiscOS style.
Most good Metacity themes are made up of barely anything but drawing operations, this makes them very flexible and dynamic.
“All i want in Gnome 2.4.0 is a good menu editor app/applet.
This is not too much to ask for!
Adding an app with nautilus just isn’t the best way, it just
feels like a quick fix.
Gconf dose not help.
And editing xml files is daft.
I’m using Gnome 2.2.x on Redhat 9. And the lack of Gnome-menu-editor is the only let down.
Come on developers make the Gnome-menu-editor. ”
This is a RH problem – apparently it breaks on some some systems (think is a KDE interaction thing), so RH disabled it.
You can re-enable it by looking for a file in /etc/gnome-vfs2 which says something like ” with menu editing” and replace the original file with it.
Menu editing has worked via the menu or in nautilus, since stock gnome 2.0.2