-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 26 Dec 2003, Charles Goodwin wrote: [...snip...] > Yes, file sniffing is slow. So implement it in a way that does not > affect the user. Last time I used Nautilus, I could scroll up and down > and jump between folders without extra pause, whilst Nautilus updates > itself in the background. So what is the issue? It only updates what > is in immediate view (as I recall) so you just scroll to your desired > file and, if necessary, wait the 2s for it to be detected. I think that this is how it was supposed to be implemented, but I don't believe that this implementation has actually been done. As a quick test, open /usr/bin in nautilus. On the box I am using to write this, /usr/bin has 2,124 files in it. Nautilus took about 10 seconds to load the contents of that directory. In comparison, use a shell and cd to /usr/bin. Then, type the command: echo * and see how much faster that returns. echo * returned instantly on my box. If you want, you can do the echo * method first just so you can convince yourself that nautilus is not caching things for the shell. Also, when nautilus is opening the directory, take note of the extreme disk churning you hear and note its absence when using the echo * command. FYI, the hardware I ran this on is a 1.8GHz P4 with 1GB RAM and U160 SCSI disk on an Adaptec 7892A controller. Hardly pokey by any standards. If we want the average user to use Linux over Windows, we have to have a system that is competitive not only in security, but also in speed. While nautilus has improved greatly over the years, it is still *far* behind explorer in speed and this file-type identification issue is a prime reason. > > If Nautilus is wrongly detecting a file type it is a _bug_ and should be > dealt with as such. It is nothing to do with the system used by > Nautilus. Detection of type by file extension is far more error prone > and relies much more on correctness of user input which is an > unreasonable expection on lay users. I dispute this notion. Proper training of users (not unreasonable) with the help of applications automatically setting file-types will go a long way towards having good input from users. [...snip...] > > The bugs present in Micros~1 Windows are not due to file type detection > > by suffix. > > Wrong, they are. By due nature of the ridiculous method, people > associate .jpg files or .gif files as images. This introduces a problem > with visual association. > > Somebody gets an email with an attachment such as 'pretty.jpg.exe' or > 'sexy.gif.pl' and they open it up. Yes, this is due to file type > detection by suffix because you are subconciously causing people to > recognise file types by file suffix and hence they can be easily > mislead. However, in this type of example, the extensions for both of these files are .exe and .pl, respectively. Therefore there is no ambiguity since a file ending in .exe is not a file ending in .jpg and a file ending in .pl is not a file ending in .gif. The only time that this can cause a problem is when the system *hides* the extension like Windows does. This is a badly contrived example. [...snip...] > > One goal of Gnome is to make Free Software desktops a global reality (as > if it already isn't). Introducing notions that add to the confusion > just to save a few cpu cycles and/or to make things look snappier > on-the-surface is no way to achieve that goal; unless you want a buggy, > insecure system but that niche is already well filled. Or unless you want to have widespread use. Unfortunately, the average user expects a computer to be fast. By coupling the file extension method with a type-match check method when the file is opened using nautilus, you get the best of both worlds. I fail to see the objection. It's just as fast as the way Windows does it, and it's just as secure as the current way that nautilus does it. Contriving a conflict is counter-productive. > I wish this pointless discussion would go away. It's clogging up my > inbox. Really, there's some damn clever guys hacking Gnome and this You can always unsubscribe to the list or request to get messages in a digest. However, terminating a discussion because it bores you or is a minor inconvenience to you is not the right approach. [...snip...] - -- Jason A. Pfeil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/8EaXF7j4r5hBUugRAkuyAJsG+EUX6CfcWeQNMAcnZ2R4NG+e5wCfVfra TdKV3hlYVi/yZb/Ey4q03kw= =nnAT -----END PGP SIGNATURE----- _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
