On 12/13/2009 11:33 AM, James Tyrer wrote:
> Nikos Chantziaras wrote:
>> On 12/12/2009 11:02 AM, James Tyrer wrote:
>>> Nikos Chantziaras wrote:
>>>> [...] $PWD is not the Documents directory. The Documents directory is
>>>> the... Documents directory. The $PWD is the $PWD.
>>>>
>>>> Now the above sounded pretty dump, but really obvious things tend to do
>>>> that. So why does Dolphin think that ~/Documents is the $PWD? Those
>>>> two are *not* the same thing. And after the lengthy explanations given
>>>> in this thread, this approach even contradicts previous statements about
>>>> how things are supposed to work on Unix systems.
>>>>
>>>> Bottom line, if an app wants access to the ~/Documents directory, it
>>>> should *say so*. From how I see it, relying that $PWD is ~/Documents is
>>>> a broken design too for the reasons you wrote previously :) Sorry, you
>>>> can't have it both ways.
>>>>
>>> (bottom line)^2 is that this (KDE) is a GUI. A GUI does not work the
>>> same as the underlying OS. MS-Windows is the same. It looks for user
>>> files in MyDocuments. I don't have MS-Windows so I don't know if it
>>> uses MyDocuments for the "cd" or not.
>>
>> Windows and Gnome work the way one would think. Current directory is
>> whatever you're looking at at any given time.
>>
>> Being a GUI doesn't mean you should not be able to launch programs that
>> expect their files to be in the same directory, *regardless* of whether
>> such programs should be considered broken or not.
>>
>>
>>> And, as I said, if an executable needs access to data, it should keep
>>> it/look for it in the proper place and not rely on it being (improperly)
>>> stored in the /bin directory with the executable. On *NIX, it is not
>>> proper to store data in a /bin directory as was common practice with
>>> PC-DOS. You don't seem to be getting that.
>>
>> No, I am getting that. What I don't get is why Dolphin can't do what
>> other GUIs do and tries to do it's own thing "because it's a GUI,"
>> totally ignoring expected behavior. What I also don't get is why
>> Dolphin should expect the world to write application the way it thinks
>> is best instead of simply allowing already existing applications to
>> continue working as they always have (and still do in pretty much
>> everything except Dolphin.)
>>
>> Also, GUIs are there to make the CLI less relevant. If a GUI can't
>> replace the CLI even for the simple task for launching a program in it's
>> current directory, then something's wrong.
>>
>> And I yet have to hear a reason of why Dolphin can't do what I described
>> :P Why exactly would it be wrong? Because it would allow "broken"
>> programs to keep working like they always did? IMO that's not up to
>> Dolphin to decide. Dolphin should be able to be used with non-KDE apps
>> too. And what would it break? Gnome and Windows users seem to do just
>> fine. (Unless there *is* a setting somewhere to configure that, of
>> course. But I didn't find any.)
>>
> KDE is perfectly capable of doing what you want. It is just that it
> isn't the default. The normal way to launch a program with the GUI is
> not to go the the /bin directory and click on the executable. As I
> said, this isn't really the correct way to do it, but it does still work
> for binary files. What you need to do is to make a *.desktop file, then
> it will do whatever you tell it to do in the *.desktop file.
If I need to create a *.desktop file every time I want to launch a
"one-time" program, then it's clear that something's not right here.
Btw, all of this is not a real problem for me anyway. All the PCs in
the labs are running either a Linux with Gnome or Windows XP. I'm just
continuing this discussion out of interest. It's interesting to see how
people want to "defend" an app they use, no matter what, even if it's
behavior in some corner case is just so obviously wrong.
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
