Bug 125600

Comment 1 Susan McCourt 2006-01-27 21:26:24 EST

At a minimum, investigate this for API repercussions in M5.  If possible, implement it.

Comment 2 Susan McCourt 2006-01-31 19:14:08 EST

This bug includes a request for clients to specify the initial size (which is necessary anyway in order to restore bounds).  What I intend to do is allow the shell size and resizability to be specified by clients.  The functionality to restore a remembered size should be a level above - probably in the workbench-level content assist field.

Comment 3 Susan McCourt 2006-02-02 01:10:20 EST

In the middle of implementing this.  The plan is to:
- add API in ContentProposalAdapter to allow clients to set the initial popup size and specify resizability.  This will either be done through setter API, constructor parameters (the constructor is already cumbersome), or providing direct access to the popup or its shell.
- ContentAssistField will use the API to set up resizability and record the size.
- The placement of the secondary dialog needs to be improved to be more like the current platform text content assist.  Using the shell constraining can cause it to appear on top of the first popup.  This will also be addressed.

Comment 4 Dani Megert 2006-02-03 02:51:33 EST

>The default is currently to the size of the field.  I don't mind a change in
>this value, but am looking for suggestions...Any comments can be made in bug
>#125600.
We could add initial size style bits:
- DEFAULT: fixed size, same value as the Platform Text content assist has
- AUTOMATIC or FIELD: size is computed from the field size
- NONE or CUSTOM: client provides initial size

But that even better than style bits would be a Point constant for AUTOMATIC and use 'null' to denote the default. With this, a single setInitialSize(Point) would do the trick and since the default would be the Platform Text content assist size client could migrate without bothering to call setInitialSize. Maybe we can even drop 'AUTOMATIC'?

Comment 5 Susan McCourt 2006-02-04 21:03:03 EST

Fixed >20060204.
I wanted to keep the API as simple as possible, so what I've provided is the following new API:
- ContentProposalAdapter.setPopupSize(Point)
sets the size for the popup (but doesn't change it if it's currently open).  typically used to set initial size.
- ContentProposalAdapter.getPopupSize()
returns a point indicating the last used size of the popup, or null if the popup never had a size and was never opened.

If the size is never specified (or set to null), it will be sized to a width that is the max of the target control's size and an internal width hint (same as platform text's internal width).  This way, someone implementing a type-ahead content assist on a wide field (such as the URL addres field in internet explorer) will get the field width, but a dialog with a small field (like find/replace) will get a nice minimum.  I think this gives you what you want in most cases without getting too complicated.

I also made the shell resizable all of the time, rather than make it an API setting.  Other improvements:
- the secondary popup will move accordingly as the shell is resized (unlike the platform text solution)
- the secondary popup will also adjust its initial location for display and monitor bounds, choosing a location on the left or right, depending on which gives the best width. 

By default, the size is retained as long as the adapter is installed.  If you want to persist the size between invocations of a dialog, it's up to the client to query the size and store it.  I don't think it makes sense for the ContentAssistField to do this since it will need the client's dialog settings for storing the size.  Since the client has to set up the dialog settings anyway, it would seem just as reasonable for the client to get its own settings and get/set the popup size accordingly as the dialog opens and closes.

Please reopen this bug if you think I should provide more on the API-side.  I'll post an updated find/replace to bug #120237 if you want to try everything out, but realize that there are still some bugs.

Comment 6 Dani Megert 2006-02-06 06:37:12 EST

Sounds reasonable and the code looks OK as well but I can currently not verify the new patch because JFace depends on changes in lower layers and I hence used the newest stuff from there as well i.e. applied the patch on N20060206-0010 but there Ctrl+Space invokes the editor's code assist (see bug 126044, comment 16).

Comment 7 Susan McCourt 2006-02-06 14:34:33 EST

I ran into the code assist binding problem yesterday when testing cell editors but thought it was my own problem.  I will follow the progress of the keybinding bugs and for now assume that this particular feature is okay.

Comment 8 Dani Megert 2006-02-07 05:30:54 EST

Verified with N20060207-0010 plus patch in bug 120237.

Comment 9 Susan McCourt 2006-03-02 18:10:43 EST

To fix bug #126138, I had to change the style bits of the content assist popup shell to use SWT.ON_TOP in addition to SWT.RESIZE.  

Using SWT.ON_TOP in conjunction with SWT.RESIZE will remove the resize behavior of the popup shell on Linux/GTK.  On Windows and the Mac, it remains.  Using SWT.ON_TOP is critical to getting the focus to remain on the target control.

I verified with the existing platform text find/replace code that resize is present on windows and the Mac, but not GTK, so I believe this to be a reasonable limitation.