Summary: | When resizing some objects sticky borders do not work | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | Andrew Walker <arwalker> |
Component: | general | Assignee: | kst |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Proposed patch |
Description
Andrew Walker
2006-05-25 20:54:34 UTC
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 |