Log from #neuros IRC channel

anyone familar with some of the ncooler/nano-x widget stuff? specifically if I have a "Picture"... how do I work in a mask or transparency so that the Picture does not have to be rectangular?

[02:37]

can I use .gif transparency to do it or do I need to do something else?

[06:41]

sourcerror: try making the Form that contains the Picture transparent, then all areas of the picture that are black should be transparent too. I have not tried this, though.

hi all

hi all

oh, hi

<anders_>

Hi

[10:01]

JoeBorn: just seen the email, i didn't check it until a few hours ago

[10:02]

I didn't send it with much advance notice.

[10:04]

no, it's ok, it's just i wasn't around to check it

[10:04]

hey swoag

[10:04]

<swoag>

hi, nerochiaro

[10:04]

everything ok ?

[10:05]

<swoag>

yep, always wondered, how did you make your message in different color?

[10:05]

here in IRC ?

[10:06]

<swoag>

I mean here in this channel.

[10:06]

<swoag>

ya

[10:06]

* nerochiaro like this ?

[10:06]

swoag: or like this ?

[10:06]

<swoag>

nope, did you notice "hey, swoag" is in brown color?

[10:06]

<swoag>

yes.

[10:07]

it's your client. in general when you say "name_of_person: message" then it means you're "talking" to someone in particular. so some clients make it in a different color if "name_of_person" it's your own name

[10:07]

those don't show as different colors on mine :(

[10:08]

<anders_>

Like this?

[10:08]

JoeBorn: what about this one ?

[10:08]

<swoag>

anders_: no

[10:08]

yep, that works. ok, understand now.

[10:08]

<swoag>

nerochiaro: did the color change on your screen?

[10:08]

yes. in general most clients highlight lines that contain your own name

[10:09]

but it's not mandatory or anything

[10:09]

<swoag>

but your first line, 'hey swoag' was highlighted too?

[10:09]

it has your name in it, no ?

[10:10]

<swoag>

ah, I see.

[10:10]

seems your client is more sensitive, doesn't require you to have "name:", just the name anywhere on the line

[10:10]

<swoag>

ok, so much for the IRC tutorial... :-)

[10:11]

<swoag>

I don't have much to update, most of the efforts have been poured to enhance the GUI

[10:12]

<swoag>

and fix critical codec related bugs.

[10:12]

<swoag>

We've got new release from Vendor (to fix the MP4 contructor issue), still in the middle of integrating it.

[10:14]

<swoag>

Lots of changes have been done to GUI, and we are still working to finalize the 'initial' version, which will have the basic color scheme/fonts/icons look right.

[10:15]

<swoag>

The release in mid next week will contain the first version of GUI with the new design.

[10:15]

<swoag>

Other than that,

[10:16]

<swoag>

we are still tuning the Network support code (more on the XP Samba support part).

[10:16]

hmm what did I miss?

[10:17]

<swoag>

it is reported that ever after .63, XP support becomes less stable than before, because of the new algorithm used.

[10:17]

Hostile: swoag's recap of new neuros developements

[10:17]

damn. the best part.

[10:17]

Hostile: check logs

[10:17]

nerochiaro: whats the link again

[10:18]

<swoag>

team is working to use two algorithms at the same time to fix that. First version with that code (0.79) seems working but still has severe random crash issues.

[10:19]

Hmm. You know what I noticed. before USB hard drives were unusable with the OSD, now my iPod works great as a storage device

[10:19]

<swoag>

and before Chinese NY, someone in Xiamen tried the Youtube transcoder from anders_, transcoded AVI files played fine on PC,

[10:19]

<swoag>

but vendor codec can not (can but with severe A/V sync issue).

[10:20]

<swoag>

Vendor is still working on this issue.

[10:22]

<swoag>

We've also fixed the IR learning/blaster code. (I was able to schedule record with the blaster working with my tape recorder)

[10:22]

swoag: I've used blaster too to try it, worked great.

[10:22]

swoag: i need to ask you a couple questions about that later, there might be to add a feature for certain kind of remotes

[10:23]

<swoag>

I've experimented with the nano-x WM idea, got the helloworld working (stopped right there)

[10:23]

<swoag>

that is all I have.

[10:23]

I'd be interested in talking more about that.

[10:23]

<swoag>

before questions,

[10:23]

<swoag>

I'd like to ask mine first. ;-)

[10:24]

<swoag>

has anyone used a Wireless-Bridge thing?

[10:24]

hmm nope.

[10:24]

<swoag>

I was thinking to get one to work with OSD, thus

[10:25]

<swoag>

I can get OSD to network without waiting for the USB Wifi ready, or having to pull a wire to my living room.

[10:25]

<swoag>

I've got Wireless network at home, so it seems the Wireless-bridge is the right approach.

[10:26]

I'm interested in doing this too.

[10:26]

Wireless Bridges are expensive though.

[10:26]

but it's still mostly a stop gap.

[10:26]

a lot more than a USB wireless card.

[10:26]

<swoag>

went to Bestbuy/Circuit City/Office Depot, _all_ out of stock.

[10:26]

is b fast enough for streaming video? or do we need g?

[10:26]

<swoag>

Hostile, internet says it is somewhere around $60 for the cheap one.

[10:27]

<swoag>

www.tigerdirect.com

[10:27]

I would be shocked if the openWRT doesn't do it.

[10:27]

en.wikipedia.org

[10:28]

I need to buy a new dvd player today, I'll look for one at the CompUSA, BestBuy here.

[10:28]

swoag: that buffalo looks sufficient, built in switch too.

[10:29]

<swoag>

Hostile, exactly, just wonder if anyone used it. seems to me a good bundle thing for OSD?

[10:30]

I think it's a reasonable stop gap solution, but my personal feeling is that it's not a good substitute for a USB apapter

[10:30]

<swoag>

with the USB Wifi, you lose the USB HDD support (before the HUB function is working).

[10:30]

swoag: hmm. Probably a good idea, I mean when I move my OSD around I use a USB hd, but it would be a lot easier to just hook up a wireless bridge and play it over the network

[10:30]

it requires separate power, a differnet device to configure and another big box to stick in the cabinet

[10:30]

<swoag>

even with the USB Wifi working, the performance with Wifi and Mass Storage at the same time won't be great.

[10:30]

<swoag>

in fact, will be pretty bad, I say.

[10:31]

I wouldn't use them at the same time. I mean if you need to use USB, just pull out the wifi device

[10:31]

but that's just me.

[10:32]

I'd use USB and wifi at the same time for sure, I'm looking for the OSD to to me a NAS of sorts

[10:32]

swoag: for lack of bandwidth for USB ? you surely won't read from network and write to USB at the same time at full speed, but why it should suck that much as you say ?

[10:32]

although I won't be streaming much video from other sources to the OSD, I'll be going the other way.

[10:32]

that just made me think about including that in the spec for the OSD2,

[10:33]

wireless out of the box would make it quite attractive to a growing crowd i think

[10:33]

btw, if we are putting those specs on the xiamen server (which I am plenty nervous about)

[10:33]

I agree.

[10:33]

how do we do that?

[10:33]

<swoag>

nerochiaro: you are probably right on that part.

[10:33]

What is the speed available over usb on the OSD?

[10:34]

anyway, I want to talk about wm when we have you on here in realtime, swoag

[10:35]

first, I should ask how is the release for 3/7 looking?

[10:35]

<swoag>

JoeBorn, 'putting those specs on xiamen server'? what did you mean?

[10:35]

after we talk about the wm, I want to discuss xmms2 :)

[10:35]

we talked about puttting the requirements doc into SVN remember?

[10:35]

well, we can talk about xmms2 first if you want.

[10:36]

might as well since I assume they are somehow related

[10:36]

I just want a status update really

[10:36]

<swoag>

JoeBorn, once you get the svn client running, it works like a charm.

[10:36]

JoeBorn: svn is pretty easy if you just want the basics

[10:37]

<swoag>

JoeBorn, 3/7 release will be pretty much 0.79, with the Samba crash removed and taking the new color scheme/text change John is working on over the weekend.

[10:38]

<swoag>

JoeBorn, code is planned to be frozen on 3/5 or 3/6.

[10:38]

<swoag>

JoeBorn, and we'll then push a new release based on latest vendor release by the end of the week, since 3/7 release will not

[10:39]

<swoag>

have the iPod/Quick time fix.

[10:39]

so .mp4 still broken for iPod qtime?

[10:39]

* sourcerror catches up on reading

[10:40]

<swoag>

JoeBorn, yes for 3/7 release.

[10:40]

swoag: so we are talking a 3/7 release, then what a 3/9 release?

[10:41]

<swoag>

Hostile: ?

[10:41]

you said we'll push a new release based on the latest codecs by the end of the week

[10:41]

when do we think we'll have qtime/ipod fixed?

[10:42]

<swoag>

JoeBorn, 3/13 release will be my guess.

[10:42]

ok, sounds good.

[10:42]

<swoag>

JoeBorn, however we are pushing to see if we can get something working by the end of the week.

[10:42]

so anders_ go ahead and ask away about xmms2

[10:43]

that sounds even better:)

[10:43]

<swoag>

JoeBorn, well my guess often doesn't work out great. :-(

[10:44]

<swoag>

we'll just have to see in which way. ;-)

[10:44]

<swoag>

Hostile: sorry for the confusion. 3/7 is a formal release. 3/9 will be an internal experimental one.

[10:45]

oh. is there anyway I can get my hands on that ;-)

[10:46]

swoag: is the difference just whether JoeBorn publishes a blog on the release?

[10:46]

<swoag>

Hostile, specifially on the diff between 3/7 and 3/9, no ;-( but we definitely need more help on bug reporting part at least.

[10:47]

<swoag>

Hostile, because the diff I meant was to integrate vendor's new release. ;-)

[10:47]

* Hostile likes new vendor codecs

[10:47]

<swoag>

sourcerror, pretty much.

[10:47]

sourcerror, yes, it's pretty much just the blog

[10:48]

anders_, you still there?

[10:48]

* swoag likes new but hates new_and_broken stuff.

[10:48]

I'm anxious to hear your xmms2 issues

[10:48]

alright swoag can you update me on the status of xmms2

[10:49]

<swoag>

Hostile, I'd like to hear that from anders_ ...

[10:49]

oh. I must have missed what anders said somewhere

[10:51]

Hostile: i think if you stay up to date with svn trunk you get all goodies before the official releases (and some random brokeness, of course, but you can always rollback to a safe date you know works)

[10:51]

<swoag>

anders_ has got the nano-x patch (fd registration support) working, it seems to me the rest of the stuff is just GUI integration.

[10:52]

nerochiaro: hmm. I don't netboot though, and I get nervous about flashing my own upks.

[10:52]

Hostile: oh, then you wait for official, yes

[10:52]

I play it safe :)

[10:53]

<swoag>

Hostile, the internal release from Xiamen is pretty safe, I'd say.

[10:53]

swoag: that patch needs also to be adapted if you want to run the server stand-alone

[10:53]

swoag: where would I be able to find that when you release it?

[10:53]

<swoag>

nerochiaro, yes, I did that when I experimented with the server.

[10:53]

swoag, well the reason I keep pushing the xmms2 issue is that I believe you're right, it UI integration, but we've been stuck at that state for months now I think

[10:54]

and my concern is the issues with cooler are an impediment to getting that done.

[10:54]

which is weighing on my judgment regarding the Qt/cooler discussion.

[10:55]

it just seems like a lot of projects die when they get to the "gui integration" stage

[10:55]

<swoag>

Hostile, it is on Xiamen ftp, I posted in on ML.

[10:55]

<swoag>

*it

[10:55]

excuse my lack of knowledge, what is ML?

[10:55]

<swoag>

Hostile, you are WARNed that this is internal release, neuros.com.cn neurosftp/qwer1234

[10:56]

=P

[10:56]

<swoag>

Hostile, sorry, mailing list

[10:56]

swoag: ahh that makes sense.

[10:56]

swoag: by the way in my work trying to use ncooler, one annoying thing is lack of prefix on cooler functions (e.g. ncooler_) it makes tracking down what is in cooler vs. osdmain annoying.

[10:57]

...that goes for enumerations and #defines also :)

[10:57]

<anders_>

Sorry, I was away for a minnute.

[10:57]

<swoag>

JoeBorn, a lot of project _may_ die because of GUI integration, but I'd definitely don't want osdmain die because of this. :-)

[10:58]

sure, I'm with you there.

[10:58]

<swoag>

well, let's hear what anders_ says first?

[10:58]

sure

[10:58]

<anders_>

Unfortunately I haven't had any time to work on xmms2-client in osdmain.

[10:59]

<anders_>

Did I ever publish my work so far?

[10:59]

<swoag>

sourcerror: very good point. we should fix that if we decide to continue to go with cooler.

[10:59]

anders_: if you did, it's better you give out the address for where you published again, i'm not sure we all have it

[11:00]

<swoag>

anders_, I got your nano-x patch in formal release, but that is it.

[11:01]

sourcerror: excellent point. also i'm a fan of functions names in prefix_widget_function style, but i'll settle with PrefixWidgetFunction style if it's too much of a problem

[11:03]

<swoag>

anders_, what is the latest status with xmms2 on OSD? maybe someone in Xiamen can pick up your work with your direction?

[11:03]

<anders_>

people.0x63.nu don't expect any wonders, address to connect to is hardcoded.

[11:04]

<anders_>

r3main.c needs to be patched to call InitXMMS2();

[11:04]

<swoag>

anders_, link NOT found?

[11:04]

nerochiaro: I actually use something from more C++ style... functions, variables are: methodName, variableName. types don't need the _t but are: TypeName. The problem is C doesn't have classes so going across modules I prefix with: moduleName_

[11:04]

<anders_>

swoag: Try now.

[11:04]

...that's like Java style also.

[11:05]

<anders_>

Also, nw-main needs to get a new menu-entry that calls ShowFormXMMS2Playlist();

[11:05]

<swoag>

anders_, worked, thanks.

[11:05]

sourcerror: hmm, mixed underscore and camel case feels ugly, but everyone has their style for doing "OO-like C" so it's just another useless holy war. anyone is actually ok for me, i was just nitpicking

[11:06]

nerochiaro: it is ugly I admit but it exposes the cross moduleness vs. just a longer name.

[11:08]

nerochiaro: we probably agree self consistency is most important :)

[11:08]

<swoag>

anders_, ok, that contains the GUI code, where do you keep the rest of the stuff?

[11:09]

<anders_>

swoag: xmms2d itself is what I published ages ago..

[11:09]

<anders_>

swoag: (during development of the gui stuff I've been running xmms2d on another computer though, connecting over tcp)

[11:10]

<swoag>

anders_, sorry, but I think we lost track of that. do you have a link somewhere?

[11:10]

but anders_ I guess my question is it seems like porting xmms2 happened quickly and you already had a GUI on another machine to control it

[11:11]

<anders_>

wiki.xmms2.xmms.se

[11:11]

then porting that GUI stalled.

[11:11]

<swoag>

anders_, wow, that is great!

[11:12]

it's more like there was a need to rewrite a gui entirely in cooler, no ?

[11:12]

<anders_>

Also GUI development required access to TV, meaning that it couldn't be done everywhere/anytime like the porting of the headless app..

[11:12]

and my concern is that's related to this WM thing and cooler

[11:13]

wow, that's kind of crazy you didn't know about that swoag !

[11:13]

<anders_>

Then I did some investigations with lua-in-mainapp instead of working on gui last time I had time to work on OSD stuff.

[11:14]

I think the access to a TV is a significant issue actually.

[11:14]

It took me months to get that setup myself at home (and it was really important to me)

[11:15]

* swoag feels terrible that lots of things fall into crack...

[11:15]

Once we have a XMMS2 gui in the main app will I still be able to connect to xmms2 over a PC client?

[11:15]

* nerochiaro loves tv tuner cards

[11:15]

I didn't have a TV next to my PC,

[11:15]

<anders_>

Hostile: Yes.

[11:15]

excellent. because I want to hook my OSD up to my stereo system to play shoutcast and stuff, and I don't have a TV over there, so I could just control it from my PC

[11:16]

nerochiaro: yea, I had this tuner card sitting around forever unused until the OSD came along actually.

[11:17]

<swoag>

anders_, I assume that link contains both xmms2 srv/client stuff OSD needs, we'll just need a GUI for it?

[11:17]

<anders_>

swoag: right

[11:17]

<anders_>

"just"

[11:17]

but the TV issue is another reason why a conventional toolkit has an advantage, no?

[11:18]

developing all on the PC, at least you can make a lot of headway without TV, right?

[11:18]

it just seems to me that we've seen this over and over with projects.

[11:18]

well are there any ways to run Nano-X in a window on top of X (in a window) for testing?

[11:18]

the app gets ported quickly and then dies at the GUI integration stage

[11:19]

XMMS2, YouTube, asterisk, etc

[11:19]

<swoag>

anders_, alright, audio support is high on our to-do list, I'll have folks in xiamen look at this, and, bug you with questions?

[11:19]

JoeBorn: absolutely. it helps with the GUI part a lot to be able to do it on PC without touching the OSD

[11:19]

<anders_>

swoag: sure!

[11:20]

sourcerror: yes, swoag knows more about that

[11:20]

sourcerror: not sure how practical that is however

[11:20]

but it simplies getting some gui basics up and running though it seems.

[11:21]

sourcerror: and also not sure how much ready is cooler to be used on a non-OSD environmnent. i think you need to ifdef lots of stuff if you want to use it on PC over X

[11:21]

s/simplies/simplifies

[11:21]

one of the problems is that cooler is GUI+utilities stuff. splitting it would also help

[11:21]

ah, right stuff tied to non gui parts.

[11:21]

<swoag>

sourcerror: yes, you can build all GUI code on PC with nano-x.

[11:21]

* Hostile would like to see this in a release soon, XMMS2 is awesome.

[11:22]

<swoag>

however, the tricky part is you have to compile control all OSD specific functions (audio/video), which is true to _any_ other toolkits.

[11:23]

swoag: i see.

[11:23]

<swoag>

actually the intial version of OSD GUI was entirely built on PC,

[11:23]

<swoag>

that is why you still saw 'ARM_BUILD' complier switch there in the code,

[11:23]

yea I've seen that

[11:24]

swoag: that is true for some GUI features. but cooler has also lots of stuff in it that is not gui and is osd specific. i think it would be cleaner to separate cooler in more discrete pieces. cooler-gui, cooler-utils, cooler-blaster, something like that

[11:24]

<swoag>

we sort of ditched because as project moves, it doesn't make much sense to do that any more.

[11:24]

I've tried to make my code do a host vs. arm build but now it was seeming impossible once I'm into GUI stuff.

[11:26]

<swoag>

sourcerror, true, because we ditched that support actually.

[11:27]

<swoag>

nerochiaro: I guess mixing everything in one big lib does work well, that is the root cause.

[11:27]

* swoag wonders if anyone know where Neuros-Cooler came from and what it means.

[11:28]

swoag: it's easier to build against if you are osdmain, but if you need only parts, it's annoying

[11:28]

* sourcerror did wonder several times

[11:28]

swoag: see crweb's remarks of some time ago

[11:29]

<swoag>

someone had the design thought that "well, let's have a lib that contains _everything_ OSD platform needs, sort of like a cooler where you can throw beers, bread or whatever in."

[11:30]

swoag: up to a certain point that's not wrong, but GUI should be definitely separated in my opinion, at least. then you can have cooler-beer to put anything else that doesn't warrant a separate lib into (small OSD-specific things, that make no sense on their own)

[11:30]

<swoag>

now I think at least we should separate the GUI part completely out?

[11:30]

haha :) so now we need mini-coolers to separate the alcoholic bevs from the food.

[11:31]

<swoag>

sourcerror: exactly.

[11:31]

swoag: especially if people is interested in replacing the GUI part, having it in one big chunk makes that harder

[11:31]

good bit of lore on the cooler name ;)

[11:32]

<swoag>

alright, speaking of the GUI toolkit ...

[11:32]

by the way, I don't want to replace or fork the gui from osdmain, but I'm trying to make a proof of concept new osdmain. I can try to explain in IRC but the best way for me is to show with code.

[11:33]

sourcerror: yeah, definitely. or mockups

[11:34]

<swoag>

I'd like to see some of proof of concept thing, I know crweb is working on something.

[11:34]

swoag: crweb is working exactly on that for QT, he told me it will probably be ready for 7th or around that date last time i checked

[11:34]

yea. and hopefully ideas can merge back into single thing that everyone will agree on.

[11:36]

<swoag>

I myself will do some research, but you all know how hard it is to swing from what you've already got. It is a tough call.

[11:36]

<swoag>

if anyone is interested with what I experimented,

[11:36]

swoag: it really is. and first of everything we need to decide if it's really worth it. i think the jury is still out on that one ?

[11:37]

or there's a consensus that cooler GUI has to be ditched sooner or later ?

[11:37]

<swoag>

check out the mgao_wm_070220 branch,

[11:37]

<swoag>

I've got the WM working, with a helloworld application demo.

[11:38]

<swoag>

look at extra-apps/demos/helloworld/helloworld.c

[11:38]

well, I know I'm an ignoramus on this, but I still struggle with why this can't be done in peices over time.

[11:38]

swoag: sounds great! can you give us a quick idea in words how the WM operates?

[11:39]

<swoag>

WM is just a regular piece of nano-x application.

[11:39]

I think it can be done in pieces. I think the WM ideas are layered on top of the toolkit or should be separate.

[11:39]

<swoag>

osdmain servers as the desktop

[11:39]

swoag: i'll give that a shot later on. however it's still a nano-x only wm. which means cooler-only apps basically. so the point we were also discussing the other day with Joe is if it's wise to keep on that path (nano-x/cooler only)

[11:40]

I understand picking the WM itself is a emotional subject, but once we pick that, I'm not sure why we can't adapt our API to that one over time.

[11:40]

<swoag>

helloworld is another app that can be loaded and run by osdmain.

[11:41]

<swoag>

while helloworld (the app) is running, you can choose to shut itself down (HOME button) to go back to desktop, or go directly to desktop and leave helloworld run in the background.

[11:42]

<swoag>

then from desktop, you'll notice there is an icon (ugly of course) to indicate whether helloworld is currently running.

[11:42]

home shuts down and back leaves it running minimized or something?

[11:42]

<swoag>

all are very rudimentary experiment.

[11:42]

<swoag>

JoeBorn, something like that.

[11:43]

sounds good. HOME is always catched from WM, right ? apps never get that key

[11:44]

<swoag>

nerochiaro: yes, I got that part, that is why I keep saying it is an 'experiment', not to drive you guys nut. ;-)

[11:45]

swoag: nice! I have maybe a slightly different view of how applications should be running. I think the OSD should be not the traditional "start/stop app" experience like on a desktop...

[11:45]

it's a good experiment, but only good if we want to keep nanox (or migrate slowly to something else with 2 parallel version). otherwise it's a bit of a waste of time. just saying that we should pick a path for this toolkit issue and follow that sooner rather than later.

[11:45]

<swoag>

nerochiaro: for the experiment, HOME is catched by the app itself.

[11:47]

...i think once a plugin app is loaded implicitly because it is in certain directories on the media, then it is always running and just another integrated part of the app. but it has to play nice in that when the app doesn't have focus/visiblity then it goes into low resource usage mode.

[11:48]

so the app gets events sent to it like APP_HIDE, APP_SHOW along with when the screens are pushed and popped

[11:49]

<swoag>

nerochiaro: i am with you, I am all ears.

[11:49]

<swoag>

sourcerror: that is definitely another way of expanding, in a single application way.

[11:51]

well, swoag and I are coming at this from different viewpoints

[11:51]

obviously I don't know anything about the details of the engineering,

[11:51]

how big these other toolkits are, how much integration, what they can do and can't etc

[11:51]

nerochiaro: how does another toolkit eliminate the need for a better WM infrastructure? they seem like two separate issues.

[11:52]

my view is very simple

[11:52]

@ phone, sorry

[11:53]

it just seems like everytime we "roll our own" it's a mistake and almost everytime we choose somethign off the shelf we're better off

[11:53]

from web services to operating systems, etc.

[11:53]

and I find it hard to imagine that motorola and sony can both choose to use off the shelf toolkits

[11:54]

when they have fairly proprietary stances in the market, along with massive resources

[11:54]

and yet Neuros with very limited resources and a quiet open stance in the market

[11:55]

that somehow it'd make sense for them to use something off the shelf and not for us.

[11:55]

ok

[11:55]

back

[11:55]

and given that raster was in the thick of our development of the hardware, it seems hard for me to believe that we don't have the HW resources for it

[11:56]

JoeBorn: what you said about rolling our own was a very good point

[11:57]

I mean I understand that's just a high level assessment that misses all the details, but still

[11:58]

sourcerror: it doesn't eliminate the need for a better wm, but the wm we are going to use depends on toolkit (unless we go with X, at which point it's all another matter, but let's suppose we don't for now)

[11:59]

<swoag>

here is how I view it, or at least to explain where we came from and where we are.

[11:59]

swoag: the choice to go with cooler GUI was made because of performance reasons ?

[11:59]

I can say in my day job. It is the same. We can't afford to waste time reinventing the wheel, but at the same time tool vendors don't always scale to our designs and crap out on the size of them. So hard decisions...

[12:00]

<swoag>

As a developer myself, I am all for a fancier toolkit, off the shelf goodies etc, however,

[12:00]

...are made to do stuff in house that appear to not be done anywhere else but we need to do for competitive edge/difference.

[12:00]

sourcerror: however most of the time in other business there's not the problem of making it easier for the community to hack. here it's a primary concern, and cooler doesn't help that

[12:00]

<swoag>

I start from the HW resource part, as of today, HW resource is still an issue, but not

[12:01]

<swoag>

as big as it was at the early stage of the project (OSD project started with 8MB flash and 32MB SDRAM), and

[12:02]

<swoag>

DM320 has the capability (multiple layered video window, GUI window, even with a dedicated mouse layer),

[12:02]

nerochiaro: you're right. I think if we had a good app plug-in model already and cooler was more organized then we'd have more people experimenting with cooler than complaining about it.

[12:03]

sourcerror: chicken and egg problem, kind of

[12:03]

<swoag>

but what we do (audio/vidoe stuff) still makes it resource hungry (ARM goes up to 90% loaded with audio encoding),

[12:03]

<anders_>

I wish I had more time working on my lua-in-osdmain stuff. That really would make hacking on the osd easier..

[12:03]

AFAIK, dm320 already has Qt running on it in a finished consumer product

[12:03]

it seems more like "swoag overloaded and can't implement all the stuff he wanted to" problem.

[12:04]

www.trolltech.com

[12:04]

<swoag>

and we have to face the reality that we can not make our assessment on that we can utilize _every_ piece of the HW capability.

[12:05]

<swoag>

based on the resource issues we had, nano-x was chosen because it has the minimal memory footprint, there is an off-the-shelp toolkit (FLTK?) for it,

[12:06]

<swoag>

I didn't pick it also because of the memory.

[12:06]

nerochiaro: my approach to the chicken egg problem is to try to take on the WM or plugin problem myself and hope you guys decide on the underlying toolkit :)

[12:06]

<swoag>

long story short, nano-x was chosen and development has been done on top of it for over a year,

[12:07]

...I'm betting on Nano-X and refactoring tiny parts of cooler as I go along.

[12:07]

<swoag>

it is just too hard for me to believe that we even have the chance to thow it away.

[12:07]

<swoag>

on the other hand,

[12:07]