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.
Not trivial rewrite, especially if we want to import old settings.
1/ Import There is no problem to import direct properties like: footerAlignment, footerFont, footerFormat, headerAlignment, headerFont, headerFormat, lineAscentCorrection, wrap. Is it really necessary to import colors for the individual mime types ? 2/ Compatibility I suggest to move PrintSettings to openide.options module similar like in #88769. 3/ API There is question whether PrintSettings should be replaced by new API or just rely on Preferences ? 4/ UI Probably should be moved to new OD and could be fixed as part of #90522 - probably by editor guys.
IMHO: Re. #1 - keep it simple. Since we never exposed print settings in a usable GUI I kind of doubt very many people ever even realized they could be customized at all. So it seems unlikely that more than a handful of users have any nondefault print settings to import. Of course we have no logs to confirm this guess. Re. #3 - I don't believe we need any API for this but check with editor folks.
Created attachment 36783 [details] Suggested API changes
Created attachment 36784 [details] Import
Created attachment 36785 [details] dependencies
Created attachment 36786 [details] Usage of new API in org.openide.actions
API is acceptable, imho. The only problem I found is that I do not see ModuleAutoDeps registered that would prevent older modules using the PrintSettings class directly to link against its new home in openide/options.
module-auto-deps.xml is also attached - see: http://www.netbeans.org/nonav/issues/showattachment.cgi/36783/i88531.diff
Do we need the Java API (PrintPreferences) at all? All I see using it, outside of the o.o.text package (for which BTW there is no diff in DefaultPrintable and CloneableEditorSupport) is PageSetupAction. But PSA could just set the appropriate Preferences keys directly, just using some documented pref keys in arch.xml for openide/text. In fact we could move PSA to openide/options, deprecate it, and add a new action to a non-API package in openide/text with similar functionality; would just need to update whatever layer (core/*?) registers it as a menu item. So I am not so eager to (re-)introduce a Java API for something that we do not expect random foreign code to be calling anyway. BTW the editor/plain module also uses PrintSettings, but apparently only to add/remove suboptions, which is to be deprecated anyway. Again there is no diff showing how this code will be corrected.
Looking at the old 'Print Settings' node in Advanced Options -> IDE Configuration -> System there is actually quite a few modules using o.o.text.PrintSettings for adding suboption with font & colors for printing. All those colors however are set to black & white by default and as Jesse pointed out hardly anybody has ever changed them. We were discussing this with Mila and we think that these options could probably be removed completely. We could then use the same font & colors for both editing and printing. It is not so uncommon nowadays to have a color printer and their drivers always give user an option for printing in black & white. I don't think we need to duplicate this functionality in the IDE.
Current usage of PrintSettings: - org.openide.text (DefaultPrintable, ... - diff not included but I'm aware about it and have it fixed) - org.openide.actions - PageSetupAction - org.netbeans.modules.image - ImagePrintSupport New API options: 1/ PrintPreferences API 2/ Preferences API and let PageSetupAction where it is 3/ no API(Preferences will be used but not documented as shared) and move PageSetupAction into org.openide.text 4/ Preferences API and move PageSetupAction into org.openide.text anyway I would like to ask reviewers for recommendation which from above mentioned options they find best. I agree with Vita but anyway I do not plan to drive fonts & colors printing myself and I'm going to reassign this issue to editor after removing PrintSetting (eventually replacing it with new API) - that's the reason why there is no diff for fonts & colors.
In fact regarding printing we just need NbDocument.Printable contract for the editor and nothing else. The adding of extra nodes in the individual modules is done by: PrintSettings ps = (PrintSettings) SharedClassObject.findObject(PrintSettings.class, true); ps.addOption((SystemOption)SharedClassObject.findObject(JavaPrintOptions.class, true)); So if the PS will be available in a deprecated module then all should be fine and the editor module should drop the code above gradually together with *PrintOptions being added under PS node.
Tomorrow is my latest M6 day, no clear agreement => M7
still not fixed (after M7)
This might be unrelated to this particular issue, but how much important is printing and print settings for platform? As part of the issue #95077 we were planning to discard the 'Print Settings' node and all its subnodes including most of the impl behind it and introduce the new 'Printing' panel under the Tools-Options->Editor, which would allow customizing page header/footer layout, fonts, etc. (but no special colors for printing) Obviously we don't want to get ourselvs in the same situation as with the Keymap panel, when functionality needed in the platform is provided by editor modules that do not belong to the platform.
Hello, thanks for putting me on Cc: of this issue. I will ask my colleagues and report back here.
I was informed that we use "File --> Page Setup" in our RCP based application. We do not use the advanced options for anything but I of course cannot speak for other platform users.
Thanks for that David. I personally doubt anybody's ever found those settings. The 'Page setup' action on the other hand is a pretty standard thing and as long as we have the action there is probably not much sense in having the same customization in Tools-Options. So, we might consider removing Print Settings node without any replacement in the modern look of Tools-Options.
Hi, could somebody knowledgable in SharedClassObject and ContextSystemOption review the following change, please? I'd like to remove print options from editor modules, but need to deal with the situation when an option instance was serialized in a userdir. So, I simply can't delete the class that implements the option, but at the same time I don't want this class to extends SystemOption anymore. Since SystemOption is SharedClassObject, its deserialization is done in a way that involves SCO.findObject(clazz), where clazz is the 'new' implementation class of the old option. This 'new' implementation class does not extend SystemOption anymore and I'd like to account for that in the SCO.WritableReplace.readObject. Please see the diff. The diff also contains changes in html/editor as an example of what I'd like to change in editor modules that are adding print options. I ran tests in openide/util and they all passed, so I think the change is ok. If nobody objects I'll commit it to trunk and remove print options from the rest of modules.
Created attachment 42347 [details] Changes in SharedClassObject and ContextSystemOption
Running 6.0 with 5.0,5.5 userdir is probably not recommended. I think that PrintSettings shouldn't be migrated into 6.0. If not migrated then you wouldn't need to care about deserialization, I think. Then you could just simply delete the class.
> Running 6.0 with 5.0,5.5 userdir is probably not recommended. This is the first time I've heard something like that. How sure are you? Anyway, backwards compatibility can be achieved and the solution is not even terribly complicated or ugly. I think we should do the removal in backards compatible way no matter what happens with PrintOptions during userdir migration.
1. Probably -1 on the patch. I don't think we should make further changes in SCO/SO/CSO semantics, and we should really attempt to disable the org.openide.options module by default in 6.0. 2. If you don't ask to load a serialized SO from 5.x, nothing will happen, so there is no compatibility issue in terms of getting CNFEs. Serialized .settings files are not loaded unless someone asks for them, which would not happen if you are now using NbPreferences. 3. Probably we do not need to import print settings. I am guessing that very few users ever customized these to begin with, especially since the UI was so esoteric. 4. If you *do* want to import print settings, add a translator to ide/launcher/upgrade, following the examples you see in sources and tests there.
#1: ok, I understand #2: The editor doesn't load them, because it doesn't need them anymore. They are loaded from the 'Print Settings' node in Tools-Options only (AFAIK). This node also offers settings for page layout customization and I am not sure if I can simply remove it. If I could then all would be fine, no need for the patch. #3, #4: No, we don't want to import print settings.
Certainly you can remove the node in Advanced Options if it doesn't even work anymore. Generally we want to remove everything from Advanced Options. Am I missing something?
Well, the node offers two things: a. page layout customization (header, footer, etc) b. childer nodes supplied by editor modules that allow customizing font & colors used for printing Now, a. is working fine, b. is not, because editor infra no longer supports special colors for printing. All I wanted to do was to get rid of the children nodes from the editor modules (b), but leave the 'Print Settings' node itself there for someone else to deside its fate. Afterall page layout is not the editor thing, it's part of the printing support in the platform. Anyway, I've got another patch that only affects PrintSettings class and its de-externalisation. Basically, PrintSettings does not load its children SystemOptions from the .settings file, but keeps loading the page layout related settings. Would that be acceptable?
Created attachment 42397 [details] PrintSettings patch that disables loading its children SystemOptions
I'm almost sure that it shouldn't be recommended but I'm sure that there is no agreement on it. I think that migration should be recommended. We have two ways(with two different result) how to deal with old settings in 6.0 IDE: 1. after migration 2. just running with old userdir After migration ---------------- Just subset of old settings is migrated. Many of those SystemOptions that were not exposed like public API, replaced by Preferences API and their classes were deleted - will be also migrated(if specialized code was put in the migration). Just running with old userdir ----------------------------- All settings will be migrated (== as it were migrated). Old not publicly visible SystemOptions(replaced by Pref.API) that were deleted won't be migrated (though no exceptions because nobody looks up them) - were is the backward compatibility here. We invest into migration - put in more specialized code and the other hand we ensure running IDE with old userdir. What is the recommended way? Which way will be tested by QA? Whatever I wrote above - If you can prevent running netbeans from throwing exceptions that its good to do it!!!
If there will be no objections I will commit patches from Radek with new on Thu. (I must review diffs as they are from December.) Current patch introduces new class into org.openide.text as replacement for PrintSettings. Vita do you need you patch in moved PrintSettings class?
Yes, but it can be much simpler, basically just empty readExternal and writeExternal methods to prevent superclass from loading/storing child SystemOptions. I can do that separately after you apply Radek's patches and move the class.
I applied patches, tried to compile, found some problems, fixed it. Still there is one problem I do not know how to handle. There is deprecated public static final class org.openide.text.NbDocument.Color extending org.openide.options.SystemOption. As dependency of org.openide.text on org.openide.options should be now removed it is not compilable now. Any idea how to solve this? I attach updated diff of openide.
Compilation error: [repeat] [repeat] /mnt/local/mslama/netbeans/nbsrc/openide/text/src/org/openide/text/NbDocument.java:611: package org.openide.options does not exist [repeat] public static final class Colors extends org.openide.options.SystemOption { [repeat]
Created attachment 42500 [details] Updated patch diff of openide
It should be possible to create a file NbDocument$Color.java in a deprecated module. Or create a dummy NbDocument.java with a Color nested class, then delete NbDocument.class.
Right, Marek is just doing this and NbDocument$Colors in openide/options seems to work. The other problem is static field in NbDocument referencing the Colors class. The right fix is to deprecate NbDocument as well and move it to openide/options. However as NbDocument is used a lot and it is also mentioned in the examples in our new book, moving it into deprecated API is like asking for the same disaster as happened with TopManager in the previous book. That is why I am suggesting to do incompatible change and remove the field (deprecated for six years). That is likely to cause less harm.
Created attachment 42662 [details] Complete diff with bigger context
I attached hopefully complete patch diff. Commit validation passes. All dependencies on org.openide.text are updated to 6.16. I will perform check to make sure old code which uses PrintSettings and NbDocument.Colors will run against new org.openide.text. I plan to commit changes on Wed or Thu.
openide/options/src/org/openide/text/NbDocument$Colors.java has a typo: package org.openide.options;
Thanks. Fixed. I do not know why compiler did not fail on this?
javac will happily compile a source in the wrong location. (It will put the .class file in the position according to the package statement.)
Created attachment 42703 [details] Updated complete diff
Last update: Fixed typo in package in NbDocument$Colors. Fixed spec version in openide/text/module-auto-deps.xml
Created attachment 42704 [details] Commit log
Fixed in main trunk. Commit log is attached as it is big.
Created attachment 42719 [details] Cleanup of print options from editor modules
cnd module: Checking in classview/nbproject/project.xml; /cvs/cnd/classview/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in completion/nbproject/project.xml; /cvs/cnd/completion/nbproject/project.xml,v <-- project.xml new revision: 1.5; previous revision: 1.4 done Checking in core/nbproject/project.xml; /cvs/cnd/core/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in gdb/nbproject/project.xml; /cvs/cnd/gdb/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in highlight/nbproject/project.xml; /cvs/cnd/highlight/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in makeproject/nbproject/project.xml; /cvs/cnd/makeproject/nbproject/project.xml,v <-- project.xml new revision: 1.8; previous revision: 1.7 done Checking in modelimpl/nbproject/project.xml; /cvs/cnd/modelimpl/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done Checking in modelutil/nbproject/project.xml; /cvs/cnd/modelutil/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in qnavigator/nbproject/project.xml; /cvs/cnd/qnavigator/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in symbian/project/nbproject/project.xml; /cvs/cnd/symbian/project/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2
*** Issue 103751 has been marked as a duplicate of this issue. ***