> If I add the ability to specify bars should maintain relative
> positions, you may be able to come close by creating two bars locked
> beside each other (if I implement it, the relative positioning will
> react to expanding active bars).
That would be great. As well as adding needed flexibility to
"active plus tray" bars, it also opens more gui design possibilities:
by "docking" one bar to another of the same width or height, seemingly
one bar could have different sections with different properties.
For example a single column vertical bar could be headed by a
horizontal row of small buttons.
It would also fix the complaint that vertical bars cannot have
more than one column.
Before jumping into the programming,
it seems to me that idea requires careful consideration of what to program,
I mean how would it be implemented from the point of view of the user?
A few people have written that it would be a useful thing to have,
(much more useful than zooming icons for example) and I agree.
Unlike zooming icons, I would definitely use a feature where
a chosen subset of my bars kept a fixed relative arrangement.
But I wonder if all the "yes please" people have the same vision
of (a) how those bars would behave (for example when one of the
group of bars is dragged, or when only one is hidden)
and (b) what options would be offered about the feature
and (c) whether any new pproconf dialog is needed, etc.
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.
Therefore we need the concept of a Group, which is a subset
of the command lists.
If so can we have more than one group?
If so, maybe it would be easiest for the user if each Bar Group
has a user defined group name.
Would a group seem to be symmetrical or hierarchic?
-- 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.
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?
-- 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.
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?
In the non-symmetrical idea, if bar1 goes accidentally goes
entirely off screen, you can't drag it, so the user would
have to execute Bar ToMouse bar1, or something.
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 no, then I would have to issue three Bar Hide commands
together, and similarly three bar Show commands would be needed.
A good solution to that problem: make a group's groupname
acceptable as an argument in any Bar command where you would
normally use a command list name.
Such as: Bar Hide mygroupname
[hides bar1 and bar2 and bar3]
How do you create a new group?
You could make a "New Bar Group" dialog where the user names the
group, picks its members from a dropdown of command list names,
and maybe checks a few options about the group's properties.
But I don't think such a dialog is essential.
Instead we could define a group's members and the relative positions
by the snapshot method:
The user arranges bar1 bar2 and bar3 as desired by manual dragging,
also hides any bars which are not part of this group, then tells
PowerPro that this is a new group.
I guess that could be done via a button in the pproconf's
Command Lists dialog which says "New bar group".
Actually pproconf's dialogs could get in the way, so instead
of making a new button in pproconf, you could just make a new
command: Bar NewGroup mygroupname
The user runs it from a hotkey, or menu item, or button,
after making a manual arrangement.
If the user executes Bar NewGroup or bar.newgroup without any argument
then a small dialog would ask for the new group name.
Bar.newgroup(groupname) could also be run from a script - usually
after the script has made an arrangement of the member bars.
A bar.hideall command would be handy for such scripts
so you don't have to change the script whenever you invent more bars:
bar.hideall
bar.show("bar1")
bar.show("bar2")
win.move("bar1",x,y)
win.move("bar2",x,y)
bar.newgroup("mygroup")
Thus people could do it by numbers if they prefer that to doing
it wysiwyg style by dragging before executing bar.newgroup
It would be handy to have user defined names for groups
so you can have the command: Bar Ungroup mygroupname.
Without an Ungroup command, it would not be possible to
rearrange them manually for a fresh snapshot.
What happens if the user forgets a group name? Stuck?
You could make a command: Bar UngroupAll
which dismantles all groups, to rescue us from that situation.
---------------------------------------------------------
I guess it would have no problems mixed with subbars?
If bar1 keeps changing height depending on which of its subbars
is currently shown, then bar2 which is "docked" to the bottom
of bar1 would move down accordingly. Maybe that is no more difficult
for you to deal with than active bars which also change size dynamically.
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.
