console change plans/ideas

[ttlanhil]

well, I've been planning a change for console for a while now... there are actually quite a few bugs in console (either crash or design, such as the tab-highlight not working properly)

 

here's my plans for the changes... non-coders probably won't get too much of it, that's okay.

 

change from cyclic array to a linked-list of messages

add a linked-list of msgptrs

 

typedef struct {

message * msg;

Uint16 start;

Uint16 len;

} msgptr;

 

in many cases, there will be multiple msgptrs per message. each holds a part of it

each msgptr will always hold one line for console, with the font size as appropriate for that font-type and by font-size setting.

any changes to either font face or size will cause the lines-shown-in-console variable to be reset, and next display of console will propogate through the entire list, doing the re-wrapping. (it would be possible to extend this to a font setting per tab or even message, but I don't think that's worth doing)

this means options window should not be available in console. using %var to set is okay, because that's a one-off, but using spinners with a change each time would be bad (hmm. could be an issue with %windowed_chat=2 as well)

it could also be extended to have one for console, one for main window (windowed chat 1 or 2) or chat window (windowed chat 2)

because we don't reset the soft breaks each console render, performance improves

the one-to-one of msgptr and console line will make some of the code dealing with console easier (move console up/down 1, page, X is far simpler, for example)

the message pointer can be used to get the channel number (set the main/other channel colours as the message is 'shown'), as well as highlight start/end (future enhancement, select&copy)

 

we can also have one of these lists per tab, which means more memory used, true, but it's not that large an amount. you're looking at, perhaps, 5 tabs times 2k messages (as a guessed average. depends how long people are online for, etc), since the pointers are to the same messages, that's like 50-100kb... compared to graphics memory used, it really isn't a big increase

on the other hand, those who have seen that filtering is done several times per render will realise that having done it when the message is received will be easier on the CPU (though, again, very small compared to current use for graphics).

mind you, there will be a bit of a hit when you need to make a list, for example, changing to windowed chat 2 and running through the list of messages... depending on the machine, it will be noticable... but based on previous tests I've done, you're most likely looking at under a second for reasonably long chatlog (if you have been on @@3 for a week, you might be waiting a minute, but who is on that long?) (note: my testing is on a lappy throttled to about 600MHz, so it's not the speediest beastie, and I'm not aiming at performance only for people with new rigs)

 

 

ideas? concerns? queries?

[crusadingknight]

One question: Will you have an optional maximum history length so that message accumulation can be (optionally) controlled by the user? (If so, this also means msgptrs can be reused by anyone with such an option enabled, instead of freeing them when history overflows, as a tiny optimization.)

[Mar(c)]

Ok very cool, this sounds like it won't be difficult to make filtering on more than one message type possible!

 • Click on a channel button [tab] to filter it to only that channel.

 • Shift-click to add (or remove) a channel to the filter, so you get mixed chat.

Btw this doesn't make the "Separate *" options obsolete.

(And I'd like to see a Separate PM's option as well.)

 

 

My thoughts about the whole chat interface:

 

The 4 "modes":

 • "Tabbed chat" mode: should IMO be the default (on login) mode;

 • "Console" mode: should IMO always have the buttons at the top (like it is in "Tabbed chat" mode currently);

 • "Old behavior" mode: only thing I can think of why it exists is to get a less cluttered screen;

 • "Chat window" mode: is a very nice addition to the console and the tabbed chat, but should be easier available.

 

I vote for removing the windowed chat option from options/el.ini, with these changes to the "Tabbed chat"/"Console" buttons:

 – add a "hide buttons" ("minimize") button for "Old behavior" style,

 – add a "chat window" ("restore/maximize") button for "Chat window" mode,

 – iconize these and the History "console" buttons, so they don't take much space.

 

[h][w][c][ Channels ][ View All ] ...

[ttlanhil]

One question: Will you have an optional maximum history length so that message accumulation can be (optionally) controlled by the user? (If so, this also means msgptrs can be reused by anyone with such an option enabled, instead of freeing them when history overflows, as a tiny optimization.)

that can be done easily enough. mind you, I'd only do history length based on the full list, not the tablists, so a max length of 5k might end up with tabs with only a few hundred lines (I know, it's not great, but otherwise you have to go to greater lengths to know when all pointers to the message itself are gone, or keep them forever, and they're where the memory is)

Ok very cool, this sounds like it won't be difficult to make filtering on more than one message type possible!

• Click on a channel button [tab] to filter it to only that channel.

• Shift-click to add (or remove) a channel to the filter, so you get mixed chat.

it won't be much different there. in the current style, you have a list that's filtered when you display. with my proposal, you have a bunch of pre-filtered lists to choose from

Btw this doesn't make the "Separate *" options obsolete.

(And I'd like to see a Separate PM's option as well.)

so would I... this is where it becomes easier, since messages can be in any mix of tablists

• "Tabbed chat" mode: should IMO be the default (on login) mode;

AFAIK, it is for new installs, but it should honour saved settings... if they log off in window mode, they log on in window mode

• "Console" mode: should IMO always have the buttons at the top (like it is in "Tabbed chat" mode currently);

you can get more space with that turned off... if you're not using tabbed mode, you don't really need or expect it there

• "Old behavior" mode: only thing I can think of why it exists is to get a less cluttered screen;

and some people are nostalgic

• "Chat window" mode: is a very nice addition to the console and the tabbed chat, but should be easier available.

personally... it can be a pain to use once you have several windows up. it's available from config as well

– add a "hide buttons" ("minimize") button for "Old behavior" style,

and then how do you get tabs back? if it's elconfig, send them there to go to oldstyle

[h][w][c][ Channels ][ View All ] ...

eh... it needs to be descriptive. having an [^][X] at the right side would be closer to recogisable, but still... I think it would cause more confusion than benefit

[Mar(c)]

• "Chat window" mode: is a very nice addition to the console and the tabbed chat, but should be easier available.

personally... it can be a pain to use once you have several windows up. it's available from config as well

That it can be a pain when you are alching at storage, true, it can be a pain, but that doesn't take away that it can also be very handy in other situations. IMNSHO it should be more easily available; not three clicks Options > Chat > change setting, but a one click "window mode" (and a one click back to "tabbed chat" or "old behavior").

The total "My thoughts" part of my post is a suggestion to make it possible in a clean way. Just look at it as a program window in your favorite OS, or as a subwindow in your favorite program; "tabbed chat" = maximized, "window mode" = restored, "old behavior" = minimized.

 

• "Console" mode: should IMO always have the buttons at the top (like it is in "Tabbed chat" mode currently);

you can get more space with that turned off... if you're not using tabbed mode, you don't really need or expect it there

With the window mode easily available, yes I really do need/want/expect the buttons in console mode... So a config option "Hide buttons in console" or "Always hide buttons" sounds needed. But not depending on in which other chat mode I might be when not in console mode. To me it doesn't sound logical to change the view/behaviour of the console with a setting that's about the out-of-console chat (as it currently).

 

– add a "hide buttons" ("minimize") button for "Old behavior" style,

and then how do you get tabs back? if it's elconfig, send them there to go to oldstyle

[h][w][c][ Channels ][ View All ] ...

eh... it needs to be descriptive. having an [^][X] at the right side would be closer to recogisable, but still... I think it would cause more confusion than benefit

– iconize these and the History "console" buttons, so they don't take much space.

Don't skip the important part: iconize, make image buttons, you know. The [h][w][c] stand for three nice image buttons (hide, window, console), and of course a tooltip to enhance recognition.

To get the tabs back; the buttons are still there in console mode. Additionally the "View console" button on the bottom of the client can be tweaked to change to "Show buttons" as soon as the user hid them.