Bugzilla – Full Text Bug Listing
|
Description
Mickael Istria
From the GTK POV is should be quite straight forward to implement an event that's fired when a Tree changes state from empty to non-empty. Laskshmi/Niraj, what do you think about Mac/Windows? (In reply to Eric Williams from comment #1) > From the GTK POV is should be quite straight forward to implement an event > that's fired when a Tree changes state from empty to non-empty. > > Laskshmi/Niraj, what do you think about Mac/Windows? Hi Mickael, Quick clarification: 'SWT.ItemAdded' event should be thrown only when a first time is added changing the state from empty to non-empty or an event on every new item added to a Tree/Table/Toolbar ? (In reply to Niraj Modi from comment #2) > Quick clarification: > 'SWT.ItemAdded' event should be thrown only when a first time is added > changing the state from empty to non-empty or an event on every new item > added to a Tree/Table/Toolbar ? I don't have strong requirement here. Having the notification only when 1st item is added, or when any item is added would work for bug 553353. I just think event for any item addition seems more powerful and maybe easier to implement, but if you feel differently, I'm fine with it. Just need to make sure that the case of addition of item, then removal, then addition sends a sequence of ItemAdded,Dispose,ItemAdded . Whoever plans to implement this API, please take care about mass additions - they should not cause event explosion. (In reply to Andrey Loskutov from comment #4) > Whoever plans to implement this API, please take care about mass additions - > they should not cause event explosion. Agreed, my thoughts is that this will be a single event fired when the Tree/Table/whatever changes from 0 items -> 1 item or more. Singular event, no more events fired for subsequent item additions. The only case where we should re-fire the event is if all items are removed (item count goes to 0), and then an item is added. From an API point of view it would certainly be appealing to have the usual added/removed events, but I see the performance implications for mass updates. Good that our immidiate requirement is detection of "becoming empty" and "becoming non-empty". It would be great if a Tree could fire events for both these symmetric situations. That would relief us from registering a bunch of DisposeListeners, as well. I'm going to submit a patch in a minute... It would be great if this could be added soon in the 4.22 cycle because bug 553353 depends on it and surely needs discussions, too. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185581 My patch adds the new SWT.EmptinessChanged event and fires it only once when the emptiness state of the tree changes, i.e., after first addition or last removal of a TreeItem. I've also added a test case that verifies this. Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185581 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f1881af9c35ea1b2be5b0696989048e9e6187e5b Thank you very much guys! I've tested again with today's I-build and it works very well. Can we resolve this bug now? (In reply to Eike Stepper from comment #11) > Thank you very much guys! I've tested again with today's I-build and it > works very well. Can we resolve this bug now? No, please provide N&N entry. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185719 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185719 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=14f2205cbddb7764fbe44e64b4d46515e91f61ad (In reply to Andrey Loskutov from comment #12) > No, please provide N&N entry. Where would that be? (In reply to Eike Stepper from comment #15) > Where would that be? It's in https://git.eclipse.org/r/admin/repos/www.eclipse.org%2Feclipse%2Fnews , 4.22/platform_isv.html New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/185721 New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/185724 Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/185724 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=f280030ff062344ed584750aa7d9fe8b2ec40a52 (In reply to Eclipse Genie from comment #19) > Gerrit change > https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/185724 was merged > to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/ > ?id=f280030ff062344ed584750aa7d9fe8b2ec40a52 Thanks Eike for the fix patch, added the SWT N&N entry. Resolving now. Something similar can be implemented for other SWT widgets: For tracking raised bug 576210: for Table and bug 576210: for Toolbar widgets. (In reply to Niraj Modi from comment #20) Correction in bug numbers bug 576210: for Table and bug 576211: for Toolbar widgets. This cause API versioning issue, as reported by Ed on the mailing-list. (In reply to Mickael Istria from comment #22) > This cause API versioning issue, as reported by Ed on the mailing-list. Taken care by commit in comment 14, API versioning issue is not seen in latest API tools report: https://download.eclipse.org/eclipse/downloads/drops4/I20210923-1800/apitools/analysis/html/org.eclipse.swt/report.html Verified in Eclipse IBuild: I20210929-1800 on Win10 |