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 88531 - Remove SystemOption usage from PrintSettings
Summary: Remove SystemOption usage from PrintSettings
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: mslama
: 103751 (view as bug list)
Depends on:
Blocks: 77030
  Show dependency tree
Reported: 2006-11-02 17:16 UTC by Jesse Glick
Modified: 2008-12-22 14:49 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Suggested API changes (62.02 KB, text/plain)
2006-12-19 08:35 UTC, rmatous
Import (69.00 KB, text/plain)
2006-12-19 08:37 UTC, rmatous
dependencies (128.06 KB, text/plain)
2006-12-19 08:46 UTC, rmatous
Usage of new API in org.openide.actions (1.74 KB, text/plain)
2006-12-19 08:52 UTC, rmatous
Changes in SharedClassObject and ContextSystemOption (8.06 KB, text/plain)
2007-05-13 08:26 UTC, Vitezslav Stejskal
PrintSettings patch that disables loading its children SystemOptions (2.31 KB, text/plain)
2007-05-15 02:42 UTC, Vitezslav Stejskal
Updated patch diff of openide (76.25 KB, text/plain)
2007-05-17 13:36 UTC, mslama
Complete diff with bigger context (363.49 KB, text/plain)
2007-05-22 21:57 UTC, mslama
Updated complete diff (363.98 KB, text/plain)
2007-05-23 16:52 UTC, mslama
Commit log (47.99 KB, text/plain)
2007-05-23 18:07 UTC, mslama
Cleanup of print options from editor modules (7.25 KB, text/plain)
2007-05-24 05:10 UTC, Vitezslav Stejskal

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2006-11-02 17:16:32 UTC
Not trivial rewrite, especially if we want to import old settings.
Comment 1 rmatous 2006-12-05 10:41:38 UTC
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.

Comment 2 Jesse Glick 2006-12-05 21:26:01 UTC

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.
Comment 3 rmatous 2006-12-19 08:35:20 UTC
Created attachment 36783 [details]
Suggested API changes
Comment 4 rmatous 2006-12-19 08:37:07 UTC
Created attachment 36784 [details]
Comment 5 rmatous 2006-12-19 08:46:09 UTC
Created attachment 36785 [details]
Comment 6 rmatous 2006-12-19 08:52:46 UTC
Created attachment 36786 [details]
Usage of new API in org.openide.actions
Comment 7 Jaroslav Tulach 2006-12-19 12:20:38 UTC
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.
Comment 8 rmatous 2006-12-19 12:48:07 UTC
module-auto-deps.xml is also attached - see:
Comment 9 Jesse Glick 2006-12-20 01:11:45 UTC
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.
Comment 10 Vitezslav Stejskal 2006-12-20 02:05:18 UTC
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.
Comment 11 rmatous 2006-12-20 09:07:47 UTC
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.
Comment 12 Miloslav Metelka 2006-12-20 12:30:26 UTC
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);

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.
Comment 13 rmatous 2006-12-21 17:29:16 UTC
Tomorrow is my latest M6 day, no clear agreement => M7 
Comment 14 Marian Mirilovic 2007-03-05 14:49:33 UTC
still not fixed (after M7)
Comment 15 Vitezslav Stejskal 2007-03-05 15:37:49 UTC
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.
Comment 16 David Strupl 2007-03-05 16:07:50 UTC
Hello, thanks for putting me on Cc: of this issue. I will ask my colleagues and
report back here. 
Comment 17 David Strupl 2007-03-07 11:19:23 UTC
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.
Comment 18 David Strupl 2007-03-07 11:19:24 UTC
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.
Comment 19 Vitezslav Stejskal 2007-03-08 22:22:49 UTC
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.
Comment 20 Vitezslav Stejskal 2007-05-13 08:25:34 UTC
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.
Comment 21 Vitezslav Stejskal 2007-05-13 08:26:45 UTC
Created attachment 42347 [details]
Changes in SharedClassObject and ContextSystemOption
Comment 22 rmatous 2007-05-14 15:21:18 UTC
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. 

Comment 23 Vitezslav Stejskal 2007-05-14 22:35:30 UTC
> 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.
Comment 24 Jesse Glick 2007-05-14 23:21:20 UTC
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.
Comment 25 Vitezslav Stejskal 2007-05-15 01:27:17 UTC
#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.
Comment 26 Jesse Glick 2007-05-15 01:48:18 UTC
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?
Comment 27 Vitezslav Stejskal 2007-05-15 02:41:34 UTC
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? 
Comment 28 Vitezslav Stejskal 2007-05-15 02:42:57 UTC
Created attachment 42397 [details]
PrintSettings patch that disables loading its children SystemOptions
Comment 29 rmatous 2007-05-15 09:46:25 UTC
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
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

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!!!
Comment 30 mslama 2007-05-15 15:20:30 UTC
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?
Comment 31 Vitezslav Stejskal 2007-05-15 22:51:17 UTC
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.
Comment 32 mslama 2007-05-17 13:26:07 UTC
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.
Comment 33 mslama 2007-05-17 13:29:29 UTC
Compilation error:
package org.openide.options does not exist
  [repeat]     public static final class Colors extends
org.openide.options.SystemOption {
Comment 34 mslama 2007-05-17 13:36:56 UTC
Created attachment 42500 [details]
Updated patch diff of openide
Comment 35 Jesse Glick 2007-05-17 15:49:23 UTC
It should be possible to create a file NbDocument$ in a deprecated
module. Or create a dummy with a Color nested class, then delete
Comment 36 Jaroslav Tulach 2007-05-21 10:34:05 UTC
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.
Comment 37 mslama 2007-05-22 21:57:20 UTC
Created attachment 42662 [details]
Complete diff with bigger context
Comment 38 mslama 2007-05-22 22:03:56 UTC
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.
Comment 39 Jesse Glick 2007-05-22 22:13:39 UTC
openide/options/src/org/openide/text/NbDocument$ has a typo:

package org.openide.options;
Comment 40 mslama 2007-05-22 22:25:21 UTC
Thanks. Fixed. I do not know why compiler did not fail on this?
Comment 41 Jesse Glick 2007-05-22 22:36:23 UTC
javac will happily compile a source in the wrong location. (It will put the
.class file in the position according to the package statement.)
Comment 42 mslama 2007-05-23 16:52:58 UTC
Created attachment 42703 [details]
Updated complete diff
Comment 43 mslama 2007-05-23 16:55:16 UTC
Last update: Fixed typo in package in NbDocument$Colors. Fixed spec version in
Comment 44 mslama 2007-05-23 18:07:55 UTC
Created attachment 42704 [details]
Commit log
Comment 45 mslama 2007-05-23 18:08:45 UTC
Fixed in main trunk. Commit log is attached as it is big.
Comment 46 Vitezslav Stejskal 2007-05-24 05:10:42 UTC
Created attachment 42719 [details]
Cleanup of print options from editor modules
Comment 47 mslama 2007-05-24 12:02:49 UTC
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
Checking in completion/nbproject/project.xml;
/cvs/cnd/completion/nbproject/project.xml,v  <--  project.xml
new revision: 1.5; previous revision: 1.4
Checking in core/nbproject/project.xml;
/cvs/cnd/core/nbproject/project.xml,v  <--  project.xml
new revision: 1.6; previous revision: 1.5
Checking in gdb/nbproject/project.xml;
/cvs/cnd/gdb/nbproject/project.xml,v  <--  project.xml
new revision: 1.4; previous revision: 1.3
Checking in highlight/nbproject/project.xml;
/cvs/cnd/highlight/nbproject/project.xml,v  <--  project.xml
new revision: 1.6; previous revision: 1.5
Checking in makeproject/nbproject/project.xml;
/cvs/cnd/makeproject/nbproject/project.xml,v  <--  project.xml
new revision: 1.8; previous revision: 1.7
Checking in modelimpl/nbproject/project.xml;
/cvs/cnd/modelimpl/nbproject/project.xml,v  <--  project.xml
new revision: 1.7; previous revision: 1.6
Checking in modelutil/nbproject/project.xml;
/cvs/cnd/modelutil/nbproject/project.xml,v  <--  project.xml
new revision: 1.4; previous revision: 1.3
Checking in qnavigator/nbproject/project.xml;
/cvs/cnd/qnavigator/nbproject/project.xml,v  <--  project.xml
new revision: 1.4; previous revision: 1.3
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
Comment 48 mslama 2007-05-24 12:31:57 UTC
*** Issue 103751 has been marked as a duplicate of this issue. ***