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 <[email protected]>
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
[email protected] <mailto:[email protected]>
http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
