program,
> I mean how would it be implemented from the point of view of the
user?
My current thoughts is that each bar can specify up to one bar that
is it to be locked to. You would specify at "lock-to" position on
the target bar, and you would specify and "lock-from" position on
the bar being configured. Positions are related to the top-left
corner of the bar and can be specified in absolute pixels or % or
bar size. I would also allow an offset pixels for the "lock-to"
position (needed when when you specify that position as a %).
So you could say:
- lock top left corner of my bar to top-right (0,100%) of lock-to bar
- lock left edge, middle (0, 50%) of my bar to right edge + 1
pixel, middle of target bar (100%+1, 50%), etc.
The bar you are configuring must have float or locked position; if
you specify another position, then the lock-to info would be ignored.
> of (a) how those bars would behave (for example when one of the
> group of bars is dragged, or when only one is hidden)
If the parent bar is hidden, so will any bars which are locked-to
it.
> and (b) what options would be offered about the feature
> and (c) whether any new pproconf dialog is needed, etc.
Yes, a new dialog is needed (to be opended from a button on the bar
properties). A new cl command is also needed to add locking info
dynamically.
>
> Here are some of the many questions raised by this idea:
>
> I presume that we could preserve the relative positions of
> a small subset of our bars? It would be useless if it had to
> include all of one's PowerPro bars moving in lock step.
Yes, by specifying different lock-to bar.
> Therefore we need the concept of a Group, which is a subset
> of the command lists.
I don't plan an explicit group, but it is implicit in the bars which
are locked together. Note that more than one bar can be locked to
a parent bar. Also note that bar A could be locked to bar b which
is in turn locked to bar c. I may have to add some loop-checking
code.
>> -- non-symmetrical means one bar is designated as the anchor and
> the others as followers, so the positions of bars 2 and 3 are
> defined relative to bar 1.
> If so you can only move the group by moving bar1.
Yes, this is what I plan.
> If so what happens when I drag bar3 -- does it snap back to its
> position relative to bar1 -- or does that action redefine bar3's
> position relative to bar1?
If you define position as locked (the existing PowerPro locked
postion), then you cannot move it. If it is float, then you can
move. Bar 3 won't snap back until you move bar1.
>
> -- or symmetrical, which means that none of the bars is designated
> as "master" or "anchor", so dragging any bar of the group
> means the others follow to preserve the arrangement.
No, this is not what I planned originally. The original plan was to
have a master bar which control movement and visibility of any bars
locked to it.
But on thinking about it, I suppose I could interpret a loop as
saying either bar is the master, ie if bar a is locked to bar b and
bar b is locked to bar a then this means that moving either one
moves the other. That would mean loops don't give an error message
but just cause the movement chain to stop. That may be a good idea.
>
> That question is involved in the next question: what happens
> when the user executes a Bar ToMouse command for bar3?
> I presume the others in the group would move too. But suppose
> that makes one or more of the group go partly off screen?
> Force the whole group unscreened automatically maybe?
It would follow the existing option on whether to force moved bars
on screen. The reason to keep it simple is that on screen depends
on whether you have multiple monitors, and I don't want to get into
actually checking the coordinates covered by multiple monitors.
>
> What happens if we issue a command: Bar Hide Bar1
> Would PowerPro hide the whole group?
> -- If yes, can I hide only one member of the group?
If you hide the master, the others will follow. You can hide the
others independently if they are not locked in a loop.
> A good solution to that problem: make a group's groupname
>
Sorry, but introducing a new concept like groups is too much work
because of all the side effect situation, some of which you list
(others would be how do you import and export groups? cl commands
to add to group and remove, etc).
The above approach gives many of the same benefits and is much
easier for me to implement; hence there is a good chance I will do
it.
Attention: PowerPro's Web site has moved: http://www.ppro.org
YAHOO! GROUPS LINKS
- Visit your group "power-pro" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
