[Kmymoney-devel] Plugin Config File Install - SOLVED

[Allan]

On 01/01/12 12:20, Thomas Baumgart wrote:
> Hi,
>
> on Saturday 31 December 2011 12:34:19 Allan wrote:
>
>> On 31/12/11 02:00, Jack Ostroff wrote:
>>> Hopefully I'm not being too simplistic, but
>>>
>>> On 2011.12.30 12:18, Allan wrote:
>>>>>> So, after installation, those two sections are available, and I load
>>>>>> into memory from the default config file the parameters for the
>>>>>> chosen profile. When the plugin is closed, the current parameters
>>>>>> are saved to the user's ~/.kde/4 config location, but this new file
>>>>>> contains only the one profile, the one that was first loaded.
>>>
>>> Will there be any other profile managment as part of the UI? Renaming
>>> profiles? Deleting profiles?
>>
>> Yes, they are present at the moment - sort of.  One can edit the profile
>> name via the combobox.  At present,this actually works by creating a new
>> profile with the new name.  It removes the old name, but doesn't, yet,
>> delete the old group in the config file.
>>
>>> Now, think about a "future" scenario: the user has three profiles saved,
>>> and creates a new one. I assume you have to read in the current file (or
>>> have already done so) and take those three, add the new one, and write
>>> out four to the rc file. Therefore I assume you already have some way of
>>> saving an rc file including one or more profiles that have not just been
>>> used.
>>
>> There isn't actually a 'future' problem.  If the user has created a few
>> profiles, he has used them, one at a time, and they will have been
>> saved, at the end of that import process.
>>
>>> Perhaps if there are no profiles saved in the local file (or there is no
>>> local file) then you automatically read in the sample profiles and save
>>> them, whether or not either of them was actually used.
>>
>> This is closer to the problem.  In normal use, the user will have
>> selected one profile, and that profile is read in and used to set up the
>> UI.  When done, the current settings are saved locally to the current
>> profile.  Any other profiles in the config will not have been read in,
>> or rather have been read in and discarded because the purpose is to set
>> up the UI.  Again, this is not a problem.  However, on the first run,
>> there is no local config file yet, as I haven't yet found a way to
>> detect where that distro has its ~/.kde or ~/.kde4 file.  There appears
>> to be a KDEHOME variable, which sounded  useful, but that presumably
>> would have had to be set by the distro, and mine is empty, and The
>> config got installed to root,  I need to know this at compile time, to
>> tell cmake where to install the config file.  So, I have to install to
>> the default location, /user/share/kde4/config.  Then, on the first run,
>> if the user selects one of the two sample profiles, that profile, and
>> that profile alone, is read in and used to set up the UI.  The other
>> sample profile remains on the config file, in /user/ etc.  When the user
>> exits the import run, the current settings are saved, to the newly
>> created local config.  As no other profiles have been read in, they
>> cannot be saved to the local config file.  And that is the nub of the
>> problem - the creation of the first local config.  Newly created
>> profiles will get saved, but not those in the default file.
>>
>>> You could also have a button somewhere to "Reload all sample profiles"
>>>
>>> I don't think any of this actually solves the problem, but hopefully it
>>> might give you something to chew on.
>>>
>>> Jack
>>
>> All that said, overnight I thought of a possibility so now to try it.
>
> Thinking a bit further, this might not be only a problem of providing initial
> templates by the devs but also those templates might be provided by the
> community as well and are certainly not tied to a KMyMoney release. This
> thinking leads to
>
> http://techbase.kde.org/Development/Tutorials/Introduction_to_Get_Hot_New_Stuff
>
> Maybe worth a look. The profiles will then be file based and not in an ...rc
> file anymore, but that is just implementation and can be solved.
>
> Just my first 0.02 in the new year.
>
I thought your email must have crossed with mine, but realised I hadn't 
actually sent  it!  Anyway, here's what I had meant to send.
"
Well, after much trial and tribulation, I got there.  I found out how, 
on first run after installation, to get the sample profiles into the 
local config folder.

What I do is to copy the groups from the default config file into a new 
file, which, on saving ends up in the right local folder.  Then, proceed 
as normal, with the sample profiles available.  Sounds simple.

It also sounds a good way to 'delete' unwanted profiles from the file, 
as it will copy just the valid profiles named in the selector combo."


I'll certainly have a look at that article.  However, my problem related 
to the build and install of a new user.  Any contributed profiles could 
be dropped into 'contrib', although that still leaves getting them 
added/available.  So, off to the article.

Thanks

Allan