Re: Kupu: default cursor position and tables

Samuel Schluep wrote:

> Hello Developers
>
> Please note some problems I encounterd, when editing with Kupu:
>
> DEFAULT CURSOR POSITION WHEN KUPU OPENS
>
> 1. Opening Kupu will position the cursor at the beginning of the 
> title. For me this is annoying, because I tend to start editing right 
> ahead - just into the title. It would be nice if Kupu would position 
> the cursor on the first line after the title.
>
Done.

> 2. To edit a new document with Kupu you have to add a new line: this 
> means (1) you have to position the cursor at the end of the title, (2) 
> press enter (which adds two rows), (3) delete one of the two rows. 
> From my point of view, these three actions are superfluous and make 
> the users life harder.
>
Done, same fix as above. When Kupu opens, if there is already content in 
the page the cursor is positioned on the first line/element of that 
content (just below the title header), if there's no content, an 'empty' 
(containing a nbsp) <p> element is placed and the cursor is positioned 
in that.

> TABLES
>
> 1. Kupu adds a blank to every cell. When the user clicks the cell to 
> enter new data, the cursor is placed after the space and the user 
> tends to enter some text right there. The cell contents will start 
> with a space, which is annoying - especially if the line wraps on 
> multiple lines. The user has to delete all spaces manually.
>
As I said before table cells *must* have content, actually if you remove 
it editing doesn't seem to be possible anymore, so that can't be 
'fixed'. What I did do, is change the code so that if you click in a 
table cell of a newly created table (not (yet?) in tables that were 
already in the document) the cell's contents will be selected if it only 
contains an nbsp, which seems to work quite nicely, you can just 'click 
and type'.

> 2. If 'subparagraph' is assigned to table cell (or to the text in a 
> table cell) the assignment can not be changed back to plain or another 
> type.
>
I can reproduce that, but it looks like it's quite hard to fix and 
doesn't have any consequences for the document (nothing happens to the 
text style, and the setting is gone after a save). Would it be a problem 
if this wasn't fixed? Not really nice, I know, but it occurs in built-in 
behaviour, what I think I should do to fix it is checking whether 
changing the text style in the current context is allowed or not, 
meaning that I need to find out if we're inside a table cell, if so if 
there's a <p> on a lower level, etc., probably also for list items, etc. 
Not sure whether the overhead (and the time it will take to fix the bug) 
is worth the gain of not having the behaviour anymore...

> 3. It would be nice if table cells could span across multiple columns, 
> to make headings for multipe columns.
>
I was thinking about this, and wonder whether a button 'add row heading' 
would do, so a user can choose to either enter a plain row (with cells) 
or a row heading (one colspanned cell) below the current row?

> WINDOW SIZE
>
> 1. The Kupu editor space should adapt to the size of the browser 
> window (width does this already, height not). Nice to have.
>
I think I'm going to skip this, since I spent way too much time on it 
already. If some CSS guru knows how to fix this problem, please let me know.

Cheers,

Guido