Can we* prettyplease do something about the KUrlNavigator?

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Jun 19 20:02:57 BST 2009


Thomas Lübking wrote:
> Am Friday 19 June 2009 schrieb Matthew Woehlke:
>>> The (real) lineedit will stay until it looses the focus.
>>> As you'd still have to click twice to enter a specific position within
>>> the line (as it is ratm) one could use the ctrl modifier as kind of
>>> "brain i/o extension" but that's still rather hidden and would remain a
>>> "pro" feature then...
>> How would that work? It seems like it would be hard to get it working
>> well, but could be a solution.
> The switch would happen on the mousepress event.
> 
> - If you click on some "empty" space in the (visually lineediting) 
> KUrlNavigator, it re-enters the lineedit mode.
> 
> - Also regardles the position if you have some modifier (in doubt: ctrl) down.
> 
> - If cou click a crumb (already indicated by hovering) it remains in the 
> breadcrumb mode and simply handles the click (change path or open popup).

To be clear, the point is I don't see this as useful unless I am able to 
pre-position the caret with a single click. (And even then, not sure how 
selection would work.)

The ideal would be to be able to switch from breadcrumb to edit mode 
without the text moving... but don't know how you would manage that. Or 
alternatively the control would have to switch on mouseover, but even 
that isn't ideal.

> I'd see two remaining questions/issues:
> 1.
> what to do if the widget looses the focus because the window lost it's active 
> state?
> a) drop focus and return to breadcrumb mode
> b) keep focus. when the window is reactivated (w/o instant focus change 
> because of clicking a strong focus widget) the lineedit mode auto-reactivates.
> 
> to me b) sounds more natural.

+1

> 2.
> how to handle the initial cursor position?
> a) present line as it has been before (on init: 1st char starts on pixel 0) 
> and move the caret to the clicked pixel
> b) move the caret to the appropriate position in the text path (i.e. 
> translated from the breadcrumb position that differs due to a possibly 
> incomplete path and the triangle delimiters) and ensure it's visible
> 
> again, i'm in favor of b), but one could probably argue a lot on this one.

As above, yes, but drag selection becomes... "interesting" in this case.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"The spiraling shape will make you go insane!" -- They Might Be Giants





More information about the kde-core-devel mailing list