[PATCH] Ticket #473: Add option of saving User ID in xml

Venkatesh Shukla venkatesh.shukla.eee11 at iitbhu.ac.in
Fri Apr 4 07:12:42 PDT 2014


First of all, I apologize for my mistake of not adding the mailing list in
my reply. I realized it just now that I haven't.

On Fri, Apr 4, 2014 at 12:19 AM, Dirk Hohndel <dirk at hohndel.org> wrote:

> On Thu, 2014-04-03 at 23:26 +0530, Venkatesh Shukla IIT BHU wrote:
> >         I think Lubomir's question was about the preference order...
> >         we store
> >
> >         the userid in the settings AND we store it in the XML file. If
> >         both are
> >         present, which one is given preference?
> >
> >
> >
> > In the present implementation, the event which happens later decides.
> > If a new file is loaded, the userid 'a' of the file would take
> > preference. If in this new file, the user opens the download dialog
> > box and downloads dives with another userid 'b' and saves it, b will
> > be stored in the file. Also, as before, b is stored in the subsurface
> > settings.Maybe we should introduce this as a preference for the user?
> >
> >
> > I have few questions regarding this.
> > 1. If a new xml file with different userid is loaded, should
> > subsurface settings be changed to replace the old with the new?
>
> That's an interesting question. I would say no. That's a file specific
> setting that should not override the local setting.
>
> I think the right semantic is this:
>
> - if the user enters a user id in the dialog, that user id is saved in
> the local settings
> - if the user clicks the setting to save it to XML, it's saved to both
> - if the user has a local setting that populates the dialog. If the user
> opens a file that has a per file userid, that is used instead - but it
> doesn't change the local setting


I have taken care of the above semantics in the attached patch.

Explanation :
When a new file is loaded,
1. If it contains user id, saving of userid is enabled. Also, this shows up
in the textbox in the download dialogbox. And the checkbox is ticked.
2. If it doesn't contain userid, saving userid is disabled. The textbox is
filled up with userid from subsurface settings. Checkbox is unticked.
If checkbox is unticked, userid is not stores in xml file.


Now, if there are userid of dialogbox, xml file and subsurface settings,
there are these 5 cases possible.
1. All three uid are same. Nothing needs to be done. Save it everywhere.
 2. All three uid are different. User has manually input a UID in the
dialogbox. Save it everywhere.
 3. Settings == File !=  Dialog UID : User has manually input a UID. Save
it everywhere.
 4. Settings == Dialog != File UID : User has changed the file UID to
settings one. Save it everywhere.
 5. File == Dialog != Settings UID : Xml file with different UID than saved
is loaded. Use the file UID to save in the file. But leave the settings as
they
    were.

Everywhere corresponds to xml file and subsurface settings.


> > 2. After the download of dives from subsurface webservice, if the
> > checkbox is ticked, should save-xml be called automatically?
>
> No
>
> >  Currently, the user has to save manually after download for the
> > effect of userid inclusion/exclusion to take place.
>
> A successful download should modify the file (as it adds GPS data and
> possibly dive site names). And because of that the user will be asked to
> save before she quits Subsurface
>
> > Okay Dirk, I'll study libgit2 and try to achieve what you have said.
> > It is indeed a good idea.
>
> Thanks


I am still working on this part.
I have tried to follow the CodingStyle document.

Regards
-- 

*Venkatesh Shukla *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140404/71520a28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-option-of-saving-subsurface-userid-in-xml.patch
Type: text/x-patch
Size: 8906 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140404/71520a28/attachment-0001.bin>


More information about the subsurface mailing list