search

lytico / xwt

MIT License
1 stars 2 forks source link

optimize multiline entry #25

Open sevoku opened 10 years ago

sevoku commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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