User talk:Standard8: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Reverted edits by TeleComNasSprVen (talk) to last revision by Standard8)
(Replaced content with "== Random Test == * https://hello.firefox.com (3 redirects) * https://www.mozilla.org/firefox/hello/ (2 redirects) * https://support.mozilla.org/kb/hello-status (1 redire...")
 
Line 1: Line 1:
== Thoughts about linking views to searches ==
== Random Test ==


At the moment we have two problems:
* https://hello.firefox.com (3 redirects)
 
* https://www.mozilla.org/firefox/hello/ (2 redirects)
* a view doesn't know a search is going on.
* https://support.mozilla.org/kb/hello-status (1 redirect)
* a search doesn't know which view the search results should be going to (asynchronus case).
* https://support.mozilla.org/en-US/kb/hello-status (final page)
 
The relevant classes are nsIAbView and nsIAbDirectory.
 
Currently the following process occurs:
 
# The user selects an ab or enters some search parameters
# The view is initialised creating a reference to an appropriate nsIAbDirectory
# An nsIAbView Enumerates the cards, which calls nsIAbDirectory->GetChildCards
#* Unimplemented in nsAbDirProperties
#* nsAbMDBDirectory and nsAbOutlookDirectory find the cards and return them straight away
#* nsAbLDAPDirectory if offline returns cards straight away
#* nsAbLDAPDirectory if online calls StartSearch and returns with no items.
# the nsIAbView then adds any returned cards to the view's result list.
 
If an ldap online search then:
# StartSearch sets up the appropriate search parameters
# Creates a nsIAbDirectoryQueryResultListener to handle the search results
# Calls nsAbLDAPDirectoryQuery::DoQuery which sets up the listeners and kicks off the connection.
# (then wait for the results)
# As the results are returned, nsAbQueryLDAPMessageListener::OnLDAPMessage handles them.
# They will eventually turn up in nsAbDirSearchListener::OnQueryItem
# followed by nsAbLDAPDirectory::OnSearchFoundCard
#* nsAbLDAPDirectory::OnSearchFoundCard doesn't know about searches and views
#* Notifies the nsIAddrBookSession that something has been added to the directory.
#* All nsIAbView items that are connected to that directory will then pick up the notification of something added and add it to thier view
#* This is wrong and causes bugs.
 
A Solution:
* When nsIAbDirectory->GetChildCards is called, if a asynchronus search is required, then return NS_ERROR_SEARCH_REQUIRED
* Provide nsIAbDirectorySearch::addResultListener/removeResultListener with a nsIAbDirectoryQueryResultListener option.
* Where searches are required, its up to the caller to decide if an extra listener is required or not.
* StartSearch does what it needs to.
* When results come in, any listeners are called with the appropriate functions.
 
Notes:
* The solution would pave the way for full fixes to [https://bugzilla.mozilla.org/show_bug.cgi?id=135231 bug 135231] (LDAP Quick search results keep duplicating with searches in Address Book, Select Addresses dialog and Sidebar) and [https://bugzilla.mozilla.org/show_bug.cgi?id=327269 bug 327269] (UI lacks proper progress indication for lookups)
 
== Card Pane View ==
 
The current Address Book card preview pane view is based on a XUL overlay. It has many elements (one for each address book field) that are hidden if empty, or displayed if not. These are updated for each card. There various disadvantages to this:
 
* Description elements aren't selectable for copy. This means addresses/text can't easily be copied out of the display.
* Email and Http Links don't work correctly.
* No context menu (though this maybe could be enabled with some work).
 
My current thoughts on this are to remove the current XUL overlay, replacing it with a browser element. The current XML generation code for printing cards could then be replaced/reworked to cope with both printing and the card preview pane. This would give the following advantages/disadvantages:
 
Advantages:
 
* Reuse of code - same code for printing & previewing cards.
** Smaller code size
** Only one central place needed for addition of new items.
** Could be potentially overriden for different types of cards to display more/less fields depending on requirements.
* Different display formats available if XML & CSS written & used correctly?
* All text selectable with copy & paste free-of-charge (fixes [https://bugzilla.mozilla.org/show_bug.cgi?id=96968 bug 96968]).
* Links and Email addresses should be able to be linked in to normal browser functions.
* Context menu should be easily available/useable.
* Could easily fix [https://bugzilla.mozilla.org/show_bug.cgi?id=117767 bug 117767]? Captions (Display name:, Home:, Fax:)in card pane should look different
 
Disadvantages:
 
* Format of XML may be specified completely in code, depending on how its written.
* Performance impact?
 
Check:
 
* Localization - need to be able to localize it. Can we learn from help here?
* [https://bugzilla.mozilla.org/show_bug.cgi?id=92321 Bug 92321] Make the view pane editable in addressbook - would we really want to do this? Its a nice idea, but is it really practical?
 
To Fix:
 
* [https://bugzilla.mozilla.org/show_bug.cgi?id=276722 Bug 276722] Long "Notes" on "Other" tab makes phone no. wrap in pane view.
 
== Address Book Migration ==
 
With the current work in address book to try and make it more pluggable, easier to work with, and the hopeful removal of nsDirPrefs we need to replace the existing address book migration code with something better.
 
The existing migration code is contained in two places:
 
* [http://lxr.mozilla.org/mozilla/source/mailnews/addrbook/src/nsDirPrefs.cpp#1956 nsDirPrefs.cpp DIR_GetServerPreferences]
* [http://lxr.mozilla.org/mozilla/source/mailnews/addrbook/src/nsLDAPPrefsService.js#121 nsLDAPPrefsService.js migratePrefsIfNeeded]
 
Currently the migration code is actually capable of the following:
 
* migration of ldap ab preferences from 4.0 to 4.5
* migration of ldap ab preferences from 4.5 to Mozilla.
 
It can cope with normal ab preferences, however, as 4.5 used the closed na2 format, we aren't able to migrate that and no one has stepped up to write something suitable.
 
It is all based around the DIR_Server that we would really like to get rid of. This all brings the following questions:
 
* Where should migration code exist?
** Should it be with the nsIAb*Directory or nsIAb*DirectoryFactory code?
** Should the existing items be consolidated into one location or split?
* How will this affect future migration code writing if they are necessary?
** This may be required if we change the setup of ab prefs.
* Should we be calling a general nsIAb*Directory or nsIAb*DirectoryFactory migrate function on startup anyway?
 
==== Some thoughts on how to do it ====
 
* AB migration only works for LDAP servers.
* Drop all other ABs during migration apart from LDAP ones
* Can we move AB migration into the profile migration code?
** are these right:
*** Netscape 4.x profiles migrated into new TB/SM can only be done by profile migration
*** Netscape 4.x -> Mozilla version x -> latest TB/SM would have the conversion done at mozilla version x stage, or could be done in the profile migration once new SM has new profile location (suiterunner will provide this) - tb already requires profile migration.
** if not, then can we find something that is always called first/make it called first to do the work for us? e.g. nsLDAPPrefsService::migrate?
 
== Collected Address Book Removal? ==
 
CAB = Collected Address Book
PAB = Personal Address Book
 
Drivers:
 
* Thunderbird doesn't want to keep the CAB - the default is to collect to the PAB. (see [https://bugzilla.mozilla.org/show_bug.cgi?id=267877 bug 267877] )
* SeaMonkey also has the default to collect to the PAB.
* Keeping the CAB as it is means that users who don't use it are forced to have an extra address book [https://bugzilla.mozilla.org/show_bug.cgi?id=171125 bug 171125]
* Keeping the CAB as it is also gives us a little bit more bloat that we don't necessarily need/want.
 
There was some discussion quite a while ago about what was required and SeaMonkey was thinking of doing something slightly different which I haven't got logged. So the solution below is what is sensible, but SeaMonkey may want to add something to it.
 
==== Solution ====
 
Remove the CAB specific bits of code, so that:
 
* the CAB is no longer forced by default
* it can be deleted if required
* BUT existing CABs will still be loaded/useable etc (and of course deletable!)
 
== Importing Address Book discussion ==
 
=== Driving bugs ===
 
[https://bugzilla.mozilla.org/show_bug.cgi?id=99936 Bug 99936] Import Address Books, what should address book names be?
 
Discusses changing imported names to "Imported Address Book n" for Outlook & Express, Eudora.
 
[https://bugzilla.mozilla.org/show_bug.cgi?id=46050 Bug 46050] Address Book name must be unique in the app (disallow duplicate names)
 
I think this would be useful as it's a UI aid, especially when selecting address books from picker lists.
 
[https://bugzilla.mozilla.org/show_bug.cgi?id=102010 Bug 102010] Warning needed for duplicate Address Book while importing from 4.x
 
Really should apply to all address book imports.
 
=== IRC Chat (extract) ===
 
Standard8: What do folks think, when importing address books, should a) use the file name (as we do now) the user has to manually rename it, b) prompt for a name using filename as default, c) prompt for a name using "Imported Address book n" as default.
 
prompt = extra page on import dialog wizard.
 
dmose: so when an addressbook is imported, you're importing from an ldif file and that ldif file doesn't contain the pretty name of the addressbook in the old profile or are you talking about cases other than important from 4.x?
 
Standard8: dmose: I didn't know ldif files could contain the pretty name of the address book.
 
dmose: i don't think they can
 
Standard8: I'm talking about import from ldif files (on disk)/csv/txt etc
 
dmose: ah, ok
 
Standard8: at the moment we just get a file selection dialog and it's the name of the file.
 
dmose: to be honest, all three of those sound reasonable to me. i guess i have a very slight preference for b). but i could easily be talked into one of the other choices.
 
NeilZZZ: hasn't actually used import in anger
 
Standard8: NeilZZZ, atm the user just gets lumped with the name of the file and they have to rename it via a seperate process, also, means we can get duplicate address books. There's a bug somewhere suggesting there should be a way of specifying it when we import it, there's also bug 99936 suggesting to change all imported books to "Imported Address Book n"
 
NeilZZZ: ah, well the wizard should check for that at the very least
 
timely: are we importing from things that have names? Imported Eudora Addressbook
 
beltzner: so scenario is that user has tb up and running, wants to import addressbook?
 
timely Imported Eudora Addressbook (2)
 
dmose i think we typically don't know the source the user just says "Import Addressbook" and up pops a file dialog
 
timely how can we not know the source? so this is .ldif? well, there's the filename :) does ldif have absolutely no hinting?
 
dmose we should check re the hinting but there will definitely be cases where there is no hint which is the question of the moment
 
timely what's the argument in favor of changing our current behavior? does someone dislike it?
 
Standard8 bah, can't find the bug. I think we need to change it a little at least - import same file twice, and get two address books of the same name, this then becomes confusing when we list the books in menus. there's also bug 99936 which requests all the names of imported address books to be consistent.
 
timely i'd much rather we figure out our in-line-editing story (of address book list) finder lets you click on a filename and rename it
 
beltzner The other way to do it would be to use the filename, but put the label of the addressbook in editmode when the import completes
 
Standard8 I think this may actually all be born out of bug 46050 - address book name must be unique in the app.
 
Standard8 so if we're going for b (prompt for name, default to filename but unique) for ldif/csv/txt etc files, or at least making the existing filename unique, what do people thing about bug 99936, which covers importing from other apps?
 
dmose so an interesting question here is what the typical case is likely to be as far as how many addressbooks people have because having an "addressbook" named "addressbook" is kinda silly anything in that pane is going to be an addressbook
 
Standard8 so "personal address book" is a bit redundant as well then. or rather we could just name it personal
 
dmose seems that way to me maybe this is stuff where i start deferring to beltzner
 
beltzner dmose: I'm not sure that the casual user wants >1 addressbook. I mean, this is going on instinct, but with search tools being what they are, I can't see many casual uses for segmentation
 
Standard8 has 5 address books.
 
beltzner where it gets interesting is when you can share addressbooks
 
dmose well, ldap servers are already represented as addresbooks
 
beltzner I was kinda lumping that into the "shared" definition
 
Standard8 I think when we discussed it for seamonkey, we came up with the idea of not creating it by default, but suggesting the use if the user enabled collection or something like that.
 
timely and yeah, naming an address book "addressbook" always seemed silly "Collected Addresses" and "Personal" are good names "Collected Address Book" or whatever was long and wordy (good luck finding a shorter name than collected addresses)

Latest revision as of 15:23, 10 November 2016

Random Test

Retrieved from "https://wiki.allizom.org/index.php?title=User_talk:Standard8&oldid=1154238"