While opening or closing a DB, should the UI

1. Ask the core to read the DB, and if successful, enumerate over the DB items and add them to the UI element (tree or grid).  Similarly, when closing a DB, ask the core to clear all items and then remove all items from the UI element.

or

2. Ask the core to read/close the DB and add/remove the DB items on getting notifications from core?

Is the UIInterface interface class written for (2), or does it only serve to update the GUI when an item is edited/added/deleted individually?

(2) would be the correct approach. I'd disable updates for the duration, though, in order to prevent lots of annoying flashing when adding entries one after the other.

Keep in mind that the UIInterface was added retroactively, mainly to support undo/redo, so some of the older code, including opening/closing the db, might not have been adapted to it.

BTW - I've a decent .deb file that should allow non-developers to run pwsafe on Debian and Ubuntu platforms. Do you see any reason not to release this as an "early beta" say, over the weekend?

If (2) should be the correct approach, we probably need another method in the UIInterface to notify the UI that a new DB has been loaded.  I had earlier thought that the DatabaseModified() function was actually serving that notification, but as per David's earlier email, its not so.

David - am I correct here?

Reg: the .deb file, I don't think the Linux build is very stable yet.  Deleting entries in the grid definitely crashes pwsafe, and there also seems to be other problems adding/removing new entries from both grid and tree views.  Also, I have never tested the undo/redo functionality on Linux at all.  I think we should release the Linux build only after this much functionality works reliably.

Plus, we don't have the import/export support yet, so users using any other password manager will not be able to import their data into pwsafe to actually use it (or go back to their older PW manager if they create a new db).

There is no need for an extra call as the UI is the driver of opening a new database and therefore knows full well that it is a new database.  Remember, the UI drives the actions.  core does what it is told and tells the UI when things are changed due to its actions.

core will not open a new database without being told to do so by the UI.

In that case, (1) below (and not 2) in my first message is the preferred approach?

I am ok either way, but I need to know which one is the supported/expected way of doing things.  Right now, the Linux build is a mix of both approaches (and therefore crashes).

How about importing and merging databases?

Last point first - import and merge are still driven by the UI.  In fact, ALL actions are driven by the UI but the UI does not necessarily know if an action it has initiated has caused any change to the database.

Looking at the MFC code, during Open, core opens the database and, on success, the UI does the initial load of the UI (Tree/List).

core has no knowledge of the UI - only of the entries in the database.  After Open, when one or more entries change, it uses the UIInterface to tell the UI that it might have to change what the user sees.  For example, a field might have been changed but the user currently doesn't display it in the List view - for example the RunCommand field - so core tells the UI that it has changed and the UI decides whether the what the user sees needs updating.

So - (1) is probably correct.

Ok.  That settles things for me.  (1) is the way to go.  I will probably document this in the 'docs' directory.  May be just archive this email thread there, to begin with.

I have some other questions regarding the UIInterface also which I will send you later, once I have stabilized the Linux build.

Rony - you concur?

Yes, I concur - David worked in this area more recently than I did, so his memory is probably more accurate.