Requested by the Bow team: Provide a way to make tabs "flash"
or otherwise request the user to click on them, for use in
Created attachment 17538 [details]
Implementation of "flashing" tabs on the 4.0 tab control w/ heavy unit tests; also some bug fixes found while writing the tests
I'm tempted to integrate this, given that the "flashing" code path will not be used by
NetBeans 4.0, and the additional tests and bug fixes (a couple off-by-one errors in the
data model when using add/remove methods the window system doesn't normally use) are
But since it's late in the 4.0 game, this should probably wait for 4.1.
Created attachment 17539 [details]
Backport of the 4.0 window system to 3.6 (test heavily if you want to use it!)
Created attachment 17564 [details]
Blinking tab patches (improved) + integration into window system & API for 4.0
The last patch adds the following methods to TopComponent:
public void requestAttention (boolean brief); //if brief, it will blink a few times and stop
public void cancelRequestAttention();
and the following methods to WindowManager:
protected void topComponentRequestAttention();
protected void topComponentCancelRequestAttention();
and blinking is also implemented for sliding buttons.
Created attachment 17565 [details]
Window system backport to 3.6 with blinking tabs code
Assigning to API reviews - might as well get a head start on this, so once the trunk is
branched for 4.0 release, it can be committed.
I can confirm that this is really heavy tested. I have no comments
about the functionality, I believe that it works and I am sure that
this will be maintainable in future.
I just want few more improvements in documentation. Please mention
1. set of usecases in
2. set of usecases of windowsystem arch*.xml
3. create apichanges document for TabbedContainerAPI and update it
4. update window system apichanges
> I just want few more improvements in documentation. Please mention
> this in...
No problem with doing that - but I've learned my lesson with including
docs patches in code patches - inevitably someone adds some other
change before the issue is committed, breaking the diff, and you have
to keep fixing the patch to keep up with arch or apichanges docs.
So no problem to do this, but if you don't mind I'd rather integrate
the code, then add the documentation.
what is the status of this review?
I assume it's approved and just waiting to be integrated. Since Tim is
no longer on the winsys/ui team, I guess I'm taking over.
Created attachment 18924 [details]
apichanges for openide
integrated into trunk.
increased version of openide+core/tabcontrol
added apichanges entries.
Thanks for doing that, Milos - I was wondering this week if I should step in and go ahead
and integrate this :-)
I would suggest to make the WindowManager methods non-abstact and
empty. It hurts nobody and makes 4.0 and 4.1 at least binary compatible.
ok, it's quite unlikely that soneone would attempt to implement
his/her own window system but generaly it's ok with me to make it
done, Windowmanager has the new methdos as non-abstract.