Bug 121525 - Bring forward / Send Backward
Bring forward / Send Backward
Status: NEW
Product: platform
Classification: Unclassified
Component: Graph
6.x
Macintosh All
: P2 with 1 vote (vote)
: TBD
Assigned To: issues@platform
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-08 23:36 UTC by _ oracmpalmer
Modified: 2011-11-28 18:26 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch to Widget (1.30 KB, patch)
2007-11-08 23:37 UTC, _ oracmpalmer
Details | Diff
WidgetSupport patch (4.53 KB, text/plain)
2007-11-08 23:38 UTC, _ oracmpalmer
Details
Changes included (6.16 KB, patch)
2008-01-07 04:30 UTC, _ oracmpalmer
Details | Diff
Final Patch Proposal (13.78 KB, patch)
2008-01-07 15:19 UTC, David Kaspar
Details | Diff
Mercurial final patch (4.57 KB, patch)
2008-02-15 13:55 UTC, David Kaspar
Details | Diff
Mercurial final patch with new files (13.78 KB, patch)
2008-02-15 14:51 UTC, David Kaspar
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ oracmpalmer 2007-11-08 23:36:48 UTC
If users create stacked widgets they currently have only Send to back and bring to front. More complex uses are required. Specifically send backward and bring 
forward.

Having discussed this and the desire for Widget to not become the "Uber" class. WidgetSupport.java and 1 new method to Widget was proposed. 

I have tested the attached diff in our application and it appears to work well.
Comment 1 _ oracmpalmer 2007-11-08 23:37:42 UTC
Created attachment 52764 [details]
Patch to Widget
Comment 2 _ oracmpalmer 2007-11-08 23:38:19 UTC
Created attachment 52765 [details]
WidgetSupport patch
Comment 3 David Kaspar 2007-11-09 11:45:45 UTC
Idea is good and we may add it to the CVS after NetBeans 6.0 release.
Comments:
1) Widget.orderChildren method is working with parentWidget.children but it makes more sense to modify the Widget
children directly instead.
2) WidgetSupport class has to be final.
3) Integer.intValue is not necessary because of auto-boxing in Java.
4) Maybe we can use arrays instead of Lists - it could be faster i.e.
Widget.reorderChildren (int... permutation)
the int[] could be used in WidgetSupport class too
5) Missing @param description in Javadoc in WidgetSupport
P.S.: You can use one patch file for all changed/new/removed files.
Comment 4 _ oracmpalmer 2007-11-09 15:21:31 UTC
>>1) Widget.orderChildren method is working with parentWidget.children but it makes more sense to modify the Widget
>>children directly instead.

I was following the lead in the methods that exist in Widget already. That is what they do? Perhaps it should be on "Scene"

>>2) WidgetSupport class has to be final.

Ok

>>3) Integer.intValue is not necessary because of auto-boxing in Java.

OK

>> 4) Maybe we can use arrays instead of Lists - it could be faster i.e.
>>Widget.reorderChildren (int... permutation)
>>the int[] could be used in WidgetSupport class too

Sure if you really believe it will help.

>>5) Missing @param description in Javadoc in WidgetSupport

OK

Comment 5 David Kaspar 2007-11-12 08:59:59 UTC
Re: Re: 1)
I assume you mean Widget.bringToFront() - that widget does not take any parameter therefore it is itself that has to be
send to particular z-order.
In Widget.orderChildren(...) - you are saying that the Widget children should be changed.

Re: Re: 4)
Ok. I am not 100% sure - I just think it would be faster and enough convenient because developers would have pre-create
the array of particular size anyway. Therefore there is not explicit need for using List.
Comment 6 _ oracmpalmer 2008-01-07 04:30:22 UTC
Created attachment 54733 [details]
Changes included
Comment 7 _ oracmpalmer 2008-01-07 04:33:24 UTC
I have made the suggested changes. I still don't think its too important about the List<Integer>.

>>Re: Re: 1)
>>I assume you mean Widget.bringToFront() - that widget does not take any parameter therefore it is itself that has to be
>>send to particular z-order.
>>In Widget.orderChildren(...) - you are saying that the Widget children should be changed.

I updated the api to include the specific parent is that sufficient? I still don't have commit access so you will have to commit the changes.
Comment 8 David Kaspar 2008-01-07 15:19:27 UTC
Created attachment 54756 [details]
Final Patch Proposal
Comment 9 David Kaspar 2008-01-07 15:21:55 UTC
I have updated the code a little bit: Mainly Widget.orderChildren method changes children of THE widget and
WidgetSupport class methods does not require parentWidget parameter.
I have attached the patch in "Final Patch Proposal".
Chris, could you look at it? Let me know, if you agree with it. If so, I will post it to API review. Thanks.
Comment 10 _ oracmpalmer 2008-01-09 00:57:34 UTC
Well I tested the patch with our application and it appears to work the same. I think we can commit and test. Once api review accepts.
Comment 11 David Kaspar 2008-01-09 08:21:33 UTC
The change is adding a new Widget.orderChildren method and a new WidgetSupport class. The patch contains documentation,
javadoc, automated test (test.apichanges.WidgetOrderTest), ...

Asking for API review.
Comment 12 Jaroslav Tulach 2008-01-15 14:28:30 UTC
Y01 I've heard somewhere, that assert shall not be used to verify API method parameters.
Y02 Write a test to verify behaviour on incorrect parameter to "orderChildren" method.
Y03 As far as my own experience (Nodes API) says, reordering with permutation is one of the biggest mistake one can 
do. First of all one needs to compute the permutation, then apply it. Who guarantees data structures are not modified 
meanwhile? Better to have reorder(Widget[] preferredOrder) that does all of this itself, imho.
Comment 13 Andrei Badea 2008-01-15 15:21:16 UTC
Re. Y01: you can use org.openide.util.Parameters for checking method parameters.
Comment 14 David Kaspar 2008-02-15 13:55:47 UTC
Created attachment 56731 [details]
Mercurial final patch
Comment 15 David Kaspar 2008-02-15 13:57:14 UTC
I have attached a new patch file with Y01, Y02, Y03 implemented.
Comment 16 Jaroslav Tulach 2008-02-15 14:14:42 UTC
Y02 I cannot find any test in the "final" diff
Y04 Is the method supposed to be threadsafe or what is its supposed threading usage? I am asking because two threads 
accessing it can cause big mess. 
Comment 17 David Kaspar 2008-02-15 14:51:09 UTC
Created attachment 56734 [details]
Mercurial final patch with new files
Comment 18 David Kaspar 2008-02-15 14:53:52 UTC
Y03: Sorry, I have forgotten to include new files into the patch.
Y04: The library is meant to be used in AWT-thread only - mentioned in documentation. It would be good to check add
checking for AWT-thread to all API methods.
Comment 19 Jesse Glick 2011-11-28 18:02:45 UTC
Still active?


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo