Hi Martin,
thanks for the information and the tip!
Please note that I did not (yet) open a bug for this, 'cause I think I have to
re-think my design in general...
...my current (1.2-compatible) design also needed to override '_isNear'...
Thanks,
Peter
P.S.: If anyone has a hint on how to implement my "SplitterWithButtons",
please feel free to post :-D
On 2011-03-02 15:07 Martin Wittemann wrote:
> Hello Peter,
> I did change much on the implementation of the splitpane for the last
> release. As you might have seen, the pane now uses a blocker to get the
> cursor changes which improved the performance a lot. But sadly, I can't
> recall why I changed that to private. :(
> Try to use the protected _applyOffset method instead. Maybe thats going to
> fix the thing in the first place. In any way, we could change it back i
> think. Would you open up a bug report for that?
> Best,
> Martin
>
> Am 01.03.2011 um 17:44 schrieb Peter Schneider:
>
>> Hi Developers,
>>
>> during my migration from version 1.2 to version 1.3 I found some problems.
>> One of them is this:
>>
>> The event handler "qx.ui.splitpane.Pane._onSplitterMove" has changed into
>> "qx.ui.splitpane.Pane.__onSplitterMove" (from 'protected' in 1.2 to 'private'
>> in 1.3)
>>
>> This gives me a problem because I am doing this in my application:
>>
>>
>> I have a split pane with a slightly different splitter[1], and therefore I
>> derived my SplitPane class from "qx.ui.splitpane.Pane" with overwritten
>> "_createChildControlImpl" method (were I return my Splitter instead of
>> "yours"
>> ;) )
>>
>> <code>
>> qx.Class.define("app.ui.splitpane.Pane",
>> {
>> extend : qx.ui.splitpane.Pane,
>> //...
>> members :
>> {
>> // overridden
>> _createChildControlImpl : function (id)
>> {
>> var control;
>>
>> // Create _our_ splitter, not qooxdoo's
>> if (id === "splitter")
>> {
>> control = new app.ui.splitpane.Splitter(this);
>> this._add(control, {type : id});
>> control.addListener("move", this._onSplitterMove, this);
>> } else {
>> control = this.base(arguments, id);
>> }
>>
>> return control;
>> },
>> // ...
>> }
>> });
>> </code>
>>
>> I wanted to avoid re-implementing the complete qooxdoo split pane, but now I
>> can't exchange the frameworks splitter by my own splitter, 'cause I would
>> have
>> to set the private method "__onSplitterMove" from the base class @
>> "addListener"...
>>
>> Is there a reason for this 'increased privacy'?
>> Or (better question): How should I implement this now?
>>
>> Do I have to _copy_ all the methods from the base class[2] until there's no
>> more private call?...Me don't like... :-/
>>
>> Any design hint would be nice ;)
>>
>> Regards,
>> Peter
>>
>> ----
>> [1] It includes two buttons for 'quick hide/show' of a pane (see attached
>> image)
>> [2] __onSplitterMove and __setBlockerPosition
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
