http://dcplusplus.sourceforge.net/wiki/ ... ?version=2
some (i.e. Opera and possibly me as well) argue that it needs a Supports
but unless a Supports command is implemented soon, I'll do without.
please comment on the above rfc
UserCommand command
Moderator: Moderators
UserCommand command
Last edited by Sedulus on 2003-08-17 07:56, edited 1 time in total.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
-
- Posts: 506
- Joined: 2003-01-03 07:33
i think i was against $UserCommands last time it was discussed so i better be consistent with my earlier belifs. ;))
First, usercommands is today visible in two frames (atleast my own mod), in the search-frame and the userlist-frame (when i think about it i have it in the filetransfer-frame aswell). Maybe it should be a good idea to seperate these sort of commands as they usualy are junk in the other frames. The problem with this is that the protocol suggestion and change becomes totaly dominated by one client DC++ as other clients might have different approach to how its gui works. I very much dislike changes in protocol which is devoted to one and only one client. Ok the $Support is a way to get around this, but hmm.. well... bit then maybee call it DC++UserCommand as the suggestion will be very DC++-specific.
This comment will be more towards why and how instead of the comments to the protocol.
Most usercommands which is not OP-related will end up in the wrong frame, thats atleast my oppinion. usercommands such that +help should probably be add into the main-hubframe (where the chat is displayed, and we only have copy-paste etc today).
OPs on the other hand often ties its usercommand to different typ of reg/kick/ban/redirect etc, and then maybee we could have options for this aswell and not only mainchat/pm. Ok, your suggestion was to add raw-support, but i don't think thats a good idea. When you kick for example you want to make sure that you have not already kicked that user (this will often be the case when you kick alot in the searchframe) as dc++ does for the kick-command.
and then we get into what the client should do with the usercommands recived, but thats another question.
i would love to see how it works on a couple of hubs for some quasi-common users.
i-will-not-use-it-and-be-against-it-but-that-doesn't-mean-its-a-bad-thing-to-impliment-ly'ers.
First, usercommands is today visible in two frames (atleast my own mod), in the search-frame and the userlist-frame (when i think about it i have it in the filetransfer-frame aswell). Maybe it should be a good idea to seperate these sort of commands as they usualy are junk in the other frames. The problem with this is that the protocol suggestion and change becomes totaly dominated by one client DC++ as other clients might have different approach to how its gui works. I very much dislike changes in protocol which is devoted to one and only one client. Ok the $Support is a way to get around this, but hmm.. well... bit then maybee call it DC++UserCommand as the suggestion will be very DC++-specific.
This comment will be more towards why and how instead of the comments to the protocol.
Most usercommands which is not OP-related will end up in the wrong frame, thats atleast my oppinion. usercommands such that +help should probably be add into the main-hubframe (where the chat is displayed, and we only have copy-paste etc today).
OPs on the other hand often ties its usercommand to different typ of reg/kick/ban/redirect etc, and then maybee we could have options for this aswell and not only mainchat/pm. Ok, your suggestion was to add raw-support, but i don't think thats a good idea. When you kick for example you want to make sure that you have not already kicked that user (this will often be the case when you kick alot in the searchframe) as dc++ does for the kick-command.
and then we get into what the client should do with the usercommands recived, but thats another question.
i would love to see how it works on a couple of hubs for some quasi-common users.
i-will-not-use-it-and-be-against-it-but-that-doesn't-mean-its-a-bad-thing-to-impliment-ly'ers.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
of course the %[mynick], %[file], %[nick], etc, etc, will have to be standardized. afaik only dc++ has usercommands atm, and the setup is quite clean imo, so I don't think there are any problems with standardizing those.ivulfusbar wrote:First, usercommands is today visible in two frames (atleast my own mod), in the search-frame and the userlist-frame (when i think about it i have it in the filetransfer-frame aswell). Maybe it should be a good idea to seperate these sort of commands as they usualy are junk in the other frames.
[snip=dc++specificness]
adding options to get the commands in the correct frame is not a good thing ("other clients might have different [...] gui"). I think it would be both easier and better to let the client decide where to put the commands.
i.e. it uses %[file]? -> we only use/add it in/to frames that support the file variable
please don't ;)ivulfusbar wrote:DC++UserCommand
true, I have nothing against adding usercommands to mainframe (copy-paste exists in oDC, not in regular dc++ :P )ivulfusbar wrote:usercommands such that +help should probably be add into the main-hubframe (where the chat is displayed, and we only have copy-paste etc today).
ah, I see what you mean, although I personally don't have problems with sending garbage to the hub if one can't remember who you just kicked. but wouldn't this easily be solved if you remove all commands that use %[nick]?ivulfusbar wrote:your suggestion was to add raw-support, but i don't think thats a good idea. When you kick for example you want to make sure that you have not already kicked that user (this will often be the case when you kick alot in the searchframe) as dc++ does for the kick-command.
aren't there any better arguments against raw commands?
(currently dc++ removes all usercommands except those that do not specify a specific hub or 'op' along with kick/redir for offline users)
I'd say add them (while connected) to the specific hub, unless the user has turned the automatically-fetch-usercommands option off. we could add them to a frame and such so everyone could enable/disable specific items, but I feel that it would be more bloat than useful as I think hubowners know what their OPs want/need (and users usually shouldn't get more than perhaps a +rules and +help)ivulfusbar wrote:and then we get into what the client should do with the usercommands recived, but thats another question.
(simply showing the usercommands on request through mainframe text would be sufficient, I think)
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
Sedulus, a couple of questions about the UserCommands.
1. The automatically-fetch-usercommands option, when will that be implemented? I believe users should have the option to choose if they should recieve these commands or not, since they are pretty invasive, and most users won't have any idea what is going on when suddenly commands appear in their menu.
2. In the wiki, only contexts 1, 2 and 4 are present. Are there more? I seem to be seeing 3 being used in Gadget's scripts, or don't they have any use? The link to version 2 seems to be faulty as well, but perhaps i'm looking at an old version.
3. "$UserCommand 255 7" doesn't seem to be erasing all commands. Actually 255 doesn't seem to do nothing, no matter what context you use. Am i understanding something wrong? The wiki is somewhat confusing in places.. However, i did notice that all commands disappear when you disconnect from the hub. Bug or feature?
That's it from me, keep up the good work =)
1. The automatically-fetch-usercommands option, when will that be implemented? I believe users should have the option to choose if they should recieve these commands or not, since they are pretty invasive, and most users won't have any idea what is going on when suddenly commands appear in their menu.
2. In the wiki, only contexts 1, 2 and 4 are present. Are there more? I seem to be seeing 3 being used in Gadget's scripts, or don't they have any use? The link to version 2 seems to be faulty as well, but perhaps i'm looking at an old version.
3. "$UserCommand 255 7" doesn't seem to be erasing all commands. Actually 255 doesn't seem to do nothing, no matter what context you use. Am i understanding something wrong? The wiki is somewhat confusing in places.. However, i did notice that all commands disappear when you disconnect from the hub. Bug or feature?
That's it from me, keep up the good work =)
there is no such option at the moment. either you code one yourself and submit a patch, or you'll have to say pretty please to some developer.Todi wrote:1. The automatically-fetch-usercommands option, when will that be implemented? I believe users should have the option to choose if they should recieve these commands or not, since they are pretty invasive, and most users won't have any idea what is going on when suddenly commands appear in their menu.
3 == 1 | 2, they are ORed together. that means they will be used both in the 1 and in the 2 context.Todi wrote:2. In the wiki, only contexts 1, 2 and 4 are present. Are there more? I seem to be seeing 3 being used in Gadget's scripts, or don't they have any use? The link to version 2 seems to be faulty as well, but perhaps i'm looking at an old version.
faulty link: yes.. that should be plain http://dcplusplus.sourceforge.net/wiki/ ... %20command
255: yes.. this is not implemented in dc++ yetTodi wrote:3. "$UserCommand 255 7" doesn't seem to be erasing all commands. Actually 255 doesn't seem to do nothing, no matter what context you use. Am i understanding something wrong? The wiki is somewhat confusing in places.. However, i did notice that all commands disappear when you disconnect from the hub. Bug or feature?
disappearing commands: yes, this is a feature, or rather, expected behaviour. else you could have UserCommands from one hub in another, which is plain useless.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
I'm trying to learn darnit 'cause i'm not good at begging. Just sit tight for a couple of years, and it shall be done.Sedulus wrote:there is no such option at the moment. either you code one yourself and submit a patch, or you'll have to say pretty please to some developer.
Aaaah.. that explains a lot of things actually... thank you for clearing that up =)Sedulus wrote:3 == 1 | 2, they are ORed together. that means they will be used both in the 1 and in the 2 context.
That explains that too =) Thank you for taking the time to answer Sedulus.Sedulus wrote:255: yes.. this is not implemented in dc++ yet
disappearing commands: yes, this is a feature, or rather, expected behaviour. else you could have UserCommands from one hub in another, which is plain useless.
*sighs*.. I better hurry up learning.. because arne doesn't seem happy with the $Usercommand or something.. since he put in the new feature "Send once to nick" (raw-nick-limited) in DC++ 0.302 and Sedulus updated the $Usercommand wiki with the exact same feature.. but DC++ still doesn't support either that, or the 255. You want me to beg? I'll beg.. pleeease combine your efforts...