18 Jun
2010
18 Jun
'10
3:44 p.m.
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.
I tried this:
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.
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.
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?
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.
If i make it publish, i will add in it the drawing
behavior that was just removed.
I do not understand.
Please, let me know how after this discussion if you are happy with MORectangleShape.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
--
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 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 
