Log from #neuros IRC channel

<Dark_Aurel>

Hi all!=)

Dark_Aurel, hi. I have a question on the current flash partition. It's static configured in kernel? I usually use mtdparts kernel boot args in my other arm board.

[06:48]

??

[06:50]

<anders_>

Hey, thats my name :)

[07:02]

<daurn>

lol

[13:31]

<JBorn_Handheld>

hi all! Connecting from my blackberry! Fancy huh?

[13:32]

<JBorn_Handheld>

Yes siree!

[13:33]

<JBorn_Handheld>

*ahem* well that's about enough of that!

[13:34]

hehe - I IRC'ed from my palm pilot before :)

[13:58]

right, that's kind of the size of it unfortunately- prove you can do it and that's about it.

[13:59]

I'd perhaps consider it on the bus or something, but it's not too likely to become a habit

[14:03]

heheh - I know

[14:03]

I desperately want a usable handheld like a zaurus or something

[14:07]

* nerochiaro finally gets his ADSL connection back from the dead

[14:07]

yay

[14:08]

it made me realize how much addicted i am to permanent broadband connection

[14:10]

* JoshMalone wishes....

[14:10]

my neighbor's wifi has been really flaky l8ly :)

[14:11]

you share it ?

[14:13]

umm...yeah....that's right...we share it :)

[14:13]

heh, i should have put quotes on that word

[14:13]

:)

[14:14]

problem is there are "3" stock, unconfigured linksys APs in the area and my card keeps roaming btwn them

[14:14]

very big PITA

[14:15]

<anders_>

Whats up?

[14:32]

anders_: i should ask that question actually, i've been missing since thursday

[14:33]

<anders_>

I've been kinda away/offline/busy aswell

[14:36]

i've heard that there was some light skirmish at the last metting on the toolkit issue, but i've yet to read the meeting lots

[14:36]

er, logs

[14:46]

I read them, but wasn't quite understanding

[14:46]

except for the fact that there seemed to be agreement that there would be parallel paths, ie

[14:47]

official neuros development would continue on cooler/nanox (present system) and crweb (and possibly you) would continue on a more "convention" toolkit and

[14:47]

hopefully you'll win eventually?

[14:47]

read them yourselves and see what you get

[14:47]

JoeyBorn: i'll give the logs a peek in a bit

[14:48]

JoeyBorn: getting back to your mail right now

[14:48]

open.neurostechnology.com a little more than half way down

[14:52]

I hope we're not seriously going to full X11 on osd

[14:52]

sure - it can be done, but it's really heavy

[14:52]

* JoeyBorn runs for cover!

[14:52]

LOL

[14:52]

* JoshMalone senses he's hit a nerve

[14:53]

JoeyBorn: did you read that email i sent to the list ?

[14:53]

about X

[14:54]

er, JoshMalone

[14:54]

open.neurostechnology.com

[14:54]

damn, i wasn't used to having both of you online at the same time

[14:54]

what date?

[14:55]

JoshMalone: see link posted by JoeyBorn

[14:56]

* JoshMalone checks

[14:57]

ah - yes...I see

[14:57]

so..this is with Xfbdev?

[14:58]

yep

[14:58]

hmmm...seems like the call to determine current fb configuration is failing...

[14:58]

...possibly due to buggy reporting by the driver?

[14:58]

what does fbset report?

[14:59]

* JoshMalone is sorry that he hasn't been following development

[15:00]

hell I haven't powered up my OSD in months

[15:00]

JoshMalone: there are 2 problems: 1) the current fb driver sucks. you basically can't change resolution, you can only change it when you load the module and only to preset number of modes. 2) the xfbdev has a fixed numbers of resolutions set at compile time, which i really don't like much either

[15:01]

hmmm....weird

[15:01]

and i'm also thinking of trying x.org just for kicks. as far as i understand the modular x.org is based on that fdo xserver anyway

[15:01]

but then again, i'm not really an X expert so i might be babbling incoherently here

[15:13]

what is it that makes people have "hostnames" like JoshMalone's there?

[15:14]

chreekat: freenode's cloaks, i think

[15:14]

chreekat: you can "buy" then with donations

[15:14]

ah

[15:15]

or by requesting affiliate status to some organization which has a registered channel, i think (but my experience with freenode's paperwork tell me the donation route is faster)

[15:17]

I finally figured out how to make utf8 Just Work. My locale setup was wrong, and I fixed it

[15:17]

that can be tricky

[15:18]

yeah, ridiculously so. Lots of parts dancing

[15:18]

now I just need a snazzy WM binding to switch between input languages

[15:18]

<sourcerror-m>

chreekat: locale on OSD?

[15:19]

* chreekat invisions osdcat output and toggling between 3 languages with one button through Ion

[15:19]

sourcerror-m: nah, just for my laptop

[15:19]

(osdcat has nothing to do with *the* OSD, as you may know)

[15:19]

I have yet to do any hacking on the OSD. :-/

[15:19]

<sourcerror-m>

dang. I'm having trouble getting my i18n experiment tow work on the OSD because It seems I can't get the locale to change. I can't figure out why.

[15:20]

<sourcerror-m>

...and that is only one part of problem.

[15:20]

All I know is make sure /etc/locale.gen is right, and then run locale-gen, and then use utf8-aware apps. :)

[15:20]

oh, and set LC_ALL

[15:21]

<sourcerror-m>

if I do something like setlocale(LC_ALL, "it_IT")... then do printf(setlocale(LC_ALL, 0)... it still says 'C'

[15:23]

<sourcerror-m>

so maybe this /etc/locale.gen is something to look at. thanks.

[15:23]

you're sure you have the locales installed? is there a return code from the first call?

[15:23]

* chreekat mans setlocale

[15:23]

<sourcerror-m>

I don't remember offhand, but isn't the first call not return something on a set.

[15:24]

nope, just finished reading, a null return means problem

[15:25]

<sourcerror-m>

you're right. the first call also gives the locale if set.

[15:25]

well, not quite. It sounds like it gives some thing you can use to restore the locale to whatever existed before the call

[15:25]

an "opaque string"

[15:25]

<sourcerror-m>

thanks. I'll check into that (I need to do later though)

[15:25]

yeah, I'm supposed to be working right now...

[15:26]

<sourcerror-m>

:)

[15:28]

<sourcerror-m>

nerochiaro: so, I have two issues with using gettext() now. (1) the locale isn't getting set by setlocale(), and (2) when I bindtextdomain() it still doesn't seem to pick up the translation files I created. I haven't given up yet, just need new ideas.

[15:29]

<sourcerror-m>

...I need to post a stripped down example and see what people think.

[15:30]

sourcerror-m: can you run locale -a on the osd?

[15:30]

<sourcerror-m>

...and I can get it to run on my linux system. so it is not my program as much as I suspect something is not enabled or is stubbed out on the OSD.

[15:31]

i actually have not tried anything yet, i've just tossed you the initial idea

[15:31]

but yes, i suggest you try posting it on the ML

[15:31]

<sourcerror-m>

chreekat: I don't know where 'locale' would come from but it isn't part of busybox as compiled into the OSD

[15:31]

also, have you had the chance to pitch the idea to gao at the meeting, maybe ?

[15:31]

<sourcerror-m>

...so I can't try that command

[15:32]

sourcerror-m: on debian, 'locale' comes from the libc6 package

[15:32]

locale -a lists all available locales

[15:33]

<sourcerror-m>

nerochiaro: oh yea, I was going to mention that to you but forgot since you've been offline for a while :)

[15:33]

sourcerror-m: what did he say ?

[15:33]

<sourcerror-m>

nerochiaro: Gao said he did try to use gettext...

[15:34]

chreekat: sourcerror-m: for the lack of "locale()" you can try starting up the busybox config and see if it supports that

[15:34]

<sourcerror-m>

but couldn't get it to work. so he went the route he did.

[15:34]

sourcerror-m: ah, ok, but he has no objections ?

[15:34]

nerochiaro: the locale I was mentioning was /usr/bin/locale, not a function

[15:34]

<sourcerror-m>

Gao basically said yea if I can get it to work it is the _right_ way.

[15:35]

chreekat: ah, i thought you was talking about this: www.opengroup.org

[15:35]

sourcerror-m: cool

[15:35]

nerochiaro: wait, I am. :)

[15:36]

chreekat: i suppose that command takes info from that directory anyway

[15:39]

<sourcerror-m>

chreekat, nerochiaro: thanks. I'll look that direction.

[15:40]

yes, /usr/bin/locale is just a utility that checks out /usr/lib/locale I think

[15:45]

<sourcerror-m>

(sorry, need to task switch. Sorry... not able to continue conversation at the moment :( )

[15:47]

* nerochiaro is away reading logs

[15:50]

sourcerror-m: bless you for pitching the focus manager/tabbing manager to Gao. i did that too and it's really something that would reduce clutter in the main app code

[15:51]

although my idea of it might be differnt than yours

[15:54]

JoeyBorn: still there ?

[15:58]

yes, I'm here.

[16:01]

from the logs i've got the impression that Gao's stance on the toolkits issue was that we stick with nano-x since we can't afford a full switch at this point, which i agree with, but also that the switch will only happen when someone from the community comes up with a decent replacement which is mostly done and working

[16:01]

which i'm not sure it's quite a good idea

[16:02]

what's your thought? I wasn't at that meeting, as you probably noticed

[16:03]

a second, very related, question is what will you be working on when you start?

[16:03]

as i said i agree we should stick with cooler right now, if i understand right the "commercial" schedules, there's no time to halt dev to do a toolkit switch

[16:04]

JoeyBorn: i don't know what i will be working on. i kind of understood you and/or Gao had already a set of priorities

[16:06]

well, we do, but we're very interested to get your input on your feeling on the toolkit priority.

[16:06]

our priorities are primarily focused on user functionality, ie getting the wifi dongle to work, getting EPG, etc

[16:06]

on the table right now i have this toolkit research, the EPG, X11 research and the wireless driver that you mentioned (which i have not started yet)

[16:07]

oh, and the getting the framebuffer driver to work decently

[16:07]

and youtube...

[16:13]

that too. but getting back to the toolkit priority, it depends. if ditching cooler entirely (and thus fully rewriting osdmain GUI part for the other toolkit) is not an option, then we should at least find a way to make other apps in other toolkits co-exist with osdmain in some way

[16:14]

the problem with nano-x is that the only nano-x-based toolkit i know of is cooler, and that cooler does not entice developers to want to develop with them

[16:15]

now, there are 2 possible solutions to that. first is to use X, thus any app in any toolkit can co-exist on the OSD (and we can use the nice matchbox as WM)

[16:17]

the other solution is to adapt the others toolkits to use nano-x instead of X. this is harder, since many toolkits are not designed to have replaceable backends, or replacing backends is quite a daunting task

[16:17]

JoeyBorn: that's my thoughts on it, more or less

[16:19]

ok, well I think this discussion calls for putting down some other task stuff so I can focus here. Give me one second.

[16:19]

sure

[16:40]

ok, well I'll never get finished, but let me try to focus on this.

[16:41]

well, where should we put the priority and on just what (with regard to toolkit or whatever we're calling this basic area)

[16:41]

so lets start with the latter question (since there are two - what priority and what)

[16:41]

what should we do with regard to this.

[16:42]

pardon my ignorance, but I tried to write up something on the meeting discussion only to realize that I really don't understand it well enough to even summarize the opinions of others

[16:42]

I'm not really even sure what Gao is suggesting.

[16:43]

I guess there's a spectrum of options from keep building cooler and forget migration all the way to

[16:43]

rewrite OSDmain to a new "toolkit" now

[16:43]

what do we even call this "toolkit" thing, I guess we're talking about a whole bunch of stuff.

[16:44]

a "window manager" which I guess is another name for a "focus" manager?

[16:44]

JoeyBorn: wait, there's definitly some confusion here

[16:44]

* JoeyBorn is confused by his own shadow

[16:47]

JoeyBorn: when i use the word "toolkit" i basically mean GUI toolkit. that is, that library that is responsible for managing on screen all the _contents_ of a window (buttons, progress bars, text boxes, lables, etc). The there's the window manager, which instead handles the windows themselves - these rectangular "frames", or "canvas" inside the confines of which the toolkit manages its stuff. the window manager manages the position of the w

[16:48]

yeah, I know that.

[16:51]

<[g2]>

hey JoeyBorn. vmarks around ?

[16:51]

well, just making sure. as for focus, the WM handles focus among the windows (i.e. which single window is the focused one which will get input routed to it). then inside the window the toolkit does its focus management among the various widgets it is managing inside that window

[16:51]

dunno, haven't heard from him lately

[16:51]

JoeyBorn: so, hope this cleared up some confusion on terminology

[16:52]

[g2]: me neither, since start of last week

[16:52]

i think

[16:52]

well, I knew that part, just not entirely clear on the exact relations of all those parts

[16:52]

for example, I would assume that either QT or E17 would do both?

[16:53]

and presumably nano-X too?

[16:55]

JoeyBorn: yes, although e17 WM is mainly designed to work with full mouse+keyboard i think. QT has a WM that might be good for mouseless operation, but crweb knows that better. as for nano-x, there's a rudimentary WM that Gao is beefing up and customizing for our usage, last I heard.

[16:56]

;hello.

[16:56]

[g2]

[16:56]

hold on, I'm reviewing the logs again

[16:56]

JoeyBorn: sure

[16:56]

<[g2]>

vmarks :) hi!

[16:57]

<[g2]>

vmarks I was at the Apple store today and couldn't resist the DVI- HDMI cable for $19. It actually works and drives HD on the TV

[16:57]

it will, provided there's no HDCP in the chain.

[16:57]

and 19 isn't that bad a price.

[16:58]

<[g2]>

vmarks a fine impulse buy :)

[16:58]

<[g2]>

vmarks is the HDCP negotiated via the I2C ?

[17:07]

okay, I think I get the general idea from the log

[17:07]

JoeyBorn: ok

[17:07]

the fundamental discussion is just that gao doesn't believe the community can really get QT working, in a candid nutshell

[17:08]

i think he doesn't believe QT can do the same as what cooler does now, from what i understand

[17:08]

I can't honestly speak to that, I'm not sure how close we are.

[17:09]

I personally feel that we're starting to re-invent the wheel here, we're already running into performance issues and I'm sure we'll waste a host of effort hacking together somethign with nano-x and cooler

[17:10]

Gao's gut is that Qt won't happen or won't do what we want.

[17:10]

my gut at this point is that we're probably re-inventing the wheel to hack a WM together ourselves.

[17:10]

I assume that would be due to its relative size?

[17:11]

"that?"

[17:11]

Gao's gut feeling that it won't work for us

[17:11]

it = qt

[17:11]

chreekat: no, the crucial point is that if we go QT, we need to rewrite all osdmain GUI part with QT

[17:11]

ah

[17:12]

and Gao seems to think QT can't produce a GUI that looks like the current osdmain GUI looks like

[17:12]

i think he basically said "show me a QT gui that mimics what we have now"

[17:12]

again, i'm interpreting

[17:12]

all I know is that kde is qt, so I can't imagine qt having feature limitation problems

[17:13]

I don't even like what the current gui is like. Whatever happened to the enlightenment fellow that had a picture showing one possible concept?

[17:13]

vmarks: he don't have time to work on that, it seems. that concept can be resurrected, though. but i don't think it's the focus now

[17:14]

unless we want to put on the table a complete redesign of osdmain, which i have the gut feeling can't be afforeded at the mement.

[17:15]

JoeyBorn: anyway. yes, we are re-inventing the wheel and we started reinventing it with cooler

[17:17]

well, I'm with you all, I'd be absolutely flabbergasted if QT can't do everything we do now and plenty more.

[17:18]

it's a professional, established toolkit for pete's sake!

[17:18]

JoeyBorn: however, at the moment starting to use a more standard wheel, so to speak, will mean rewriting the GUI part of osdmain to use that wheel (the QT or E17 or whatever wheel)

[17:18]

which is the crucial point

[17:19]

we either bite the bullet and do that, or we stick with our own wheel and pretend the rest of the world doesn't exist (and ask all others to use our wheel if they want to work on the OSD)

[17:19]

well, I guess that's a question of path and how we do that

[17:20]

I was favoring some kind of refactoring approach, but that got pooped on fairly hard.

[17:20]

so, I'm looking for a alternate suggestion on the path to a new toolkit.

[17:21]

i don't think that can be done incrementally, unfortunately

[17:23]

i mean, we can refactor osdmain so that its functionality is as detached from the GUI as possible. but at some point i suppose we need to stop, take away the old GUI and put in place the new GUI

[17:23]

wow, "qtopia core" provides its own windowing system.. x11 not required

[17:24]

chreekat: if you want to have only QT-apps, yes

[17:24]

yeah there is that small detail. ;)

[17:27]

no, i'm serious. we can say "if you want to work on the osd, you need to use QT" and that would already be a lot better than "you need to use cooler". of course having X would be even better, but 1) we're still evaluating how viable X11 is and 2) that would still require various toolkit libs to be on the OSD, which doesnt' have much space or memory -- so bottomline is that maybe the many-toolkits scenario isn't even that realistic. but the

[17:28]

er , replace "isn't even that realistic" with "might not be very practical, but i'm not sure yet"

[17:28]

;)

[17:29]

I don't know if it's the server or my client, but I didn't see anything past "even that realistic. but the"...

[17:30]

I think our man nerochiaro has an itchy enter finger :)

[17:30]

i hate writing short bursts, it's too easy to mix sentences with other people's and i hate that :)

[17:31]

chreekat: i'll PM the last part to you

[17:31]

but yes, I was thinking the same thing

[17:31]

nerochiaro: sure

[17:31]

I'm still figuring out irssi. If it really was my client, I need to figure out how to change that setting.

[17:32]

so, nerochiaro how big an effort is this QT thing in your opinion, switching OSDmain that is?

[17:33]

and then there's the second question which is is there a point in this interim solution, which my inclination is not

[17:33]

there seems little point in a WM if no one's willing to write 3rd party apps, it seems :)

[17:33]

i agree with the last statement

[17:34]

have we confirmed that QT's licensing is fine with us? I believe they have some kind of dual licensing thing

[17:34]

you can use their stuff for free if all your apps are GPL, but you have to pay if not?

[17:34]

anyone know?

[17:34]

we can fool ourselves saying that if we make cooler better people will write for it, but i think that's wishful thinking. last thing people need is to learn yet another toolkit

[17:35]

especially one that's not complete and needs a lot of love

[17:36]

JoeyBorn: I'm pretty sure it would be fine. IANAL of course

[17:36]

QT is licensed as GPL. if your app is GPL you can use it and be happy

[17:36]

well, chreekat has a vague notion its ok, and so do I, I think it's settled :)

[17:37]

if your app is non-GPL, you need to get a different license from trolltech, and you pay that

[17:37]

ok.

[17:37]

so osdmain has to be gpl, basically

[17:37]

it is already

[17:37]

anyone have an idea, how big a project this is?

[17:37]

nerochiaro: I figured it was

[17:38]

JoeyBorn: i say quite large, and have not done any in-depth analysis yet

[17:38]

JoeyBorn: crweb seemed to be more optimistic last time i spoke with him

[17:38]

about this

[17:39]

well, what do we do?

[17:39]

also there's another very important point i'm really really afraid to raise

[17:39]

clearly we have pressures on increasing the user functionality, we have to implement a front end for XMMS2, etc

[17:39]

we've got to do stuff with the EPG, youtube, etc

[17:39]

which is: let's say we decide to go with another toolkit: which toolkit ? **flame war ensues**

[17:41]

JoeyBorn: that is also related to the Xiamen team. what do they know, what do they need to learn ? i am fast at learning, but i don't know the other folk in the team

[17:41]

my first choice would be that you and crweb get together and make a reccomendation if that's possible

[17:42]

well, eric comes from a windows prgramming background actually

[17:43]

most of the other folks come from embedded, so it's mostly low level stuff

[17:43]

i'm pretty sure crweb would reccomend QT, and as much as it pains me to admit, that's more "mature" than e17 at the moment. personally i really love e17, but can't deny QT has a much larger user base, unless i'm completely mistaken

[17:45]

I personally don't believe that the installed base is that much of an issue, simply because I believe we can get a higher fraction of the E17 folks interested than the QT folks, sort of a bigger fish in a smaller pond, although I guess E17 does have the particuliarly disadvantage of the PS3 thing

[17:45]

since it really divides the "set-top box" hackers so to speak.

[17:45]

JoeyBorn: why do you say so about the PS3 ?

[17:45]

well, maybe Qt is the way to go. Clearly there's no right answer

[17:46]

well, my idea was that rasterman would help us raise the profile of Neuros within the enlightenment community

[17:46]

and we could even recruit rasterman with the right deal, etc

[17:46]

that would mean that we could be a lot higher profile users of enlightenment than QT

[17:47]

ie X% of enlightenment hackers know neuros and only y% of QT hackers know Neuros

[17:47]

however, every hacker has some "user" profile so to speak

[17:47]

they like the PC, or portables, or set-top boxes.

[17:48]

they like video or audio (or games)

[17:48]

it just seems to me that we'd be competing directly with Sony for enlightement hackers.

[17:49]

my guess is that it will be easier to find developers that know QT and are interested in a non-PC device than the same for e17. QT is already used in embedded extensively, i think. e17 basically nevery

[17:50]

as for competing with the PS3, i'm not sure. i follow the e17 ML and chats (sometimes) and i don't see a barrage of PS3 related talk

[17:52]

well, I agree based on the previous conversations, it seems like crweb is a QT guy, it's really up to you to push for E17 if you think its right.

[17:52]

all that said, there's still a nagging voice in the back of my head that shouts e17 in a high pitched voice, but i'm not sure if it's really good for us

[17:52]

If I can chime in here -- I think our first target should be ported applications, not ones built specifically for the OSD.

[17:53]

ducktayp, well that's an interesting point.

[17:53]

<[g2]>

openmoko is almost shipping and I think that's QT on X11 with a 640x480 resolution

[17:53]

There are FAR more QT apps than e17 apps

[17:53]

so we'd get a much larger pool of potential applications

[17:53]

ducktayp: indeed

[17:53]

Personally, I'd like to know what those applications are

[17:53]

and how they'd work.

[17:53]

ducktayp: however, they might not be that easy to port to the osd

[17:53]

ducktayp: given limited input, screen constraints etc

[17:54]

it would be great to have a device that we can simply say "hey that's a great non mouse interface, we'd like it to work like that" and there certainly are some out there

[17:54]

my blackberry and the Q are two examples of non mouse GUIs

[17:54]

nerochiaro: well, that's true. But there are also lots of embedded QT apps, which should be easier to port

[17:54]

and TONS AND TONS AND TONS of thought and effort has gone into them.

[17:54]

This is also why I think getting X11 to run should be a high priority

[17:54]

to not build on that, is substantially idiotic

[17:55]

ducktayp: the problem with X11 that is see is that we might end up not having the space (mem+disk) to run more than 1 toolkit at a time anyway

[17:55]

and what about mythTV? what's that built on

[17:55]

?

[17:55]

nerochiaro: yes, I can see that might be a problem

[17:56]

nerochiaro: at least for me -- I don't mind running applications from an NFS share (or maybe a CF card)

[17:56]

ducktayp: in general however i would still want an X11 so we can run also a good mouseless WM like matchbox

[17:57]

ducktayp: so we leave the door open to people like you who don't have space constraints (however RAM will always be a constraint)

[17:57]

nerochiaro: I was thinking of trying to get SDL to run (it seems like it should be easy once we have X11)

[17:57]

nerochiaro: then lots of other stuff becomes very easy to port

[17:58]

ducktayp: it does run, i've just done it the other day. it runs with nanox backend (and once we fix the fb driver will also work with fb backend)

[17:58]

ducktayp: i mean SDL

[17:58]

ducktayp: what does become easy to port ?

[17:58]

nerochiaro: Wow! That's great! where can I get the code?

[17:59]

nerochiaro: I was thinking of pygame

[17:59]

nerochiaro: Since python can already run (more or less)

[17:59]

ducktayp: didn't release anything yet, will do. i say python is not realistic instead

[17:59]

what's the point of matchbox? what does it do that QT doesn't?

[17:59]

especially for games

[17:59]

nerochiaro: I wanted to try running pyddr (although that also requires USB input support to work)

[18:00]

nerochiaro, one thing I will say about E17, is that I do think it's a better cultural/company etc fit

[18:00]

JoeyBorn: it's designed to work mouseless and is tailored for embedded devices in mind (so it throws away common desktop metaphors and does things in a way that makes more sense for embedded). i don't know abou the WM built in into QT

[18:01]

because of rasterman and the fact that it's not commercial

[18:01]

nerochiaro: is python too RAM hungry?

[18:01]

hi Xorlev

[18:01]

I managed to get a precompiled version running (got a text prompt); but I didn't really try anything with it

[18:01]

'ello Joe

[18:04]

JoeyBorn: i can relate to that feeling, i really do. however it's a bit of a gamble. you're taking a relatively smaller hacker base and hope that you can get many out of it that are interested. the problem with that is that 1) it's hard and 2) even if you succeed, it's still a smal-ish niche

[18:05]

(i don't have actual figures, if anyone even gathered them at all, of course)

[18:06]

but how big is the learning curve between something like QT and E17 really/

[18:06]

the difference in learning one against the other ?

[18:06]

I mean at the end of the day, they are going to have to be OSD hackers, they are going to have the device in their house and want to do things with it

[18:06]

indeed

[18:06]

yes, if you know Qt, how hard to learn E17?

[18:07]

or the other way around. i don't think any decent dev's head would explode at the transition.

[18:07]

but what about all the existing qt apps?

[18:08]

chreekat: that was the point of many, indeed

[18:08]

not that the simple fact that there *are* many of them is enough a reason, in itself.

[18:08]

chreekat: however, everyone has consistently failed to nominate lots of QT apps that can _reasonably_ be ported over to OSD

[18:09]

chreekat: we say "there are many"... but which ones specifically no one seems to know

[18:09]

yes

[18:10]

JoeyBorn: why did you ask that "devs switching from QT to e17" ?

[18:10]

hence my followup to my own 'there are many' comment. :-P I was thinking to myself, "Not that I would be wanting to run KMyMoney on the osd"

[18:10]

JoeyBorn: er, that last question, i mean

[18:11]

chreekat: no, wait. KDE != QT

[18:12]

well, my point was that, I believe that more developers are going t