Bug 115136 - Concept of flow for objects
Summary: Concept of flow for objects
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: view objects (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: HI major
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-26 19:21 UTC by George Staikos
Modified: 2010-08-14 14:40 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (3.51 KB, patch)
2006-06-17 00:40 UTC, Andrew Walker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description George Staikos 2005-10-26 19:21:14 UTC
View objects need a new concept which I describe as "flow".  Cleanup layout  
and alignment, for instance, both should act only on a certain subset of  
objects.  I think these are the same subset too - presently plots.  View  
objects should have a boolean flag that can be queried to determine if an  
object followsFlow() and only then should they be used for flow-related  
operation.  This will give a performance boost and cleanup the code for 
gridding and aligning.
Comment 1 Stéphane Gourichon 2005-12-29 15:00:36 UTC
Can you explain a bit more ? Attach a (even fake) screenshot ?
Comment 2 George Staikos 2005-12-29 18:02:24 UTC
On Thursday 29 December 2005 09:00, StXXphane Gourichon wrote:
> ------- Can you explain a bit more ? Attach a (even fake) screenshot ?


   The important thing, to start, is that "cleanup" will only cleanup objects 
like plots.  They will go onto a grid, whereas non-plots (lines, labels) 
which are at the top level will just float or stay where they are.  I don't 
have a screenshot right now.
Comment 3 Netterfield 2006-01-26 05:24:43 UTC
Is this done?
Comment 4 George Staikos 2006-01-26 05:43:14 UTC
No
Comment 5 Andrew Walker 2006-01-26 19:45:53 UTC
Should be fixed for 1.2.1 release
Comment 6 Nicolas Brisset 2006-03-29 13:01:53 UTC
I think it is a good idea to layout only plot objects and not top-level objects (like labels), better anyway than what is done right now. However, I don't see how we can avoid covering some plots with the top-level floating objects (which will result in user complaints), unless we implement the "flow-around" part of bug #109430. 
In the discussion attached to bug #109430, George mentioned that there is no clear concept as to how this could be done. Maybe I have missed some issues, but to me it does not sound utterly complicated to maintain a list of objects with the "flow-around" property set, and determine the area available to layout plots as the biggest interior rectangle. "Cleanup layout" would only use this area, thus avoiding interference with objects that the users may have put on the sides...

Note that this is a very important request for me, as many people here complain that they cannot easily add extra information in their windows while preserving all the nice layouting functionality kst offers.
Comment 7 Netterfield 2006-06-17 00:02:55 UTC
view objects currently have a followsFlow method which cleanup() uses to decide if an object should be moved or not.

Currently labels and plots seems to set followsFlow and everthing else does not.

I propose that the following objects follow flow:
  -2dplots
  -non-transparent labels with autoresizefortext not set

everything else should not follow flow.
Comment 8 Andrew Walker 2006-06-17 00:40:49 UTC
Created attachment 16648 [details]
Proposed patch

Implements flow for plots and non-transpraent non-auto-resize labels, as
proposed by Barth.
Comment 9 George Staikos 2006-06-17 00:58:40 UTC
Looks good to me.
Comment 10 Netterfield 2006-06-17 00:59:02 UTC
Upon consideration, perhaps metaplots and boxes might want to flow.

Would it be useful to have flow settable in the dialog for certain objects?
Comment 11 Netterfield 2006-06-17 01:49:22 UTC
After discussion on the list, and more thinking I change my suggestion to:
-change nothing except whether certain objects follow flow.
-plots, meta plots, and boxes follow flow.

Nothing else does.

If you want a legend or label to follow flow, put it in a box.

Don't change any of the class structure.

flip/flop/flip/flop... sigh...
Comment 12 Andrew Walker 2006-06-17 02:00:49 UTC
In which case no changes are required. Can this be withdrawn then?
Comment 13 Netterfield 2006-06-17 02:16:53 UTC
Right now labels also follow flow... I guess that they shouldn't.
Comment 14 Andrew Walker 2006-06-17 02:45:38 UTC
SVN commit 552215 by arwalker:

BUG:115136 Do not have labels follow flow

 M  +0 -2      kstviewlabel.cpp  


--- trunk/extragear/graphics/kst/src/libkstapp/kstviewlabel.cpp #552214:552215
@@ -59,7 +59,6 @@
 : KstBorderedViewObject("Label") {
   _fallThroughTransparency = false;
   _container = false;
-  setFollowsFlow(true);
   _dataPrecision = 8;
   _autoResize = false; // avoid madness
   _txt = txt;
@@ -84,7 +83,6 @@
   // some defaults and invariants
   _fallThroughTransparency = false;
   _container = false;
-  setFollowsFlow(true);
   _type = "Label";
   _dataPrecision = 8;
   _autoResize = false; // avoid madness
Comment 15 Nicolas Brisset 2006-06-19 14:30:42 UTC
So, how can one create say a box at the bottom of the page to put some textual information, and prevent it from covering/being covered by plots when cleaning up the layout ?
Maybe there are two different notions here: followsFlow() to say it should be moved when relayouting and borderObject() (or smth of the kind) to say plots or other view objects should not cover that object (basically, they would be "pinned on top" and determine areas where cleanup layout can't put anything). We could add a checkbox in the UI for such objects, and try to find a simple enough algorithm to determine the useful plotting area (in the simplest case, the interior rectangle as explained above, and it would be up to the user to make sure that he does not put such objects in the middle).
Should I open a separate report for this as I don't think the current functionality allows it ? I could also post screenshots of what I expect to be able to do easily...
Comment 16 Peter Kümmel 2010-08-14 14:40:47 UTC
Change version to 1.x