|
|
Author |
Message |
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
 Posted: Mon Jul 24, 2006 8:21 pm Post subject: Manually downloadable member list |
|
|
Status: Included in version 1.4.0
From the 1.4.0 alpha thread:
| impishfae wrote: |
| Connecting to my test server, I noticed it wasn't synchronising my local member list properly. (In fact, it looks like it's wiping the local copy). |
| Quote: |
| Everything else is able to be downloaded on connection and via the option, so I figure the member list should to. Keep 'em both. |
The current way the member list works is not very intuitive. As impishfae pointed out everything else can be downloaded both via the menu and an option, that should be possible with the member list too.
The member list currently works in the following way. A file with a list of members is kept in the client's work directory. That file is only used when one is not connected to a server. In that file one can freely add and remove members. When one however connects to a server that server's member list will be downloaded and overwrite the existing local member list (but it's only used from the memory).
When connected one is basically working directly against the server, whenever one asks to add a member that request is given to the server, then the client will request the new member list from the server and display that instead. Removing members is not allowed when connected to the server.
A couple of problems with this system is that
1. The local member list only exists until one connects to the server, then it's overwritten.
2. It is totally different from the way member-aliases, autocompletion and the configuration works when storing them on a server.
So the question is how to change the way that the server's member list is treated so that it becomes more intuitive and similar to the others.
Last edited by Lokorin on Wed Aug 23, 2006 3:50 pm; edited 2 times in total |
|
Back to top |
|
 |
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Tue Jul 25, 2006 5:55 pm Post subject: |
|
|
One way to change it is to change it so that one always works against the local copy of the member list. It would work just like the configuration, but when uploading the member list to the server one would instead be comparing the local list vs the server's list and add all members that are missing. I think this was how impishfae means. The reason that it's not like this at the moment is that the member list was built long before the other sevrer-synchronizable things, so it's more of a legacy solution. |
|
Back to top |
|
|
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Tue Jul 25, 2006 10:37 pm Post subject: |
|
|
Well, initially I just meant I wanted to perform whatever operation happens to your member list when you connect to the server.
But now I realise it overwrites the local copy, I'm definitely hankering for a merge.
Usual problem with a merge occurs though: how do you tell what's latest?
Say the client has member list A, B, C as does the server.
Then a member leaves the guild and is removed from the server (the only place you can remove them) so you're down to A and B on the server.
The client parses its log file and discovers that A, B and D were on the raid.
So now we have client list: A, B, C, D with server list A, B.
If the client adds in members that are missing that it has in its local list, 'C' will reappear on the server.
So maybe client first removes anybody it has in its list that the server doesn't have, adds any members the server has that it doesn't, then uploads any members new from the current raid? Will that take care of the merge issue? Not sure... |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Wed Jul 26, 2006 7:03 am Post subject: |
|
|
I think that would basically have the same effect as checking the new options for automatically downloading the member list on connect and automatically uploading added members on exiting the program. That would require that one connects to the server before parsing though.
So the client has A, B, C - The server has A, B
The client connects to the server and downloads the member list A, B. So both the client and the server now has A, B.
The client parses the log and adds D to its member list. So the client has A, B, D - The server has A, B.
The cient is closed and all members that do not exist on the server (D) are added, both the client and server now has A, B, D. |
|
Back to top |
|
|
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Wed Jul 26, 2006 8:10 am Post subject: |
|
|
ok! Works for me.  |
|
Back to top |
|
|
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Sat Jul 29, 2006 7:33 am Post subject: |
|
|
I saw you've done this one already (fast work!).
From a usability perspective, can you swap the order of the menu items around? The most common operation a user will be performing in the 'upload' menu is 'Upload/Day'. They have to do that every time they use DKPLP or the whole point of the operation is lost. (Some days I want a big button on the UI somewhere that just says 'GO' for easy uploading!)
It makes more sense to have the 'Day' at the top of the upload menu. And put Member List (in upload and download) next to the member aliases. |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Sat Jul 29, 2006 9:26 am Post subject: |
|
|
| Quote: |
| From a usability perspective, can you swap the order of the menu items around? |
Done |
|
Back to top |
|
|
|
