Multiline strings in wxDataViewCtrl

[Vadim Zeitlin]

Hello,

Currently if the value of a wxDataViewCtrl cell is a multiline string,
it's rendered badly under both MSW and GTK (I didn't check OS X yet): only
the first line is fully visible and, worse, the very top of the second line
is still visible, so you just see the top pixel of the full height letters
(such as "f", "h" or "l") in it and nothing else.

Also, editing such a value opens a single line wxTextCtrl which,
unsurprisingly, is not really suited for editing multiline values,
especially under MSW where the "\n"s are still present in the string but
are completely invisible, you can only detect their presence by noticing
that you need to move cursor by 2 positions to skip over them. In GTK
things are a bit better as "\n"s do appear on the display, as "000a"
unprintable character in a box, but this is still hardly ideal.

The question is, what could be done to improve the situation? An obvious
answer is to avoid using multiline values with wxDataViewCtrl, but perhaps
we could do something better? For the rendering part, the choice is either
render only the first line of the value, possibly with some "continuation"
character(s), or show the full multiline value on a single line after
replacing the new line characters with something else, e.g. "RETURN SYMBOL
(U+23CE)" (http://www.fileformat.info/info/unicode/char/23ce/index.htm).

For the editing part, the best solution would clearly be to use a
multiline text control, but I am not sure how to do this in the GTK (let
alone OS X) version, does anybody know if it would be possible? As a stop
gap, we could at least edit the value with the new lines replaced by the
"RETURN SYMBOL" in single line wxTextCtrl. In fact, I wonder if we
shouldn't always do this (i.e. s/\n/\x23ce/g) in single line wxTextCtrl
under MSW because while it's definitely not great, it's much more clear and
useful than the standard behaviour. The only problem I see is that this
would make editing strings containing the literal "RETURN SYMBOL" character
in them confusing, but I doubt it's going to be that big a deal in
practice.

Thanks in advance for your thoughts,
VZ

[Tobias T]

Hi,

 The question is, what could be done to improve the situation? An obvious
answer is to avoid using multiline values with wxDataViewCtrl, but perhaps
we could do something better?

As a user I wouldn't even expect a control like dataviewctrl to render multiline values.
But maybe that's just me :)
 

For the rendering part, the choice is either
render only the first line of the value, possibly with some "continuation"
character(s), or show the full multiline value on a single line after
replacing the new line characters with something else, e.g. "RETURN SYMBOL
(U+23CE)" (http://www.fileformat.info/info/unicode/char/23ce/index.htm).

If support for multi line is added I would definitely prefer all lines to be rendered in multiple lines.
Or if we stick with a single line I would prefer "..." (or similar) to rendering a single line with return symbols.
 

 For the editing part, the best solution would clearly be to use a
multiline text control, but I am not sure how to do this in the GTK (let
alone OS X) version, does anybody know if it would be possible?

I don't know if this is possible, but if it is not possible on at least one native implementation, it shouldn't be added to the generic one.
 

As a stop
gap, we could at least edit the value with the new lines replaced by the
"RETURN SYMBOL" in single line wxTextCtrl. In fact, I wonder if we
shouldn't always do this (i.e. s/\n/\x23ce/g) in single line wxTextCtrl
under MSW because while it's definitely not great, it's much more clear and
useful than the standard behaviour.

Allowing multi line editing in a single line wxTextCtrl seems hackish to me
and the expected behavior probably depends on context. Like in a more technical
program (e.g. IDE, Other Dev tool) it might make more sense to replace new lines
with \n as that what users are used to. Also how would the user even enter the unicode
return character in case he want's to add a new line?

Regards,
Tobias

[Vadim Zeitlin]

On Wed, 30 Sep 2015 00:55:34 -0700 (PDT) Tobias T wrote:

TT> > The question is, what could be done to improve the situation? An obvious
TT> > answer is to avoid using multiline values with wxDataViewCtrl, but perhaps
TT> > we could do something better?
TT>
TT> As a user I wouldn't even expect a control like dataviewctrl to render
TT> multiline values.
TT> But maybe that's just me :)

To be honest, I hadn't thought about this neither until yesterday. But it
turns out that in the case of the program I'm working on, there is really
nothing fundamentally wrong with showing multiline strings in wxDVC and
even though I'm not sure if it's really useful, currently it's just plain
ugly and unusable: ugly because the very top pixel of the second line is
shown (in the generic version), resulting in something that looks very much
like display corruption and unusable because editing a multiline string in
a single line text control is pretty weird, at least under MSW (GTK is not
ideal but usable).

To give a simpler and self-contained example: suppose wxDVC is used as a
front-end to a database table: even if typically a database column contains
only single line strings, you can't really guarantee (well, you can with
some database-level constraints but IME nobody does this) that NLs don't
get into it. And if they do, it would be better to show them in at least
somewhat reasonable way instead of doing what we do now.

TT> > For the rendering part, the choice is either
TT> > render only the first line of the value, possibly with some "continuation"
TT> > character(s), or show the full multiline value on a single line after
TT> > replacing the new line characters with something else, e.g. "RETURN SYMBOL
TT> > (U+23CE)" (http://www.fileformat.info/info/unicode/char/23ce/index.htm).
TT>
TT> If support for multi line is added I would definitely prefer all lines to
TT> be rendered in multiple lines.

I don't think this is realistic, this would require using the
wxDV_VARIABLE_LINE_HEIGHT style and you don't want to use it as it
completely kills the performance with many items.

TT> Or if we stick with a single line I would prefer "..." (or similar) to
TT> rendering a single line with return symbols.

I thought about this but I think the ellipsis is not very clear because we
already use it for, well, ellipsization, so you wouldn't see at a glance if
the value is truncated horizontally or vertically. We could use some other
character instead, e.g. VERTICAL ELLIPSIS (U+22EE), but it's not very clear
neither.

And, of course, whichever symbol we would use, it still wouldn't be
possible to see the full multiline text in the cell which is the main
benefit of flattening it into a single line.

TT> > For the editing part, the best solution would clearly be to use a
TT> > multiline text control, but I am not sure how to do this in the GTK (let
TT> > alone OS X) version, does anybody know if it would be possible?
TT>
TT> I don't know if this is possible, but if it is not possible on at least one
TT> native implementation, it shouldn't be added to the generic one.

I agree. But I am probably not ready to work on this anyhow, for my needs
using a single line wxTextCtrl with the s/\n/\x23ce/g replacement is good
enough.

TT> > As a stop gap, we could at least edit the value with the new lines
TT> > replaced by the "RETURN SYMBOL" in single line wxTextCtrl. In fact, I
TT> > wonder if we shouldn't always do this (i.e. s/\n/\x23ce/g) in single
TT> > line wxTextCtrl under MSW because while it's definitely not great,
TT> > it's much more clear and useful than the standard behaviour.
TT>
TT> Allowing multi line editing in a single line wxTextCtrl seems hackish to me

It definitely is, but it kind of makes sense though, doesn't it? At least
IMO it makes more sense than the native behaviour which is plainly unusable
(just try pasting a multiline string into a simple EDIT and play with it).
In fact, the native behaviour was pretty similar to this in the older
Windows versions where NLs appeared as vertical bars in the text controls.
And this is similar to the native GTK behaviour too.

TT> and the expected behavior probably depends on context. Like in a more
TT> technical program (e.g. IDE, Other Dev tool) it might make more sense
TT> to replace new lines with \n as that what users are used to.

I think any program that really wants to support editing multiline text
would use a wxTextCtrl with wxTE_MULTILINE for it anyhow. The question is
whether the proposed change would help if a text with NLs gets used in a
control which was not meant for editing multiline text. And IMO it would.

TT> Also how would the user even enter the unicode return character in case
TT> he want's to add a new line?

He would need to copy and paste it, just as with GTK "00 0a" box. Again,
this is clearly not ideal but I think it's still better than the current
situation: right now to add a new line you would have to copy and paste an
_invisible_ NL character.

Regards,
VZ

[Igor Korot]

Hi, (Vadim, Tobias),

Why not render the multiline as multiline and use a single line for the editing.
Just display "\n\r" or "\n" as a new line character for the editing in
a single line
text control...

Thank you.

[Iwbnwif Yiw]

Hello, FWIW I think a multiline wxDVC is definitely useful and there are very many use cases for it. 

I fact I implemented a wxDataViewCustomRenderer to achieve a similar thing for displaying database records, however I didn't attempt in-place editing of the records, instead opening a dialog where all relevant fields in the row could be edited.

In my implementation I did use wxDV_VARIABLE_LINE_HEIGHT and adjusted the height to match the amount of text. I didn't notice any performance issues but that is probably that is because I only had a couple of hundred rows, however I do think that variable row heights can look a bit ugly in a grid format. I also implemented word wrapping so the row height depended on both the column width and the amount of text in it.

If wxDV_VARIABLE_LINE_HEIGHT is not an option (and in fact in any case), I would like to propose that a 'number of visible text rows' could be set. This would imply a consistent font for all rows, but basically no matter how long the text is you would always see the first 2, 3, 4 ... rows, probably followed by ellipses to show an overflow.

I tried this, but I also wanted to show the whole text in a tooltip when the user hovered over a cell with an overflow. Unfortunately it seems that cell-by-cell tooltips are not possible in wxDVC and therefore I scrapped this whole approach and went with a wxGrid when I need multiline text instead :(

[Vadim Zeitlin]

On Wed, 30 Sep 2015 06:48:53 -0700 (PDT) Iwbnwif Yiw wrote:

IY> Hello, FWIW I think a multiline wxDVC is definitely useful and there are
IY> very many use cases for it.

I think there are 2 related but separate issues: first one is the one you
discuss and while I agree that it would be useful to have better support
for multiline values in wxDVC, this is not something I plan to work on in
the immediate future _unless_ it's the only way to address the second
problem, which is the one I'm really interested in because it affects the
project I'm working on, i.e. the clearly bad behaviour if a multiline
string just happens to be displayed in a normal "text" wxDVC cell.

I just want to make the latter case less awful, both for rendering where
something just has to be done, even if this something is just truncation of
the text to the first line, because we can't have corrupted display as we
do now, and, ideally for editing too. And thinking about the latter made me
realize that we have exactly the same problem more generally with the
single line wxTextCtrls, i.e. what happens if a multiline string finds its
way into one -- and here the behaviour is also pretty bad under MSW (but
not GTK).

The solution I propose, with the RETURN SYMBOL replacement, would work
consistently for both wxDVC and wxTextCtrl under MSW (BTW, maybe wxDVC
under GTK could use the same boxed "00 0a" as the native GtkEntry uses)
which is why I like it. What other solutions do we have? The only
reasonable one I see is to truncate the multiline string on display in
wxDVC, but this (a) doesn't allow to see the full value and (b) is
inconsistent with wxTextCtrl behaviour, so I don't see how is it better
than what I propose.

Am I missing anything?
VZ

[Iwbnwif Yiw]

On Wednesday, September 30, 2015 at 4:31:31 PM UTC+1, VZ wrote:

 I just want to make the latter case less awful, both for rendering where
something just has to be done, even if this something is just truncation of
the text to the first line, because we can't have corrupted display as we
do now, and, ideally for editing too. And thinking about the latter made me
realize that we have exactly the same problem more generally with the
single line wxTextCtrls, i.e. what happens if a multiline string finds its
way into one -- and here the behaviour is also pretty bad under MSW (but
not GTK). 

Ah, I really apologize - I completely missed that you wanted this (less awful ;)) behavior in all multiline situations. 

In which case I don't have much to add, except perhaps to say that showing the full text in a tooltip would be nice. Also perhaps consider to include the option to use a 'Pilcrow' (ASCII 244) instead of Return Symbol?.

Interestingly Excel (I know it's not the same thing as a data view) behaves similarly to a wxTextCtrl, i.e. if it is set to "Word wrap" then a new line is started after a return, otherwise the second line is appended to the first without a space.

[Vadim Zeitlin]

On Wed, 30 Sep 2015 09:13:15 -0700 (PDT) Iwbnwif Yiw wrote:

IY> On Wednesday, September 30, 2015 at 4:31:31 PM UTC+1, VZ wrote:
IY> >
IY> > I just want to make the latter case less awful, both for rendering where
IY> > something just has to be done, even if this something is just
IY> > truncation of the text to the first line, because we can't have
IY> > corrupted display as we do now, and, ideally for editing too. And
IY> > thinking about the latter made me realize that we have exactly the
IY> > same problem more generally with the single line wxTextCtrls, i.e.
IY> > what happens if a multiline string finds its way into one -- and here
IY> > the behaviour is also pretty bad under MSW (but not GTK).
IY>
IY> Ah, I really apologize - I completely missed that you wanted this (less
IY> awful ;)) behavior in all multiline situations.

Yes, my concrete goal is to just fix the bug in my project right now. Of
course, I could do it by doing the replacement in my own code and I've
actually already done it and tested how it worked and, FWIW, I think it's
much better than the current behaviour, but I also thought that it would
make sense to always do this and not just in my particular case.

IY> In which case I don't have much to add, except perhaps to say that showing
IY> the full text in a tooltip would be nice. Also perhaps consider to include
IY> the option to use a 'Pilcrow' (ASCII 244) instead of Return Symbol?.

Hmm, isn't PILCROW SIGN (U+00B6) a paragraph, rather than line, marker? I
agree that the RETURN SYMBOL is not obviously ideal in this context and I'd
like to find something better, but the PILCROW SIGN doesn't seem to be
obviously appropriate -- unless it's already used in some common software
with this meaning?

IY> Interestingly Excel (I know it's not the same thing as a data view) behaves
IY> similarly to a wxTextCtrl, i.e. if it is set to "Word wrap" then a new line
IY> is started after a return, otherwise the second line is appended to the
IY> first without a space.

I thought about just replicating this too, as this does seem to be the
native behaviour, but it just seems so bad to me that I still prefer using
a replacement character, rather nothing at all.

Regards,
VZ

[Iwbnwif Yiw]

 Hmm, isn't PILCROW SIGN (U+00B6) a paragraph, rather than line, marker? I
agree that the RETURN SYMBOL is not obviously ideal in this context and I'd
like to find something better, but the PILCROW SIGN doesn't seem to be
obviously appropriate -- unless it's already used in some common software
with this meaning?

Yes, I think what you say is correct.

But I guess it depends on how the new lines are appearing in your database fields. In my case it was users cutting and pasting from Word or PDF documents, so that is why a Pilcrow would make some (admittedly limited) sense.