[scribus-dev] Tables GSoC - Weekly Report #8 and #9 - Double Report

[Andreas Vox]

Hi Elvis!

Comments inline:

> -----Ursprüngliche Nachricht-----
> Von: Elvis Stansvik [mailto:elvstone at gmail.com]
> Gesendet: Montag, 1. August 2011 23:53
> An: Scribus Development Mailing List
> Betreff: [scribus-dev] Tables GSoC - Weekly Report #8 and #9 - Double
> Report
> 
...
> == Problems / Questions ==
> 1) As mentioned in another thread on the ML, I can't seem to get the
> guides and grid shown. For some reason they are always invisible for
> me, even though I have "Show Grid" and "Show Guides" on. Any ideas?
> I've tried changing their colors, putting the in foreground/background
> as well as wiping ~/.scribus. If anyone is testing my repo, it would
> be great if you could check. I really hope I didn't break anything and
> that it's just some weird graphics issue or something (I'm on nvidia).
> But I don't think I've touched any of those code paths.
> 

Is that in all modes or just in table editing? Do you call the routine that 
draws the guides? (I'd have to search to find out where it's usually
called, but it should be either in canvas.cpp or canvasmode.cpp)
Does it receive a correctly configured painter? (see save()/restore() below)

> 2) When I wanted to have the selection of the table painted similar to
> that of a text frame when it is edited (e.g. just a red rect, no
> handles), I found that I could do this by calling
> CanvasMode::commonDrawControls(). However, I discovered something that
> I think is kind of nasty; if you take a look at
> CanvasMode::drawSelection(), which is called by commonDrawControls(),
> you'll see that it performs transformations on the painter without
> save()ing and restore()ing it properly. I discovered this since I was
> doing my own transformation of the painter. Okay I thought, I'll just
> fix that, so I added save() and restore(). I then discovered that a
> lot of the current items rely on this behavior. I really doubt this
> was intended? So it is a bit of a work to make a proper fix. At the
> moment I worked around it by guarding my call to
> CanvasMode::commonDrawControls() with save()/restore() myself, e.g.:
> 
> p->save()
> commonDrawControls();
> p->restore()
> 
> but this is a hack. Just thought I'd give a heads up on this.
> 

Yes, that's a bug I also encountered when working on the canvas-bug. Feel 
free to fix it.

> 3) Minor question; I guess c++0x is still off limits for Scribus code?
> 
For now, yes. You can use boost, though.

> 4) InDesign draws a simply blue grid while a table is resized, without
> any respect for cell spans/column spans. In my implementation, the
> blue grid will respect row span / column span. Which one do we want? I
> guess ID did it like this because its simpler (and possibly slightly
> faster).
> 
Your implementations sounds perfect.

> 5) Now that I've worked a bit with the canvas mode code, I've gotten
> this idea in my head for the editing of cell text content; what if I
> create a canvas gesture that simply acts as a proxy to an instance of
> the real text editing canvas mode (CanvasMode_Edit), which would be
> set up to edit the text frame of the cell being edited? Do you think
> such an approach could work? This proxy gesture would forward all
> events (possibly intercepting some of them for cell navigation). It
> might even be activated when a cell is hovered with the mouse, which
> would save us from multiple layers of modes having to be activated by
> the user to be able to edit cell content (But for a start, I would
> activate it on double click on a cell). The approach has a slightly
> hacky vibe to it, but if it could work I think it would be great as
> all the functionality of the existing text editing canvas mode could
> be leveraged. And what is really the alternative? Someone (was it
> avox?) mentioned in another thread that one should simply forward
> mouse presses and use insertText() in the keyboard event or something
> to that effect? Perhaps this is what was meant...
>
Yes, that was me. I wouldn't start with edit mode right now. Using a proxy
to access a textframe might work, but you might also get lost in the
textmode intrinsics. If you start from scratch, best follow these steps:

- get the display of text content right
- implement cursor placement with the mouse
- implement text selection
- then implement keyboard events: use insert/deleteText on the StoryText
  and let layout()/update() do the rest
 
> Anyway, too many questions already for one report :)

Not at all :-)

/Andreas