**** BEGIN LOGGING AT Tue Jan 10 02:59:58 2012
Jan 10 03:00:11 <PuffTheMagic> dtzWill, just trust vttests
Jan 10 03:00:13 <PuffTheMagic> vttest
Jan 10 03:00:16 <PuffTheMagic> its golden
Jan 10 03:00:17 <dtzWill> kk
Jan 10 03:00:38 <PuffTheMagic> idk if u have looked at its code yet
Jan 10 03:00:43 <dtzWill> nope
Jan 10 03:00:50 <PuffTheMagic> but its the most convoluted way of doing things that seem simple
Jan 10 03:00:54 <PuffTheMagic> just to stress features
Jan 10 03:00:55 <dtzWill> hahaha
Jan 10 03:00:58 <dtzWill> wonderful.
Jan 10 03:01:02 <PuffTheMagic> its really quite excellent
Jan 10 03:01:04 <dtzWill> i mean as test cases xD
Jan 10 03:01:07 <dtzWill> yep <3
Jan 10 03:01:36 <PuffTheMagic> we are pretty damn close
Jan 10 03:02:03 <dtzWill> good. i'm excited to see this perfect with respect to the common usage
Jan 10 03:02:15 <dtzWill> (and FAST ;) :D)
Jan 10 03:02:16 <PuffTheMagic> well the ssh issues are strange
Jan 10 03:02:22 <PuffTheMagic> ya its fucking fast
Jan 10 03:02:29 <PuffTheMagic> dmesg wizes by
Jan 10 03:03:22 <dtzWill> ^_______^
Jan 10 03:03:32 <dtzWill> i'm more than pleased with how that worked out
Jan 10 03:04:01 <dtzWill> often don't have the success/time spent ratio that you hope for when trying such things
Jan 10 03:04:08 <dtzWill> (although it took a few iterations xD)
Jan 10 03:05:02 <PuffTheMagic> well i've said this before, im glad you (and Brybry) are hacking on this, working on projects along is just borng
Jan 10 03:05:05 <PuffTheMagic> boring
Jan 10 03:05:57 <dtzWill> :D yeppers glad to help, it's fun and turning out well
Jan 10 03:06:03 <dtzWill> and collaboration is a blast, you're very right on taht
Jan 10 03:06:37 <PuffTheMagic> its a blast till someone reminds you how bad your css/js is <- oil ;)
Jan 10 03:06:44 <PuffTheMagic> j/k i still like working with you oil
Jan 10 03:07:17 <dtzWill> haha i'm garbage at anything remotely UI related
Jan 10 03:07:25 <dtzWill> have you SEEN vba/snes? hahaha
Jan 10 03:07:27 * oil is a jerk :/
Jan 10 03:07:50 <PuffTheMagic> oil, u are in a crowd of jerks here
Jan 10 03:08:35 <dtzWill> alright well i'm off to relax with the girly, take care and such :)
Jan 10 03:08:43 <PuffTheMagic> laters
Jan 10 03:08:46 <dtzWill> hopefully we can fix the vttest stuff soon :D
Jan 10 03:08:46 <dtzWill> cya
Jan 10 03:09:08 <PuffTheMagic> oil, would still love your help making the vkb code sexier and visually more appealing
Jan 10 15:49:10 <dtzWill> PuffTheMagic: lol, do you know a terminal that doesn't suck at vttest? xD
Jan 10 15:50:18 <PuffTheMagic> konsole,xterm,rxvt
Jan 10 15:50:27 <dtzWill> do you have to start them in 80x80 mode or somethng?
Jan 10 15:50:54 <PuffTheMagic> i just figure out what size it is and then set the right cmdline args
Jan 10 15:50:58 <dtzWill> ah, kk
Jan 10 15:50:59 <PuffTheMagic> but hold on a sec
Jan 10 15:51:20 <PuffTheMagic> dtzWill, how are u getting vttest for your non TP
Jan 10 15:51:24 <PuffTheMagic> building the version in wterm
Jan 10 15:51:28 <PuffTheMagic> or from orig source
Jan 10 15:51:32 <dtzWill> wterm
Jan 10 15:51:43 <PuffTheMagic> well that version should auto detect the rows and cols
Jan 10 15:51:57 <PuffTheMagic> so no need to specify any overrides on cmdline
Jan 10 15:51:58 <dtzWill> hrm
Jan 10 15:52:02 <dtzWill> kk
Jan 10 15:52:20 <PuffTheMagic> dtzWill, glad to see u wake up thining wterm too
Jan 10 15:52:28 <dtzWill> haha
Jan 10 15:52:31 <PuffTheMagic> i dream about escape codes
Jan 10 15:53:01 <PuffTheMagic> im trying to figure out what that first menu 1 test is broke
Jan 10 15:53:07 <PuffTheMagic> but it looks fine full width
Jan 10 15:59:05 <dtzWill> no idea :). do you debug this by looking at the escape code stream/vttest source?
Jan 10 16:00:00 <dtzWill> also is https://github.com/PuffTheMagic/wTerm/issues/18 fixed?
Jan 10 16:20:47 <ka6sox-farfarawa> wheee
Jan 10 16:21:33 <dtzWill> ka6sox-farfarawa: haha
Jan 10 16:21:37 <dtzWill> love your nick + "wheee"
Jan 10 16:21:45 <dtzWill> very appropriate, ka6sox-farfarawa++
Jan 10 16:26:45 <ka6sox-farfarawa> indeed.
Jan 10 16:33:45 <PuffTheMagic> dtzWill, ya I use the vttest code to help debug
Jan 10 16:33:57 <PuffTheMagic> im thinking of making a new cursor for when the term is no in focus
Jan 10 16:34:00 <PuffTheMagic> not in focus
Jan 10 16:34:17 <dtzWill> great
Jan 10 16:34:35 <dtzWill> btw i was looking at the rendering modes, and we don't handle blink (hehe) or underline
Jan 10 16:34:38 <dtzWill> underline seems useful
Jan 10 16:35:12 <dtzWill> maybe we could just replace the italic font with one rendered with underline?
Jan 10 16:42:16 <PuffTheMagic> i was going to do those
Jan 10 16:42:24 <dtzWill> oh hooray
Jan 10 16:42:26 <PuffTheMagic> why not just do underline
Jan 10 16:42:28 <PuffTheMagic> isnt that easy
Jan 10 16:42:35 <dtzWill> we
Jan 10 16:42:36 <dtzWill> should do underline
Jan 10 16:42:37 <dtzWill> i'm confused
Jan 10 16:42:50 <dtzWill> i was saying we should
Jan 10 16:42:54 <PuffTheMagic> ohh i misread what u said
Jan 10 16:43:00 <PuffTheMagic> is underline a different font
Jan 10 16:43:07 <dtzWill> if you're doing that, that's great. i just created an issue so you/we didn't forget and it happened
Jan 10 16:43:17 <PuffTheMagic> i mean, it was on my mental todo
Jan 10 16:43:22 <PuffTheMagic> i havent started it yet
Jan 10 16:43:30 <dtzWill> it's not generally.  i think you can just use TTF_SetFontStyle or somethign
Jan 10 16:43:52 <PuffTheMagic> why doesnt that work for bold also
Jan 10 16:43:58 <PuffTheMagic> why was a new font needed for bold
Jan 10 16:44:05 <dtzWill> i don't know.
Jan 10 16:44:08 <dtzWill> maybe we do need a new font.
Jan 10 16:44:47 <PuffTheMagic> TTF_SetFontStyle(font, TTF_STYLE_BOLD|TTF_STYLE_ITALIC);
Jan 10 16:44:48 <dtzWill> http://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf_22.html was what i was looking at btw
Jan 10 16:44:51 <PuffTheMagic> i dont think we need a new font
Jan 10 16:44:55 <dtzWill> (I see you found that)
Jan 10 16:44:58 <PuffTheMagic> i think we can ditch all the extra ones
Jan 10 16:45:04 <dtzWill> try it? I have no idea
Jan 10 16:45:10 <dtzWill> but then why do those fonts exist at all :(
Jan 10 16:45:21 <PuffTheMagic> the previous dev, not me
Jan 10 16:45:29 <PuffTheMagic> idk what he was thinking
Jan 10 16:45:37 <dtzWill> understood, i wasn't even geting to the code i just mean
Jan 10 16:45:39 <PuffTheMagic> i'd prefer to only package 1 font file
Jan 10 16:45:40 <dtzWill> we're opening font files
Jan 10 16:45:46 <dtzWill> that have different names
Jan 10 16:46:03 <dtzWill> why are there different ttf files with hardcoded bold/italic to begin with
Jan 10 16:46:13 <dtzWill> shrug, guess we don't have to solve that to do wterm
Jan 10 16:46:17 <PuffTheMagic> i've seen "bold fonts" that are much heavier than their root font with bold enabled
Jan 10 16:46:29 <dtzWill> ah, interesting
Jan 10 16:46:37 <PuffTheMagic> dtzWill, no point in guessing what the previous dev was going to do
Jan 10 16:47:01 <dtzWill> well give it a go and lmk how it goes.  if the sdlfontgl stuff is lame lmk and i'll help with that.  it presently expects an array of fonts that you refer to later by index
Jan 10 16:47:42 <dtzWill> so easiest approach regarding that is to just load the same font 4x and set the various attributes (bold, bold/underline, etc)
Jan 10 16:47:46 <dtzWill> or whatever works, idk haha :)
Jan 10 16:58:39 <PuffTheMagic> ooh ya, i get to figure out how new sdlfontgl stuff
Jan 10 16:59:18 <PuffTheMagic> dtzWill, YO
Jan 10 16:59:23 <PuffTheMagic> i just thought of something
Jan 10 16:59:56 <PuffTheMagic> your new font stuff will allow us to not need wide chars for a little bit
Jan 10 17:00:12 <PuffTheMagic> since we can just render the unicode char into the glyph cache
Jan 10 17:02:54 <dtzWill> PuffTheMagic: yep
Jan 10 17:03:13 <dtzWill> good call. i was thinking same thing, only assumed we'd want wchat_t to track the unicode value
Jan 10 17:03:26 <dtzWill> but no reason we can't do exactly what we do today, and just handle the mapping at render-time via the glyph cache
Jan 10 17:03:37 <dtzWill> (as you just suggested :))
Jan 10 17:03:44 <PuffTheMagic> if we want a full utf-8 term we need a wchar_t or wsting buffer object
Jan 10 17:03:50 <PuffTheMagic> and everything else has to get adjusted
Jan 10 17:04:06 <dtzWill> right but if we just wanna support arbitrary fonts
Jan 10 17:04:07 <PuffTheMagic> if we want to be able to use unicode line drawing chars we can just map them to the extended ascii range
Jan 10 17:04:12 <dtzWill> right :D
Jan 10 17:04:14 <PuffTheMagic> and then we dont need to hack fonts
Jan 10 17:04:15 <PuffTheMagic> :D
Jan 10 17:04:17 <PuffTheMagic> score
Jan 10 17:04:26 <dtzWill> high-five o/
Jan 10 17:04:26 <dtzWill> xD
Jan 10 17:04:58 <PuffTheMagic> dtzWill, i think i am going to defer the TTF_SetFontStyle stuff to you for now since u understand all that code (if want to do it that is)
Jan 10 17:05:07 <PuffTheMagic> im gonna focus on these failed vttests
Jan 10 17:09:56 <dtzWill> sounds good
Jan 10 17:10:12 <dtzWill> and yeah np tackling that stuff, esp after deep-diving it earlier
Jan 10 17:11:40 <PuffTheMagic> i love how i always get emails for wterm, wirc and freetether asking me if there is or ever will be a ios or android version
Jan 10 17:12:00 <dtzWill> lol
Jan 10 17:25:15 <dtzWill> apparently there is an italic TS_GM mode
Jan 10 17:25:32 <dtzWill> err TS_GM anyway, i guess "GM" probably means graphics mode
Jan 10 17:26:09 <Brybry> hmm
Jan 10 17:26:37 <dtzWill> not that was actually change fonts for it
Jan 10 17:26:38 <dtzWill> but
Jan 10 17:26:42 <dtzWill> just saying in theory that's something one might want
Jan 10 17:27:00 <dtzWill> although i use udnerline often (url highlighting primarily)
Jan 10 17:27:06 <dtzWill> trying to think of when i've seen italic used
Jan 10 17:27:09 <PuffTheMagic> dtzWill, according to what docs?
Jan 10 17:27:18 <dtzWill> according to the fact that there's a TS_GM_ITALIC
Jan 10 17:27:24 <PuffTheMagic> thats the def
Jan 10 17:27:25 <dtzWill> which i was hoping he didn't entirely fabricate
Jan 10 17:27:25 <PuffTheMagic> dev
Jan 10 17:27:27 <PuffTheMagic> that dont mean shit
Jan 10 17:27:29 <dtzWill> but
Jan 10 17:27:30 <dtzWill> .........
Jan 10 17:27:32 <dtzWill> why
Jan 10 17:27:32 <dtzWill> :(
Jan 10 17:27:33 <dtzWill> okay
Jan 10 17:27:34 <dtzWill> ._.
Jan 10 17:27:36 <PuffTheMagic> show it to me in the vt102 docs
Jan 10 17:27:41 <dtzWill> no you're right
Jan 10 17:27:48 <dtzWill> the vttest woud probably exercise that
Jan 10 17:27:53 <dtzWill> if it was standard
Jan 10 17:27:59 <dtzWill> good, so we can hide behind that
Jan 10 17:28:02 <dtzWill> b/c i don't wanna keep it
Jan 10 17:28:03 <dtzWill> hooray
Jan 10 17:28:03 <PuffTheMagic> dtzWill, u should also note that depending on how new the term is, some terms implement bright and others implement bold
Jan 10 17:28:03 <dtzWill> lol
Jan 10 17:28:13 <PuffTheMagic> and YAY
Jan 10 17:28:19 <PuffTheMagic> i fixed the vttest 1.1 issue :D
Jan 10 17:28:22 <dtzWill> oh?!
Jan 10 17:28:23 <dtzWill> \o/
Jan 10 17:28:41 <dtzWill> wait a sec before shipping it, i'm doing the font stuff in my spare time and hope to have that done soonish
Jan 10 17:28:44 <dtzWill> 'font stuff'==underline
Jan 10 17:28:50 <dtzWill> not the mapping thing we talked about, taht's later
Jan 10 17:28:54 <PuffTheMagic> im not pushing a release soon
Jan 10 17:29:00 <dtzWill> kk :)
Jan 10 17:29:04 <PuffTheMagic> im sure we have lots of new code to commit today
Jan 10 17:29:21 <PuffTheMagic> just let me know when u are done hacking for the day
Jan 10 17:29:22 <PuffTheMagic> then i will
Jan 10 17:30:06 <dtzWill> i probably won't do muich
Jan 10 17:30:22 <dtzWill> i have a big demo to prepare for and then quals that i'm a failure and didn't start studying nearly early enough for
Jan 10 17:30:22 <dtzWill> lol
Jan 10 17:30:39 <PuffTheMagic> :D
Jan 10 17:32:56 <dtzWill> underline is a go
Jan 10 17:33:00 <dtzWill> i repeat underline is a go
Jan 10 17:33:02 <dtzWill> :D
Jan 10 17:33:20 <PuffTheMagic> did u convert bold to using the set attributes too?
Jan 10 17:33:27 <dtzWill> no
Jan 10 17:33:31 <dtzWill> wasn't sure what to do about that
Jan 10 17:33:42 <PuffTheMagic> no need for the other font
Jan 10 17:33:45 <dtzWill> as you mentioned someone might wanna pick different font for bold
Jan 10 17:33:46 <dtzWill> oh
Jan 10 17:33:46 <dtzWill> okay
Jan 10 17:34:07 <PuffTheMagic> i doubt someone would pick a different font
Jan 10 17:34:14 <PuffTheMagic> the most they would do is enable bold for bright
Jan 10 17:34:30 <PuffTheMagic> or vise vera
Jan 10 17:34:31 <PuffTheMagic> or both
Jan 10 17:34:46 <PuffTheMagic> bright/bold seems to be not too standard
Jan 10 17:38:16 * PuffTheMagic wonders how to best do inverted background
Jan 10 17:38:29 <PuffTheMagic> well inverted is wrong
Jan 10 17:38:34 <PuffTheMagic> term
Jan 10 17:38:48 <dtzWill> errr hmm?
Jan 10 17:38:53 <PuffTheMagic> the default fb and bg are inverted
Jan 10 17:38:56 <PuffTheMagic> swapped i mean
Jan 10 17:39:06 <dtzWill> yeah, that works.. doesn't it?
Jan 10 17:39:10 <PuffTheMagic> nope
Jan 10 17:39:11 <dtzWill> via NEGATIVE or w/e?
Jan 10 17:39:18 <PuffTheMagic> TS_TM_SCREEN
Jan 10 17:39:20 <dtzWill> oh
Jan 10 17:39:22 <dtzWill> i see
Jan 10 17:39:25 <dtzWill> terminal mode, not graphics mode
Jan 10 17:39:29 <PuffTheMagic> ya
Jan 10 17:39:30 * dtzWill doesn't actually know much about these things
Jan 10 17:39:31 <dtzWill> great
Jan 10 17:40:33 <dtzWill> so...votes on implementing blink? xD
Jan 10 17:40:35 <PuffTheMagic> eww
Jan 10 17:40:40 <dtzWill> hahaha
Jan 10 17:40:45 <PuffTheMagic> the NEGATIVE background is getting bright
Jan 10 17:40:51 <PuffTheMagic> i must have forgot that spot
Jan 10 17:40:56 <PuffTheMagic> it should be dark
Jan 10 17:41:07 <PuffTheMagic> only the fg should be bright/bold
Jan 10 17:41:17 <Brybry> does sdlfontgl expect the folors to have already been set or something? hmm
Jan 10 17:41:44 <dtzWill> Brybry: see 'resetGlyphCache' in sdlcore.cpp, and corresponding setupFontGL in sdlfontgl.cpp
Jan 10 17:41:49 <dtzWill> it takes an array of fonts and colors
Jan 10 17:42:03 <dtzWill> and you draw text with indices into the fonts/color set you last gave it
Jan 10 17:43:11 <Brybry> yeah, that's where I segfault when trying to run wterm from commandline standalone (I want to do that to see if luna is passing input differently to pdk apps and hybrid apps)
Jan 10 17:43:31 <PuffTheMagic> dtzWill, setForegroundColor(state.backgroundColor);
Jan 10 17:43:37 <PuffTheMagic> that takes ints now right
Jan 10 17:43:43 <PuffTheMagic> the enum actually
Jan 10 17:44:14 <dtzWill> oh we can run wterm standalone?!
Jan 10 17:44:15 <Brybry> setupFontGL does clearGL which tries to free haveFontLine (which I think is uninitialized at that point)
Jan 10 17:44:15 <PuffTheMagic> yup
Jan 10 17:44:22 <PuffTheMagic> dtzWill, ya :D
Jan 10 17:44:23 <Brybry> used to be able to
Jan 10 17:44:29 <dtzWill> Brybry: haveFontLine isn't initialized in the constructor?
Jan 10 17:44:33 <Brybry> nah
Jan 10 17:44:35 <Brybry> so I added that
Jan 10 17:44:35 <dtzWill> if not, it should be and i'm sorry
Jan 10 17:44:38 <Brybry> but then I ran into other issues
Jan 10 17:44:48 <Brybry> so I *think* I'm just seeing a symptom of the problem
Jan 10 17:44:50 <Brybry> and not the problem
Jan 10 17:46:36 <Brybry> like when I put that in the initialization list I think I was crashing in ensureFontLine on TTF_RenderText_Blended but as far as I could tell everything looked good in terms of parameters
Jan 10 17:46:56 <Brybry> I'll have to attach gdb to it when it's running as a hybrid and see what's different
Jan 10 17:47:49 <dtzWill> Brybry: commit the initialization fix, sorry about that.
Jan 10 17:48:01 <Brybry> I need to learn to do branches in git =x
Jan 10 17:48:23 <dtzWill> (I can do it, if you'd prefer)
Jan 10 17:48:28 <dtzWill> but you found the bug :D
Jan 10 17:48:58 <Brybry> you can do it but it's not like an end user will run into the problem ;)
Jan 10 17:49:05 <dtzWill> fair enough
Jan 10 17:49:06 <PuffTheMagic> dtzWill, u just files a duplicate issue ;)
Jan 10 17:49:25 <dtzWill> it's unclear to me how it'd cause you problems when running standalone
Jan 10 17:49:28 <dtzWill> but not from luna
Jan 10 17:49:28 <dtzWill> lol
Jan 10 17:50:01 <dtzWill> PuffTheMagic: you mean the pull request? haha sorry
Jan 10 17:50:29 <PuffTheMagic> no
Jan 10 17:50:33 <PuffTheMagic> the font attributes
Jan 10 17:50:57 <Brybry> I honestly think it's just getColor() that's the problem and I need to initialize the colors differently
Jan 10 17:50:57 <dtzWill> https://github.com/PuffTheMagic/wTerm/pull/35 ?
Jan 10 17:51:02 <PuffTheMagic> dtzWill, ya
Jan 10 17:51:29 <dtzWill> Brybry: any magic ot running it standalone?
Jan 10 17:51:35 <dtzWill> just ./wterm ?
Jan 10 17:51:37 <Brybry> sdlterminal just sets them all to r=0 b=0 g=0
Jan 10 17:51:40 <Brybry> fontsize
Jan 10 17:51:43 <PuffTheMagic> no
Jan 10 17:51:44 <Brybry> ./wterm 12
Jan 10 17:51:46 <PuffTheMagic> ya
Jan 10 17:51:49 <dtzWill> ah, kk
Jan 10 17:51:51 <PuffTheMagic> in the app dir
Jan 10 17:51:54 <PuffTheMagic> so that it finds the fonts
Jan 10 17:52:02 <dtzWill> kk
Jan 10 17:52:23 <PuffTheMagic> i should make it not segfault if no font is specified on the cmdline ;)
Jan 10 17:52:37 <PuffTheMagic> i willd o that after i fix this negative issue
Jan 10 17:52:39 <Brybry> gdb --dir=./src/plugin --args wterm 12 from us.ryanhope.wterm (though I suppose one could set working directory from commandline as well)
Jan 10 17:55:03 <Brybry> PuffTheMagic, there was also a bug with orientation setting that I fixed but haven't pushed yet (I need to get my repository in a better place!)
Jan 10 17:55:35 <Brybry> basically if rotation lock is set but the touchpad is in a different orientation getWindowOrientation doesn't obey the lock and so it tries to put up the wrong keyboard
Jan 10 17:57:11 <PuffTheMagic> ah
Jan 10 17:57:13 <PuffTheMagic> good call
Jan 10 17:59:09 <dtzWill> Brybry: why run from src/plugin and not the app dir?
Jan 10 17:59:19 <Brybry> you aren't running from src/plugin with that
Jan 10 17:59:25 <Brybry> dir= sets the source path
Jan 10 17:59:33 <dtzWill> oh good
Jan 10 18:03:17 <PuffTheMagic> u no longer need to specify a font
Jan 10 18:03:24 <PuffTheMagic> it will default to 12 if u dont pass one
Jan 10 18:11:31 <dtzWill> Brybry: agreed it seems the default color configuration is the issue
Jan 10 18:12:37 <PuffTheMagic> when people pull my next commit and their colors are fucked, delete wterm and start over
Jan 10 18:12:50 <PuffTheMagic> on the TP that is
Jan 10 18:12:50 <Brybry> maybe it uses the alpha values and those are uninitialized? or everything being 0,0,0 I have no idea
Jan 10 18:12:53 <PuffTheMagic> uninstall it
Jan 10 18:12:59 <PuffTheMagic> need to update the default prefs
Jan 10 18:16:14 <dtzWill> Brybry: have it running from standalone, fwiw
Jan 10 18:16:27 <dtzWill> will commit changes shortly
Jan 10 18:16:41 <dtzWill> (almost entirely based on your debugging reports)
Jan 10 18:16:42 <Brybry> yay :D
Jan 10 18:17:29 * dtzWill rips out debug syslogs and calls to 'checkGLError()'
Jan 10 18:17:30 <dtzWill> lol
Jan 10 18:17:45 <Brybry> then I'm going to go beat someone at hp with a stick when I find out that hybrid and pdk apps get different input values for the bluetooth keyboard arrow keys
Jan 10 18:18:53 <Brybry> syslogs are sometimes the only way
Jan 10 18:19:07 <dtzWill> well
Jan 10 18:19:10 <dtzWill> now that i can run it from the CLI
Jan 10 18:19:12 <Brybry> it's *really* hard to track down uninitialized variables otherwise
Jan 10 18:19:13 <dtzWill> i'm very happy
Jan 10 18:19:18 <PuffTheMagic> ok i really broke something with the colors now :(
Jan 10 18:20:28 <dtzWill> Brybry: in commit for uninitialized, how do you want me to cite you? is 'BryBry' appropriate?
Jan 10 18:20:41 <PuffTheMagic> reset --hard
Jan 10 18:20:42 <Brybry> you don't need to cite anything
Jan 10 18:20:47 <Brybry> but "Brybry" is fine
Jan 10 18:21:06 <Brybry> that's so tiny and my name is already elsewhere
Jan 10 18:22:02 <dtzWill> understood, it's more about the principle of giving credit where credit is due, no matter how small :)
Jan 10 18:27:16 <dtzWill> Brybry: https://github.com/PuffTheMagic/wTerm/pull/36 fwiw
Jan 10 18:27:27 <dtzWill> although i imagine puff'll pull it once he's done with w/e he's doing :)
Jan 10 18:27:42 <dtzWill> Brybry: lmk if that doesn't resolve things for you
Jan 10 18:28:48 <Brybry> it should though I'm mostly curious as to what exactly the problem was
Jan 10 18:29:19 <PuffTheMagic> pulled
Jan 10 18:29:22 <Brybry> was it the values of the colors themselves?
Jan 10 18:32:00 <dtzWill> well there are three commits
Jan 10 18:32:05 <dtzWill> each mandatory for it to work
Jan 10 18:32:17 <dtzWill> the initialization error you caught fixes segfault in clearGL
Jan 10 18:32:35 <dtzWill> the restGlyphCache fixes a bug that i didn't care to debug beyond the fact that sdlfontgl ended up with stale fonts
Jan 10 18:32:49 <dtzWill> (Which resulted in a segfault on startup)
Jan 10 18:32:56 <dtzWill> and the last fix makes it so that the screen isn't all black
Jan 10 18:33:13 <dtzWill> since having all 0's for colors means everything is black-on-black :)
Jan 10 18:33:23 <Brybry> oh ok, so the colors didn't actually segfault anything
Jan 10 18:33:27 <dtzWill> nopers
Jan 10 18:33:28 <Brybry> whew, good. I'm not going crazy!
Jan 10 18:33:47 <dtzWill> whoa whoa let's not get carried away
Jan 10 18:33:48 <dtzWill> :P
Jan 10 18:33:49 <dtzWill> :D
Jan 10 18:33:51 <Brybry> :D
Jan 10 18:34:32 <PuffTheMagic> dtzWill, sooooo
Jan 10 18:34:48 <PuffTheMagic> how do u feel about taking care about the last font issue for the immediate future
Jan 10 18:35:08 <dtzWill> which font issue?
Jan 10 18:35:54 <PuffTheMagic> well so your glyph cache i assume renders all the printable ascii chars to a texture right
Jan 10 18:35:58 <dtzWill> (and i'm glad you removd unneeded fonts, i was gonna include that in the pull req but figured that didn't belong part of it)
Jan 10 18:36:13 <dtzWill> PuffTheMagic: okay so you mean "fix the need for hacked fonts" issue
Jan 10 18:36:17 <PuffTheMagic> andya
Jan 10 18:36:19 <PuffTheMagic> ya
Jan 10 18:36:36 <dtzWill> where is the mapping currently defined?
Jan 10 18:36:40 <PuffTheMagic> its not
Jan 10 18:36:43 <PuffTheMagic> yet
Jan 10 18:36:43 <dtzWill> errr
Jan 10 18:36:47 <dtzWill> well i see lines on my screen sometimes
Jan 10 18:36:52 <PuffTheMagic> ya
Jan 10 18:36:53 <dtzWill> so presumably something works
Jan 10 18:36:57 <PuffTheMagic> thats cause of the hacked font
Jan 10 18:37:00 <dtzWill> right
Jan 10 18:37:06 <dtzWill> but i'd be doing same
Jan 10 18:37:10 <dtzWill> with a hardcoded mapping
Jan 10 18:37:15 <PuffTheMagic> yes and no
Jan 10 18:37:19 <PuffTheMagic> there is no font hacking
Jan 10 18:37:20 <dtzWill> from ascii range to some unicode charactes
Jan 10 18:37:29 <dtzWill> right and the result would be no need to hack fonts
Jan 10 18:37:43 <dtzWill> but i still need to know the values of the characters to map to/from
Jan 10 18:37:50 <dtzWill> i mean
Jan 10 18:37:52 <dtzWill> err, right?
Jan 10 18:37:54 <PuffTheMagic> i am going to populate an array of lengh 256
Jan 10 18:37:59 <PuffTheMagic> seeded will nulls
Jan 10 18:38:16 <PuffTheMagic> then set specific cells to a wchar_t
Jan 10 18:38:26 <PuffTheMagic> specifying specific unicode chars
Jan 10 18:38:30 <dtzWill> okay so you're gonna handle building the mapping
Jan 10 18:38:34 <PuffTheMagic> ya
Jan 10 18:38:43 <PuffTheMagic> err wait
Jan 10 18:38:49 <PuffTheMagic> the array is 128 long
Jan 10 18:38:58 <dtzWill> why not 256?
Jan 10 18:39:07 <PuffTheMagic> so when u get a char from 0 to 127 u render the normal ascii character
Jan 10 18:39:12 <dtzWill> oh
Jan 10 18:39:13 <dtzWill> well
Jan 10 18:39:15 <dtzWill> >.<
Jan 10 18:39:15 <dtzWill> lol
Jan 10 18:39:16 <dtzWill> okay
Jan 10 18:39:19 <PuffTheMagic> if its from 128 to 255 u render my custom char
Jan 10 18:39:34 <dtzWill> and if that array entry is null?
Jan 10 18:39:35 <PuffTheMagic> else u render the char -128
Jan 10 18:39:39 <dtzWill> ah
Jan 10 18:39:44 <dtzWill> can do
Jan 10 18:39:54 <PuffTheMagic> does that make sense?
Jan 10 18:39:57 <dtzWill> absolutely
Jan 10 18:40:11 <dtzWill> can i assume there's some array in sdlcore.cpp that contains this mapping?
Jan 10 18:40:17 <dtzWill> errr that the array you're talkign about is a member of sdlcore?
Jan 10 18:40:26 <PuffTheMagic> i could be
Jan 10 18:40:28 <dtzWill> (does that work for how you'd be populating it?)
Jan 10 18:40:29 <PuffTheMagic> it does not exist yet
Jan 10 18:40:43 <dtzWill> the present model for the fontgl configuration is via setupFontGL which is done in resetGlyphCache
Jan 10 18:40:57 <PuffTheMagic> dtzWill, now if u want to be super slick
Jan 10 18:41:02 <dtzWill> as long as it works to pass it into setupFontGL along with the other things, i'm good with that
Jan 10 18:41:13 <PuffTheMagic> u could come up with a way to support multiple custom maps
Jan 10 18:41:26 <PuffTheMagic> if u do vttest menu 3
Jan 10 18:41:31 <PuffTheMagic> which shows the char set
Jan 10 18:41:37 <dtzWill> well that's why it'd be a member of sdlcore
Jan 10 18:41:47 <dtzWill> a property of the current rendering state like m_foregroundColor and others
Jan 10 18:42:12 <PuffTheMagic> well
Jan 10 18:42:13 <dtzWill> so that sdltemrinal, if it wanted, could track all the possible states (like it does for graphics states) and enable the correct one when rendering or whenever is appropriate
Jan 10 18:42:55 <PuffTheMagic> there already is code that says what charset to use
Jan 10 18:42:58 <dtzWill> but i'm less paricular about engineering the rest just wanted to informally agree upon some interface so i could go make this happen and you could hook it up to whatever (statically-built array for first pass, it seems)
Jan 10 18:43:28 <dtzWill> oh, does some of that stuff exist? sorry idk anything about these things.
Jan 10 18:43:51 <dtzWill> for now, i'll just write the code that makes /use/ of the final 'what to do with chars [128,256)' array
Jan 10 18:44:06 <dtzWill> and you/we can iterate on how to build that with respect to the various encodings or terminal properties
Jan 10 18:44:12 <dtzWill> you have a much better handle on that anyway
Jan 10 18:44:15 <dtzWill> sound good?
Jan 10 18:44:20 <PuffTheMagic> ya
Jan 10 18:44:28 <PuffTheMagic> once thats in place it will be easier to extend
Jan 10 18:44:33 <dtzWill> yeppers
Jan 10 18:45:49 <dtzWill> oh i see.
Jan 10 18:46:01 <PuffTheMagic> vt terms support ~5 charsets
Jan 10 18:46:02 <dtzWill> if i'm undertsanding correctly, the 128-255 mapping is explicitly and only defined by the charset
Jan 10 18:46:13 <dtzWill> like "ISO-8859-1" says what they are
Jan 10 18:46:18 <dtzWill> vs other charsets
Jan 10 18:46:21 <dtzWill> is that correct?
Jan 10 18:46:23 <PuffTheMagic> umm
Jan 10 18:46:31 * dtzWill trying to do basic understanding so his code doens't look too silly
Jan 10 18:46:56 <PuffTheMagic> vt tems handle charsets by swapping ROMS
Jan 10 18:47:05 <PuffTheMagic> and it can have 2 roms loaded at once
Jan 10 18:47:11 <PuffTheMagic> but only 1 active
Jan 10 18:47:23 <dtzWill> okay they're called 'ROM's then? interesting
Jan 10 18:47:35 <PuffTheMagic> so there are commands that controls which charset it loaded into the 2 ROM slots
Jan 10 18:47:46 <PuffTheMagic> and there are escape codes to control which ROM slot is the active ROM
Jan 10 18:47:49 <dtzWill> lol
Jan 10 18:47:50 <dtzWill> okay
Jan 10 18:48:16 <dtzWill> what does ROM stand for? in my book it's read-only memory
Jan 10 18:48:28 <dtzWill> (were these hardcoded, and your ROM slots were selectors across various mappings?)
Jan 10 18:48:31 <dtzWill> haha sorry for the 20q :3
Jan 10 18:49:35 <PuffTheMagic> yes read-only mem
Jan 10 18:49:49 <PuffTheMagic> we are talking 80
Jan 10 18:49:53 <PuffTheMagic> 80's here
Jan 10 18:49:56 <PuffTheMagic> they had no mem
Jan 10 18:50:17 <Brybry> uguu
Jan 10 18:50:55 <PuffTheMagic> dtzWill, just skim this http://vt100.net/docs/vt102-ug/chapter5.html#S5.5.2.16
Jan 10 18:51:04 <dtzWill> PuffTheMagic: ty
Jan 10 18:51:22 <Brybry> bluetooth keyboard up key standalone: Press:- Scancode: 0x00, Name: pause 0x13, Unicode: ^S (0x0013)
Jan 10 18:51:26 <PuffTheMagic> dtzWill, your glyph cache is a ROM
Jan 10 18:51:45 <Brybry> bluetooth keyboard up key plugin: Press:- Scancode: 0x00, Name: unknown key 0xE0A0, Unicode: ? (0xE0A0)
Jan 10 18:51:46 <PuffTheMagic> instead of having it be 256 long maybe it should be 128
Jan 10 18:51:49 <PuffTheMagic> and we can have 2 of them
Jan 10 18:51:56 <PuffTheMagic> that would make this all really easy
Jan 10 18:51:58 <dtzWill> well having them all in 1 texture is useful
Jan 10 18:52:06 <dtzWill> i'd rather just update the single texture as needed
Jan 10 18:52:20 <dtzWill> i mean this is a property of the entire screen, right?
Jan 10 18:52:23 <PuffTheMagic> well how ever u want to do it
Jan 10 18:52:33 <PuffTheMagic> think of 0-127 as ROM SLOT1
Jan 10 18:52:38 <PuffTheMagic> and 128-255 as SLOT2
Jan 10 18:52:48 <dtzWill> by useful i mean "binding different textures on-the-fly is slow"
Jan 10 18:52:50 <PuffTheMagic> and we will need an easy way to swap out what is in each slot
Jan 10 18:52:58 <dtzWill> errr
Jan 10 18:52:59 <dtzWill> oh
Jan 10 18:53:04 <dtzWill> we'll want to swap out the first 128 too?
Jan 10 18:53:07 <dtzWill> intresting
Jan 10 18:53:08 <PuffTheMagic> yes
Jan 10 18:53:08 <dtzWill> okay
Jan 10 18:53:13 <PuffTheMagic> that technically possible
Jan 10 18:53:21 <PuffTheMagic> though uncommon
Jan 10 18:53:35 <dtzWill> yeah i'm just gonna expect one big array that maps every character to its wchat_t
Jan 10 18:53:53 <PuffTheMagic> like the ROM that contains the line drawing chars could be loaded in both slots if someone wanted to
Jan 10 18:54:02 <dtzWill> (possibly we can agree that if it's blank i should render the normal char % 128 instead)
Jan 10 18:54:13 <dtzWill> and let sdlcore/sdlterminal/etc deal with how to populate that array
Jan 10 18:54:20 <PuffTheMagic> hmmm
Jan 10 18:54:24 <dtzWill> makes me happy, sense i didn't want the sdlfontgl stuff to deal with encodings anyway
Jan 10 18:54:31 <dtzWill> but having a mapping is reasonable and easy
Jan 10 18:55:30 <PuffTheMagic> i think u should have a function that populates the glyph cache
Jan 10 18:55:34 <PuffTheMagic> and it should take 2 args
Jan 10 18:55:44 <PuffTheMagic> both args are arrays of wchar_t that are 128 long
Jan 10 18:55:55 <PuffTheMagic> hmmm
Jan 10 18:56:05 <PuffTheMagic> ya i think that would do
Jan 10 18:56:16 <PuffTheMagic> i can then worry about building those arrays
Jan 10 18:56:19 <dtzWill> or just add a single arugment to the existing cache invalidation and let sdlcore populate it (two memcpy's if it likes)
Jan 10 18:56:21 <dtzWill> alright
Jan 10 18:56:25 <dtzWill> i'll make your function haha
Jan 10 18:56:34 <dtzWill> i jsut don't likeit in sdlfontgl, but i'm not sure you're saying you care either
Jan 10 18:58:17 <PuffTheMagic> so here is something else to think about first
Jan 10 18:58:33 <PuffTheMagic> right now, when I get the escape code to switch slots
Jan 10 18:58:42 <PuffTheMagic> I add 128 to the char before drawing it
Jan 10 18:59:06 <PuffTheMagic> it would be much easier to just activate a different glyph cache texture
Jan 10 18:59:12 <PuffTheMagic> as the default
Jan 10 18:59:40 <PuffTheMagic> i think that is actually the better route
Jan 10 19:00:18 <dtzWill> i mean the only difference is that we're then just caching these in GPU memory
Jan 10 19:00:24 <dtzWill> as opposed to rebuilding them as needed
Jan 10 19:01:04 <PuffTheMagic> hold on
Jan 10 19:01:05 <dtzWill> so maybe you're right, but maybe we can leave that for later?
Jan 10 19:01:56 <PuffTheMagic> if we have a texture that hold 256 glyphs then I need to add 128 to each char every time a new char comes in (when the alternate rom is activted)
Jan 10 19:02:11 <PuffTheMagic> if there were instead 2 textures of 128 glyphs
Jan 10 19:02:12 <dtzWill> oh wait
Jan 10 19:02:16 <PuffTheMagic> then all that needs to change is 1 pointer
Jan 10 19:02:21 <dtzWill> so under no circumstances
Jan 10 19:02:30 <dtzWill> does a terminal /actually/ give you a character above 127y?
Jan 10 19:02:32 <PuffTheMagic> and it only has to happen when the alternate rom is activated/deactivated
Jan 10 19:02:35 <PuffTheMagic> NOPE
Jan 10 19:02:37 <dtzWill> we just are abusing that range for convenience
Jan 10 19:02:41 <PuffTheMagic> yes
Jan 10 19:02:55 <dtzWill> and you're saying you have a 'hack' that looks up what slot we're using and adds 128 appropriately
Jan 10 19:02:57 <dtzWill> ahhhhh
Jan 10 19:02:57 <dtzWill> okay
Jan 10 19:02:59 <dtzWill> well
Jan 10 19:03:05 <PuffTheMagic> yes thats what im saying
Jan 10 19:03:14 <dtzWill> i think we should just give the fontgl stuff the active mapping then
Jan 10 19:03:16 <dtzWill> and be done
Jan 10 19:03:19 <PuffTheMagic> lol
Jan 10 19:03:33 <dtzWill> and if somehow that makes things slow
Jan 10 19:03:38 <PuffTheMagic> why would it?
Jan 10 19:03:51 <PuffTheMagic> it still uses the same amount of memory
Jan 10 19:03:53 <dtzWill> by having to rebuild that texture because someone likes switching encodings 100 times a second
Jan 10 19:04:07 <PuffTheMagic> that doesnt happen
Jan 10 19:04:17 <dtzWill> i know/didn't think so :)
Jan 10 19:04:30 <dtzWill> are you suggesting the sdlfontgl has the active *two* mappings then?
Jan 10 19:04:41 <dtzWill> slot 1/slot 2 i mean
Jan 10 19:04:47 <dtzWill> and you tell it which slot to render from?
Jan 10 19:04:48 <PuffTheMagic> ummm
Jan 10 19:04:48 <dtzWill> i'm sorry :(
Jan 10 19:04:54 <PuffTheMagic> active no, loaded textures yes
Jan 10 19:05:01 <PuffTheMagic> only 1 is active
Jan 10 19:05:40 <PuffTheMagic> its like g0texture = <SOMETHING>; g1texture = <SOMETHINGELSE>
Jan 10 19:05:50 <PuffTheMagic> activetEXTURE = g0texture
Jan 10 19:05:56 <dtzWill> right, you want the fontgl to maintain two textures
Jan 10 19:05:58 <dtzWill> one for each slot
Jan 10 19:06:01 <PuffTheMagic> and the rendering shit only draws from activeTexture
Jan 10 19:06:04 <dtzWill> and you tell it which to use
Jan 10 19:06:38 <dtzWill> whether we actually split it into two textures or not seems immaterial to everything else unless i'm misunderstanding something
Jan 10 19:07:10 <PuffTheMagic> dtzWill, well how do u get the index of the glyph
Jan 10 19:07:11 <PuffTheMagic> ?
Jan 10 19:07:33 <dtzWill> well i could have two textures like you said and index with the character directly
Jan 10 19:07:39 <PuffTheMagic> i would assume that 1 texture of 256 glyphs would be the same mem usage as 2 textures of 128 glyphs
Jan 10 19:07:41 <dtzWill> or i could push the "which slot is active" logic to the mapping
Jan 10 19:07:49 <dtzWill> or i could push the "Which slot is active" to exactly where it is right now
Jan 10 19:08:09 <PuffTheMagic> the latter seems to have unnecessary math involved
Jan 10 19:08:13 <PuffTheMagic> every time a new char comes in
Jan 10 19:08:13 <dtzWill> lol
Jan 10 19:09:19 <dtzWill> i...
Jan 10 19:09:29 <dtzWill> i don't think an addition for each character on the screen
Jan 10 19:09:31 <dtzWill> of all things in wterm
Jan 10 19:09:33 <dtzWill> is going to be a problem.
Jan 10 19:09:38 <PuffTheMagic> w/e
Jan 10 19:10:10 <dtzWill> but alright i'll give it two slots lol
Jan 10 19:10:43 <PuffTheMagic> i just though the code would be over all simpler if somewhere we didnt have to modify the incoming chars
Jan 10 19:11:13 <dtzWill> well we're just moving around the complexity
Jan 10 19:11:40 <dtzWill> if (slot1active) c+= 128; vs glBindTexture(TEXTURE_2D, slot1active ?texture0: texture1)
Jan 10 19:11:54 <dtzWill> only the latter involves additional logic to populate and maintain the additional texture
Jan 10 19:11:55 <dtzWill> lol
Jan 10 19:12:02 <PuffTheMagic> ok ok
Jan 10 19:12:12 <dtzWill> maybe that's why i'm grumpy, it's more work :P
Jan 10 19:12:12 <dtzWill> lol
Jan 10 19:12:16 <dtzWill> :3
Jan 10 19:22:15 <PuffTheMagic> hmm
Jan 10 19:22:19 <PuffTheMagic> there is a font loading issue now
Jan 10 19:25:55 <PuffTheMagic> like every other 'make test' there is a font loading error
Jan 10 19:27:56 <dtzWill> that's strange
Jan 10 19:28:20 <PuffTheMagic> this disappearing cursor issue is also strange
Jan 10 19:31:15 <dtzWill> PuffTheMagic: err the charset *is* a property of the full screen, right?
Jan 10 19:31:26 <dtzWill> as in whole terminal, not a particular range of characters or line?
Jan 10 19:31:40 <dtzWill> i'm asking because i'm looking at TSLineGraphicsState_t that contains the charset information
Jan 10 19:31:45 <PuffTheMagic> no
Jan 10 19:31:49 <PuffTheMagic> its not fullscreen
Jan 10 19:31:58 <dtzWill> ............ oh.
Jan 10 19:32:03 <PuffTheMagic> it works just like setting a graphics mode
Jan 10 19:32:13 <dtzWill> so you *will* be changing modes on the fly
Jan 10 19:32:17 <dtzWill> during a single render
Jan 10 19:32:17 <dtzWill> lol
Jan 10 19:32:31 <PuffTheMagic> well, that is a valid behavior
Jan 10 19:32:40 <dtzWill> right
Jan 10 19:32:42 <dtzWill> okaayyyy
Jan 10 19:32:50 <dtzWill> well i guess what we have for now will work
Jan 10 19:33:42 <dtzWill> hrrm.  can you have more than 2 encodings displayed at once, then? d'oh
Jan 10 19:33:57 <PuffTheMagic> sure u could
Jan 10 19:34:15 <dtzWill> well
Jan 10 19:34:17 <dtzWill> lol
Jan 10 19:34:20 <dtzWill> sigh
Jan 10 19:34:30 <dtzWill> i see.
Jan 10 19:34:54 <PuffTheMagic> load rom1 in slot 1 load rom2 into slot2, print some chars, move to next line, load rom3 into slot2, print more chars
Jan 10 19:34:54 <dtzWill> so forget slot 1, slot 2, or anything else
Jan 10 19:34:55 <PuffTheMagic> etc etc
Jan 10 19:35:44 <dtzWill> to use this glyph cache model (and not invalidate it halfway through a render), we'd have to have a texture for each encoding
Jan 10 19:36:11 <dtzWill> sorry i asked if it was a property of the screen above and thought you confirmed, but no you dind't
Jan 10 19:36:16 <PuffTheMagic> vt terms support 10 roms
Jan 10 19:36:22 <PuffTheMagic> look at menu 3
Jan 10 19:36:27 <PuffTheMagic> in vttedy
Jan 10 19:36:29 <PuffTheMagic> vttest
Jan 10 19:36:37 <PuffTheMagic> its all about charsets
Jan 10 19:36:41 <dtzWill> hhrrrmm well different textures means...sigh.
Jan 10 19:36:45 <dtzWill> well i'll think about it i guess
Jan 10 19:37:10 <PuffTheMagic> 10 is a theoretical max
Jan 10 19:37:19 <PuffTheMagic> but most terms i've seen only implement like 3
Jan 10 19:37:29 <dtzWill> well so one big win rendering-wise is using the same texture for the entire rendering
Jan 10 19:37:42 <PuffTheMagic> UK/international, US ASCII and US ASCII with special line drawing chars
Jan 10 19:38:10 <dtzWill> supporting switching characters on the fly means that doesnt' quite work.  we could do something like "batch text operations with the same encoding" that'd be rather straightforward
Jan 10 19:38:31 <dtzWill> "if $desiredencoding == $currentencodingforthisbatch" etc
Jan 10 19:38:35 <dtzWill> but that seems lame too.
Jan 10 19:38:43 <dtzWill> maybe i can just grow the texture taller and throw them on there
Jan 10 19:38:53 <dtzWill> and index based on font/encoding into the cache
Jan 10 19:39:13 <PuffTheMagic> i will let you worry about optimization
Jan 10 19:39:22 <PuffTheMagic> just make it work first ;)
Jan 10 19:39:26 <dtzWill> well it partially defines how you interact with it
Jan 10 19:39:32 <dtzWill> i already added support for arbitrary mappings
Jan 10 19:39:41 <dtzWill> but that was assuming it was a screen-wide setting
Jan 10 19:39:50 <dtzWill> not per-character
Jan 10 19:40:31 <PuffTheMagic> everything visual is term wide except of the fliping of foreground and background i think
Jan 10 19:40:39 <PuffTheMagic> s/term/char/
Jan 10 19:40:54 <dtzWill> well font and colorscheme isn't, i didn't think
Jan 10 19:41:08 <dtzWill> nvm font lol that's not what i meant
Jan 10 19:43:09 <dtzWill> PuffTheMagic: these ROMS are in fact entirely static, right?
Jan 10 19:43:37 <dtzWill> so no need to support changing what 'rom 1' is, just need to be able to associate the two roms with a given bit of text while rendering
Jan 10 19:54:21 <PuffTheMagic> yes the roms would be static
Jan 10 19:54:25 <PuffTheMagic> well
Jan 10 19:54:35 <PuffTheMagic> unless we allow user defined roms via the prefs
Jan 10 19:54:45 <dtzWill> kk
Jan 10 19:55:18 <dtzWill> i'm gonna export a "setCharset(int i, CharMapping_t)" interface that can be used initially to populate it with our predefined values
Jan 10 19:55:28 <dtzWill> but down the road can be used to replace mappings as we see fit
Jan 10 19:55:46 <dtzWill> and then when you render text you just tell it what slot1/slot2 are, and it does the rest
Jan 10 19:56:09 <PuffTheMagic> k
Jan 10 19:56:09 <dtzWill> (you'll see what i mean when i wrap this up and can code review accordingly)
Jan 10 20:17:55 <dtzWill> oh setting the colors to non-black initially makes the screen flash before showing correct theme
Jan 10 20:17:56 <dtzWill> hrrm
Jan 10 20:19:23 <dtzWill> PuffTheMagic: do we have the data for these encodings somewhere?
Jan 10 20:19:36 <dtzWill> I know you mentioned you'd handle that, but i want to at least partially populate one for testing
Jan 10 20:31:55 <PuffTheMagic> hold on 1 sec
Jan 10 20:31:59 <PuffTheMagic> i can make them
Jan 10 20:32:04 <dtzWill> hooray
Jan 10 20:32:06 <PuffTheMagic> well
Jan 10 20:32:16 <PuffTheMagic> it might be easier if u pushed this code and I then populated maps
Jan 10 20:32:21 <dtzWill> agreed
Jan 10 20:32:23 <dtzWill> very close to being done
Jan 10 20:32:26 <dtzWill> the actual code is done
Jan 10 20:32:34 <dtzWill> just stubbing out some sdlcore stuff
Jan 10 20:37:12 <PuffTheMagic> omg dtzWill
Jan 10 20:37:24 <PuffTheMagic> i think its your glyph shit that broke the cursor
Jan 10 20:37:33 <dtzWill> disappearing you mean?
Jan 10 20:37:36 <PuffTheMagic> ya
Jan 10 20:37:42 <dtzWill> it's possible.  thought i fixed that though.
Jan 10 20:37:43 <dtzWill> i'm sorry :(
Jan 10 20:37:49 <dtzWill> i really thought i fixed all cases that it happened
Jan 10 20:37:55 <dtzWill> by all
Jan 10 20:37:55 <PuffTheMagic> fixed in a commit i havent pulled?
Jan 10 20:37:58 <dtzWill> i mean that derawREct was broken
Jan 10 20:37:59 <dtzWill> no no
Jan 10 20:38:00 <dtzWill> like
Jan 10 20:38:03 <dtzWill> long before you ever saw it
Jan 10 20:38:12 <dtzWill> errr at least if you just looked at the pull request anyway
Jan 10 20:38:31 <PuffTheMagic> well if I type text at the prompt and then use back arrow to go back and edit a command, the cursor disappears
Jan 10 20:38:36 <PuffTheMagic> and same in vi/vim
Jan 10 20:38:43 <PuffTheMagic> if i hit backspace to delete shit
Jan 10 20:38:45 <PuffTheMagic> bye bye cursor
Jan 10 20:38:58 <PuffTheMagic> or if i use arrow to go back in vi
Jan 10 20:39:00 <PuffTheMagic> bye cursor
Jan 10 20:39:11 <dtzWill> oh
Jan 10 20:39:12 <dtzWill> okay
Jan 10 20:39:13 <dtzWill> well
Jan 10 20:39:18 <dtzWill> add that to the issue?
Jan 10 20:39:23 <dtzWill> it'll probably be a quick fix, sorry
Jan 10 20:42:22 <PuffTheMagic> add to existing issue or new issue
Jan 10 20:42:39 <dtzWill> existing if you've found information about it
Jan 10 20:42:58 <PuffTheMagic> well u said u fixed it
Jan 10 20:43:00 <dtzWill> i just mean "please write that down somewhere that will for sure get fixed/you can beat me with later if not resolved"
Jan 10 20:43:02 <PuffTheMagic> so this sounds like a new bug
Jan 10 20:43:16 <dtzWill> no no i thought i fixed that as part of introducing the sdlfontgl stuff
Jan 10 20:43:16 <dtzWill> okay
Jan 10 20:43:19 <dtzWill> idc new bug works too
Jan 10 20:43:34 <dtzWill> (whatever you think is best is fine i'm sure)
Jan 10 21:05:31 <dtzWill> PuffTheMagic: pull req sent on charset stuff
Jan 10 21:05:59 <PuffTheMagic> ok
Jan 10 21:06:07 <PuffTheMagic> i will play with that, fix the cursor ;)
Jan 10 21:08:33 <dtzWill> (you didn't open an issue for the cursor stuff, did you? (asking b/c i do'nt see it))
Jan 10 21:08:37 <dtzWill> fine if not, i'm on it now anyway
Jan 10 21:08:39 <dtzWill> just double checking
Jan 10 21:09:30 <PuffTheMagic> well one already exists for it
Jan 10 21:09:35 <PuffTheMagic> the vi cursor issue
Jan 10 21:09:39 * dtzWill nods
Jan 10 21:09:50 <dtzWill> everything is good i just wanted to make sure i was on same page
Jan 10 21:15:10 <dtzWill> should be fixed, pull req sent ^.^
Jan 10 21:15:40 <dtzWill> told ya you did the hard work in narrowing it down ^.^
Jan 10 21:18:28 <PuffTheMagic> dtzWill, where were you imagining I initialize the new maps
Jan 10 21:19:27 <dtzWill> hmm, hadn't given that too much thought.
Jan 10 21:20:36 <dtzWill> preferrably early-ish.
Jan 10 21:20:57 <dtzWill> perhaps initialize them in the SDLCore/SDLTerminal constructor (or a helper method called from the constructor?)
Jan 10 21:21:23 <dtzWill> you could throw it in initCustom (or call it from there) in sdlcore.cpp also
Jan 10 21:23:21 * dtzWill is eager to see this. also line drawing is broken until we at least define those chars :)
Jan 10 21:23:49 <dtzWill> also lmk if you think my stuff isn't working.  it isn't really tested except in the "empty mapping" case
Jan 10 21:24:42 <PuffTheMagic> so CharMapping_t charMappings[MAX_CHARSETS];
Jan 10 21:25:17 <PuffTheMagic> why do u have #define MAX_CHARSETS 10
Jan 10 21:25:25 <dtzWill> well i have it at 12
Jan 10 21:25:38 <PuffTheMagic> there was already an enum for this
Jan 10 21:25:38 <PuffTheMagic> TSCharset_t
Jan 10 21:25:43 <dtzWill> well
Jan 10 21:25:44 <PuffTheMagic> in terminalstate.hpp
Jan 10 21:25:47 <dtzWill> i know
Jan 10 21:25:52 <dtzWill> TS_CS_MAX
Jan 10 21:25:59 <dtzWill> i need to refactor all this anyway
Jan 10 21:26:06 <dtzWill> it doesn't make sense OO-wise at all, lol :3
Jan 10 21:26:10 <Brybry> yeah
Jan 10 21:26:17 <PuffTheMagic> doesnt make sense
Jan 10 21:26:22 <Brybry> we have parent sdlcore relying on stuff in sdlterminal :D
Jan 10 21:26:25 <PuffTheMagic> i think the enum makes perfect sense
Jan 10 21:26:25 <dtzWill> but since SDLFontGL is the top-level class atm, i was trying very very hard not to pull up various states
Jan 10 21:26:28 <dtzWill> Brybry: yep
Jan 10 21:26:46 <dtzWill> Brybry: i spent a while trying to fix that, but i figured i'd be better off waiting until this works
Jan 10 21:26:48 <dtzWill> then refactoring it
Jan 10 21:27:00 <PuffTheMagic> dtzWill, the default for slot 1 and 2 should be TS_CS_G0_ASCII and TS_CS_G2_ASCII
Jan 10 21:27:05 <PuffTheMagic> s/G2/G1/
Jan 10 21:27:18 <dtzWill> PuffTheMagic: good. i wasn't sure, and figured you'd know and set them properly
Jan 10 21:27:30 <dtzWill> so \o/ for you being on that
Jan 10 21:27:59 <dtzWill> Brybry: i'd certainly welcome any help/comments regarding how to better structure it all, and would be happy to do a bunch of the work
Jan 10 21:28:09 <dtzWill> already, introducing the charset state pushed /more/ terminal state into sdlcore
Jan 10 21:28:28 <dtzWill> but one of those things where at some point i just wanted it to work :/
Jan 10 21:28:30 <dtzWill> my design-fu is weak :(
Jan 10 21:29:06 <Brybry> I'm currently beating my head against the role file wall
Jan 10 21:29:43 <dtzWill> Brybry: errr, what?
Jan 10 21:29:55 <dtzWill> oh you mean what role each file has?
Jan 10 21:30:06 <PuffTheMagic> dtzWill, but u didnt use the enum to set the defaults so where are the defaults currently set
Jan 10 21:30:54 <dtzWill> see line 60 of terminalstate.cpp
Jan 10 21:31:07 <dtzWill> oh well then set few lines down
Jan 10 21:31:11 <dtzWill> that's the defaults?
Jan 10 21:32:05 <PuffTheMagic> hmm
Jan 10 21:32:12 <PuffTheMagic> so before that is when i should set the custom maps
Jan 10 21:32:23 <dtzWill> err, why?
Jan 10 21:32:28 <dtzWill> just as long as they're ready at render time
Jan 10 21:33:14 <dtzWill> but that wouldn't be a bad place, either, i just mean you don't /have/ to ensure you do it before AFAICT
Jan 10 21:34:58 <Brybry> in the old sdlterminal I did something like https://gist.github.com/c7f90cbc337d0fbd3958 so that I could register a second lunaservice handle under the same app but either I have a typo in the wterm one or it works differently for hybrid apps
Jan 10 21:35:17 <dtzWill> hrrm. i see.
Jan 10 21:36:37 <dtzWill> PuffTheMagic: also the values seem hardcoded in resetTerminal() also, FWIW
Jan 10 21:36:50 <dtzWill> (I can't comment on whether or not that's correct)
Jan 10 21:45:10 <PuffTheMagic> dtzWill, so how do i set the active slot with your setup
Jan 10 21:45:30 <dtzWill> PuffTheMagic: should already be done by virtue of the code that adjusts chars by the active slot
Jan 10 21:46:37 <PuffTheMagic> http://pastebin.com/zS4BtP9s
Jan 10 21:46:42 <PuffTheMagic> i have something like that to test
Jan 10 21:47:03 <dtzWill> sure.
Jan 10 21:47:13 <PuffTheMagic> but nothing
Jan 10 21:47:13 <dtzWill> so any text that uses those charsets will use those mappings
Jan 10 21:47:32 <dtzWill> since entirely separate from the API to populate/define the character mappings
Jan 10 21:47:38 <PuffTheMagic> ./src/plugin/terminal/terminalstate.cpp:        if (getShift() && getG0Charset() == TS_CS_G0_SPEC && c>95) c = c + 128;
Jan 10 21:47:43 <dtzWill> is the actual rendering API which says "the charset for this tate is $FOO$"
Jan 10 21:48:25 <dtzWill> *the slots for this text are 'slot1' and 'slot2', as defined by the associated graphicsstate
Jan 10 21:48:27 <PuffTheMagic> line 1142 and 1143
Jan 10 21:48:36 <PuffTheMagic> in terminalstate.cpp
Jan 10 21:48:45 <PuffTheMagic> is where the magic used to happen
Jan 10 21:48:56 <PuffTheMagic> are those lines not needed any more?
Jan 10 21:49:30 <PuffTheMagic> like are we doing the +128 method or is there something else to set the default slot
Jan 10 21:49:43 <dtzWill> is 'getShift' the 'which slot is active' lookup?
Jan 10 21:49:49 <PuffTheMagic> yes
Jan 10 21:50:07 <dtzWill> i'm sorry, i thought you automatically encoded the character in the top 128 of the 'char' range if slot2 was active
Jan 10 21:50:52 <PuffTheMagic> well it is sorta
Jan 10 21:51:00 <dtzWill> i only pushed down the infrastructure so far as to hook the rendering to the graphicsstate for the given text
Jan 10 21:51:19 <dtzWill> which defines the two slots for the character (Well range of characters, but that's just an optimization)
Jan 10 21:51:21 <PuffTheMagic> idk what you mean by that
Jan 10 21:51:51 <PuffTheMagic> how does your code know what slot is active?
Jan 10 21:52:23 <dtzWill> if the character uses the top 128 it's slot 2
Jan 10 21:52:29 <dtzWill> if it's in the bottom 128 it's slot 1
Jan 10 21:52:38 <dtzWill> which is active is encoded in the character accordingly
Jan 10 21:52:54 <dtzWill> hmm
Jan 10 21:53:17 <PuffTheMagic> this font loading crash is getting annoying
Jan 10 21:53:45 <dtzWill> crash?! o__O
Jan 10 21:54:12 <PuffTheMagic> every other time i do make test the plugin does nto load the font
Jan 10 21:54:21 <PuffTheMagic> and the plugin exits
Jan 10 21:54:25 <PuffTheMagic> crash is prob wrong
Jan 10 21:54:47 <dtzWill> that's strange :(
Jan 10 21:55:25 <PuffTheMagic> ok so forget about that for now
Jan 10 21:55:38 <dtzWill> okay so the way we render
Jan 10 21:55:51 <dtzWill> is each chracter has a graphics state
Jan 10 21:55:53 <dtzWill> TSLineGraphicsState_T
Jan 10 21:56:22 <dtzWill> and the code i added uses that to render the text
Jan 10 21:56:34 <dtzWill> apparently the TSLineGraphicsState_t does not encode the active slot
Jan 10 21:57:11 <dtzWill> which could mean it's not a per-character setting, or that the text itself should encode that by which half of the 256 'char' range is stored
Jan 10 21:57:40 <dtzWill> if it /is/ a per character setting than we need that information in TSLineGraphicsState_t somehow, since that's how we manage the per-character non-text state
Jan 10 21:57:59 <dtzWill> (or encode it in the character itself at insert time, just "if (getShift()) c+= 128" (or !getShift() or whatever))
Jan 10 21:58:37 <dtzWill> that last approach assumes one can't move cursor around and change the encoding for a character like you can a color, or at least mandates we handle that properly
Jan 10 22:01:29 <dtzWill> yes
Jan 10 22:01:46 <dtzWill> afaict, from looking at http://vt100.net/docs/vt102-ug/chapter5.html#S5.5.2.16
Jan 10 22:02:35 <dtzWill> each terminal character can be 0->254, but each 'ROM' only maps half the set
Jan 10 22:02:41 <dtzWill> so you have commands to set slot1/slot2 and whatnot
Jan 10 22:03:28 <PuffTheMagic> well if u look at mc
Jan 10 22:03:45 <PuffTheMagic> the line drawing chars show up as ascii chars in the 0-127 range
Jan 10 22:03:55 <dtzWill> right
Jan 10 22:04:04 <PuffTheMagic> so the terminal set absolutely does not go higher than 127
Jan 10 22:04:05 <dtzWill> but they'll set shift for those, right?
Jan 10 22:04:17 <dtzWill> which means we internally store them as 'shifted' characters, aka += 128
Jan 10 22:04:28 <PuffTheMagic> right
Jan 10 22:04:43 <PuffTheMagic> so i could add the shift state to the graphics state struct
Jan 10 22:04:46 <PuffTheMagic> if its not there already
Jan 10 22:04:48 <dtzWill> lol
Jan 10 22:04:51 <dtzWill> noooo
Jan 10 22:04:53 <dtzWill> i mean
Jan 10 22:04:54 <dtzWill> you could
Jan 10 22:04:58 <dtzWill> or you could take advantage
Jan 10 22:05:02 <dtzWill> of everything taht exists already
Jan 10 22:05:07 <dtzWill> and just go if (getShift()) c+= 128
Jan 10 22:05:13 <PuffTheMagic> i did that
Jan 10 22:05:16 <PuffTheMagic> and nothing happens
Jan 10 22:05:46 <dtzWill> and slot1/slot2 are set (via escape commands or w/e) to the correct encodings?
Jan 10 22:06:37 <PuffTheMagic> yes
Jan 10 22:06:42 <dtzWill> because AFAICT the code that actually populates the g0/g1 charsets for the  TSLineGraphicsState_t doesn't exist yet
Jan 10 22:06:47 <dtzWill> but if you added that then good
Jan 10 22:06:56 <PuffTheMagic> wait
Jan 10 22:07:05 <PuffTheMagic> i didnt add anything new besides the stuff to populate the maps
Jan 10 22:08:13 <dtzWill> we probably ened to extend addGraphicsState
Jan 10 22:08:16 <dtzWill> to include the desired charsets
Jan 10 22:08:28 <dtzWill> and set them to m_currentGraphicSTate.g0charset/etc
Jan 10 22:08:33 <dtzWill> anyway i gotta run, i'm sorry. bbl
Jan 10 22:10:03 <PuffTheMagic> no we dont need to extent addGraphicsState
Jan 10 22:27:16 <PuffTheMagic> dtzWill, i think u went way overboard with some of this code
Jan 10 22:35:40 <dtzWill> conceivably.  hard to discuss without describing what you mean, though :(
Jan 10 22:36:15 <dtzWill> you sure you can't just do the if(getshift()) c+= 128; bit i mentioned? that and populating the mappings and things should work, no?
Jan 10 22:38:33 <dtzWill> PuffTheMagic: lmk when you get back, and if i'm not here couldja describe what you think is wrong/overboard?
Jan 10 22:38:51 <dtzWill> some of it might have more reason than you think, others might be wrong.  either way seems worth resolving :)
Jan 10 22:39:04 <PuffTheMagic> yes i am sure
Jan 10 22:39:28 <PuffTheMagic> the problem is that you are not using getG0Charset() and getG1Charset() to set the slots
Jan 10 22:39:35 <dtzWill> that's
Jan 10 22:39:38 <dtzWill> not a problem
Jan 10 22:39:39 <dtzWill> sigh
Jan 10 22:39:42 <PuffTheMagic> it is
Jan 10 22:39:46 <dtzWill> getG0Charset is prat of the current terminal state
Jan 10 22:39:56 <dtzWill> which is used when you add characters
Jan 10 22:40:01 <dtzWill> to poulate the associated graphicsstate
Jan 10 22:40:05 <dtzWill> which is used to render the text
Jan 10 22:40:13 <dtzWill> i dind't build any of that, that all already existed
Jan 10 22:40:53 <dtzWill> only problem is we only transfer the color inforatmon from the terminal state into the associated graphicsstate, despite having charset fields in that structure
Jan 10 22:41:54 <PuffTheMagic> putting this:
Jan 10 22:41:54 <PuffTheMagic> m_slot1 = state.g0charset;
Jan 10 22:41:54 <PuffTheMagic> 	m_slot2 = state.g1charset;
Jan 10 22:42:00 <PuffTheMagic> in setGraphicState is totally wrong
Jan 10 22:42:08 <dtzWill> ?
Jan 10 22:42:14 <PuffTheMagic> the charsets get set independently of the graphics state
Jan 10 22:42:26 <PuffTheMagic> so by putting those there, you are missing changes to the charset
Jan 10 22:42:32 <dtzWill> okay
Jan 10 22:42:38 <dtzWill> hold on
Jan 10 22:42:40 <dtzWill> to be clear
Jan 10 22:42:51 <PuffTheMagic> thats why the getter functions exist
Jan 10 22:42:54 <dtzWill> the two slots are properties of each character, right?
Jan 10 22:43:01 <PuffTheMagic> no
Jan 10 22:43:09 <dtzWill> so they ARE screen-wide settings?
Jan 10 22:43:11 <dtzWill> $#%^!##!%^#%
Jan 10 22:43:11 <dtzWill> lol
Jan 10 22:43:36 <PuffTheMagic> no that is sorta the wrong view also
Jan 10 22:44:12 <dtzWill> well seems to me that we have a terminal state, that tracks the current values of the slots, colors, etc
Jan 10 22:44:21 <PuffTheMagic> correct
Jan 10 22:44:25 <dtzWill> when you insert a character, you use those fields to insert that character
Jan 10 22:44:32 <PuffTheMagic> yes
Jan 10 22:44:35 <dtzWill> okay
Jan 10 22:44:36 <dtzWill> so
Jan 10 22:44:37 <dtzWill> to render that later
Jan 10 22:44:40 <dtzWill> you store that state
Jan 10 22:44:42 <dtzWill> with that chracter
Jan 10 22:44:46 <dtzWill> saaayyy in the graphicstate
Jan 10 22:44:54 <dtzWill> which alread has fields for it :(
Jan 10 22:45:06 <dtzWill> and if we just set them there things'll work? :(
Jan 10 22:45:21 <PuffTheMagic> i guess, let me see
Jan 10 22:46:55 <PuffTheMagic> i guess we just need to update m_slot1 = state.g0charset;
Jan 10 22:46:55 <PuffTheMagic> 	m_slot2 = state.g1charset;
Jan 10 22:47:00 <PuffTheMagic> in other places as well
Jan 10 22:47:40 <dtzWill> well
Jan 10 22:47:49 <dtzWill> why not use all the existing infrastructure
Jan 10 22:47:52 <dtzWill> for associating state with text
Jan 10 22:48:10 <PuffTheMagic> ITS NOT WORKING!
Jan 10 22:48:16 <dtzWill> since that's significantly more likely to actually work when it comes to removing/adding characters
Jan 10 22:48:28 <dtzWill> oh, did you extend addGraphicsState?
Jan 10 22:48:30 <dtzWill> lol
Jan 10 22:48:40 <dtzWill> you saying i was wrong and we shouldn't suggests you rejected the idea
Jan 10 22:48:47 <dtzWill> not that you tried it and i was wrong.  i'm sorry
Jan 10 22:49:00 <PuffTheMagic> no, i havent changed addGraphicsState yet
Jan 10 22:49:32 <PuffTheMagic> but setting the new maps and and doing +128 when shift is true is not enough
Jan 10 22:49:40 <dtzWill> also if you could tone down the hostility and attackingness like 10 degrees that'd be great.  Especially regarding my understanding of the code, epsecially my understanding of the code I wrote.  I'm not always right regardless, but come on-- we're on the same side, right? :)
Jan 10 22:49:47 <dtzWill> PuffTheMagic: right, b/c we don't update the graphicsstate properly (yet)
Jan 10 22:49:53 <dtzWill> as mentioned in the commit message :(
Jan 10 22:50:25 <PuffTheMagic> :/
Jan 10 22:50:26 <PuffTheMagic> newState->g0charset = m_defaultGraphicsState.g0charset;
Jan 10 22:50:31 <PuffTheMagic> thats where getG0 goes
Jan 10 22:51:05 <dtzWill> well
Jan 10 22:51:06 <dtzWill> no
Jan 10 22:51:21 <dtzWill> do you see it querying terminalstate for the colors?
Jan 10 22:51:41 <PuffTheMagic> I see where u have TODO: implment this properly
Jan 10 22:51:49 <PuffTheMagic> and then u use the default instead of current
Jan 10 22:51:51 <dtzWill> it goes as arguments to it, or if you're right then it should have no arguments and populate things entirely from the current terminalstate
Jan 10 22:51:56 <dtzWill> indeed i did
Jan 10 22:52:13 <dtzWill> b/c nowhere else does it reference the current
Jan 10 22:52:37 <PuffTheMagic> i am so confused what you are telling me to do
Jan 10 22:53:45 <PuffTheMagic> all i know is that graphicsInfo.slot1 = (int)m_slot1; is always 0
Jan 10 22:53:48 <PuffTheMagic> and it never gets changed
Jan 10 22:53:51 <dtzWill> yep
Jan 10 22:53:59 <dtzWill> i'll make a commit doing what i had in mind
Jan 10 22:54:05 <dtzWill> that should work with your +=128 and mappings testing
Jan 10 22:54:13 <dtzWill> or at least when combined will hopefully make things clearer
Jan 10 22:54:35 <dtzWill> actually damn i have to go for real now.  should be back in 30 sorry :)
Jan 10 23:09:24 <PuffTheMagic> dtzWill, when u come back dont start coding, i think i did what u suggested
Jan 10 23:10:04 <PuffTheMagic> but now I discovered why we cant use the +128 method
Jan 10 23:21:31 <PuffTheMagic> we cant just add 128 to everything because it breaks non printable char processing like tabs and line returns etc
Jan 11 00:02:35 <Brybry> <PuffTheMagic> this font loading crash is getting annoying <-- I ran into this, the font file size was 0 so palm-package or somewhere in the install process it borked (maybe with the debug symbols we go over some package limit, I have no idea)
Jan 11 00:13:04 <PuffTheMagic> we are packaging less fonts now
Jan 11 00:13:12 <PuffTheMagic> i dont think its a size of package issue
Jan 11 00:26:26 <dtzWill> hooray
Jan 11 00:26:31 <dtzWill> i'm back, have code doing what i suggested
Jan 11 00:26:33 <dtzWill> i see re:128
Jan 11 00:26:36 <dtzWill> but we can for printables
Jan 11 00:26:38 <dtzWill> i'll do that
Jan 11 00:26:38 <dtzWill> shit
Jan 11 00:29:16 <dtzWill> shit==kitchen exploded
Jan 11 00:29:33 <dtzWill> errr jar fell out of fridge, *kablooey*, i'm in other room haha
Jan 11 00:29:35 <dtzWill> anyway
Jan 11 00:32:21 <PuffTheMagic> so your code is working?
Jan 11 00:32:48 <Brybry> lol, PuffTheMagic :D
Jan 11 00:32:59 <Brybry> it's so obvious
Jan 11 00:33:31 <Brybry> if you do an ipk install while the file handle is still open to that font...
Jan 11 00:33:37 <Brybry> (aka wterm is still running)
Jan 11 00:33:55 <Brybry> though honestly it shouldn't be open, I would swear we close those pretty early
Jan 11 00:34:16 <dtzWill> i changed some of that, maybe i messed that up somehow?
Jan 11 00:34:58 <PuffTheMagic> Brybry, i suspected it had to do with how fonts were closed down
Jan 11 00:35:12 <PuffTheMagic> dtzWill, so how does your code differ from what I pushed
Jan 11 00:35:18 <dtzWill> i haven't checked
Jan 11 00:35:22 <dtzWill> i'll check in a bit
Jan 11 00:48:57 <Brybry> PuffTheMagic: do you have a non-HP bluetooth keyboard?
Jan 11 00:49:24 <dtzWill> looks like i have some lines working
Jan 11 00:49:33 <dtzWill> (using only the mapping from what you had above)
Jan 11 00:49:58 <dtzWill> i had a small bug in my sdlfontgl stuff (it _was_ entirely untested, after all)
Jan 11 00:50:28 <dtzWill> oh goodie you pushed the mappings
Jan 11 00:50:28 <dtzWill> \o/
Jan 11 00:51:24 <dtzWill> well 'bug' is that is assumed if you reset the glyph cache you'd reset the mappings
Jan 11 00:51:27 <dtzWill> but that seems wrong
Jan 11 00:51:33 <dtzWill> but just saying as far as bugs go :P :3
Jan 11 00:54:06 <dtzWill> PuffTheMagic: why the '95' comparison?
Jan 11 00:54:31 <dtzWill> not a challenge i just don't know what 95 is or what that's important
Jan 11 00:56:32 <dtzWill> oh and what happened to TS_CS_NONE?
Jan 11 01:01:34 <PuffTheMagic> Brybry, no i dont
Jan 11 01:01:43 <PuffTheMagic> TS_CS_NONE does not exist
Jan 11 01:02:00 <PuffTheMagic> and the 95 comparison is because +128 breaks shit
Jan 11 01:02:13 <PuffTheMagic> its breaks handling non printable chars like tab
Jan 11 01:02:16 <PuffTheMagic> new line
Jan 11 01:02:18 <PuffTheMagic> backspace
Jan 11 01:02:19 <PuffTheMagic> etc
Jan 11 01:09:34 <dtzWill> errr
Jan 11 01:09:38 <dtzWill> oh but TS_CS_NONE is a useful placeholder
Jan 11 01:09:42 <dtzWill> for memset'd structs O:)
Jan 11 01:15:27 <PuffTheMagic> initialize to the actual defaul
Jan 11 01:15:37 <dtzWill> well no
Jan 11 01:15:51 <dtzWill> well
Jan 11 01:16:25 <dtzWill> tell me if what i have doesn't work.  the placeholder is useful for not overwriting the previousstate
Jan 11 01:16:44 <dtzWill> if we're "uninitialized" (That is, no one's overridden us with an escape code or something)
Jan 11 01:18:30 <PuffTheMagic> do u have something for me to look at?
Jan 11 01:18:46 <dtzWill> yeah sorry was documenting it
Jan 11 01:19:11 <dtzWill> https://github.com/PuffTheMagic/wTerm/pull/39
Jan 11 01:19:32 <dtzWill> "works here", doesn't seem to break non-printable parsing and the charset vttest looks right for what we're setting
Jan 11 01:20:27 <PuffTheMagic> dtzWill, we still cant use the +128 stuff
Jan 11 01:20:33 <dtzWill> i'm sorry?
Jan 11 01:20:35 <PuffTheMagic> the >95 its not good
Jan 11 01:20:59 <dtzWill> (why not/what's wrong?)
Jan 11 01:21:29 <PuffTheMagic> because there are chars less than 95 that are valid for replacement
Jan 11 01:21:42 <dtzWill> right
Jan 11 01:21:47 <dtzWill> did you see the code i pushed?
Jan 11 01:21:52 <dtzWill> there's no 95 comparison
Jan 11 01:22:42 <PuffTheMagic> it should be >32 <127
Jan 11 01:22:55 <dtzWill> it's behind a isPrintable()
Jan 11 01:23:15 <dtzWill> we apply shift to printables or those nonprintables that we don't handle
Jan 11 01:24:58 <dtzWill> ah, maybe we should only apply to printable (which is the [32,127) range you mention)
Jan 11 01:25:58 <dtzWill> anyway dinner bbiab
Jan 11 01:26:27 <dtzWill> (If you don't like the getShift logic for some resaon, i'm less confident about that other than it seems to work just fine, and have my blessing to replace as you see fit)
Jan 11 01:27:18 <dtzWill> gl, etc, hopefully what's pushed at least is a good foundation or something :)
Jan 11 01:40:51 <PuffTheMagic> dtzWill, well your code works so... i guess i will leave it at that for now
Jan 11 02:04:07 <PuffTheMagic> dtzWill, pinger
Jan 11 02:15:02 <PuffTheMagic> dtzWill, i believe there is a bug in the font code that calculates the positioning of characters on the screen
Jan 11 02:26:25 <dtzWill> hmm. bummer :(
Jan 11 02:26:28 <dtzWill> what's the bug?
Jan 11 02:28:10 <dtzWill> (what are you seeing that's wrong? :()
Jan 11 02:28:27 <PuffTheMagic> well i think there are actually 2 bugs
Jan 11 02:28:34 <PuffTheMagic> bug 1 is found with every font i try
Jan 11 02:28:39 <dtzWill> lol
Jan 11 02:28:45 <PuffTheMagic> there seems to be an extra pixel between each line
Jan 11 02:28:53 <dtzWill> oh
Jan 11 02:28:55 <dtzWill> lol
Jan 11 02:28:57 <PuffTheMagic> which causes the vertical lines to appear as dashes
Jan 11 02:29:03 <dtzWill> mmhmm
Jan 11 02:29:05 <dtzWill> that's an easy fix
Jan 11 02:29:20 <PuffTheMagic> the second bug happens when i try another fix
Jan 11 02:29:25 <PuffTheMagic> font i mean
Jan 11 02:29:33 <PuffTheMagic> like DejaVuSansMono
Jan 11 02:29:33 <dtzWill> strange though since i thought i positioned them in the same manner that the SDL code did.  shrug, i'll look into it
Jan 11 02:29:43 <PuffTheMagic> the horizonal dashes have spaces between them
Jan 11 02:29:49 <PuffTheMagic> and thus results in shit not lining up
Jan 11 02:29:58 <dtzWill> well
Jan 11 02:30:03 <dtzWill> everything should be gridded perfectly always
Jan 11 02:30:07 <dtzWill> but it's possible to have breaks
Jan 11 02:30:20 <dtzWill> sounds like we just overestimate the sizes
Jan 11 02:30:42 <PuffTheMagic> are u doing a ceil where it should be a floor maybe?
Jan 11 02:31:37 <dtzWill> never intentionally invoke either; misc rounding is always possible
Jan 11 02:33:32 <dtzWill> err
Jan 11 02:34:00 <dtzWill> when you say "thus reults in shit lining up" do you mean "when i run mc with dejavusansmono shit doesn't line up"?
Jan 11 02:34:23 <PuffTheMagic> not lining up
Jan 11 02:34:28 <dtzWill> b/c it's not like we position characters based on what's around them, their position is calculated directly
Jan 11 02:34:29 <PuffTheMagic> and ya that is with dejavusansmono
Jan 11 02:34:34 <dtzWill> kk yeah, b/c that's what i'm seeing
Jan 11 02:34:43 <PuffTheMagic> i tried veramono
Jan 11 02:34:49 <PuffTheMagic> but that doesnt have linedrawing chars
Jan 11 02:34:57 <PuffTheMagic> im gonna test with other "mono fonts" too
Jan 11 02:36:35 <PuffTheMagic> but for now if we can fix the 1 pixel gap between rows i would be happy with current font
Jan 11 02:36:47 <PuffTheMagic> then we just have to fix that "cant load fonts" every other install issue
Jan 11 02:37:05 <dtzWill> well fwiw the only reason that didn't happen before is that we *stretched* the glyphs to fit the grid, lol :(
Jan 11 02:37:18 <dtzWill> which i stopped doing b/c it seemed wrong and resulted in strangeness sometimes
Jan 11 02:37:25 <dtzWill> but maybe there's something to that :/
Jan 11 02:37:47 <dtzWill> well i'll make a pass too to make sure i'm not also doing something wrong
Jan 11 02:37:55 <PuffTheMagic> dtzWill, idk whats proper either, im new to all this, im just going by what it look like on my desktop terms
Jan 11 02:38:01 <dtzWill> yep
Jan 11 02:38:14 <dtzWill> agreed, we should fix it _somehow_ I'm just not sure how :)
Jan 11 02:41:28 <PuffTheMagic> so insteresting, Konsole only supports like 5 fonts
Jan 11 02:41:52 <PuffTheMagic> and it does not support a few mono fonts that I know dont support box drawing symbols
Jan 11 02:42:29 <PuffTheMagic> too bad droid sans mono doesnt support box drawing chars
Jan 11 02:42:36 <PuffTheMagic> its a really clean font on the TP screen
Jan 11 02:44:56 <PuffTheMagic> jmm
Jan 11 02:45:03 <PuffTheMagic> liberation mono looks perfect
Jan 11 02:45:11 <PuffTheMagic> no inappropriate gaps
Jan 11 02:45:22 <PuffTheMagic> we are def not doing "something" right
Jan 11 02:45:31 <PuffTheMagic> because they all look perfect on konsole
Jan 11 02:51:48 <dtzWill> hmm oh i have an idea
Jan 11 02:52:03 <dtzWill> here's hoping i'm right (err, you're right--i do have a bug) b/c if my code works then we're more SOL haha
Jan 11 02:52:39 <dtzWill> brb
Jan 11 02:52:51 <dtzWill> (in short i think i do something wonky with overlapping regions by a pixel)
Jan 11 02:53:16 <PuffTheMagic> i think i need to buy new memory
Jan 11 02:53:19 <dtzWill> mismatch between specifying base/width and pixels ranges (inclusive)
Jan 11 02:53:19 <PuffTheMagic> my pc keeps crashing
Jan 11 02:53:40 <PuffTheMagic> dtzWill, sorry to be putting all this font shit off on you
**** ENDING LOGGING AT Wed Jan 11 02:59:57 2012