[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: frame placement (in KWord)
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-11-12 1:03:55
[Download RAW message or body]

On Samedi 10 Novembre 2001 21:56, Thomas Zander wrote:
> > When Laurent and I first discussed this change, we talked about the 
> > "make frame inline" functionality (at least I assume we were talking about that ;).
> > When you right-click a frame and asks for "please make it inline", there is NO CURSOR
> > anywhere, since the frame is selected, and in KWord you have no cursor when you're
> > selecting frames. So you're whole discussion is a bit... useless (sorry). 
> > You can't suggest to "position the inline frame where the cursor is", since there's
> > no cursor ;-)
> 
> The discussion was about creation of content, not modifying it.

But consistency calls for the same solution to both problems IMHO.

> > The code used to try and do it automatically, by choosing the position of the closest
> > character (in frameset 0, but that should have been in the closest frame, and using 
> > z-order if necessary). The problem with that approach is that... it's quite hard
> > to move an inline frame that isn't where you want it. You have to cut and paste,
> > or drag and drop, both of which are more complex than what you need to do to
> > move a non-inline frame (click on it and drag it). 
> 
> Ehh,
> Select a table as text (by dragging the mouse over it so it becomes ghosted) and
> you can then click-drag it anyware you want.  (Might have to select a character
> before it as well, but thats a bug that can be fixed)
> Thats _easy_ and thats the way all text can be moved about in KDE (QT even)

Try this with a table that is higher than the visible portion of the document.
First you have to fight to select the table, because "drag over it" requires to first
position the cursor to the left of the table, then drag to the right,
then you have to fight to position the table where you want, because you don't
see where you're going, so you have to drag and use the auto-scroll feature
until the area where you want the table to be.
Obviously in such a case a smaller zoom level would greatly help but that's
not the point ;) The point is that moving around huge objects is cumbersome,
especially inline objects (because if you do it step by step the whole text reflows around
it, which doesn't happen with non-inline no-runaround frames)
and there's not much we can do about that.

> Simply not true, creation of non inline frames is always easy, as you say.
> Inline frames _only_ have a problem when there is no cursor. This will be when 
> the user just selected a frame and therefor went out of text-editing mode. (in
> other words pretty rare) Then you can auto place the frame in the first frame 
> on the page and top left, allowing the user to move it

This is indeed a completely different solution to this problem, which obviously
provides a working solution, but quite different. I don't care much either way,
but Laurent's way is coded and in CVS, which gives it a good advantage ;)
I'd rather see us move on to bugfixes and missing features, in the end that's
what counts much more than how the user does something, as long as he
can do it (feature being present), and in a reasonably easy way. I think the
"extra click when positioning an inline frame" isn't that much of a hassle...
but I haven't tested this with a real-world document yet.

> So you argue that for the cases where you use pretty advanced features of KWord
> the interface might not be so easy and therefor the interface for all placements
> should get an extra 'click' from the user.

And you argue that we should only think about the simple case, and not care
about the "advanced" case (making it hard for the advanced case) :)
[where "simple" and "advanced" can be non-inline vs inline, and/or small vs huge....]
But as I said, I don't care that much. I count on my future use of KWord for
providing more input on that - and on users, too ;)

> ps. you might want to check how people create frames with the current approuch, 
> about all people I watched creating a frame first placed it _very_ roughly how
> they wanted it and then moved/sized it to the final position Which IMO is natural.

I think you're talking about the DTP-like non-inline frames, and I agree for that
case. I don't think this applies to inline frames - and btw your idea of using
the current cursor position slightly contradicts the above "first positining roughly,
then moving" (there's nothing "rough" about the cursor position....)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/ , http://www.konqueror.org/
KDE 3.0: Konquering the Desktops
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]