(*** This bug was imported into bugs.kde.org ***) Package: kword Version: KDE 3.0.5 CVS/CVSup/Snapshot Severity: normal Installed from: Compiled sources Compiler: gcc 2.95.3 OS: Linux OS/Compiler notes: Not Specified Using tables in kword is extremely inconvenient. Especially: - It's difficult to set the style options for the complete table. You have to apply settings for each single table cell. - TAB key does not advance to the next table cell instead a TAB space is inserted. This is unexpected behaviour for people using Star Office or Open Office (or any other office suite) - changing width and height of rows and columns is difficult. You cannot drag row or column borders like you can in other office suites. - selecting the whole table or complete rows or complete columns or just any set of columns is inconvenient. You have to shift-click into the columns to select them instead of clicking into a starting cell and then extending the selection by simply hovering the mouse across the cells. Again see Star Office for reference. - selecting table cells by keyboard is not conveniently possible. I noticed when I tried to write a bill. Usually takes about five minutes with Star Office but nearly 15 minutes with kword just because the handling of tables is so complicated. (Submitted via bugs.kde.org)
Agreed on (almost) all points; my implementation ideas were to get the basi= cs=20 working correctly first. Now they do (almost) better usability is create= d. I am (eagerly) awaiting a table styles implementation and laurent just made= a=20 table-sizing dialog. I am not entirely sure that tab is a good idea for KWord table navigation; - I want to be able to use a tab in a table-cell. - shift-tab is unknown to many many people and arrow up is so a lo more=20 intuitive if you found arrow down. - we use arrow down/up for this kind of navigation. After some time its a = lot=20 more convenient. But I am eager for more feedback on this..
On Friday 10 May 2002 23:45 Thomas Zander wrote: > Agreed on (almost) all points; my implementation ideas were to get the > basics working correctly first. Now they do (almost) better usability is > created. > > I am (eagerly) awaiting a table styles implementation and laurent just made > a table-sizing dialog. A dialog? What about in-place sizing? > I am not entirely sure that tab is a good idea for KWord table navigation; > - I want to be able to use a tab in a table-cell. Mhm maybe split the table cell instead? > - shift-tab is unknown to many many people and arrow up is so a lo more > intuitive if you found arrow down. Well people are used to navigate with tab/shift-tab if they ever used Star Office Open Office or Microsoft Word. > - we use arrow down/up for this kind of navigation. After some time its a > lot more convenient. Not if you want to navigate fast. With arrow keys you have to first navigate within the cell changing cells only if you navigate beyond the content of the cell. This is a lot slower. regards matze
I am in agreement with matze@stud.fbi.fh-darmstadt.de. It is necessary to improve the use of the tables. I believe that at the moment it is difficult to use the tables. antonio.crevillen@hispalinux.es
I agree too. The current tables in kword (1.2.1) is really hard to use.
Subject: koffice/kword CVS commit by goutte: Add tabulator navigation in tables. (Tab for cell right, Shift-Tab for cell left) (The replacement key for a real tabulator is normally Control-Tab, but as it is used in KDE, any combinaison with Control-Tab will do. I recommend using Alt-Control-Tab.) CCMAIL:61039-close@bugs.kde.org CCMAIL:41752@bugs.kde.org M +22 -3 kwtableframeset.cc 1.250 --- koffice/kword/kwtableframeset.cc #1.249:1.250 @@ -2636,4 +2636,5 @@ void KWTableFrameSetEdit::keyPressEvent( KWTableFrameSet::Cell *fs = 0L; + bool tab=false; // No tab key pressed if(moveToOtherCell) { @@ -2685,8 +2686,13 @@ void KWTableFrameSetEdit::keyPressEvent( } break; + case QKeyEvent::Key_Backtab: + tab=true; + if (e->state() & QKeyEvent::ControlButton) + break; // Break if tab was pressed with Control (in *any* key combination) + // Do not break case QKeyEvent::Key_Left: { KoTextCursor *cur = (static_cast<KWTextFrameSetEdit *>(m_currentCell))->cursor(); - if(!cur->parag()->prev()&&cur->index()==0) + if ( tab || (!cur->parag()->prev()&&cur->index()==0) ) { KWTableFrameSet* tableFrame=tableFrameSet(); @@ -2710,8 +2716,13 @@ void KWTableFrameSetEdit::keyPressEvent( } break; + case QKeyEvent::Key_Tab: + tab=true; + if (e->state() & QKeyEvent::ControlButton) + break; // Break if tab was pressed with Control (in *any* key combination) + // Do not break case QKeyEvent::Key_Right: { KoTextCursor *cur = (static_cast<KWTextFrameSetEdit *>(m_currentCell))->cursor(); - if(!cur->parag()->next()&&cur->index()==cur->parag()->string()->length()-1) + if( tab || (!cur->parag()->next()&&cur->index()==cur->parag()->string()->length()-1) ) { KWTableFrameSet* tableFrame=tableFrameSet(); @@ -2745,5 +2756,13 @@ void KWTableFrameSetEdit::keyPressEvent( { if ( !textframeSet->textObject()->protectContent() ) + { + if (tab && (e->state() & QKeyEvent::ControlButton) ) + { + QKeyEvent event(QEvent::KeyPress, QKeyEvent::Key_Tab, 9, 0, QChar(9)); + m_currentCell->keyPressEvent( &event ); + } + else m_currentCell->keyPressEvent( e ); + } else KMessageBox::information(0L, i18n("Read-only content cannot be changed. No modifications will be accepted."));
I would like to suggest to place newly created tables in a textframe by default. This makes tables much easier to resize and drag around the page. It also removes the need for the 'place the cursor to where you want to insert the table' method of placing new tables, which I think is far too restrictive with respect to where the user can place a new table. New tables should be placed exacly like new text frames: Drag a rectangle with your mouse.
> I would like to suggest to place newly created tables in a textframe by default. You have that option, just uncheck the 'The table is inline' when creating a table.
Yes, I found that option, but it does not really work as expected. I drag a rectangle with the mouse, but I get a table that is much bigger than the square I was drawing. The table fills the entire width of the document. Also, I can't see the frameborder that encloses the table, so I can't resize the thing and I can only move the table vertically.
By the way, I forgot to mention that I am talking about the current KOffice 1.3 Beta 4.
Created attachment 5644 [details] described patch
On Wednesday 14 April 2004 21:40, Ken Deeter wrote: > --> (http://bugs.kde.org/attachment.cgi?id=5644&action=view) > described patch konsole ?? Wrong bug number?
Comment on attachment 5644 [details] described patch oops sorry wrong bug
Just about all these issues are solved in 1.5 Not that I will claim tables are perfect now ;)
I don't think this bug is fixed completely (in kword 1.6.3), selection of cells is still bothersome and the main operating modes should pretty much offer/allow the type of user interaction that other WP's offer in the same context. At least full table, column, row selection should be very easy (single mouse click in the right location, indicated by a mousecursor change). Cheers Simon