On 18 Jun 2010, at 15:44, Alexandre Bergel wrote:
In fact
MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything),
but the drawing is not the same.
MORectangleShape does not do anything. Some of the functionalities of MOBoundedShape will
be moved down to MORectangleShape.
Also, MOBoundedShape may be merged with MOFilledShape. I have to think about that. So
far, it does not make sense to have
MONodeShape
MOFilledShape
MOBoundedShape
MOCurveShape
MODiamondShape
...
MORectangleShape
see the images, even having color black the text with the current version is like grey.
That was one of the reasons for using labelShape and not rectangle at the beginning.
I cannot reproduce this difference of color. I attached what I have in my image. The code
that displays the string is rigorously the same.
<Screen shot 2010-06-18 at 09.09.04.png><Screen shot 2010-06-18 at
09.12.36.png>
I tried this:
<Screen shot 2010-06-18 at 09.25.44.png>
with MOLabelShape, the font is darker than with MORectangleShape.
I found the reason. MORectangleShape always displays a whiteBackground before displaying
the text. For some reason, the text appears gray in that situation. I added
MOBoundedShape>>withoutBackGroup. It solves the problem apparently.
<Screen shot 2010-06-18 at 09.32.35.png>
Does this solve your problem?
Plus the vertical padding works different, by
default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1
then i have more space that the one i need (see third image).
I cannot reproduce this. I inserted some times ago textPadding.
this is hard to reproduce with single nodes only with nested nodes.... but the
difference is basically in the computation of textHeightFor:
<Screen shot 2010-06-18 at 09.27.48.png>
Does it solve your issue?
LabelShape controls that better with
interlineSpace (not an accessor)... My extension changed that internal value, and i have
an extra control for fonts..
Which control?
I calculate the width a label uses before the drawing is done, for setting the width to
other nodes
In addition, Mondrian uses font cache (correct),
but if you change the system fonts, that was not reflected on mondrian... I needed to
validate that for Torch, another reason for my specialization...
I guess it should.
MCBoundedShape manages this ok (labelShape was failing in that)
If i make it publish, i will add in it the
drawing behavior that was just removed.
I do not understand.
I meant the drawing method of MCLabelShape
Please, let me know how after this discussion if you
are happy with MORectangleShape.
I will try with your last version, but will still keep my extension for the two
first reasons...
Cheers,
Alexandre
regards,
Veronica
<labelShape-extension.png> vs<labelShape-now.png>
<labelShape-now+padding.png>
On 18 Jun 2010, at 11:48, Tudor Girba wrote:
Hi Veronica,
As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I
guess that is why Alex removed it. I do not particularly like that, but this is the
situation now.
Could you subclass that one for the time being? Also, is the extension not of interest
for the general public? If yes, maybe it would make sense to publish it in Mondrian
directly :).
Cheers,
Doru
On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
Hi,
Can't test? where is MOLabelShape, why was it deleted??
I use it and now is gone!!! I even had a specialization of it for Torch...
Veronica
On 17 Jun 2010, at 17:47, Tudor Girba wrote:
> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it
gets displayed.
>
> Jannik, Veronica, could you check in your cases?
>
> Cheers,
> Doru
>
>
>
> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>
>> Hi Alex,
>>
>>>> Indeed, this caching should happen for all properties and for all shapes
(both for nodes and for edges). I think that Alex stopped in the middle because he did not
know whether this caching had an effect or not.
>>>
>>> I was wondering whether it would make sense to do this for all the metrics.
Apparently yes, I then continued. All shape parameters should be cached.
>>>> Alex, could you take a look at that?
>>>
>>> Done. Mondrian-Alexandre_Bergel.470
>>
>> Great. I checked a bit the implementation, and I would only suggest to check for
isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>
>>>> The next question is that if the border color is called all the time,
what is the use of the bitmap cache?
>>>
>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>
>> I know, but if you compute it once why do you still need to re-render?
>>
>> Cheers,
>> Doru
>>
>>
>>
>>>>> ======
>>>>> |view o |
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open
>>>>> ======
>>>
>>> A better version could be
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> |view o a |
>>> a := {0}.
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open.
>>> a
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Just inspect the expression, and see if the array a changes over the time.
>>>
>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>>
www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
>
www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the
right one."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev