Version: HEAD (using KDE KDE 3.5.0) Installed from: Compiled From Sources OS: Linux PROBLEM: When resizing objects the borders should snap to the borders of other objects, but this does not always happen. STEPS TO REPRODUCE: Start kst Create three rectangles in the default window Layout the rectangles such that two of the rectangles are children of the third and siblings of each other Resize one of the children rectangles RESULTS: The rectangle being resized does not snap to the borders of its sibling during the resize EXPECTED RESULTS: The rectangle being resized should snap to the borders of its sibling during the resize
Created attachment 16290 [details] Proposed patch
This is blocked for the same reason that the previous one will be reverted again. View related UI does not belong in the view objects themselves.
I'm confused by this statement. The view objects, by design, handle their own dialogs. What is it that this patch does that should be avoided. Andrew argued that different view objects will have different sticky rules (which is correct). How should this be implemented? On Friday 26 May 2006 18:40, George Staikos wrote: [bugs.kde.org quoted mail]
I have yet to see one that will have different rules, and I've seen magnetic borders implementations in several places in the past. None of them required changes anywhere except in the workspace manager. If the plan is to make non-edges magnetic, I think it's a bad idea. It's already difficult to use Kst with those active in many cases, I find. The magnetic borders are also completely unrelated to dialogs or anything else in the layout interface. That's specifically what KstTopLevelView is. What was in KstTopLevelView before was fine. Piling more into KstViewObject is not what I want to see. It's already turning into a big mess.
SVN commit 549222 by arwalker: BUG:127536,128033 Correctly handle snapping to child objects when moving and resizing. M +92 -79 ksttoplevelview.cpp M +2 -0 ksttoplevelview.h