Autocompletion on Windows 10

[Neil Hodgson]

Windows 10 displays the autocompletion list differently to Windows 7: the wide sizing border has disappeared but there is a 6-pixel high white top border:
http://www.scintilla.org/ACBorder.png

From online discussions, this top border is quite difficult to remove properly. Its a remnant sizing border which still exist on all 4 sides of resizable windows on Windows 10. Windows hides the left, bottom and right borders by removing them from the area that the display compositor shows. Some people have used compositor calls (Dwm*) to remove the top border but this appears to have its own problems.

The resizable attribute can be turned off which fixes this problem but resizing has been popular.

The default autocompletion height is 5 items which made more sense when screens were tiny. I’d like to increase this. Visual Studio uses 9 items and this looks like a reasonable number.

On Windows 7 and earlier, the focus rectangle was a single pixel wide and subtle. On Windows 10, it is 2 pixels wide and quite ugly. The focus rectangle is more valuable in dialog boxes where there are multiple lists and it is harder to see which has focus or where multiple selections can be made. Visual Studio does not display a focus rectangle in its autocompletion so I think it should be dropped.

The colours could also be improved, possibly to be more like a menu with a light grey background and a lighter blue highlight. I tried some different colours but was unable to find a scheme that I liked more than the current one.

Neil

[Mike Lischke]

  The default autocompletion height is 5 items which made more sense when screens were tiny. I’d like to increase this. Visual Studio uses 9 items and this looks like a reasonable number.

+1

  On Windows 7 and earlier, the focus rectangle was a single pixel wide and subtle. On Windows 10, it is 2 pixels wide and quite ugly. The focus rectangle is more valuable in dialog boxes where there are multiple lists and it is harder to see which has focus or where multiple selections can be made. Visual Studio does not display a focus rectangle in its autocompletion so I think it should be dropped.

+1

 The colours could also be improved, possibly to be more like a menu with a light grey background and a lighter blue highlight. I tried some different colours but was unable to find a scheme that I liked more than the current one.

There are also problems on macOS. Since a few Scintilla versions the width is no longer computed correctly. There are 2-3 pixels missing causing the longest entry to be shorted:

 

Regarding layout/colors/drawing: I'd like to see an API in Scintilla that allows the application to draw the auto completion entries. I often could use more text in the box than what I would complete then. Here's an example what I consider a very good list:

https://coderunnerapp.com/images/Screenshot_4_small.jpg

(XCode uses a very similar layout, but without the context help). Such an API could be a notification carrying a pointer to a native drawing surface (HDC on Windows, CGContextRef on Cocoa, cairo_t on GTK) and a rectangle where to draw to. This would also allow me to draw png images instead of converting everything to raw RGB or xpm.

Mike
-- 
www.soft-gems.net

Mike
-- 
www.soft-gems.net

[Neil Hodgson]

Mike Lischke:

> There are also problems on macOS. Since a few Scintilla versions the width is no longer computed correctly. There are 2-3 pixels missing causing the longest entry to be shorted:
>

> <cc1.png> <cc2.png>

There is already an average character width (commonly around 7 pixels) worth of extra space added which is visible as unused space on the right. Whether the text is truncated depends on the text and font - zoom the view in or out and the problem may not appear. The measurement of the width of the strings appears reasonable but there may be additional details that should be taken into account - perhaps there is an API to ask for the text column’s preferred width for a string. I suppose an extra 3 pixels can be arbitrarily added but that may still break in untried cases.

> Regarding layout/colors/drawing: I'd like to see an API in Scintilla that allows the application to draw the auto completion entries.

On Cocoa, Scintilla doesn’t even draw the entries: Cocoa does the drawing with Scintilla telling it what the text or icon is for each cell.

The autocompletion list implementation differs greatly between platforms. Perhaps adding platform-specific APIs would be simpler than trying to abstract over all the platforms.

> (XCode uses a very similar layout, but without the context help). Such an API could be a notification carrying a pointer to a native drawing surface (HDC on Windows, CGContextRef on Cocoa, cairo_t on GTK) and a rectangle where to draw to.

This isn’t how list boxes work on Cocoa, GTK+, or Qt. On Cocoa, you implement a NSTableViewDataSource-compliant object that feeds data into an NSTableView and then the NSTableView (or its sub-objects) does the drawing. Custom drawing could be implemented by subclassing NSCell but that looks like much work. The coderunner example appears to be using 3 list columns with attributed text for the rightmost column as it displays both bold and plain.

GTK+ is similar and Qt uses a simplified API that handles the common icon+text case. Its only on Windows that Scintilla draws autocompletion entries.

Neil

[Mike Lischke]

> There is already an average character width (commonly around 7 pixels) worth of extra space added which is visible as unused space on the right. Whether the text is truncated depends on the text and font - zoom the view in or out and the problem may not appear. The measurement of the width of the strings appears reasonable but there may be additional details that should be taken into account - perhaps there is an API to ask for the text column’s preferred width for a string. I suppose an extra 3 pixels can be arbitrarily added but that may still break in untried cases.

I don't think that randomly adding more space on the right side is a good solution. Measuring a text's width is a standard task today and there shouldn't be any guess work necessary. Maybe it's the fact that my image in the list have a non square form which causes the mis-computation? I remember older versions of my app where I used squared images and never saw this problem.

>
>> Regarding layout/colors/drawing: I'd like to see an API in Scintilla that allows the application to draw the auto completion entries.
>
> On Cocoa, Scintilla doesn’t even draw the entries: Cocoa does the drawing with Scintilla telling it what the text or icon is for each cell.
>
> The autocompletion list implementation differs greatly between platforms. Perhaps adding platform-specific APIs would be simpler than trying to abstract over all the platforms.

True, it might be difficult to make all platforms send paint notifications, but here we are talking about an idea: how to customize the auto completion list. I can also imagine that scintilla uses an application provided drop down (similar to menus) and only takes care for positioning/open/close/completion. Then it wouldn't matter much how the built-in drop looks like.

Mike
--
www.soft-gems.net

[Neil Hodgson]

Mike Lischke:

> I don't think that randomly adding more space on the right side is a good solution. Measuring a text's width is a standard task today and there shouldn't be any guess work necessary.

Currently, Core Text is used through calling CTLineGetTypographicBounds. Its possible that CTLineGetImageBounds would be better but that requires a graphics context. I tried using a completely different API, NSAttributedString size, but that gives the same result.

> Maybe it's the fact that my image in the list have a non square form which causes the mis-computation? I remember older versions of my app where I used squared images and never saw this problem.

This can occur without any image.

> True, it might be difficult to make all platforms send paint notifications, but here we are talking about an idea: how to customize the auto completion list. I can also imagine that scintilla uses an application provided drop down (similar to menus) and only takes care for positioning/open/close/completion. Then it wouldn't matter much how the built-in drop looks like.

An application-implemented window would allow for more flexibility with a Scintilla-defined protocol for sharing input events, positioning, and life-cycle. I have done some experiments but not found a good solution. Its likely that something worthwhile could be done here if someone put enough work into it.

Neil

[Neil Hodgson]

The Win32 changes to remove the focus rectangle and increase the default number of items were committed:
https://sourceforge.net/p/scintilla/code/ci/d93769d7e7571dc8e839d7c8cb0515e47b31b7e6/

For Cocoa, the autocompletion list is now 4 pixels wider. While this is a hack, is better than truncated text and can be fixed if anyone works out how to calculate widths accurately.
https://sourceforge.net/p/scintilla/code/ci/bd49c446e0eca46c3e9c79f943cc75ce190a7e0b/

Neil

[Mike Lischke]

Thank you Neil.

Mike
--
www.soft-gems.net

[MizJunAmi]

Would you consider adding support for custom draw for ac list and calltips?
Currently I use some subclassing tomfoolery to get the job done but i think it would be much more fluid and efficient to support NM_CUSTOMDRAW unless im missing something

[Neil Hodgson]

MizJunAmi:

> Would you consider adding support for custom draw for ac list and calltips?
> Currently I use some subclassing tomfoolery to get the job done but i think it would be much more fluid and efficient to support NM_CUSTOMDRAW unless im missing something

The autocompletion list is a ListBox, not a ListView so doesn’t support NM_CUSTOMDRAW.

Custom drawing by itself is inadequate for most of the extensions wanted, and will not work cross-platform. As said before, a more extensible way to allow application-defined auxiliary windows is with a protocol for cooperation between Scintilla and the auxiliary window.

Neil

[MizJunAmi]

Understood.