[Bug 242830] New: kde doesn't take "hint" of "current" directory for virtually anything

David Rankin drankinatty at suddenlinkmail.com
Sat Jun 26 00:28:19 BST 2010


https://bugs.kde.org/show_bug.cgi?id=242830

           Summary: kde doesn't take "hint" of "current" directory for
                    virtually anything
           Product: kde
           Version: unspecified
          Platform: openSUSE RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: drankinatty at suddenlinkmail.com


Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

Guys,

    One very frustrating aspect of KDE4 is that it doesn't seem to have a clue
about what the active directory for opening or saving anything should be. This
is a pervasive flaw throughout kde4. For example, if I want to change my
wallpaper, I rt-click on the desktop and choose "Desktop Activity Settings.."
The dialog appears and I currently have the "time-blue-lt1" wallpaper in use
from my ~/img/wp/abstract/scene directory and I now want to choose the
'time-blue-1.jpg' file from the same directory. So right clicking and choosing
desktop activities the time-blue-lt1 wallpaper as being current:

(see: kde-noDirHint_01.jpg  -- attached)

    But, instead of taking the "hint" to open the file select dialog in the
'current' ~/img/wp/abstract/scene directory, KDE4 simply opens the file select
dialog in the ~/ directory (see attachment _02.jpg) forcing you to navigate
img/wp/abstract/scene to get to the same directory as the 'current' wallpaper. 

(attachment: kde-noDirHint_02.jpg)

    This is wrong behavior. Every other desktop, kde3, gnome, etc.. does what
modern software is suppose to do -- it anticipates what the user wants to do
next and selects the directory from the current file to make changing, doing,
opening, whatever -- a more efficient process.

    KDE4 completely fails in this regard. It's like somebody forgot to
implement the same logic that we had in KDE3 that made using the desktop very
enjoyable and efficient.

    I don't know what the "technical term" for this logic is, but KDE should
select the current directory for whatever file is currently being used and
present the 'current' directory to the user though the file-open, file-save and
file-save-as dialog every time something is chosen or selected. It's the
difference between a mature desktop or a hack.

    I expect to have to hunt and work a little harder in PEK or Sawfish, but
not in KDE4. Especially since we had the "select the current directory" logic
in KDE3. Now this example of changing the wallpaper is just one example. No
matter what you do in using or configuring kde4, kde4 fails to provide the user
with a logical starting point for getting to the data the user needs and
instead just shows your home directory. This seems like some system wide logic
could be easily implemented to solve this deficiency. Even something as simple
as a bit of BASH basedir logic to set the current dialog directory would be
100% better than providing no such logic. For the wallpaper problem something
like:

dlgdir=${wallpaper%/*}

and then setting the starting directory as dlgdir would work.

I'm sure in KDE with all the whizbang inheritance and polymorphism there is
some concept of what the "current-object" is. Applying this logic to the
current-object should solve the problem.

** attachments to follow


Reproducible: Always

Steps to Reproduce:
try to do anything in kde -- or use the example above if you can't think of
anything else..

Actual Results:  
see above -- I was presented with a file dialog that just dumped me into my
home directory

Expected Results:  
to be presented with a file-dialog that has the current directory set to the
same directory as the current object in question

Nope -- that's it..

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Unassigned-bugs mailing list