Deskbar is an applet which sits in the GNOME panel and which integrates quite seamlessly with different search tools like Beagle and the Google search API to bring the same functionality of OSX’s Spotlight to Linux/GNOME. This article explains how one can set up this applet to among other things, provide Google web search on the Linux/GNOME desktop. In related news, this article takes a look at the major new features of… Gedit 2.14. No kidding.
“Network transparency
Gedit can now open remote files, edit them and save them back through network, as if it were located on your own hard disk. Don’t bother anymore to copy those files from your server, or, worse, to use Vim on SSH: just open, edit, and save!”
That’s nice. KDE has had this for years, in all KDE apps.
“The new plugin system allows anybody to write quickly new plugins using Python.”
Python, eh? What happened to the love affair with Mono?
Granted, I don’t use GNOME, I’m sure similar things can be said for KDE apps, and there are some nice features in there. Still, I found those two a bit funny.
“That’s nice. KDE has had this for years, in all KDE apps. ”
No, it doesn’t. It has this in all KDE apps that use kioslaves, and GNOME has had this for years in all apps that use gnome-vfs. Now GEdit uses gnome-vfs.
“Python, eh? What happened to the love affair with Mono? ”
GNOME supports two languages in the desktop set, C and Python. You have no idea what you’re talking about.
No, it doesn’t. It has this in all KDE apps that use kioslaves, and GNOME has had this for years in all apps that use gnome-vfs. Now GEdit uses gnome-vfs.
Does that mean that ALL applications that cannot open and/or edit remote files are not using gnome-vfs? If that is the case, then why aren’t they using it? Even if it’s merely a compilation option. It’s one of those things that really grinds my gears with GNOME, especially since I do the majority of my work on remote computers… It’s not flawless on KDE (especially media players), but it generally got better support.
You’d have to find an application that doesn’t use gnome-vfs and ask their developers about it.
Won’t be that hard… Unless it changed recently, many media players like Rhythmbox and Totem didn’t. Neither Quod Libet, but I guess it doesn’t count. Same thing for EOG or the other image viewer included in Ubuntu supporting slideshows (don’t remember its name and I’m not in front of a GNOME system) didn’t either.
That said, the new Gedit looks nice. “Don’t bother anymore to copy those files from your server, or, worse, to use Vim on SSH”, heh, I’m doing the latter right not… It’s not that bad, but copy/paste between files is a pain. The little editor is getting a bit fat, but as long as it’s useful, I won’t complaint…
Rhythmbox gained remote gnome-vfs support in 0.9.3. Adding support to applications isn’t trivial, because there are usually assumptions through the code that no longer hold – but it can be done, if someone is serious about doing it.
Adding support to Gedit would probably have been much harder than for many other applications. Gedit saves backup files in case the save fails – but that won’t work if you only have write access to the file, not the directory it is in. Different underlying protocols may support different things, which means “better” ways of doing things may not work with everything. There are a lot of corner-cases to cover.
guess then that’s the real difference between KDE and Gnome – to get a Gnome app barely usable, you’ll have to go lots of work, while a KDE app can be written to have network transparancy, the same toolbars like in all apps, a toolbar editor, fully configurable shortcuts etc etc etc almost without any effort..
Does that mean that ALL applications that cannot open and/or edit remote files are not using gnome-vfs?
basically: yep.
If that is the case, then why aren’t they using it?
because gnome-vfs it’s not the simpliest library of the platform.
Even if it’s merely a compilation option.
come on, if it were just a compilation option it would have been really easy to add support.
fact is, using gnome-vfs the right way (that is, using the asynchronous stuff) is not that easy; it’s a bit lacking on the documentation and tutorials.
by the way, gedit now fully uses it, and the code is really clean, so anyone wanting to develop an application with vfs support should have a look at gedit’s sources.
No, it doesn’t. It has this in all KDE apps that use kioslaves, and GNOME has had this for years in all apps that use gnome-vfs. Now GEdit uses gnome-vfs.
That’s not entirely accurate. gEdit was able to open files through gnome-vfs. For some reason, most likely a good one, gEdit did not allow people to save files through gnome-vfs.
No, it doesn’t. It has this in all KDE apps that use kioslaves…
People who say this don’t have too much idea of how KDE works. If you write a KDE application it will support KIO without you doing absolutely anything or having to write code or support it in any way.
As a result, all KDE apps support KIO and use it.
Edited 2006-02-28 10:53
> As a result, all KDE apps support KIO and use it.
I think you’re missing what’s being said. If your KDE app uses POSIX’s fopen() instead of the KDE file open methods, your app won’t magically use KIO for file access. You have to do things “the KDE way” to get “the KDE benefit automatically”. The same is true with GEdit. They’re now doing things “The GNOME way” and as a result get “the GNOME benefit automatically”.
I think you’re missing what’s being said.
No.
If your KDE app uses POSIX’s fopen() instead of the KDE file open methods, your app won’t magically use KIO for file access.
You could, but the point is that your KDE app is built on a real framework that gives you all that for free. If you don’t use what’s in kdelibs then it isn’t a KDE application.
You could, but the point is that your KDE app is built on a real framework that gives you all that for free.
this is also true for Gnome, and gnome-vfs. while the rules for what technology the Gnome applications should use are a bit more “relaxed”, gnome-vfs has been part of the platform for a while; it’s up to the developers to decide whether to use it or not – for the common, local case, gnome-vfs might indeed be overkill, and the asynchronous stuff is a bit convoluted and under-documented.
GNOME supports two languages in the desktop set, C and Python.
nope. the languages supported in the desktop set are the same as the platform bindings set, that is: perl, python, c++ and java.
any application written using one of these bindings is eligible for entering the desktop platform. if not, the bindings used must be added to the bindings platform first; plus, the language bindings must adhere to the release rules (api/abi freezes, six months release cycles, etc) too.
Python, eh? What happened to the love affair with Mono?
Gnome doesn’t have a love affair with mono. Novell/Ximian does. In fact there is no part of official gnome that uses mono. Redhat loves python and redhat has also contributed a lot to gnome.
Yawn… Yet another “X has had Y for years” comment, how interesting. This is about what’s new in gedit, not why gedit is superior to everything else. I don’t think there is any feature in gedit (or kate for that matter) that isn’t available in many other text editors as well.
Regarding your second comment, Python is and has always been the favorite scripting language among the GNOME community. Mono serves a very different purpose and there is more than enough room for both.
I wish the Gnome community would stay far away from Mono. That is just a big problem waiting to happen.
Deskbar applet is one of the really sexy little things that make gnome shine. I start typing into it and have live google query results displayed. The same can be said for the new Gedit’s CTRL K find as you type search. It’s these little features and polish that make me choose gnome. I guess the devs have been focusing on software that gets their users laid, way to go!
http://many.corante.com/archives/2005/02/16/social_software_stuff_t…
After trying out Deskbar applet, I found it really interesting to use it. Just type in some words or phrases and – provided you have beagle installed – you get a collection of files which contain the words. I think the philosophy of integration between different applications bodes well for the future of the Gnome desktop.
As far as GEdit is concerned, the new features are quite an improvement but the developers should not be including the features at the cost of higher memory usage by the editor. I believe, the initial goal of gedit was to be a windows Notepad alternative for linux.
…gedit looks sexy
Don’t bother anymore to copy those files from your server, or, worse, to use Vim on SSH…
Worse?? Man, I hate non-command-line-editor people…
From the article:
First of all, the new gedit is faster than the old one. Way faster. Not only it starts up in less time, but loading of local files is almost instantaneous, even for bigger files, thanks to the use of mmap
At last Gedit is a great little Editor, but so slow to load. It takes almost as long as loading a full word processor like Abiword.
Edited 2006-02-28 13:13
At last Gedit is a great little Editor, but so slow to load. It takes almost as long as loading a full word processor like Abiword.
Yeah, true. Then again, gedit is not just another notepad.exe, It offers much more than just that. I’m completely happy with its new and really simple plugin system and simplicity in whole. Now, if I can figure it out how to move around and set line position from plugin, that would be a gift for me.
I don’t know why, it is not anything better than others, in fact it lacked compared to them. But somehow I like this damn editor very much (yeah, I don’t understand why, either).
p.s. I tried it recently on dapper (using ancient 733MHz that I had to set up for my friend). And all I can say desktop flies on dapper, breezy on my X2 just doesn’t feel so breezy anymore. Gedit just pops up in a second with all plugins enabled.
true, but there are texteditors that offer more than gedit does, while still being faster and lighter on memory…
Does this version have code-folding, the one feature that forces me to use Kate instead for large programs.
Also, from the looks of the screenshots the syntax-highlighting is printable – the print preview certainly shows blue bits, is this true, or is the preview not really WYSIWYG?