KDE-CVS-Digest for February 21, 2003

This week's edition of KDE-CVS-Digest highlights the larger merges of Safari code, Xinerama support,
msword filters, KMail bugfixes, Kopete developments, along with continuing work on aRts and much more.

Dot Categories: 

Comments

by Adam Treat (not verified)

This is really my primary source of news on the day to day happenings within KDE. It can't be said too much ... great job Derek!

by Eike Hein (not verified)

Merde, you beat me to the first "Thank you, Derek" post. :-)

by dkite (not verified)

Glad you enjoy it. Doing it weekly was the primary goal of the project. Now the challenge will be continuing during my busy work period. May to August gets rather hairy.

Derek

by not me (not verified)

Yay, David Faure is working on the Word import filter for KWord! Hopefully KOffice 1.3 will have a nearly complete filter. That would make KWord a lot more useful for me, at least. Thanks for the updates, Derek!

by Peter (not verified)

Yes, and it seems most of the really important things are in there (except for images)

by Kerry Whittle (not verified)

Important for you...important for everyone. The decisionmakers who choose
software won't even consider an office package that isn't 100.00%
interoperable with M$ Office. Sad but true.

Why I used to work for one of the major movers behind OpenOffice.org where
we used Applix company wide. There were enough problems importing from
and exporting to Word and Excel documents for customers that I would say that
had more to do with the purchse of Star Office than any other gallant pupose.
And why not, not being able to work with the customer means no sales, no
sales means no company, and I thnk we all understand the rest.

The completeness of the Word and Excel input filters for the office suites will
have more to do with the expansion of Linux onto the corporate desktop than
any single application or operating framework now or in the forseeable future.

How do I know this? I have had this conversation with the decision-makers
who considerd using *N*X as their enterprise desktop when making the switch
at Y2K. Interoperability was the one flaw that stopped the migrations. One of
these was a LARGE enterprise too, a major Utah university. While the other
was not nearly so large, they were very visible on the corporate radar.

Filters, filters, filters!! Good Luck to the author that he might get them as near
to perfect as is humanly and economically possible!

Now lets talk about printing...

Later all,
Kerry

by Melchior FRANZ (not verified)

> Aaron J. Seigo committed a change to kdebase/kdesktop
>
> allow running apps by their desktop file name (as a last resort)
> would be nice to make it case insensitive one day, [...]

NO!!! Never ever make anything file system related case insensitive! That's the root of all evil
and still bites Micros~1 users in their asses. Unix file systems aren't case insensitive. Period.
I'm afraid I will have to sue somebody, if I type "RM -rf ~" and KDE chooses "rm -rf ~" instead, because this cool new RM program happens not to be in the $PATH.

The correct answer to the application name vs. binary name problem IMHO is, to either make
a few hundred links (ln -s KMail kmail), or to ask the user: "There's no application 'KMail', did you mean 'kmail'?" Guessing what the user might have meant is not an option.

m.

by Aaron J. Seigo (not verified)

i wasn't talking about making all commands in minicli case insensitive, just the check for .desktop Name= entries which are checked AFTER looking for the program in your PATH, looking for servicenames, looking for .desktop file names, etc... so it wouldn't run random commands on disk (e.g. /usr/bin/RM vs /bin/rm) but only work w/regard to the names you see in the KMenu as a last ditch attempt to figure out what you want before trying to resolve it as a domain name.

someone typing "quanta plus" probably means "Quanta Plus", wouldn't you say? and for the record, i've NEVER 'rm -rf'd from minicli ;-) i'd really like to see this go even further and try some clever heuristics so if you do "quanta+" and that doesn't match anything in your PATH, services, .desktops, etc.. it runs Quanta Plus which is actually just quanta. but that's for 3.3...

as for asking the user "did you mean Foo?", that would be easily implementable once case insensitive matching is there. but that's the big job since it means mucking with ksycoca's hash storage of things, which is performance critical and not something to do lightly obviously =)

by Melchior FRANZ (not verified)

The problem is, that with these changes the user is no longer is control of which application will
be started. He won't even notice. If I type "kMaiL" and there is no such binary, then I want to
get a warning, and not have "kmail" started silently behind my back. I might have meant
"kmail", but then again, I might not have. What comes next? An animated paperclip that starts
konqueror when I requested mozilla?

And for the record: I've never used "rm -rf" from minicli myself. So why would I want it started,
when I was actually typing "RM -rf". I'm not a frequent minicli user anyway. I always have a
konsole open. But I don't want to apologize for things like that every time I recommed KDE
to some advanced user.

People who are interested in typing-in commands, rather than clicking on colored pictures, are
probably also interested in literal execution, rather than computer aided guesses. (Hey, what
about making this configurable. ;-)

by Aaron J. Seigo (not verified)

before my patch, mincli would already try the .desktop files by name. now it also tries the Name= entry (localized to your language, of course). minicli is not hogtied to the command line, or even the filesystem since (for example) it undertands and launches URLs.

if you type kMaiL and there is a kMaiL binary then it will get launched.
otherwise next it tries services and .desktop file names
if we still don't have a find then it tries Name= entries
if it STILL doesn't find anything then i'd like it to try the Name= entries case insensitive. note that this isn't looking at actual binaries (we've already done that) or random input (it's using the .desktop files)

given the above set of rules, can you describe a real world situation where this will not work as expected?

by André Somers (not verified)

Easy: what if I have two desktop files: FOO and Foo (wich refer to programs with completely different names), and I try to start foo. Which one will get started? What if I have these: Foo and food, I type foo, but I just incidently hit the Enter button before the d. I will end up with Foo, not what I wanted at all!
Really, I like the idea of trying to help the user find his software, but I really think a "Did you mean Foo?" or even a, to refer to my first example, "Did you mean FOO or Foo?" ("FOO", "Foo", "Neither") would be order. Adding a checkbox "Don't ask me again" so the user won't be bugged again about _this_ name could help users who like the feature, just like the user should be able to turn it off completely.

by Aaron J. Seigo (not verified)

> what if I have two desktop files: FOO and Foo (wich refer to programs with
> completely different names), and I try to start foo.

this is pretty contrived, but possible. the solution is easy, as you note: it would need to ask which one was intended.

> What if I have these: Foo and food, I type foo, but I just incidently hit the Enter
> button before the d

red herring. what if i type local and hit enter accidentally when i wanted to execute locale instead. so this particular issue has nothing to do with capitalization.

by André Somers (not verified)

Oh, but it does!
I did not name Foo with a capital for nothing, nor is food called like that for nothing. Please keep in mind that there are more languages than English, and that words with different meaning may look very much alike in these languages. Anyway: what's the hurt in _asking_ the user what he wants? Sure, it may take more than that six lines of code, but it may also save a lot of frustration.
My point is: you should be wary to make assumptions on how "the user" would want the system to react, especially with things as fuzzy as this. One of the things I like most about Linux/KDE is that is does not try to decide for me what's good for me or what I may want...

by Dawnrider (not verified)

I'm sorry, but Aaron is being quite reasonable. I appreciate that you are trying to be perfectly set-complete about the namespaces, and case sensitivity is good for that.

That said, however, people almost never put files of the same name with different capitalisation in the same directory as a matter of choice, because *it is confusing*! The English language (or indeed any other), was not parallel assignment of words to different concepts. It happens, but not often, and in social and oral environments, it causes a great deal of confusion. In fact, Chinese is an example of a language that has parallel assignment with substantially different meaning. Words are distinguished by changes in tone, such as a word rising in tone at the end, staying level or lowering. Tonal accidents are an entire form of humour in Chinese! My advice, make sure your files have properly unique filenames... It'll help you and others who ever want to use them.

Case sensitivity is a good thing in that it helps reduce namespace clashes, but only up to a point. In usability terms, it has serious issues. Perhaps someone had intended to start Scribus, but it had been named ScRibUs. I'd like to see the length of time it would take most users to be able to launch it this way without case insensitivity. They will get the case wrong many times. I know I certainly would.

>What if I have these: Foo and food, I type foo, but I just incidently hit the Enter button before the d. I will end up with Foo, not what I wanted at all!

Bad example... That is like saying that I typed './h' and expected /home/dawnrider/mydocs/server/ip/thisbin to be executed.

If someone types kmail, that isn't found naturally and it gets to the stage of searching the desktop files, picking 'Kmail' would satisfy the majority of people. The people with 'Kmail' and 'KMail', who received the former and wanted the latter would be tiny, compared to the rest (of an already small group).

I appreciate being able to be absolutely correct every time, but sometimes 'close enough' will do. This is probably one of those times :)

by Melchior FRANZ (not verified)

I don't want to continue this debate ad infinitum and this is probably my last reply. However, I
was quite amused about the attempts to elaborate how case insensitivity is an improvement.

* "minicli is not a command line but an URL launcher":
LOL -- There are two parts in URLs that are case insensitive: the protocol ("file:" in our case)
and the hostname ("localhost" in our case). Everything else =is= case sensitive. So this
argument backfires.

* "why not drop tab completion as well" (meant to be sarcastic):
LOL -- What a great example for the right thing to do: 1) Tab completion isn't forced on you.
You have to activate it (). 2) It doesn't do anything behind your back. It =shows= the
system's suggestion. 3) It asks for confirmation. You can still edit the suggested command
or parameter. Now, these three points are exactly what I'm asking for. So this argument
backfires as well.

* "case sensitive filesystems are bad, anyway":
This opinion is pointless. KDE runs almost exclusively on systems with case sensitive
file systems. (Exceptions: (v)fat mounted devices; the KDE2 port to MICROS~1)
This is the world we are living in. Case insensitive file systems are obsolete. And there's
a reason for it. I'm even willing to discuss this on a newbie list.

The main problem is, that this new mechanism takes predictability from the system.
Predictability is one of the most important properties of a reliable computer system.
What's wrong with "educating" the user? If someone asks KDE to start kmaiL and
there is no such thing, he should be told. He will profit next time when he tries to start
kmaiL in konsole, where there's no Clippy around.

While the current behavior is already reason enough for me to warn people against using
minicli(ppy ;-) for starting programs ("might start something else"), the comment "would be
nice to make it case insensitive one day" is alarming. Is this where we want to go tomorrow?

(I don't mean to sound arrogant and I'm not religious about this issue ... no, wait. I =am=
religious about it. I'm believing in the one true religion of Unix. And I know that I can change
the code in my local copy. It's not like this would be the first change in my KDE. :-)

by Space Cowboy (not verified)

> no, wait. I =am= religious about it.
> I'm believing in the one true religion of Unix.

Religious arguments aren't the best way to
make an engineering or a GUI decision.

There is no one true religion of Unix. Perhaps
you refer to the ancient AT&T stuff and it's
ideals, not the result of 30 years accumulating
stuff.

By the way, Mac OS X is Unix and is case
insensitive down to the Terminal level.

So, there!

by Rayiner Hashem (not verified)

Who takes Mac OS X, at the user level (where it's case-insensitive) seriously as a UNIX? It might be a UNIX at the lowest levels (where it is case sensitive), but not in the absolutely hacked up, "let's hide everything from the user even in Terminal.app" user level.

by fault (not verified)

> Case insensitive file systems are obsolete. And there's
a reason for it. I'm even willing to discuss this on a newbie list.

I don't know how you get this. NTFS is pretty much a case insensitive, as is HFS+.

What is really evil is case destroying file systems such as VFAT and many network file systems (sans nfs.)

Face it.. if you want grandma or Joe Little-Skilled Office Worker to use KDE, you can't expect them to remember case in binary names. Ideally, they shouldn't be forced to remember the binary names either... :)

> Is this where we want to go tomorrow?

Personally, I do, but doing it at anything under the desktop would be painful for more advanced users perhaps. Still, it makes sense usability wise in most instances.

by Aaron J. Seigo (not verified)

> * "minicli is not a command line but an URL launcher":
> LOL -- There are two parts in URLs that are case insensitive:
> the protocol ("file:" in our case) and the hostname ("localhost"
> in our case). Everything else =is= case sensitive. So
> this argument backfires.

i supplied URLs as an example to demonstrate that minicli is not tied to the command line as was asserted. and since there are parts of a URL that are case insenstiive, it obviously shows that there are places where that makes sense. case insensitive matching on .desktop Name= entries is another.

minicli is a way for human beings to interact with "commands", be they in .desktop files, on the network or in their file system. minicli is human centric, not resource centric. and humans are decidedly non-case sensitive.

> While the current behavior is already reason enough for me to warn people against
> using minicli(ppy ;-) for starting programs ("might start something else"), the

you really have absolutely zero clue about what the patch i committed does, don't you? if you don't understand it, which you obviously don't, please don't comment on it. there's enough useless noise in the universe as it is.

by Rayiner Hashem (not verified)

humans are decidedly non-case sensitive
>>>
That's entirely untrue.

Gnarfnarkel <--- proper noun
gnarfnarkel <--- adjective or verb, other noun
Gnarf Nar Kel <--- Title
gnarf nar kel <--- three random words.
GNARFNARKEL <--- Exclamation

You can get a great deal of information out of an arrangement of words, just from the casing of the words.

by oliv (not verified)

>humans are decidedly non-case sensitive

A pacifist would definitely not interpret the files Chirac_agrees_with_us.pdf and Chirac_agrees_with_US.pdf the same way :-)

by Joe User (not verified)

I agree 100% with everything that Melchior has said.

by Tim Jansen (not verified)

Right. And please disable tab-completion, people want to write the whole name. Otherwise they dont remember the spelling when using tools that dont support it. And please disable this ASCII input, enter the name is hexcode. People should be reminded that the name is just a sequence of numbers. After all were elite unix users, no whiny windows users.

by Jan Schumacher (not verified)

Tab completion is quite different as pointed out elsewhere -- It does not execute its guesses automatically. In fact, the equivalent of tab completion for minicli would be great, even if case insensitive, assuming it waits for enter after offering a canonical (correct?) application name.

by Robert (not verified)

Go back and re-read the post you're answering to, but now in "satire-enabled" frame of mind ;-)

by fault (not verified)

> If I type "kMaiL" and there is no such binary, then I want to
get a warning, and not have "kmail" started silently behind my back.

Why not? Isn't it what you meant?

> The problem is, that with these changes the user is no longer is control of which application will be started.

Perhaps.. but it sounds like if the software is now empowering the users to be more productive. Software should work for the users, not the other way around.

by Anonymous (not verified)

How many non-experts (e.g. people that don't know that linux is generally case-sensitive and/or don't know the correct spelling of application names) do actually use Alt-F2 or "run command" to start ANY application. These people usually just browse the application menu until they find what they need and only use the run feature if someone explicitly tells them to type in a command name (on windows that might be regedit, then search for key and edit).

I really don't see how this feature will help new users, but if people really think it does please a east add a confirmation dialog.

by Anonymous (not verified)

About one of the messages in the KDE .cvs digest (by Aaron J. Seigo)

>> it was done at the request of a user wondering why they couldn't just type the same name that they saw in the menu.

To be honest with you I did think that this patch was a good idea at first, it is a somewhat drastic change in the purpose of 'Run Command...', it should be renamed to reflect the change to something like 'Run Program...'. A 'Run Program...' button is much more useful than a 'Run Command...' button (IMHO) because when I want to run a command I will use Konsole (or hit CTRL+ALT+F2, or whatever). I use 'Run Command...' / ALT+F2 because I want to launch a program and it is quicker (and requires less thought) to type its name than to take my hands of the keyboard and search through menus/click an icon (for me atleast).

>> allow running apps by their desktop file name (as a last resort)
would be nice to make it case insensitive one day, but that will require
some fairly drastic alterations to the ksycoca storage, methinks

I am not a KDE developer but I fail to see how it would it be a drastic change. Surely it wouldn't require much more than converting the name given to lowercase and testing it against the lowercase equivalents of the .desktop names you have already tested it against.

Please, consider a change of name (at least in the long term) to reflect the new functionality

by not me (not verified)

The only reason there are any problems with Windows being case-insensitive is that every other OS isn't. If every OS was case-insensitive, then there would be no problems. Actually everything would be nicer. There is *no* reason to have a case-sensitive filesystem. If I give a name to something, I don't want anything else to have a name that could be confused with it just because one or two of the letters are uppercase, and I don't want to have to try and remember whether I capitalized certain letters when I named my file or not (or try and figure out the case convention used by some other guy when he named all his files). Case sensitivity is confusing for inexperienced users and adds nothing useful for power users. The only reason computers are case-sentitive in the first place is that it is the path of least resistance when using ASCII. Just laziness. If I ever make a programming language or OS, it will be case-insensitive all the way.

I wish KDE could do something about this, but it is really too late. Changing Linux now is totally impractical, and it goes against POSIX and accepted practice anyway. Kinda a shame, really.

by Micha (not verified)

So, check out the diff between 'a' and 'A' in an ASCCI table.
They are differnt.
So why sould the computer handle them, like they are the same?

Some peopla user the case of a word for sorting their files and directories.
So, why take this option from them?

by not me (not verified)

Of course they are different in the internal representation of the computer. But exposing the computer's internal representation to the user is the cause of an enormous number of usability problems. The user shouldn't care that the computer sees them differently. The computer should conform to the user's expectation.

As for using the case of a word for sorting, I'm not sure what you mean. I think it is a silly idea to sort 'Z' before 'a', if that's what you mean. If what you really want is a way to make a directory be listed at the top when you type 'ls', then you should implement that feature in a way that doesn't break standard alphabetic sorting. Maybe a special "priority file" flag or something. I can see how such a thing could be useful. But using case to do it is stupid, since it breaks users' expectation of how sorting works. Before I got used to this UNIX quirk, I often had trouble finding files that had the misfortune to be named with an uppercase letter at the beginning, because they weren't in the correct sorted place.

by Micha (not verified)

for me its logical, and I expect that when I do a ls, the README shows up before anything in lower case.
If you think, Joe User needs some differnt behaviour, ok, BUT make that option configurable.
A hint for not losing files: give everything lower case letters, except the _very_ important ones.

by not me (not verified)

I never make files that have capital letters in them. That doesn't help me much though. Maybe you don't, but I often want to deal with files not named by me, and it never ceases to annoy me when (for example) I can't find a manpage because it's XF86Config instead of xf86config or XF86config or xf86Config or Xf86config. For you it is logical because you're used to it, and that is precisely why KDE can't change it now. Too many people are used to it the way it is; the case-sensitive attitude is pervasive in UNIX. But case-sensitivity is hardly found anywhere except computers. Certainly nowhere but computers (and UNIX in particular) are uppercase letters sorted before lowercase letters. Casual computer users and newbies are apt to be confused by case-sensitive behavior.

by vod (not verified)

Man, the argument you've stumbled onto is the one that was on a few days ago involving mosfet.
Keep useful features or take em away from all the users because some of them might be dumb.
Case sensitivity gives very useful features to a lot of people. Why take it away?
I'm in the mosfet camp. I've never found it hard to remember cases of my binaries.
Don't make me suffer because some people are retarded. You might as well just use something like
windows if you want everything dumbed down to the lowest denominator and that's exactly the reason
why I fdisk'ed my windows partition.
(the above is about the silly idea of making case insensitive Linux, not the kde patch)
Actually, I've just had a great idea. If you think case insensitivity is so great, start your own distro.
Let's see how many people use it.. I'm thinking of a number, it's lower than 2.

by not me (not verified)

Who is advocating taking away Linux's case sensitivity? Not I! I would be the last to propose such a thing. I think you need to re-read my posts.

That said, I still have yet to see what "useful features" case sensitivity gives. The sorting thing is bunk. Are there any other benefits to case-sensitivity that I don't know about?

by Kang (not verified)

Case sensitivity is evil! Well, really bad at least. The anti-MS camp or language snobs don't think so, but all you here out of them is "We don't have a problem remembering case". The very point is that you shouldn't have to have gotten used to it to begin with! It's a notion whose time has long passed. Computers are not the place for semantic meaning; this is not the English language. There should be no difference between things that are spelled the same way, just cased differently. It serves no purpose. We were tasked with porting our Windows FTP traffic over to UNIX; the nightmare was so painful because of case sensitivity. Finally, we were let out of the carnage because it was taking too long to compensate for the case sensitivity coming from an environment that didn't care. The problem is even worse in programming. I have more important things to worry about than trying to remembert the proper case of a file, variable, class, or function name (C-based languages). The issues of having to codify non-Latin-alphabet-based languages and other localization issues are no longer a problem (the reason B, Unix, and subsequently C were case sensitive). MS had a wonderful opportunity to leave this old baggage behind when developing C# - oops! But they had to for backward compatibility and familiarity expected by would-be Java/C++ converts. Check out this link: "http://www.kurumi.com/opinion/case.html"...

by André Somers (not verified)

[quote]I wish KDE could do something about this, but it is really too late. Changing Linux now is totally impractical, and it goes against POSIX and accepted practice anyway. Kinda a shame, really.[/quote]
You seem to be in luck! Checkout your Konqueror: in the view menu, there is a Sort option. Guess what, you can set it to case insensitive!

by not me (not verified)

Surely you jest. You can still create two files whose names differ only in capitalization and you always have to refer to a file with its correct capitalization or it won't work. Plus every non-kde program is still totally case-sensitive. Changing Konqueror's sorting option doesn't change the kernel filesystem api. If only life were that simple! KDE can try and hide the case-sensitivity if it wants, but that will only cause more problems while the underlying system is still case-sensitive.

by fault (not verified)

You can always have a layer around POSIX cruft anyway. MacOSX is pretty much case insensitive (as is cygwin), and they handle POSIX stuff fine.

by Marco Menardi (not verified)

I totally subscribe what you say. I've suse distribution, and their files are often with "SuSE" prefix, or have capitalization in some points to make them easier to read. I've not only to remember their name, but also the capitalization! So bad. The OS have to be "users goal centric", not machine code friendly. But since it was programmed in C, it inherits this "assembler like" language. If it were programmed in Pascal, it whould have been better ;)
Ok, you can write all in lowercase, but often case mixing makes things be more readable (MyFinancialBudget can be read in a snap, while myfinanciialbudget does not).
KDE should hide this the most it can, in my opinion.
One of the best reading a programmer can do are Alan Cooper's books: www.cooper.com. They will change the way you see software UI and design in general.
regards
Marco Menardi

by Aaron J. Seigo (not verified)

> The only reason there are any problems with Windows being case-insensitive is that
> every other OS isn't.

mac os x is case insensitive as well. not that that means or proves anything, except that this assertion is false.

by not me (not verified)

Good for OSX! How do they reconcile that with their BSD subsystems? Is the command-line case-insensitive too? If not, how does the finder handle it when two files are given names that differ only in capitalization?

by Aaron J. Seigo (not verified)

yes, i believe the command line is case insensitive (don't have an os x box at home to make sure, though). as for the finder, it simply ignores capitalization and gives similar errors that you get on linux when you try and create a file with the same name (including capitalization)

i'm not a big MacOS user, so i'm not long on details. i basically use it when visiting various friends to compare UI concepts, see how people deal with that OS's design decisions and try out those decisions for myself =)

by My Left Foot (not verified)

It depends on the filesystem.

On an HFS+ (the default) partition, everything is case-insensitive. You lose some POSIX compliance brownie points and some software written for POSIX doesn't work right.

On a UFS (BSD-derived) partition, everything is case-sensitive. Your POSIX apps behave correctly, but some MacOS Classic apps don't run correctly.

Cocoa and Carbon apps behave appropriately either way.

From a usability perspective case-insensitivity has some advantages but they're pretty marginal in a GUI environment where you have file dialogs. In defence of case-sensitivity, it seems to encourage people not to use SHOUTY NAMES for files unless they want them to stand out, which is nicer on the eyes.

Not something to get terribly worked up over though, and not something that's easily changed either.

by oliv (not verified)

I'll just give my example again which proves your opinion is completely wrong:

A pacifist would definitely not interpret the files Chirac_agrees_with_us.pdf and Chirac_agrees_with_US.pdf the same way :-)

CQFD

by yo! (not verified)

Case sensitivity blows! flatout. I'm surprised that they haven't resolved this problem in unix. It seems like an easy fix you try to resolve the old way for backwards compatibility and if it falls you typecast the filesystem and the users input and resolve it that way. it might suffer from collisions but for the most part it would resolve as long as the developers didn't abuse type sensitivity in the first place, which I don't think they commonly do. this could even be built from kde in the format of METADATA. its alot of tables that would need to be built since each file and folder entry would need a key but it doesn't sound that hard.

ASCII by itself really needs to get dumpt anyway for a unicode system but but no designers want to do that they all love there 8 bit ascii.

by Jesper Juhl (not verified)

Ok, I know a lot of people have commented on this already, so most of what I'm about to say will probably be redundant - but I still want to add my own personal views on this.

- Case sensitive versus case insensitive :
At the file system level I personally like having stuff be case sensitive. I like naming scripts with an initial capital letter so I always know if I'm launching a binary or a script simply by looking at the first letter. This lets me create scripts that mimic the behaviour of other commands (but slightly different) without having to invent new names - I just name them the same but with a capital first letter. This is a personal habbit/preference and many people may disagree, but I like it that way. if launching stuff was suddenly case insensitive then I'd have a hell of a time launching some of my scripts.
I also like the fact that most programs sort file lists case sensitively. I use this when I organize my documents. I usually name my 'main' or 'index' documents with a capital first letter to make them show up in the top of directory listings - other documents related to the same topic usually are named with the same starting word, but in lower-case as to not show up in the top but still be grouped together lower down in the list. This way case sensitivity helps me organize the contents of a directory without having to stuff things in subdirs.

- Launching programs by desktop entry names :
I like the idea that if a program is not found by searching for a binary of the name the user enters that a search for the name specified in the desktop files is then made. But, in my oppinion, if we get to this last resort (and only then) it should be handled like this; if there is a case sensitive match of the name on the desktop file with what the user entered, then launch the program. If there is only a case insensitive match, then prompt the user if this is the program he/she wants to launch (with an option to never ask again for this specific name). if there is an ambiguity between different programs due to case differences, then the user should be presented with a list of the programs to run (with as much info about the different programs as possible) and be asked to select one of them (again with the option to make this choice permanent).

Just my 0.02euro

/Jesper Juhl

by not me (not verified)

Instead of capitalizing the first letter, you could use an underscore before or after the command, or the prefix 'my_', or the letter 'z', or whatever. There are lots of choices that don't require a case-sensitive filesystem and the other drawbacks that come with it.

As for the sorting, it seems that there is a genuine need for a "priority flag" or something to make files appear first in the directory listing. That's fine. Just implement that feature isntead of mangling another feature to get the behavior you want.

Once again, let me reiterate that I am not advocating a change in Linux. People are used to it the way it is, and changing it would upset them tremendously. I am simply saying that case-insensitive is better user-interface design.

by Jesper Juhl (not verified)

> Instead of capitalizing the first letter, you could use an underscore before or after the command, or the prefix 'my_', or the letter 'z', or whatever.

yes, I'm well aware that there are plenty of other options. I was simply describing the way that I like to do it.

> I am simply saying that case-insensitive is better user-interface design.

I'm not sure I agree. Depends on your target audience.

by not me (not verified)

It is better user-interface design, period. Now, since mistakes have been made in the past, we're stuck with the status quo. That doesn't mean that the status quo has become good user-interface design in the meantime. It just means we shouldn't change the behavior of a system people are used to unless the result is an order of magnitude better than the current situation. Although case-insensitive is better, I wouldn't argue it's quite THAT much better.

If you were designing a new operating system though, you should go case-insensitive all the way.