Log from #neuros IRC channel

so what should we do now? you've got the parser and fetcher and Gao will work on getting the files to play right (although confusingly Johan said his played fine)

[10:32]

* JoeBorn notices jug has gone missing

[10:32]

so what should we do now?

[10:32]

<anders_>

World domination?

[10:32]

and I guess the question is not that different for XMMS2

[10:33]

* JoeBorn sounds "world domination attack charge" horn!!!

[10:33]

we should make an interface to allow people to find videos

[10:34]

in osdmain?

[10:34]

I guess that's my question, it seems to me that there are two approaches

[10:34]

well, on the OSD. osdmain or not will be less relevant once we have the WM

[10:34]

since it seems there's no real interest in programming for osdmain, and I believe I have a decent handle on why

[10:35]

<anders_>

Whatabout luascripts running from osdmain?

[10:35]

I guess my question is should I put together a UI and hand it off to the xiamen team to implement since no one outside of there will touch OSDmain with a ten foot pole

[10:35]

anders_: they still need to use the cooler widgets for user interface, which are probably one of the things that keeps people away from osdmain in the first place

[10:37]

<anders_>

Why doesn't people want to use cooler widgets?

[10:37]

nerochiaro, I believe you have some ideas :)

[10:37]

anders_: well, it's just my guess but

[10:38]

anders_: thy require tedious amounts of boilerplate code to do things that are best handled automatically by the toolkit

[10:38]

in a nutshell. i can forward you an email with more details if you want

[10:39]

<anders_>

Please do.

[10:39]

doing

[10:39]

would love to get your insight into that issue.

[10:39]

Gao is the first to admit that he's from a firmware background

[10:39]

<crweb>

sounds like he's got the email handy. Heh

[10:39]

we need to make sure that we don't make the same types of high level architecture mistakes as we did with OSDMain, etc

[10:40]

BTW, all I have a big announcement to make!

[10:40]

anders_: PM me your email address, please

[10:40]

crweb: i had gmail open

[10:40]

<anders_>

nerochiaro: andersg@0x63.nu

[10:41]

anders_: there you go

[10:43]

nerochiaro and I are getting married!

[10:43]

um, no wait that wasn't the announcement

[10:43]

eek, put down the alchool please !

[10:44]

no the real announcement is that we're very close to inking a deal whereby nerochiaro comes on to Neuros full time

[10:45]

stunned silence grips the channel

[10:45]

* nerochiaro watches tumbleweed roll by, shrugs and goes brewing a cup of tea

[10:45]

<crweb>

hmm.. tea

[10:46]

<crweb>

oh oh, contgrats :)

[10:46]

nice warm cup of earl grey

[10:46]

and thanks :)

[10:46]

<crweb>

I was just editing the vm page

[10:46]

so anyway, just thought you'd all like to know that.

[10:47]

back to the YouTube/XMMS2 and window manager issue.

[10:48]

I guess my question is what does everyone think the timing is on a new WM and should we integrate these new apps in OSDMain (presumably using the xiamen team to do so)

[10:49]

once we have the WM there's no more need to integrate the apps any more than putting them in the "applications" menu

[10:49]

nerochiaro, yeah, exactly my point.

[10:49]

where by "integrating" i mean "making them part of osdmain as single block"

[10:49]

should we do it now, or "once we have..." is the questio

[10:51]

i thought Gao wanted to have the WM soon

[10:51]

but anyway

[10:52]

it doesn't seem a bad idea

[10:53]

however the people who are put off by cooler will be still be put a bit off, since you will still be writing cooler apps, just not in a single block within osdmain

[10:54]

well, I guess that's a second question, are the WM manager and the cooler widgets independent subjects or are the linked?

[10:57]

anders_, did you read nerochiaro email on the cooler stuff?

[10:57]

the WM can run only applications written for nanox or for nanox-based tookits, such as cooler. i'm not sure if there are other, potentially better, nanox-based gui toolkits

[10:59]

<anders_>

Sorry, I got caught up with other stuff.

[11:03]

well, I'm looking forward to Gao's response to your email nerochiaro, but I feel pretty confident that after working with him for years, I have a pretty solid understanding of the context

[11:04]

it's just a difference between embedded and pc development thinking, IMHO

[11:04]

the embedded guys come from these assembly and micro backgrounds where you often program this highly efficient assembly language etc

[11:05]

on the PC side, the cleverness and effort is applied to unique functionality and speed of cranking out that functionality

[11:06]

embedded guys don't value the latter and "PC guys" don't value the former (obviously this is a silly and black and white characterization but you get the point)

[11:07]

but my view today is that the OSD is a big big project and it will collapse under its own weight if we don't employ those high level development tools

[11:07]

<crweb>

JoeBorn: with the growing popularity of embedded development and hardware. I feel thats changing

[11:08]

and I don't believe at all that they will be inherently slower, I've seen too many embedded device run Java, etc just fine to believe they won't work well in "low powered" devices.

[11:08]

crweb, yep I agree with you there.

[11:08]

but I'm just saying our team by and large comes from the traditional embedded space.

[11:10]

well, the things that i think are "not attractive" of cooler are not derived from a "let's optimized to the metal" kind of thiking. they seem to come more to the fact that the in-house devs don't care if writing the same piece of code over and over is boring and useless, they just do it because "that's the way". there seem to be no will to refactor things that are cut and pasted over and over into reusable blocks instead

[11:11]

for example

[11:13]

in cooler the logic to jump from widget to widget have to be micro-managed by the programmer. you have to write these huge switch statements where for each single widget you say "when we press the right key go to this other widget, when we press the left key go to this other widget" ... and this is repeated for every widget on the window

[11:15]

<crweb>

I just figured its not a completed toolkit. not that its that way by design

[11:15]

well, possibly, but that's not pleasant to use anyway

[11:15]

it's just my opinion of course

[11:15]

maybe others just don't care

[11:16]

but i'm just thinking that to maybe this is turning down contributions

[11:16]

not that it's the only factor or even the main one

[11:16]

well, as I mentioned, I believe it's a big problem and I'm convinced the folks we want to recruit will care.

[11:16]

quiestion is how do we fix it?

[11:16]

we fix cooler

[11:22]

so keep cooler, but fix it?

[11:22]

and forget about E17, Qt?

[11:22]

or borrow from them or ???

[11:22]

they require a considerable amount of re-engineering of osdmain that rules them off

[11:22]

in the short term at least

in my opinion

crweb? anders_ ?

what say you?

<crweb>

I hate to say it, but I think he is right. Qt is an amazing toolkit. You can produce gui's features and code extremely fast.

[11:24]

<crweb>

but, ncooler is here, its invested

[11:24]

<crweb>

you either throw it all away and start over (which now that things are being removed from osdmain would be much easier)

[11:24]

<crweb>

or fix it

[11:26]

there's a middle ground which i've been experimenting on which is basically wrapping QT or e17 into the cooler API, then phasing out cooler gradually. but it's kind of a minefield to do.

[11:27]

<crweb>

the problem with qt is, you use qt for EVERYTHING

[11:27]

same with any other toolkit

[11:27]

<crweb>

true

[11:28]

<crweb>

qt provides http, ftp, sql, all that stuff :)

[11:28]

<crweb>

anyway... heh..

[11:28]

let's focus on the GUI right now

[11:28]

:)

[11:29]

clients you mean? ftp, http?

[11:29]

<crweb>

i could go on forever about that

[11:29]

<anders_>

Well, I wouldn't mind having qt instead.. But that isn't really my call.

[11:29]

crweb: yeah, that's why i was saying let's focus.

[11:29]

hmm... ok.

[11:30]

so the wrapping thing is too much of a minefield in your opinion, nerochiaro

[11:30]

?

[11:30]

why just for my own education

[11:31]

<anders_>

But the cooler issues doesn't seem that big huge to me. But I haven't digged that deep.. But it shouldn't be that hard to refactor them to make it easier to use?

[11:31]

yeah, i didn't have much time to pursue that avenue lately, but from the little i have already done on that idea it seems one these "seems easy but in fact it's filled with little traps and pitfalls" kind of deals

[11:31]

anders_: no, it should not be that hard

[11:32]

anders_: it needs only sitting down and put some time and manpower into it

[11:32]

er, brainpower :)

[11:33]

<crweb>

needs some designing, yes

[11:33]

again, i'm not saying it's disgusting and no one will touch it even with a 10ft pole. it just has kinks that need some desing ironing

[11:36]

well, gao will certainly view refactoring cooler more favorably then replacing it, I imagine

[11:37]

i would suppose so

[11:37]

but I can't help avoiding the feeling that we're re-inventing the wheel, I mean these other projects have been around for years

[11:37]

with the concerted effort of a number of talented experienced folks.

[11:38]

Gao's point is that they are all mouse based which impacts the architecture overall, how things flow, windows work etc

[11:39]

<crweb>

JoeBorn: you have to write keyboard controls for them

[11:39]

the way to do ncooler or refactored ncooler and not reinvent is to... keep features minimal (I think).

[11:39]

well, these can be adapted

[11:39]

ncooler by itself is already a wheel re-invented

[11:39]

<crweb>

but they most certianly aren't bound to having to have a mouse

[11:40]

nerochiaro, right, I don't want to throw good "effort" after bad so to speak regarding cooler...

[11:40]

crweb, well if a system relies on a window with an _O X at the upper right, it's fundamentally designed for mouse navigation

[11:40]

JoeBorn: it's all a matter of timing. neuros decided to go down a certain path with cooler, and right now it's not the best moment to change course radically

[11:40]

<crweb>

JoeBorn: thats why you don't draw windows like that

[11:41]

JoeBorn: window borders are also something that is done by the WM

[11:41]

well, honestly my problem is I still don't really understand what Qt, E17 really do.

[11:41]

JoeBorn: all the widgets you see _inside_ windows. that's what they do

[11:41]

in a nutshell

[11:42]

I was actually working on a proposal (code example) for at least a focus manager. that would save a lot of the code junk in the GUI apps.

[11:42]

a very small nutshell at that

[11:42]

<crweb>

windows themselves are widgets

[11:42]

<crweb>

they can be drawn with or without borders, X's, etc

[11:42]

sourcerror: that would sure be a good improvement

[11:42]

crweb: but the toolkit stops there. borders are managed by the WM

[11:43]

<crweb>

what you see on desktops is a window manager placing a border with mouse controls around the window

[11:43]

<crweb>

nerochiaro: kinda. the WM is usually based on the toolkit being used.

[11:43]

crweb: not necessarily

[11:43]

<crweb>

nerochiaro: start a kde app in gnome, kde still has its same theme, borders, and controls

[11:44]

<crweb>

i can tell my qt app to draw with or with out borders and controls

[11:44]

<crweb>

but yes, WM does do that

[11:44]

crweb: not really. i'm in e17 as window manager. borders are e17 borders even if i run KDE or Gnome apps

[11:44]

<crweb>

qt app in twm is twm borders

[11:44]

er, QT or GTK apps

[11:45]

ok, let's not add confusion. JoeBorn are you still there or confused ?

[11:45]

I'm here and confused :)

[11:46]

<anders_>

e17 is a full evironment, no? Both windowmanager and widgetset?

[11:46]

<crweb>

JoeBorn: www.limesg.com

[11:46]

<crweb>

JoeBorn: thats qt4 application running on OSD

[11:46]

<crweb>

no mouse, no borders, no X's

[11:46]

can't fine that image

[11:46]

404

[11:47]

<crweb>

JoeBorn: www.limesg.com

[11:47]

<crweb>

JoeBorn: www.limesg.com

[11:48]

<crweb>

is the same

[11:48]

cheese?

[11:48]

<crweb>

sgomes: bubbles

[11:48]

ah :)

[11:48]

<crweb>

its just a back ground image

[11:48]

I know, but I found it funny ;)

[11:48]

<crweb>

JoeBorn: everything you see, is Qt

[11:48]

anders_: e17 has a WM (called E) and 2 widget toolkits (called EWL and ETK)

[11:48]

<crweb>

a badly designed qt

[11:49]

<crweb>

and with really bad artwork

[11:49]

<anders_>

nerochiaro: Right, thanks.

[11:50]

well, I'm not sure what I see there to be honest. in the second, I see a UI that look familar to a lot of devices

[11:50]

JoeBorn: on the same spirit, this is an e17 app running on the osd: img212.imageshack.us

[11:50]

<crweb>

JoeBorn: the buttons, the drawing on the screen, the text, all of those things are Qt widgets

[11:51]

nerochiaro: thanks for the vonage ad ;)

vonage ?

mine is t-mobile :)

popup ;)

not my fault if your browser can't kill popup ads ;)

[11:52]

probably would help I guess to see the underlying code, I guess.

[11:52]

JoeBorn: i'm not sure

[11:52]

it will help clear your confusion

[11:52]

I guess firefox didn't block it.

[11:53]

firefox blocked it for me.

[11:53]

well, sorry about that ad. it's the only image pastebin i know that retains them a long time

[11:53]

<crweb>

JoeBorn: underlying code.. would look something like QPushButton *okButton = new QPushButton("Save");

[11:54]

<crweb>

JoeBorn: creates a new button, that you can place in a layout. Layouts position the widget in its correct place on the screen

[11:54]

<crweb>

JoeBorn: a layout is drawn by X on the screen. Producing the GUI

[11:55]

wait, drawn by X?

[11:55]

JoeBorn: if that's any help to you, sample code is here: pastebin.ca

[11:55]

JoeBorn: but i guess it's not

[11:55]

<crweb>

JoeBorn: on your desktop, X is what draws the data to your monitor

[11:55]

<crweb>

JoeBorn: on the OSD its currently nano x

[11:55]

JoeBorn: either nano-x or direct framebuffer drawing

[11:56]

crweb: does QT use nano-x underneath ? doesn't it go to fb directly too ?

[11:56]

Qt provides images to X?

[11:57]

<crweb>

JoeBorn: in a manor of speaking

[11:57]

yeah, I'd need some pointers on where to look on this source code... but probably not important right now

[11:57]

JoeBorn: no, X provides QT a "canvas" on which to draw whatever it wants. that "canvas" is all the space bounded by the window borders

[11:57]

ok

[11:57]

<crweb>

JoeBorn: Qt phsycially tells X to draw something in a given space

[11:57]

ok

[11:58]

ok, well what distinguishes QT from E17? the way they do things or the specific widgets or the appearance of the widgets or the way they are customized?

[11:59]

<crweb>

JoeBorn: all of that yes.

[11:59]

all of that, also style of the API and other technical details. all very geeky stuff that would bore you to death probably ;)

[11:59]

somehow QT and E17 are different enough to evoke emotions supporting respective favorities, but how that could be is a mystery to me, I don't understand how they are different

[12:00]

<crweb>

Its the stuff people don't see that makes them way different

[12:00]

<crweb>

the code, the design, the API, the tools, provided features, etc

[12:00]

JoeBorn: because your job description is not that of a software developer ;)

[12:00]

that's the reason of the mystery

[12:00]

for example, those gold buttons, the appearance, etc I assume that's irrelevant?

[12:01]

JoeBorn: well, depends. it's a feature.

[12:01]

the navigation method with those arrows up and to the side, is that relevant to the difference between thsoe two?

[12:01]

the appearance of the fonts? is that an issue?

[12:01]

they are all factors

[12:01]

an issue of difference?

[12:01]

but as crweb said, it's what you don't see that matters to geeks

[12:02]

what products use QT?

[12:02]

which products use E17?

[12:02]

I guess the Sony PS3 has a boot option to yellow dog linux and E17

[12:02]

FWIW

[12:03]

I know that it's a big frustration of Gao's that we have these really crappy flat looking buttons on the OSD

[12:03]

and he's looking for something more like what's shown in the E17 jpeg

[12:04]

but that seems more just like a small picture that he's planning on using within cooler

[12:04]

(thus my confusion)

[12:04]

JoeBorn: basically yellow dog for ps3 is the first and basically only thing of a certain weght that i know of that uses e17 (aside of tons of e17 desktop users, of course). e17 has the problem that it's technically "not released yet" and "will be ready when it's ready" kind of project. it's perfectly usable and mature though, as the PS3 thing shows

[12:05]

JoeBorn: what you mean "a small picture" ?

[12:05]

well, what I mean is this

[12:05]

gao asks jolson for a picture, bmp or whatever to replace crappy buttons (up and depressed)

[12:06]

then the buttons will look good.

[12:06]

Thus I'm forced to conclude that appearance is somehow not something inherent to cooler

[12:07]

now I'm left with the conclusion that it's primarily a matter of implementing new UIs that's at issue here

[12:07]

Gao wants to add a feature to cooler: he wants to make cooler themeable (or skinnable if you prefer)

[12:07]

or perhaps difficulty with implementing an improved button appearance (for exampl)

[12:07]

that is, he wants to have the ability to alter the aspect of the widgets

[12:07]

<crweb>

JoeBorn: adobe photomaker, skype, Sidekick 3, Sharp Zaurus, Greenphone, Opera, Everything in KDE, MythTV

[12:07]

<crweb>

JoeBorn: all qt

[12:07]

<crweb>

JoeBorn: www.trolltechvideo.com

[12:08]

<crweb>

ah, google earth

[12:08]

<crweb>

neat

[12:08]

crweb: yeah, qt has a much larger user base out there

[12:09]

<crweb>

the Qtopia button at the bottom of the Qt Gallery on that flash site is the embedded stuff

[12:11]

phew

[12:11]

well, I guess I'm fine with refactoring cooler since I guess that's the concensus anyway

[12:12]

JoeBorn: the bottom about cooler v/s other toolkits here is: there are lots of factors that makes programmer prefer one toolkit to the other. many are excessively technical, others also regard available features (such as the themeing ability we mentioned). but in the end i think programmers always prefer to use a stable, mature, well-featured tookit insted of one that was put togheter ad-hoc, with a short design history and that is still in

[12:12]

I'm concerned that it will continue to be an impediment to porting stuff since there's not anything in cooler

[12:13]

right understood on that.

[12:13]

I mean the XMMS2 situation is a good example.

[12:13]

<crweb>

learning a toolkit is an investment.

[12:13]

I imagine if we had E17 or QT it probably would be available by now.

[12:13]

JoeBorn: probably, since there are more users of both QT and e17 already

[12:14]

crweb, and it's one more investment that we're asking users to make to get started with the OSD, which is not that appealing

[12:14]

what crweb said is very true

[12:14]

yeah, not just users, but already applications, there are front ends for both QT and E17, IIRC

[12:14]

for a quick hack they can just take cues from existing code. but to start an app from scratch with cooler needs investment in learning it

[12:15]

JoeBorn: front-end ?

[12:15]

the wrapper thing seems very appealing for that reason, but the fact that both nerochiaro and Gao seem to feel there are real impediments to implementing, I guess we'll have to wait?

[12:15]

<crweb>

nerochiaro: xmms2 is nothing but a server. It needs something to connect to it to control it

[12:15]

<crweb>

"frontend"

[12:16]

<crweb>

the nicest one i've seen as been that Qt one

[12:16]

crweb: yeah, it wasn't the best example, but you get the point. an xmms2 front-end probably is what joe means

[12:16]

anyone have a pointer to where "wrapper thing" was discussed?

[12:16]

yes, that's what I mean, a UI for XMMS2

[12:16]

JoeBorn: about the wrapper. i would really love to put down with some quality time on that project and see how much of a minefield really is

[12:17]

sourcerror: it wasn't

[12:17]

sourcerror: we exchanged some mails with Joe and Gao

[12:17]

sourcerror: since i'm not actually very sure it's feasible yet

[12:17]

it was just an idea

[12:17]

ok, I was just trying to understand without bothering everyone to repeat

[12:18]

sourcerror: in a nutshell

[12:18]

is there a refactoring option? ie as we fix the widgets to make them less combersome we also use the E17 UI, making it easier to port down the road?

[12:18]

<crweb>

JoeBorn: honestly, you're asking for a tookit war there...

[12:18]

sourcerror: osdmain uses cooler. we create a library that exposes the same API as cooler, but that inside does everything using e17 or another toolkit

[12:19]

crweb: indeed

[12:19]

nerochiaro: thanks.

[12:19]

sourcerror: no problem

[12:20]

JoeBorn: you can't have both i think. we either stick to cooler, or we move to something else. mixing and matching inside osdmain is not possible

[12:20]

well, I'm not sure what that means, but my guess is that no matter what we do, that's probably inevitable.

[12:20]

or at least not practical

[12:20]

"oh that's QT like! You fiend!"

[12:20]

only thing I would suggest is that probably osdmain could be rewritten in the amount of time to create a wrapper. and OSD main would probalby come out for the better.

[12:20]

JoeBorn: it's more "oh they picked QT, i am an e17 fanboy, i will scorn the OSD project"

[12:21]

JoeBorn: that's childish, but some people like to think that way, unfortunately

[12:21]

well, in the words of margaret thatcher, the trouble with being in the middle of the road is that you are hit by traffic from both sides.

[12:21]

<crweb>

aslong as gtk isn't being considered, probably won't get to much backlash from qt lovers.. heh

[12:22]

<crweb>

which.. gtk shouldn't be considered..

[12:22]

<crweb>

:D

[12:22]

sourcerror: that's also a possibility, and probably one of the reasons for not going down the wrapper road

[12:22]

I mean I don't really know or have much emotional stake, but it seems to me that we have a potential for having a more meaningful and unique relationship with the E17 folks than trolltech for obvious reasons.

[12:22]

JoeBorn: crweb: see ? that's how flame wars start ;)

[12:23]

JoeBorn: i don't really know

[12:23]

about the emotional relationship thing

[12:23]

well, trolltech is a company, they have a booth at tradeshows and employees in polo shirts, I've seen them.

[12:24]

rasterman attends our IRC meetings, it's a fairly stark difference

[12:24]

;)