Chat interface modifications

[ttlanhil]

new version on berlios (linky)

changes: ctrl+ pageup/pagedn now cycle through just the real tabs, not 'history' and 'channels'

#jc #lc and @@name now check against the list (which is a step forward for localisation and configurability)

note: if the length of the string of numerals is longer than the string of the name (for example, "guild" is shorter than "1000000216"), then it's unchanged. if it turns out that it's safe to make the string longer, then this check can be removed

 

ed: oh yes, and these functions work even if you have a space in the name. yes, something like `@@gen help message goes here` works if the client knows the name 'gen help' is channel 2

 

known bugs: @@name while in console seems to not get called, and I can't find out why. the same data goes through the same function with different results.

maybe someone can have a look and figure out why?

the problem seems to be in gamewin.c:

else if ( ( input_text_line.data[0] == '@' ) && ( input_text_line.data[1] == '@' ) && ( input_text_line.data[2] != ' ' ) )

if it's coming from map or main window, the code inside gets called. if coming from console, it doesn't

note: this isn't a crash causing bug, it'll just pass on the name to the server, which probably doesn't know it

Edited January 5, 2006 by ttlanhil

[Vegar]

May I ask what this is supposed to do?

-	if (use_windowed_chat == 1)
-		display_tab_bar ();
-	else if (use_windowed_chat == 2)
+	if (use_windowed_chat == 2)
		display_chat ();
+	LOG_TO_CONSOLE(c_blue1, "This is a _Custom_Client_. Date of CVS and the patch numbers can be found in #ver");

Edited January 5, 2006 by Vegar

[ttlanhil]

May I ask what this is supposed to do?

well you can probably guess that the last line was a mistake. that's from back in the days when we were allowed to give out custom clients.

 

the other change is because the tab bar is drawn in console and in main window, hence it has a parent window of -1 and has to be dealt with a little differently

 

that's what I get for mixing alcohol and C

 

thanks for that, I'll fix it now

Edited January 5, 2006 by ttlanhil

[crusadingknight]

snprintf(fname, sizeof(fname), "./languages/%s/strings/channels.txt", lang);

*coughuseunixdatadircough*

Edited January 5, 2006 by crusadingknight

[ttlanhil]

snprintf(fname, sizeof(fname), "./languages/%s/strings/channels.txt", lang);

*coughuseunixdatadircough*

okay, fixed

[Vegar]

snprintf(fname, sizeof(fname), "%s/languages/%s/strings/channels.txt", datadir, lang);

is not working on win32 systems

and where are you free()ing this?

+		||((entry->description = malloc(strlen(desc))) == NULL)
+		||((entry->name = malloc(strlen(name))) == NULL)){

 

 

in tab_special_click()

+						for(;step->next != NULL;++listlen){
+							step = step->next;
+						}

wouldn't it be easier to use chan_name_queue->elements instead of counting the nodes?

Edited January 5, 2006 by Vegar

[ttlanhil]

snprintf(fname, sizeof(fname), "%s/languages/%s/strings/channels.txt", datadir, lang);

is not working on win32 systems

grumble. it works on mine, but then I have ` #data_dir="./" ` in my el.ini... that should be the default when on windows, then we can do away with all those #ifdefs each time you wanna use datadir (until such time as we actually use the users' home dir on WinNT, anyway)

and where are you free()ing this?

+		||((entry->description = malloc(strlen(desc))) == NULL)
+		||((entry->name = malloc(strlen(name))) == NULL)){

I'm not, that queue is for the duration. it could be free()'ed when the client closes for completeness, I guess.

currently you can't remove/rename entries in the queue, but I don't really see a need for it. should we have a GUI interface that allows us to add/remove/rename channels and their descriptions, then working with that memory will start to matter

[crusadingknight]

OK, I wrote the parsing functions, and built them a little source file. (This is just so you can use them however you want... I don't really know that much about your patch, though I *think* parse_channels() can replace init_channel_names(), but I'm not positive.) I can add WRITE_XML support later, if necessary.

 

Source file: http://www.rootshell.be/~bremac/dist/patches/channelparse.c

[Lachesis]

CK, I think it would be sufficient to add two buttons on the chat window.

Optionally disablable? I can only open up two channels as it is... the third still overflows. Two more buttons will be messy.

Buttons, not tabs

[ttlanhil]

new version on berlios now, made chan_target_name() a bit cleaner and got rid of a bug

 

merp. I have some other code to remove from the patch. then I'll look at CK's stuff

[Vegar]

I'm not, that queue is for the duration. it could be free()'ed when the client closes for completeness, I guess.

Can you do that? It pollutes elmemory.log and makes it harder to track down memory leaks.

[ttlanhil]

OK, I wrote the parsing functions, and built them a little source file. (This is just so you can use them however you want... I don't really know that much about your patch, though I *think* parse_channels() can replace init_channel_names(), but I'm not positive.) I can add WRITE_XML support later, if necessary.

would it be much hassle to have the pseudo channels and the real channels inside different nodes?

eg:

<channels>

<labels>

<channel name="server">server messages</channel>

</labels>

<realchans>

<channel number=1 name="newbie">Newbie help</channel>

</realchans>

</channels>

 

(no, I'm not an XML-versed person )

 

that might help a little in forcing the pseudo ones to be in the right order... other option is that the pseudo ones have a number as well, which corresponds to where in the index the client expects it to be... which might be a better option anyway

then there'll be two functions to add the channel, depending if it's real or not. from there, the patch can be adusted to have 2 queues instead of the one (which is likely to be a bit more efficient)

[Vegar]

Does the patch depend on getting the channels in some predefined order?

[crusadingknight]

would it be much hassle to have the pseudo channels and the real channels inside different nodes?

eg:

<channels>

<labels>

<channel name="server">server messages</channel>

</labels>

<realchans>

<channel number=1 name="newbie">Newbie help</channel>

</realchans>

</channels>

 

that might help a little in forcing the pseudo ones to be in the right order... other option is that the pseudo ones have a number as well, which corresponds to where in the index the client expects it to be... which might be a better option anyway

then there'll be two functions to add the channel, depending if it's real or not. from there, the patch can be adusted to have 2 queues instead of the one (which is likely to be a bit more efficient)

 

Actually, with the pseudo-channels, why not just use an array, since there's a constant number of them? I agree that numbering the pseudo-channels is a better option, anyway. Once you get that part of the patch done, it can be separated into different nodes. Of course, for self-documenting purposes, it doesn't make sense to call them both "channel".

Edited January 5, 2006 by crusadingknight

[ttlanhil]

Actually, with the pseudo-channels, why not just use an array, since there's a constant number of them? I agree that numbering the pseudo-channels is a better option, anyway.

works for me. it's easier if they stay the same order, so that'd be, in order:

Channel %d
Guild
View All
None
Channels
History
Local
PMs
GMs
Server
Mod

Once you get that part of the patch done, it can be separated into different nodes. Of course, for self-documenting purposes, it doesn't make sense to call them both "channel".

well, you're writing the part that cares about the name anyway, so feel free to use the most descriptive term you can think of

All that I have left to do is adusting it to use an array and the queue, then mixing in your stuff. only real change there is having it able to parse the pseudo ones then then real ones, I doubt that'd take long to change for someone who's used to the XML stuff

[crusadingknight]

To add them to the array, just use the pseudo-channel number as the array element number. That way, there's no need to read/write them in order.

[ttlanhil]

To add them to the array, just use the pseudo-channel number as the array element number. That way, there's no need to read/write them in order.

good point, I can make the XML file and put the right numbers in then

[ttlanhil]

okay, I checked a couple of times to make sure... it took very little to make it use an array and the queue... either I missed stuff that didn't show up during testing, or I did a better job of modularisation than I thought

just need the XML loading code for the two-section setup, then merge that in, convert the plain text file I have to XML, and it's done (well, and more testing/review, of course ^_^ )

 

ooh yes, and:

I'm not, that queue is for the duration. it could be free()'ed when the client closes for completeness, I guess.

Can you do that? It pollutes elmemory.log and makes it harder to track down memory leaks.

will do

 

Does the patch depend on getting the channels in some predefined order?

currently half-yes, but once the XML stuff is done it won't matter (as long as the normal and special channels aren't mixed up)

right now you have to have the 'special' ones in order, after that it doesn't matter, that's because stuff like 'all' doesn't have a channel number

Edited January 5, 2006 by ttlanhil

[ttlanhil]

hokay. it now works(*). it uses an XML file and all

 

the main patch is still here

the patch for the languages rep (the /en/ part at least) is here

and the channels.xml file is here (please remember to view source before copying if your browser wants to render the XML, which it probably will)

this file goes in ./languages/en/strings/

 

notes:

there are 2 known bugs.

@@name doesn't work in console, and I can't find why

 

[16:55:50] Found an unexpected node type while parsing ./languages/en/strings/channels.xml.
Last message repeated 39 times

I checked, and the node type it thinks it sees is 'text'. and there's exactly 40 lines of XML

editing the list, adding and removing entries is all manual. if you don't like the list, you edit the .xml yourself. there's potential for a gui for editing this stuff at some later stage, but it's not critical

Edited January 6, 2006 by ttlanhil

[ttlanhil]

oh, and one of the admin should really go over the list of channels, to see if there's anything that shouldn't be included, anything that isn't and should, anything that needs to be renamed, etc etc

[Placid]

I got some funny behaviour with scrolling on first use. The original layout looks slightly messy, then once scrolled, the channels list becomes somthing like the following:

Mod

 

 

 

 

Newbie

Market

Gen. Chat

Roleplay

etc

-------------

Explanation here

 

Any ideas?

[ttlanhil]

I got some funny behaviour with scrolling on first use. The original layout looks slightly messy, then once scrolled, the channels list becomes somthing like the following:

Mod

 

 

 

 

Newbie

Market

Gen. Chat

Roleplay

etc

-------------

Explanation here

 

Any ideas?

 

hmm... looks like I didn't check if the list is too short. this'll happen when the list isn't found (which I guess I didn't test enough)

back to work. joy

 

 

okay, that's fixed. and while I was at it I found a cool side-effect: channels you #jc are added to the drop-down list. problem is, the scrollbar wasn't adusted for length when this happened(and you'd only see it when the list was really short, ie the generic list).

oh well, another improvement (now the scrollbar will allow you to see them as well... added channels just go on the end of the list, they're not sorted in any way)

Edited January 6, 2006 by ttlanhil

[Placid]

I don't think I had a channel list XML or flatfile in any of my testing. I'll add one next time, although its good testing if I don't :-)

[ttlanhil]

I don't think I had a channel list XML or flatfile in any of my testing. I'll add one next time, although its good testing if I don't :-)

nope, you didnt (at least, the errors you got indicate it wasn't loading it). it resulted in finding some bugs and improvements though, so it's all good ^_^ (the plain text file is no longer used or supported, it's only the XML now)

[Roja]

Can you name channel 2 just Help instead of Gen Help? I think we can shorten that.

 

Also, what does @@ do? (maybe i missed it)