Solve MultiLine TextEntry problem by adding a new TextArea widget #369
Conversation
and move it to GtkWorkarounds.cs
extension method for easier implementations for other editable widgets.
for different alignments
* mark TextEntry.MultiLine obsolete
Some toolkits (like Gtk) have different widgets for single- and multi-lined
text input. This makes it possible to implement multi line text enty backend
for those toolkits in a clean way.
using Gtk.TextView as backend
and mark as deprecated
sevoku
changed the title
|
I still think the fact that some Backends uses different widgets for single line and multi line text isn't enough a motive to add a extra Xwt widget (TextArea in this case). For instance. Assume I coded a window with a Xwt.TextArea that you propose on this PR. When using the same code on WPF, will the Xwt.TextArea be mapped to WPF.TextBox with the multiline setted true? So we'll have 2 classes that only changes one property of the backend. I think is a complexity the API doen't need to have. As I said at lytico#25, in my opinion the Gtk.Entry and Gtk.TextView should both implement the Xwt.TextEntry and the choice would be made at Multiline property change, as second lvl backend. This way we don't have to mind what widget we're using when "port" Xwt.Gtk code to others Backends that don't have 2 widgets for text and vice-versa. The only drawback, as @sevoku pointed at lytico#25, would be if one wants to do some Gtk specific code, but this breaks the "porting" ability anyway... |
|
I think this is not "much more" complex then only one Widget with the Property, but think about the complexity in the backend development. Maybe someone will be going to add Xamarin (iOS/Adnroid) support (at least iOS has different Widgets) or some sort of Web backend (html has two widgets, too). The implementation will be as complex as in Gtk. And there are many reasons to use Native access (it's really a nice feature) without "portability" concerns. Monodevelop does it for example. I use it to reuse widgets between different GUIs in guest mode. Adding backend switching may break such implementations, so the developers will have to change their code. My approach doesn't break something (I hope so). Old implementations can continue using the TextEntry.MultiLine property and expect same behavior (of the backend, too). New projects could use the different Widgets, or continue using the "Windows-like" API for easier porting of WPF guis and adopt the API change later on. Think of API "flexibility" instead of "complexity" 😉 |
|
Ok. I agree. I was looking at some others GUI libraries and is true most of them uses two widgets for single line and multi line text io... Adding the TextArea will indeed help with the development of new backends... 😃 |
|
I've rebased the changes and created a new branch. The new PR is here: #375 |
This is an approach to solve problems with TextEntry.MultiLine in a more clean way. Some Backends (Gtk for now, maybe other in the future) have different widgets for a single- and a multi-line text input (Gtk.Entry vs. Gtk.TextView).
There are some different approaches and ready solutions, but none of them is really clean (see #367 and discussions in #288, lytico#25 and some posts in Forum).
This PR solves the issue by deprecating Xwt.TextEntry.MultiLine and adding a new widget Xwt.TextArea (like in HTML). The most code has been moved to an abstract class Xwt.TextBox which handles everything except the MultiLine property. TextEntry and TextArea are subclasses of Xwt.TextBox and implement only their specific properties (new TextArea.Wrap and deprecated TextEntry.MultiLine)
It is important, that TextEntry.MultiLine has not been removed (only marked with the Obsolete attribute). ITextEntryEventSink is not used by any Backend anymore, but should still be functional (for third party implementations). TextEntry still maps the deprecated TextEntryEvent (replaced by TextBoxEvent), too.
PS: This PR contains #368! I accidentally checked out the wrong branch and realized that after pushing it to github. So this PR depends on #368 and I had no time to split them. SORRY!