**** BEGIN LOGGING AT Fri Jul 29 02:59:56 2011
Jul 29 03:02:56 <DocScrutinizer> what makes you think "the interface is powered off"?
Jul 29 03:04:31 <gkwhc> DocScrutinizer wierd, it didnt show up in iwconfig a while ago..
Jul 29 03:05:27 <DocScrutinizer> and you think this is related to power?
Jul 29 03:05:51 <gkwhc> i suppose so. what else could it be related to?
Jul 29 03:06:13 <DocScrutinizer> errors while loading kenel module
Jul 29 03:06:25 <DocScrutinizer> ifup
Jul 29 03:06:45 <gkwhc> hm i didnt think of ifup
Jul 29 03:07:16 <DocScrutinizer> ifconfig -a
Jul 29 03:07:27 <gkwhc> yeah its up now
Jul 29 03:08:42 <gkwhc> DocScrutinizer: would you happen to know how to make the keyboard keys bigger?
Jul 29 03:08:59 <DocScrutinizer> nope
Jul 29 03:09:26 <DocScrutinizer> you need to compile a new gtk file for that AIUI
Jul 29 03:09:45 <gkwhc> that sounds rather complicated :/
Jul 29 03:10:01 <DocScrutinizer> seems only 7 persons on this globe are capable of doing that
Jul 29 03:10:13 <gkwhc> i wish i were on of  em :)
Jul 29 03:10:27 <gkwhc> they should at least document it!
Jul 29 03:14:11 <DocScrutinizer> somewhere in the badlands of illume/enlightenment there should be some hints
Jul 29 03:14:52 <DocScrutinizer> but I recall there once been that fullscreen transparent kbd, maybe that serves your needs better?
Jul 29 03:15:57 <gkwhc> i'd like to have bigger keys, and alphabets only unlike the terminal. i saw a link on openmoko wiki of one thats finger friendly, but that link is dead..
Jul 29 03:16:54 <DocScrutinizer> ask again here in now+6.12h
Jul 29 03:17:16 <DocScrutinizer> 6...12
Jul 29 03:17:29 <gkwhc> i presume most people here reside in europe?
Jul 29 03:17:36 <DocScrutinizer> yup
Jul 29 03:17:41 <gkwhc> cool
Jul 29 03:17:50 <wolfspraul> China
Jul 29 03:18:15 <gkwhc> nice
Jul 29 03:18:35 <gkwhc> 11 o clock in the mornin eh
Jul 29 03:18:45 <wolfspraul> yes
Jul 29 03:18:55 <wolfspraul> had my morning coffee, starting into the day now :-)
Jul 29 03:19:54 <gkwhc> zao ahn :)
Jul 29 06:00:18 <mrmoku>  moin
Jul 29 06:19:07 <JaMa> moin
Jul 29 06:26:14 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r65a8799c21fb 10/meta-zaurus/recipes-kernel/linux/ (21 files in 15 dirs): linux(-kexecboot): switch to 2.6.39.3 kernels
Jul 29 06:26:15 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * re6bef7afae99 10/meta-zaurus/recipes-bsp/kexecboot/ (4 files): kexecboot: sync with org.openembedded.dev
Jul 29 06:26:15 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r6c26d0b7c5a7 10/meta-zaurus/recipes-bsp/zaurus-utils/encdec-updater.bb: encdec-updater: bump PR after necessary edit for oe-core
Jul 29 06:26:18 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r9aaa9b0b9d7d 10/meta-zaurus/recipes-bsp/zaurus-utils/zaurus-installer.bb: zaurus-installer: adopt necessary changes for oe-core
Jul 29 06:26:19 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r2b630451fe07 10/meta-zaurus/recipes-bsp/zaurus-utils/ (nandlogical-klibc_1.0.0.bb nandlogical_1.0.0.bb): nandlogical: adopt necessary changes for oe-core
Jul 29 06:26:20 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r921c026befab 10/meta-zaurus/recipes-bsp/klibc/ (39 files in 4 dirs): klibc: import reworked 1.5.23 from org.openembedded.dev
Jul 29 06:26:20 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * rd596f80070a6 10/meta-zaurus/recipes-bsp/zaurus-utils/ (files/gnu-tar.gz zaurus-legacy-tar.bb): zaurus-legacy-tar: adopt necessary changes for oe-core
Jul 29 06:26:33 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r141a81fbd7ab 10/meta-zaurus/recipes-bsp/zaurus-utils/zaurus-updater.bb: zaurus-updater: adopt necessary changes for oe-core
Jul 29 06:26:33 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r09ec31a855fb 10/meta-zaurus/conf/machine/ (6 files in 2 dirs): zaurus: import machine configs from org.openembedded.dev
Jul 29 06:26:36 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r4db4cfc48404 10/meta-zaurus/files/ (3 files): files/device_table: sync with org.openembedded.dev
Jul 29 06:26:36 <CIA-82> SHR: 03andrea.adami 07meta-smartphone * r56e2d292a978 10/meta-zaurus/recipes-bsp/kexec-tools/ (3 files): kexec-tools: sync with org.openembedded.dev
Jul 29 16:40:12 <DocScrutinizer> mrmoku: http://comments.gmane.org/gmane.linux.alsa.devel/76703 - just for the scriptie thingie :-D (I'm not d'accord with the rationale later on why this must not be a call to an external binary)
Jul 29 16:40:56 <DocScrutinizer> anyway looks like v0.0.1 of a fsoaudiod config file
Jul 29 16:41:27 <DocScrutinizer> missing: priorities for each control
Jul 29 17:05:54 <gkwhc> hm SHR runs really slow..is it because the system is on NAND rather than on uSD?
Jul 29 17:30:36 <JaMa> mrmoku: om-gta02 can be built again in shr-core
Jul 29 17:42:57 <CIA-82> SHR: 03Martin.Jansa 07meta-smartphone * r97837da9d190 10/meta-shr/conf/distro/shr.conf: shr: prefer thumb without arm overrides (_armv4t override no longer works)
Jul 29 17:49:03 <mrmoku> DocScrutinizer: interesting... still reading
Jul 29 17:49:06 <mrmoku> JaMa|Off: great
Jul 29 18:17:18 <DocScrutinizer> mrmoku: yeah, it's actually pretty much targeting what we got by fsoaudiod. It's missing a lot of the bits we need though
Jul 29 18:17:32 <DocScrutinizer> s/got/will get/
Jul 29 18:17:33 <apt> DocScrutinizer meant: mrmoku: yeah, it's actually pretty much targeting what we will get by fsoaudiod. It's missing a lot of the bits we need though
Jul 29 18:18:11 <DocScrutinizer> basically it's really a scenario manager
Jul 29 18:23:12 <DocScrutinizer> mrmoku: the section where it's claimed ucm should figure how to best do the transitions makes me shudder. This again means hardcoded platform specific "intelligence"
Jul 29 18:24:47 <nschle85> hello, i am trying to compile "shr-core"   image but the eglibc-initial stops:  configure: error: compiler support for __thread is required
Jul 29 18:25:45 <nschle85> my question: can I expect that the image will compile or should i stop here and wait some days ... ?
Jul 29 18:35:59 <nschle85> DocScrutinizer: can you compile succesfully shr-core ?
Jul 29 18:36:35 <DocScrutinizer> never even pondered to do
Jul 29 18:36:59 <nschle85> do you work on old oe dev ?
Jul 29 18:43:25 <mrmoku> DocScrutinizer: how do we remember the volume of a alsa softdevice?
Jul 29 18:44:06 <DocScrutinizer> mrmoku: remeber where exactly?
Jul 29 18:44:14 <mrmoku> let's say on startup
Jul 29 18:44:27 <mrmoku> the first time an app uses a softdevice
Jul 29 18:48:02 <DocScrutinizer> My suggestion (first approach, still based on the idea of fsoaudiod simply running scripts with amixer cmds) been to have dedicated files for the values, like /etc/aci/volumesstore/headphone (content: "85%") and then in those amixer scripts do >> amixer sset sidetone-playback-shouldbeHeadphones $(cat /etc/aci/volumesstore/headphones)<<
Jul 29 18:49:06 <mrmoku> yeah, something like that is what I would do probably
Jul 29 18:50:55 <DocScrutinizer> you'd probably also want to write to those files whenever you tear down a path that is using this control, and preferably also provide generic functions that do both write to file and call amixer to set control, and call these functions for contrlling volume via a slider in an app, rather than directly accessing the volume control on alsalib functioncall level
Jul 29 18:52:00 <DocScrutinizer> not exactly mandatory as the file will get updated when the path gets torn down, or the device shiuts down regularly. But for consistency it would be preferrable to keep those controls and their files in sync
Jul 29 18:52:28 <DocScrutinizer> note that there can be several differently named files for the same physical control
Jul 29 18:53:12 <DocScrutinizer> e.g in GTA02 the stereo-headphones and speaker volume control in mixer is identical
Jul 29 18:53:13 <mrmoku> yup, most 'normal' softdevices will have the same path
Jul 29 18:53:29 <nschle85> mrmoku: DocScrutinizer: does shr-core: shr-lite-image currently compile for gta02 ? (armv4t)
Jul 29 18:53:59 <DocScrutinizer> but the script establishing the the path will use the right value file matching the virtual device, to set the control accordingly
Jul 29 18:54:06 <mrmoku> nschle 19:29 < JaMa> mrmoku: om-gta02 can be built again in shr-core
Jul 29 18:54:14 <mrmoku> so I would say yes
Jul 29 18:54:16 <DocScrutinizer> nschle85: I got no f* clue
Jul 29 18:54:44 <DocScrutinizer> nschle85: I haven't touched a freerunner for over a year
Jul 29 18:55:07 <DocScrutinizer> mrmoku: ok?
Jul 29 18:55:19 <mrmoku> yup
Jul 29 18:55:28 <DocScrutinizer> off for dinner then :-D
Jul 29 18:56:58 <mrmoku> have fun :)
Jul 29 18:57:38 <DocScrutinizer> ne more note: the above indicates we need a startup and a teardown section in the config, for each virtual audiodevice. teardown section mostly empty usually, just caring for writeback of control values to value file(s)
Jul 29 18:59:58 <DocScrutinizer> interesting problem: how to handle collisions just in case they may happen for volume controls? can this happen at all? If so, will both files get new values, I.E. when you change the speaker volume while speaker and headphones patch are active, will this affect the headphones value as well, as both use same phy mixer control?
Jul 29 19:00:38 <DocScrutinizer> the standard paradigm is: collision is ok when both pathes try to set a control to same value
Jul 29 19:00:55 <DocScrutinizer> not applicable for volume controls that can change interactively
Jul 29 19:02:25 <DocScrutinizer> (for the records, on collision) when two pathes collide on value for a control, the path with higher priority for this particular control wins
Jul 29 19:04:02 <DocScrutinizer> if you got no priority defined in your config for this particular control, it will inherit the priority defined for the whole path (the usual case)
Jul 29 19:04:30 <DocScrutinizer> o/
Jul 29 19:35:36 <DocScrutinizer51> mrmoku: it seems I can't refuse any longer to write a semi-decent whitepaper on ACI large picture plus some details
Jul 29 19:43:08 <mrmoku> DocScrutinizer51: probably that would help me a lot :-)
Jul 29 19:46:55 <DocScrutinizer51> iphone is schon toll: freund schreibt grad: "bitte in letzter SMS vierzehnmal gegen biertrinken ersetzen"
Jul 29 19:47:23 <DocScrutinizer51> s/gegen/durch/
Jul 29 19:47:23 <apt> DocScrutinizer51 meant: iphone is schon toll: freund schreibt grad: "bitte in letzter SMS vierzehnmal durch biertrinken ersetzen"
Jul 29 19:47:57 <GNUtoo|laptop> iphone's baseband is never off
Jul 29 19:48:50 <GNUtoo|laptop> ( Lopi who works on the iphone3g SHR support told me that)
Jul 29 19:54:12 <gkwhc> is SHR slow on NAND because the filesystem is compressed??
Jul 29 20:58:31 <GNUtoo|laptop> mrmoku, are the use case sufficents?
Jul 29 20:58:35 <GNUtoo|laptop> *sufficent
Jul 29 20:58:44 <GNUtoo|laptop> for alsa routing
Jul 29 20:58:56 <GNUtoo|laptop> do we miss some devices?
Jul 29 20:59:51 <Artox> Hi
Jul 29 21:00:07 <Artox> I was wondering if someone here has experience with building shr for a netbook
Jul 29 21:00:14 <Artox> or any x86 cpu
Jul 29 21:00:49 <Artox> I tried it and ran into problems concerning yasm not beeing found by other packages
Jul 29 21:07:08 <GNUtoo|laptop> Artox, I built angstrom for eee701
Jul 29 21:08:08 <Artox> ok
Jul 29 21:08:23 <Artox> I just thought I should do some research why liubav and ffmpeg wont find yasm
Jul 29 21:09:03 <Artox> actually it should be inside tmp/sysroots/i686-oe-linux
Jul 29 21:09:04 <Artox> right?
Jul 29 21:09:34 <Artox> will openembedded automatically install all packages that it builds there?
Jul 29 21:10:21 <GNUtoo|laptop> yes
Jul 29 21:10:28 <Artox> mhm
Jul 29 21:10:29 <GNUtoo|laptop> no
Jul 29 21:10:34 <Artox> ah
Jul 29 21:10:37 <Artox> I couldnt find it there
Jul 29 21:10:48 <GNUtoo|laptop> what are you looking for exactly
Jul 29 21:10:54 <Artox> anything
Jul 29 21:10:56 <Artox> a yasm executable
Jul 29 21:10:57 <GNUtoo|laptop> sysroot is the lib and headers
Jul 29 21:11:00 <Artox> but the bin folder is empty
Jul 29 21:11:03 <Artox> a header file
Jul 29 21:11:05 <GNUtoo|laptop> work is for the workdir
Jul 29 21:11:40 <GNUtoo|laptop> basically it works that way
Jul 29 21:11:47 <GNUtoo|laptop> bitbake mplayer for instance
Jul 29 21:11:52 <GNUtoo|laptop> it will extract it in workdir
Jul 29 21:11:55 <GNUtoo|laptop> build in workdir
Jul 29 21:12:02 <GNUtoo|laptop> and during the install part
Jul 29 21:12:11 <Artox> I checked the configure arguments for ffmpeg
Jul 29 21:12:14 <GNUtoo|laptop> it will copy the headers and lib to the staging
Jul 29 21:12:16 <Artox> and they contain --sysroot=/OE/shr-unstable-netbook/tmp/sysroots/i686-oe-linux
Jul 29 21:12:20 <GNUtoo|laptop> so s/no/yes/
Jul 29 21:12:24 <GNUtoo|laptop> sorry I read to fast
Jul 29 21:12:40 <GNUtoo|laptop> yes
Jul 29 21:12:40 <Artox> so
Jul 29 21:12:54 <Artox> where should yasm be so ffmpeg configure script can find it
Jul 29 21:12:56 <GNUtoo|laptop> that's done automatically oe_runconf
Jul 29 21:13:37 <GNUtoo|laptop> you use debian or something like that
Jul 29 21:13:44 <GNUtoo|laptop> it's like if the target -dev packages
Jul 29 21:13:47 <GNUtoo|laptop> +the libs
Jul 29 21:13:53 <GNUtoo|laptop> were in a separate filesystem 
Jul 29 21:14:00 <GNUtoo|laptop> which is here:
Jul 29 21:14:07 <GNUtoo|laptop> tmp/sysroots/i686-oe-linux
Jul 29 21:14:15 <Artox> makes sense
Jul 29 21:14:38 <Artox> I might have just spotted the problem
Jul 29 21:14:51 <Artox> the ffmpeg configure scrip tries to run the yasm binary
Jul 29 21:14:53 <GNUtoo|laptop> ok
Jul 29 21:15:01 <Artox> I saw that in config.log
Jul 29 21:15:12 <Artox> but that binary is not in tmp/sysroots/i686-oe-linux
Jul 29 21:15:27 <Artox> obviously not when only dev packages go there
Jul 29 21:15:30 <GNUtoo|laptop> ah ok
Jul 29 21:15:31 <GNUtoo|laptop> that's normal
Jul 29 21:15:45 <Artox> so ffmpeg fails to find yasm
Jul 29 21:15:51 <Artox> and wont configure
Jul 29 21:16:24 <GNUtoo|laptop> think of sysroots/i686-oe-linux like arm-oe-linux
Jul 29 21:16:24 <GNUtoo|laptop> so if that's like arm-oe-linux you need to have the compiler somewhere else
Jul 29 21:16:29 <GNUtoo|laptop> that's x86-64_something
Jul 29 21:16:39 <GNUtoo|laptop> ir x86-32 something
Jul 29 21:16:50 <GNUtoo|laptop> I don't remember exactly
Jul 29 21:16:50 <GNUtoo|laptop> I can look if you want
Jul 29 21:17:02 <Artox> for me its x86_64-linux
Jul 29 21:17:33 <Artox> so
Jul 29 21:17:40 <Artox> tmp/sysroots/x86_64-linux/usr/bin/
Jul 29 21:17:48 <Artox> is that the place where the yasm binary should be?
Jul 29 21:21:05 <Artox> I need to have yasm-native then right?
Jul 29 21:36:33 <Artox> ah GNUtoo|laptop is back
Jul 29 21:36:40 <GNUtoo|laptop> Artox, sorry connection issues
Jul 29 21:36:45 <Artox> I see
Jul 29 21:36:46 <GNUtoo|laptop> the wifi AP is far
Jul 29 21:36:48 <Artox> have them too sometimes
Jul 29 21:36:52 <GNUtoo|laptop> and I've a VPN on top
Jul 29 21:36:56 <GNUtoo|laptop> ssh vpn
Jul 29 21:37:01 <Artox> [23:16] <GNUtoo|laptop> I can look if you want
Jul 29 21:37:03 <Artox> [23:16] <Artox> for me its x86_64-linux
Jul 29 21:37:04 <Artox> [23:17] <Artox> so
Jul 29 21:37:06 <Artox> [23:17] <Artox> tmp/sysroots/x86_64-linux/usr/bin/
Jul 29 21:37:07 <Artox> [23:17] <Artox> is that the place where the yasm binary should be?
Jul 29 21:37:09 <Artox> [23:20] <Artox> I need to have yasm-native then right?
Jul 29 21:37:19 <GNUtoo|laptop> yes
Jul 29 21:37:27 <GNUtoo|laptop> yasm-native should be staged the          Retry  long limit:7   RTS thr:off   Fragment thr:off
Jul 29 21:37:30 <GNUtoo|laptop> re
Jul 29 21:37:41 <Artox> what was that
Jul 29 21:37:50 <[Rui]> hi all
Jul 29 21:38:02 <Artox> Hello [Rui]
Jul 29 21:38:10 <GNUtoo|laptop> hi
Jul 29 21:38:12 <Artox> some people really liek to make otehrs type weird keys
Jul 29 21:40:16 <GNUtoo|laptop> oops what did I past
Jul 29 21:40:38 <GNUtoo|laptop> anywayy I wanted to tell that:
Jul 29 21:40:56 <GNUtoo|laptop> yasm-native should be staged in tmp/sysroots/x86_64-linux/usr/bin/
Jul 29 21:41:47 <Artox> yes
Jul 29 21:41:48 <Artox> it is now
Jul 29 21:41:55 <Artox> I had bb build it
Jul 29 21:41:56 <Artox> but
Jul 29 21:42:02 <Artox> shouldnt it have build it automatically?
Jul 29 21:42:26 <Artox> befre attempting ffmpeg or libav?
Jul 29 21:53:44 <Artox> and libav has built :)
Jul 29 21:53:50 <Artox> thanks GNUtoo|laptop for oyur help
Jul 29 21:54:04 <GNUtoo|laptop> Artox, it should but do that
Jul 29 21:54:11 <GNUtoo|laptop> DEPENDS += "yasm-native"
Jul 29 21:54:16 <GNUtoo|laptop> or something like that
Jul 29 21:54:22 <Artox> I had expected this
Jul 29 21:54:23 <GNUtoo|laptop> roughly add yasm-native to DEPENDS 
Jul 29 21:54:26 <GNUtoo|laptop> it's a bug
Jul 29 21:54:26 <Artox> but didnt try yet
Jul 29 21:54:29 <GNUtoo|laptop> and must be fixed
Jul 29 21:54:50 <Artox> yes
Jul 29 21:55:10 <GNUtoo|laptop> and then send a patch
Jul 29 21:55:17 <GNUtoo|laptop> to the oe ml
Jul 29 21:55:31 <Artox> ok
Jul 29 21:55:34 <Artox> also
Jul 29 21:55:38 <Artox> I had a problem with building ode
Jul 29 21:55:54 <GNUtoo|laptop> to test it clean both yasm-native and the ffmpeg
Jul 29 21:55:58 <GNUtoo|laptop> and bitbake ffmpeg
Jul 29 21:56:13 <Artox> yes
Jul 29 21:56:15 <Artox> I will 
Jul 29 21:56:20 <Artox> maybe over night
Jul 29 21:56:32 <Artox> I really hate waiting 10 minutes for it to rebuild the cache
Jul 29 21:56:34 <GNUtoo|laptop> ok
Jul 29 21:56:39 <Artox> so
Jul 29 21:56:41 <Artox> ode
Jul 29 21:56:43 <Artox> checking if double precision is requested... configure: error: in `/OE/shr-unstable-netbook/tmp/work/i686-oe-linux/ode-0.9-r1/ode-0.9':
Jul 29 21:56:44 <Artox> configure: error: cannot run test program while cross compiling
Jul 29 21:56:54 <Artox> is that known problem?
Jul 29 21:57:04 <GNUtoo|laptop> I don't know what ode is
Jul 29 21:57:05 <GNUtoo|laptop> sorry
Jul 29 21:57:09 <GNUtoo|laptop> maybe other people know
Jul 29 21:57:10 <Artox> ok :)
Jul 29 21:57:11 <Artox> well
Jul 29 21:57:14 <Artox> bb shr-image builds it
Jul 29 21:57:23 <GNUtoo|laptop> also try #oe when no one respond in #openmoko-cdevel
Jul 29 21:57:38 <Artox> ok
Jul 29 22:04:19 <CIA-82> freesmartphone.org: 03morphis 07aurora * r6cf5c644bea0 10/aurora-components/ (README THANKS): aurora-components: update documentation
Jul 29 22:04:19 <CIA-82> freesmartphone.org: 03morphis 07aurora * r98f4288d59e6 10/aurora-applications/app-phone/ (ActiveCallPage.qml InCall.qml): aurora-applications: app-phone: remove unused qml components
Jul 29 22:04:20 <CIA-82> freesmartphone.org: 03morphis 07aurora * r2f078204b3bc 10/aurora-applications/app-phone/CallPage.qml: aurora-applications: app-phone: minor bug fixes for the call page
Jul 29 22:04:21 <CIA-82> freesmartphone.org: 03morphis 07aurora * r2fc9ccd48b89 10/aurora-applications/app-phone/qmldir: aurora-applications: app-phone: remove old entries from the qmldir file
Jul 29 22:04:21 <CIA-82> freesmartphone.org: 03morphis 07aurora * rf4a7077fbfdd 10/aurora-daemon/aurora/ (aurora.in extensions/agents.py): aurora-daemon: implement a method to require and release the cpu resource
Jul 29 22:40:00 <antrik> DocScrutinizer51: why do we need per-control priorities?
Jul 29 22:42:19 <Artox> I just noticed
Jul 29 22:42:20 <Artox> http://patches.openembedded.org/patch/5067/
Jul 29 22:42:28 <Artox> a patch was already sent in for libav
Jul 29 22:42:31 <Artox> in May
Jul 29 22:48:40 <DocScrutinizer> antrik: tbh I have no decent example yet, but I'm sure we'll eventually see one
Jul 29 22:50:31 <gkwhc> hm how can i configure SHR/X to start in landscape mode?? i triedn the settings panel but it always reverts back to portrait mode upon reboot
Jul 29 22:50:34 <DocScrutinizer> actually I thought about volume controls, when e.g a signal tone shall get mixed into a normal mp3 playback. The volume control may be the same, and depending on your policy you signal tone is either leveled to the mp3 playback when signal device has lower prio on volume than mp3, or other way round
Jul 29 22:50:59 <DocScrutinizer> still no good example, but at least a real example
Jul 29 22:51:57 <DocScrutinizer> tbh it's just the way I (and probably each devel) design my apps. It's more aesthetics than always cold rationale
Jul 29 22:52:35 <DocScrutinizer> we need to do a compare on control level anyway, so why not have the option to define prio on control level, it doesn't cost us anything after all
Jul 29 22:53:06 <DocScrutinizer> s/level/granularity/g
Jul 29 22:53:08 <apt> DocScrutinizer meant: we need to do a compare on control granularity anyway, so why not have the option to define prio on control granularity, it doesn't cost us anything after all
Jul 29 22:56:59 <DocScrutinizer> <path name="stereo-hifi" prio=500> <control><name>left-mux</name> <value>50%</value> </control>  <control prio=600><name>right-mux</name> <value>50%</value> </control> </path>
Jul 29 22:58:58 <DocScrutinizer> looks simple enough to implement in code, so we want to keep the syntax to do per-control prio eventually if we need it, and maybe even implement it from very beginning
Jul 29 23:44:57 <antrik> DocScrutinizer: sounds like over-engineering TBH... such things should be considered when actually needed, not before
Jul 29 23:45:27 <DocScrutinizer> antrik: that's definitely not the way I design things
Jul 29 23:46:21 <antrik> that's the right way though :-P
Jul 29 23:46:26 <DocScrutinizer> I did once, and that's been a never ending pain to fight the shortcomings in the "organically grown" architecture of the program
Jul 29 23:46:34 <DocScrutinizer> uhuh
Jul 29 23:47:03 <DocScrutinizer> right, we see it success of this "right way" when looking at... scenarios
Jul 29 23:49:32 <antrik> nobody can forsee all possible requirements; so any attempt to cater for expected future requirements just results in bloated code, which generally turns out useless (and even a hinderance) when actual new requirements come up
Jul 29 23:49:40 <antrik> also known as the YAGNI principle
Jul 29 23:49:40 * DocScrutinizer shakes head at attributing a simple IT standard concept like inheritance/local-override of parameters "over-engineering", and same time suggesting a syntax or architecture could "grow"
Jul 29 23:50:41 <DocScrutinizer> hey, weren't you the guy that pestered me about ucm and my refusal to do it your way - just yesterday or the day before?
Jul 29 23:50:47 <DocScrutinizer> gnite pal
Jul 29 23:51:16 <antrik> err... my way?
Jul 30 00:43:20 <gkwhc> How can I change the SHR lock screen?
**** ENDING LOGGING AT Sat Jul 30 02:59:56 2011