It is a sort of multiple-property editor. Edited value need to be
propagated into several properties (text, mnemonic, mnemonicIndex).

Is is possible?

Created attachment 7317 [details]
Patch for "An&ything"

Created attachment 7318 [details]
Patch for "An&ything"

I'd like you to look at the patches, but not integrate, because maybe
the method 
org.openide.awt.Actions.setMenuText is to be moved into some other
place in order to be redistributable.

Also please verify that you have the most recent
org/openide/awt/Actions.java, because Dafe only recently integrated
the patch for Issue # 26678 into the main trunk.
The older (not patched, release34 tag setMenuText will also work, but
only for English).

Created attachment 7319 [details]
Demo form, benefiting from above patches ;))

Maxym, the idea is interesting, but it cannot be realized this way. We
cannot force people to have to use some "org.openide.awt.Actions" with
the forms suddenly. We try to use standards only (i.e. JDK libraries)
and not to introduce our specific libraries people had to bundle them
with their programs... Trung explained it on nbdev rather clearly.

But we need not throw this away completely... Probably if we generated
the code of Actions.setMenuText as an additional
method in the form and made it configurable in options, then it would
be more usable.

Short Copy of My answer to Trung:

Well, I think this functionality should be triggered, and the default
be "DO NOT USE".
+: developing Netbeans using Netbeans benefits much,
because I18N of IDE will be much faster&easier
+: developers, which create I18Nized applications, benefit much (I'm
one of them).
-: incompatibility with other IDEs

> idea is interesting, but it cannot be realized this way.
I know, that's why I asked just to look at it. I intentionally didn't
bother with triggering to make a code changes smaller and more readable.

> We cannot force people
Of course! 

> But we need not throw this away completely... 
thanks ;)

> Actions.setMenuText as an additional method
OK, if text contains "&", and the option is on, generate.
Sounds good?

e.g.
jLabel1.setText("&File");
Actions.setMenuText(jLabel1,"&File",true); // <--

Not exactly. What I meant was to generate additional method (e.g.
after the standard initComponents) called like 'setButtonText'
containing code similar to what's now in Actions.setMenuText. This
method call would be used then, Actions would not be needed. Question
is if the method itself can be simple enough not to have to much
duplicated code. I would prefer such an independent solution rather
than some special one privileging developing NetBeans in NetBeans...

Tomas, contra's seem to overweight the pro's:

+: no extra binaries/classes needed for end-user application
+: strict standards conformance

"-": a lot of duplicated code that uses reflection (about 160 lines, I
suppose - the method setButtonText - 80 & setLabelText - 80 *),  
e.g. Netbeans has a lot of forms, the project I'm working on too.

"-": at a time Netbeans switches to support 1.4 & 1.5 (like now it
supports 1.3 & 1.4), all these reflections will be of no use, the code
should be cleaned up.

BIG "-": for non-English mnemonic letters the method uses a bundle to
lookup the correspondance between locale&latin mnemonic keys,
e.g. mnemonic is cyrillic 'A', on the keyboard it's English 'F', so in
order for Button to react on Alt+F (which is fired when a user presses
Alt+ cyr. A), we need to set 'F' as mnemonic, and underline cyr.
letter 'A'.
    So this bundle either must be hard-coded (also in every form, that
gives big memory overhead), or redistributed - why then to integrate
the code?, or hand-made by every developer for every package (also
disk overhead)

    This affects a lot of language locales, that have the 1:1
correspondance between local&english alphabets on the keyboard:
Cyrillic (Russian, Ukrainian, ...), Georgian, Greek, may be more. 
I can provide such bundles for Russian & Ukrainian, and even they will
occupy at least 37pairs like \u0424=A. 
And if some Greek user appears, how is he supposed to customize such a
bundle? If it's only one - no problem.

Sorry for a long story ;(
It's a very detailed, though ;)

---------------------------------------------
* JButton, JMenu & JMenuItem are children of AbstractButton
  JLabel is not.
  I wonder why didn't they at SUN JDK created some 
interface HavingMnemonic {
    public setMnemonic(int);
    public setDisplayedMnemonicIndex(int);
}
 and made both AbstractButton & JLabel implement it.
  Maybe it's worth an RFE?
---------------------------------------------

I see. I have not noticed the way how Actions translates the mnemonics
using bundles... So you are right, there's really too many things that
had to be generated for each form, that's not acceptable.

So, do you agree that we create some .jar and if users use such a
feature, they have to redistribute this .jar?

Or you are strongly against redistributing anything, and have another
solution in mind?

I basically agree with generating code using Actions.setMenuText
requiring additional library (openide or whatever) -- if it is
configurable and off by default. I don't like it much, but it seems to
be useful. Some concerns:
- It will be used by NetBeans developers only (need not care 
  about distributing some library) -- this reduces the set
  of effective users.
- Being default off, people don't find this feature (even
  the NetBeans developer) -- not knowing about it, they
  won't use it -- this reduces the user set further.
- Users not dealing with internationalization issues will
  set the mnemonic separately, which is rather simple and
  straightforward. These users probably won't miss the new
  feature, won't look for it at all.
- So aren't we creating something for "all the three users"?

Another thing I don't like is that integrating this to form editor is
just one ungly hack. Why should some properties of some components
have some special code generation hardcoded in form editor which tries
to work generally with components, not depend strictly on some library?

Don't understand me wrong, despite that all, I'm willing to implement
it (probably wait for clarifying where the setMenuText like methods
will be placed - as discussed in issue 26640). I just want to be sure
we are aware of all problems.

> I don't like it much
I thought & thought, and couldn't find any better solution, that cares
about I18N & jdk compatibility.

> It will be used by NetBeans developers only
Not only, I think that developing of I18nized applications will also
benefit much.

> Being default off, people don't find this feature
I think it can be advertised in Help, Tooltip on "text" property, e.g.
when user types "&File" into the text property, show the question,
what does he mean?: & symbol or underlining of F, and proposal to turn
on this feature with explanation that then he needs to redistribute
some .jar stuff.

> even the NetBeans developer
I'll personally file bugs to all module owners in order that they
change the code from using separate text & mnemonic into such one.

> Users not dealing with internationalization issues will
> set the mnemonic separately, which is rather simple and
> straightforward. These users probably won't miss the new
> feature, won't look for it at all.
Some users, coming from IDEs, where &File means use F as mnemonic
(e.g. Delphi, Visual C++, maybe other), will surely mistype "&File",
and will be alerted of such a feature.

> So aren't we creating something for "all the three users"?
Netbeans developers will HAVE TO use this feature, I think.
I18Nized-programs-developers will find it at least useful.
Others may find it handy to set "Save &As" instead of "Save As" to
text, 'A' to menmonic, and displayedMnemonicIndex on Others property
tab to 5.

> integrating this to form editor is just one ugly hack.
What I find ugly is the SWING design to have three different
properties to implement such a small feature as "Save &As"
Any idea where it should belong? I had none :(

> I just want to be sure we are aware of all problems.
Me too.
There're problems you mentioned, but the result should overweight.

I think using tooltip and help is okay (well, tooltip is another hack
:), showing a message would be most noticeable, but it seems to be too
offensive...

> I'll personally file bugs to all module owners in order that 
> they change the code from using separate text & mnemonic
> into such one.

You drive this issue really thoroughly, you are admirable example of
contributor ;) Thanks

> showing a message would be most noticeable, but it seems 
> to be too offensive...
If the user mistypes '&' we anyway should give him a hint that
mnemonics must be set another way.

> You drive this issue really thoroughly, you are admirable 
> example of contributor ;)
I'll try to create another patches during weekend, which will be aware
of Optioning this feature, and showing a hint if user types '&'.

Read on Monday/Tuesday

Just small note:
> If the user mistypes '&' we anyway should give him a hint
> that mnemonics must be set another way.

And if she does not mistype? Imagine the user wants to just have
labels like "Drag & Drop", "Look & Fell", "Rock & Roll" and does not
want to use the feature -- then she will be permanently bothered by
the message... Also, from implementation point of view, there's no
easy way to recognize that the text being set to property comes from
user input and not from an internal operation (like loading a form,
copying a component, etc).

>Drag & Drop", "Look & Fell", "Rock & Roll
The dialog appears only once

> loading a form
isFormLoaded() ;)

> copying a component
under investigation

Created attachment 7358 [details]
proposed patches

The patch looks usable. May I ask you to create a binary patch so
other people (e.g. from UI) could try it easily? I would do it by
myself but I have no time just now... You may look at
http://nbbuild.netbeans.org/patching.html to see how to make a module
patch. Basically, you just pack all class files of changed classes
(also properties files -- generally all  changed files) into a jar
file (of arbitrary name), keeping the package structure inside (same
as form.jar is built) and then place that file in
module/patches/org-netbeans-modules-form directory. Thanks

One more note to the patch: would not be nice if the information
dialog could also enable the feature directly, e.g. by a checkbox (so
the user need not go to options)?

> May I ask you to create a binary patch
OK, no problem

> One more note to the patch: would not be nice if the 
> information dialog could also enable the feature directly, 
Thanks for the idea.

I'll implement both.
Read on Wednesday.

The following attachments are new onces, still they are not worth
integrating, until 26640 is resolved (new names for methods are proposed).

Created attachment 7370 [details]
Form patch

Created attachment 7371 [details]
The benefitting form - 2

Just $0.02 - I think we should be very careful about adding any
functionality to the form editor that is not based on the Swing &
JavaBeans standards. Changes to mnemonic handling are properly the
domain of the JRE. Trying to bypass Swing may make sense *temporarily*
for NB code (until an improved JRE is released) but I don't think we
should be advertising this ability to users of NB who are not NB
developers; or if we do, it should be off by default, clearly marked
as an NB-specific extension, and carefully documented in terms of why
you may not want to use it.

Jesse Glick wrote:

> Issue #27009 is the proper place to discuss whether & how
> Mnemonic.java could be redistributed to users. That
> question should be handled by the form module developers. 
> For example, they can easily package any particular class
> from openide/src/ into a dedicated redistributable JAR 
> file without help from openide developers (simple
> form/build.xml patch I guess).

So, form developers?
What about bundling openide/src/org/openide/awt/Mnemonic & Mnemonic14
into some netbeans/redist/form/ ?

Is this an acceptable solution?

2 Tomas, 
Hi, Sorry to bother, did you@form forget about this issue?

You asked me to create a binary patch, I did it and no response for a
month& a half (since 2002-09-12).
Please, respond!

=======================================================
2 Jesse:

Final proposal: 
1. This functionality is mainly for developing Netbeans using
Netbeans, hence it will be advertised as such to users ("Don't use it
unless you know what you're doing" ;) ).
2. It goes into 4.0
3. Name:
   Class is org.openide.awt.Mnemonic.java (+ *14.java) 
   Methods are:
     public static void setLocalizedLabel(AbstractButton b, String text);
     public static void setLocalizedLabel(JLabel l, String text);
=======================================================
2 Everybody:
If no feedback in 48 hours, I start coding & asking everybody on the
Earth to put my code into CVS, then to change all their code to use mine.

Sincere, Maxym

I think this works (part mihmax just wrote to me).

Yarda, any architectural comments on shipping an org.openide.** class
as an optional user-classpath lib for form editor? I don't see any
particular harm.

The form editor part looks good to me. We may change some 
details after the complete patch is done or integrated. 
Maxym, go ahead...

Created attachment 7784 [details]
The patch for Netbeans3.4: form module & openide (nmb).

Created attachment 7785 [details]
The patch for Netbeans3.4: form module & openide (nmb).

Created attachment 7786 [details]
Source differences (and Mnemonics.java)

OK, I made it. Sorry for the delay.
& Sorry for double-attaching

2 Jesse:
thanks for your suggestion about "Rock & Roll" 
("& " and "'&'" are skipped).

org.openide.awt.Mnemonics should be marked abstract or final, and/or
have a private constructor. Compare e.g. org.openide.util.Utilities.

org.openide.awt.Bundle, not org.openide.awt.bundle.

You want java.specification.version, not java.version, and compareTo
is inadequate (consider JDK 1.10).

I would call ex.printStackTrace() instead of
ErrorManager.getDefault().notify(ex). Swallowing exceptions is evil.

How does this method work for Japanese translations, where generally a
Roman mnemonic is needed? Currently we use e.g.

    \u30d5\u30a1\u30a4\u30eb(&F)

(Menu/File) which produces the mnemonic key 'F' and displays that somehow.

You may want to get rid of Yarda's awful hack of using
java.util.Map.Entry as a communications interface. It will not work on
JDK 1.1, anyway. Suggest a package-private interface inside Mnemonics,
that Mnemonics14 would implement. Or simply use
java.lang.reflect.Method to access the 1.4 method: while our
convention for NB sources is generally to use a *14.java class, in
this case since the code is intended for general consumption, it might
be simpler to just access the method using reflection, and use only
one class.

2 Jesse:
> Mnemonics should be marked abstract or final, and/or
have a private constructor. Compare e.g. org.openide.util.Utilities.

OK, why?

> org.openide.awt.Bundle, not org.openide.awt.bundle.

Sorry, somehow strangely I didn't get any error, but it's a 100% bug.
my fault.

I'd like to use Mnemonics.properties:
- not to mix up the MNEMONIC_\u0424=A with normal Bundle.
- easier "howto customize for you language".

> You want java.specification.version, not java.version, 
Any doc about what all these versions are about? I'm really confused,
but yes, you're right:
for SUNjdk1.4.1 - java.specification.version="1.4",
and java.version="1.4.1".

> and compareTo is inadequate (consider JDK 1.10).
Maybe I should cut&paste some code from
org/openide/modules/Dependency.java (especially ibmHack ;). I don't
like to depend on any of the other opendie files in Mnemonics.java,
because I'd like it to be easily redistributable.
Also I wander of the correctness of this patch at a time when 1.10
comes ;-).

> I would call ex.printStackTrace() instead of
ErrorManager.getDefault().notify(ex). Swallowing exceptions is evil.

Sure. my fault.

> How does this method work for Japanese translations, where generally
a Roman mnemonic is needed? 

it works OK when there's some \xxx\yyy\zzz (&L), but I encountered
another bug: So often advertised (by me) "Save &As" doesn't work ;-(

> You may want to get rid of Yarda's awful hack of using
java.util.Map.Entry as a communications interface. It will not work on
JDK 1.1, anyway. 

OK, I'll try more deep testing of DemoForm o different JDK's. 
I'll use reflection, otherwise Mnemonics14.java will simply not
compile on jdk1.3 (if a user wants to recompile a class himself).

Hear not soon. I'll take more time to test.
Sincerely Maxym.

P.S: Thanks for the comments. It was rather buggy code ;-(

Prefer to make it impossible to instantiate or subclass a static
utility class for which no instances should ever be created.

java.version is an implementation version; format is unspecified.
java.specification.version is the JRE's API revision, so this should
be used when testing for existence of certain public APIs.

I understand doing a proper spec version comparison here is hard -
copying & pasting from Dependency (& SpecificationVersion) is probably
overkill. Just test for "1.1", "1.2", "1.3", "1.[4-9]", "1.??", all
possibly followed by a period and more stuff (I guess).

I agree that a user might want to compile Mnemonics.java for
him/herself, and that user cannot be expected to have our build setup
with the 1.3-then-1.4 passes etc. So using reflection here is probably
more attractive for a user redistributing the class.

OK, I coded a single public final class Mnemonics with private
constructor, but didn't test it on jdk's earlier then 1.3.
On 1.3 & 1.4 works as expected.

I'd like to use another resource bundle: Not "Bundle.properties", but
"Mnemonics.properties". Redistribution will be handier. Any objections?

I am ok with the class API, just prevent the instantiation of the
class - private constructor. I suggest to replace:

            setText(item, getText(item)+" ("+latinChar+")");

with MessageFormat with two arguments { item, new Character (latinChar
) } to give this final look into hands of localizator. Use of own
Mnemonics.properties is fine for me.

If you want to run on jdk1.1 I suggest to use
java.util.Hashtable.get/set for communication with the Mnemonic14 ;-)
Jesse does not like hacks but I think they are fine if they are used
localy.

Agreed re. Mnemonics.properties and MessageFormat, both good points.

Re. Hashtable - such tricks should not be necessary if reflection is
used to call the 1.4-specific methods, since then there is no separate
Mnemonics14 anyway.

RE: I'll use MessageFormat, but it's another day of delay.

Test results:
- I couldn't get it working on JDK1.0.2, but I tried ;-)
  Swing's missing there ;-)
- I could get it morking on SUN's JDK1.1.8 and MSJVM, but the separate
swing.jar for JDK1.1 uses other packages: com.sun.java.swing vs.
javax.swing. 
I suggest an instruction on how to use under JDK1.1: 
take Mnemonics.java, replace all occurences of "javax.swing" with
"com.sun.java.swing". That's all.

- SUN's JDK 1.2.2, JDK 1.3.0, JDK 1.3.1 all work OK, and append "
(_L)" for localized text or simply display "S_ave As".

- SUN's JDK 1.4 & 1.4.1 work OK and underline the appropriate symbol.

The final release of Swing for 1.1 (JFC 1.1.1) shipped with
javax.swing package names, so don't worry about this. Anyway it is now
officially "end-of-lined" by Sun:

http://java.sun.com/products/jfc/download.archive.html

Yeah, I used swing1.0.8, now I see that there's no need.

Created attachment 7799 [details]
Mnemonics.java & Mnemonics.properties

new:
- Using MessageFormat
- Catching all the weird exceptions and printing stack traces.

refreshed:
- Working on Sun's JVMs 1.1 (+swing 1.1.1), 1.2, 1.3, 1.4 and MSJVM
5.00.3802 (+swing 1.1.1).

I think it's worth integrating.

Looking good. Remaining quibbles with the exception handling:

Never call System.exit from a library method, that is extremely evil.
Print the stack trace, then assume something is wrong, set
isJDK14OrLaterCache to false, retry.

Also catching Exception in the second block (JDK 1.3) serves no
obvious purpose, so remove it.

Not sure if printing the stack trace for the MissingResourceException
in getLatinKeyboardChar is appropriate - it would be expected to have
this MRE thrown for unknown characters, right? So it is not a real
error -> ignore it.

> Never call System.exit from a library method, that is extremely evil.

Sorry, I removed some, but obviously not all.

> Print the stack trace, then assume something is wrong, set
isJDK14OrLaterCache to false, retry.

did it, thanks for the suggestion.

> Also catching Exception in the second block (JDK 1.3) serves no
obvious purpose, so remove it.

No way. What if the bundle or "FORMAT_MNEMONICS" key is missing?

> Not sure if printing the stack trace for the
MissingResourceException in getLatinKeyboardChar is appropriate - it
would be expected to have this MRE thrown for unknown characters,
right? So it is not a real
error -> ignore it.

It IS an error if I set, e.g. "&X-locale", but don't give a
correspondance X->Latin.

Created attachment 7805 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7806 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7807 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7808 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7809 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7810 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7811 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7812 [details]
Improved Mnemonics.java & Mnemonics.properties

Created attachment 7813 [details]
Improved Mnemonics.java & Mnemonics.properties

sorry for so many attachments, something went seriously wrong.
I'm awfully sorry

"What if the bundle or "FORMAT_MNEMONICS" key is missing?" - then the
JAR is corrupted and passing up a runtime exception is appropriate,
just as if any other part of the JAR were suddenly deleted or mangled.
Code should generally not catch exceptions which it knows statically
should never happen (IMHO).

"It IS an error if I set, e.g. "&X-locale", but don't give a
correspondance X->Latin." - OK, fine then - I just wasn't sure if this
was really supposed to be an error, or whether this would be a
"normal" case.

Jesse, you convinced me, see mnemonics3.zip

Created attachment 7823 [details]
Mnemonics Version 3

Thanks, looks good.

BTW is "int.class" actually valid syntax? I thought you had to use
Integer.TYPE. Not important.

Jesse, will you put this file into trunk?
Is it enough stable to your opinion?

I may provide a patch for org.openide.awt.Actions.setMenuText to use
Mnemonics and deprecate this method (should it be deprecated, BTW?),
and also find occurences of setMnemonics all around the NetBeans code
and file issues against the modules, providing the patches against trunk.

Looks fine IMO. (I guess you checked suggestions in #29676 and applied
them? Looks that way. In which case that issue should be marked a
duplicate of this one.) Minor thing:

- getBundle need not do any caching; ResourceBundle does its own
caching already

I agree that Actions.setMenuText should be deprecated and delegate to
this class, which should be easy.

Please file a PATCH for me in openide (subcomponent AWT/Swing I think)
to add Mnemonics.{java,properties}, patch Actions.java, and do the
other stuff related to an API change (spec version stuff, listing the
change, etc.). Make that PATCH block this issue. If module code should
be using

JLabel l = new JLabel();
Mnemonics.setLocalizedText(l, "&Hello");

where currently it does

JLabel l = new JLabel("Hello");

then the Upgrade Guide also needs an entry for this.

Actually #26640 is probably the best place to do all this - it is
already open after all. Just reassign to me, attach final versions of
stuff.

#26640 would then be the API change, not this issue.

I'm trying to order these two issues: 26640 and 27009.

This issue will be the change in form module to use RFE from #26640 to
enable usage of that API in NetBeans developing NetBeans, this
functionality will be off by default, and not recommended for other
than NetBeans programs.
(however, I'll use it in my own, if you don't mind).

Issue 26640 should be openide Enchancement.

Jesse wrote:
============= CUT ============
3. (Most important) When you have a diff like this:
- 
versionLabel.setText(java.util.ResourceBundle.getBundle
("org/netbeans/modules/apisupport/lite/Bundle").getString
("LBL_Version"));
+ 
org.openide.awt.Mnemonics.setLocalizedText
(versionLabel,java.util.ResourceBundle.getBundle
("org/netbeans/modules/apisupport/lite/Bundle").getString
("LBL_Version"));

Fine, but what happens the next time a developer opens 
this form in the Form Editor? This change is immediately 
reverted with no warning, since the .form file still says 
this:

        <Property name="text" type="java.lang.String"
editor="org.netbeans.modules.i18n.form.FormI18nStringEditor
">
          <ResourceString
bundle="org/netbeans/modules/apisupport/lite/Bundle.propert
ies"
key="LBL_Version"
replaceFormat="java.util.ResourceBundle.getBundle(&quot;
{bundleNameSlashes}&quot;).getString(&quot;{key}&quot;)"/>
        </Property>

You need to change both the .java and .form in parallel.
============= CUT ============

So, Tomas, how can we change .form file in order that it's 
clear to NetBeans that it should use 
org.openide.awt.Mnemonics.setText(label, "text") and not 
label.setText("text");

??

Ah, I think I understand - the form editor now has an option to use
Mnemonics.setLabel to set the bean property JLabel.text etc., yet it
does not actually persist this choice in the .form file. If true, this
is a high-priority bug (potential loss of work after reopening a form)
which would make the form editor support for this method unusable.

In fact, there is no way to store (in the .form file) the option how
to generate setText code. It can be just a global option. This is a
design flaw of all global code generation options. But it causes no
real loss of work... Well, in this case it is arguable, but the
mnemonic support has not been integrated yet.

"In fact, there is no way to store (in the .form file) the option how
to generate setText code. It can be just a global option." - IMHO the
global option should be a *default* but for a particular label the
.form file should specify whether it was used or not.

And I think it can cause loss of work - unintentional reversions of
behavior - if a developer with the option turned off opens up a form
created by someone with the option turned on. (The reverse could be
annoying too, but at least it would be caught easily when
org.openide.awt.Mnemonics is not found in the compiler classpath!)

Ppl, I think I've got an idea:
Form editor supports individual Post-Init code for every component,
maybe we can put there this API call.

PERF people may interrupt:
Calling BOTH

lbl.setText(bundle.getString("LAB_TTT"));
Mnemonics.setLocalizedText(lbl,bundle.getString("LAB_TTT"));

But I see no other solution with current Form Editor design.

Created attachment 9183 [details]
Patch project

The above "Patch project" is what I think may be done.
I recognize that the patch is completely wrong:
 - GandalfPersistanceManager.java is a wrong place for 
this for sure, maybe this code should be incorporated in 
RADProperty.java
 - There's a lot to be done

But still it gives (to me) the possibility to insert this 
API call somewhere and get it serialized between sessions 
even in backward-compatible way, so that this Mnemonics 
call will not be removed by accident.

Please, take a look.

P.S. Do you feel it should go to 3.5? I do, that's why I 
adjusted Target Milestone. If you object, revert it back 
to TBD, however I feel strong to force this thing.

"In fact, there is no way to store (in the .form file) the option how
to generate setText code. It can be just a global option."

There's really none.

But there're ways how to specify that we need to generate _Additional_
code:
- "Post-init" code of a component. It may be edited by user, hence the
second option is better.
- "PostCode" of a property. It's not user-editable, however I'm not
sure, is it auto-edited by Form Editor or not. I filed issue 31520 to
clarify, where is this method used, and why.

Is an approach to generate additional API call generally accepted?
Should we CC some PERF people to look at the thing?

Not to get lost in this, I suggest to make a summary.
Seems there are two problems:
1) how to implement the mnemonics support in the form editor,
2) how to get it to NB 3.5 (is it even possible?),
3) and if 2) is not possible, then how to tell people to use the
Mnemonics.setLocalizedText in forms without any form editor support.

As for 1), Maxym - I appreciate your activity and effort to find a
solution, but it's really non-trivial to understand some parts of form
editor code ;). Let's rather agree on what exactly are the
requirements, then I can implement them.

So here we go:

a) Provide a way the developers could set text and mnemonic  of
buttons and labels in form editor just by passing one string
containing '&' character, getting Mnemonics.setLocalizedText generated
properly (as described in issue 26640).

b) This form editor's feature must be off by default, it is intended
as an aid for NetBeans developers. So there must be a global option
for turning the feature on/off.

c) Once the global option is on, nothing should change immediately,
just all new text properties entered should generate the Mnemonics
code. If the option is  set off, again nothing should change, just the
new new text properties won't be set to use Mnemonics code.

d) The way how concrete properties uses this feature (i.e. what code
it generates) should be preserved (persisted). So there needs to be a
per-component option (not per-property as components have just one
text property). The global option would just determine initial setting
of the component option when the component is created, but then the
global option would have no effect on it. On the component level, the
option would be freely setable as a "Code Generation" property. It
would have three values:
  (i) not set at all - then can be set to (iii)
      automatically if the global option is turned on,
  (ii) turned off explicitly,
  (iii) turned on explicitly.

e) To avoid loss of Mnemonics code if the form is opened in older
version of NetBeans (would be regenerated to ordinary setText code),
the form spec version should be rised if there is some property with
Mnemonics turned on. Such a form could not be opened in previous
versions of NetBeans.

Is this correct? Did I forget something? This way it can be implemented...



Now let's look at 2: How to get it to NB 3.5. Is it even possible?
Well, I doubt so. I have strange feeling I argued the same way not to
putting this to 3.4.1, but this is a pretty new feature, includes also
some UI changes. And the feature freeze was at the end of January, we
are going to enter high-resistance mode soon... I've looked at this
month ago, but issue 26640 was not resolved yet and the target
milestone was set to 4.0, so I thought this was not to be done for
3.5. I agree it would be nice to have this already in, but I would
have to do it pretty secretly, not telling anyone ;-). On the other
hand, it would not have so big effect now - the developers would not
rewrite their dialogs now to use the feature (and so to help with
localization of NetBeans)...


As for 3), I'm still thinking about it, will answer on nbdev.

Created attachment 9195 [details]
Patch with /* */ (idea by Tor Norby)

Not very nice hack:
- produces ugly code,
- does not test if the component is really button or label,
- does not take into account if the user wants something
  like this (i.e. you should test some option),
- gets broken if you rename the component,
- etc.

This can be done better by adding an aux-value property as I wrote
above. And you still could not avoid a UI change - you would have to
create the global option, or maybe also some message dialog. Maxym,
please stop creating patches and read what I've written above...

Summary - Answered  (I read it)
My ideas below ****************

short:
- Not going to 3.5, we need an extra time to think about 
and test it (think as you convinced me).
- Support for this in 3.5 will be voluntary and absolutely 
manual, no automatic support.

requirements:
a) - YES, perfect description
b) - YES, global option possibly with Dialog to warn when 
turning ON.
c) - ADDON - There should be a method to upgrade/downgrade 
a whole form to use/don't use this API.
d) - AGREED
e) - INCOMPATIBILITY with earlier NetBeans versions is 
generally a bad thing, because it will force NetBeans 
developers to use some certain version of NetBeans to 
develop NetBeans itself. However maybe it's the only 
possible solution.
*************
As for the patch, it's so simple because I din't want to 
introduce any complexity. I recognize it's more of a hack, 
not a real solution, but I just wanted to archive Tor's 
proposal somewhere in this issue.
*************
Tomas, do you have any incompatible changes in mind for 
4.0 as well as this one?
I may propose one: Allow to override _all_ init code for a 
certain property, not only adding Pre & Post code. It's 
actually Tor's proposal, he is for his reasons unsatisfied 
that he may only partially edit a code, 
e.g. setText( <insert here> );
And not the full line.
Then this RFE would be a narrow case of that one.

Sounds? Or you feel this RFE should be implemented 
completely separately. I propose to brainstorm this RFE's 
implementation.

ad c) ADDON - would be useful, but not critical - if you change the
generation method (i.e. whether using Mnemonics or not), you should go
through all components manually anyway - to either include '&', or to
remove it and set the mnemonic property. So when you touch each
component, you can set its Code Generation property accordingly. Or,
you can select all the components in inspector and set the property at
once.

I simply don't like to put another hack in ;) - action doing something
over the form, there's currently nothing like that. But let's solve
this later.


as for e) - INCOMPATIBILITY with earlier NetBeans versions, I think
it's okay - if you add a feature that the old version is not able to
handle, it is acceptable you cannot open the form in it. Note this
does not break backward compatibility - you always open older forms in
newer version, but can't expect vice versa. Moreover, this will be
used mostly with NetBeans developers, who usually work with newest builds.

The other solution would be not to rise the version, the risk that
someone opens the form in older NetBeans and gets bad code generated
is also small - for the same reason above.



As for possibility to override whole init code for a property, it is
technically doable (relatively easily). I have some minor objections
in my mind, but please file a separate issue, it is not so related to
this issue as you might think. Thanks.

ADDON would be _extremely_ useful to change a bunch of 
forms, because manually going through all the components 
is, hm..., not very developer-friendly ;-)

> you should go through all components manually anyway
> - to either include '&', or to remove it and set the
> mnemonic property. 

Even not necessarily so:
- if the value of a text is read from a bundle, I may edit 
the bundle itself, and don't touch the form editor to 
change value of text property.
- I saw tons of code that manually assigns setMnemonic 
from bundle (i18n limitation of not i18n-zing only strings)

So, there's a possibility to change value of "text" 
property even not opening Form Designer ;-(

Is this something that needs to be noted in the 3.5 
readme? It seems to me that it is less of a "known 
problem" and more of an incomplete implementation (the 
readme would probably be 100 pages if we included those :-
) ). Seriously, if whoever marked this as RELNOTE could 
suggest some text, I'll consider it for the readme or 
(more likely) an FAQ.

I also think this is rather for FAQ right now - until we implement
direct support in form editor. What Maxym meant was probably that:

To set localized text of labels and buttons with mnemonics in the Form
Editor using the new Mnemonics API, you need to add the appropriate
code in post-initialization code of 'text' property. Normally, you
would just set the text using the Resource Bundle editor and got:

lbl.setText(bundle.getString("LAB_TTT"));

This is not enough (mnemonics not set). You need additionally set the
post init code also to:
Mnemonics.setLocalizedText(lbl,bundle.getString("LAB_TTT"));

Having both lines of generated produces partially duplicated code. So
the other possibility is not to set the texts in form editor at all
and write everything by hand e.g. in the constructor.

Agreed on RELNOTE removal, as this is targeted at 4.0

This RFE is not implemented, there never've been such possibilities in
NB before, so it shouldn't be a relnote. When we're done with it, it
must go to "What's New?", but no earlier.

Status?
Any ideas when it gets "STARTED" ?

Tomas et al,

As I can see, this RFE is not in form module plans.
I wander why?

Actually I'd be glad to implement it, but:
> I appreciate your activity and effort to find a solution,
> but it's really non-trivial to understand some parts of
> form editor code ;). Let's rather agree on what exactly 
> are the requirements, then I can implement them.

I suppose we've agreed on requirements, when will _you_ implement it.
I mean dates. (if you don't want me to touch the code, do it yourself,
no problems, but set a date on it).

Maxym, the current plan has just one big item: integrate with the
projects. All other features have much lower priority so are not even
planned yet.

But: this thing is not so big and I would really like to have it done.
But doing it on prj40_prototype branch doesn't make much sense and is
even not possible until the basic integration of form editor as
described in issue 27180 is done. Anyway the projects build won't be
usable for real development still for some time then. Probably it
could be implemented in trunk and merged to projects later...

If this is urgent for you, will you give me say three weeks to either
start with this or at least sketch out the design I would like? I
should find some time for it. If not, then you can start working on it
in trunk, I promise ;).

OK, you have one month ;-)

I'll ping you short in advance before the dead line and if you still
have no time, discuss what "cool hack" is more appropriate on nbdev.

So I did first attempt to implement this. I modified several files and
created issue_27009 branch for it.

/cvs/form/src/org/netbeans/modules/form/Bundle.properties
new revision: 1.141.44.1; previous revision: 1.141
/cvs/form/src/org/netbeans/modules/form/FormLoaderSettings.java
new revision: 1.51.44.1; previous revision: 1.51
/cvs/form/src/org/netbeans/modules/form/FormLoaderSettingsBeanInfo.java
new revision: 1.53.44.1; previous revision: 1.53
/cvs/form/src/org/netbeans/modules/form/JavaCodeGenerator.java
new revision: 1.127.18.1; previous revision: 1.127
/cvs/form/src/org/netbeans/modules/form/VisualReplicator.java
new revision: 1.35.44.1; previous revision: 1.35

I've implemented what we agreed on - a global option and a
per-component synthetic property, code generation, storage, and also
support for designer. Still the dialog informing about the feature is
not implemented, but everything is prepared for it (search
JavaCodeGenerator for "show Mnemonics info dialog here"). Also
converting whole form at once is not implemented, I have no idea how
to do it yet.

Maxym - could you look at this? Comments? Any willingness to continue
working on this?

For commit log, see
http://form.netbeans.org/servlets/ReadMsg?msgId=551399&listName=cvs

Tomas,  sorry for a late answer, I was on a vacation

Now I have a lot of work to do at work, so I'll try to take a look
during next week.

> I ... created issue_27009 branch for it.
I beleive it's only in form module, and other modules should be build
from trunk.

> Also converting whole form at once is not implemented, 
> I have no idea how to do it yet.

Add action for top component (if the feature is on), then recursively
going through all the components and setting this synthetic property on.

> Any willingness to continue working on this?

A lot ;-), what can I do except for reviewing (write docs/test/code)?

P.S. status -> STARTED

Tomas, it works,
I plan to write a short doc on this, OK?

Created attachment 11193 [details]
Proposed Specification

In short, this spec differs from your code in one thing:

The synthetic property, whether to use Mnemonics calls or not, belongs
to top-level continer (usually JFrame), and not to each individual
button/label.

The benefit is that single property per form is, imho, easier to
change and see, if it's set or not.

Well, the problem is that in this case, the property should be on the
whole form level (on the root node) - the JFrame is not the root,
there are also the "Other Components" (out of the JFrame's hierarchy).
The ability to have such synthetic properties for the whole form is
missing... But would it be sufficient to have only per form
granuality, not per component? I admit it would solve the problem of
changing all mnemonics in the form at once without the need to have
special functionality for it...

> A lot ;-), what can I do except for reviewing (write
> docs/test/code)?

It's quite a lot of work too. Your spec is quite nice. But you might
also consider implementing:
> Still the dialog informing about the feature is
> not implemented, but everything is prepared for it (search
> JavaCodeGenerator for "show Mnemonics info dialog here").

We should maybe let some UI guys look at it it too...

Tomas,
several alternative solutions re. property placement:

1. while browsing the code I remember that JFrame/other top-container
is treated rather specially, so even if it's not a root, it's highly
visible and switching some synth. property for JFrame can be easily
propagated to all it's children. What about other components: what
kind are they, maybe such components don't need mnemonic support at
all (Timer/etc).

2. if I understood you correctly you propose that the property will
still reside in every JLabel/JMenuItem/JButton but changing it for one
component will change for all other.  Very strange behaviour, I'd say.

I've tried to solve the problem by itroducing the mnemonics property
also on the top container as you suggested (though I don't like it
much) - the components in the form default to this property if they
don't have their own property set. So you can change mnemonics
generation for whole form at once. Please try and let me know if this
works for you now (I've updated the issue_27009 branch; branched also
RADVisualFormContainer and GandalfPersistenceManager).

> 2. if I understood you correctly you propose that the
> property will still reside in every 
> JLabel/JMenuItem/JButton but changing it for one
> component will change for all other.  Very strange
> behaviour, I'd say.

Probably misunderstanding, I did not suggest this. As I wrote above,
each component has mnemonics property, but only as its own setting. If
it is not set, top container is asked for value. If the top container
has it not set either, then value is "false". If the mnemonics support
is turned on in global Options, then each new created component's
mnemonics is set to true (once setting its text first time; not needed
if the form's top container mnemonics was already set to true). 

The current solution seems perfect to me (besides the need for a
dialogue and a help topic), I'll rewrite a spec

Created attachment 11262 [details]
Proposed spec 2

Great.

Just
  "The mnemonics support can also be turned on in global
  options, then each new created form's "Generate mnemonics"
  is set to true. "

is not quite right - it is set to each component individually right
now. It works, but would be nice to do it on the form level - should
do it when the form is instantiated from template.

Integrated to trunk.

Tomas, 10x a lot, but what is actually integrated and why didn't you
close the issue?

I've integrated the state from the branch plus added the missing
dialog. Probably I should still apply my last comment about newly
created forms - they should take over the global property if set on.
But basically this is done. I would be glad if you tested the current
dev build.

We should also let know the doc writers know before closing this
issue. Patrick, could you look at the attachment "Proposed spec 2
(text/html)" and say if this can go to the help docs? Thanks.

I'll look at it. It probably won't get prominent mention in the docs,
but I'll try to find a place for it.

I just looked at the feature in 200401131900. According the spec (and
my opinion), the option should be off. But in the build, the option is
on by default. This should change as I imagine the majority of users
are not building apps just to run in NB. :-)

The text in the dialog was very helpful. However, I would offer this
version to be a little bit clearer.

"You can define mnemonics of labels and buttons by using the '&'
character inside the text property instead of setting the text and
mnemonics properties separately. This allows precise mnemonics
definition and easy internationalization. However, this feature
requires the org.openide.awt.Mnemonics class, so you should turn it on
only if you develop forms to be run within NetBeans IDE. 

Use org.openide.awt.Mnemonics for mnemonics definition.
Don't show this dialog again.

You can later turn this option on or off. Choose Tools | Options.
Expand the Editing node, and select Form Editor Settings. Then change
the Generate Mnemonics Code property."

Patrick - thanks very much for correcting the text in the dialog. I've
just committed it.

> I just looked at the feature in 200401131900. According the spec
> (and my opinion), the option should be off. But in the build, the
> option is on by default.

Hm, I tried the same build and it was certainly off by default. I hope
QA will check this for sure.


So now I hope this can be closed as fixed.

*** Issue 84531 has been marked as a duplicate of this issue. ***

Integrated into 'main-golden', will be available in build *200909010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/39f936c230c0
User: Martin Krauskopf <mkrauskopf@netbeans.org>
Log: ruby-debug-ide-0.4.8 released:

- fixed bug #27009
- rename to ruby-debug-ide.rb
  - to not collide with lib/ruby-debug.rb from ruby-debug-cli