1

I'm currently creating an application to edit parallel lists of events which happen on a timeframe. In the model/backend there is a list of lists where the sublist has all the items in order.

Each event should be represented by a string/glyph (from a ttf font) and each of the textlines should be edited like a normal line of text with a few exeptions how they are displayed. Look at this picture:

Example

Basically each lines represents a line of text. Each event is a single char/glyph. So its a text editor?! Not quite

  1. There are no linebreaks
  2. Multiple lines in parallel
  3. Each glyph has an individual space after it (X-direction)
  4. Each glyph can be shifted "up" and "down" individually (Y-Direction) (Maybe the most important point)
  5. If you delete a glyph all items right of it go a step "left" to close the gap (just like in a normal texteditor).
  6. If you insert a glyph all items right of it go a step "right" to create a gap to insert.

Most of these points are covered by QGraphicsLinearLayout, but maybe its the wrong widget/layout for this approach. Do you have any advice?

nilshi
  • 504
  • 1
  • 6
  • 16
  • Could you give some information about the dimensions we are talking about here? 5 lines with 15 events? 100 lines with 5000 events? – Exa Aug 05 '11 at 12:32
  • @Exa Yes of course.I can't really predict it since its a users choice, but here is some common sense: Since the lower boundaries will be no problem (performance wise) anyway a common upper boundary would be around 150 lines with several hundreds to around 5k events. Values above that should not be prevented but it is seldom and users would expect performance issues from here on anyway. – nilshi Aug 05 '11 at 12:47

1 Answers1

1

I would suggest trying to setup a QGraphicsScene with your events as QGraphicText objects (or possibly a class derived from QGraphicText). Let each be positioned independently, but let them know about the "next" event on their line, like a linked list. Then, when one is inserted or deleted, you can quickly do that operation and (unfortunately, more slowly) update the positions of the other events in the line. This update might not be too much code, if it's just setting the position to be X pixels to the right of the previous item, but it will have to update every event in the line after the modification.

You could maybe do some thing where the event to the right is a child of the current event, and push off the position updates to Qt. I don't know if that would be any more efficient, and I don't know how deep child trees can really get.

Updating the Y position of the event (requirement 4) should be easy: just change its Y position.

Scott Minster
  • 422
  • 5
  • 9