[Libreoffice-commits] core.git: new uno sidebar api tdf#91806

[Stephan Bergmann]

On 08/21/2015 03:25 PM, Laurent Godard wrote:
>>> +    */
>>> +    void setTitle( [in] string newTitle );
>>
>> Is setTitle necessary and/or useful?  (At least, none of the code in
>> this commit appears to use it.)
>>
>
> --> it allow changing the Deck title (as named)
> --> in UnoDeck.hxx
> http://opengrok.libreoffice.org/xref/core/include/sfx2/sidebar/UnoDeck.hxx#40
>
> --> do i miss somehing ?

What I mean is:  Is it supposed to be useful functionality that a client 
that has access to an XDeck instance can change its title?  Or should 
the title rather be immutable and attached to the XDeck instance when it 
is created?

I often wonder this when I see UNO interfaces that have getter/setter 
method pairs for some item of the object's internal state.  When an 
object is considered as internal state plus an external set of 
"messages" it can react to, it often does not make sense to have setter 
methods for individual items of the internal state.  Nevertheless, 
people are sometimes tempted to add such setters "just because," and 
that may lead to unnecessary problems.  That's why I'm asking.

>>> +    void setOrderIndex( [in] long newOrderIndex );
>>
>> Is setOrderIndex necessary and/or useful? (At least, none of the code in
>> this commit appears to use it.)  Is setOrderIndex(0) the same as
>> moveFirst()?
>>
>
> first, have to say that only rely of existing implementation.
>
> unfortunatelly, the Decks and panels are global to libreoffice
> that means that 2 panels or desk can't have same order index (or at
> least i did not test that case regarding the existing. I may verify if 2
> panels or Decks can have same orderIndex)
> setting setOrderIndex(0) as movreFirst() on one panel, the the other
> would disturb non displayed panels (even on non visible decks) or would
> require to re-arrange all the Decks/Panels each time
>
> i personnaly do not like this architecture despite i understand the
> reusability goal. i think there are cleanir things to be done (but as a
> first round i did not want to destray all the existing structure)

I'm not sure I understand you here.  But if there is no real need for 
client code to be able to change an XDeck's orderIndex, I'd suggest to 
just not offer that functionality.  (This is similar to the above setTitle.)