This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 103187 - Permit folder ordering using numeric sort
Summary: Permit folder ordering using numeric sort
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
: 24776 (view as bug list)
Depends on: 106914 107550 107732 110981 111560
Blocks: 20358 103582
  Show dependency tree
Reported: 2007-05-03 00:58 UTC by Jesse Glick
Modified: 2008-12-22 12:01 UTC (History)
7 users (show)

See Also:
Exception Reporter:

Log of relative -> position conversion (279.61 KB, text/plain)
2007-06-16 11:02 UTC, Jesse Glick
Commit log (64.79 KB, text/plain)
2007-06-16 11:09 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-05-03 00:58:11 UTC
Using relative ordering attributes has proven to be cumbersome when the number
of modules contributing to a folder is large. It should be possible to use
numeric ordering as a simpler alternative.
Comment 1 Jaroslav Tulach 2007-05-03 15:19:28 UTC
Do you know that /etc/init.d scripts deprecated numeric ordering and are 
switching to relative one?
Comment 2 Jesse Glick 2007-05-03 21:00:01 UTC
I had not heard that. (Reference? Google turns up nothing.) Nonetheless the
justification listed in the wiki still applies.
Comment 4 Jesse Glick 2007-05-05 02:09:31 UTC
Interesting, but a quite different situation with little bearing on NB.
Comment 5 Antonin Nebuzelsky 2007-05-10 23:31:41 UTC
Dafe will be interested in this too, as he had to reorder Windows menu for M9.
And was not lucky about that, surprisingly...
Comment 6 David Simonek 2007-05-11 07:19:12 UTC
Great! I spent many evenings with relative ordering and proposed change will
make our developer life (and life of our customers) much easier, I fully support
proposed solution. Thanks for this...
Comment 7 Jesse Glick 2007-05-15 21:04:28 UTC
*** Issue 24776 has been marked as a duplicate of this issue. ***
Comment 8 Jaroslav Tulach 2007-05-24 16:42:33 UTC
A thing which is still not fully clear to me is whether this is proposing an 
incompatible change or not. If it is, then I'd like to remove the FAST from 
API_REVIEW_FAST, if there was such keyword. Anyway, I'd like to see a 
discussion about possible options before doing an incompatible change.
Comment 9 Jesse Glick 2007-05-24 17:36:52 UTC
I don't expect any incompatibilities. As detailed in the wiki, relative ordering
attributes would continue to function, after logging warnings.

It's not up for API review yet because I am still developing it. But you can see
the plans on the wiki.
Comment 10 Jesse Glick 2007-06-11 00:32:03 UTC
I would like to submit this change for API review, targeted for inclusion in
M10. Everything you need to know is in the wiki. I am continuing to work on
implementation (mainly usages of the new API) but the API itself, including
usage in DataFolder, should be ready for review. I expect changes to be
compatible - while I will upgrade all modules in the standard IDE, unmodified
third-party modules should still be able to insert files in relative positions
(with warnings printed to the log).
Comment 11 err 2007-06-11 02:08:46 UTC
I support a module unchanged between NB55 and NB60 (thanks to a little
reflection). One problem was the position of a Tools menu item. Discovering that
position was determined through a tsort algorithm actually made is simple to set
it up so the same layer file worked with both NB versions. The wiki seems to
indicate that good practice, when changes are made, is to keep existing numbers
as possible. There's a question in here somewhere...

How difficult do you think it will be moving from release to release with the
absolute verses relative schemes?
Comment 12 Jesse Glick 2007-06-11 16:24:52 UTC
To err's question:

If the immediate context of your menu item does not change between releases,
then relative ordering attributes are OK: you can use the same pair of attrs for
both releases. The problem arises when the nearby menu items do change. In some
cases you can overspecify your order in such a way that your item will still
show up in the right place in both releases. (If the menu is totally rearranged
this might not be possible, though this is rarer.) This can be pretty
cumbersome, however.

Using numeric positioning, you would just choose an appropriate position in the
earlier release and then check up on it in the newer release. It is possible
your menu item will have "drifted" a bit, though catastrophically wrong
positions are much less likely than when using relative attrs. You are correct
that it is desirable for maintainers of the IDE/platform/whatever to not make
gratuitous changes to positions of existing menu items between releases.

As mentioned in the wiki, I have a script which I plan to use to replace all
relative attrs with numeric positions in the full IDE (i.e. including visualweb,
uml, ...). It simply assigns positions 100, 200, 300, ... to each file/subfolder
in the desired order. This should be enough to get us started, though probably
for 6.0 we will want to hand-tune the positions for important areas like the
menu bar and list of templates, so that separators are placed e.g. at multiples
of 1000 and perhaps named according to their position ("sep2000.instance").
Comment 13 Jesse Glick 2007-06-16 11:02:56 UTC
Created attachment 43839 [details]
Log of relative -> position conversion
Comment 14 Jesse Glick 2007-06-16 11:09:34 UTC
Created attachment 43840 [details]
Commit log
Comment 15 Jesse Glick 2007-06-16 11:10:49 UTC
Implemented in trunk. Minor tasks remain, as detailed in wiki.