Martin,
since you are working in the selection manager. There is a behavior I
noticed months ago. It's describe in this thread:
http://www.mail-archive.com/[email protected]/msg22778.html
:
I noticed that _styleSelectable is called more than once when
selecting/deselecting nodes. Is that right? e.g. if I deselect a node, it
gets deselect, select and finally deselect (that's the behavior for
qx.ui.tree.SelectionManager, but consequently its for my selection manager
too).
And here is a typo I saw in the last commit:
tree.SelectionManager:48
return this._isItemSelectabel(item)
shouldn't it be "return this._isItemSelectable(item)"?
On Mon, Jul 19, 2010 at 11:20 AM, Guilherme Aiolfi <[email protected]>wrote:
> I hit that "bug" I while ago. I thought it was designed that way because I
> remember extjs has the same behavior.
>
> I thought it was ok to be that way since those items were not created util
> they were visible, that's (I thought was) why they weren't being selected.
>
> I remember that extjs couldn't fix that. But if that can be changed in
> qooxdoo it would be great, because that's the behavior (returning invisible
> items too) I would expect.
>
> On Mon, Jul 19, 2010 at 11:07 AM, Derrell Lipman <
> [email protected]> wrote:
>
>> On Mon, Jul 19, 2010 at 10:02, MartinWittemann <[email protected]
>> > wrote:
>>
>>>
>>> Hello developers,
>>> I fixed a bug today which initially was about modelSelection, on of our
>>> favorite topics on the list. ;) I debuged the whole thing down to the
>>> selection management of the tree and the getSelectables method of the
>>> tree.
>>>
>>> Here is what the API-Doc says about this method:
>>> "Returns all elements which are selectable."
>>>
>>> So what I expected was that I get all selectables of the tree but the
>>> method
>>> returned all visible selectables of the tree which is in my opinion a
>>> bug.
>>> The following playground example shows you what exactly whats happening:
>>>
>>> http://tinyurl.com/39rpq9v
>>>
>>> Now enough story telling and to my question. Have you ever used
>>> getSelectables of the tree and did you experience the same problem than I
>>> did? Do you think this change could break your application? Or some else
>>> application?
>>> Feedback is highly appreciated.
>>>
>>
>> Returning more rows, post-change, than were returned pre-change, would be,
>> to my thinking, a serious breakage in backward compatibility. Although I
>> would probably agree with your reading of the documentation, I believe this
>> change of behavior should be controlled by a property with a default such
>> that the pre-change behavior is maintained. The documentation should be
>> updated to mention the controlling property, and the default behavior.
>>
>> Derrell
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
