--- Log for 07.11.116 Server: karatkievich.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 0 days ago 00.02.43 Quit cc___ (Ping timeout: 260 seconds) 00.09.14 Quit paulk-collins (Quit: Leaving) 00.35.45 # <__builtin> can someone test g#1413 on a slow target with cpu boosting available? 00.35.46 # 3Gerrit review #1413 at http://gerrit.rockbox.org/r/1413 : 3XWorld: some fixes by Franklin Wei 00.36.07 # * __builtin is trying to avoid boosting the cpu all the time to save power 00.38.30 # <[Saint]> There's a couple of targets where boosted vs. unboosted doesn't really provide a great deal of saings. 00.38.43 # <[Saint]> Classic would be a pretty decent example. 00.38.49 # <[Saint]> Perhaps the best example. 00.38.55 # <__builtin> mmh, I beg to differ 00.39.06 # <[Saint]> Well, you're free to do so. 00.39.15 # <__builtin> unboosted with smooth scaling gives absymal performance 00.39.45 # <[Saint]> trading more cpu time at a lesser clock for less cpu time at a higher clock on the classic doesn't really provide much savings at all. 00.40.07 # <__builtin> maybe 50% target frame rate, while boost gives around 200-300% target fps 00.40.51 # <__builtin> oh wait, you mean power-wise, right? 00.40.58 # <[Saint]> have you actually measured how much power you're actually saving on the classic? 00.41.01 # <[Saint]> and, yes, yes I do. 00.41.41 # <[Saint]> you did say 'to save power', should I have parsed that differently? 00.42.45 # <__builtin> sorry, I misunderstood what you said 00.42.49 # <[Saint]> N2G is another one where the benfits or caveats of scaling can be debated I believe. 00.43.15 # <[Saint]> mainly because it is difficult to get a universally stable underclock. 00.43.33 # <__builtin> so are you saying that boost doesn't drain all that more battery than no boost? 00.44.26 # <[Saint]> For some targets, yes. For others where a great deal of time has been spent on clocks/divisors/voltages, it makes a large difference. 00.46.01 Quit ender` (Quit: Two possibilities exist: Either we are alone in the Universe, or we are not. Both are equally terrifying. — Arthur C. Clarke) 00.46.24 # <__builtin> hmm, so should I try to make boosting more selective or just forgo the notion altogether and boost all the time? 00.46.50 # <[Saint]> I think in the context of this type of plugin if you need to boost to get realtime you may as well do so because the savings overall aren't going to be very significant. 00.47.06 # <[Saint]> I doubt people are really spending hours at a time on any given plugin. 00.48.19 *** Saving seen data "./dancer.seen" 00.48.35 # <[Saint]> based on frame rates alone as long as you're pushing around 30fps no one is going to actually see a difference anyway. 00.48.58 # <[Saint]> 30fps and 300fps are for all intents identical. 00.49.25 # <__builtin> actually the game was written to run at around 10-12fps anyhow 00.49.50 # <[Saint]> ah, right - one of the many games of the era that tie events to frame rate? 00.50.08 # <[Saint]> modern games still occasionally do that and it boggles my mind. 00.50.14 # <__builtin> in fact it varies throughout 00.50.23 # <[Saint]> for legacy games it is way more forgivable. 00.51.37 # * __builtin will remove the selective boost code then 00.52.11 Quit JanC (Ping timeout: 260 seconds) 00.52.32 Join JanC [0] (~janc@lugwv/member/JanC) 00.54.03 # <[Saint]> If we're talking about running the clocks boosted or unboosted full-time, then yeah - that'll definitely impact. 00.54.27 # <[Saint]> But in the context of a plugin where people aren't likely to be running it for extended periods I don't really think it matters a lot. 00.54.38 # <[Saint]> If you need to boost to get acceptable gameplay, you may as well. 00.55.11 # <__builtin> well the thing is it doesn't always have to boost for full frame rate 00.55.42 # <__builtin> the classic for example runs the game at faster than the target frame rate in some cases 00.56.09 # <__builtin> but then slower than the target rate in others (with fancy scaling turned on, for example) 00.56.27 # <[Saint]> well, neither does mpegplayer - for instance. but it does. I think this is primarily because the impact is so small, and the complexity to do otherwise is fairly large. 00.56.52 # <[Saint]> somewhat of a tradeoff, I guess. 00.56.55 # <__builtin> yeah, I guess that's right 00.59.28 # <__builtin> but it should still unboost when it comes to menus and other lightweight tasks, so I need to fix that 01.07.19 # <[Saint]> If you ask me, I think we're doing scaling wrong for the 'high power' targets. 01.07.27 # <[Saint]> But Doing It Right(TM) is a lot of work. 01.08.09 # <[Saint]> Intermediate scaling is very hard to practically impossible to implement without walking across pretty much everything. 01.09.06 # <[Saint]> I think we need at least three scaling levels and an interchangeable governor system. 01.09.45 # <[Saint]> well..."need". 01.10.39 Quit michaelni (Ping timeout: 260 seconds) 01.13.04 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.18.40 Quit michaelni (Quit: Leaving) 01.30.54 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.36.32 Quit krabador (Quit: Leaving) 01.40.59 Quit ulmutul (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) 01.45.21 Join shamus [0] (~shmaus@ip-206-192-195-210.marylandheights.ip.cablemo.net) 02.00.57 # <__builtin> alright then, could someone merge g#1413 now? 02.00.59 # 3Gerrit review #1413 at http://gerrit.rockbox.org/r/1413 : 3XWorld: some fixes by Franklin Wei 02.03.18 Quit ZincAlloy (Quit: Leaving.) 02.20.27 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 02.20.51 Join fs-bluebot [0] (~fs-bluebo@xd9bef119.dyn.telefonica.de) 02.23.07 Quit fs-bluebot_ (Ping timeout: 250 seconds) 02.23.51 Quit bluebrother^ (Ping timeout: 268 seconds) 02.24.34 Quit krnlyng (Ping timeout: 250 seconds) 02.37.29 Join krnlyng [0] (~liar@77.116.123.130.wireless.dyn.drei.com) 02.48.20 *** Saving seen data "./dancer.seen" 03.25.53 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 03.26.36 # [Saint]: pamaury: I added a special workaround for multi-volume targets not long before the file system rework 03.27.19 # it basically checked when parsing ambiguous paths to see if using the internal or external storage made more sense based on the current working directory 03.27.22 # <[Saint]> saratoga: aha - so I was right in remembering it working? 03.27.32 # i didn't notice that it was removed during the file system rework until recently 03.27.45 # <[Saint]> thank you, I thought I was going mental. 03.28.14 # https://git.rockbox.org/?p=rockbox.git;a=commit;h=b30edcd62f2e16525bc9c6fe0b52769ae30b0dc8 03.29.15 # probably not too hard to put back (its only a few lines) but I haven't had time to look at it 03.29.45 # <[Saint]> my main issue is having to familiarize myself with the fs code again. 03.30.00 # <[Saint]> it's significantly more complex now. 03.41.00 Quit shamus (Quit: chaos reigns within reflect repent and reboot order shall return) 03.46.09 # i don't have time to play with this now, but it looks pretty trivial to add back the old behavior 03.48.59 Quit [Saint] (Ping timeout: 260 seconds) 03.56.14 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 03.58.50 Join [Saint] [0] (77e01fae@rockbox/staff/saint) 03.59.20 # <__builtin> hmm, well looks like I figured out how to bypass the code wheel verification 03.59.25 # <__builtin> on all versions of the game 04.24.34 # [Saint]: I got the button selection done if you have time you minds telling me what you think? 04.30.53 Join Harbec [0] (~Harbec@dsl-159-75.b2b2c.ca) 04.32.15 # just installed rockbox on an ipod classic 6th generation, thanks to whoever did the tutorial! 04.41.35 # <[Saint]> did you use the dualboot bootloader (Yes.) or Freemyipod's emCORE (No.)? 04.43.07 # Yes. 04.44.26 # <[Saint]> Excellent. The reason I ask is that if you're on a Windows based machine you need to know that at this stage USB still isn't particularly solid and if you have problems you should force Apple Dick Mode or the original firmware for USB. 04.44.43 # <[Saint]> Argh, that was unfortunate. 04.44.44 # <[Saint]> *Disk 04.44.56 # still makes sense 04.45.58 # isn't USB stable now? i have never succeeded in crashing the same driver on AMS 04.46.13 # <[Saint]> ANd with emCORE it is quite possible to get yourself in to a situation where you need to remove the battery if it gets deep discharged. 04.46.37 # I had no bugs/unstable issues yet, I will keep you inform if I find one 04.46.38 # <[Saint]> saratoga: I'm still getting reports of people having write corruption on batch transfers under Windows. 04.46.50 # with a stock hard drive? 04.46.57 # <[Saint]> Yes. 04.47.20 # [Saint]: really? there should be a universal way of recovering from a deep discharged battery situation (100mA charge with lock switch on) 04.48.02 # also with a strong power supply it can actually boot up despite a completely flat/nonpresent battery 04.48.22 *** Saving seen data "./dancer.seen" 04.48.44 # and emcore has quite some sophisticated code to handle this situation in an end-user friendly way (but not sure if that was ever officially released) 04.48.46 # <[Saint]> TheSeven: does this assume an official power supply? perhaps that's the issue I bounced off. 04.48.48 Quit michaelni (Ping timeout: 268 seconds) 04.49.17 # lock + plug in, leave it sitting for 10min, attempt to boot it, should work with any USB power source 04.49.34 # it should stay off when plugging it in, it will charge at 100mA 04.50.21 # <[Saint]> I was trying that with my laptops and they just won't supply any power to it at all, I was watching it with an inline meter to make sure I wasn't crazy. 04.50.36 # <[Saint]> works with an apple wall wart or a 'dumb' charger though. 04.50.52 # hmm, that might be more of a laptop USB suspend thing then 04.51.09 # <[Saint]> Hmmm, possible. 04.51.59 # <[Saint]> I really need to motivate myself and acquire time and available effort to backport that deep discharge protection to the other ipods. 04.52.09 # <[Saint]> it is insanely useful. 04.53.10 Quit Harbec () 04.54.35 Part chrisb ("rcirc on GNU Emacs 25.2.50.1") 05.01.53 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 05.15.01 Join soap_ [0] (~soap@rockbox/staff/soap) 05.17.05 Quit soap (Ping timeout: 260 seconds) 05.20.00 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 05.20.49 Quit soap_ (Ping timeout: 260 seconds) 05.21.08 Join soap [0] (~soap@rockbox/staff/soap) 05.25.19 Join soap_ [0] (~soap@rockbox/staff/soap) 05.26.25 Quit soap (Ping timeout: 260 seconds) 05.30.08 Join soap [0] (~soap@rockbox/staff/soap) 05.32.12 Quit soap_ (Ping timeout: 260 seconds) 05.39.57 Quit ParkerR (Ping timeout: 260 seconds) 05.40.33 Join ParkerR [0] (~ParkerR@znc.withg.org) 05.42.35 Quit ParkerR (Changing host) 05.42.35 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 06.17.56 Quit TheSeven (Ping timeout: 260 seconds) 06.18.21 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.48.26 *** Saving seen data "./dancer.seen" 06.55.10 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 07.00.24 Quit cc___ (Ping timeout: 260 seconds) 07.21.05 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 07.23.56 Quit dfkt_ (Ping timeout: 256 seconds) 07.27.52 Quit Bilgus (Quit: Page closed) 08.03.14 Join wodz [0] (~wodz@94-75-75-29.home.aster.pl) 08.25.03 Join ender` [0] (krneki@foo.eternallybored.org) 08.30.12 Quit ruhans (Quit: Connection closed for inactivity) 08.43.10 Nick GodEater` is now known as GodEater (~whoknows@90.218.131.42) 08.43.35 Quit GodEater (Changing host) 08.43.36 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 08.48.29 *** Saving seen data "./dancer.seen" 08.50.59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.51.24 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 08.51.24 Quit pixelma (Quit: .) 08.54.02 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.54.03 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 09.08.17 Quit pamaury (Ping timeout: 252 seconds) 09.10.53 Join petur [0] (~petur@91.183.48.77) 09.10.53 Quit petur (Changing host) 09.10.53 Join petur [0] (~petur@rockbox/developer/petur) 09.54.30 Join elensil [0] (~edhelas@2001:1c02:1903:d800:1b5:ba26:8c63:1529) 10.05.59 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.08.33 # pamaury: I looked at atj hwstub. The commit 0e2b4908 switched driver from polling to irq. I swear it was tested but apparently doesn't work. 10.09.14 # pamaury: BUT with pre 0e2b4908 which enumerates correctly I still can't connect with recentish hwstub_shell 10.13.37 Join MrZeus [0] (~MrZeus@81.144.218.162) 10.18.42 # wodz: if my memory serves, usb on atj never worked before 0e2b4908 10.20.44 # pamaury: Not true. It didn't work before we realized that you have to do 4byte transfers to fifo *always* and that was included in initial commit of hwstub for atj 10.22.24 # ok maybe, but even then I doubt the usb code in the library is to blame 10.22.43 # * pamaury suggest wireshark or a usb analyzer 10.23.55 # pamaury: I definitely will try to trace it but I am rather short with time 10.24.49 Quit MrZeus (Quit: Leaving) 10.24.54 # you can always instrument the usb library code with printf to see where it fails 10.25.05 Join MrZeus [0] (~MrZeus@81.144.218.162) 10.25.15 # I guess more debug printing is always useful (it's always hidden behind a verbose switch) 10.27.05 # pamaury: First I'll try to reconstruct working setup (aka old stub + old tools). Then I can move forward to fix whats broken 10.29.16 # pamaury: BTW. Can't we recompile soc lib and hwstub lib *always* when compiling tools? Increase in compile time will be tiny compared to time spent on debugging whats not working 10.29.24 # wodz: I don't remember when of all this was modified but there was a change in the protocol some time ago. IIrc, the new one mayb use slightly more forms of transfers (like control IN with long payloads) 10.29.48 # wodz: yeah, if you want to add the require make -C all over the place just go on 10.30.27 # I am trying to avoid editing makefiles as long as I can :P 10.32.14 # ok I'll do it 10.32.32 # I have acquired a taste for makefile if one could say 10.32.40 # I guess I stared too long at too many of them 10.34.28 # pamaury: So if I revert 0e2b4908 (which touches atj usb driver only) the stub in theory should work with recent tools, right? Assuming of course that this fixes driver problem 10.34.45 # I guess so 10.46.26 Quit girafe (Quit: Leaving) 10.48.31 *** Saving seen data "./dancer.seen" 10.49.43 # wodz: try g#1415 10.49.45 # 3Gerrit review #1415 at http://gerrit.rockbox.org/r/1415 : 3hwstub/tools: always run make for the libraries by Amaury Pouly 11.34.53 Join paulk-minnie [0] (~paulk@147.210.204.186) 12.01.30 Quit paulk-minnie (Ping timeout: 265 seconds) 12.06.24 # pamaury: I'll keep it in mind to test 12.14.36 Join paulk-minnie [0] (~paulk@37.166.48.161) 12.16.48 Join robertd1 [0] (~as@201.208.225.40) 12.31.06 Quit paulk-minnie (Ping timeout: 250 seconds) 12.46.43 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e9f9:9b6e:b6c5:21f0) 12.48.35 *** Saving seen data "./dancer.seen" 13.03.03 # <[Saint]> pamaury: Oh, not sure if you saw the logs or not? 13.03.10 # <[Saint]> Turns out we were both right. 13.03.33 # <[Saint]> You had your historical hat on, and I had my fairly-recent (in the grand scheme of things) hat on. 13.04.26 # <[Saint]> walking relative paths across internal and external storage was added by saratoga shortly before JhMikeS did the filesystem rework. 13.07.41 # [Saint]: if I read the commit saratoga's mention correctly, this has (mostly) nothing to do with relative paths, it's just a problem with playlist code? 13.08.39 # but I admit I don't quite understand this commit anyway, I have zero knowledge of playlist code 13.10.32 # also this commit sees unrelated to how the FS works/is implemented, except for the volume prefix which is still the same as before I think 13.10.53 # or do I misunderstand what you mean by relative paths? 13.16.04 # <[Saint]> pretty hard to imagine that could be the case. 13.17.27 # <[Saint]> the easy way of understanding it is that if a playlist wanted /1/2/3/4.mp3 but this doesn't reside on the internal, but /2/3/4.mp3 resided on external, it could 'Just Work'.. 13.18.24 # <[Saint]> I was fairly sure it always used to work this way, but, apparently I was mistaken and it was a relatively (excuse the accidental pun) recent addition. 13.20.14 # <[Saint]> from memory it decided what path to attempt to use based on where the playlist resided on but I would need to actually look at the code for that. 13.20.55 # <[Saint]> without that behavior, you need to use absolute paths, which can be kinda cumbersome - but maybe this is subjective. 13.21.36 # [Saint]: you mean the opposite: the playlist wants /2/3/4.mp3 but the file is in /microSD/2/3/4.mp3 ? 13.22.05 # <[Saint]> ah, yes. sorry. 13.22.20 # ok I see what you mean. But this is not a FS problem 13.22.37 # I mean the FS can only for file where you ask it to :) 13.22.42 # *only look 13.22.52 # <[Saint]> Wel, it is in so far as it is a direct regression from that filesystem rework. 13.23.23 # <[Saint]> it isn't a 'filesystem problem' per se, sut it used to work, and it no longer does, and the reason why is that massive FS rework. 13.23.28 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 13.23.30 # but why was this code from playlist removed then? Since it's unrelated to the fs 13.24.03 # <[Saint]> No idea. Have you seen that commit? 13.24.24 # <[Saint]> It walks over a bunch of places that have no obvious, or a tenuous connection to the filesystem. 13.24.39 # <[Saint]> hundreds of files in thousands of places. 13.25.14 # which commit? 13.26.05 # yeah the commit should have been splitted, I don't object that 13.26.08 # but it doesn 13.26.14 # 't remove this code from playlist 13.28.09 # <[Saint]> No, it does't. It doesn't function as expected though, and I nailed that commit down as the catalyst. 13.28.37 # <[Saint]> I never meant to imply that it was deliberate. 13.30.27 # ah my mistake, the FS rework did change a lot of things in playlist.c to replace most path string code with common functions. And apparently this feature got lost. 13.31.02 # I guess it just need to be put back there 13.31.31 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 13.31.46 # I think hidding it behind multivolume is broken though, since then we also got support for things like RaaA where the very notion of root is...unclear 13.32.44 # I'll have a quick try maybe tonight or later this week, this doesn't look particularly hard 13.34.13 # <[Saint]> is very clear in RaaA. 13.34.35 # <[Saint]> Sorry. 13.34.39 # <[Saint]> / is very clear in RaaA. 13.34.57 # <[Saint]> It will always be /sdcard or any one of the backwards compatible links thereto. 13.36.14 # Pamaury: I got that commit up still some formatting changes to do and I've been going through button_target files found quite a few button_ I didn't have 13.36.24 # <[Saint]> the notion of what 'sdcard' is in Android, be it internal, or external, is ambiguous. 13.36.31 # <[Saint]> But this doesn't matter for our purposes. 13.36.39 # Bilgus: I don't know if you see pixelma suggestion 13.36.59 # she suggests (and I think she is right) that instead of masking buttons, we should be masking context actions 13.38.06 # anyway I can go through and check what has been loaded against the cat_value mask 13.38.18 # <[Saint]> Oh. Hah. I see what I did just now...well, that was stupid. 13.38.21 # remove dups. 13.38.33 # <[Saint]> I generated a diff between the same iteration of $file 13.38.38 # contex actions huh 13.38.48 # <[Saint]> yes, yes it was removed. I see that now. 13.39.00 # <[Saint]> idiot cloudy haze removed. 13.39.06 # Bilgus: the advantage of masking actions are: 1) no need to know the button (it's just the button used for the action) 2) more sematic (talks about the intended action) 13.40.01 # <[Saint]> won't that make the UI stuff a mess because users will have no idea what a button context is but know presicely what the HW key will be? 13.40.58 # <[Saint]> basically I'm saying "won't that make for a bunch of magic required to turn the contexts back in to buttons so we can show it to the user?" 13.41.04 Quit elensil (Ping timeout: 260 seconds) 13.41.19 # could use a show me the key I press feature 13.41.24 # [Saint]: no for the user it's easy, you say "in WPS, do you want to enable the following actions when soft-locked: Volume +/-, Play, ..." 13.41.40 # which internally translated to ACTION_WPS_VOLUP 13.41.58 # <[Saint]> you really think they'll want that much granularity? 13.42.08 # <[Saint]> IMO I think they'll just want VOL+ 13.42.12 # in some cases yes 13.42.17 # play and skip is very useful too 13.42.24 # I could use that 13.42.53 # <[Saint]> Hmmm, I guess. It just makes the UI from elegant to pretty damn convoluted. 13.43.04 # <[Saint]> the simple picker is now...not. 13.43.09 Join TheLemonMan [0] (~root@unaffiliated/thelemonman) 13.43.15 # Well it's still simple 13.43.20 # <[Saint]> ~ 13.43.24 # it's basically the same thing 13.43.37 # And anyway I expect this will only apply to the WPS 13.43.42 # the selection is the easy part the hard part is going to be catching the actions at the right time 13.43.55 # <[Saint]> I doubt it. 13.44.05 # yeah, I think the UI will be pretty clear, be it with keys or actions 13.44.06 # <[Saint]> It should also apply with FMS. 13.44.14 # ^^ 13.44.25 # <[Saint]> because tune/autotune would be just as useful as seek/skip, no? 13.44.46 # <[Saint]> recscreen too, arguably. 13.44.53 # and ffs how long till record too 13.45.00 # do we even have soft lock in those screens ? 13.45.00 # <[Saint]> gets messy pretty quick. 13.45.13 # <[Saint]> FMS yes, recscreen...no idea. 13.45.19 # well no, because if you allow some keys in all screens then it gets messy 13.45.32 # for example if you don't want to enable skip/prev in fm but you want it in wps 13.45.54 # (or if the skip/prev keys in wps have a completely different meaning then skip/prev) 13.46.32 # <[Saint]> If you ask me (I'm aware no one did) the idea of a partial user-defined softlock is vomit-in-mouth gross. 13.47.06 # they can go under sub menus to keep it somewhat tidy but that is a lot of screen and settings to traverse I'd be more worried about the converse where I wanted consistent action between them 13.47.12 # why? You complain the other ignore you but you ignore them when they want a useful feature 13.47.39 # <[Saint]> Once again in English? 13.48.30 # ok how about I make a context aware picker as well under a different commit and we can see which looks better 13.50.24 # the complex part again will be behind the scenes grabbing the actions for selective backlight and softlock 13.51.02 # <[Saint]> To be clear, I'm not a fan full stop, I think a softlock should lock keys, all keys, except the combination required to unlock it. 13.51.14 # <[Saint]> I think it should be entirely analogous to a HW lock. 13.51.40 # <[Saint]> But I'm *really* not a fan of making it foolishly complex and insanely granalar. 13.51.45 # [Saint]: do you have any softlock target? If you, I am really surprised you say so 13.51.54 # <[Saint]> I do. 13.52.25 # well then clearly we don't have the same use cases. For the fuze+, this would be very nice. And for other targets too 13.52.34 # <[Saint]> I always saw this happening, basically. 13.52.45 # <[Saint]> opening the floodgates for it to become foolishly complex. 13.52.53 # [Saint]: if we go in this direction, I could plain remove the database 13.53.01 Join elensil [0] (~edhelas@2001:1c02:1903:d800:1b5:ba26:8c63:1529) 13.53.09 # touchscreen devices with some real keys is the only place I don't agree ^Fuze+ Yes! 13.53.10 # it's complicated, unmainted, unused by the devs, has myriads of crazy options, shoul 13.53.13 # personally I'd expect lock to do ehm. locking. Not semi locking, custom locking or whatever. 13.53.16 # <[Saint]> IMHO, anyone who actually knows they want this to be as granular as you want it to be should be perfectly capable of making it happen on their own time. 13.53.49 # <[Saint]> I sincerely doubt Joe User really gives much of a shit to be honest. 13.54.10 # well we have different views. But just to give you an example, take the Fiio's, the OF has this setting 13.54.15 # <[Saint]> If they did I would see them wanting buttons over contexts just so they aren't constantly forgetting what is applied in what screen. 13.54.32 # yuck 13.54.42 # <[Saint]> historically what the OF does or doesn't do has had pretty much zero consequence on Rockbox. 13.54.56 # <[Saint]> We've even thrown this at users before several times in a "so what?" fashion. 13.55.00 # You are saying use Joe doesn't care, if it was the case I doubt the OF would have it 13.55.49 # <[Saint]> If you think any firmware has features because they believe the end users all deeply care about it - I've got some news for you about how the majority see Rockbox. 13.56.09 # <[Saint]> It was likely similar to this, here. Some dev wanted it and no one in QC said no. 13.56.13 # Honestly how is this complicated: 13.56.14 # WPS: volume +/-, play, prev/next 13.56.14 # FM: volume +/-, skip 13.56.14 DBUG Enqueued KICK pamaury 13.56.14 # Seems obvious to me how it works 13.56.45 # <[Saint]> if it were formatted that way, I might agree. 13.56.57 # <[Saint]> But it will need to be a single colum list with subheaders. 13.57.05 # yeah that's how it should be 13.57.30 # pamaury: I probably miss your usecase but why do you see semi locking as desired feature? 13.57.37 # Bilgus reused the filesystem selector code, which supports subelements I think 13.57.46 # yes 13.58.00 # wodz: you can soft-lock the target (lock touchpad) and still use volume +/- without unlocking 13.58.17 # <[Saint]> which is exactly how a lock should not work. 13.58.24 # <[Saint]> locks should...lock. 13.58.29 # pamaury: +1 13.58.40 # which is exactly how it should work, because touchpad is VERY different from physical buttons 13.58.40 # I mean lock should lock period. 13.58.47 # if you have it in your pocket, that's a life saver 13.59.06 # <[Saint]> unwanted button presses are a lifesaver? 13.59.08 # <[Saint]> Who knew? 13.59.16 # <[Saint]> "its a feature(TM)" 13.59.22 # [Saint]: no one forces you to enable it 13.59.43 # ha 13.59.51 # <[Saint]> This is true, but every 'feature because feature' needs clear discussion. 14.00.00 # All smartphones do that, maybe everyone has become dumb about what locking means 14.00.02 # <[Saint]> we got in this mess because of exactly this reasoning. 14.00.11 # <[Saint]> now we have a million fucking settings that no one uses. 14.00.22 # <[Saint]> except the one guy who added it. 14.00.22 # this feature is asked very often 14.00.32 # for the fuze+ at least 14.00.36 # I want it for backlighting 14.00.47 # EVERYWHERE 14.01.00 # well target wise atleast 14.01.08 # pamaury: does fuze+ have hw buttons for vol+/vol- ? 14.01.15 # yes 14.01.21 # by context makes sense there 14.01.24 # those are the only physical buttons with power 14.01.42 # I have a fuze+ and that is its downfall 14.02.06 # no clip and constantly unlock to change vol 14.02.22 # <[Saint]> how often do you need to change volume? 14.02.28 # <[Saint]> do you not use replaygain? 14.03.33 # I state once more, personally I think this is bad design (TM) to not lock *some* buttons. 14.03.53 # <[Saint]> I absoilutely agree. 14.04.02 # <[Saint]> sans spelling mistakes. 14.04.06 # I repaired my clip+ over it.. 14.04.47 # <[Saint]> serious question, if the stated case seems to be volume - how often does this actually happen? 14.05.02 # I don't understand you guys, you are basically saying that a feature like what all smartphones have and everyone uses is useless, I don't get it. 14.05.06 # <[Saint]> I pick a comfortable listening volume and this literally never changes. 14.05.19 # I change volume quite often, call me strange if you want 14.05.34 # for me probably 20-30x an 8hr day 14.05.43 # <[Saint]> a smartphone WILL NOT activate the HW volume buttons unless the screen is awake. 14.05.52 # <[Saint]> So you need to activate the lockscreen anyway. 14.05.58 # <[Saint]> may as well unlock at that point. 14.06.12 # <[Saint]> so - no. 14.06.13 # that's not true, most smartphone let you change the volume when screen is locked 14.06.14 # <[Saint]> very no. 14.06.37 # <[Saint]> Yes, but you still need to wake the screen. 14.06.42 # no 14.06.50 # that's the WHOLE point 14.06.54 # <[Saint]> I know of no phone that acts like this. 14.06.58 # <[Saint]> AOSP sure as shit doesn't. 14.07.17 # <[Saint]> note, I am saying *wake* the screen, not unlock. 14.07.44 # <[Saint]> with the screen not powered on, HM bottums are all dead in every phone I own. 14.07.53 # <[Saint]> With the exception of 'long power == hard reset". 14.08.09 # <[Saint]> *HW buttons, bah - spelling. 14.08.20 # htf do you wake the screen on say the fuze+ lol auto relock would be the next 'feature' 14.08.48 # <[Saint]> therein lies the clusterfuck of why this sucks. 14.09.04 # <[Saint]> its bad idea UX turtles all the way down. 14.09.50 # [Saint]: you know what? Forget about it, we'll do it as usual: a patch on gerrit so that users "that know what they are doing" can download it and apply it 14.09.57 # this has worked oh so well so far 14.10.25 # <[Saint]> so - what I said about ten minutes ago then? 14.10.26 # button remap will be the next thing and that is the real cluster 14.10.41 # I just don't want to argue anymore 14.11.10 # <[Saint]> Bilgus: yeah - that's a messy one, before the weird touchscreen on this it was kinda a NODO. 14.11.29 # <[Saint]> But this touch panel made the concept of what was or wasn't a button kinda ambiguous. 14.11.42 # still a no in my book that is needlessly complex to the nth 14.14.01 # I'm off Ill look at this later on and see which direction to go 14.14.14 Quit Bilgus () 14.14.18 # <[Saint]> actually, I think it may have been 'demoted' by way of protracted discussion from a NODO to a DoItRight. 14.14.44 # <[Saint]> It isn't like we use the HW buttons as they're labelled 100% of the time anyway. 14.17.52 Quit thrillho_ (Ping timeout: 250 seconds) 14.24.49 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 14.35.38 Quit pamaury_ (Ping timeout: 250 seconds) 14.45.33 # <[Saint]> I want to say it, just so it is absolutely crystal clear, and it doesn't matter if anyone already knows it or if they believe it or not, but it isn't personal. 14.45.40 # <[Saint]> It's never personal. 14.46.21 # <[Saint]> I know I have a way of wording things that is like the verbal equivalent of brutalist architecture, and I work to change this where I can, but I am fallible. 14.47.39 # <[Saint]> I just think that each of us has a certain duty to protect a project that we love from what we passionately believe are for lack of a better way of putting it, bad ideas. And I realize what constitutes a bad idea is subjective. 14.48.37 *** Saving seen data "./dancer.seen" 14.48.47 # <[Saint]> If I came up with something that you thought was a truly bad or poorly thought out idea on my part, I'd expect people to challenge me on it at least as passionately. 14.50.13 # <[Saint]> I really think we need to concentrate on removing or unifying a bunch of settings. 14.51.15 # <[Saint]> To add more I think it needs to be a _reaaaally_ good idea and essentially free, or preferably at a negative binsize. 14.57.35 # I still believe that allowing some keys on soft-lock is a good idea. I don't believe that there exists free features 15.02.21 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 15.10.13 # lately there's been bricked xduoo x3 15.10.28 # apparently they all ran the unofficial port 15.10.44 # <[Saint]> I guess it is somewhat like Schroedinger's Feature. 15.11.27 # <[Saint]> A feature that exists in states of being both shit, and great, until it is observed. 15.12.30 # sth: I can't see that in the forums, was that reported elsewhere? 15.12.49 # headfi, xduoo x3 rockbox thread 15.12.53 # it's a recent thing 15.13.10 # might be a bad batch of flash chips 15.13.19 # <[Saint]> I didn't think it was really possible to brick an Xduo X*? 15.13.34 # <[Saint]> Barring actual hardware failure I mean. 15.14.13 # It's impossible to really brick it but it might be hard to recover 15.14.31 # xduoo x3 unoficial port was RaaA, no? 15.14.39 # no it's a native port 15.14.40 # it's random apparently 15.14.44 # <[Saint]> Oh. Sorry. Did you mean it just incidentally, or is the implication that it is Rb related? 15.14.46 # just happened one day 15.14.47 # <[Saint]> Native. 15.15.09 # <[Saint]> I can't seem to find it, broken google-fu. 15.15.30 # <[Saint]> is it "there's a bricked Xduo" or "Rb bricked an Xduo"? 15.15.40 # it seems no one really know what caused it 15.15.58 Quit thrillho_ (Ping timeout: 256 seconds) 15.16.10 # it's a bricked x3 that just happens to run rb, might be rb related or not 15.16.37 # <[Saint]> thank you. sorry, I made that needlessly hard. 15.16.54 # ah, ok. So currently it has the same status as dying clips I'd say 15.17.16 # it sorta started here: http://www.head-fi.org/t/803844/rockbox-xduoo-x3/855#post_12977911 15.17.24 # haven't been following it 15.17.27 # <[Saint]> yeah, sad fact of life is that nands just occasionally shit the bed. 15.17.55 # thing is with rb it doesn't even use internal storage 15.18.05 # <[Saint]> I guess it could be arguable deep down as to if there was a software cause in some unicorn-rare case though. 15.18.38 # <[Saint]> but without a bunch of hardware to brick and a repeatable method by which to brick it...well, yeah. 15.19.00 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.29.04 # the guy who reported bricked xduoo x3 reports a few pages later that after taking apart and disconnecting battery the player was back to life. 15.29.12 Quit wodz (Quit: Leaving) 15.29.12 Quit advcomp2019_ (Ping timeout: 250 seconds) 15.40.36 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 15.44.16 Join Fa1th [0] (~Fa1th@46.101.133.147) 15.45.55 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 15.58.29 Quit amayer (Remote host closed the connection) 15.59.36 Join Bilgus [0] (~Bilgus@184-227-111-194.pools.spcsdns.net) 16.01.41 Join amayer [0] (~amayer@mail.weberadvertising.com) 16.03.36 # PAmaury: the underlying code for the backlight and soft lock arent terribly huge wonder if [saint] etc. Would be ok with the button masks being added and then back to the plugin idea.. 16.05.12 # <[Saint]> plugins don't really have any business governing system settings IMO. 16.06.08 # <[Saint]> I don't believe we have any that do so. 16.06.40 # It would pull it out of the main binary though and make it pretty easy for those that don't care to get rid of it 16.07.22 # Bilgus: I suggest you keep with whatever approach you like at the moment and when you have something working, put it on gerrit. The plugin is not going to solve the problem, what [Saint] is against the concept itself 16.08.38 # <[Saint]> I have my opinions about how a softlock should act, but I want it known for the record that I was pretty cool with the idea until it got really convoluted. 16.09.44 # <[Saint]> and, shit, why does what I think even matter? heaps of things I dslike with a passion got in anyway because no one cares what any one person thinks and no should they. 16.10.46 # <[Saint]> *nor should they 16.11.10 # well it's going to be tricky. [Saint] is for buttons and pixelma said she was more for actions. 16.11.22 # Already up ill fix the dup buttons issue hopefully tonight and then work on a context version 16.13.21 # <[Saint]> this whole concept of softlock action is a really touchy subject. This is far from the first time there's been a heated discussion about dynamic or selective softlock. 16.13.35 # Trying to please everyone always gets you in trouble so whats the least disliked? 16.13.39 # <[Saint]> It just so happens to be that there are approximately equal camps on both sides. 16.14.04 # [Saint]: but is it resistively touchy or capacitively touchy? 16.14.40 # <[Saint]> gevaerts: hm? in what context sorry? 16.15.08 # <[Saint]> Ohhhhhh. 16.15.13 # <[Saint]> hardy har. 16.15.15 # [Saint]: sorry, my brain sees jokes where there may not be any :) 16.16.35 # <[Saint]> Bilgus: myself personally if i accept that it is going to happen as an immutable fact, I would prefer it to be button based and in-core. 16.17.28 # <[Saint]> button based because state dependant context is a bit much in my honest opinion and in-core because We Just Don't Do That (TM) with plugins. 16.17.38 # I guess I can settle for buttons, in the end I think it's just more complicated and more code but meh 16.18.44 # <[Saint]> plugins that modify system behavior opens somewhat of a floodgate that it seems like we've been really careful to keep closed. 16.19.35 # <[Saint]> I believe we want it to Just Work even if you happen to build without plugins, or remove them, or end up in some screwing pluginAPI mismatch. 16.19.45 # <[Saint]> *screwy 16.22.12 # yeah the plugin is a bad idea 16.22.27 # and it requires code in core anyway to filter the buttons 16.25.51 Join krabador [0] (~krabador@unaffiliated/krabador) 16.28.08 Quit Bilgus (Ping timeout: 250 seconds) 16.32.20 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 16.32.43 Join Bilgus [0] (~Bilgus@184-227-111-194.pools.spcsdns.net) 16.33.38 # PAmaury ok so buttons it is have you decided what you want to do on the button names? 16.35.26 Quit Bilgus (Remote host closed the connection) 16.35.48 Quit Rower (Ping timeout: 260 seconds) 16.39.43 Join Bilgus [0] (~Bilgus@184-227-111-194.pools.spcsdns.net) 16.41.02 Join ZincAlloy1 [0] (~Adium@2a02:8108:8b80:1700:e9f9:9b6e:b6c5:21f0) 16.41.52 Join amiconn_ [0] (~amiconn@rockbox/developer/amiconn) 16.41.52 Nick amiconn is now known as Guest87200 (~amiconn@rockbox/developer/amiconn) 16.41.52 Quit Guest87200 (Killed (adams.freenode.net (Nickname regained by services))) 16.41.52 Nick amiconn_ is now known as amiconn (~amiconn@rockbox/developer/amiconn) 16.42.28 Quit Ivoah (Ping timeout: 250 seconds) 16.42.52 Quit ZincAlloy (Ping timeout: 250 seconds) 16.43.12 Quit pixelma (Disconnected by services) 16.43.12 Join pixelma_ [0] (~pixelma@rockbox/staff/pixelma) 16.43.18 Quit Slasheri (Ping timeout: 250 seconds) 16.44.03 # Bilgus: well since we are going for buttons this is going to be tricky. Either you do it by hands for all targets, or you use a script and derive names semi-automatically 16.48.03 # I like the script idea the ifdefs are already getting unwieldly but how does that fit into compiling.. Seamlessly i hope. or do it in button_target for each 16.48.04 # and it's going to be massively tricky anyway since some button-target.h are shared between targets with some ifdef sometimes 16.48.33 # Bilgus: I guess you create a huge list in some dedicated file in the settings 16.48.39 *** Saving seen data "./dancer.seen" 16.48.49 # which is generated by a script the very first time, and then edited by hand 16.49.08 Join Ivoah [0] (uid49352@gateway/web/irccloud.com/x-akxxkumhguubunmm) 16.49.42 # Trying what i have atm on a few sims its not too bad and once i finish dup removal its just a case of defining the special names first 16.50.11 # Another option is to given up putting all keys (since most of them won't ever be used) and focus on a the few that matter 16.50.28 # probably either to do with some grepping 16.50.51 # other I can dig up a script I wrote some time ago that could tell use whic defines exist for each build (more or less) 16.51.03 # (if I can find it) 16.54.09 Join Slasheri [0] (~miipekk@xen.ihme.org) 16.54.09 Quit Slasheri (Changing host) 16.54.09 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri) 16.54.11 # hum it doesn't quite to the job but can be modified, wait a minute 16.54.16 # that could save a lot of time 16.56.49 # K that would be helpful. Lastnight i got through 5 pages of the online source searching for button_ with 50+ to go 17.02.09 # I think just default to a standard list if there isn't a special define in button_target and then we only have to define for special targets but maybe just better to define for each kinda torn on whats going to be better 17.05.17 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 17.06.19 Quit Bilgus (Ping timeout: 244 seconds) 17.06.50 Quit petur (Quit: Connection reset by beer) 17.07.23 # here is the script but it's tricky to run and require many toolchains: https://gist.github.com/pamaury/2ff88a35c5866d2cd62e8a796f297447 and https://gist.github.com/pamaury/6334a211fe7099d22abc8420c1406d71 17.07.23 # And here is the result (partial only): https://gist.github.com/pamaury/385b38342a1562e854e478ba62390212 17.08.00 # however it's probably more manageable if you focus on a few buttons 17.11.11 Join Bilgus [0] (~Bilgus@184-227-111-194.pools.spcsdns.net) 17.11.58 # Ill have to catch up in log. My lunch is over ill be back to my dev machine in 6hrs 17.14.50 Quit Bilgus (Read error: Connection reset by peer) 17.32.01 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 17.45.50 # the stuff i did isn't exactly relative paths, its just handling ambiguous paths 17.45.57 # like C:\music\file.mp3 17.46.22 # the original behavior was to always guess that C:\ was the root, but that failed if you had an SD card with the music on it 17.46.59 # so i changed it to guess that "C:\" should refer to whatever volume the playlist was on, which is right 99% of the time 17.49.38 # yeah, this needs to be redone, the FS rework simply removed the code 17.49.58 # I wasn't aware of this feature, since I don't use playlists 18.01.56 Quit elensil (Quit: Leaving.) 18.05.07 Quit pamaury (Remote host closed the connection) 18.08.11 Quit dfkt (Disconnected by services) 18.08.16 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 18.08.26 Quit dfkt_ (Remote host closed the connection) 18.08.50 Quit pamaury_ (Ping timeout: 244 seconds) 18.19.20 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 18.21.50 Quit toli (Ping timeout: 256 seconds) 18.28.14 Join toli [0] (~toli@213.49.130.147) 18.28.24 Join Senji [0] (~Senji@212-5-158-45.ip.btc-net.bg) 18.29.19 Quit rela__ (Quit: Leaving) 18.29.40 Join rela [0] (~x@pdpc/supporter/active/rela) 18.32.35 Quit Senji (Client Quit) 18.48.40 *** Saving seen data "./dancer.seen" 18.49.47 Quit Kruppt (Quit: Leaving) 18.55.59 Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) 18.57.48 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.25.33 Join Kruppt [0] (~Krupptus@74-37-207-191.dr01.aplv.mn.frontiernet.net) 19.26.04 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 19.51.09 Join SJXwcLvbMwrBRBsD [0] (~SJXwcLvbM@67-197-253-252.yk1.cm.dyn.comporium.net) 19.51.13 Quit SJXwcLvbMwrBRBsD (K-Lined) 19.59.29 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 20.16.04 Join Link8 [0] (~me@546AC6B1.cm-12-3d.dynamic.ziggo.nl) 20.18.17 Quit Link8 (Remote host closed the connection) 20.19.29 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 20.23.56 Quit thrillho_ (Ping timeout: 240 seconds) 20.26.37 Join smoke_fumus [0] (~smoke_fum@leased-line-195-222-90-170.telecom.by) 20.36.40 Quit Kruppt (Quit: Leaving) 20.48.43 *** Saving seen data "./dancer.seen" 20.51.04 Quit pamaury (Ping timeout: 244 seconds) 20.51.27 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.59.33 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 21.04.20 Quit thrillho_ (Ping timeout: 248 seconds) 21.24.58 Quit amiconn (Quit: No Ping reply in 64 seconds.) 21.25.08 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 21.38.46 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 21.43.43 Quit thrillho_ (Ping timeout: 260 seconds) 22.04.04 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 22.04.44 # PAmaury that is a lot of buttons nice script though 22.05.08 # yeah, that's why I suggest to focus on a few buttons 22.10.17 # I think I can tweak that to spit out a pre formatted list but I'm leaning towards a standard list in the file and a table in each button_target 22.11.43 # I don't know which one is better, because spreading this info all around the place is not great 22.11.56 # exactly 22.12.05 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 22.12.05 # * pamaury thinks actions would be so much simpler 22.14.04 # far fewer variables it the overall scheme of things 22.14.14 # in* 22.17.55 # Ill finish up the button one with what I have already 22.19.09 # What if we didn't present the actions as individual contexts and instead merged all the similar actions across all contexts that applied 22.20.21 # yeah I was thinking that 22.20.33 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 22.20.58 # it's probably easy, I think volume is always ACTION_WPS_VOL{UP,DOWN} and then one needs to gather PLAY and SKIP for several screens 22.21.10 # <[Saint]> Bilgus: what IRC client do you use? 22.21.45 # <[Saint]> (hint: you should be able to type the first letter of a nick, and then press [Tab] to auto-complete it) 22.22.06 # using web atm 22.22.14 # <[Saint]> {Just [Tab] by itself should autocomplete nicks based on last-spoken-order} 22.22.21 # nice. 22.22.35 # <[Saint]> The latter is hit and miss on any given client, the former should always work. 22.23.09 # <[Saint]> I just noticed that you must've typed out PAmaury by hand. 22.23.16 # <[Saint]> So I thought I'd give a heads up. 22.23.51 # <[Saint]> No one knows how to spell pamaury or gevaerts without nick completion :p 22.23.59 # I know both! 22.24.30 # It's names like Siant that cause me trouble 22.24.30 # <[Saint]> geveeaeaaerts: Shuush, you do not! 22.24.32 # its been twenty years since I Irc'd those scripts were always a source of entertainment 22.24.48 # Thanks 22.24.49 # <[Saint]> Hah, jokes on you, I highlight on siant and sanit. :p 22.25.28 Quit thrillho_ (Ping timeout: 265 seconds) 22.25.36 # * gevaerts tries stain 22.25.49 # Might be more appropriate :) 22.25.55 # <[Saint]> touche. 22.28.53 # <[Saint]> Seems like the Freenode QWebIRC client doesn't do last-spoken-order completing with [Tab] alone. 22.29.28 # <[Saint]> It is doing some crazy completion of just '/command foo' 22.32.19 # pamaury: I think the action one would only make sense with the WPS I mean why do you need any other context? 22.33.30 # [Saint]: actions are going to be more useful and less code in the end 22.34.19 # have you seen the number of variabilities across the targets? 22.34.21 # <[Saint]> behind the scenes, perhaps - I still feellike contexts shouldn't be presented to the user for selection. 22.35.30 # <[Saint]> WPS_NEXT/WPS_FF/FMS_SEEK/FMS_* and friends should all be presented under a single 'BUTTON_NEXT' option, IMO. 22.35.49 # don't present them as contexts 22.36.30 # <[Saint]> right, but do you understand what I'm hinting at? Call it 'FF', call it 'Next'...hell, call it Frank for all I care. 22.36.44 # <[Saint]> Just group them instead of having the absurdly granular options. 22.37.05 # agreed 22.39.29 # I think I'd go for the WPS name and then make it carry over to the others 22.48.44 *** Saving seen data "./dancer.seen" 22.53.40 # unfortunately all the action codes are incremented by 1 so that wipes out the mask 22.54.32 Join Guest66888 [0] (~Slayer@c-73-86-128-62.hsd1.va.comcast.net) 22.56.29 # could multiply each context by 64 and make a new mask 22.57.39 Quit Guest7162 (Ping timeout: 244 seconds) 22.59.32 # Bilgus: the mask does not need to related to actions directly 22.59.54 # no but it does need to be related to the buttons 23.00.21 # you can create your own mask: MASK_ACTION_VOL = 1, MASK_ACTION_PLAY = 2, MASK_ACTION_SKIP = 4. And then the setting is the OR of that and in the filter code you just decode the mask 23.00.26 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 23.00.32 # only a few actions are interesting anyway 23.00.57 # and they will correspond to several actions so it's just better 23.02.28 # if you are ok with having a separate function to do that then sounds good 23.03.24 # if you use the pre defined contexts it can all be done bitwise 23.03.29 Quit utrack (Ping timeout: 250 seconds) 23.04.23 # I mean that encoding of the setting should reflect what the user chooses, not how its implemented 23.04.47 Quit thrillho_ (Ping timeout: 250 seconds) 23.05.11 # k easier on my end more complex on the back 23.05.21 # so the use can choose a bitmap of "Volume +/-", "play" and "skip/prev" then the setting should be a bitmak of 3 items (like those above I listed). Then only in the implemention of the setting (in the button handling code I guess) you related those with the actual context and action 23.05.27 # yeah exactly 23.05.41 # because if we want to change the implementation, this is far easier 23.06.26 # yeah no point in choosing vol up / down 23.10.31 Join utrack [0] (~utrack@21422.s.t4vps.eu) 23.18.33 Join rela_ [0] (~x@p200300764D4F2D00BC18F7FF479CF2F7.dip0.t-ipconnect.de) 23.22.04 Quit rela (Ping timeout: 260 seconds) 23.26.49 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) 23.28.16 Join shamus [0] (~shmaus@ip-206-192-195-210.marylandheights.ip.cablemo.net) 23.35.07 Quit The_Prospector (Quit: when in doubt, kernel panic) 23.36.57 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 23.40.44 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 23.42.59 Quit paulk-collins (Quit: Leaving) 23.45.55 Quit thrillho_ (Ping timeout: 268 seconds)