[sip-comm-dev] First Contact Info Example


#1

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that. Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

Adam

Contact Info 06-25-2007.zip (179 KB)


#2

Hi Adam,

I've just tested your alpha contact info plug-in and it works well.

Before answering your questions I would like to make some suggestions about the user interface, because I have imagined it a little differently, something like this:
  - left panel containing the list of sub contacts - here you could use a JList, instead of JTable, because it'll look simpler for the user.
  - center panel containing a JTabbedPane with two tabs: Summary and All details. In the Summary we will have a photo, all the names, gender, age, birth date, e-mail, phone number (you could see the attached file, which is a screenshot from Miranda contact details form, it's just an example how we could arrange labels). The "All details" tab will contain a table with two columns: "Detail name", "Detail value". There we could put all details coming from the protocol.

The idea would be the same as you said in your mail, when you click on a
contact in the list in the left, the right panel will load the details
of the chosen protocol contact.

Below you'll find some inline comments and answers to your questions.

Adam Goldstein wrote:

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

You should be even more explicit:) We've created the specific ContactDetails classes (like FirstNameDetail, LastNameDetail, etc.) with the idea that in the GUI this will facilitate the access to a concrete detail. Thus in the ContactInfoProtocolPanel you don't need to make this:

Iterator iter = ssci.getAllDetailsForContact(contact);
          while (iter.hasNext())
          {
              GenericDetail detail = (GenericDetail) iter.next();
              if (detail instanceof BinaryDetail || detail instanceof
ImageDetail)
              {
                  standardInfo[0] = detail;
              }
              .........
          }

and then invoke this: imageLabel = new JLabel(new ImageIcon(
                          (byte[]) standardInfo[i].getDetailValue()));

If we talk in the terms of contact details with a "Summary" and "All details" page you'll have the following situation:

For the Summary page you should directly call ssci.getDetals(Contact
contact, Class detailClass) for each of the details. For example if you
want to show the first name, you should have:
  JLabel firstNameLabel = new JLabel("First name:");

which won't change when changing contacts. And you should have another:
  JLabel firstNameValueLabel = new JLabel();

and when you click on a Contact on the left you should make:

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())
{
  firstNameValueLabel.setText(ssci.getDetals(contact,
FirstNameDetail.class).next());
}

Thus you will set the first found detail for the first name property.

For the "All details" you should just call:

ssci.getAllDetailsForContact(contact);

and insert all details from this list into a table. And that's it.

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that.

Yes, exactly. I've changed it. Now ImageDetail extends BinaryDetail.

Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

I agree. We could have a NotesDetail which will extend StringDetail.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

I think it's not implemented yet. Damian, do you have an idea about this?

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

This is a good idea, but be careful, because you have to consider the
fact that the Local User Info form should be added as a
ConfigurationForm in the ConfigurationWindow.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

It runs fine and it's not so basic and you didn't make any terrible
mistakes:)) I think it's great that we have a base already on which we
could discuss. I think you're going in the right direction, you should
just try to stay simple and don't add many complex functionalities (I'm
talking about the Search). I'm not sure if I have explained well how I
imagine it, so if you have any questions, or something you don't
understand, please ask. Also if there's something you don't agree, don't
hesitate to discuss it.

Yana

···

Adam

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Adam,

about the pictures for icq contacts. Pictures of contacts can be retrieved by contact.getImage.
This is implemented not only for icq but also and for jabber and yahoo. Is this approach ok ?

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Yana,

Thanks for all of the comments. I think I understand how you're describing you envision it, but let me check just to make sure. The left panel containing a JList with the sub contacts rather than a JTable is no problem, and getting rid of the search is probably a good idea. On the right, I think you were saying a JTabbedPane, but with just Basic and All views. Do you think rather than putting all of the information into the extended tab, it would be alright to make more tabs, similar to how it is done in the Miranda picture, except with tabs instead of buttons on the left. So all together, the strategy would be similar to that picture, but with tabs instead of clicking on the left, it leaves the space for the subcontact list on the left while still remaining relatively compact. Does that sound like what you had in mind?

I was a bit confused about what you were saying about the FirstNameDetail. You were saying it should be consistent across subcontacts, but that doesn't seem like it would necessarily be true. Someone may use entirely different names for each account, so it seems like that should be updated each time. Also, you were saying to use the line

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())

but I don't really understand that. In what event would a contact have more than one FirstNameDetail? I understand iterating through maybe an InterestDetail, but I didn't quite understand that comment.

Oh, and Damian, thanks for the change in the detail. I appreciate it.

Adam

Yana Stamcheva wrote:

···

Hi Adam,

I've just tested your alpha contact info plug-in and it works well.

Before answering your questions I would like to make some suggestions about the user interface, because I have imagined it a little differently, something like this:
    - left panel containing the list of sub contacts - here you could use a JList, instead of JTable, because it'll look simpler for the user.
    - center panel containing a JTabbedPane with two tabs: Summary and All details. In the Summary we will have a photo, all the names, gender, age, birth date, e-mail, phone number (you could see the attached file, which is a screenshot from Miranda contact details form, it's just an example how we could arrange labels). The "All details" tab will contain a table with two columns: "Detail name", "Detail value". There we could put all details coming from the protocol.

The idea would be the same as you said in your mail, when you click on a
contact in the list in the left, the right panel will load the details of the chosen protocol contact.

Below you'll find some inline comments and answers to your questions.

Adam Goldstein wrote:

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

You should be even more explicit:) We've created the specific ContactDetails classes (like FirstNameDetail, LastNameDetail, etc.) with the idea that in the GUI this will facilitate the access to a concrete detail. Thus in the ContactInfoProtocolPanel you don't need to make this:

Iterator iter = ssci.getAllDetailsForContact(contact);
         while (iter.hasNext())
         {
             GenericDetail detail = (GenericDetail) iter.next();
             if (detail instanceof BinaryDetail || detail instanceof
ImageDetail)
             {
                 standardInfo[0] = detail;
             }
             .........
         }

and then invoke this: imageLabel = new JLabel(new ImageIcon(
                         (byte[]) standardInfo[i].getDetailValue()));

If we talk in the terms of contact details with a "Summary" and "All details" page you'll have the following situation:

For the Summary page you should directly call ssci.getDetals(Contact
contact, Class detailClass) for each of the details. For example if you
want to show the first name, you should have:
    JLabel firstNameLabel = new JLabel("First name:");

which won't change when changing contacts. And you should have another:
    JLabel firstNameValueLabel = new JLabel();

and when you click on a Contact on the left you should make:

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())
{
    firstNameValueLabel.setText(ssci.getDetals(contact,
FirstNameDetail.class).next());
}

Thus you will set the first found detail for the first name property.

For the "All details" you should just call:

ssci.getAllDetailsForContact(contact);

and insert all details from this list into a table. And that's it.

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that.

Yes, exactly. I've changed it. Now ImageDetail extends BinaryDetail.

Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

I agree. We could have a NotesDetail which will extend StringDetail.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

I think it's not implemented yet. Damian, do you have an idea about this?

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

This is a good idea, but be careful, because you have to consider the
fact that the Local User Info form should be added as a
ConfigurationForm in the ConfigurationWindow.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

It runs fine and it's not so basic and you didn't make any terrible
mistakes:)) I think it's great that we have a base already on which we
could discuss. I think you're going in the right direction, you should
just try to stay simple and don't add many complex functionalities (I'm
talking about the Search). I'm not sure if I have explained well how I
imagine it, so if you have any questions, or something you don't
understand, please ask. Also if there's something you don't agree, don't
hesitate to discuss it.

Yana

Adam

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Damian,

I would imagine contact's images would be used outside of just specific profile context, so that sounds good to me. Thanks for letting me know.

Adam

Damian Minkov wrote:

···

Hi Adam,

about the pictures for icq contacts. Pictures of contacts can be retrieved by contact.getImage.
This is implemented not only for icq but also and for jabber and yahoo. Is this approach ok ?

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Adam,

on second look at the OperationSet it will be better images to be accessed and from the operationset I will make it and will commit it.

damencho

Adam Goldstein wrote:

···

Hey Damian,

I would imagine contact's images would be used outside of just specific profile context, so that sounds good to me. Thanks for letting me know.

Adam

Damian Minkov wrote:

Hi Adam,

about the pictures for icq contacts. Pictures of contacts can be retrieved by contact.getImage.
This is implemented not only for icq but also and for jabber and yahoo. Is this approach ok ?

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Adam,

Adam Goldstein wrote:

Hi Yana,

Thanks for all of the comments. I think I understand how you're describing you envision it, but let me check just to make sure. The left panel containing a JList with the sub contacts rather than a JTable is no problem, and getting rid of the search is probably a good idea. On the right, I think you were saying a JTabbedPane, but with just Basic and All views. Do you think rather than putting all of the information into the extended tab, it would be alright to make more tabs, similar to how it is done in the Miranda picture, except with tabs instead of buttons on the left. So all together, the strategy would be similar to that picture, but with tabs instead of clicking on the left, it leaves the space for the subcontact list on the left while still remaining relatively compact. Does that sound like what you had in mind?

I was also thinking of this solution, but I thought it would become more complex and when you think people are most often interested only in seeing the name, phone number, email. Emil, WDYT?

I was a bit confused about what you were saying about the FirstNameDetail. You were saying it should be consistent across subcontacts, but that doesn't seem like it would necessarily be true. Someone may use entirely different names for each account, so it seems like that should be updated each time.

No, I didn't say that the first name detail should be consistent across subcontacts. I said that for each property in the Summary page you would have two JLabel-s: one which gives the name of the property and one that gives the value. My example for the FirstNameDetail was with these two labels. In order to have in the window:

First name: Adam

you'll have JLabel("First name:"), which is constant for all subcontacts and another JLabel(), which text would be obtained from the contact details each time a subcontact is clicked. May be the last time I didn't explain it very well.

Also, you were saying to use the line

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())

but I don't really understand that. In what event would a contact have more than one FirstNameDetail? I understand iterating through maybe an InterestDetail, but I didn't quite understand that comment.

I see what's bothering you, but in fact the getDetails method is meant to be used for obtaining all kind of details. In order to be possible to obtain a group of details, like in the case of InterestDetail, it returns an iterator over a set of values. It sounds less logical in the case of FirstNameDetail, but as I said the method should be convenient for all kind of details.

Yana

···

Oh, and Damian, thanks for the change in the detail. I appreciate it.

Adam

Yana Stamcheva wrote:

Hi Adam,

I've just tested your alpha contact info plug-in and it works well.

Before answering your questions I would like to make some suggestions about the user interface, because I have imagined it a little differently, something like this:
    - left panel containing the list of sub contacts - here you could use a JList, instead of JTable, because it'll look simpler for the user.
    - center panel containing a JTabbedPane with two tabs: Summary and All details. In the Summary we will have a photo, all the names, gender, age, birth date, e-mail, phone number (you could see the attached file, which is a screenshot from Miranda contact details form, it's just an example how we could arrange labels). The "All details" tab will contain a table with two columns: "Detail name", "Detail value". There we could put all details coming from the protocol.

The idea would be the same as you said in your mail, when you click on a
contact in the list in the left, the right panel will load the details of the chosen protocol contact.

Below you'll find some inline comments and answers to your questions.

Adam Goldstein wrote:

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

You should be even more explicit:) We've created the specific ContactDetails classes (like FirstNameDetail, LastNameDetail, etc.) with the idea that in the GUI this will facilitate the access to a concrete detail. Thus in the ContactInfoProtocolPanel you don't need to make this:

Iterator iter = ssci.getAllDetailsForContact(contact);
         while (iter.hasNext())
         {
             GenericDetail detail = (GenericDetail) iter.next();
             if (detail instanceof BinaryDetail || detail instanceof
ImageDetail)
             {
                 standardInfo[0] = detail;
             }
             .........
         }

and then invoke this: imageLabel = new JLabel(new ImageIcon(
                         (byte[]) standardInfo[i].getDetailValue()));

If we talk in the terms of contact details with a "Summary" and "All details" page you'll have the following situation:

For the Summary page you should directly call ssci.getDetals(Contact
contact, Class detailClass) for each of the details. For example if you
want to show the first name, you should have:
    JLabel firstNameLabel = new JLabel("First name:");

which won't change when changing contacts. And you should have another:
    JLabel firstNameValueLabel = new JLabel();

and when you click on a Contact on the left you should make:

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())
{
    firstNameValueLabel.setText(ssci.getDetals(contact,
FirstNameDetail.class).next());
}

Thus you will set the first found detail for the first name property.

For the "All details" you should just call:

ssci.getAllDetailsForContact(contact);

and insert all details from this list into a table. And that's it.

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that.

Yes, exactly. I've changed it. Now ImageDetail extends BinaryDetail.

Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

I agree. We could have a NotesDetail which will extend StringDetail.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

I think it's not implemented yet. Damian, do you have an idea about this?

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

This is a good idea, but be careful, because you have to consider the
fact that the Local User Info form should be added as a
ConfigurationForm in the ConfigurationWindow.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

It runs fine and it's not so basic and you didn't make any terrible
mistakes:)) I think it's great that we have a base already on which we
could discuss. I think you're going in the right direction, you should
just try to stay simple and don't add many complex functionalities (I'm
talking about the Search). I'm not sure if I have explained well how I
imagine it, so if you have any questions, or something you don't
understand, please ask. Also if there's something you don't agree, don't
hesitate to discuss it.

Yana

Adam

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Yana Stamcheva wrote:

Hi Adam,

Adam Goldstein wrote:

Hi Yana,

Thanks for all of the comments. I think I understand how you're describing you envision it, but let me check just to make sure. The left panel containing a JList with the sub contacts rather than a JTable is no problem, and getting rid of the search is probably a good idea. On the right, I think you were saying a JTabbedPane, but with just Basic and All views. Do you think rather than putting all of the information into the extended tab, it would be alright to make more tabs, similar to how it is done in the Miranda picture, except with tabs instead of buttons on the left. So all together, the strategy would be similar to that picture, but with tabs instead of clicking on the left, it leaves the space for the subcontact list on the left while still remaining relatively compact. Does that sound like what you had in mind?

I was also thinking of this solution, but I thought it would become more complex and when you think people are most often interested only in seeing the name, phone number, email. Emil, WDYT?

I agree. Think it would be a good idea to have one first tab containing a fixed set of the details that are most commonly consulted and made available. If some of the properties in this tab are not available in some cases - you'll leave them empty. The second tab would contain a very simple "name:value" table containing all (and only the) details available for the contact (including those shown on the first page).

This approach would both suit users that would like to quickly retrieve commonly used properties (in the first tab) and at the same time allow for exposing absolutely all details supported for this protocol/contact (in the advanced tab).

Implementing more tabs at this point is something that might turn out to be quite tricky for the following reasons:

1. We don't have a clear idea of all the details that are made available by the various protocols we support.
2. We have an even less clear undestanding of what details are supported by the stacks that we are using.

Hence we might end up with tabs that contain lots of fields, 90% of which are empty in 90% of the cases.

I'd therefore prefer for us to first have the simple approach implemented. I think this would make your job a lot easier.

Then, someday, based on our experience, we may decide that we are able to determine a second, and a third (, and so on..) set of properties that are available for most users and make them available in a new tab that we'll insert right after the generic details.

Does this make sense?

Emil

···

I was a bit confused about what you were saying about the FirstNameDetail. You were saying it should be consistent across subcontacts, but that doesn't seem like it would necessarily be true. Someone may use entirely different names for each account, so it seems like that should be updated each time.

No, I didn't say that the first name detail should be consistent across subcontacts. I said that for each property in the Summary page you would have two JLabel-s: one which gives the name of the property and one that gives the value. My example for the FirstNameDetail was with these two labels. In order to have in the window:

First name: Adam

you'll have JLabel("First name:"), which is constant for all subcontacts and another JLabel(), which text would be obtained from the contact details each time a subcontact is clicked. May be the last time I didn't explain it very well.

Also, you were saying to use the line

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())

but I don't really understand that. In what event would a contact have more than one FirstNameDetail? I understand iterating through maybe an InterestDetail, but I didn't quite understand that comment.

I see what's bothering you, but in fact the getDetails method is meant to be used for obtaining all kind of details. In order to be possible to obtain a group of details, like in the case of InterestDetail, it returns an iterator over a set of values. It sounds less logical in the case of FirstNameDetail, but as I said the method should be convenient for all kind of details.

Yana

Oh, and Damian, thanks for the change in the detail. I appreciate it.

Adam

Yana Stamcheva wrote:

Hi Adam,

I've just tested your alpha contact info plug-in and it works well.

Before answering your questions I would like to make some suggestions about the user interface, because I have imagined it a little differently, something like this:
    - left panel containing the list of sub contacts - here you could use a JList, instead of JTable, because it'll look simpler for the user.
    - center panel containing a JTabbedPane with two tabs: Summary and All details. In the Summary we will have a photo, all the names, gender, age, birth date, e-mail, phone number (you could see the attached file, which is a screenshot from Miranda contact details form, it's just an example how we could arrange labels). The "All details" tab will contain a table with two columns: "Detail name", "Detail value". There we could put all details coming from the protocol.

The idea would be the same as you said in your mail, when you click on a
contact in the list in the left, the right panel will load the details of the chosen protocol contact.

Below you'll find some inline comments and answers to your questions.

Adam Goldstein wrote:

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

You should be even more explicit:) We've created the specific ContactDetails classes (like FirstNameDetail, LastNameDetail, etc.) with the idea that in the GUI this will facilitate the access to a concrete detail. Thus in the ContactInfoProtocolPanel you don't need to make this:

Iterator iter = ssci.getAllDetailsForContact(contact);
         while (iter.hasNext())
         {
             GenericDetail detail = (GenericDetail) iter.next();
             if (detail instanceof BinaryDetail || detail instanceof
ImageDetail)
             {
                 standardInfo[0] = detail;
             }
             .........
         }

and then invoke this: imageLabel = new JLabel(new ImageIcon(
                         (byte[]) standardInfo[i].getDetailValue()));

If we talk in the terms of contact details with a "Summary" and "All details" page you'll have the following situation:

For the Summary page you should directly call ssci.getDetals(Contact
contact, Class detailClass) for each of the details. For example if you
want to show the first name, you should have:
    JLabel firstNameLabel = new JLabel("First name:");

which won't change when changing contacts. And you should have another:
    JLabel firstNameValueLabel = new JLabel();

and when you click on a Contact on the left you should make:

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())
{
    firstNameValueLabel.setText(ssci.getDetals(contact,
FirstNameDetail.class).next());
}

Thus you will set the first found detail for the first name property.

For the "All details" you should just call:

ssci.getAllDetailsForContact(contact);

and insert all details from this list into a table. And that's it.

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that.

Yes, exactly. I've changed it. Now ImageDetail extends BinaryDetail.

Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

I agree. We could have a NotesDetail which will extend StringDetail.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

I think it's not implemented yet. Damian, do you have an idea about this?

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

This is a good idea, but be careful, because you have to consider the
fact that the Local User Info form should be added as a
ConfigurationForm in the ConfigurationWindow.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

It runs fine and it's not so basic and you didn't make any terrible
mistakes:)) I think it's great that we have a base already on which we
could discuss. I think you're going in the right direction, you should
just try to stay simple and don't add many complex functionalities (I'm
talking about the Search). I'm not sure if I have explained well how I
imagine it, so if you have any questions, or something you don't
understand, please ask. Also if there's something you don't agree, don't
hesitate to discuss it.

Yana

Adam

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hey Emil, Yana,

What you're both saying makes a lot of sense, and I definitely agree. I should be able to change things around pretty quickly.

In my first e-mail about this, I talked about unique detail types, as in ones that retrieve a value that is not an extension of StringDetail, and I talked about ordering them by some sort of priority. Do you guys think there should be any particular order, or for the more extensive pane, should I just start printing them out there?

And in the event that a contact has no additional details outside of the ones we define in the first tab, should the second tab still be created to show some sort of default message about how there is no extra information?

Oh, and Yana, I understand what you meant now about the details. For the Basic tab, since all information will still display detail names, regardless of whether or not they have values, I don't need to recreate all of those JLabel's, but I do need to retrieve the actual value each time.

Thanks,
Adam

Emil Ivov wrote:

···

Yana Stamcheva wrote:

Hi Adam,

Adam Goldstein wrote:

Hi Yana,

Thanks for all of the comments. I think I understand how you're describing you envision it, but let me check just to make sure. The left panel containing a JList with the sub contacts rather than a JTable is no problem, and getting rid of the search is probably a good idea. On the right, I think you were saying a JTabbedPane, but with just Basic and All views. Do you think rather than putting all of the information into the extended tab, it would be alright to make more tabs, similar to how it is done in the Miranda picture, except with tabs instead of buttons on the left. So all together, the strategy would be similar to that picture, but with tabs instead of clicking on the left, it leaves the space for the subcontact list on the left while still remaining relatively compact. Does that sound like what you had in mind?

I was also thinking of this solution, but I thought it would become more complex and when you think people are most often interested only in seeing the name, phone number, email. Emil, WDYT?

I agree. Think it would be a good idea to have one first tab containing a fixed set of the details that are most commonly consulted and made available. If some of the properties in this tab are not available in some cases - you'll leave them empty. The second tab would contain a very simple "name:value" table containing all (and only the) details available for the contact (including those shown on the first page).

This approach would both suit users that would like to quickly retrieve commonly used properties (in the first tab) and at the same time allow for exposing absolutely all details supported for this protocol/contact (in the advanced tab).

Implementing more tabs at this point is something that might turn out to be quite tricky for the following reasons:

1. We don't have a clear idea of all the details that are made available by the various protocols we support.
2. We have an even less clear undestanding of what details are supported by the stacks that we are using.

Hence we might end up with tabs that contain lots of fields, 90% of which are empty in 90% of the cases.

I'd therefore prefer for us to first have the simple approach implemented. I think this would make your job a lot easier.

Then, someday, based on our experience, we may decide that we are able to determine a second, and a third (, and so on..) set of properties that are available for most users and make them available in a new tab that we'll insert right after the generic details.

Does this make sense?

Emil

I was a bit confused about what you were saying about the FirstNameDetail. You were saying it should be consistent across subcontacts, but that doesn't seem like it would necessarily be true. Someone may use entirely different names for each account, so it seems like that should be updated each time.

No, I didn't say that the first name detail should be consistent across subcontacts. I said that for each property in the Summary page you would have two JLabel-s: one which gives the name of the property and one that gives the value. My example for the FirstNameDetail was with these two labels. In order to have in the window:

First name: Adam

you'll have JLabel("First name:"), which is constant for all subcontacts and another JLabel(), which text would be obtained from the contact details each time a subcontact is clicked. May be the last time I didn't explain it very well.

Also, you were saying to use the line

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())

but I don't really understand that. In what event would a contact have more than one FirstNameDetail? I understand iterating through maybe an InterestDetail, but I didn't quite understand that comment.

I see what's bothering you, but in fact the getDetails method is meant to be used for obtaining all kind of details. In order to be possible to obtain a group of details, like in the case of InterestDetail, it returns an iterator over a set of values. It sounds less logical in the case of FirstNameDetail, but as I said the method should be convenient for all kind of details.

Yana

Oh, and Damian, thanks for the change in the detail. I appreciate it.

Adam

Yana Stamcheva wrote:

Hi Adam,

I've just tested your alpha contact info plug-in and it works well.

Before answering your questions I would like to make some suggestions about the user interface, because I have imagined it a little differently, something like this:
    - left panel containing the list of sub contacts - here you could use a JList, instead of JTable, because it'll look simpler for the user.
    - center panel containing a JTabbedPane with two tabs: Summary and All details. In the Summary we will have a photo, all the names, gender, age, birth date, e-mail, phone number (you could see the attached file, which is a screenshot from Miranda contact details form, it's just an example how we could arrange labels). The "All details" tab will contain a table with two columns: "Detail name", "Detail value". There we could put all details coming from the protocol.

The idea would be the same as you said in your mail, when you click on a
contact in the list in the left, the right panel will load the details of the chosen protocol contact.

Below you'll find some inline comments and answers to your questions.

Adam Goldstein wrote:

Hey Yana and Everybody,

It's only a small example, but here's the current code of the new style of contact information. I had different ideas about how to do things, so before continuing with what I've done, I wanted to see what everyone thinks of my approach. The final idea I ended up going with seemed like a good method, but as I got going, it started to feel a bit explicit, and I'd really appreciate it if people could look at it to see if it is too specific. In the attached zip there are all the Java files that I used and the manifest. To access it within the program, just right click on a contact, pick "New Contact Info" at the bottom, and it'll pop up. As it is now, only ICQ works because that's the only protocol with the OperationSet implemented, but the other's will still pop up a default view.

Here's the basic idea: When activated, a JFrame is created with a left panel, the ContactInfoSearchPanel, and a right panel, the ContactInfoProtocolPanel. In the SearchPanel, there is a text field that will in the future be used to search for other contacts, but for now, it doesn't do anything. Below that, there is a JTable that lists all of the respective protocols and account names of all of the subcontacts of the selected MetaContact. Although it isn't set to do so now, in the future, you'll be able to select each contact from the list, and it will update the information in the ProtocolPanel. I originally made the list sortable, but that was using some convenient methods from a more recent JDK, so I'll have to reimplement that.

The ProtocolPanel is currently split into two areas, but I'm thinking in the future of making it three. At the moment, the top panel contains what should be rather standard information - First name, middle name, last name, gender, and e-mail address. Also, if they have an image associated with them, it will add that to the left side. Below that panel, there is extended information which is just the toString of all other ServerStoredDetails display name and value. Most protocols tend to have one detail that is a generic profile, like Notes in ICQ or the text you have in AIM, so I think I will put a text area below the standard information that shows that. Underneath that area, I'll put the extended information, and I think I'll make it collapsible.

What I'm hoping you'll look at in the ProtocolPanel is how explicit I'm being. I specifically look for certain Details and handle things certain ways and I just want to be sure it's not too specific and I'm not doing anything stupid that seemed like a good idea at the time, but really isn't. I looked through all of the ServerStoredDetails and I made a list of all types that exist that are not just an extension of StringDetail. What I'm planning on doing is adding them in a certain order of priority to extended info, and then finishing with all of the random StringDetails afterwards. Right now, I haven't stylized the special cases yet because I want to be sure that's the right approach and that others agree with me on the priority I set. Here's the list that I made:

BinaryDetail - Special method = byte[] getBytes()
CalendarDetail - Special method = java.util.Calendar getCalendar()
BooleanDetail - Special method = boolean getBoolean()
LocaleDetail - Special method = java.util.Locale getLocale()
NumberDetail - Special method = java.math.BigDecimal getNumber()
TimeZoneDetail - Special method = java.util.TimeZone getTimeZone()
URLDetail - Special method = java.net.URL

This is the priority I was thinking of:
CalendarDetail
TimeZoneDetail
LocaleDetail
URLDetail
BooleanDetail
NumberDetail

You should be even more explicit:) We've created the specific ContactDetails classes (like FirstNameDetail, LastNameDetail, etc.) with the idea that in the GUI this will facilitate the access to a concrete detail. Thus in the ContactInfoProtocolPanel you don't need to make this:

Iterator iter = ssci.getAllDetailsForContact(contact);
         while (iter.hasNext())
         {
             GenericDetail detail = (GenericDetail) iter.next();
             if (detail instanceof BinaryDetail || detail instanceof
ImageDetail)
             {
                 standardInfo[0] = detail;
             }
             .........
         }

and then invoke this: imageLabel = new JLabel(new ImageIcon(
                         (byte[]) standardInfo[i].getDetailValue()));

If we talk in the terms of contact details with a "Summary" and "All details" page you'll have the following situation:

For the Summary page you should directly call ssci.getDetals(Contact
contact, Class detailClass) for each of the details. For example if you
want to show the first name, you should have:
    JLabel firstNameLabel = new JLabel("First name:");

which won't change when changing contacts. And you should have another:
    JLabel firstNameValueLabel = new JLabel();

and when you click on a Contact on the left you should make:

if( ssci.getDetals(contact, FirstNameDetail.class).hasNext())
{
    firstNameValueLabel.setText(ssci.getDetals(contact,
FirstNameDetail.class).next());
}

Thus you will set the first found detail for the first name property.

For the "All details" you should just call:

ssci.getAllDetailsForContact(contact);

and insert all details from this list into a table. And that's it.

A question I had in terms of details is, why doesn't ImageDetail extend BinaryDetail? It seems like ImageDetail is maybe referring to a specific avatar of the account and a random BinaryDetail may just be additional pictures associated with the user, but it isn't really clear. I wasn't quite sure how to handle that.

Yes, exactly. I've changed it. Now ImageDetail extends BinaryDetail.

Also, if the ProtocolPanel is split into three parts and there's a standardized Notes panel, I think it would be useful to make that into it's own ServerStoredDetail class.

I agree. We could have a NotesDetail which will extend StringDetail.

Another thing I noticed is that ICQ users have avatars associated with their accounts, but the ICQ implementation of OperationSetServerStoredContactInfo does not seem to retrieve any pictures. I don't know if that's a mistake or if that's just not finished or what.

I think it's not implemented yet. Damian, do you have an idea about this?

There is no functionality for setting your own account information, but I was thinking of adding that next. Rather than having a separate GUI, I was planning on using the same frame and just setting it so that if the user being queried is one of your own accounts, then you will be able to edit the information. My plan, if you agree with how I have been doing it so far, is to display all of the information in TextFields rather than JLabels and just turning edit on and off, depending on whether or not it is your own account, and adding a submit button to the bottom.

This is a good idea, but be careful, because you have to consider the
fact that the Local User Info form should be added as a
ConfigurationForm in the ConfigurationWindow.

I hope this runs alright for you and I'm sorry if it's a bit open ended, too basic, or if I've made terrible mistakes. Thank you very much for looking at all of this and please let me know whatever you think of it.

It runs fine and it's not so basic and you didn't make any terrible
mistakes:)) I think it's great that we have a base already on which we
could discuss. I think you're going in the right direction, you should
just try to stay simple and don't add many complex functionalities (I'm
talking about the Search). I'm not sure if I have explained well how I
imagine it, so if you have any questions, or something you don't
understand, please ask. Also if there's something you don't agree, don't
hesitate to discuss it.

Yana

Adam

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net