[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: r34216 - lyx-devel/trunk/src/insets
From:       Abdelrazak Younes <younes () lyx ! org>
Date:       2010-04-20 9:41:48
Message-ID: 4BCD76DC.1090700 () lyx ! org
[Download RAW message or body]

On 04/20/2010 11:12 AM, Vincent van Ravesteijn - TNW wrote:
>>>>>>> The problem was that I never expected that InsetInfo
>>>>>>> is a child class of InsetCollapsable. This feels wrong.
>>>>>>>                
>>>>>> We need something between InsetText and InsetCollapsable
>>>>>> or we migrate the inset decoration to InsetText. Then
>>>>>> InsetCollapsable would just add tha ability to collapse.
>>>>>>
>>>>>>              
>>>>> Note that the InsetCollapsable design is fundamentally wrong in my
>>>>> opinion: we should not inherit from InsetText, InsetCollapsable
>>>>> should instead own and InsetText and an InsetButton. But this is
>>>>> quite late to address that design problem.
>>>>>            
>>>> FWIW, I understand, but do not (fully) share your opinion on this.
>>>>
>>>>          
>> So you have a third solution?
>>
>>      
> Then I guess I mean the second point ;-).
>
>    
>> Maybe you could be a bit more verbose to stop this
>> ping pong game :-)
>>      
> I think InsetInfo can just inherit from InsetText. I think it's
> inherently wrong to inherit from a class that specifically adds some
> functionality and then not using it. I'm not sure what precisely we need
> with respect to the decoration, and why this is in InsetCollapsable
> only. Therefore, I agree to move this decoration stuff to InsetText.
>    

Good :-)

> I don't agree that InsetCollapsable is wrong by inheriting from
> InsetText. I can really imagine that it _is_ an InsetText with an added
> button that can toggle the visibility of the text. The most important
> thing is that it is an Inset containing text (i.e. an InsetText). The
> toggling is just a painting issue and not an inherent different object
> IMHO.
>    

Well, there are pros and cons to each vision of course. But I disagree 
that this is only a painting issue. InsetText should IMO only be about 
painting text not about decoration around that text. With a new inset 
composed of a button and an InsetText, all mouse and keyboards events 
can be handled transparently: i.e. if the mouse is here dispatch the 
event to the button, if not, dispatch to the insettext, etc. This new 
Inset would be about gluing the two components together, nothing else. 
If you think about it, some insettext don't need the button: the main 
text, the text in table cells, the text in math... so why impose a 
decoration capability on all?

Abdel.

[prev in list] [next in list] [prev in thread] [next in thread]