Community
Participate
Working Groups
I have many packages in modules like the following com.company.module.packagea com.company.module.packagea.core com.company.module.packagea.test com.company.module.packageb com.company.module.packageb.core com.company.module.packageb.test Since packagea and packageb only differ by the last character (in real case it is more than just the last character, but the 5-6 characters are the same) compression doesn't help much in identifcation, except by knowing the order after the main package. c.c.m.packagea c.c.m.p.test c.c.m.p.core c.c.m.packageb c.c.m.p.test c.c.m.p.core Instead, I would like to be able to compress only the first N parent packages (in this case 3) and have: c.c.m.packagea c.c.m.packagea.core c.c.m.packagea.test .etc. Since I know that all packages in the module will start with "com.company.module" I actually would choose '...' which I can currently, but for all but the last name, not just the first N.
Makes sense. Any suggestion on how to name the option?
Finally put some thought into this, and I would make this part of the existing option setting "Compress Package Name Segment" (Preferneces->Java- >Appearance). I would add a new Sub setting (in addition to 'Compress pattern') and add "Compression Depth". For example for a package called "com.company.foo.bar" and a compression pattern of "1." the following senarios exist with "Compression Depth". Compression Depth: 1 (only the first package name is compressed) c.company.foo.bar Compression Depth: 2 (the first two package names are compressed) c.c.foo.bar Compression Depth: -1 (default) (all but the last one is compressed) c.c.f.bar Compression Depth: -2 (all but the last two are compressed) c.c.foo.bar etc.
Would you also compress the last package if the depth is bigger than the segment count? I think the most significant i.e. last should always be visible. I assume 'depth' would need to be explained - especially negative depth.
Additional comments from Robert Varga (from bug 24612): A useful package name compression feature would be to cut a user-settable number of parts from the beginning of the fully-specified package name in the package explorer, if the full package name is longer than the specified number of parts to be cut. The cutting would be indicated with a dot (.) at the beginning of the shown version of the package name. Eg. with a number of two, a package name of 'com.mycompany.project.test' would result in displaying something like '.project.test' ( to show that the full number of parts were cut). In case of the full package name is less than or equal to the number of parts to cut, it would show the original package name, eg. with a setting of 4, 'com.company.project.test' would be displayed as 'com.company.project.test', 'com.company.something' would be 'com.company.something', but 'com.company.project.something.ui.test' would be only '.ui.test'. It would be most useful if this number could be set on a per-folder or at least per-project basis, but even if it would be a single setting for the whole Java Perspective, it would still be useful. Regards, Robert Varga
Yes, I would totally agree that the last name should always be visible and "depth" would have to be explained. "Depth" might not be the best name for it either. However, I think it is a better solution to have this feature be part of the current compression option, instead of a new one. "Number to Compress" might be a better name than "Compression Depth". However, explaining the differences between +2 and -2 would still be the difficult part.
how'bout adding a checkbox (or a group of 2 radio buttons) - if checked, then the 'depth' is positive otherwise it's negative the labels would be sth like: 'compress trailing segment names' and 'compress leading segment names'
Created attachment 2158 [details] PackageNameCompressor class implementing suggested package name compression
hm, here comes the suggestion, because it somehow got omitted: The mentioned feature request (22208) describes a behaviour similar to what I mentioned with some differences. That solution can be used to reproduce mine, if compression is set to leave 0 characters of package names, except for that it leaves additional dots at the beginning of the results. The most satisfying combination of the two requests could be the following: 1. More than one compression zones could be specified. 2. The zone has a length, which can be given in the number of segments. At all zones but the last, this number is mandatory and must be positive. At the last zone, it can also be a negative number, or can be omitted, which is the same as the setting of -1. A specified setting of 0 is considered negative and means even the last segment is compressed. 3. Different number of characters to show from the segments could be set for each zone. 4. If number of characters to leave from a segment is 0, and the length/depth of that zone is greater than 1, then it should be possible to hide the dots that are in the middle of that zone. (the output of that zone would be a single dot, and not a number of dots equal to the length/depth of the zone). 5. A setting can control, that zones should be compressed only if there are segments remaining after this zone, or also when no segments are after this zone. This is meaningful only in zones with length/depth specified. Processing the zones: - Case A: If the length of the last zone is positive: 1. All segments are compressible. Unprocessed segments are fed to zones from left to right. 2. If a zone does not compress any segments, then compressing stops. 3.1 If the number of uncompressed segments is greater then the length of this zone, then the zone is compressing its prescribed number of segments. 3.2 If case 3.1 does not fit, but the zone is set to 'compress segments, even if the number of uncompressed segments is not greater than the length of this zone (no segments will be left uncompressed in this case), then the zone is compressing the remaining segments. - Case B: If the length of the last zone is negative (or ungiven which is the same as -1): 2. If the full original package name is shorter than 'n' segments, then no segments are compressible, therefore nothing is done, stop. 3 Otherwise, the compressible segments are fed to the zones from left to right. 4. The compressible segments are processed the following way: 4.1 If zone is the last zone (length is negative), all the remaining compressible segments are processed. 4.2 If this is not the last zone, and the previous zone did not process any segments, then this zone does not process any segments. 4.3 If this is not the last zone, and the previous zone processed segments: 4.3.1 If there are at least 'x' number of unprocessed segments where 'x' is the zone-to-be-processed, then the zone is processed. 4.3.2 If zone is not processed in 4.3.1, but there are unprocessed segments, then if the zone is set to process segments, even if the number of unprocessed segments is not greater than the length of the zone (no unprocessed compressible segments remain after the zone), then the zone is processed. In this case, the last zone will process 0 segments. 1. If the last zone length is positive, all segments are compressible. If the last zone length is negative, then the last 'n' segments are never compressed, where 'n' is the absolute value of the length specifier of the last zone, they are not compressible. The segments before this 'n' segment are the compressible segments. If the last segment length is omitted, it is interpreted as a length of -1. If the last segment length is a specified 0, it is interpreted as in negative, therefore all remaining segments are compressible. 2. If there are no compressible segments, then the original package name is returned. 3. The zones are processed from first to last. The segments are fed to the zones from left to right. 4. Loop on zones: a: If the zone is the last zone and the length is negative, all remaining segments are compressed. Otherwise: b: If the previous case (4.a) does not fit, and there are less than 'x' uncompressed but compressible segments left, where 'x' is the length of this zone, then - if we are not forced to process zones when there are no segments after the zone, then -- if the last zone is negative, then jump to that zone, and compress all remaining compressible segments as per that zone, and then stop compressing. -- if the last zone is not negative, then stop compressing. - otherwise do case 4.c c: The zone compresses the number of segments specified for it, if there are that many compressible segments, otherwise processes all compressible segments left. If there are compressible segments left, then take next zone, if not specified otherwise in 4.b 5. Uncompressible segments are appended to the compressed ones. Compression of a segment is the following: 1. Take the number of characters as specified to be kept. 2. If the length of the segment is more then the specified for keeping, then append the replace character if it is given. 3. If the segment is not the last segment, then - if the dot in the middle of a zone setting is true for this zone, and it is not the last segment in the processed part of the zone (a zone can be partially processedin step 4.c) then append a dot ('.') - if the dot after the zone setting is true, and we are at the end of the processed part of the zone, then append a dot ('.') The cases in both requests (22208, and this) and also the behaviour in 2.0.1 can be fully carried out with this specification. Zones can be given as a space separated list of zone definitions. A zone is parsed from the right side of the string. A zone definition format is the following: zonedefinition::= <compressionspecifier>[<lengthspecifier>] lengthspecifier::= { SLASH | BACKSLASH } length Slash means compression is not forced if - the last zone length is positive, and no segments remain after the zone, or - the last zone length is non-positive, and the processed zone is not the last, and there are less compressible segments than the length of the zone processed zone Backslash means compression is forced in the upper two cases. compressionspecier::= [<keepchars>][<replacechar>][<dotchar>] dotchar::= { DOT | EXCLAIM | PIPE | ASTERISK } DOT ::= '.' and it means, dots has to be appended after every compressed segment EXCLAIM ::= '!' and it means no dot will be appended after compressed segments PIPE ::= '|' and it means, that only dots in the middle of a processed zone will be appended (in case of incompletely processed zones, the last processed segment won't be followed by a dot). Not too useful. ASTERISK::= dots will be appended only after a processed zone, but no compressed segments not ending a zone Here a segment is considered compressed, even if the name is shorter or equal long to <keepchars>. replacechar::= any non-space and non-digit character (default nothing) ********************************************** * for replacechar to be any valid dotchar * * character, dotchar has to be given as well * ********************************************** keepchars::= number of characters to keep from a segment (default 0) (at least one of the uppers must be specified)
Created attachment 2159 [details] Corrected version of the PackageNameCompressor.java
Created attachment 2160 [details] Reformatted and corrected suggested specification
Hm, the formatting got a bit wrong, and I found a small bug. Here comes the code and the new specification again, now corrected, both attached. I uploaded the corrected versions. (the files with timestamp 10/10/02 15:26) Regards, Robert Varga
Forgot to mention: The suggested specification is backward compatible with the mentioned suggestions and the old behaviour. All old patterns are working the same way. Normal compression depth of eg. 2, can be set by appending a /2 Compression depth of -2 (except two from backward) can be set by appending /-2 Cutting away three root packages with dot prepended is the pattern if there are at least 4 segments: 0*/3 Same without a dot prepended is 0!/3. Cutting away to packages, compressing another two to 2 characters and tilde is: "0/2 2~/2" And so on... Regards, Robert Varga
Created attachment 2163 [details] Here is what I implemented (read readme.txt in the zip file)
smartcompresspattern.zip contains my implementation put into Eclipse R201 and I20020920 Included is two new classes with source: PackageNameCompressor.java and PackageNameCompressionZone.java, put in the org.eclipse.jdt.internal.ui.viewsupport package. Also a changed version of org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabels from both mentioned versions is included in the zip file, both source and class file. From that it would be easy to create a patch file, but I did not bother with that. For documentation, look at readme.txt No change is necessary on the user interface, everything is handled from the single pattern field. I haven't done a thorough testing, but it works in Eclipse with all patterns that I tried so far, and what patterns I mentioned previously. I am already using it :) Feel free to use it, change it as you want, the only thing I ask is, that you send me a message if the functionality gets into Eclipse so that I won't have to modify versions on my machine manually :-) Regards, Robert Varga
Robert, thanks for your contribution! I will take a closer look probably for M3 (no commitment though ;-)
Neil, would the provided/described compression satisfy your needs too?
Daniel and Robert, I plan on trying it out sometime soon. From the sound of it, it does look like it support what I want. Thanks, Neil
Created attachment 2173 [details] fixed problem in processSegment if segment name was longer than characters kept
ehh... not longer, but shorter... :)))
I have tried out the code and it does provide the functionality that I desired as part of the compression process. I had some bugs using it in which my Package Explorer would go blank, and disabling the compression mode wouldn't fix the problem (had to restart). However, I didn't use the bug fix code posted on 10/11, just the 10/10 zip file. I had more problems testing on the 2.1 stable build compared to using the 2.0.1 build. If I have a package of the following: com.company.module, com.company.module.test, and I select 1./3 I get com.company.module ...test (it doesn't compress the one with just 3 segments at all, I'm not sure if I would want ..module, ..., or what happened.) Once I use the syntax and try various senarios it works quite well. However, I worry that first time users will find it difficult and select senarios that are not very good. Hence, a better UI might need to be explored or at least a good description. Good work on the development of this, since it will really help compact the packages giving back more screen space back to the editor.
The last uploaded version (10/11/02 16:19) fixes the freeze in the Package Explorer. 1./3 pattern does not compress a three-segment package name at all. 1.\3 does compress it (enforce compressing zone, when no segments remain after the zone). It would make c.c.m of com.company.module. Of course a better UI is always welcome to this, mostly because then the user won't have to use characters with obscure meaning, but can have explanatory text beside the settings. It also took a bit time until I found out what the normal compression is exactly capable of.
I use Eclipse 3.0.1. Is there a solution for this problem? The status of this bug is still New. I want to use a Working Set which shows me only some Java packages. If I use Flat Layout in Package Explorer, the view must be really wide to read the package names because they are so long. We have something like this: com.haefele.hsw2.purchasing.components.supplier.global.SupplierVO I want to crop the package name so that it only shows the last three packages: components.supplier.global The other package names shall not be shown, not even in a compressed form. How can I do this without rewriting Eclipse?
I did not update my code for the latest version but probably it is very easily doable. The change to be done was almost identical for 3.0 milestones to the one posted here. Unfortunately it never made into Eclipse, I did not get a response at all about this, after it being promised to be looked into after 2.1M3 which is quite a while ago... I will try to take some time and fix this and package it up so that it can be put into the directories without overwriting anything.
Moving back to inbox (ownership changed).
No high priority for 3.1 given that we have to get J2SE 5.0 rolling.
(In reply to comment #25) > No high priority for 3.1 given that we have to get J2SE 5.0 rolling. I saw a friend with the IDEA IntelliJ editor and saw how he had compressed a package names to really utilize the screen space effectively and not clutter it with repeated and unnecessary stuff. For example, in Eclipse I see: + com.my.company.name.projectname.business for a particular project, whereas he sees: + business (or projectname.business if he so decides). The best I could do without losing too much information so I can still decipher the package name is: + com.my.com~.nam~.pro~.business Can you take a guess which one seems better to me? And don't forget that it ensures your naming pattern doesn't have anything that starts with the same letters! Thanks.
>for a particular project, whereas he sees: > >+ business Eclipse can do this as well: simply enter 0 as compression pattern. In addition try the hierarchical layout.
(In reply to comment #27) > >for a particular project, whereas he sees: > > > >+ business > > Eclipse can do this as well: simply enter 0 as compression pattern. > In addition try the hierarchical layout. > Sorry, I suppose I used a bad example, as there may be: business business.this business.that dao dao.this dao.that so that just showing the last package name wouldn't be sufficient. I'm ignoring the whole com.company.module. prefix on the package names above for berevity.
Robert would you be willing to provide CVS patches (using Team > Create Patch...) that we can directly apply and test? The patch should not only contain the new code but also an updated version of the preference page, explaining the new options to the user and also updated versions of the corresponding documentation files: org.eclipse.jdt.doc.user/reference/ref-preferences-appearance.htm org.eclipse.jdt.doc.user/tips/jdt_tips.html
(In reply to comment #29) > Robert would you be willing to provide CVS patches (using Team > Create > Patch...) that we can directly apply and test? The patch should not only > contain the new code but also an updated version of the preference page, > explaining the new options to the user and also updated versions of the > corresponding documentation files: > org.eclipse.jdt.doc.user/reference/ref-preferences-appearance.htm > org.eclipse.jdt.doc.user/tips/jdt_tips.html > Hi Daniel, unfortunately I am not really experienced in hacking Eclipse. I managed to track down what needs to be done to make this behaviour working, but I did not touch the preferences page at all (therefore even the explanation there remained the same (which still applies, only it does not cover the new functionality in its entirety). I will try to update the code to work with 3.1/3.2 codebase, but I don't yet know where to look for the preference stuff. I will probably be able to modify the two mentioned html files. I am also unsure whether even a short version of the description of the functionality would fit into the preference page to the place currently occupied by the example static text. Preferably a new set of preferences should be added for easy configuration but I am not proficient in hacking Eclipse to volunteer for that in a short timeframe. Anyway, I will update the stuff I mentioned as soon as I am able (I have to make some free space on my hard drive to be able to start hacking on 3.1/3.2, and familiarize myself with the changes in the source and patch structure in 3.1/3.2). Best regards, Robert Varga
>unfortunately I am not really experienced in hacking Eclipse. No need for hacking ;-) Simply load 'org.eclipse.jdt.ui' and add the feature as you would like to see it in the product. Then create a patch (Team > Create Patch...). >but I did not touch the preferences page at all see 'AppearancePreferencePage' in org.eclipse.jdt.ui
*** Bug 207703 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
