Development discusion for 1.9: Multibuttons
1 view
Skip to first unread message
Tayedaen
Dec 3, 2007, 5:09:34 AM12/3/07
to develop_xub
Hi,
I am going to repost my comments her (already typo corrected), so that
the discussion can be read here on one place.
I am going to repost my comments her (already typo corrected), so that
the discussion can be read here on one place.
Message has been deleted
Tayedaen
Dec 3, 2007, 5:25:34 AM12/3/07
to develop_xub
Hi !
The big new feature of 1.9 will be 'Multibuttons'. That means:
Multiple clicks are possible.
For macros (and USE-Buttons), all clicks will just result in the same
action (eg. Macro started).
However if a macro use modifiers in it's code, then this should work
as intended in the future.
Both support for SHIFT/ALT/CTRL and multiple mouseclickes (left, right
middle, click4, click5) will be added.
However I am not sure about the UI yet.
My current plans are (MB=mousebutton, KB=Keyboardbutton):
MB-Ranked mode
============
CLICK rank
-------------------------------------
LeftClick max
RightClick rank 2
MiddleClick max rank/2 (will be changed, but that's not in the
code
yet)
all other clicks (button4, button 5 or any combination of shift, alt
ctrl etc.) will result in the same action as LeftClick.
KB-Ranked mode
============
CLICK rank
-------------------------------------
no modifier max
ALT player
SHIFT rank 1
all other clicks (incl all mousebuttons) will result in the same
action as no modifier.
MB-Target mode
============
CLICK destination
-------------------------------------
LeftClick frameunit
RightClick player
MiddleClick target
Button4Click focus
all other clicks (button5 or any combination of shift, alt ctrl etc.)
will result in the same action as LeftClick.
KB-Target mode
============
CLICK destination
-------------------------------------
no modifier frameunit
ALT player
SHIFT target
CTRL focus
all other clicks (incl all mousebuttons) will result in the same
action as no modifier.
Examples showing how ranking will be defined (can only be defined in
'Custom Buttons'):
CB_Renew1,buff,Renew,,Renew [eg. a standard
button]
CB_Renew2,buff,Renew,MB-Ranked,Renew
CB_Renew3,buff,Renew,KB-Ranked,Renew
CB_Macro1,macro,496,/cast [button:2,target=player] Renew; [help] Renew
Examples showing how targeting will be defined (can only be defined in
'Group Specifications'):
group1,CB_Renew,* [eg. a standard button]
group2,CB_Renew,MB-Target
group3,CB_Renew,KB-Target
group4,CB_Renew2,KB-Target
group5,CB_Renew3,MB-Target
A combination of both is possible (see group4 and group5).
Combining two of the same modfiers is allowed, but I think it makes no
sense ;)
The big new feature of 1.9 will be 'Multibuttons'. That means:
Multiple clicks are possible.
For macros (and USE-Buttons), all clicks will just result in the same
action (eg. Macro started).
However if a macro use modifiers in it's code, then this should work
as intended in the future.
Both support for SHIFT/ALT/CTRL and multiple mouseclickes (left, right
middle, click4, click5) will be added.
However I am not sure about the UI yet.
My current plans are (MB=mousebutton, KB=Keyboardbutton):
MB-Ranked mode
============
CLICK rank
-------------------------------------
LeftClick max
RightClick rank 2
MiddleClick max rank/2 (will be changed, but that's not in the
code
yet)
all other clicks (button4, button 5 or any combination of shift, alt
ctrl etc.) will result in the same action as LeftClick.
KB-Ranked mode
============
CLICK rank
-------------------------------------
no modifier max
ALT player
SHIFT rank 1
all other clicks (incl all mousebuttons) will result in the same
action as no modifier.
MB-Target mode
============
CLICK destination
-------------------------------------
LeftClick frameunit
RightClick player
MiddleClick target
Button4Click focus
all other clicks (button5 or any combination of shift, alt ctrl etc.)
will result in the same action as LeftClick.
KB-Target mode
============
CLICK destination
-------------------------------------
no modifier frameunit
ALT player
SHIFT target
CTRL focus
all other clicks (incl all mousebuttons) will result in the same
action as no modifier.
Examples showing how ranking will be defined (can only be defined in
'Custom Buttons'):
CB_Renew1,buff,Renew,,Renew [eg. a standard
button]
CB_Renew2,buff,Renew,MB-Ranked,Renew
CB_Renew3,buff,Renew,KB-Ranked,Renew
CB_Macro1,macro,496,/cast [button:2,target=player] Renew; [help] Renew
Examples showing how targeting will be defined (can only be defined in
'Group Specifications'):
group1,CB_Renew,* [eg. a standard button]
group2,CB_Renew,MB-Target
group3,CB_Renew,KB-Target
group4,CB_Renew2,KB-Target
group5,CB_Renew3,MB-Target
A combination of both is possible (see group4 and group5).
Combining two of the same modfiers is allowed, but I think it makes no
sense ;)
Tayedaen
Dec 3, 2007, 5:38:32 AM12/3/07
to develop_xub
Now to the discussion:
1) paladindorme wrote: I like rank -2 for Healing Per Mana and Rank
Max for Healing Per Sec.
Yes, Rank-2 is better then rank/2. So it's on the ToDo list.
2) CosmicCleric wrote: will the button assignments (ex.: Button4Click)
be redefinable? I use Button4Click for when I wish to talk on Vent/
VoIP for example.
Hmm. This is not easy, unless I would switch fomr premade to user
definable button clicking, see 3)
3) Paladindrome proposed an other way of defining the click behaviour:
"CB_Renew2,buff,Renew,Mouse[button:1 rank=Max][button:2 rank=-2]
[button:3 rank=-1],Renew"
Hmmmmm. While I really like the idea, I see at least two problems
here:
a) It's too complicated for the average user to set up, while adding
complexity (and parsing tends to take a lot of computing too)
b) The current state of XUB does not allow mixing rank defintions with
target definitions
4) Some users fear lag
Now lag is no problem witrh the changes I made.
First of all, the new code is in the XUB_MakeButtons, and is never
called OnUpdate.
Second, if you are NOT using the new features, then all it takes two
single IF, none of them beeing in the critical OnUpdate path.
Generally, I'd like you to test what I wrote, and please give me your
feedback then.
I want to have this discussion based on fact, not opinions ;-))))))))
I will post a new version later (when I've learned to manage SVN).
I used beta 3 in raid yesterday without problems.
cu
tay
1) paladindorme wrote: I like rank -2 for Healing Per Mana and Rank
Max for Healing Per Sec.
Yes, Rank-2 is better then rank/2. So it's on the ToDo list.
2) CosmicCleric wrote: will the button assignments (ex.: Button4Click)
be redefinable? I use Button4Click for when I wish to talk on Vent/
VoIP for example.
Hmm. This is not easy, unless I would switch fomr premade to user
definable button clicking, see 3)
3) Paladindrome proposed an other way of defining the click behaviour:
"CB_Renew2,buff,Renew,Mouse[button:1 rank=Max][button:2 rank=-2]
[button:3 rank=-1],Renew"
Hmmmmm. While I really like the idea, I see at least two problems
here:
a) It's too complicated for the average user to set up, while adding
complexity (and parsing tends to take a lot of computing too)
b) The current state of XUB does not allow mixing rank defintions with
target definitions
4) Some users fear lag
Now lag is no problem witrh the changes I made.
First of all, the new code is in the XUB_MakeButtons, and is never
called OnUpdate.
Second, if you are NOT using the new features, then all it takes two
single IF, none of them beeing in the critical OnUpdate path.
Generally, I'd like you to test what I wrote, and please give me your
feedback then.
I want to have this discussion based on fact, not opinions ;-))))))))
I will post a new version later (when I've learned to manage SVN).
I used beta 3 in raid yesterday without problems.
cu
tay
Tayedaen
Dec 3, 2007, 5:58:55 AM12/3/07
to develop_xub
Hi, since I am at work I just uploaded the latest version in the file
sarea, instaed of adding it to the svn.
I'll learn to SVN later ;-)
Paladindrome, could you please add my code to the repository ?
And: Happy testing !! ^^
cu
tay
sarea, instaed of adding it to the svn.
I'll learn to SVN later ;-)
Paladindrome, could you please add my code to the repository ?
And: Happy testing !! ^^
cu
tay
Cosmic Cleric
Dec 3, 2007, 1:08:30 PM12/3/07
to develop_xub
I mentioned this on another post here already, but I'll repeat it here
(heh wished I had read this subject first :p ).
First off, please don't judge me via my WoW UI Forums posts. Its a
pet-peave of mine when developers take the easy way out and try to
'document away' lazy programming, which I thought they were doing. A
fuctiion should always return a valid value, and not a sometimes
value. Maybe its my perspective coming from Java coding, where if
something goes wrong you throw an exception, otherwise you always
return a valid response to a method(function) call. But for that
function to return a nil sometimes in a valid way and sometimes in a
invalid way is bad programming, IMHO. Why bother returning a nil in
certain valid situations when it can return the same value in other
invalid situations? Anyways, enough of that rant. :)
Just so you know, I'm usually VERY good at judging things based on
experiencing something first (even experience from previous
experience), vs. just spouting opinions w/o any basis in
fact. ;-))))))))
Having said this, this is REALLY a show-killed for me. I NEED to have
my MOUSE4 button NOT be taken-over by XUB. I can't express this
enough. From what I was told, if my mouse pointer is over a XUB
button, then instead of my Ventrillo client talk being activated, I
will try to activate a XUB action (always, or only if I have a
floating frame?). This is really not acceptable to me. I would have
to branch XUB for my own purposes, or at the very least have to edit
each new version of XUB and remove the code.
One person's 'focus' frame target is another person's Ventrillo talk
button. :) I don't think its proper for any add-on to take control
exclusively of buttons, especially with mouse buttons. A click of a
mouse button with a pointer over something is always supposed to mean
actions on the item the mouse pointer is over, not an action on a
different item than what the mouse pointer is over. Its very counter-
intuitive, it seems to me.
As I mentioned in another post, don't we specify, via the GROUPS
script section, what target frame a button is associated with anyways
(ex.: prehealing,_PvPTrinket1,player)?
On Dec 3, 2:38 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> 2) CosmicCleric wrote: will the button assignments (ex.: Button4Click)
> be redefinable? I use Button4Click for when I wish to talk on Vent/
> VoIP for example.
> Hmm. This is not easy, unless I would switch fomr premade to user
> definable button clicking, see 3)
(heh wished I had read this subject first :p ).
First off, please don't judge me via my WoW UI Forums posts. Its a
pet-peave of mine when developers take the easy way out and try to
'document away' lazy programming, which I thought they were doing. A
fuctiion should always return a valid value, and not a sometimes
value. Maybe its my perspective coming from Java coding, where if
something goes wrong you throw an exception, otherwise you always
return a valid response to a method(function) call. But for that
function to return a nil sometimes in a valid way and sometimes in a
invalid way is bad programming, IMHO. Why bother returning a nil in
certain valid situations when it can return the same value in other
invalid situations? Anyways, enough of that rant. :)
Just so you know, I'm usually VERY good at judging things based on
experiencing something first (even experience from previous
experience), vs. just spouting opinions w/o any basis in
fact. ;-))))))))
Having said this, this is REALLY a show-killed for me. I NEED to have
my MOUSE4 button NOT be taken-over by XUB. I can't express this
enough. From what I was told, if my mouse pointer is over a XUB
button, then instead of my Ventrillo client talk being activated, I
will try to activate a XUB action (always, or only if I have a
floating frame?). This is really not acceptable to me. I would have
to branch XUB for my own purposes, or at the very least have to edit
each new version of XUB and remove the code.
One person's 'focus' frame target is another person's Ventrillo talk
button. :) I don't think its proper for any add-on to take control
exclusively of buttons, especially with mouse buttons. A click of a
mouse button with a pointer over something is always supposed to mean
actions on the item the mouse pointer is over, not an action on a
different item than what the mouse pointer is over. Its very counter-
intuitive, it seems to me.
As I mentioned in another post, don't we specify, via the GROUPS
script section, what target frame a button is associated with anyways
(ex.: prehealing,_PvPTrinket1,player)?
On Dec 3, 2:38 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> 2) CosmicCleric wrote: will the button assignments (ex.: Button4Click)
> be redefinable? I use Button4Click for when I wish to talk on Vent/
> VoIP for example.
> Hmm. This is not easy, unless I would switch fomr premade to user
> definable button clicking, see 3)
Tayedaen
Dec 3, 2007, 2:41:37 PM12/3/07
to develop_xub
> Having said this, this is REALLY a show-killed for me. I NEED to have
> my MOUSE4 button NOT be taken-over by XUB. I can't express this
> enough.
I understand you completely. But that does not necessarily mean I
> my MOUSE4 button NOT be taken-over by XUB. I can't express this
> enough.
agree ;-))))))))
> From what I was told, if my mouse pointer is over a XUB
> button, then instead of my Ventrillo client talk being activated, I
> will try to activate a XUB action (always, or only if I have a
> floating frame?).
If the button is not a custom button then the action triggered will be
the same as leftclick
> I don't think its proper for any add-on to take control
> exclusively of buttons, especially with mouse buttons. A click of a
> mouse button with a pointer over something is always supposed to mean
> actions on the item the mouse pointer is over
And now please replace "addon" in your sentence with "ventrilo" !!
Then you will see what I mean.
If you have your mouse over a button, then a mouseclick on this
button
MUST trigger an action for THIS button!
That is a very basic priciple of programming.
[ And what the action is does not matter here in this discussion. ]
Basically that means XUB is right, and your definition of a
mousebutton
as ventrilo trigger is the one thing causing problems here.
Please read what I wrote carefully.
I don't want to be missunderstood here.
You are perhaps the most important and most influencing user for this
addon, and highly estimate your input!
But you are asking for something that is against all principles of GUI
programming.
My goal is to write code that is valid and valuable for all users.
And I want to keep the spirit in which Elenesski wrote this addon in
the beginning.
Please try just for one day either to change your ventrilo button to
the keyboard,
or to keep your mose next to the button.
I personally do not use a button for Teamspeak at all, I use a voice
trigger. ;-))
NOW.
That said, I will keep thinking about a solution that satisfies both
our needs.
Cosmic Cleric
Dec 3, 2007, 5:53:37 PM12/3/07
to develop_xub
:( I'm sorry, but I literally CANNOT change my ventrillo button. In
PvP, its all about twitch and instant button mashing, it truly is. I
used to try to use the tilde "~" button, and I would fumble and miss
the button all the time, especially when I was being attacked and
calling out on Vent for help from my teammates (as a priest, this
happens allot::p ). The mouse4 button puts my "push to talk" right
next to my thumb, where I never miss, and after three years of using
this button for this action, its way too late for me to change it, as
well as even if I did, I would go back to not being able to talk
efficiently.
:(
PvP, its all about twitch and instant button mashing, it truly is. I
used to try to use the tilde "~" button, and I would fumble and miss
the button all the time, especially when I was being attacked and
calling out on Vent for help from my teammates (as a priest, this
happens allot::p ). The mouse4 button puts my "push to talk" right
next to my thumb, where I never miss, and after three years of using
this button for this action, its way too late for me to change it, as
well as even if I did, I would go back to not being able to talk
efficiently.
:(
Cosmic Cleric
Dec 3, 2007, 6:26:10 PM12/3/07
to develop_xub
Could we at least use the WoW key bindings and have the actions you
want to create for the floating bar assigned via these key bindings?
want to create for the floating bar assigned via these key bindings?
Cosmic Cleric
Dec 3, 2007, 6:31:28 PM12/3/07
to develop_xub
Er, couldn't help myself, have to post this as well. Hopefully it
won't cause more conflict, but I have to say this.
I believe you are incorrect in your presumptions on how buttons work
on GUIs.
A button is associated with a target, and how you click on the button
determines what action is done to the target of the button.
What you want is to have a button assigned to a floating frame that
selects different targets based on how you click on the button. That
is counter-intuitive to how buttons have been working on GUI's since
Windows 1.0.
For example, having a button choose which rank of a healing/casting
spell based on how you click on it, always applied to the same target,
is different than having a button associated with a target but a
different target is selected based on how you click on the button.
The former is how its always worked with GUIs, the latter is a
specific way of doing it for one application (XUB). Even WoW's
toolbars work the same way, the button is targeted at the item
selected in the target frame (unless its something that doesn't have a
a specific target like an AOE spell).
Anyway, my $0.02 worth.
won't cause more conflict, but I have to say this.
I believe you are incorrect in your presumptions on how buttons work
on GUIs.
A button is associated with a target, and how you click on the button
determines what action is done to the target of the button.
What you want is to have a button assigned to a floating frame that
selects different targets based on how you click on the button. That
is counter-intuitive to how buttons have been working on GUI's since
Windows 1.0.
For example, having a button choose which rank of a healing/casting
spell based on how you click on it, always applied to the same target,
is different than having a button associated with a target but a
different target is selected based on how you click on the button.
The former is how its always worked with GUIs, the latter is a
specific way of doing it for one application (XUB). Even WoW's
toolbars work the same way, the button is targeted at the item
selected in the target frame (unless its something that doesn't have a
a specific target like an AOE spell).
Anyway, my $0.02 worth.
Drome
Dec 3, 2007, 6:49:00 PM12/3/07
to develop_xub
I have created a new working branch for Tayedaen from the original
1.9B1 release. I have updated it to the 1.9b3 level (from the rar
file) and then branched it to create a 1.9b3 tagged. I have arranged
the repository:
* extreme-unit-buttons/
# CosmicCleric/
# Drome/
# Tayedaen/
# beta/
# 1.8rc3/
# 1.8rc4/
# 1.9b1/
# 1.9b3/
# release/
# 1.6/
# 1.7/
# 1.7.1/
# 1.7.3/
# 1.8/
# working/
* pitbull-frame-names/
# beta/
# release/
# working/
The Goal is to have each of us have a branch that we can work on - and
we merge into working when we feel it is stable. When we agree that a
beta, release or bug fix is available we branch and tag the tree. The
benefit is that we can see what any release looks like by syncing to
that branch in the tree. While I am sure that there were many
incremental changes between 1.6 and 1.9b3 the history is up here to
see - and it is relatively easy to get to any of the named versions.
I got command line svn working but a friend recommended Tortoise and
It is very easy. The quick steps are:
Go to http://code.google.com/p/extremeunitbuttons/source and generate
your password.
Download and install TortoiseSVN
Create an empty subdirectory IE wowaddons/XUB/Drome
Right click on the new Directory and select "SVN Checkout"
In the URL of the Repository enter the URL - using Drome from above:
https://extremeunitbuttons.googlecode.com/svn/extreme-unit-buttons/Drome
Press OK
Enter username and generated password in dialog box.
You are now linked in. When you make a change Right click on the
Directory and commit.
Do the same for Working and any other source tree you want to maintain
links too.
Drome
PS - Set a test directory to 1.6 and then do a diff between 1.6 and
1.9b3 - to get a feel for all the work Tay has done - I bet 80% of
1.9b3 is his work.
On Dec 3, 5:58 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> Paladindrome, could you please add my code to the repository ?
> tay
1.9B1 release. I have updated it to the 1.9b3 level (from the rar
file) and then branched it to create a 1.9b3 tagged. I have arranged
the repository:
* extreme-unit-buttons/
# CosmicCleric/
# Drome/
# Tayedaen/
# beta/
# 1.8rc3/
# 1.8rc4/
# 1.9b1/
# 1.9b3/
# release/
# 1.6/
# 1.7/
# 1.7.1/
# 1.7.3/
# 1.8/
# working/
* pitbull-frame-names/
# beta/
# release/
# working/
The Goal is to have each of us have a branch that we can work on - and
we merge into working when we feel it is stable. When we agree that a
beta, release or bug fix is available we branch and tag the tree. The
benefit is that we can see what any release looks like by syncing to
that branch in the tree. While I am sure that there were many
incremental changes between 1.6 and 1.9b3 the history is up here to
see - and it is relatively easy to get to any of the named versions.
I got command line svn working but a friend recommended Tortoise and
It is very easy. The quick steps are:
Go to http://code.google.com/p/extremeunitbuttons/source and generate
your password.
Download and install TortoiseSVN
Create an empty subdirectory IE wowaddons/XUB/Drome
Right click on the new Directory and select "SVN Checkout"
In the URL of the Repository enter the URL - using Drome from above:
https://extremeunitbuttons.googlecode.com/svn/extreme-unit-buttons/Drome
Press OK
Enter username and generated password in dialog box.
You are now linked in. When you make a change Right click on the
Directory and commit.
Do the same for Working and any other source tree you want to maintain
links too.
Drome
PS - Set a test directory to 1.6 and then do a diff between 1.6 and
1.9b3 - to get a feel for all the work Tay has done - I bet 80% of
1.9b3 is his work.
On Dec 3, 5:58 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> Paladindrome, could you please add my code to the repository ?
Drome
Dec 3, 2007, 7:32:52 PM12/3/07
to develop_xub
As I understand it the modified action will only work if you select a
rank of nB-RANKED in the button or a target of nB-TARGET in the
group. So it will be up to any user to determine if the button will
do something special. On the downside the selection is is all or
nothing for that button or group. So the only real issue is that CC
wont be able to enable MB-RANKED because he may cast a spell when he
talks to someone on vent.
A compromise would be to enable the buttons individually.
make the lines like
myButton:SetAttribute("*spell3", aSpellName ..
"(" .. RANK .. " " .. math.ceil((l_MaxSpellRank+1) / 2) .. ")" )
only set up based on conditions.
If (XUB_GLOBAL.ENABLE_MB_4) then myButton:SetAttribute("*spell3",
aSpellName .. "(" .. RANK .. " " .. math.ceil((l_MaxSpellRank+1) /
2) .. ")" ) end
Then CC can add the UI to set this Global Variable (note the move to
the repository).
I have not investigated enough to understand how "*spell3" works so I
may be all wet.
Drome
rank of nB-RANKED in the button or a target of nB-TARGET in the
group. So it will be up to any user to determine if the button will
do something special. On the downside the selection is is all or
nothing for that button or group. So the only real issue is that CC
wont be able to enable MB-RANKED because he may cast a spell when he
talks to someone on vent.
A compromise would be to enable the buttons individually.
make the lines like
myButton:SetAttribute("*spell3", aSpellName ..
"(" .. RANK .. " " .. math.ceil((l_MaxSpellRank+1) / 2) .. ")" )
only set up based on conditions.
If (XUB_GLOBAL.ENABLE_MB_4) then myButton:SetAttribute("*spell3",
aSpellName .. "(" .. RANK .. " " .. math.ceil((l_MaxSpellRank+1) /
2) .. ")" ) end
Then CC can add the UI to set this Global Variable (note the move to
the repository).
I have not investigated enough to understand how "*spell3" works so I
may be all wet.
Drome
Cosmic Cleric
Dec 3, 2007, 8:36:41 PM12/3/07
to develop_xub
Thats a good compromise, as long as XUB will not intercept the mouse4
button unless its configured to do so in the script.
I do still think we need to offer key bindings for all of the buttons
besides mouse left-click, instead of hard-coding it though. Its a
standard way that WoW add-ons use to allow the user to change default
values for actions.
I've never tried implementing them before, but from what I've read at
the WoW wiki it didn't see overly complicated to do?
button unless its configured to do so in the script.
I do still think we need to offer key bindings for all of the buttons
besides mouse left-click, instead of hard-coding it though. Its a
standard way that WoW add-ons use to allow the user to change default
values for actions.
I've never tried implementing them before, but from what I've read at
the WoW wiki it didn't see overly complicated to do?
Cosmic Cleric
Dec 3, 2007, 9:35:41 PM12/3/07
to develop_xub
I setup both TortoiseSVN and WinMerge, so am ready to go. Thank you
for the instructions on setup, they were nice to have (hate
reinventing the wheel).
I was curious what the "working" subfolder was for? Is that as in
"working as intended" or as "work in progress" or ? ??
> Go tohttp://code.google.com/p/extremeunitbuttons/sourceand generate
for the instructions on setup, they were nice to have (hate
reinventing the wheel).
I was curious what the "working" subfolder was for? Is that as in
"working as intended" or as "work in progress" or ? ??
Drome
Dec 4, 2007, 1:44:06 PM12/4/07
to develop_xub
Working is the main trunk. When you think you have something
worthwhile merge it with working then update working. The goal is
that your branch is something that you update frequently as you are
developing - I know I will use it to manage between my home machine
and my laptop. Working is a shared repository. When we want a beta
or release version we branch the working to create the beta or
release. so:
Drome CosmicCleric Tayedaen
\ ! /
\ ! /
\ | /
\ ! /
Working
|
Working ------------------- beta/1.9b3
|
Working -------------------- beta/1.9b1
|
Working -------------------- release/1.8
|
so on into the past
reality is a little more complex - each branch maintains it own
history.
worthwhile merge it with working then update working. The goal is
that your branch is something that you update frequently as you are
developing - I know I will use it to manage between my home machine
and my laptop. Working is a shared repository. When we want a beta
or release version we branch the working to create the beta or
release. so:
Drome CosmicCleric Tayedaen
\ ! /
\ ! /
\ | /
\ ! /
Working
|
Working ------------------- beta/1.9b3
|
Working -------------------- beta/1.9b1
|
Working -------------------- release/1.8
|
so on into the past
reality is a little more complex - each branch maintains it own
history.
Tayedaen
Dec 6, 2007, 8:02:56 AM12/6/07
to develop_xub
@Cosmic Cleric:
I completely understand what you are saying.
But I still think you did not see the whole problem yet.
@All:
Let's forget all about spells and targeting for a moment.
Let's assume there is no 'MB-RANKED' and no 'MB-TARGET'
No let's have a look at macros.
I've used a macro for several timse, found here:
http://borkweb.com/story/wow-priest-macros
I quote from there:
----------------------
/cast [target=targettarget, button:1] Greater Heal (Rank 1);
[target=targettarget, button:2] Power Word: Shield;
[target=targettarget, button:4] Flash Heal; [target=targettarget;
button:5] Greater Heal
----------------------
This macro usese button 4 and buton5.
Now let's say I want to embedd this macro in XUB.
What I need here is that all mousebuttons are transfered
to the macro.
This would result in the following code:
----------------------
myMacrotext = "/cast [target=targettarget, button:1] Greater Heal
(Rank 1); [target=targettarget, button:2] Power Word: Shield;
[target=targettarget, button:4] Flash Heal; [target=targettarget;
button:5] Greater Heal"
myButton:RegisterForClicks("AnyUp");
myButton:SetAttribute('type','macro');
myButton:SetAttribute('*macrotext*', myMacroText );
----------------------
Now in XUB, the user has the right to define freely what
his button should do.
And some users want to trigger XUB actions with mousebutton 4.
To enable this, I need to transfer ALL button clicks to the macro.
That means: To enable this feature, I am NOT ALLOWED to block any
clicks.
That's the main reason why I am so insisting on this.
It' not about multiranking or even multitargeting.
It's simply: Allow the users to define what they want.
Transfer a buttonclick to the button, and let the button decide
what he wants to do with this click.
By blocking mousebutton 4 I would block a lot of reasonable buttons.
So please try it out only _one_ _single_ day.
Change either your ventrilo to use some keyboard button, or
change ventrilo to voice activation, oder simply keep your mouse
next to the button.
Please try to this for one single day.
Sometimes it's better to get rid of old habits to gain a
newer and better future.
Try to adjust instead of trying to limit the features of XUB.
It's important for me that you understand my motivation here.
I want to improve XUB, by user request.
See here:
http://www.wowinterface.com/downloads/fileinfo.php?id=6794&so=&page=3
I completely understand what you are saying.
But I still think you did not see the whole problem yet.
@All:
Let's forget all about spells and targeting for a moment.
Let's assume there is no 'MB-RANKED' and no 'MB-TARGET'
No let's have a look at macros.
I've used a macro for several timse, found here:
http://borkweb.com/story/wow-priest-macros
I quote from there:
----------------------
/cast [target=targettarget, button:1] Greater Heal (Rank 1);
[target=targettarget, button:2] Power Word: Shield;
[target=targettarget, button:4] Flash Heal; [target=targettarget;
button:5] Greater Heal
----------------------
This macro usese button 4 and buton5.
Now let's say I want to embedd this macro in XUB.
What I need here is that all mousebuttons are transfered
to the macro.
This would result in the following code:
----------------------
myMacrotext = "/cast [target=targettarget, button:1] Greater Heal
(Rank 1); [target=targettarget, button:2] Power Word: Shield;
[target=targettarget, button:4] Flash Heal; [target=targettarget;
button:5] Greater Heal"
myButton:RegisterForClicks("AnyUp");
myButton:SetAttribute('type','macro');
myButton:SetAttribute('*macrotext*', myMacroText );
----------------------
Now in XUB, the user has the right to define freely what
his button should do.
And some users want to trigger XUB actions with mousebutton 4.
To enable this, I need to transfer ALL button clicks to the macro.
That means: To enable this feature, I am NOT ALLOWED to block any
clicks.
That's the main reason why I am so insisting on this.
It' not about multiranking or even multitargeting.
It's simply: Allow the users to define what they want.
Transfer a buttonclick to the button, and let the button decide
what he wants to do with this click.
By blocking mousebutton 4 I would block a lot of reasonable buttons.
So please try it out only _one_ _single_ day.
Change either your ventrilo to use some keyboard button, or
change ventrilo to voice activation, oder simply keep your mouse
next to the button.
Please try to this for one single day.
Sometimes it's better to get rid of old habits to gain a
newer and better future.
Try to adjust instead of trying to limit the features of XUB.
It's important for me that you understand my motivation here.
I want to improve XUB, by user request.
See here:
http://www.wowinterface.com/downloads/fileinfo.php?id=6794&so=&page=3
Reply all
Reply to author
Forward
0 new messages