Function & Data Members in same view

[soumyat85]

Hey rem,
I saw your function call thing. The problem with that is that it used the original znode window which really doesn't match with our UI. The key factor for a UI is that it should be uniform across all functionality. So I added a "D" button to the nodes which will show the data members and their usage all together while also showing the inherited members out of it.

The other thing is since we are showing a list of classes you shouldn't use a window listing the same thing. Its redundant.
Take a look at the view and you will see what I was talking about.
Use the multi-level-inheritance file to see it.
Also, I didn't understand the issue you mentioned with your implementation. Could you elaborate and show me a test case and what happens there.

[rob8861]

Hi Soumya,

Ok, I'll have to look at it. The idea of the znode window is to have the
user select a class and then a function call from that class. I don't think
it is redundant. I guess you could add another button to the node and have
the user select a function calls from a list.
Otherwise, I don't see any other way of doing it.

In terms of implementation, what I ment was that the object 'usage' returns
arrays of objects each of witch represent a usage case. However, to get the
usage information you need to look inside 'type_usage' and this object is
randomly placed in a different index so I wasn't sure how to fetch that.
For example:

if you run the function_calls.js it would generate the following object:
Then to get the usage information you loop thru the object and display the
content as follow:

class_members[key][0]['line'] will return the line number
class_members[key][1]['code_str'] will return the code statement.

but sometimes the index is not correct so you get back 'undefined'...

thanks,
Rem

On Wed, Apr 18, 2012 at 12:27 PM, Soumya Tripathy <
[email protected]

wrote:

Hey rem,
I saw your function call thing. The problem with that is
that it used the original znode window which really doesn't match with our
UI. The key factor for a UI is that it should be uniform across all
functionality. So I added a "D" button to the nodes which will show the
data members and their usage all together while also showing the inherited
members out of it.

The other thing is since we are showing a list of classes you shouldn't
use a window listing the same thing. Its redundant.
Take a look at the view and you will see what I was talking about.
Use the multi-level-inheritance file to see it.
Also, I didn't understand the issue you mentioned with your
implementation. Could you elaborate and show me a test case and what
happens there.

---

Reply to this email directly or view it on GitHub:
#5

[soumyat85]

Hey Rem,
Thanks for pointing that out. The function call object and type were flipped when calling it. Also when getting class members.. use class_members[key][1].get_code_string() & class_members[key][1].get_line_number()....
Yeah I meant adding a button to the node to show highlighted functions and data members. Take a look at that. So the point is we shouldn't use extra windows to show a list of classes. Thats what I meant by redundant, since we already display the list of nodes. anyways take a look at what I put in and if you think that we should do it the other way we can change it.
It also takes care of showing any composition elements there too.

[rob8861]

Hey Soumya,

I just looked at it and it looks good.
I need to think about the additional button to the node. After all we don't
want to clog it.

I mean, if a user click on "display functions" button on a node, then he
should be presented with a list of functions which he can select from. then
another view will jump in showing him the usage data. That's where I get
confused.

Oh, and the usage data is working now. It is getting the correct data and
display it in a table.
I'll work on it more tonight.

Looks like we are really close to finish. Just need to get the last things
hooked up and we should be good to go. Has Di submitted his view? I know
vishal did.

thanks,

On Wed, Apr 18, 2012 at 4:49 PM, Soumya Tripathy <
[email protected]

wrote:

Hey Rem,
Thanks for pointing that out. The function call object and type
were flipped when calling it. Also when getting class members.. use
class_members[key][1].get_code_string() &
class_members[key][1].get_line_number()....
Yeah I meant adding a button to the node to show highlighted functions and
data members. Take a look at that. So the point is we shouldn't use extra
windows to show a list of classes. Thats what I meant by redundant, since
we already display the list of nodes. anyways take a look at what I put in
and if you think that we should do it the other way we can change it.
It also takes care of showing any composition elements there too.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[rob8861]

Hi Soumya,

two questions:

1. Is there a way to display where the member is actually used. The current
   usage data tells the line number + code str but not the actual class name
   the member is being used at.
2. I can add another button to the node for function call but quite
   honestly, it would need to display the list of functions in the node before
   it display the view which is essentially the usage. This is why I used the
   windows because the first window ask user to select a class and the second
   window ask the user to pick a function in that class. Then it display the
   usage data for that function.

Otherwise, we can just use the new button you added "D" and remove my view
since they are almost the same.

That do you think?

Thanks,

On Wed, Apr 18, 2012 at 6:01 PM, Re'em Fazio [email protected] wrote:

Hey Soumya,

I just looked at it and it looks good.
I need to think about the additional button to the node. After all we
don't want to clog it.

I mean, if a user click on "display functions" button on a node, then he
should be presented with a list of functions which he can select from. then
another view will jump in showing him the usage data. That's where I get
confused.

Oh, and the usage data is working now. It is getting the correct data and
display it in a table.
I'll work on it more tonight.

Looks like we are really close to finish. Just need to get the last things
hooked up and we should be good to go. Has Di submitted his view? I know
vishal did.

thanks,

On Wed, Apr 18, 2012 at 4:49 PM, Soumya Tripathy <
[email protected]

wrote:

Hey Rem,
Thanks for pointing that out. The function call object and
type were flipped when calling it. Also when getting class members.. use
class_members[key][1].get_code_string() &
class_members[key][1].get_line_number()....
Yeah I meant adding a button to the node to show highlighted functions
and data members. Take a look at that. So the point is we shouldn't use
extra windows to show a list of classes. Thats what I meant by redundant,
since we already display the list of nodes. anyways take a look at what I
put in and if you think that we should do it the other way we can change it.
It also takes care of showing any composition elements there too.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[soumyat85]

1. I don't have that right now but I can do it probably.

2. I don't think that giving a class list and then a function list is the right way to go. Well my opinion was to keep the "D" and use that to display all the functions and data members as well as their usage. It also highlights the base class members and the composition class members separately so I think that should complete the view. But you can open this up for discussion in case people have a different opinion.

[rob8861]

Hi Soumya,

1. I'll look into that as well.

2. I like the "D" button and we should probably keept it. However, it only
   satisfy one requirement of the FunctionCalls view, which is selecting a
   class. But a user also need to select a function call in that class. My
   view displays all the functions in the class and then initiates the view.

We could probably do the following:

• add another section to the "D" view and call it "Function Declaration"
  and then display where that function is used {"line", "code_str", "calling
  class"}
• Add another button called "F" which opens a new window that display the
  list of functions in that node. Then make the rows clickable so when
  clicked the final view opens up and display the usage information.

What do you think?

Thanks
Rem

p.s: I think I fixed the svg bug. I'll push the patch once I am done with
the function view.

On Wed, Apr 18, 2012 at 11:48 PM, Soumya Tripathy <
[email protected]

wrote:

1. I don't have that right now but I can do it probably.

2. I don't think that giving a class list and then a function list is the
   right way to go. Well my opinion was to keep the "D" and use that to
   display all the functions and data members as well as their usage. It also
   highlights the base class members and the composition class members
   separately so I think that should complete the view. But you can open this
   up for discussion in case people have a different opinion.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[soumyat85]

Sorry I didn't understand what you meant in (2). So what other data needs to be displayed... Can you give me an example of what else should be displayed... (a code example actually. ?? )..

Its so good that you could track down that svg bug.. its really important.. Thanks so much. Could you push that sooner than later :).

[rob8861]

Hi Soumya,

Sorry for the late reply. I will reply back with more details when I get home.

Thanks

Sent from my iPhone

On Apr 19, 2012, at 10:32 AM, Soumya [email protected] wrote:

Sorry I didn't understand what you meant in (2). So what other data needs to be displayed... Can you give me an example of what else should be displayed... (a code example actually. ?? )..

Its so good that you could track down that svg bug.. its really important.. Thanks so much. Could you push that sooner than later :).

---

Reply to this email directly or view it on GitHub:
#5 (comment)