--- Log for 05.11.112 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 2 months and 7 days ago 00.00.08 # <[Saint]> yep, that's right...2 00.00.18 # <[Saint]> and wodz did them both, quite recently. 00.00.18 # makes the radio version easy then :) 00.00.33 # <[Saint]> hahaha, not the point, but...yes! 00.04.14 # any thoughts on min/max params for %iu? 00.04.33 # im thinking %iu(min, max) but not sure how to make %iu(X) work 00.04.46 # should that be max only or min only? or just not allow that one? 00.05.09 # (max/min == max number of lines to try and min lines to use even if the actual viewport uses less) 00.05.53 # <[Saint]> "min lines to use even if the viewport uses less"? 00.06.04 # <[Saint]> ....so, display lines that will never be...errr, displayed? 00.06.39 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 00.06.41 # so if you have %iu\n\n%Iu you can be sure it will fit nicely 00.07.34 # <[Saint]> I'm not even sure we should care about that. 00.08.08 # <[Saint]> it should just be two viewports, I'm not a fan of being able to call both %iu and %Iu in the same viewport. 00.09.21 # <[Saint]> I mean, I like it, but...it seems like it adds a lot of complication that could be avoided by just...not. 00.13.01 Quit n1s (Quit: Ex-Chat) 00.13.28 # well, say you've got room for total 6 lines, and your current track doesnt have tags so it only uses 1 line, nex track could use 4 00.13.49 # but if you've hardcoded it with seperate viewports you'll end up with lots of empty lines 00.14.44 # <[Saint]> with the alternative you'd have to code in an empty line anyway, though, no? 00.15.03 # <[Saint]> (as most cabbies have distinct current/next blocks) 00.15.16 # sure, one blank is better than 3 though 00.15.59 # <[Saint]> If the current track only uses one line when it has no tags, I'd say we're doing somthing wrong... 00.16.19 # <[Saint]> there's a heap of info that could be displayed in it's stead. 00.16.52 # i suppose 00.17.59 # <[Saint]> fallback to filename for track name, dir 2 (if exists) for Artist, dir 1 (if exists) for album, root if non exists, bitrate, etc. lots of stuff. 00.18.20 # <[Saint]> current git HEAD makes a half assed attempt at this. 00.18.48 # <[Saint]> its not just "Is this here? Nope...display nothing" 00.26.21 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 00.28.10 # [Saint]: you have a super fancy show-fucking-everything wps-code block right? how many lines does it do? 00.28.50 # <[Saint]> less than the maximum that can be displayed, that's for sure. 00.29.08 # <[Saint]> the absolute max on cabbie is something like 18 lines total. 00.29.39 # <[Saint]> (many of those are blank) 00.30.01 # haha, can you do one which will work nicely for 2,3,4,5 lines? 00.30.21 # actually, ignore me 00.30.45 # * JdGordon needs to tihnk a bit more 00.30.47 # and work :p 00.30.49 # <[Saint]> the "problem" with it, is that is bases the display of the next line based on the success of the previous checks. 00.31.27 Quit Horschti (Quit: Verlassend) 00.32.19 Quit Wardo (Read error: Connection reset by peer) 00.32.26 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 17.0/20121031065642]) 00.34.43 Part copper 00.38.18 Join Thra11 [0] (~thrall@87.115.113.147) 00.38.37 # has anyone looked at the code for the progress bar and volume bar with sliders recently? 00.38.39 # i think there is room to improve them 00.39.18 # im sure there is :) 00.39.27 # what in particular? 00.40.49 # on sec. im stepping out(switching to phone) 00.40.54 Part amayer 00.42.56 Join amayer_ [0] (~yaaic@18.sub-174-255-215.myvzw.com) 00.43.39 # JdGordon: let's say you set up a progress bar like so: 00.43.53 Quit crose (Quit: Leaving) 00.44.04 # %on(10,10,120,8) 00.44.14 # I'm on my phone so bear with me 00.44.46 # * [Saint] points out that firstly, that's nowhere near how you set up a progress bar. 00.45.24 # <[Saint]> and secondly, I'm fairly confident that %on isn't a real tag... 00.46.40 # that's %pb. if you switch the above progress bar to include a slider you would need to readjust the width to accomidate for the slider. and then adjust the the viewport to match. and them it doesn't line up with you backdrop 00.47.14 # didnt we have this conversation before? 00.47.17 # [Saint]: I'm on my phone(see autocorrect) 00.47.44 # <[Saint]> bare with me, or bear with me the slider does some weird magic I don't like that centers the slider image on the upper/lower bounds of the bar. 00.47.47 # I think you helped me fix a theme. but I'm not sure if we had this discussion or not 00.47.58 # <[Saint]> not ideal, but, easy to code around if you're expecting it. 00.48.54 # I've done 2 themes with sliders and its a huge pain to line them up with the background 00.49.08 # <[Saint]> center the bar in a viewport that == bar width+slider width, and it'll "just work" 00.50.29 # <[Saint]> or, it should, unless you're doing silly things that I'll adress if you're doing them. :P 00.50.57 # you mean put a %ac before the %pb? 00.51.56 # <[Saint]> whoah...no, alignment tags don't work like that (I think I pulled you up on that in a forum thread). 00.52.15 # <[Saint]> and, actually...now I rethink it, I know what you're talking about, and it *IS* a royal pain inthe ass. 00.52.18 # you did. you said not for a viewport. 00.52.38 # <[Saint]> well, read "not for a viewport" as "not for anything non-text" 00.53.07 Quit ender1 (Quit: All general statements are false. -- The Ultimate Law) 00.53.14 # so what do you mean by center the progress bar? 00.54.18 # <[Saint]> I believe I misunderstood your issue. 00.54.41 # <[Saint]> The problem you're having is that half the slider image gets cut off when it hits the upper/lower bounds? 00.56.16 # <[Saint]> perhaps show me an image of the issue you're having if it is hard to describe. 00.56.18 # my issue is that you need to adjust the width when you add a slider 00.58.00 # <[Saint]> there's no way you could not have to do so and still have it work with touch. 00.58.35 Quit djp_ (Quit: leaving) 00.58.37 # oh... that might be what I wasn't seeing. I didn't take into consideration the touch aspect 00.58.41 # <[Saint]> otherwise you could never do full/min volume, or seek/ 00.59.28 # <[Saint]> the exact middle of the slider image (with a slight preference for the left, iirc, in cases where there's no "middle" is used as the "marker" for the bar. 01.00.03 # <[Saint]> imagine there's a closing bracket in there where it should be, please. 01.00.37 Quit prof_wolfff (Ping timeout: 256 seconds) 01.00.46 # <[Saint]> fwiw, touch is really the only reason to use this. 01.01.09 # <[Saint]> ...maybe not even then. 01.01.24 # <[Saint]> It's likely easier to just make the "slider" a part of the bar image. 01.01.57 # <[Saint]> in fact, it definitely is easier. maybe not as graceful, but definitely easier. 01.02.39 # <[Saint]> oh...hmmm. 01.02.56 # you can't do that 01.03.25 # it lays the image and displays part of it. it doesn't move the image 01.03.53 # <[Saint]> yeah, I just looked at my code example that does that and took a deep gulp. 01.04.10 # <[Saint]> it's _possible_, it's not "easy" :) 01.04.44 # Haha oh ok 01.05.00 # <[Saint]> and it likely doesn't work anymore, actually. this seems to rely on broken draw ordering. 01.05.23 # * [Saint] needs to stop deliberately abusing breakages in the skin engine. 01.05.34 # [Saint]: will you be on here in about an hour? 01.06.43 # <[Saint]> If I'm not, my client will be. 01.06.59 # <[Saint]> I just thought, do you *need* it to be an absolutely fluid bar? 01.07.26 # <[Saint]> you could do it with bitmapstrips and the percent-played tag. 01.08.41 # <[Saint]> iff %played == 10, show foo, iff %played == 20, show bar, etc. Useful if you don't require the bar to have absolutely fluid motion. 01.09.15 # I would like it to be fluid. I listen to a lot of podcasts. so if I make a theme I would need it to work well with long audio 01.09.52 # <[Saint]> well, long or short, it would always break it into as many tuples as you give the condition. 01.10.27 *** Saving seen data "./dancer.seen" 01.10.36 # but I don't want the 100 slide bitmap that view with it 01.11.08 # goes with it* 01.11.25 # <[Saint]> well, realistically, 20 would be a bit of overkill as you're likely displaying the time in seconds/mins also. 01.11.30 # <[Saint]> ...but, I see your point. 01.12.01 # <[Saint]> It's just a quick visual reference. It needn't be pixel perfect...but, I'm anal too...so, can't talk here :P 01.12.34 # <[Saint]> were it a touch theme, I wouldn't suggest this. 01.12.46 # <[Saint]> the fact it isn't means corners can be cut here if needed. 01.12.52 # either way. my point is that there should be an easier way then exploiting theme engine bugs to do it. 01.13.38 # <[Saint]> It's not really that, it's more that it's non-obvious what the bar does when a slider gets added. 01.14.00 # <[Saint]> it's not an abuse, more...a lack of documentation telling you what is expected. 01.15.27 # [Saint]: ill have to send you an example when I get home(about an hour) 01.16.14 # <[Saint]> are you drawing the bar's backdrop with the bar itself? 01.16.36 # <[Saint]> as, iiuc, that will leave a "slider image/2" width block of nothing at either end of the bar. 01.16.44 # no 01.17.26 # <[Saint]> guess I need to see it. 01.17.35 # <[Saint]> I'll be here, or, not far. 01.17.40 # the background of the bar is on the backdrop 01.18.02 # <[Saint]> ah, yeah...that's a bad move all round. 01.19.40 # ??? 01.20.00 Quit Provel_ (Ping timeout: 245 seconds) 01.20.11 # I don't think I've seen any themes where that wasn't the case 01.20.42 # even the default theme does it that way 01.21.01 # <[Saint]> lots of themes on the themesite are copy/paste kludges from ancient themes. 01.21.23 # <[Saint]> as a side effect, very few people use modern syntax, and cabbie sets some really bad examples. 01.21.25 Quit nosa-j (Ping timeout: 260 seconds) 01.21.38 # * [Saint] is working on the cabbie part. 01.22.04 # * JdGordon is working to outdate that work! 01.22.28 # <[Saint]> for example, if you wanted to display the volume/progress bar in two or more places, you'd need two or more backdrops. 01.22.34 # Haha 01.22.43 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 01.23.03 # do you have a working theme that doesn't do this? 01.24.02 # <[Saint]> https://github.com/saint-lascivious/RaaA-CabbieV2 01.25.10 # <[Saint]> basically: %pb(0,0,-,-,image,progressbar,backdrop,progressbar-backdrop) 01.25.34 # <[Saint]> where "progressbar" and "progressbar-backdrop" are labels for pre-loaded bitmaps. 01.25.54 # ill check it out in 15 end. 01.26.04 # 15 when I get home 01.26.17 # <[Saint]> image is a define that says "draw the bar with this image" and backdrop is a define that says "use this backdrop for the bar" 01.26.33 # <[Saint]> both are followed by an identifier. 01.27.24 # <[Saint]> the wiki and/or manual should explain new bar behavior. 01.27.39 # <[Saint]> where new == the last 18months+ 01.29.11 Join nosa-j [0] (~m00k@184.76.254.130) 01.30.00 Quit Totalled (Quit: PETTAN PETTAN, TSURUPETTAN!) 01.30.07 # * amiconn wonders whether the Clip+ (and probably other targets where the display causes interference in mic recordings) deserves a special display mode for recording, which keeps the display disabled as long as the recording is actually running 01.30.36 # we do that for the fm screen, so sure 01.30.46 # (i.e. not while in standby or paused, so you can still adjust gain etc) 01.31.21 # IMO probably not a bad idea. The display sound on the clipv1 and clip+ are both rather loud. 01.31.56 # But it definitely should be disabled *only* when recording. 01.33.23 # * the-kyle just read "not while in standby or pause." Oops, sorry, I just repeated what was already expressed. 01.39.43 Join amayer [0] (~alex@72.25.53.76) 01.41.29 # <[Saint]> JdGordon: probably a good candidate for your dynamic refresh rate patch? 01.41.54 # ? 01.41.55 Quit amayer_ (Ping timeout: 248 seconds) 01.42.25 # <[Saint]> if refreshes are interfering, lessening them if possible couldn't hurt... 01.42.35 # sure 01.51.48 # [Saint]: It's not the refreshes that interfere, but the actual display operation 01.53.19 # [Saint]: do you have a working theme that is 320x240? that uses the method you were talking about for the progress bar? 01.53.49 # This is different from the FM interference on e.g. FM recorder and (old) Ondio FM, where there's no noise as long as the display content is static 02.09.55 Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) 02.19.25 # <[Saint]> amiconn: ohhh, OK. My mistake. 02.20.23 # <[Saint]> I thought it was screen refreshes, nano2g (one screen type only) suffers from noise due to screen refresh. 02.20.41 # <[Saint]> I thought that was the issue, apologies. 02.21.06 # <[Saint]> amayer: no. 02.21.32 # im looking at the other sizes now 02.22.23 # <[Saint]> the code for all of them is identical save for coordinates. 02.22.36 # <[Saint]> ones as good as another. 02.23.52 # i know. i was just wondering if there was one i could load on the simulator that i already have compiled 02.24.26 # <[Saint]> I just compile an SDL sim larger than any target I need. 02.24.34 # <[Saint]> it loads any theme. 02.24.42 # really? 02.24.47 # i didnt know that 02.25.24 # <[Saint]> smaller themes, larger themes will fail. 02.26.38 # <[Saint]> this is an "app type" specific thing, iirc. I think other targets need the backdrop to be the "screen dimensions". 02.26.59 # <[Saint]> app type should align smaller themes top left. 02.27.11 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 02.27.33 # [Saint]: is this something that needs changed? 02.27.36 # http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildap4.html#x20-408000D.23 02.27.38 # beside example it says "%ax%V(...)" 02.27.53 # <[Saint]> no. 02.28.09 # <[Saint]> that's a very specific case. 02.28.19 # so that works? 02.28.39 # but %al%V(...) wont? 02.28.53 # <[Saint]> yes, but it isn't an alignment tag per se. 02.29.25 # <[Saint]> that will ONLY work with view ports, not text. 02.29.48 # what is %al? 02.30.05 # <[Saint]> it means "mirror the vp horizontally if Lang == RTL 02.30.13 # ah, right 02.30.15 # <[Saint]> JdGordon: align left, no? 02.30.37 # * JdGordon needs to get rid of the rtl support tags and just make them implicit 02.30.46 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 02.30.52 # <[Saint]> prior response was for amayer , sorry. 02.30.58 # <[Saint]> I'm slow on my mobile. 02.32.17 # <[Saint]> JdGordon: if you did so, you'd need a way to pass "don't fiddle with my viewport alignments EVER"…but, pretty sure I've mentioned that. 02.32.54 # but that doesnt make any sense 02.33.20 # <[Saint]> rather, a way to pass "don't fiddle with THIS view ports alignment ever" 02.35.09 # <[Saint]> I can only imagine it causing issues if the author was going for a specific effect, but...it's nice to not force things like this IMO. 02.35.28 # <[Saint]> Or, if you do force it, offer an (optional) way out. 03.04.39 # [Saint]: this works alot better then what i was trying before 03.04.40 # %pb(0,0,298,11,C,backdrop,D,slider,E) 03.04.43 # is it really necessary for the slider to overhang the edges of the progress bar tho at the beginning and end? 03.10.14 # <[Saint]> yes. 03.10.21 # *reads back and answers his own question* 03.10.29 *** Saving seen data "./dancer.seen" 03.11.37 # <[Saint]> you could always leave a slider_image/2 transparent gap at the beginning and end of the bar images. 03.12.15 # that might work i will try it 03.12.37 # now for my next question: 03.12.39 # I cant seem to put pb_empty and pb_full in 1 image as a sprite(top and bottom) 03.12.41 # is that possible? 03.13.16 # <[Saint]> no, bars don't allow subimages. 03.13.37 # boo... 03.19.51 # [Saint]: that makes it hang even further over the edge 03.20.09 # would i need to add more padding on the slider? 03.23.37 # nvm. that doesnt work 03.24.04 # [Saint]: did you get anywhere with the "check if file exists" patch? 03.24.09 # i.e is it useful? 03.27.02 # <[Saint]> I think it is, yes. 03.27.25 # <[Saint]> I didn't get very far with it, but I definitely think it is useful. 03.46.18 # <[Saint]> amayer: sorry, I messed that up. 03.47.03 # <[Saint]> does adding slider_image_width/4 tarnsparent pixel to the slider image make it look riht? 03.47.42 # * [Saint] be type of today badlingly 03.50.04 # no it doesnt because then the progress bar tag just takes the new slider_image width and divides that by 2 03.50.04 # <[Saint]> oh, shit...no. 03.50.48 # you could add 1000px to each side of the slider bar and it would still center it 03.50.59 # (and error because its too wide for the screen) 03.52.00 Join Thra11_ [0] (~thrall@15.154.125.91.dyn.plus.net) 03.52.35 # <[Saint]> it was a long time ago now, but, this might just have been why I gave up on the idea of using a slider for my cabbie raaa variants. 03.55.12 Quit Thra11 (Ping timeout: 244 seconds) 03.55.29 # now that i think about it coding this to work the way i am describing would be kinda tricky 03.59.17 # <[Saint]> ugly as fuck: you could use two progress bars conditionally, one for volume 0-50% and one for volume 50-100% and swap them out like that. the volume == 0-50% slider bitmap would be twice the width of the visible image, with the entire left side comprised of transparency, the reverse for the volume == 50-100% case. 03.59.54 # what the shitsnacks are you talking about? 04.00.16 # <[Saint]> that way, when it did its 'center the slider image' thing, you'd only have transparency out of view. 04.00.38 # [Saint]: ...i think my morals would prevent me from writing code to do that 04.01.04 # <[Saint]> it'd work.... ;) 04.01.18 # that it would 04.01.23 # <[Saint]> and I did say it'd be ugly. 04.01.39 # would there be a flicker when they switched? 04.02.05 # <[Saint]> yeah, you read my mind. it's possible, yes. 04.02.10 # actually, you would see the slider jump back when they switched 04.02.32 # <[Saint]> ahhhhh, yes, you would too. 04.02.48 # so that wont even work 04.03.09 # <[Saint]> JdGordon: the weird, non-obvious yet totally unavoidable way the slider bar tag param works. 04.03.45 # <[Saint]> and hacks to make it look like it works like it should. 04.03.59 # ? 04.04.09 # <[Saint]> ...possible hacks/workarounds/bike-shedding. 04.04.46 # <[Saint]> the slider image ends up half off the bar at 0 or 100% 04.05.22 # that was always by design 04.05.32 # ...but it looks ugly 04.05.45 # <[Saint]> as the exact middle of the image is the 'marker', there doesn't seem to be any way to have it appear as though it doesn't do that. 04.05.45 # i get it from a functionality point of view 04.06.11 # <[Saint]> and, I know it is intentional. which is why I mentioned it being unavoidable. 04.07.44 # <[Saint]> amayer: how wide is the bar? would doing it with subimages really not be an option? 04.08.11 # the bar is 298px wide 04.09.04 # if i was using someone elses theme and i didnt know that it did it the subimage way it wouldnt bug me... but if i did it i would never be able to look at myself in the mirror 04.09.54 Quit Thra11_ (Ping timeout: 256 seconds) 04.10.23 # like i said i listent to alot of podcasts. if i did 10 images. then the slider would move every 6 min. 04.11.15 # for songs it would be more like 3 sec. 04.12.09 # [Saint]: i would really really really really like to avoid it. but if i have to i guess i dont have any other options 04.12.32 # i just started the theme so ill finish it and worry about this last 04.12.54 # <[Saint]> well...if you expanded it to 300px, and used 30 subimages, it'd be at a level where it would be almost impossible to discern that the slider wasn't *exactly* where it should be. 04.13.10 # <[Saint]> and it'd only vary by +/-2px or so. 04.15.01 # <[Saint]> I'm not sure anyone (possibly including yourself) would ever actually notice this when presented with a double blind test with both the single and subimage implementations. 04.16.10 # i didnt actually do that artwork. and idk if my art guy is going to like this idea 04.16.28 # if it comes to it. then i guess ill have to talk him into it 04.16.38 # <[Saint]> as I said earlier, it's really supposed to be a quick visual indicator, pixel perfect fluid movement is only really needed if gou were using it for seeking on a touch theme...and, probablg not even then because your finger would be covering any discrepency. 04.18.21 # would people be opposed to having an option that makes it display the way we are talking about? 04.18.24 # kinda like the "invert" option that doesnt take another parameter after it but name it like "pretty" or "TheWayItShouldLook" 04.18.36 Join Gallomimia [0] (~Gallo@d50-98-213-185.bchsia.telus.net) 04.20.53 # <[Saint]> the magic needed to do that would be non-rrivial, but... JdGordon is really the one to talk to here. 04.21.22 # <[Saint]> *non-trivial 04.21.26 # JdGordon: ^ 04.22.14 # [Saint]: i guess this would only be used on non-touch targets 04.22.43 # <[Saint]> basically, you want the slider image to not exceed the bounds of the bar itself. 04.22.51 # yes 04.23.03 # i couldnt have worded it better myself 04.23.57 # why are the Cowon D2 and iPod Video the same size but dont have the same number of themes on the theme site? 04.24.22 # <[Saint]> that's your job! 04.24.28 # <[Saint]> :p 04.24.50 # someone in the forums pointed out that my themes pop up there when i post them for the iPod Video 04.25.22 # <[Saint]> as they should. 04.25.54 # but they are non-touch themes 04.26.09 # Cowon D2 is touch from my understanding 04.26.13 # <[Saint]> that doesn't matter. 04.26.54 # <[Saint]> the device will automagically switch to grid mode. 04.27.26 # <[Saint]> grid mode is a 3x3 grid of touch actions. 04.28.20 # i dont really like that it does that. 04.28.43 # i would like to make my themes touch enabled but i dont have the cash to get a cowon D2 04.28.59 # <[Saint]> why would you need to? 04.29.26 # to play with the theme on a real target before i release it 04.29.39 # i always use my themes for a week before i post them 04.29.47 # kinda like quality testing 04.30.00 # <[Saint]> sim, or sdl app...that's what they're for. 04.30.30 # <[Saint]> both just take mouse input as "touch". 04.30.41 # hmm... interesting 04.30.42 # <[Saint]> no need for the physical target. 04.31.03 # next question: 04.31.05 # if you have touch enabled theme how would it act on a non-touch target 04.31.52 # <[Saint]> just as it should. 04.32.06 # <[Saint]> ie. it'll 'just work'. 04.33.10 # ill have to look into that 04.33.12 # *sees days of work ahead of him redoing old themes* 04.33.52 # <[Saint]> since a few monhs ago bars need no special handling for touch any more. 04.34.15 # <[Saint]> bars automatically define their own touch regions. 04.34.27 # * JdGordon coughs 04.34.48 # <[Saint]> ? 04.35.01 # but play, seek, random, and shuffle will 04.35.14 # <[Saint]> yes. 04.35.30 # :) 04.35.37 # <[Saint]> JdGordon: ? 04.35.38 # [Saint]: only because you didnt like it doing it automatically :) 04.36.07 # <[Saint]> JdGordon: they still do... 04.36.21 # <[Saint]> you need to pass notouch to avoid it. 04.36.58 # <[Saint]> also, it wasn't *just* me that didn't like the default ;) 04.38.43 # <[Saint]> unless you reverted it, bars magically draw their own touch regions unless specifically told not to with the notouch param. 04.39.16 # correct 04.39.29 # JdGordon: did you see the convo ^ at 21 min ago? 04.39.34 # <[Saint]> I wanted them to not, and to have to pass a 'touch' param if this was desired... but, you had your feasons. 04.39.50 # <[Saint]> *reasons 04.40.30 # amayer: no, im busy 04.40.50 # ok thats cool 04.41.39 Quit amiconn (Disconnected by services) 04.41.39 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.41.39 Quit pixelma (Disconnected by services) 04.41.40 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.41.42 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.41.42 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.41.55 # <[Saint]> amayer: the magic to do so would be kinda difficult I imagine. you'd need to cater for 0-33%, 34-66%, and 67-100% iiuc. 04.42.53 # <[Saint]> so the left/middle/right of the slider indicated the current volume. 04.43.20 # you just need to make the slider run on a different base then the actual bar 04.44.18 # <[Saint]> at 0-34%, the extreme left of the slider was the 'current position', 34-66% the middle of the slider was the current position, etc. etc. 04.44.20 # 100% for the slider = bar - slider width 04.44.21 Join TheSphinX_ [0] (~briehl@p5B32373A.dip.t-dialin.net) 04.45.07 # i dont know the code. and the theory in my head is kind fuzzy. 04.45.20 # <[Saint]> and, doing that without seeing he slider image jump visibly forwards or backwards would be an issue too. 04.45.47 # is the code broken down into those ^ percents? 04.46.24 # <[Saint]> no, but I figurednyou'd need to cater for at least those cases if you wanted it to look right. 04.46.44 Quit Rower85 (Quit: Hmmm...) 04.47.32 Quit TheSphinX^ (Ping timeout: 248 seconds) 04.47.36 # <[Saint]> thoug, a trivial 'fix' would be shrinking the usable area of the bar. 04.48.52 # <[Saint]> so that if a slider was used the usable display area of he bar shrunk by *slider_width*, but not the images. 04.49.29 # <[Saint]> hey hey...that would actually work. 04.49.33 # i think it would be something like this: 04.49.35 # slider_pos = (bar_width - slider_width) * cur_percent 04.49.52 # if you guys come up with a cleaner syntax for the bar tags we can implement it 04.50.10 # im happy to deprecate/replace the current one 04.50.26 # i should look at the code where is it in the gui folder? 04.50.34 # apps/gui/skin_engine 04.50.45 # no no... you stay on the theme site :) 04.50.47 # <[Saint]> JdGordon: if you can parse what I mean, what about my suggesgion a few mins ago, immediately above? 04.51.07 # <[Saint]> is it clear what I mean there, or do I need to explain it better? 04.51.14 # timestamp? 04.51.28 # <[Saint]> 16:47:34 04.51.50 # wow... im about to go to bed and you guys are just getting off work 04.52.05 # im not sure that would be less confusing 04.52.41 # i mean, isnt that at least as confusing as current? 04.52.42 # <[Saint]> it would look right, and behave exactly the same. 04.53.12 # [Saint]: is my psudo code the same thing you are talking about? 04.54.02 # or am i reading it wrong? 04.55.44 # <[Saint]> maybe, I'm not certain. my brain hurts. basically, this: if you have a 100px bar and a 10px slider image, the usable area of the bar starts from 0,5 and runs to 0,95, to allow for the slider. 04.56.26 # <[Saint]> this way the slider would stop at the upper/lower bounds, and you'd need no special syntax to set it up. 04.57.24 # wont that cause probalems with the background image also? 04.57.39 # ok, im mostly here.. can you summarise the issue? 04.57.55 # with pics if possible! 04.58.01 # <[Saint]> not if the bar drew its own background. 04.58.34 # <[Saint]> if it didn't, then, yes...probably. 04.58.56 # JdGordon: ill make some pics 04.59.18 # <[Saint]> amayer: can you parse what I said above? 04.59.29 # <[Saint]> I mean, are we on the same page? 05.00.40 # would it make it easier if the progressbar was something like images where you configure it, and then display it? 05.01.12 # [Saint]: i think we are 05.01.13 # and you'd configure all tags with one tag instead of 5 different tags doing the same thing 05.01.23 # <[Saint]> I don't hink so, I just need to be able to explain myself proper.y. 05.02.27 # sorry for the mess but look at the bottom progress bar 05.02.29 # http://ubuntuone.com/3FnSFJlFc4q6UApJjJ3LJ2 05.02.37 # <[Saint]> the magic to display 0-100% needs to be adjusted when a slider is present so it starts and ends at half slider width. 05.02.46 # at 0% it over hangs the gray box that is the background 05.03.11 # and at 100% it over hangs the other side 05.04.13 # [Saint]: the way we are describing it the pointer for current position wouldnt be in the middle of the slider. it would have to more from one end to the other end of the slider 05.04.34 # why dont you redraw the background so it looks correct? 05.05.14 # because then the bar doesnt line up nice 05.05.42 # how should it look? 05.05.54 # <[Saint]> JdGordon: that's actually possible, but only if you're drawing the bar in the backdrop. 05.06.08 # <[Saint]> it wouldn;t work if the bar drew its own backdrop. 05.06.52 # http://ubuntuone.com/7BpMyJAkHSKcYk302jGS1l 05.06.54 # here is 100% 05.07.09 # if you moved the grey backdrop then there would be grey on the end of the red 05.07.36 # you're ysing a bad slider image and backdrop combo 05.07.53 # the slider image needs to be designed to look correct at 0 and 100... 05.08.03 # but it cant 05.08.23 # course it can 05.08.24 # because the slider will always overhang the bar 05.08.34 # <[Saint]> It can, I just need to explain myself properly and I don't know how. 05.08.46 # <[Saint]> I'm trying to draw it in gimp now. 05.09.15 # at 0% the slider is positioned at: 05.09.17 # 0 - (slider_width/2) 05.09.19 # so in this case it is positioned at -4 05.09.46 # amayer: make your slider image taller than the bar and it wont look wierd 05.10.08 Join Sonant [0] (Ferrous@04-146.008.popsite.net) 05.10.26 # <[Saint]> it'll still look weird because it will always overhang the bar's upper/lower bounds 05.10.32 *** Saving seen data "./dancer.seen" 05.10.38 # <[Saint]> unless I manage to explain myself. 05.11.20 # what [Saint] is saying is that the slider shouldnt leave the backdrop and progress area 05.11.28 # you've never seen a stereo IRL with a slider like that that overhangs on all 4 sides? 05.12.06 # I can probably do it so the slider is bounded correctly 05.12.07 # yes 05.12.23 # is that what is wanted? 05.12.27 # *facepalm* thats what we are asking 05.13.34 # if the bar is 100 px we want the slider to stay in that 100px 05.13.47 # but the bar itself? 05.13.52 # not 100px +/- half its width 05.14.27 # that is where it could get tricky 05.14.29 # if the user has a round slider that has transparent bits the bar will show infront of it 05.16.34 # JdGordon: are you understanding what we are saying now? 05.16.36 # (not that anyone is right or wrong) 05.17.25 # the code shouldnt allow the slider outside the bars rectangle 05.17.35 # it shrinks the bar so it will fit 05.19.33 # lets say the slider is 10px 05.19.35 # right now the slider starts at -5px(relative to the bar) and ends at (bar_width - 5) which is 5px over the end of the bar 05.20.05 # the whole bars rectangle will still be what you specified 05.20.14 # <[Saint]> ok, here we go, this is what I've been trying to say: http://imgur.com/e0EYt 05.20.35 # <[Saint]> and yes, I did delight in making this look crappy. 05.21.26 # <[Saint]> so, when a slider is specified, the 0-100% range starts and ends at half slider_width. 05.21.43 # <[Saint]> this should behave the same, and look right. 05.21.52 # <[Saint]> and not need any new syntax. 05.21.52 # thats whats the code does 05.22.02 # <[Saint]> no, it's really not. 05.22.24 # JdGordon: did you see where the slider hung over the sides in my images? 05.22.42 # <[Saint]> amayer: seeing that, are we on the same page? 05.23.16 # yes 05.23.22 # <[Saint]> woo! 05.23.43 # but yours is based on the center mine is based on the left 05.24.15 # <[Saint]> unsurprisingly, I think may way is better :P 05.24.19 # <[Saint]> *my 05.24.34 # at 0% slider should be at 0px 05.24.36 # at 100% slider should be at (bar_width - slider_width) 05.25.27 Quit [7] (Disconnected by services) 05.25.32 # ok... this is what the code does... x and width both come untouched from the wps code... 05.25.33 # [Saint]: im coming from a drawing point of view 05.25.35 # i think you are coming from a song position pointer point of view 05.25.36 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.25.58 # 1) if a slider is there, width -= slider_width, x += slider_widht/2 05.26.04 # <[Saint]> amayer: I think my way caters for both. 05.26.20 # 2) if there is a backdrop, draw it but using the new width and x values 05.26.25 # is *that* the problem? 05.26.28 # part 2? 05.26.54 Quit Clear_runway (Ping timeout: 260 seconds) 05.27.06 # [Saint]: is your image what it should look like? or what it does look like? 05.27.19 # <[Saint]> what it should look/behave like. 05.27.33 # his image shows where the slider should be at 0% 05.27.36 # <[Saint]> currently, the slider overhangs the bar at 0/100& 05.27.55 # but it should actually be touching the side 05.28.15 # as opposed to current way that overhangs the side 05.29.52 # im confused... if you declrae the bar with width=100, do you want the background image to be 100px or 100-(slider/2)? 05.30.16 # bar = 100px 05.30.16 # (part one of my confusino ^ ) 05.30.18 # background = 100px 05.30.52 # slider_pos = (starts at 0px) 05.31.06 # <[Saint]> but the 0-100% should be calculated from slider_width/2 to bar_width -slider_width 05.31.17 # amayer: apps/gui/skin_engine/skin_display.c from line 204... i think this will just be easier if you modify and push a patch :) 05.32.29 # [Saint]: uh... OH... 05.32.33 # * [Saint] cries at not being able to accurately describe the desired behaviour. 05.32.45 # <[Saint]> oh, was that a "click"? 05.32.54 # ... possibly... 05.33.20 # we dont want to shrink that bar at all 05.34.25 # JdGordon: if you dont get it i will look at the code tomorrow... but its 11:33 here and i have to be at the gym in 5 hours(way to tired to look at unfamiliar code) 05.34.41 # 11:33pm 05.38.08 # JdGordon: i think if we just took out all that code(204-221) that it would acheive what we want 05.38.41 # dont quote me on that tho 05.47.29 # <[Saint]> ahhhhh, crap. can someone give the forum a nudge for me please? 05.47.31 # JdGordon: http://ubuntuone.com/1u0ckJus49XEyt0upjndZ2 05.48.00 # [Saint]: ^ 05.49.29 # <[Saint]> yes, that's the one (though, I think my picture was cooler :p) 05.49.42 # <[Saint]> straight lines...pah! 05.49.48 # [Saint]: yeah right. i got skillz 05.49.58 # mine has color 05.50.09 Quit factor (Read error: Connection reset by peer) 05.51.19 Join factor [0] (~factor@r74-195-182-80.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 05.55.35 # *wakes up in a puddle of drool* 05.55.37 # i think its time for me to go to sleep 05.55.39 # ill check back on this tomorrow 05.57.43 Part amayer 05.59.47 # <[Saint]> Hmmmm...forums are down? 05.59.59 # you broke them! 06.00.08 # <[Saint]> apparently I did... 06.01.17 # 63 guests 06.02.02 # <[Saint]> downforeveryone/isup.me report it as downed. 06.02.12 # its up, just insanely slow 06.02.14 # scorche: 06.02.30 # * scorche looks 06.03.03 # <[Saint]> Even though I didn't do anything other than post...I hope I *didn't* break it :-S 06.03.27 # well, the server/apache/mysql is certainly doing fine - i am working on another project on it right now... 06.03.36 # <[Saint]> s/post/my usual post; edit; post/ 06.03.47 # just the forums seems to be haivng issues... 06.04.29 # seems to be working fine for me now... 06.04.42 # * [Saint] checks 06.04.54 # now its better 06.04.55 # <[Saint]> Oh, there we go. Odd. 06.05.33 # * scorche shrugs 06.06.02 # [Saint]: hmm, i dont like your answer :) but i tinhk its because my explanation needs work 06.07.18 # <[Saint]> I was trying to point out that if you're going to be making files that are specific to one theme, and one theme only, that you may as well just edit the .wps directly. 06.07.38 # <[Saint]> which is exactly what this is supposed to be avoiding. 06.08.22 # <[Saint]> I wasn't saying that the user should do this...oh no. 06.16.07 # and its slow again 06.27.05 Join icarusfactor [0] (~factor@r74-195-182-80.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 06.27.47 Quit factor (Disconnected by services) 06.27.49 Nick icarusfactor is now known as factor (~factor@r74-195-182-80.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 06.34.01 Quit Sonant (Quit: This dial up is too slow to transport my blood-HHNNNG) 07.10.34 *** Saving seen data "./dancer.seen" 07.55.52 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 08.00.32 Quit nateloaf (Quit: Leaving.) 08.01.03 Quit Provel (Read error: Connection reset by peer) 08.04.46 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 08.04.48 Join derk0pf [0] (~k@p5DDC3DA8.dip.t-dialin.net) 08.15.47 # [Saint]: Some other targets LCD also do, but the Clips are different in that they have an OLED display 08.19.24 # * [Saint] isn't sure what the OLED has to do with it in particular. 08.21.01 # <[Saint]> Are they especially prone to causing interference? 08.21.04 # <[Saint]> amiconn: ^ 08.24.10 Quit kadoban (Read error: Operation timed out) 08.25.04 # An OLED display needs significant power for the display contents itself, unlike an LCD. So its inverters have to transfer much higher currents, and those currents fluctuate during internal refresh (bright vs. dark pixels) 08.25.50 # <[Saint]> I suppose the greylib trickery we do doesn't help with this? 08.25.50 # And transient currents cause interference 08.26.40 # <[Saint]> as (iiuc) we're *rapidly* blinking these pixels to make the color effects (shades) that we do, correct? 08.27.10 # The greylib has nothing to do with this, because it's not active during recording. It can't, since it's plugin only 08.28.04 # <[Saint]> Oh, sorry again, something from the earlier discussion made me think that there was interference present outside of recording also. 08.28.27 # <[Saint]> (but that it was particularly notable during recording) 08.28.31 # The pixels are quickly switched *by the display*, as is the case with every passive matrix display 08.29.20 # But in LCDs, the currents are almost neglectible (well, almost - on the 1st and 2nd Gen iPods LCDs you can see that they aren't completely neglectible) 08.30.54 # The case with interference on refresh on some targets is not caused by the transient currents within the displayitself , but in the data lines moving the data 08.31.13 Join ender1 [0] (krneki@foo.eternallybored.org) 08.33.13 # * yuriks hears interference (high pitched whine) when the display is on on his Clip+, if that's under debate 08.35.32 # During playback? 08.40.41 Join Buschel [0] (~chatzilla@p5790571B.dip.t-dialin.net) 08.41.36 # the nano 2g's display also whines when switched on. rockbox lowers the supply voltage a bit, then it vanishes 08.43.15 # Is this the display itself or the backlight? 08.43.25 # <[Saint]> display 08.43.41 # <[Saint]> one possibly LCD variant is WAY worse than the others, also. 08.44.00 # <[Saint]> *possible 08.44.01 # let me check 08.44.54 # it's the display 08.44.58 # <[Saint]> the backlight definitely worsens the whining noise, but (for me at least) it can still happen when the backlight isn't enabled at all. 08.45.33 # <[Saint]> Buschel: what LCD type is that? 08.45.45 # <[Saint]> (should be present in the debug screen somewhere) 08.46.17 # <[Saint]> settings - debug - view HW info 08.47.58 # just checked -> type 1, (7) LDS176 08.48.25 # <[Saint]> Ah, yes. Believe it or not, that's a "quiet" display :) 08.48.45 # then my hearing still seems to be quite well :) 08.51.25 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 08.51.25 Quit GodEater (Changing host) 08.51.25 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 08.54.00 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.10.29 Quit bootlkjkgf (Ping timeout: 276 seconds) 09.10.37 *** Saving seen data "./dancer.seen" 09.15.54 Join stoffel [0] (~quassel@pD9E41F75.dip.t-dialin.net) 09.17.53 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 09.28.24 # [Saint]: have yoy got a wps with the broken slider bar? 09.42.37 # why do we have 25 wps' :'( 09.43.40 # <[Saint]> for some added fun, look for the number of files that have been needlessly reporduced. 09.44.25 # <[Saint]> the *exact* same files, renamed just so that they could be foo.240x320.bmp 09.44.40 # <[Saint]> instead of foo.320x480.bmp, etc. 09.44.48 # <[Saint]> and no, I don't, sorry. 09.45.18 # oh this is lovely.... seems cabbie uses %ac when there is no AA, and %al when there is :/ 09.45.35 # <[Saint]> Yep. 09.45.41 # i tihnk i need to push the alignment through the viewport then 09.45.57 # <[Saint]> ...wha? 09.46.15 # <[Saint]> Oh, right. 09.46.20 # that is something which should be up to the themer, not user 09.46.37 # if i can figure out how to cleanly do that 09.48.08 # <[Saint]> Just wait til you discover that there's several cabies that don't even use viewports, and that predate alignment tags. 09.48.49 # <[Saint]> I *really* want charcell/hwcodec to be forked, as that would mean I didn't have to clean them up... 09.49.04 # <[Saint]> I've been avaoiding it, as it is a REAL pain in the ass to do. 09.50.23 # <[Saint]> I know that seems a touchy subject...but, I'm really beyond caring. 09.50.44 # <[Saint]> they're a burden, basically. 09.53.47 # <[Saint]> I understand that wodz wouldn't mind this happening either, and I know you and kugel are both pretty supportive of it. 09.54.05 # <[Saint]> (and, that's saying something...the three of us really agree on anything! :P) 09.54.18 # <[Saint]> s/really/rarely/ 09.55.38 # hwcodec doesnt really change anything here though 09.56.19 # <[Saint]> the hwcodes cabbies are old and neglected, they can go :P 09.57.23 # if they dont *need* viewports then they can stay as is 09.58.12 # <[Saint]> that makes it a pain in the ass to do some of the things that I'd like to do. 10.05.28 Join Zagor [0] (~bjst@sestofw01.enea.se) 10.05.29 Quit Zagor (Changing host) 10.05.29 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 10.09.08 # arg, would it ever really make sense to have a few lines left aligned and some centered in the same viewport? 10.14.26 Quit Buschel (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]) 10.16.13 # <[Saint]> I've seen it done, yes. 10.16.40 # <[Saint]> Does it make sense? Debatable. Will/do people do so? Yes. 10.17.55 # * JdGordon will be stern with any users who complain about this then :p 10.18.50 # <[Saint]> they would just need to (admittedly, this would be fucking annoying) split the lines that need different alignment out. 10.21.07 Join bootlkjkgf [0] (~Prmhfhfx@87.254.67.112) 10.31.36 Join thegeek_ [0] (~thegeek@171.17.9.46.customer.cdi.no) 10.34.11 Quit thegeek (Ping timeout: 248 seconds) 10.35.38 Quit rasher (Remote host closed the connection) 10.41.18 Join rasher [0] (~rasher@rockbox/developer/rasher) 10.41.48 Join |akaWolf| [0] (~akaWolf@188.134.9.161) 10.45.53 Quit derk0pf () 10.47.08 Quit AlexP (Ping timeout: 256 seconds) 10.49.34 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.49.35 Quit pamaury (Changing host) 10.49.35 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.51.46 Join AlexP [0] (~alex@rockbox/staff/AlexP) 10.58.50 Part grawity ("Bye.") 11.01.22 # [Saint]: got it working, users can still overwrite the alignement if they want 11.01.45 # and it is set with %iu(l) (or c, r and is always with lang directoin) 11.05.30 # * pixelma wonders what [Saint]'s problem with the hwcodec cabbies is (except that they are old and use syntax of their time= 11.06.12 # well, should also be *one* wps only 11.07.02 # <[Saint]> pixelma: I don't have a problem with it, per se, just that it is difficult to re-write them and keep the original alignment. 11.07.34 # <[Saint]> it's not just a quick update of the syntax, but rather a full re-write, and I guarantee that someone will take issue if I update some cabbies and leave others. 11.07.47 # that's one wps less out of how many? 11.08.14 # <[Saint]> In truth, I thought there was more than one. Sorry. 11.08.26 # *maybe* I'd help out if I find the time, if it's only this one 11.08.48 # or other monochrome ones for that matter 11.09.15 # <[Saint]> If I need images made, you'll be the first person I poke. 11.09.26 # or greyscale. But I also haven't seen your code yet, don't know where you want to go 11.09.30 # <[Saint]> you have a gift for creating nice looking greyscale icons. 11.10.05 # <[Saint]> I'm trying not to change anything, really. I don't want the physical appearance to change at all. 11.10.24 # <[Saint]> except of course for the cases where new features are being added, but, that will come later. 11.10.39 *** Saving seen data "./dancer.seen" 11.10.56 # <[Saint]> new feature(s) == (at least) showing the volume in digits while changing volume 11.11.38 # <[Saint]> also, fwiw, there's non-hwcodec/charcell targets that I would like to see die in a fire too ;) 11.12.28 # <[Saint]> the mrobe and D2 cabbies are in pretty bad shape as well. 11.12.36 # * JdGordon finds another case in cabbie this doesnt work with 11.12.39 # understood, but how do you want the code to look like more exactly? (maybe show an example) 11.12.46 # alternating one line next track infos :/ 11.13.08 # <[Saint]> why doesn't that work? 11.13.18 # <[Saint]> also, that is dotted throughout a LOT of cabbies... 11.13.29 # [Saint]: I asked last week - which m:robe do you mean: 100 or 500? That's quite a difference... ;) 11.13.42 # [Saint]: 112x64x1.wps 11.13.58 # <[Saint]> JdGordon: there's way more than that. 11.14.03 # it does ;;;etc 11.14.14 # <[Saint]> there's a LOT of them that do this alternating one-line next track info. 11.14.34 # <[Saint]> Ohhhhh....it alternates with a progress bar? 11.14.39 # <[Saint]> hehe...that's, nice. 11.14.59 # hmm, can't remember that 11.15.41 # ah, 11.16.47 # is this a case to just ignore? 11.16.55 # <[Saint]> Hmmmm...wait, it does? 11.17.03 # <[Saint]> shit, I need a clean tree to look at. 11.17.08 # <[Saint]> mine doesn't seem to do this. 11.17.37 # I remember it using same sublines to force refresh of nextrack metadata as on hwcodec those won't be there until part of the next track is loaded 11.17.40 # %t(5)%ac%s%?Fn<%Sx(Next:) %?It<%It|%Fn>|%ac%?Sr<%pe %Sx(of) %pp|%pp %Sx(of) %pe>>%;%t(5)%ac%s%?Fn<%Sx(Next:) %?Ia<%Ia|%Fn>|%ac%?Sr<%pe %Sx(of) %pp|%pp %Sx(of) %pe>> 11.19.27 # %pp etc. is not progress but play time info 11.19.30 # <[Saint]> why. so. many. alignment. tags. 11.20.38 # one is the playtime, playlist (position) info line, the other is the (centered) next track info 11.20.57 # and before viewports 11.21.44 # <[Saint]> well...shit. I've accidentally cut that out of the version I'm working on. 11.21.46 # and as I said, same sublines twice, to force the refresh 11.22.13 # <[Saint]> that shouldn't be needed anymore since ages, iiuc. 11.22.18 # it isnt.. its %Ia and %It so i cant do what i want 11.22.48 # [Saint]: in theory maybe, not on hwcodec (yes, pitty I have to say it this time) 11.23.17 # * [Saint] sees a few places where he has fucked up royally. 11.23.19 # <[Saint]> uuuuuurgh. 11.23.31 # <[Saint]> shit shit shit. 11.23.35 # hehe 11.23.38 # and you can't see it in a sim as the sim doesn't have the playback buffer restraints and doesn't simulate it close enough 11.23.48 # * [Saint] nods 11.23.56 # "it" metadata display in the WPS 11.25.09 # <[Saint]> Ahhhh, to hell with this. 11.25.39 # * [Saint] is really bloody demotivated at this point 11.26.22 # <[Saint]> being the only person that seems to care about cabbie as a teaching tool is doing my head in. 11.26.23 # noooo! 11.27.01 # <[Saint]> I'm likely not, but, I seem to be the only one with the time (now..there's a joke and a half) or the inclination to do something about it. 11.27.26 # <[Saint]> consequently, I bite off more than I can chew, and burn myself out. 11.27.42 # small chunks! 11.27.59 # is your work available somewhere? 11.29.04 # <[Saint]> not presently, I've been trying to find the time to sort my tree out for a few days, but it looks like I'll be stashing the work I have available presently and starting clean. 11.29.28 # <[Saint]> I will certainly ping you once it is in a public repo, as I need your input for the greyscale targets. 11.29.41 # do one target at a time! 11.29.50 # <[Saint]> (and, all the other targets too...really) 11.31.09 # * [Saint] may not make it known as he should, but really values pixelma's input 11.32.03 # by the way, the way to force the refresh *should* probably not be needed, but I don't think the underlying problem has been fixed and that hack always worked 11.32.49 # <[Saint]> Yes, that's a perfect example. You know these targets and their flaws/merits more than I. I know only the recent/color targets and app targets. 11.33.19 # <[Saint]> Had you not reminded me of this refresh issue, I would have considered it a legacy or oversight (I actually did) and cut it out. 11.34.29 # I'd much prefer if that hack wasn't needed anymore 11.34.52 # unfortunately I lack the skills to fix it 11.34.58 # <[Saint]> I'll be re-doing the bulk of this stuff tomorrow afternoon/evening, and (as JdGordon and many others don't really want me to shit out a review with 25 cabbie wps/sbs/fms all at once) doing it one at a time. 11.35.22 # <[Saint]> You'll be on my list of people to request reviews from, if that is ok with you? 11.35.47 # <[Saint]> (don't see why not, but it pays to ask...I'm not sure if you have time, etc.) 11.36.37 # yes, that's ok. And if it helps to relax the atmosphere about the hwcodec one... :) 11.38.02 # don't have much time myself though and quite a few other things on my plate too (even the "hobby project" plate) 11.39.20 # <[Saint]> here's my rough plan of action: 1 - update syntax, comment code, unify code; 2 - strip icon/bar backdrops from the main backdrop and "viewportify" individual theme elements for the eventuality that they may one day be able to be aligned automagically; 3 - introduce an anti-aliased font for all that can display it and stop this silliness with building the fonts on-demand 11.39.37 # <[Saint]> 3 is a possibly contentious issue. 11.41.04 # <[Saint]> Having all cabbies use GNU Unifont is something that I feel pretty strongly about. 11.41.30 Quit stoffel (Ping timeout: 246 seconds) 11.41.35 # <[Saint]> Is it an ugly font? Hell yes. Does it "just work" with all the langs we support? Yes. 11.44.22 # <[Saint]> pixelma: here's an example of what I want them to look like: http://pastebin.com/zNwTTQ4Z 11.44.29 # <[Saint]> re: code 11.44.55 # <[Saint]> (I still havent changed the identifiers to alphabetize them, but...meh) 11.46.32 # <[Saint]> I also want to change all the volume images with bars where possible/appropriate 12.04.06 # [Saint]: thanks, I'll have a look later 12.05.35 # how does the volume bar deal with positive gain values, does it need another bar or so? 12.07.28 Join Topy [0] (Topy44@f048106025.adsl.alicedsl.de) 12.09.08 # <[Saint]> pixelma: it...well, it doesn't. 12.09.35 # <[Saint]> which is why it needs to be combined with showing the volume in dB when changing volume. 12.10.17 Quit bluebrother (Disconnected by services) 12.10.20 # <[Saint]> volume bars just scale from min_volume to max_volume, where max_volume == "maximum possible" and not 0dB 12.10.22 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 12.11.09 # <[Saint]> I _could_ do two volume bars, and swap them out conditionally. 12.11.34 Quit T44 (Ping timeout: 256 seconds) 12.11.53 # <[Saint]> One for min_volume to 0dB, and the other for 0dB+ 12.12.56 # <[Saint]> ...that seems kinda ugly, but, afaik it is the only solution to be able to show a visual indication that the volume has exceeded 0dB with the bar 12.13.16 Quit fs-bluebot (Ping timeout: 252 seconds) 12.13.51 # <[Saint]> (something along the lines of what the volume indicator does now, making it red for values that will almost certainly clip {0dB+}) 12.14.37 Join fs-bluebot [0] (~fs-bluebo@g226071247.adsl.alicedsl.de) 12.24.03 Join derk0pf [0] (~k@vpn501.hotsplots.net) 12.28.05 Quit Syconaut (Ping timeout: 276 seconds) 12.29.47 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 12.42.36 Quit derk0pf () 12.46.53 Join derk0pf [0] (~k@vpn501.hotsplots.net) 12.54.20 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 13.10.41 *** Saving seen data "./dancer.seen" 13.23.22 Join Syconaut [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 13.46.42 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 13.51.40 Quit derk0pf () 14.00.53 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 14.01.42 # I have almost working gif plugin for imageviewer based on giflib :-) There is some glitch and some features of gif are not supported yet though 14.04.49 # hmm, the glitch is caused by compiler optimization apparently as with -O0 images are decoded correctly :/ 14.06.41 # yeah, -Os breaks the decoder 14.11.44 Join RAThomas [0] (~chatzilla@r74-195-239-222.stl1cmta01.stwrok.ok.dh.suddenlink.net) 14.13.05 Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) 14.13.44 # wodz: which target ? 14.14.35 # sim 14.15.37 # pamaury: glancing at your nwz tools - is sony so stupid to allow key download off device? 14.16.05 # yeah :) but you need to disassemble the code on the device to find out so it's fair enough in a way ^^ 14.16.06 # pamaury: btw EmmaMobile1 gonna be new beast :-) 14.17.04 # I had to dump the emmc on the PCB to figure that out, it was exactly easy but I'm glad I did. However it has no recovery feature so I still don't know how I will do the port yet 14.18.48 # pamaury: If underlaying OS is capable RaaA will be 10000 times faster 14.19.00 # it's linux 14.19.13 # I mean with properly written drivers 14.19.14 # so yeah, I'm thinking about it 14.19.32 # I can't tell for this ^^ 14.20.03 # the question is if they have proper alsa driver, freq scaling and so on 14.20.17 # Don't they provide sources? 14.20.40 # there is the code for linux but some drivers are proprietary 14.20.48 # lovely 14.21.51 # I am not quite sure what to do with animated gifs. They don't quite fit imageviewer architecture 14.22.39 # all the important stuff is in linux however. The proprietary stuff is about crypto, keys, mtp/msc, radio, cpufreq, and some of them which I don't understand 14.23.12 # and some of the ioctl are available in the linux headers and the drivers still have some symbols so the situation is not that bad 14.23.24 # however the usb driver is crap 14.24.20 # I'm unsure about the graphic driver 14.24.27 # probably linux fb 14.27.00 # how does RaaA work w.r.t to the c library and the kernel ? you need the headers and the library ? 14.27.38 Join stoffel [0] (~quassel@pD9E41F75.dip.t-dialin.net) 14.27.40 # yes, R0 toolchain do that for you 14.28.30 # is the toolchain specific to this particular setup or can it work for any linux ? 14.29.26 # you build static exec AFAIK so it should be universal 14.32.52 # I really thinking about RaaA, because the whole booting procedure is complicated and error prone and terribly difficult to fix if you get it wrong 14.34.24 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.38.32 Join laen [0] (~laen@cust.17.21.adsl.cistron.nl) 14.45.24 Quit Mir (Remote host closed the connection) 14.46.36 Join LinusN [0] (~linus@giant.haxx.se) 14.56.25 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.08.36 Join derk0pf [0] (~k@p5DDC358D.dip.t-dialin.net) 15.10.43 *** Saving seen data "./dancer.seen" 15.16.31 Quit nateloaf (Quit: Leaving.) 15.20.02 # Hey all, i was just wondering (because all i have is rather old data).. is the difference in audio between a non-Rockboxed and Rockboxed Clip+ still this big w/ the latest Rockbox firmware, or have there been SQ improvements? 15.20.08 # Talking about: http://rmaa.elektrokrishna.com/Temp/Clip%2B%20Rockbox%20HQ%20Patch%2065%20Ohm%20incl%200x1B.htm 15.32.55 Quit brkfstsqd___ (Ping timeout: 245 seconds) 15.32.55 Quit brkfstsqd__ (Ping timeout: 245 seconds) 15.37.07 Quit kadoban (Ping timeout: 248 seconds) 15.50.15 # scorche: ping 16.12.11 # amayer: pong for 5-ish minutes before i head to work... 16.13.16 # i was just wonering if you got a chance to pull the updates to the server yet 16.14.09 # send me an email and i will try to tonight 16.14.23 # scorche: sounds good 16.19.24 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 16.36.52 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 16.39.13 Quit Topy (Read error: Connection reset by peer) 16.41.13 Quit wodz (Quit: Leaving) 16.45.35 Quit stoffel (Read error: Operation timed out) 16.53.11 Quit Topy44 (Read error: Connection reset by peer) 16.53.11 Join T44 [0] (~Topy44@f048106025.adsl.alicedsl.de) 16.58.16 Quit T44 (Read error: Connection reset by peer) 16.58.20 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 16.59.00 Quit Zagor (Quit: Clint excited) 17.10.44 *** Saving seen data "./dancer.seen" 17.11.24 Join Thra11 [0] (~thrall@15.154.125.91.dyn.plus.net) 17.12.08 Quit factor (Ping timeout: 276 seconds) 17.20.10 Quit Topy44 (Ping timeout: 244 seconds) 17.21.39 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 17.24.00 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 17.24.00 Quit Topy44 (Read error: Connection reset by peer) 17.24.13 Join factor [0] (~factor@r74-195-185-66.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 17.45.33 Quit derk0pf () 17.47.01 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 17.47.01 Quit n1s (Changing host) 17.47.01 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.49.06 Quit T44 (Ping timeout: 244 seconds) 17.49.27 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 17.54.08 Part amayer 17.55.54 Quit T44 (Read error: Connection reset by peer) 17.56.14 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 17.59.32 Join saratoga [0] (123e0cfc@gateway/web/freenode/ip.18.62.12.252) 18.00.08 # laen: those plots you linked are testing which volume levels will overdrive the amp, they don't tell anything about quality 18.00.41 Quit T44 (Read error: Connection reset by peer) 18.00.58 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.02.08 Quit T44 (Read error: Connection reset by peer) 18.02.39 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.03.42 Quit T44 (Read error: Connection reset by peer) 18.04.13 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.05.52 Quit n1s (Read error: Connection timed out) 18.06.14 Join amayer [0] (~amayer@mail.weberadvertising.com) 18.06.41 Quit T44 (Read error: Connection reset by peer) 18.07.21 Join T44 [0] (~Topy44@f048106025.adsl.alicedsl.de) 18.07.22 Join derk0pf [0] (~k@p5DDC358D.dip.t-dialin.net) 18.07.48 Quit sciopat (Read error: Connection reset by peer) 18.08.00 Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) 18.11.06 Part LinusN 18.13.27 Quit T44 (Read error: Connection reset by peer) 18.14.03 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.16.54 Quit T44 (Read error: Connection reset by peer) 18.16.59 Join Topy [0] (Topy44@f048106025.adsl.alicedsl.de) 18.19.53 Quit Topy (Read error: Connection reset by peer) 18.20.55 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.22.18 Quit Topy44 (Read error: Connection reset by peer) 18.22.46 Join Strife89 [0] (~Strife89@207.144.201.128) 18.22.55 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.24.28 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.26.57 Quit T44 (Read error: Connection reset by peer) 18.26.59 Join Topy [0] (Topy44@f048106025.adsl.alicedsl.de) 18.27.51 Quit Topy44 (Ping timeout: 244 seconds) 18.29.56 Quit Topy (Read error: Connection reset by peer) 18.30.50 Quit zoktar (Ping timeout: 245 seconds) 18.30.51 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 18.32.58 Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) 18.39.33 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 18.47.50 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.06.06 Quit pamaury (Remote host closed the connection) 19.09.03 Quit Topy44 (Read error: Connection reset by peer) 19.10.45 *** Saving seen data "./dancer.seen" 19.11.38 Join n1s [0] (~n1s@rockbox/developer/n1s) 19.18.19 Quit n1s (Ping timeout: 255 seconds) 19.21.58 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 19.21.59 Quit pamaury (Changing host) 19.21.59 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 19.31.38 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 19.36.38 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 19.36.39 Quit n1s (Changing host) 19.36.39 Join n1s [0] (~n1s@rockbox/developer/n1s) 19.48.27 Quit akaWolf (Ping timeout: 244 seconds) 19.54.16 Quit n1s (Read error: Connection timed out) 19.58.25 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 20.04.37 Quit |akaWolf| (Quit: my exit) 20.04.38 Quit Topy44 (Read error: Connection reset by peer) 20.04.41 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 20.20.47 # any other tool than audacity could be useful to work on AMSv2 recording? 20.27.10 Quit T44 (Read error: Connection reset by peer) 20.27.38 Join Topy44 [0] (~Topy44@f048106025.adsl.alicedsl.de) 20.28.04 Quit melmothX (Ping timeout: 240 seconds) 20.30.08 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 20.34.25 Quit XavierGr (Ping timeout: 245 seconds) 20.51.28 Join lebellium [0] (~chatzilla@g231222178.adsl.alicedsl.de) 20.53.49 Quit Topy44 (Read error: Connection reset by peer) 20.54.32 # saratoga: the distortion and cutoff is what i'm worried about 20.55.08 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 20.57.11 # laen: thats just a test of what happens when you overdrive the amp 20.57.11 Quit Topy44 (Read error: Connection reset by peer) 20.57.23 # you get distortion because the amp is overdriven 20.57.35 Join Topy44 [0] (Topy44@f048106025.adsl.alicedsl.de) 20.57.46 # basically that test was run to figure out what the max level of the amp is (that is how many mV can it put out before it clips) 20.58.55 # saratoga: why is there a HQ version, then, i don't quite get it. 21.00.00 # figure out who did the test and ask them 21.00.42 Quit Topy44 (Read error: Connection reset by peer) 21.00.43 Join T44 [0] (Topy44@f048106025.adsl.alicedsl.de) 21.00.49 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 21.01.38 # oh thats one of dfkt's tests, its probably just some different patches when we were writing the audio driver 21.01.55 # or fixing it rather 21.04.29 Quit melmothX (Quit: bau) 21.10.47 *** Saving seen data "./dancer.seen" 21.11.18 Quit mystica555 (Ping timeout: 246 seconds) 21.26.22 Join mirak [0] (~mirak@89-92-229-91.hfc.dyn.abo.bbox.fr) 21.28.43 Join sentriz [0] (~Senan@78.143.151.93) 21.50.02 # pamaury: raaa sounds workable. if you have any question go ahead 21.50.31 # currently I don't have, I want to have a proof of concept that the update procedure works. Then I'll have plenty I think ^^ 21.53.39 # the ypr0 tool chain is pretty ypr0 centric as far as kernel/libc _versions_ are concerned, however the upstream tar balls are used iirc 21.53.53 # +to build it 21.54.10 Quit Thra11 (Quit: kthxbai) 21.54.27 # generalizing it would be good 21.58.44 # what do you for the display/screen ? 21.58.46 # *use 22.00.39 # [Saint]: I have an Archos Ondio FM. In case you need someone to give Cabbie a try on it feel free to ping me. I'm rather busy these days though. 22.00.57 # so don't expect me to be able to test it immediately :) 22.08.39 Quit sentriz (Ping timeout: 252 seconds) 22.31.33 Part laen 22.31.43 Quit T44 (Ping timeout: 244 seconds) 22.34.22 Quit Strife89 (Quit: Heading home.) 22.49.41 Quit derk0pf () 23.05.49 Quit amayer (Ping timeout: 244 seconds) 23.10.40 Quit kevku (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 23.10.48 *** Saving seen data "./dancer.seen" 23.16.49 Quit the-kyle (Ping timeout: 256 seconds) 23.17.16 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.20.12 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 23.29.52 Join brkfstsqd [0] (~quassel@ip68-224-121-213.lv.lv.cox.net) 23.38.38 Quit mirak (Remote host closed the connection) 23.50.45 Join lebellium_ [0] (~chatzilla@g231208005.adsl.alicedsl.de) 23.52.19 Quit lebellium (Ping timeout: 244 seconds) 23.52.25 Nick lebellium_ is now known as lebellium (~chatzilla@g231208005.adsl.alicedsl.de) 23.56.13 Join Thra11 [0] (~thrall@15.154.125.91.dyn.plus.net)