Bug 42677 - When user opens document, set initial path to same as currently focused document
Summary: When user opens document, set initial path to same as currently focused document
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdevelop
Classification: Applications
Component: All editors (show other bugs)
Version: 2.1
Platform: Mandrake RPMs Linux
: VLO wishlist
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-16 09:03 UTC by germain
Modified: 2007-02-23 12:01 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description germain 2002-05-16 08:57:00 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kdevelop
Version:           2.1 (using KDE 3.0.1 (CVS >= 20020327))
Severity:          wishlist
Installed from:    Mandrake Linux Cooker i586 - Cooker
Compiler:          gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
OS:                Linux (i686) release 2.4.18-6mdk
OS/Compiler notes: 

That way when you know the document you want to open is at the same location than an already opened one you just give the focus to that document before hitting "open".

Very intuitive save a lot of filesystem browsing and certainly a trivial change.

The current behaviour of "open last accessed path" is a *pain* when you are juggling with multiple locations.



(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Harald Fernengel 2002-05-20 15:29:34 UTC
Hi

why don't you use the bookmarks of the file dialog? You can add your favour=
ite=20
directories there so you can access them very quickly.

Best regards
Harry
Comment 2 Germain Garand 2002-05-21 08:52:33 UTC
Le Lundi 20 Mai 2002 16:29 Harald Fernengel a =E9crit :
> Hi
>
> why don't you use the bookmarks of the file dialog? You can add your
> favourite directories there so you can access them very quickly.
>
> Best regards
> Harry

I do use them but that's definetly not suitable for that use because :

1) it's global so it will pollutes ALL your file dialogs with stuf that is=
=20
specific to one project and not necessarily frequently accessed.=20
2) you've got to know BEFORE opening the file that you'll need a bookmark t=
o=20
it.=20

 Let's take a simple real life example : you want to build a kioslave so=
=20
naturally you'll want to have a look at existing ioslaves ... you open sa=
y:
/somewhere/CVS/kdelibs/kioslave/ftp/ftp.cc
 (why would you bookmark such a funny thing)

Now you need to read the notes you jotted about your project so you open so=
me=20
private documentation
/home/me/dev/doc/rocking_project.txt

Then you go back to reading ftp.cc...and damn you see you need to have a=
=20
look at the ftp.h header file in the same directory than ftp.cc... so you h=
it=20
"open"...
and you are prompted with /home/me/dev/doc !
you browse back to the deeply nested thing above open ftp.h only to discov=
er=20
that you made invalid assumptions about ioslaves so you'll need to switch =
to=20
plan B described in :
/home/me/dev/doc/alternate_project.txt

Get the picture ?

It would be so simple if once a file has been opened every time it gets th=
e=20
focus in the editor hitting the "open" button brought you it's directory...
Comment 3 Amilcar do Carmo Lucas 2004-07-20 17:23:01 UTC
It is still valid :(
Comment 4 Jens Dagerbo 2004-07-28 18:38:37 UTC
Maybe it's "valid", but that doesn't mean it's sane.. ;)

Seriously, I understand the problem he wants to solve and agree that the proposed solution perhaps is the "least effort" way of doing it, but I don't think it's the least bit intuitive. And doesn't the KDE file dialog history keep track of visited locations? Isn't it enough to use that? 

Btw, the FileSelector plugin's bookmarks are not global. If that is of any help.
Comment 5 Amilcar do Carmo Lucas 2004-07-28 18:44:36 UTC
He basicaly wants KDevelop to behave like emacs regarding the file open command.

Putting it to VLO priority
Comment 6 Andreas Pakulat 2007-02-23 12:01:41 UTC
As far as I understand this is a wontfix, as we don't think this is sane behaviour (and I do think so too).