[scribus-dev] Tables GSoC - Weekly Report #6

[Elvis Stansvik]

Good morning,

Here comes my sixth report [1], along with a little screencast showing
the bits of new UI I've added:

http://www.nya-doxa.se/elvis/gsoc2011/week6_table_pp_editing.ogv

Of course none of it is set in stone, so please comment.

Cheers,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Weekly_Reports

= Tables GSoC - Weekly Report #6 =

== Work Report ==
* Changed logic if TableBorder::joinsWith(..); null borders can never join.
* Finally fixed the joining algorithm. It is now 100% according to
spec. I had actually missed two cases of possible joins. Any more work
to be done on the joining algorithm are just aesthetic adjustments for
the more obscure cases (e.g. four borders of different width meeting
at a cross et.c.).
* Added a test script that tests the 43 join cases (see attached screenshot).
* Changed grid lines to be painted in a separate pass. This is needed
as they need to be on top of everything else. TODO is to add a setting
for turning them on/off.
* Fixed a bug in grid line painting on cells that span multiple rows/columns.
* Fixed a similar bug in cell fill painting.
* Fixed an off-by-one bug in the calculation of border segment interval.
* Fixed the bugs in the neighboring cell determination I was talking
about in my last report. I've since realized there's another bug there
relating to spanning cells, but that one should be easy to fix.
* Added a new widget TableSideSelector for selecting which sides of a
table/cell to apply border properties to.
* Cleaned up and extended the API of TableBorder a bit, and made sure
that border lines are always in descending order by width.
* Initialized borders properly in default table/cell styles.
* Added support to PropertiesPalette_Table for editing table borders
and fill (using the new TableSideSelector widget).
* Blogged a couple of times about the border joining (http://estan.dose.se/).

== Project Status ==
In the schedule for week 6 was

* Wrapping up for mid-term evaluation.
* Fix bugs/finish up what I have so far.

But my goal as stated in the last report was catching up with the
schedule, so I've both been working on fixing bugs and on the UI.
Unfortunately I've still not had time to do any text frame integration
work, apart from some discussions on the ML. But as I said before,
there are some gaps in the schedule coming up and I'm still hopeful
that I'll catch up completely.

== Problems / Questions ==
During the UI work a couple of things popped up:

===Question 1===
* When the item selection changes,
PropertyPalette::handleSelectionChanged() is called, which in turn
calls handleSelectionChanged() on my table property palette. In there,
I take care of setting up stuff for editing of the selected item.
Among other things, I reset the new table side selection widget to
have all four sides selected. This is the initial state of the widget
when editing a newly selected item.
* After changing a property on the table from the PP, I call update()
on the item to request an update, which I guess is the correct way to
do it?

The problem is that the call to update() will in the end result in
handleSelectionChanged() being called. I've discovered that this is
true for all items; when editing a property of an item in the PP,
handleSelectionChanged() will be called, even though no selection
change has really occurred, just a change in an item property. This
has the following consequence

* Select a table.
* Select just the top side in the new side selector widget.
* Change the border width using the spinbox.
* Ouch! Since handleSelectionChanged() was called, the palette assumed
the selection changed and therefore reset the side selector widget to
have all four sides selected.

At the moment I work around this by checking in
handleSelectionChanged() if the selection really did change (pointer
comparison to previously selected item). So my questions regarding
this is

1) Is update() the correct function to call to request an update after
changing a property on an item?
2) Is it desired behavior that
PropertyPalette::handleSelectionChanged() is always called when
update() is called on one of the items in the document? The selection
didn't change..
3) Is my workaround above OK or is there a better way?

===Question 2===
I've now finally hit some problems relating to painting outside of the
table frame (before I didn't have any artifacts because of this, but
now they've started to appear sometimes when changing the border
through UI).

So how should we handle this? Should the top/left side of the table
always stay inside the table frame (e.g. be offset by
max(top_borders)/2 in the Y direction and max(left_borders)/2 in the X
direction) or not?

== Next Week ==
The schedule for next week simply says

* Row and column spanning.

which is pretty much finished, so I think I'll try to keep working on
UI to get some steam going on that. I'll finish off editing of the
supported table features in the PP and then do the same for the SM.
Then I'll start looking at cell selections / canvas modes and the
editing of cell properties. I think I'm reconsidering the approach
I've taken with using a QListWidget for the border lines, and I'll
probably turn it into a proper model/view instead.

Since the mid-term evaluation deadline is on Friday, I'll also write
up a short summary report of the first 6.5 weeks of the project, and
maybe make another blog post showing off the new UI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 43_cases.png
Type: image/png
Size: 262841 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110711/44dc50b6/attachment-0001.png>