OSNews

Well, I for one think that having file managing functions inside the file selector is bad and wrong.

I've seen so many times people screw up their files making non undoable changes inside a file selector.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.

I've seen so many times people screw up their files making non undoable changes inside a file selector.

I don't think it is a good reason. It is no difference with the file manager. Any users can screw up in file manager either.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

What is the difference with 'Create Folder'? Isn't it influence outside? or something that I don't understand?

Having a way to quickly open nautilus on the current directory

Not all users (include me) are using Nauitlus or file manager. When he creates a new file and somehow he wants to rename old file and use that old name for new file. It is wasting time to open and jump in file manager.

I know I have borked my system before using a terminal and forgetting where I was in the file hierarchy and deleting a file that I didn't mean to. No matter what the system, some of us can still screw it up.

I would mod you up, if OS News was not coming back with errors

It could be an hidden option tho...in GConf or something like that.

Well, I for one think that having file managing functions inside the file selector is bad and wrong.

Oh please. What on earth do you think you're doing when you open or save a file? This is just silly.

I've seen so many times people screw up their files making non undoable changes inside a file selector.

Like what? This is just sensationalist, 'users are stupid', BS. If you have reusable components in your integrated desktop then you're going to be able to get consistent and familiar file operations wherever you are.

It's certainly not uncommon for someone to try and save a file, open the save dialogue and think "Oh dear, I want to put this in a separate folder" or open an open dialogue and think "Oh dear, I made a typo saving the file, so I'll change it". You shouldn't need to open another application to do what you want. If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.

Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

What says that this sort of functionality is out of the scope of a file dialogue?

Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.

How on Earth would having an extra step and having to deal with another application make things any better?

I'm sorry, but this is just lunacy.

Edited 2007-09-25 22:15

I don't get it either. Why can't they just embed the view from Nautilus in there... It just makes sense. It would have file previews etc, and as such improve usability.

Or is it that they just CAN'T do that?

It's a matter of not having GTK+ depend on Nautilus. The GTK+ filechooser needs to function regardless of whether Nautilus is installed or not.

well, lucky for us your book is not the last word.

Even Trolltech is providing Qt bindings for Mono, that would mean KDE apps. based on Mono, you like it or not.

Oh please. What on earth do you think you're doing when you open or save a file? This is just silly.

When you open or save a file, you're not renaming or deleting a file.
An open or save dialog is not a dialog for doing all kinds of file managing operations, which is what the original poster intended to say I think. Stop playing dumb.
And this is not a "user is stupid" problem, this is a user hazard that can happen to anyone, stupid or not.

Like what? This is just sensationalist, 'users are stupid', BS. If you have reusable components in your integrated desktop then you're going to be able to get consistent and familiar file operations wherever you are.

Exactly, but "being able to" doesn't mean "have to". There's an HIG for that. This is a power against usability problem again.

It's certainly not uncommon for someone to try and save a file, open the save dialogue and think "Oh dear, I want to put this in a separate folder" or open an open dialogue and think "Oh dear, I made a typo saving the file, so I'll change it". You shouldn't need to open another application to do what you want.

And why you shouldn't?
Why shouldn't you run a file managing application to manage your files?
Why should a "file open dialog" or a "file save dialog" transform into a "file renaming dialog" or "file deleting dialog" (with all the user error this will create)? Just because you can?
Now that's silly!
For years, you could do everything with everything in FOSS desktops, and they were deemed unusable and bashed for that.
Now Gnome tries to go away from that, has even a HIG, and you bash it again? Besides, I'm pretty sure you're aware of the reasons behind that design decision, but it's just a case of you not agreeing with it.
But if you want it to change, I agree your best way to change this behaviour is to bash the current one.

If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.

That's nonsense. Why it should? And that is no justification for it to happen.

Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.

This I agree more with, but that still doesn't mean it's a desirable behaviour. I can see the point in a image manipulation application, I can't see the point when you're dealing with text documents. IIRC, recent GTK+ filechooser API allows you to implement it in your app if you want, but doesn't force it.
Which is much better than your resource hogging solution. If you mean they should implement it in Nautilus and put a checkbox configuration to have this or not in your file dialogs, then I agree it would be a good thing.

What says that this sort of functionality is out of the scope of a file dialogue?

The answer was in the sentence: the HIG.

How on Earth would having an extra step and having to deal with another application make things any better?

Because it's a validation step that you really know what you're doing, as renaming a file in a open or save dialog should be a hidden functionality, right?
These are file operation dialogs, not file managers.

What says that this sort of functionality is out of the scope of a file dialogue?

The answer was in the sentence: the HIG.

That's a bad excuse for not doing something. Just having a HIG doesn't magically make your apps of DE more user friendly. Bindly following a bad HIG is a lot worse than having no HIG at all. A HIG should be a set of guidelines not a set of commandments. You should refuse to implement a feature because you can show it's a bad idea, not just because it goes against some arbitrary set of rules set down by some arbitrary groupd of people.

Even the much worshiped Apple knows when to ignore their own HIG.

I agree with you as long as we are talking about file selection dialogs. But not if you are talking about save dialogs, here it is already possible to create new folders. If you can create them you certainly should be able to rename them, e.g. if you make a typo.

If you can rename folders, why shouldn't you be able to rename files. E.g imagine you are downloading an image from the net, you name it house.jpg, then you find a similar image and want to give both images descriptive names. E.g. house-south-side.jpg and house-west-side.jpg or you may want to create a folder named house, and move the images into it. You shouldn't need to open Nautilus for this.

As for messing things up, opening Nautilus gives the user even more possibilities to mess things up.

Actually the problem is that thumbnail support in the filechooser isn't inside of gtk and is left up to the individual application writers to implement. There are a few functions to implement it that make it pretty easy.

Yes this is _totally friggin lame_, but until someone puts this support into gtk, it won't happen.

In the meantime about all you can do is file bugs or send patches to software you want screenshots in the filechooser for.

In the meantime about all you can do is file bugs or send patches to software you want screenshots in the filechooser for.

No need to, there are already two of that in bugzilla. As for the patches, sadly, I will have to learn C to do that.

Alexander Larsson (Nautilus maintainer) is doing the heavy lifting and working on a gnome-vfs replacement called GVfs that will be put in the right place of the stack, i.e. GLib/GTK+.

Thumbnails in the filechooser will be a cake walk when that's done.

It might land sooner than you think. He's even proposed it for GNOME 2.22.

http://mail.gnome.org/archives/desktop-devel-list/2007-September/ms...

Edited 2007-09-25 20:49

I don't get why there aren't filepreviews and such in the filechooser. Doesn't the filechooser just reuse code from Nautilus? Or is it something totally different? Of course, I'm looking at this from a KDE view, where I know Dolphin offers it's fileview to Konqueror and every filedialog in KDE - so they all have filepreviews, several basic viewing capabilities like list/icons/details and some basic editing like 'new folder'. That approach just makes sense to me - can't you guys do that in Gnome? Or is code reuse evil, or is it impossible due to architecture, or???

"Doesn't the filechooser just reuse code from Nautilus?"

It doesn't. They want GTK to be independent and don't want it to depend on Nautilus, so they don't use Nautilus code and thus it doesn't support file previews natively.

The VFS (GNOME-VFS) has traditionally been higher in the stack than the toolkit (GTK+/GLib). This made using GNOME-VFS in the lower parts of the stack hard (interfaces and abstractions had to be used).

GVfs/GIO will be put in the right place of the stack, namely in the toolkit itself. (And hence, no more abstractions are needed... on that level at least.)

Reusing too much stuff (some might be reasonable...) from the filemanager would just lead to another bunch of abstractions.

I guess KDE is a bit different since it builds a layer on top of the toolkit so abstractions are the rule rather than the exception? (Note: I haven't looked on any KDE code in a looong time...)

so what are you trying to do?

Trying to bring attention to the fact that the dependency on mono is a bad thing.

It's not. Move on.

Just because you say it is a bad thing doesn't make it so. Give a good valid reason why something like this, which can be removed easily if you so choose, is so horrible.

False, Gnome does not depend on Mono which can be easily removed. Only applications like Beagle, Fspot, Tomboy, Banshee require it. On Fedora you can do
yum remove mono and Debian/Ubuntu, apt-get remove Mono* (Thanks Apoclypse) to get Gnome running without Mono at all.

* Wrote the right apt-get command

Edited 2007-09-25 20:23

It's apt-get remove mono*

to be anal:

$sudo apt-get purge mono

purge is identical to remove except that packages are removed and purged.

afaik, Gnome includes Tomboy by default since 2.16, thereby requiring Mono to install.
That I can remove it afterwards, doesn't change the fact that it initially depends on it.

"Only applications like Beagle, Fspot, Tomboy, Banshee require it."

...and as time goes by, more and more "Gnome" applications will be using mono, so simply removing it won't leave much in the way of functionality will it?

I feel about as much at ease with any MS tech being in Gnome as I do with a single ebola strand inhabiting my sandwich. Initially it all seems quite harmless...but oh my, doesn't it turn nasty later on...

This is too true. I'm tired of people saying that "Mono is required for Gnome" It isn't. It's optional.

Why is Mono such a bad thing anyhow? It's faster than Python, which nobody complains about being tied to Gnome.

It's released under an open-source license, so it's free software.

What exactly is the problem here?

Yeah it is true its optional but some distros are *bad* at packaging these optional things. For example this happened to me once:

Removing Mono wants to remove
- Tomboy (understand this)
- Gnome Applets (because tomboy is one!?..)
- Gnome Panel (because applets sit on it..)

etc etc and break the gnome desktop as a result. I am not going to name the distro for needless flaming but merely pointing out that it is usually the packagers fault when removing mono breaks the gnome desktop as it works flawlessly on other distros as others have mentioned.

So first place to complain about such problem would be the bug tracker for your distro.

Removing Mono wants to remove
- Tomboy (understand this)
- Gnome Applets (because tomboy is one!?..)
- Gnome Panel (because applets sit on it..)

Gnome Applets is almost certainly a metapackage, depending on all the applets. Remove one and the metapackage is removed, but the rest remain. Gnome Panel probably is too (it would be pretty dumb to have it removed otherwise). Likewise, Gnome-Desktop is a metapackage. Its removal means nothing other than that you no longer have every single piece installed (which is what you want, since you wish to be rid of Tomboy).

I see this all the time in Debian with KDE. Someone complains about having multiple multimedia players or multiple text editors. When told to remove the ones they don't want, (s)he says (s)he can't because it "would remove KDE." Yes, the KDE metapackage that draws in all parts including many text editors. If you don't need all of it, you don't need the metapackage.

Similarly, if you don't need all of the Gnome Applets (say, you don't want Tomboy), you don't need the metapackage. That's assuming it is a metapackage, which I don't know for sure since I don't use Gnome and you didn't mention which distro you are using, though I am assuming Ubuntu.

While it is technically true that you don't need the metapackage, it is not quite as simple to remove it as you say. The problem is that when you install the equivalent of kde-desktop, it pulls in a bunch of other packages, and marks those packages as having been automatically installed. This is usually a good thing, because when you remove that metapackage you want all the dependencies to be removed as well. Now the problem is when you want to remove one of those packages because you don't need it. The metapackage must be uninstalled because it no longer has all of its dependencies installed. Unfortunately when you uninstall it, it wants to uninstall all the other packages as well. Then you have to manually fix all the packages it wants to uninstall.
It's not hard, but it certainly is disconcerting to see the package manager wanting to uninstall half the system just because you want to uninstall one app.

Personally, I dont like Mono because of the tie-in with Microsoft. Just because Mono is OSS doesn't mean it's exempt from any leverages MS may - or may not - have. At any rate, I want to avoid it.

You may be surprised at this little piece of news, but not all objections to software technology have to be technical. The guy expressed a legitimate concern, namely that in an unprecised future MS might be using Mono to strongarm or stop (or simply FUD about: see their stance on patent FUD) Gnome development.

So it doesn't matter how good Mono is on purely technical grounds, if it's a poisoned pill having it go down your throat nice and sweet can only make things worse for you.

Rehdon

Because it's patent-encumbered and uses gobs of memory.

How it it patent encumbered? Name some patents that it infringes.

It may indeed infringe some patents. Some say that most free software projects infringe patents. I guarantee you that you're running software that could be claimed to "infringe patents". Note Microsoft's claim about the kernel. This is because of a broken system that allows broadly-defined patents, and is not the fault of software.

So then don't use Tomboy? Just what exactly is the problem?

So then don't use Tomboy? Just what exactly is the problem?

Read the article. It will become increasingly difficult to avoid Tomboy and Mono with distributions shipping with it, and if the integration with lots of third party applications happens then it will be impossible to avoid. However, like everything in the open source world, if enough people to decide to use it then that's par for the course.

Although I'm personally not keen on Mono and I think there are far better ways of creating a great looking framework, considering that I've complained about a lack of integration, I think this is no bad thing. Gnome needs a good, straightforward development framework and environment to develop and integrate applications.

Personally, I think when Ximian initially thought about cloning .Net I just wished they'd looked at it practically and took what was good about it, ditched what wasn't going to be practical, looked at what was happening and what was wrong with Java in the enterprise arena, looked at up and coming languages like Python and Ruby and created something new and original.

However, if no one steps up to the plate and creates something good for Gnome developers to get hold of then I'm not sure what the alternatives are. Red Hat (and Sun) could do something with Java now being open sourced and Eclipse, but it's not happening.

No, that's not going to happen. Apps are included in GNOME because they're good, not because they use Mono. There is no evil conspiracy to take over the world with Mono, get over it.

If you don't like Mono, then don't load Tomboy. That way Mono will never be loaded into memory. It's as simple as that. If you don't like Mono app $FOO, then load use $FOO.

Agreed. I find it ironic that they celebrate 10 years of freedom by going into the devil's hand.

Mono might be "free software" by definition of the term, but it's certainly not so by the spirit. It's a trap, and very well made one at that. The fact the most people don't see it doesn't make it go away tho...

On the other hand, none of the core stuff depends on Mono [yet] so it's possible to go without mono (as I do now for example). But I'm fairly sure someone will make some core part of GNOME in Mono one day and that's when we're screwed.

that's what forking and competing projects are for

"But I'm fairly sure someone will make some core part of GNOME in Mono one day and that's when we're screwed."

Please, take off the tinfoil hat and relax. Mono is not patent encumbered, it's a clean reimplementation, and free software. Just because you don't like MS does not make the technology bad.

Actually there are patents on mono; the issue isn't whether they exist; no one is denying that (except you), the concern is whether Microsoft will exercise their rights as the patent holder. Given one doesn't have to act immediately with patent violations, Microsoft allow this to simmer for quite some time and exercise when it can inflict maximum damage.

With that being said, however, they have an agreement with Novell for a patent sharing agreement, which will give them the ability to clone technologies, including the patented ones within .NET. Sun is in a similar situation. All things being equal, the issue then shouldn't be so much whether Microsoft will exercise those rights but where those distributors who haven't signed patent sharing agreements, sit into the bigger equation. Will we see Microsoft sue Red Hat and Conical for not playing ball? its all wait and see for now.

"no one is denying that (except you)"

Actually, I wasn't really denying that the patents exist, I just wasn't very clear. I guess the problem I have is the word "encumbered" as I also believe that the deal with Novell protects Mono and Linux users from any legal problems with MS. So I guess I look at it as a non issue. So while there is patents on .NET technology, I think were all safe in this case.

Mono might be "free software" by definition of the term, but it's certainly not so by the spirit. It's a trap, and very well made one at that. The fact the most people don't see it doesn't make it go away tho...

Your comments and others like it are indicative of a lack of knowledge about the subject. Mono is an implementation of a standarized language. Mono has its own classes and bindings. There are reimplentations of things like WindowsForms but they are unneeded in GNOME and on Linux in general. Those are the only things that Microsoft would even have a shot at taking away from FLOSS and they don't matter to Linux. When is the last time anyone created a programming language they didn't want anyone using anyway?

You are aware of the fact, that it is only CLR/IL + C# that has been standardized?
The copying of .NET features, is the part that can hit Mono distributors, that hasn't made a deal with Micorsoft, yet.

Indeed. These technologies are royalty-free, and the GNOME stack is built on top of that free base. GNOME doesn't use the Mono/Winforms or Mono/ASP.NET implementations.

You are aware of the fact, that it is only CLR/IL + C# that has been standardized?
The copying of .NET features, is the part that can hit Mono distributors, that hasn't made a deal with Micorsoft, yet.

Like I said before the only thing MS could possibley stop is the Microsoft compatibility stuff and it doesn't seem likely that they will try to stop it. After all how long has WINE beeen around without issue from Microsoft? Even if they did stop the Microsoft compatibilty code it isn't needed for Linux applications like Tomboy, Banshee, Beagle, and F-Spot.

Why?

Not only Gnome doesn't require Mono, but there's now even less chance it happens.
Remember that people were saying that C was not practical anymore for desktop dev, and that we needed a higher level language, like Java or Mono (C#).
Well, it seems like some devs found an easier solution, which is Vala (http://live.gnome.org/Vala).
Well, it's not well documented, but if all goes right (I'm sure there'll be lot of bitching), it could prevent the use of resource hogging (compared to C) Java or Mono on our desktop, without having to go the "harder" C++ way.
Vala is tailored for GObject, which is GTK+ specific, so in my eyes that's the best solution for Gnome main dev language.

In my opinion, the last thing GNOME needs is a new language. I understand the advantages that Vala would bring, but it could deter the occasional contributor from submitting bug fixes or improvement patches. Even though it's close to C#, it's not quite C# and I'm not sure casual developers would bother to learn its quirks. Furthermore, even though Vala generates C code, it's still an additional layer of code interpretation, bringing various bugs, issues, etc.

It wouldn't be so bad if Vala was meant as a general purpose language, but it really looks like "by GNOME, for GNOME", bringing the NIH syndrome to a new level. Without a large userbase, its development could slow down GNOME.

Combined with the new web-oriented direction proposed by Havoc, it looks like the core developers are having fun with a pissing contest or something like that... ;-)

Anyway, my 2¢.

Just an update; you'll need to upgrade libexpat to at least 2.0.1 as dbus (and other components) rely on the updated version.

Gnome includes Tomboy:
from their news section:
Tomboy: Stable version 0.6.1 released! This will be the version included by GNOME 2.18.0.
If Gnome includes tomboy, then gnome becomes dependent on any of its sub packages, and thus its dependent on mono.

Edited 2007-09-26 09:20

GNOME would only depend on Mono if it fails to build without Tomboy but AFAIk you dont *have* to build and install Tomboy. I could be wrong though.

How about Samba? Wine? Fat32 that used to be a problem until recently? NTFS drivers? OpenOffice.org .doc filters? And so on?

Because Mono is a little bit different in how patents have, and can be, applied to it. With stuff such as Samba, Wine, Fat32, NTFS and OpenOffice filters these are all independently produced code for interoperability purposes that you could never nail down anything common with. Microsoft prefers shifting technical goalposts anyway, which is far cheaper.

The line that many people, including the Mono project itself, have come up with is that the ECMA stuff is OK whereas the Microsoft specific APIs may not be. I really don't know how anyone can say that. Microsoft have stated that they have a patent or two on things such as the CLR, and the ECMA provides implementers no real patent protection whatsoever. The ECMA does not state that people submitting standards can't hold patents, but merely states that they must give some kind of RAND agreement. However, that still doesn't stop companies from using their patents, and in that event all that can happen is that the ECMA standard in question will be dropped:

http://www.ecma-international.org/memento/codeofconduct.htm

This is why we had some discussion about the Mono people supposedly having a letter from HP and Microsoft that the common .Net underpinnings such as the CLR would be available under RAND terms forever. No such letter ever materialised, and presumably, only Novell's customers can be sure that

The clincher is that in all of Microsoft's patents regarding .Net related stuff that I've seen, they have clearly stated that the patent only applies to code run with a CLR (Common Language Runtime). It's not a general thing as you see with most of them.

However, the the acid test is whether anyone will use Mono in the open source world (and they are), and in the absence of anything better currently that's the way things are. Certainly from a Gnome development perspective, Mono is just a big step forward.