Nested delegates in a QListWidget

[youkai]

Hi.

The delegate of a list item is a table. So far, so good. The tables cells are also editable and use a delegate (line edit).

Whenever I'm in that second level delegate and hit "up" or "down", den listwidget enters a strange state where every "tab" or "arrow" hit crashes the program.

On focus loss, only one level of editing will be closed also.

What do I have to check if I want to use such nested delegates correctly?

Bye

[wysota]

Could you rephrase your question? Try describing it using simple sentences and please give more details. A code snippet might help greatly as well.

By the way, you are incorrectly referring to the term 'delegate'. The delegate is an invisible object that provides service to a view and paints items on its behalf. Usually there is one delegate for the whole view, even if you want different items to be handled differently. I don't know what you did in your delegate(s) but you probably have a design flaw somewhere.

[youkai]

Here is a screenshot with the "nested" editing active.



If you hit the down-arrow, both edit modes will not be closed correctly.

Bye

[wysota]

You have a table widget inside a list widget? Wouldn't it be easier using a QTextEdit? Constraining edit to a single word should not pose a problem (if that's what you want).

[youkai]

And disable line breaks? The content is arranged in syllables already. A QTextEdit is no possibility.

Bye

[wysota]

And disable line breaks?

Sure, why not?

The content is arranged in syllables already. A QTextEdit is no possibility.

I don't see the problem. QTableWidget inside a QListWidget is probably one of the worst possible solutions. A simple custom widget would be much better here than this construction but I still think you can use QPlainTextEdit if you reimplement its keyPressEvent and disable some of the keys. If not then QListWidget with a custom delegate is an option. So is a QListWidget without a custom delegate but with items properly laid out which should be possible by enabling wrapping.

[youkai]

Thanks for your input. I will think about it. My problem was solved by disabling Key_UP and Key_DOWN while in edit mode.

Your ideas are quite nice but I think the usability of the result would not be so good. Well, I will think about it.

Bye

[wysota]

Your choice. Your current solution is completely unscalable and QListWidget is practically unused at all. You might have used QScrollArea instead of it as well. To me it seems you are emulating a text editor/browser widget with two nested widgets serving for a completely different purpose. I don't how it relates to usability But that's your choice, no problem with me.

[youkai]

Unscalable? Well, there won't be much text - just the lyrics of one song - not that much. I use the QListWidget for selecting a line - not "unused" at all. Or what do you mean?

The use-case is to offer a more convenient way for editing this kind of text file:

...
: 185 2 10 ter
: 189 5 10  an,
- 196 222
: 242 3 8 der
: 247 3 8  hat
: 252 2 8  so
: 255 5 8 gar
: 263 3 5  ein
* 270 6 13  Au
* 278 14 10 to.
- 294 329
: 349 4 12 Wa
: 354 4 12 rum
: 360 4 13  gehst
: 365 3 10  du
: 369 4 10  nicht
...

...
: 185 2 10 ter
: 189 5 10  an,
- 196 222
: 242 3 8 der
: 247 3 8  hat
: 252 2 8  so
: 255 5 8 gar
: 263 3 5  ein
* 270 6 13  Au
* 278 14 10 to.
- 294 329
: 349 4 12 Wa
: 354 4 12 rum
: 360 4 13  gehst
: 365 3 10  du
: 369 4 10  nicht
...

To copy to clipboard, switch view to plain text mode 

You must not destroy the syllable itself but make minor corrections like adding/remove a whitespace or fix spelling issues.

Do you have a better approach in mind?

Bye

[wysota]

To me the perfect solution is to use a QTableWidget. Either a standard one or a modified one with visualRect (and probably some other methods as well) changed so that you can have different widths of columns in different rows if you need that. A feasible solution is also to implement a completely custom view so that you have a bit more control over what is going on. The view is really simple so it should take no more than an hour to implement it. Once you have visualRect() and indexAt() implemented, the rest will build upon them.