RFE for a function to return all channel objects for channels with a given name

RESOLVED FIXED

Status

Other Applications
ChatZilla
--
enhancement
RESOLVED FIXED
17 years ago
11 years ago

People

(Reporter: jwatt, Assigned: Robert Ginda)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cz-0.9.76])

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5) Gecko/20011011
BuildID:    20011011

This bug is an RFE for a function that would obtain the channel object
corresponding to a channel name specified after a command typed by a user. The
need for this function stems from the fact that chatzilla supports simultanious
connections to multiple hosts, therefore a user can potentially be connected to
more than one channel with the same name on different hosts. This makes the code
for selecting the most likely channel is several lines long, and due to the fact
that many commands such as the /part /topic /invite /kick /mode /ban and /hop
commands all potentially allow the user to specify a channel after the command,
it seems to make sense to create a function for this rather than repeating the
code in the functions handling all these commands. The format of these commands is: 

/part #channel
/topic #channel newtopic
/invite nickname #channel
/kick #channel nickname
/mode #channel|nickname [[+|-]modechars [parameters]]
/ban [#channel] <nickname|address> [type]
/hop [-c] [#channel] [message]

Where #channel in the case of Chatzilla can of course be a URL. 

In my opinion when trying to determine the object for the channel the user
intended the behaviour of the function should be as follows: 

1) Look for the channel on the host of the current view and return its object if
found assuming that if channels with the same name exist on other hosts the user
meant the channel on the host of the current view. 
2) If the channel is not found on the host of the current view look for the
channel on all other hosts and return all matches (reason for this below). 

My suggested code for this function is as follows: 

// getChannels() returns an array of channel objects who's 
// name(s) match the channel name passed to the function. 

function getChannels (channelName)
{
    var channels = [];
    var o = getObjectDetails(client.currentObject);
    var c = o.server.channels[channelName];
    if (c) channels.push(c);
    else {
        for (var network in client.networks) {
            if (client.networks[network].isConnected()) {
                var c = client.networks[network].primServ.channels[channelName];
                if (c) channels.push(c);
            }
        }
    }
    return channels;
}

The code calling this function can then check the length property of the
returned array and decide on what to do with the objects from there. If only one
channel object is returned then that is of course the channel the user intends
for use with the command. If more than one channel with the specified name is
found then most likely the user should be informed that they should use a URL to
specify the channel they mean, but by returning all the channel objects this
leaves options open. 

Reproducible: Didn't try
(Assignee)

Comment 1

17 years ago
I'll put something similar to this in 0.8.5
Status: NEW → ASSIGNED
Depends on: 103386
(Assignee)

Comment 2

17 years ago
Here is what I propose to add...

array client.getMatchingChannels(name);

Only exact matches are returned.  This may include channels which the user is no
longer a member of.  Clients may check the state of channel.joined to determine
whether or not the channel is active.  If no channels are found, an array of
length 0 is returned.

onJoin, onPart, and onKick (in irc.js) will need to be changed to keep track of
the channel.joined state.  This function could be modified in the future to
accept regexps, if there is a reason for it.
(Reporter)

Comment 3

17 years ago
As this method will return all matches across all hosts, could we have a
property added to the array so that a quick test can be made to see if a channel
was found on the host of the current view? Something like this:

function getMatchingChannels (channelName)
{
    var channels = [];
    var s = getObjectDetails(client.currentObject).server;
    var c = s.channels[channelName];
    if (c) {
        channels.push(c);
        channels.matchOnCurrentHost = true;
    }
    else {
        channels.matchOnCurrentHost = false;
    }
    for (var network in client.networks) {
        if (client.networks[network].isConnected()) {
            // you don't want the same object in the array twice so:
            if (s = client.networks[network].primServ) continue;

            var c = client.networks[network].primServ.channels[channelName];
            if (c) channels.push(c);
        }
    }
    return channels;
}

We would then be able to quickly tell if a channel had been found on the host of
the current view and that it would be the first object in the array if found. 

(Assignee)

Comment 4

17 years ago
How about a .mostLikely property on the returned array.  If one of the channels
w efind is part of the network associated with the current view, then that
channel is mostLikely, failing that, the first channel in the tab list that
matches is mostLikely, failing that, the first match, and if all else fails,
mostLikely is null.

If the calling function is only interested in a single, most likely match, this
would make things very simple.
(Reporter)

Comment 5

17 years ago
That would be cool too. But I would like a quick way of specifically checking if
a match was found on the current host. 

I'm just throwing ideas around here, but how about properties for .currentHost,
.firstTab, etc where the default value of these properties is -1, and if a match
is found then they take the index of the element of the array that contains the
relivant channel object? We could still have a mostLikely property as well?
(Assignee)

Comment 6

17 years ago
I'm worried about making getMatchingChannels do too much.  Why do you care if it
is on the current host?  What are you going to do if it is not?  Why does
getMatchingChannels need to do this, instead of the code that calls it?
(Reporter)

Comment 7

17 years ago
Sure, I see what you mean. My reasoning is that if the user is on one channel
and they specify to /part /hop or whatever another channel then they probably
mean the channel with that name on network of the current view. Any channels
with the same name on another host can be ignored. 

Failing this they must mean a channel on another network they are connected to.
As I see it the best thing is then to check for all possible channels with this
name. If there is only one then that is the one they meant and actions should
continue as normal on this channel. If there is more than one they should be
informed that they should have used an irc url instead only a channel name. 

The main point though is that I would select the channel on the host of the
current view first and therefore it is good to be able to easily tell quickly if
one was found. 

As an after thought maybe I think it would be better to check in this order:

1) current host
2) on tabs
3) on all hosts
(Assignee)

Comment 8

17 years ago
pushing past 0.8.5
No longer depends on: 103386

Comment 9

16 years ago
Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(
QA Contact: mozilla → samuel
Product: Core → Other Applications

Comment 10

12 years ago
Do we actually need/want this still? I personally really want to vote WONTFIX on this one (or perhaps WORKSFORME based on whatever we do for tabcompletion these days).

Comment 11

12 years ago
http://lxr.mozilla.org/seamonkey/source/extensions/irc/js/lib/irc.js#786
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

11 years ago
Whiteboard: [cz-0.9.76]
You need to log in before you can comment on or make changes to this bug.