| 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 | fs-bluebot_ | Gerrit review #1413 at http://gerrit.rockbox.org/r/1413 : XWorld: 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:00 |
| 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 |
| 02:00:57 | __builtin | alright then, could someone merge g#1413 now? |
| 02:00:59 | fs-bluebot_ | Gerrit review #1413 at http://gerrit.rockbox.org/r/1413 : XWorld: 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:00 |
| 03:25:53 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
| 03:26:36 | saratoga | [Saint]: pamaury: I added a special workaround for multi-volume targets not long before the file system rework |
| 03:27:19 | saratoga | 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 | saratoga | 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 | saratoga | https://git.rockbox.org/?p=rockbox.git;a=commit;h=b30edcd62f2e16525bc9c6fe0b52769ae30b0dc8 |
| 03:29:15 | saratoga | 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 | saratoga | 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:00 |
| 04:24:34 | Bilgus | [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 | Harbec | 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 | Harbec | 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 | Harbec | still makes sense |
| 04:45:58 | saratoga | 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 | Harbec | 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 | saratoga | with a stock hard drive? |
| 04:46:57 | [Saint] | Yes. |
| 04:47:20 | TheSeven | [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 | TheSeven | 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 | TheSeven | 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 | TheSeven | lock + plug in, leave it sitting for 10min, attempt to boot it, should work with any USB power source |
| 04:49:34 | TheSeven | 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 | TheSeven | 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:00 |
| 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:00 |
| 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 |
| 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:00 |
| 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:00 |
| 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:00 |
| 10:05:59 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:08:33 | wodz | 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 | wodz | 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 | pamaury | wodz: if my memory serves, usb on atj never worked before 0e2b4908 |
| 10:20:44 | wodz | 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 | pamaury | 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 | wodz | 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 | pamaury | 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 | pamaury | I guess more debug printing is always useful (it's always hidden behind a verbose switch) |
| 10:27:05 | wodz | 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 | wodz | 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 | pamaury | 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 | pamaury | wodz: yeah, if you want to add the require make -C all over the place just go on |
| 10:30:27 | wodz | I am trying to avoid editing makefiles as long as I can :P |
| 10:32:14 | pamaury | ok I'll do it |
| 10:32:32 | pamaury | I have acquired a taste for makefile if one could say |
| 10:32:40 | pamaury | I guess I stared too long at too many of them |
| 10:34:28 | wodz | 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 | pamaury | I guess so |
| 10:46:26 | | Quit girafe (Quit: Leaving) |
| 10:48:31 | *** | Saving seen data "./dancer.seen" |
| 10:49:43 | pamaury | wodz: try g#1415 |
| 10:49:45 | fs-bluebot | Gerrit review #1415 at http://gerrit.rockbox.org/r/1415 : hwstub/tools: always run make for the libraries by Amaury Pouly |
| 11:00 |
| 11:34:53 | | Join paulk-minnie [0] (~paulk@147.210.204.186) |
| 12:00 |
| 12:01:30 | | Quit paulk-minnie (Ping timeout: 265 seconds) |
| 12:06:24 | wodz | 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:00 |
| 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 | pamaury | [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 | pamaury | but I admit I don't quite understand this commit anyway, I have zero knowledge of playlist code |
| 13:10:32 | pamaury | 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 | pamaury | 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 | pamaury | [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 | pamaury | ok I see what you mean. But this is not a FS problem |
| 13:22:37 | pamaury | I mean the FS can only for file where you ask it to :) |
| 13:22:42 | pamaury | *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 | pamaury | 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 | pamaury | which commit? |
| 13:26:05 | pamaury | yeah the commit should have been splitted, I don't object that |
| 13:26:08 | pamaury | but it doesn |
| 13:26:14 | pamaury | '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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | Bilgus | 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 | pamaury | Bilgus: I don't know if you see pixelma suggestion |
| 13:36:59 | pamaury | she suggests (and I think she is right) that instead of masking buttons, we should be masking context actions |
| 13:38:06 | Bilgus | 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 | Bilgus | remove dups. |
| 13:38:33 | [Saint] | I generated a diff between the same iteration of $file |
| 13:38:38 | Bilgus | 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 | pamaury | 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 | Bilgus | could use a show me the key I press feature |
| 13:41:24 | pamaury | [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 | pamaury | 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 | Bilgus | in some cases yes |
| 13:42:17 | pamaury | play and skip is very useful too |
| 13:42:24 | pamaury | 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 | pamaury | Well it's still simple |
| 13:43:20 | [Saint] | ~ |
| 13:43:24 | pamaury | it's basically the same thing |
| 13:43:37 | pamaury | And anyway I expect this will only apply to the WPS |
| 13:43:42 | Bilgus | 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 | pamaury | 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 | Bilgus | ^^ |
| 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 | Bilgus | and ffs how long till record too |
| 13:45:00 | pamaury | 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 | pamaury | well no, because if you allow some keys in all screens then it gets messy |
| 13:45:32 | pamaury | for example if you don't want to enable skip/prev in fm but you want it in wps |
| 13:45:54 | pamaury | (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 | Bilgus | 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 | pamaury | 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 | Bilgus | 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 | Bilgus | 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 | pamaury | [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 | pamaury | 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 | pamaury | [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 | Bilgus | touchscreen devices with some real keys is the only place I don't agree ^Fuze+ Yes! |
| 13:53:10 | pamaury | it's complicated, unmainted, unused by the devs, has myriads of crazy options, shoul |
| 13:53:13 | wodz | 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 | pamaury | 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 | Bilgus | 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 | pamaury | 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 | pamaury | Honestly how is this complicated: |
| 13:56:14 | pamaury | WPS: volume +/-, play, prev/next |
| 13:56:14 | pamaury | FM: volume +/-, skip |
| 13:56:14 | DBUG | Enqueued KICK pamaury |
| 13:56:14 | pamaury | 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 | pamaury | yeah that's how it should be |
| 13:57:30 | wodz | pamaury: I probably miss your usecase but why do you see semi locking as desired feature? |
| 13:57:37 | pamaury | Bilgus reused the filesystem selector code, which supports subelements I think |
| 13:57:46 | Bilgus | yes |
| 13:58:00 | pamaury | 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 | wodz | pamaury: +1 |
| 13:58:40 | pamaury | which is exactly how it should work, because touchpad is VERY different from physical buttons |
| 13:58:40 | wodz | I mean lock should lock period. |
| 13:58:47 | pamaury | 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 | pamaury | [Saint]: no one forces you to enable it |
| 13:59:43 | Bilgus | ha |
| 13:59:51 | [Saint] | This is true, but every 'feature because feature' needs clear discussion. |
| 14:00 |
| 14:00:00 | pamaury | 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 | pamaury | this feature is asked very often |
| 14:00:32 | pamaury | for the fuze+ at least |
| 14:00:36 | Bilgus | I want it for backlighting |
| 14:00:47 | Bilgus | EVERYWHERE |
| 14:01:00 | Bilgus | well target wise atleast |
| 14:01:08 | wodz | pamaury: does fuze+ have hw buttons for vol+/vol- ? |
| 14:01:15 | pamaury | yes |
| 14:01:21 | Bilgus | by context makes sense there |
| 14:01:24 | pamaury | those are the only physical buttons with power |
| 14:01:42 | Bilgus | I have a fuze+ and that is its downfall |
| 14:02:06 | Bilgus | 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 | wodz | 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 | Bilgus | 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 | pamaury | 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 | pamaury | I change volume quite often, call me strange if you want |
| 14:05:34 | Bilgus | 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 | pamaury | 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 | pamaury | no |
| 14:06:50 | pamaury | 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 | Bilgus | 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 | pamaury | [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 | pamaury | this has worked oh so well so far |
| 14:10:25 | [Saint] | so - what I said about ten minutes ago then? |
| 14:10:26 | Bilgus | button remap will be the next thing and that is the real cluster |
| 14:10:41 | pamaury | 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 | Bilgus | still a no in my book that is needlessly complex to the nth |
| 14:14:01 | Bilgus | 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 | pamaury | I still believe that allowing some keys on soft-lock is a good idea. I don't believe that there exists free features |
| 15:00 |
| 15:02:21 | | Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) |
| 15:10:13 | sth | lately there's been bricked xduoo x3 |
| 15:10:28 | sth | 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 | pamaury | sth: I can't see that in the forums, was that reported elsewhere? |
| 15:12:49 | sth | headfi, xduoo x3 rockbox thread |
| 15:12:53 | sth | it's a recent thing |
| 15:13:10 | sth | 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 | pamaury | It's impossible to really brick it but it might be hard to recover |
| 15:14:31 | wodz | xduoo x3 unoficial port was RaaA, no? |
| 15:14:39 | pamaury | no it's a native port |
| 15:14:40 | sth | 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 | sth | 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 | sth | it seems no one really know what caused it |
| 15:15:58 | | Quit thrillho_ (Ping timeout: 256 seconds) |
| 15:16:10 | sth | 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 | wodz | ah, ok. So currently it has the same status as dying clips I'd say |
| 15:17:16 | sth | it sorta started here: http://www.head-fi.org/t/803844/rockbox-xduoo-x3/855#post_12977911 |
| 15:17:24 | sth | 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 | sth | 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 | wodz | 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:00 |
| 16:01:41 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 16:03:36 | Bilgus | 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 | Bilgus | 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 | pamaury | 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 | pamaury | well it's going to be tricky. [Saint] is for buttons and pixelma said she was more for actions. |
| 16:11:22 | Bilgus | 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 | Bilgus | 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 | gevaerts | [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 | gevaerts | [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 | pamaury | 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 | pamaury | yeah the plugin is a bad idea |
| 16:22:27 | pamaury | 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 | Bilgus | 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 | pamaury | 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 | Bilgus | 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 | pamaury_ | 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 | pamaury_ | 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 | pamaury_ | 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 | Bilgus | 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 | pamaury_ | 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 | pamaury_ | probably either to do with some grepping |
| 16:50:51 | pamaury_ | 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 | pamaury_ | (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 | pamaury_ | hum it doesn't quite to the job but can be modified, wait a minute |
| 16:54:16 | pamaury_ | that could save a lot of time |
| 16:56:49 | Bilgus | K that would be helpful. Lastnight i got through 5 pages of the online source searching for button_ with 50+ to go |
| 17:00 |
| 17:02:09 | Bilgus | 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 | pamaury_ | here is the script but it's tricky to run and require many toolchains: pamaury/2ff88a35c5866d2cd62e8a796f297447">https://gist.github.com/pamaury/2ff88a35c5866d2cd62e8a796f297447 and https://gist.github.com/pamaury/6334a211fe7099d22abc8420c1406d71 |
| 17:07:23 | pamaury_ | And here is the result (partial only): pamaury/385b38342a1562e854e478ba62390212">https://gist.github.com/pamaury/385b38342a1562e854e478ba62390212 |
| 17:08:00 | pamaury_ | 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 | Bilgus | 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 | saratoga | the stuff i did isn't exactly relative paths, its just handling ambiguous paths |
| 17:45:57 | saratoga | like C:\music\file.mp3 |
| 17:46:22 | saratoga | 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 | saratoga | 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 | pamaury_ | yeah, this needs to be redone, the FS rework simply removed the code |
| 17:49:58 | pamaury_ | I wasn't aware of this feature, since I don't use playlists |
| 18:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 22:04:04 | | Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) |
| 22:04:44 | Bilgus | PAmaury that is a lot of buttons nice script though |
| 22:05:08 | pamaury | yeah, that's why I suggest to focus on a few buttons |
| 22:10:17 | Bilgus | 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 | pamaury | I don't know which one is better, because spreading this info all around the place is not great |
| 22:11:56 | Bilgus | 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 | Bilgus | far fewer variables it the overall scheme of things |
| 22:14:14 | Bilgus | in* |
| 22:17:55 | Bilgus | Ill finish up the button one with what I have already |
| 22:19:09 | Bilgus | 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 | pamaury | yeah I was thinking that |
| 22:20:33 | | Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) |
| 22:20:58 | pamaury | 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 | Bilgus | using web atm |
| 22:22:14 | [Saint] | {Just [Tab] by itself should autocomplete nicks based on last-spoken-order} |
| 22:22:21 | Bilgus | 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 | gevaerts | I know both! |
| 22:24:30 | gevaerts | It's names like Siant that cause me trouble |
| 22:24:30 | [Saint] | geveeaeaaerts: Shuush, you do not! |
| 22:24:32 | Bilgus | its been twenty years since I Irc'd those scripts were always a source of entertainment |
| 22:24:48 | Bilgus | 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 | gevaerts | 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 | Bilgus | 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 | Bilgus | [Saint]: actions are going to be more useful and less code in the end |
| 22:34:19 | Bilgus | 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 | Bilgus | 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 | Bilgus | agreed |
| 22:39:29 | Bilgus | 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 | Bilgus | 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 | Bilgus | could multiply each context by 64 and make a new mask |
| 22:57:39 | | Quit Guest7162 (Ping timeout: 244 seconds) |
| 22:59:32 | pamaury | Bilgus: the mask does not need to related to actions directly |
| 22:59:54 | Bilgus | no but it does need to be related to the buttons |
| 23:00 |
| 23:00:21 | pamaury | 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 | pamaury | only a few actions are interesting anyway |
| 23:00:57 | pamaury | and they will correspond to several actions so it's just better |
| 23:02:28 | Bilgus | if you are ok with having a separate function to do that then sounds good |
| 23:03:24 | Bilgus | 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 | pamaury | 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 | Bilgus | k easier on my end more complex on the back |
| 23:05:21 | pamaury | 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 | pamaury | yeah exactly |
| 23:05:41 | pamaury | because if we want to change the implementation, this is far easier |
| 23:06:26 | Bilgus | 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) |
icon identifies that the person is a core developer (has commit access).