Bug 64279

I can confirm that the File Selector options doesn't persist. 

I'm not sure what cvsservice options are referred to...

I can add one more broken option. The project run options, especially the executable, don't *seem* to get saved. Actually they do get saved and the project can be debugged using them, but if you open up the options window again, it apparently fails to read the options back in for editing, and you get blank fields. The original options are now lost and must be re-typed before hitting 'ok'.

This still exits in Beta-1

"the executable, don't *seem* to get saved"

If the path to executable is to be absolute then it MUST start with / otherwise it gets cleaned up. This is not a bug! The GUI is explicit enough!

Again, can you be more specific about what other options do not presist?

Subject: Re:  kdevelop doesnt store some global/project settings

Amilcar do Carmo Lucas wrote:

>------- You are receiving this mail because: -------
>You are a voter for the bug, or are watching someone who is.
>     
>http://bugs.kde.org/show_bug.cgi?id=64279     
>
>
>
>
>------- Additional Comments From a.lucas@tu-bs.de  2003-11-07 10:44 -------
>"the executable, don't *seem* to get saved"
>
>If the path to executable is to be absolute then it MUST start with / otherwise it gets cleaned up. This is not a bug! The GUI is explicit enough!
>
>Again, can you be more specific about what other options do not presist?
>  
>
It's not absolute. The GUI above says that it is relative from the build 
directory. There are three radio button selects there. the one chosen by 
default is 'relative from build directory'. So I simply typed in the 
name of the executable. I obviously typed in the correct name with the 
correct path (which is no path in this case), since (as stated before) I 
CAN debug the executable. In other words, gdb got called with the 
correct parameters to find the executable. Its just that when I enter 
the dialogue again it gets lost.

In any case, isn't it sort of counter-intuitive that the GUI will 
actually destroy something that I typed in explicitly without at least a 
dialogue or something? What if I had typed in the absolute path on 
purpose, but clicked the wrong radio button? I'd get pretty annoyed with 
having to fix both the radio button and the path (again). Possibly even 
more annoyed than I get right now when I have to type in the executable 
name again when it was obviously working as entered last time.

Sorry, I can not duplicate it here (HEAD)   :(

I'm the author of that particular piece of code and I don't remember changing it since b1 release. But you say it exist in b1, can anybody else replicate this?

I do:
Project settings... -> Run Options
Set to relative to build dir
Set the executable path
click ok
Project settings... -> Run Options
ALL is OK
Close project
Open project
Project settings... -> Run Options
ALL is OK

Alright, I've discovered some more, hopefully useful information. I had original specified my make directory as a relative directory from the place where the kdevelop project files are stored: 'Builds/BobsBuild'. The executable was then specified relative to this directory: 'BobsBuild'. (So the concatenated path would be 'Builds/BobsBuild/BobsBuild'.) When I would close the options dialogue after setting both of these values, I can both build and run the executable. However, upon re-opening the dialogue, the definition for the executable would disappear. And unless I typed it in again before closing the dialogue, I would no longer be able to use gdb afterwards.

However, I recently changed the specification of the Make directory to an absolute path: '/x/y/Builds/BobsBuild' Where the upper path '/x/y' is changed for the purposes of this bug report to protect the innocent. Upon doing this, the problem went away.

Another possibly important piece of information is that the top most directory 'x' is a symbolic link to elsewhere in the directory tree. I haven't tested with a non-symbolic-link tree to see if the problem still exists with the relative path specification. I doubt that this will have any effect, though: Unless kdevelop is doing something really wierd.

In addition, I noticed another issue, that maybe deserves its own bug, but falls under the all encompassing scope of this one: Under Settings->Configure KDevelop->File Selector, the three options to customize Auto-Synchronization get lost across program exit/restart cycles.

Subject: kdevelop/parts/fileselector

CVS commit by dagerbo: 

Make FileSelector save/restore settings properly. This fixes the remaining verified issues reported in #64279.

Patch reviewed by Anders Lund.

CCMAIL: 64279-done@bugs.kde.org


  M +0 -1      fileselector_part.cpp   1.21
  M +6 -4      fileselector_widget.cpp   1.12


--- kdevelop/parts/fileselector/fileselector_part.cpp  #1.20:1.21
@@ -54,5 +54,4 @@ FileSelectorPart::~FileSelectorPart()
 {
     if (m_filetree){
-        m_filetree->writeConfig( instance()->config(), "fileselector" );
         mainWindow()->removeView( m_filetree );
     }

--- kdevelop/parts/fileselector/fileselector_widget.cpp  #1.11:1.12
@@ -227,5 +227,7 @@ KDevFileSelector::KDevFileSelector( File
 
 KDevFileSelector::~KDevFileSelector()
-{}
+{
+        writeConfig( m_part->instance()->config(), "fileselector" );
+}
 //END Constroctor/Destrctor
 
@@ -685,5 +687,5 @@ KFSConfigPage::KFSConfigPage( QWidget *p
 void KFSConfigPage::apply()
 {
-    KConfig *config = kapp->config();
+    KConfig *config = fileSelector->m_part->instance()->config();
     config->setGroup( "fileselector" );
     // toolbar
@@ -740,8 +742,8 @@ void KFSConfigPage::reload()
 void KFSConfigPage::init()
 {
-    KConfig *config = kapp->config();
+    KConfig *config = fileSelector->m_part->instance()->config();
     config->setGroup( "fileselector" );
     // toolbar
-    QStringList l = config->readListEntry( "fstoolbar", ',' );
+    QStringList l = config->readListEntry( "toolbar actions", ',' );
     if ( l.isEmpty() ) // default toolbar
         l << "up" << "back" << "forward" << "home" <<

Robert,

I can't figure out if what you are seeing is a usability issue or a bug. If the issue persists, could you open a new bug (for the correct component) for that? This bug report is too "wide", I we keep it open ppl can keep stuffing items in it for years.. ;)