|
@@ -708,18 +708,6 @@ message. It contains the name that the server supplied for itself
|
708
|
708
|
identifies itself as `node3.uk.irc.example.com`), and the nickname
|
709
|
709
|
that the server says we are using.
|
710
|
710
|
|
711
|
|
-==== ServerFeaturesUpdated
|
712
|
|
-* Type: IrcEvent
|
713
|
|
-* Properties:
|
714
|
|
-** `serverFeatures`: `ServerFeatureMap` - the features supplied by the server
|
715
|
|
-
|
716
|
|
-Corresponds to the server sending a single 005 ISUPPORT line. Multiple
|
717
|
|
-events of this type may be raised in quick succession when features are
|
718
|
|
-split over multiple lines.
|
719
|
|
-
|
720
|
|
-In general, you should wait for a <<ServerReady>> event and then query the
|
721
|
|
-<<Features>> instead of relying on this event.
|
722
|
|
-
|
723
|
711
|
==== ServerReady
|
724
|
712
|
* Type: IrcEvent
|
725
|
713
|
* Properties: _(none)_
|
|
@@ -744,55 +732,160 @@ channels, will be reset when disconnected from the server. State should not
|
744
|
732
|
be queried until a new <<ServerReady>> event has been received, at which
|
745
|
733
|
point it will have been recreated.
|
746
|
734
|
|
747
|
|
-==== ServerCapabilitiesReceived
|
748
|
|
-
|
749
|
|
-TODO
|
750
|
|
-
|
751
|
|
-==== ServerCapabilitiesAcknowledged
|
752
|
|
-
|
753
|
|
-TODO
|
754
|
|
-
|
755
|
|
-==== ServerCapabilitiesFinished
|
756
|
|
-
|
757
|
|
-TODO
|
758
|
|
-
|
759
|
735
|
==== MotdLineReceived
|
|
736
|
+* Type: IrcEvent
|
|
737
|
+* Properties:
|
|
738
|
+** `line`: `String` - the line of the message of the day that was received
|
|
739
|
+** `first`: `Boolean` - true if the line is the first one received
|
760
|
740
|
|
761
|
|
-TODO
|
|
741
|
+The MotdLineReceived event is raised whenever the server sends a single
|
|
742
|
+line of its Message of the Day. The `first` parameter is set on the
|
|
743
|
+first line of the MOTD so that special formatting or UI handling can
|
|
744
|
+be applied. When the MOTD is finished, a <<MotdFinished>> event is raised.
|
762
|
745
|
|
763
|
746
|
==== MotdFinished
|
|
747
|
+* Type: IrcEvent
|
|
748
|
+* Properties:
|
|
749
|
+** `missing`: `Boolean` - indicates the MOTD was missing
|
764
|
750
|
|
765
|
|
-TODO
|
|
751
|
+This event occurs in two circumstances: when the server has sent a
|
|
752
|
+series of <<MotdLineReceived>> events and has reached the end of the
|
|
753
|
+Message of the Day; or when the server has no MOTD to send and
|
|
754
|
+informs the client that the MOTD is missing.
|
766
|
755
|
|
767
|
756
|
=== Channel events
|
768
|
757
|
|
|
758
|
+NOTE: Many events such as <<MessageReceived>> apply to both channels and
|
|
759
|
+users. These are documented in the <<Channel/User events>> category.
|
|
760
|
+
|
769
|
761
|
==== ChannelJoined
|
|
762
|
+* Type: IrcEvent, TargetedEvent, SourcedEvent, ChannelMembershipAdjustment
|
|
763
|
+* Properties:
|
|
764
|
+** `user`: `User` - the user that joined the channel
|
|
765
|
+** `target`: `String` - the channel that was joined
|
770
|
766
|
|
771
|
|
-TODO
|
|
767
|
+Raised whenever a user joins a channel, including the KtIrc client. You
|
|
768
|
+can determine whether the join applies to another user or the local client
|
|
769
|
+using the <<isLocalClient>> utility method.
|
772
|
770
|
|
773
|
|
-==== ChannelJoinFailed
|
|
771
|
+When the local client joins a new channel, this event will typically be
|
|
772
|
+followed by one or more <<ChannelNamesReceived>> events, then
|
|
773
|
+<<ChannelNamesFinished>>, <<ChannelTopicDiscovered>> and if the
|
|
774
|
+`requestModesOnJoin` <<Behaviour>> is enabled a <<ModeChanged>> event.
|
774
|
775
|
|
775
|
|
-TODO
|
|
776
|
+==== ChannelJoinFailed
|
|
777
|
+* Type: IrcEvent, TargetedEvent
|
|
778
|
+* Properties:
|
|
779
|
+** `target`: `String` - the channel that we tried to join
|
|
780
|
+** `reason`: `JoinError` - the error that prevented us from joining
|
|
781
|
+
|
|
782
|
+The ChannelJoinFailed event is raised when we attempt to join a channel
|
|
783
|
+but the server doesn't allow us to do so. The reason parameter enumerates
|
|
784
|
+the possible problems:
|
|
785
|
+
|
|
786
|
+* `TooManyChannels` - we are already in the maximum number of channels allowed
|
|
787
|
+ by the server.
|
|
788
|
+* `NoHiding` - the channel is no-hiding (+H), but we have invisible join/parts
|
|
789
|
+ enabled.
|
|
790
|
+* `NeedKey` - the channel is keyed (+k) and a valid key was not provided
|
|
791
|
+* `NeedInvite` - the channel is invite only (+i) and no invite was received.
|
|
792
|
+* `NeedRegisteredNick` - the channel is limited to registered users only, and we
|
|
793
|
+ are not registered.
|
|
794
|
+* `NeedTls` - the channel is secure-only, and we're not using TLS.
|
|
795
|
+* `NeedAdmin` - the channel is limited to server admins and we are not one.
|
|
796
|
+* `NeedOper` - the channel is limited to ircops and we are not one.
|
|
797
|
+* `Banned` - we are banned from the channel.
|
|
798
|
+* `ChannelFull` - the channel is limited (+l) and currently full.
|
|
799
|
+* `BadChannelName` - the channel name is disallowed by the server.
|
|
800
|
+* `Throttled` - we're trying to joiin too many channels and have been throttled.
|
|
801
|
+* `Unknown` - we don't know why.
|
|
802
|
+
|
|
803
|
+[WARNING]
|
|
804
|
+====
|
|
805
|
+ChannelJoinFailed events are generated on a _best-effort_ basis by KtIrc. Error
|
|
806
|
+handling on IRC is very poorly standardised, and varies wildly between server
|
|
807
|
+implementations. For example, trying to join a secure-only channel on an
|
|
808
|
+ircd-seven server will send a NOTICE to the user instead of an error response,
|
|
809
|
+so no `ChannelJoinFailed` event will be raised.
|
|
810
|
+
|
|
811
|
+When tracking whether a join suceeded or failed you should combine monitoring
|
|
812
|
+for the response with a reasonable timeout, and assume failure if the timeout
|
|
813
|
+lapses without a <<ChannelJoined>> or <<ChannelJoinFailed>> event occurring.
|
|
814
|
+====
|
776
|
815
|
|
777
|
816
|
==== ChannelParted
|
|
817
|
+* Type: IrcEvent, TargetedEvent, SourcedEvent, ChannelMembershipAdjustment
|
|
818
|
+* Properties:
|
|
819
|
+** `user`: `User` - the user that parted the channel
|
|
820
|
+** `target`: `String` - the channel that was parted
|
|
821
|
+** `reason`: `String` - the user-supplied reason for parting
|
778
|
822
|
|
779
|
|
-TODO
|
|
823
|
+Raised when any user parts a channel that we are on. Users can supply a reason
|
|
824
|
+when parting a channel; if they have done so the `reason` property will be
|
|
825
|
+non-empty.
|
780
|
826
|
|
781
|
827
|
==== ChannelUserKicked
|
|
828
|
+* Type: IrcEvent, TargetedEvent, SourcedEvent, ChannelMembershipAdjustment
|
|
829
|
+* Properties:
|
|
830
|
+** `user`: `User` - the user that performed the kick
|
|
831
|
+** `victim`: `String` - the nickname of the user that was kicked
|
|
832
|
+** `target`: `String` - the channel that the victim was kicked from
|
|
833
|
+** `reason`: `String` - the user-supplied reason for kicking
|
782
|
834
|
|
783
|
|
-TODO
|
|
835
|
+This event occurs when a user is kicked (forcibly removed) from a channel.
|
|
836
|
+
|
|
837
|
+NOTE: The `user` is the one performing the kick, and will remain in the
|
|
838
|
+channel. The `victim` is the one being forcibly ejected.
|
784
|
839
|
|
785
|
840
|
==== ChannelQuit
|
|
841
|
+* Type: IrcEvent, TargetedEvent, SourcedEvent, ChannelMembershipAdjustment
|
|
842
|
+* Properties:
|
|
843
|
+** `user`: `User` - the user that quit
|
|
844
|
+** `target`: `String` - the channel that the user was in
|
|
845
|
+** `reason`: `String` - the user-supplied reason for quitting
|
786
|
846
|
|
787
|
|
-TODO
|
|
847
|
+After a <<UserQuit>> event, KtIrc will "fan out" the event to all of the
|
|
848
|
+channels that we share with the user and raise a `ChannelQuit` event for
|
|
849
|
+each channel. This is designed to make implementing certain features easier;
|
|
850
|
+if you fully handle a UserQuit event there is no need to also handle the
|
|
851
|
+ChannelQuit events, and vice-versa.
|
|
852
|
+
|
|
853
|
+Users and servers can supply a reason when a user quits; if supplied then
|
|
854
|
+the `reason` parameter will be non-empty.
|
788
|
855
|
|
789
|
856
|
==== ChannelNickChanged
|
|
857
|
+* Type: IrcEvent, TargetedEvent, SourcedEvent, ChannelMembershipAdjustment
|
|
858
|
+* Properties:
|
|
859
|
+** `user`: `User` - the user who has changed their nickname
|
|
860
|
+** `target`: `String` - the channel that the user is in
|
|
861
|
+** `newNick`: `String` - the user's new nickname
|
790
|
862
|
|
791
|
|
-TODO
|
|
863
|
+After a <<UserNickChanged>> event, KtIrc will "fan out" the event to
|
|
864
|
+all of the channels that we share with the user and raise a `ChannelNickChanged`
|
|
865
|
+event for each channel. This is designed to make implementing certain features
|
|
866
|
+easier; if you fully handle a UserNickChanged event there is no need to also
|
|
867
|
+handle the ChannelNickChanged events, and vice-versa.
|
|
868
|
+
|
|
869
|
+TIP: The user property will contain the user's old details, but you will
|
|
870
|
+not be able to access additional information from the <<UserState>> using
|
|
871
|
+these details as KtIrc will have internally renamed the user to use the
|
|
872
|
+new nickname.
|
792
|
873
|
|
793
|
874
|
==== ChannelNamesReceived
|
|
875
|
+* Type: IrcEvent, TargetedEvent
|
|
876
|
+* Properties:
|
|
877
|
+** `target`: `String` - the channel that the user is in
|
|
878
|
+** `names`: `List<String>` - the partial list of names that are in the channel
|
794
|
879
|
|
795
|
|
-TODO
|
|
880
|
+When we join a channel (or manually request it) the IRC server sends the
|
|
881
|
+list of channel members in a sequence of NAMES messages. KtIrc raises a
|
|
882
|
+`ChannelNamesReceived` event for each of these messages.
|
|
883
|
+
|
|
884
|
+WARNING: The given names may not be a complete list of members of the channel,
|
|
885
|
+as more names could follow. The format of the names varies between IRC servers
|
|
886
|
+and depending on the IRCv3 <<Capabilities>> that KtIrc negotiated. Most
|
|
887
|
+implementations should simply wait for <<ChannelNamesFinished>> and then request
|
|
888
|
+the complete list of names from KtIrc's <<ChannelState>>.
|
796
|
889
|
|
797
|
890
|
==== ChannelNamesFinished
|
798
|
891
|
|
|
@@ -866,6 +959,30 @@ TODO
|
866
|
959
|
Raised when the IRC server sends a PING message to the client. KtIrc will
|
867
|
960
|
automatically reply with an appropriate PONG.
|
868
|
961
|
|
|
962
|
+==== ServerFeaturesUpdated
|
|
963
|
+* Type: IrcEvent
|
|
964
|
+* Properties:
|
|
965
|
+** `serverFeatures`: `ServerFeatureMap` - the features supplied by the server
|
|
966
|
+
|
|
967
|
+Corresponds to the server sending a single 005 ISUPPORT line. Multiple
|
|
968
|
+events of this type may be raised in quick succession when features are
|
|
969
|
+split over multiple lines.
|
|
970
|
+
|
|
971
|
+In general, you should wait for a <<ServerReady>> event and then query the
|
|
972
|
+<<Features>> instead of relying on this event.
|
|
973
|
+
|
|
974
|
+==== ServerCapabilitiesReceived
|
|
975
|
+
|
|
976
|
+TODO
|
|
977
|
+
|
|
978
|
+==== ServerCapabilitiesAcknowledged
|
|
979
|
+
|
|
980
|
+TODO
|
|
981
|
+
|
|
982
|
+==== ServerCapabilitiesFinished
|
|
983
|
+
|
|
984
|
+TODO
|
|
985
|
+
|
869
|
986
|
==== AuthenticationMessage
|
870
|
987
|
|
871
|
988
|
TODO
|
|
@@ -902,6 +1019,10 @@ TODO
|
902
|
1019
|
|
903
|
1020
|
TODO
|
904
|
1021
|
|
|
1022
|
+=== isLocalClient
|
|
1023
|
+
|
|
1024
|
+TODO
|
|
1025
|
+
|
905
|
1026
|
== IRCv3 support
|
906
|
1027
|
|
907
|
1028
|
TODO
|