[Scilab-Dev] Regarding tooltps in uitable

Sun Jun 5 09:31:06 CEST 2016

Hello,
Thank You for your inputs.1) I have updated my code and now I accept both types of input.    ut.tooltipstring = ["a","","c","d"]
     and 
     ut.tooltipstring = "[a,b,c,d]"

   The first one if the user want to input variables(string type) and also as Samuel suggested one can input only few non-empty strings    TT=emptystr(.string); TT([pos1 pos2 pos3..]) = ["tt1 "tt2" "tt3"...];
    The second one if the user wants to just input strings(no variables) but dont want to input so many "" (This is my opinion)

2) Q: Could you confirm that your implementation for the case 2) updates .tooltipstring when .string is modified?     A: Yes, it does :)
3) If possible I wanted to know what exactly the flag I should use, I want to use a flag instead of passing the whole data because of the reason I described. So if you think its better to use flag then I would like to know which flag I should use.
4) Samuel: If possible I would like to complete the basic functionalities appropriately and then I will work on your suggestions, they seems to be useful for someone focused on uitables and I will be happy to provide them with these functionality.
Thanking YouRishubh Jain       

    On Friday, 3 June 2016 3:25 AM, Samuel Gougeon <sgougeon at free.fr> wrote:

  Rishubh,

 IMO, your initial "values" flag was a clear one. "~" is less clear. Why not "=" ?  I am not kind of "~" (that means "similar" that is "more or less equal"). A detail.
 Could you confirm that your implementation for the case 2) updates .tooltipstring when .string is modified?
 Case 3): i do not think that
 ut.tooltipstring = "[a,b,c,d]"
 instead of ut.tooltipstring = ["a","b","c","d"]
 or
 ut.tooltipstring = "[a,,c,d]"
 instead of ut.tooltipstring = ["a","","c","d"]
 would be clear enough. "[a,b,c,d]" could be easily interpreted by users as [content_of variable_named_a, ... etc], as if eval("[a,b,c,d]") had to feed .tooltipstring
 Putting only a few non-empty strings in the whole table could be done with TT=emptystr(.string); TT([pos1 pos2 pos3..]) = ["tt1 "tt2" "tt3"...];

 What's you opinion about 

   - a way to make uitable displaying tooltips only for cells not wide enough? IMO, it would be useful, but a difficult task, depending on the font properties, and whether LaTeX is used or not, etc...    

   - a way to make uitable displaying values in tooltips only for chosen columns? could be done with a row of indices of chosen colums to be tooltiped?
   - a way to make uitable displaying values in tooltips with lengths above a given threshold given as a single number?   
 With restrictions: not applicable to LaTeX inputs ; not taking into account the font properties ; etc   

 Will you test the efficiency of the implementation with big .string and .tooltipstring arrays?

 Best regards
 Samuel

 Le 02/06/2016 22:43, Rishubh Jain a écrit :

  Hi, 
  Thankyou for inputs, 
  I have blogged my results :http://batcode17.blogspot.in/2016/06/tooltips.html 
  Please suggest if its upto the expectation or what modifications should I make. 
  Thanking You Rishubh 

      On Thursday, 2 June 2016 11:58 PM, Samuel Gougeon <sgougeon at free.fr> wrote:

 Hello,

 Thanks Rishubh for your proposal.

 Le 02/06/2016 15:56, Clément David a écrit :
 > Hi Rish,
 >
 > I guess the simpler proposal is the better, from a user point of view :
 >
 >> 1)  "no value" : no tooltip is displayed
 > Simply use the empty matrix scilab symbol [] for empty or none representation.
 >
 > ```scilab
 > o = uicontrol("table", ...);
 > o.tooltips = []
 .
 .tooltips expecting a string, IMO "" would even be clearer than 
 providing a constant and less specific type [].
 But both could be supported.

 >> 2)  "values" (special flag): The value of each cell is tooltiped when overflying it.
 >> This mode is required to ensure that the contents of too narrow cells can be fully seen without
 >> editing the cell.
 .
 Definitively yes. This proposal will be able to automatically update 
 .tooltips when modifying .data.
 Exactly what is needed, and the best way to avoid discrepancies.

 > This is a corner-case that can be easily implemented in a generic way. To display all the values as
 > tooltips, implement something like :
 >
 > ```scilab
 > o = uicontrol("table", ...);
 > o.tooltips = o.data;
 >
 > ```
 >
 >> 3)  "TT":  where TT is a matrix of strings of .strings size: When overflying the cell(i,j), the
 >> tooltip's content is the        TT(i,j) content + \n + the cell(i,j) content.
 > Again this seems to be complex and hard to understand by the end user. Using a string matrix will
 > allow a simple definition of what a tooltip is. Ignore the empty string "" to let the user undefine
 > a tooltip for a specific cell ; othewise any string value might be used as a tooltip.
 Yes, finally i rather agree with this. The first idea was to have a 
 "cumulated" mode (entries + comment) as the default.
 But being able to set only a comment would be better. If we want to 
 display entries as well,
 doing a element-wise .tooltips = comment + .data will be very simple, 
 and more customizable:
 if we want entries in heading lines instead of trailing ones, .tooltips 
 = .data + comments will do i.
 >
 > ```scilab
 > o = uicontrol("table", ...);
 > o.tooltips = ["tooltip for (1,1)" "tooltip for (1,2)" "tooltip for (1,3)"
 >                "tooltip for (2,1)" "tooltip for (2,2)" ""]
 >
 > ```
 >
 > Thanks for any remarks,
 I was somewhat wondering about the way the heading line and column will 
 be declared when needed,
 and then where (in .data($,:) and .data(:,$), to be rendered in (1,:) 
 and (:,1)). But finally, even them could
 need some tooltips. No reason to exclude tooltips for them.

 Hoping to read other comments soon,

 Samuel 

 _______________________________________________
 dev mailing list
 dev at lists.scilab.org
 http://lists.scilab.org/mailman/listinfo/dev

 _______________________________________________
dev mailing list
dev at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160605/a55727d4/attachment.htm>