optimize multiline entry

[sevoku]

Hi,
your frame implementation is not very nice, since you draw the frame yourself. You should use a native frame to keep the native feeling and honor users theme settings.

[sevoku]

your change breaks this feature for PasswordEntry and SearchTextEntry.
I've added specific extensions methods for Gtk.Entry and Gtk.TextView. RenderPlaceholderText should not be applicable on other Gtk widgets (Gtk.Widget) so lets make it private.

[thiagojedi]

Placing a TextEntry and a PasswordEntry side-by-side shows that the PasswordEntry, still with the Gtk.Entry as backend, is a little taller than the TextEntry.

I sugest add 6 pixels to the lineHeight and set the PixelsAboveLines to 3 pixels... This way they will look alike... at least they did here on my pc (Xubuntu 14.04)

[sevoku]

yes, but its a wrong way to set PixelsAboveLines here, cause it remains if MultiLine is changed after initialization. Lets set it together with the MultiLine prop.

[sevoku]

Hhm, with this approach we have still inconsistent style compared to Gtk.Entry (and so PasswordEntry and SearchTextEntry). Many Gtk themes style Gtk.Entry differently. On Ubuntu Gnome 14.04 all Entries have rounded frame corners and the frame border has a different color, when the entry is focused.

I've tried a dirty approach by using a table (instead of a frame) and adding a Gtk.Entry behind Gtk.TextView (see http://stackoverflow.com/a/17977591). This solves the problem with rounded frame corners, but the Entry in the background needs a focus to draw the colored frame correctly, which steals the focus from TextView. So not really applicable.

[thiagojedi]

Is there any way to change the Backend widget on the fly?
I mean, with Multiline set false it uses Gtk.Entry and with true it uses
Gtk.TextView.

Both Backends implements the same interface, should be no problem
there.

[sevoku]

I've done this already for me that way, but it is really dirty and the code is hard to read, because all methods have an if (MultiLine) .. else.

A better solution would be to remove the Xwt.TextEntry.MultiLine completely (or better mark it as Deprecated) and add a Xwt.TextEntryMultiline class, derived from TextEntry, but bind it to a new ITextEntryMultilineBackend interface. For Wpf and Mac TextEntryBckend would implement both (ITextEntryBackend and ITextEntryMultilineBackend). Gtk would register different backends (the old one for ITextEntry and the new one only for ITextEntryBckendMultiline).

This would be the cleanest solution, but a massive change of the Xwt API.

[thiagojedi]

I was thinking more in the way of a 2nd level backend.
We make the "TextEntry" class route the method calls to a
TextEntrySingleline or TextEntryMultiline, the same way the Xwt itself
does.

Most of the complexity will be on the Multiline property setter,
as some properties like the Placeholder and the Text will need to be transfered
from one object to the other.

It doesn't break the API, and it would be way cleaner than a lot of conditionals.

[sevoku]

oh, yes, this would work of course. But I personally don't really like both ways of switching backends. It makes the backend code much more complex and makes it harder to implement backend specific code on the consumer part (since you have to check what backend is actually used).
I've implemented some little API changes and will push them tomorrow to my repository. The changes are not very deep and should have no regressions, since the old api is only marked as obsolete.

[lytico]

Thanks for your inputs. I'll review it in the next days.