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

[Elvis Stansvik]

Hi Andreas,

2011/8/2 Andreas Vox <andreas.vox at googlemail.com>:
> 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)

It turned out it was me who broke it in a change to ScPainter. See the
other mail to the list from me, where I have some questions about the
validity of the fix I finally ended up with.

>> 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.

It shouldn't be too hard to just go through the places where this
behavior is (wrongly) relied upon. Just gotto make sure I catch them
all. I'll add it to my TODO.

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

Ah I was just curious as it has some goodies in it. But I'm perfectly
fine with using just good'ol C++ for now.

>> 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.

Good.

>> 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:

Alright. I guess you're right.

> - 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

Thanks a lot for these tips. After finishing the canvas modes I'm
working on, this is the next thing on my list.

>> Anyway, too many questions already for one report :)
>
> Not at all :-)

Thanks for the input :)

Elvis