[08:58:07] <hunger> IRC MEETING LOG STARTS HERE. Just so I can grep for this one;-)
[08:58:56] * stefan wanders in
[08:59:09] <hunger> Hi stefan.
[08:59:17] <stefan> hey hunger
[08:59:22] <dsevill4> hi, stefan
[08:59:24] <dsevill4> how are you?
[08:59:36] <stefan> dsevill4: hey. Thanks. Good to see you here !
[08:59:59] <dsevill4> I'm happy to see you too :)
[09:01:47] * hunger shivers.
[09:02:08] BenB has joined #fresco
[09:02:20] <BenB> hey :-)
[09:02:20] <oxygene> hi BenB
[09:02:25] <hunger> My xterm has 5000 lines scrollback buffer... and that's not enough to hold all the errormessages I get from gcc trying to build my string class:-(
[09:02:26] <stefan> velco: heh, you are here, too ?!?
[09:02:38] <velco> stefan: yeah, kinda :)
[09:02:53] <stefan> velco: awesome ! (kinda ;-)
[09:03:01] <velco> heh
[09:03:04] <oxygene> hunger: make 2>&1 | less
[09:03:04] <dsevill4> hunger: haha. Don't worry. Normally you fix one line and 90% or the errors dissapear
[09:03:28] <hunger> oxygene: I know. It's just so depressing having to do that;-)
[09:03:49] <stefan> hunger: I reworked the bug and task cgi forms somewhat. Could you have a look ? They should now fit nicely into a page...
[09:05:30] <hunger> stefan: Looks very nice.
[09:05:53] neiljp has joined #fresco
[09:05:59] <stefan> hunger: I did everything to make the forms less wide...
[09:06:08] <stefan> hey neiljp
[09:06:19] <BenB> hunger: thanks for the reminder on the ML, BTW, I would have forgotten it otherwise.
[09:06:23] <hunger> stefan: I think we can close bug21 then.
[09:06:26] <neiljp> stefan: Hey :)
[09:06:30] <neiljp> ...and everyone else :)
[09:06:43] <stefan> neiljp: did you get in contact with wiggy ? What's your 'status
[09:06:45] <stefan> now ?
[09:06:50] <hunger> BenB: You are welcome.
[09:06:52] <neiljp> ooh, 28 people :)
[09:07:09] <dsevill4> hi, neiljp
[09:07:14] <stefan> neiljp: yeah, and nicholas and alexander are still missing :)
[09:07:29] <neiljp> dsevill4: oh, hi...long time no see :)
[09:07:36] <neiljp> stefan: boh!
[09:07:44] <dsevill4> neiljp: I know... sorry.
[09:07:56] <neiljp> dsevill4: no problem...good to see you :)
[09:08:15] <njs> stefan: so should we wait another 5 minutes?
[09:08:17] <hunger> Anybody but me logging?
[09:08:32] * neiljp examines xchat for logging options
[09:08:41] <stefan> njs: may be.
[09:08:56] <stefan> does anybody here have experience with donations ?
[09:09:00] <BenB> hunger: yes, me, always.
[09:09:00] <velco> neiljp: Sewtting ->IRC->Logging
[09:09:10] <BenB> stefan: define "experience"
[09:09:13] <hunger> neiljp: Settings->IRC->Logging
[09:09:35] <stefan> BenB: well, ever received some; knows how to deal with them legally, etc.
[09:09:47] <hunger> neiljp: You can just turn it on and it will spam your HD with all the conversation you ever happened to listen in on:-)
[09:09:50] <BenB> stefan: I got soem money for Mozilla work.
[09:10:01] <neiljp> yes, I appear to be logging :)
[09:10:01] <BenB> stefan: that was dedicated to a certain task, though.
[09:10:20] <stefan> BenB: you as BenB or you as 'Beonex' (?) ?
[09:10:25] <hunger> stefan: Shouldn't we wait for nicholas and Alexander before getting down to busines?
[09:10:27] <neiljp> velco: yeah, just didn't know where the log files were :)
[09:10:31] <BenB> stefan: well, legally, that's the same
[09:10:38] <neiljp> hunger: I noticed ;)
[09:10:50] <stefan> hunger: well, we can warm up a bit, can't we ? We are not going to decide anything yet :-)
[09:10:55] <BenB> neiljp: ~/.xchat/xchatlogs/
[09:11:02] <stefan> BenB: is it ? That would surprize me.
[09:11:05] <neiljp> BenB: exactly :)
[09:11:17] <BenB> stefan: there is no company "Beonex".
[09:11:24] <BenB> stefan: I am a Freelancer
[09:11:28] <hunger> BenB: You don't need a company.
[09:11:33] <BenB> ("selbstständig")
[09:11:42] <hunger> BenB: You need a legal personality...
[09:12:06] <hunger> BenB: Something like a company, a "Verein" or so. Being Freelance is like having a company anyway.
[09:12:13] <BenB> hunger: I meant "company" = juristical (non-natural) person
[09:12:31] <BenB> hunger: not really, I am personally liable etc.
[09:12:32] <hunger> BenB: Do you have a 'Gewerbeschein'?
[09:12:35] <BenB> hunger: yes.
[09:12:36] * neiljp likes the thinner bug display
[09:12:42] <njs> stefan: depending on the amount of money involved, we could always just wing it. Have someone send the money to you, and trust that you'll use it responsibly, or whatever. It doesn't have the framework to make sure things are accountable and deal with taxes and all that, but for smaller sums that's probably okay.
[09:12:54] steveh has joined #fresco
[09:13:10] <hunger> BenB: Then you do have a company. That yoiu didn't pick a "Rechtsform" that does not make you personally liable is your fault.
[09:13:18] <BenB> njs: agreed.
[09:13:23] <stefan> njs: yeah, I thought about that. But I wanted to get an idea about how much *would* be involved if ever we'd want to make it more formal.
[09:13:28] <njs> (as compared to a company, where there's all this framework with a board of directors, etc.)
[09:13:28] <stefan> hey steveh
[09:13:38] <steveh> Hi
[09:14:13] <BenB> stefan: you have to create a legal entity, like a Verein.
[09:14:18] <neiljp> well, abi[source,word] handle it ok with...how much?
[09:14:20] <stefan> njs: and yes, there isn't much money involved, as far as I'm aware of. Someone just asked me some weeks ago where to put the 50$ he wanted to donate...
[09:14:32] <BenB> stefan: a Verein is advanturous, because it doesn't need base capital.
[09:14:41] <hunger> stefan: The easiest thing would be to fund a "Verein" in Germany. Only requirement: 3 people and some paperwork. I don't know how the 'international cooperation' works for a Verein though.
[09:14:53] <stefan> BenB: you are thinking too much in German jurisdiction :-)
[09:15:12] <BenB> stefan: other forms, like GmbH etc. usually need a substantional amount of base capital (10000-100000DM), which you have to invest into the company.
[09:15:25] <oxygene> stefan: don't think any other country (except .at and .ch) have "verein" as legal entity
[09:15:36] <BenB> stefan: I am talking solely about German jurisdiction. can't talk abouto USA or canada.
[09:15:39] <hunger> stefan: We'd need to settle for some juristdication...
[09:16:03] <stefan> hunger: well, yeah, that's part of the question.
[09:16:13] bughunter_away changes name to bughunter
[09:16:21] <hunger> stefan: I'd prefer that not to be the one in the US;-)
[09:16:29] <BenB> hunger: I think you need more people for a Verein.
[09:16:29] <oxygene> stefan: the good thing is, that ben, tobias and I are about 100-200km away from each other, and only 3 people are needed...
[09:16:31] <stefan> hunger: why ?
[09:16:46] <oxygene> BenB: no, tobias explained that already - it's a relict of the "skatvereine" ;)
[09:16:56] <hunger> stefan: I don't have much faith in anything US-based nowadays.
[09:17:13] <njs> stefan: well, dunno. it depends, I think, on what we want to do with it -- if we're hiring someone to do work, then we'd probably have to deal with taxes. If we're just using it for one off things (maybe paying for someone to go to a conference, or renewing DNS), then organization isn't a hassle and probably the first real limit is when you start dealing with quantities large enough that its effect on your personal taxes are a serious worry.
[09:17:24] <BenB> well, for 50$, it's totally pointless to found a verein. the paperwork alone costs considerably more.
[09:17:25] <hunger> stefan: Definitly not enough to have money there;-)
[09:17:27] <stefan> hunger: well, it was just a question. The US are as good as any other place.
[09:17:31] rajan has joined #fresco
[09:17:40] <rajan> did i missed the meeting? did i?
[09:17:43] <njs> The US is a pretty bad place, really, considering that I'm the only one here :-)
[09:17:48] <oxygene> rajan: you're just right :)
[09:17:51] <oxygene> hi rajan
[09:17:57] <rajan> hi oxygene
[09:18:02] <hunger> rajan: No, we just started to talk about what would be needed to accept donations.
[09:18:06] starseeker has joined #fresco
[09:18:06] * neiljp should talk to his Dad...an accountant...
[09:18:07] <njs> rajan: yeah, it turned out we only had 14 minutes worth of stuff to talk about after all :-P
[09:18:14] <rajan> njs: well, in that case, the same for me.
[09:18:35] <stefan> njs: oh, good point ! As far as those 50$ are concerned, we may just throw it mourad's way, as he had the most important expenses last year when we tried to get rid of verisign.
[09:18:41] <rajan> hunger: IIRC, you would need to open up a non-profit organization, and to do that, you need a lawyer. and those are expensive creatures
[09:19:10] <njs> actually setting up a corporation is a serious hassle and not cheap at all, and makes no sense until you're talking serious money.
[09:19:24] <stefan> well, I'm part of a choir that is a
[09:19:30] <stefan> non-profit organization
[09:19:42] <stefan> it's not *that* hard at least to apply for it.
[09:19:47] <njs> (for free software values of serious, of course, but still :-))
[09:19:55] <starseeker> you can code and sing???
[09:20:00] <rajan> njs: well, from what I see from osnews.com is that there is a lot of people interested in supporting Fresco, but can't
[09:20:11] soyt has joined #fresco
[09:20:15] <hunger> Can't we ask SPI to handle things for us?
[09:20:33] <njs> if SPI ever gets their act together again, we could refer people to them, considering that their whole purpose is to be a legal umbrella for projects like ours
[09:20:36] <stefan> hunger: do we want that ? I don't know what that actually means...
[09:20:38] <neiljp> rajan: what do you mean? 'lots' want to donate?
[09:20:45] <rajan> hunger: you can, but remember, we are giving SPI enough hassles already, and now from what I hear from rumours, they are having internal problems
[09:20:46] <njs> but they're in a bit of shambles right now, I'd wait to see what happens
[09:21:34] <rajan> neiljp: I don't know. but it is easy to find out. fresco has a huge PR following at OSNews, and I can easily convince Eugenia to have a poll asking for input on that regard
[09:21:41] <BenB> njs: "shambles"?
[09:21:51] <rajan> neiljp: but my point, it is possible.
[09:22:02] <njs> BenB: total disarray, non-functioning board, etc.
[09:22:08] <neiljp> rajan: I must search osnews :)
[09:22:19] <neiljp> rajan: I remember there was an article there, but not sure whether I read the comments :)
[09:22:22] <BenB> njs: nod :-(
[09:22:47] <rajan> neiljp: mostly negative. all about the slow moment of fresco. but it was a piece of cake explaining it to them
[09:22:47] <stefan> njs: did you get up early, or stand up late ?
[09:22:52] <neiljp> well as long as purcel still runs...thats ok :)
[09:23:01] <njs> BenB: enough of their board members are unable to spend any time on SPI stuff that they haven't managed to achieve quorum for months, there are proposals to lower the quorum requirements to start fixing this but it's pretty controversial, etc.
[09:23:02] <rajan> well, i would suggest slashdot if it wasn't so negative towards fresco
[09:23:07] <njs> stefan: stay up late :-)
[09:23:23] <hunger> So far we have the option to fund a non-profit organisation in canada, a Verein in germany or ask SPI.
[09:23:27] <hunger> Anything else?
[09:23:28] <stefan> njs: how big is their quorum ?
[09:23:31] <rajan> njs: movement, not moment :-)
[09:23:50] <stefan> hunger: yes, not do anything at all, just send the money (if there is any) to individuals.
[09:23:53] <njs> stefan: 2/3 of board
[09:23:54] <neiljp> well...there may be something that could be done in the UK...but... ;)
[09:24:08] <stefan> njs: ...and how big is the board ?
[09:24:10] <njs> rajan: parse error
[09:24:13] <hunger> stefan: I don't particularly like that...
[09:24:14] <neiljp> uh, someone change the topic? :)
[09:24:19] <njs> stefan: umm, 8
[09:24:19] <BenB> hunger: or do nothing
[09:24:24] njs changed the topic to The Fresco Windowing System -- IRC meeting NOW!
[09:24:30] * neiljp grins
[09:24:30] <rajan> hunger: setting up a non-profit org in malaysia is easy too, and i probably could get my aunt's (accountant at central bank) and uncle (famous lawyer, mostly civil) to help
[09:25:03] <njs> rajan: I think we can wait on that poll until we actually come up with something to do with the money :-)
[09:25:08] * stefan thinks if ever fresco becomes a legal entity it should be near a place with a high concentration of developers
[09:25:34] <hunger> So far we have the option to fund a non-profit organisation in canada or malaysia, a Verein in germany, ask SPI, or ask people to send money to developers directly.
[09:25:36] <njs> stefan: yeah, Canada or Germany for sure (unless the developer mix changes radically between now and then, I suppose :-))
[09:25:38] <neiljp> stefan: so that's Canada or Germany then? ;)
[09:25:47] <stefan> ok, if I propose to that nice guy to send a check to mourad for his expenses with verisign, would there be any objections ?
[09:25:59] <hunger> stefan: No.
[09:26:00] <njs> no
[09:26:05] <rajan> njs: well, there is a number of users. like giving it all to rajan. and of course giving it all to rajan. did i mention giving it all to rajan? serious, SPI is in bad shape now, we should brace for any event. money serves that purpose
[09:26:42] <neiljp> what are the details of the verisign thing? absence of being emailed about that ;)
[09:26:45] <hunger> stefan: I'd object if you'd ask for a nice 3D card to send to someone:-)
[09:26:47] <BenB> stefan: no, good idea
[09:26:47] <njs> rajan: mm, I don't think they're in that bad shape, having read up on it a bit. Serious organizational issues, yes, but they're not going to simply disappear.
[09:26:49] * stefan takes a note to get in touch with mourad...
[09:27:02] <rajan> well, between Canada and Germany, I would say Germany because it is more friendly to poor non-profit orgs....
[09:27:39] <rajan> njs: well, we would never know. what happens if the board all starts disagreeing and leave?
[09:27:43] <BenB> hunger: why? I'd find that great. even if the person in question is not me *g*
[09:27:50] <BenB> hunger: great motivation ;-)
[09:27:51] <stefan> hunger: well, hardware such as 3D cards is a gadget, as far as fresco is concerned. We are not going to develop drivers...
[09:28:09] <hunger> rajan: Not really:-) But we have the concept of a "Verein" which is basically a legal entity trying to further some goal (like sports, music, etc.).
[09:28:11] <rajan> stefan: none
[09:28:13] <stefan> hunger: input devices is already different, because it allows us to actually experiment
[09:28:18] <stefan> hunger: (or PDAs for that matter)
[09:28:26] <neiljp> hunger: uh, charity?
[09:28:27] <rajan> hunger: ahh, okay
[09:28:41] <njs> rajan: SPI's too important for that; they pay for lots of _debian_'s hosting. No-one's going to let that happen.
[09:28:47] <oxygene> neiljp: hard to explain, it goes in that direction I think
[09:28:57] <hunger> rajan: The cool thing is that if you get registered to be "Gemeinnützig" (good for the public), you get fines set by courts send your way;-)
[09:29:16] <neiljp> stefan: like that strange device like a pen like an anglepoise lamp [/cryptic] :)
[09:29:29] <BenB> neiljp: it's basically a bunch of people meeting, formally.
[09:29:34] <BenB> neiljp: with a goal.
[09:29:36] * bughunter wonders, what are the _technical_ topics...
[09:29:46] <njs> stefan: well, if we end up with money, I could imagine sending a 3d card to one of the kgi developers being a good investment :-)
[09:29:48] * neiljp grins
[09:30:01] * neiljp thinks bughunter wakes up round about now
[09:30:02] <stefan> bughunter: just defining the goals for the upcoming milestone(s)
[09:30:04] * philbo agrees with njs :-)
[09:30:08] * neiljp lol
[09:30:13] <njs> philbo: thought you might :-)
[09:30:14] <stefan> bughunter: unfortunately, the main contributor is still absent :-/
[09:30:33] <stefan> njs: yes, definitely
[09:31:09] <njs> Should we stick a tip jar on the web site, though, do you think?
[09:31:31] <neiljp> njs: not paypal...from what I've heard... ;|
[09:31:35] <hunger> njs: sending the tip where?
[09:31:38] <njs> neiljp: yeah :-(
[09:31:39] <stefan> njs: in fact - but that is a different topic - it would be interesting to meet with these people (kgi, ggi, etc.) to see how we can support each other better, i.e. collaborate to enhance visibility.
[09:31:46] <neiljp> njs: abiword probs...
[09:31:48] <rajan> hunger: lol, really?
[09:31:51] <njs> neiljp: well, paypal's okay as long as you don't actually let them keep any of your money for you
[09:31:53] <BenB> neiljp, njs: know any alternatives to paypal, by chance, btw?
[09:32:00] <neiljp> stefan: include omniorb in that?
[09:32:04] <hunger> rajan: Really what?
[09:32:13] <njs> BenB: there's one...
[09:32:14] <neiljp> BenB: uh, well, not OTTOMH :)
[09:32:24] <starseeker> Is there somewhere with a good explanation of KGI vs GGI?
[09:32:31] <stefan> neiljp: yes, possibly. I suggested to Duncan already that I'd like to help implement the messaging QoS specs...we could make good use of that.
[09:32:35] <neiljp> njs: nod
[09:32:42] <rajan> BenB: well, i heard of a company named PayPal. pretty similar to PayPal. address at paypal.com
[09:33:01] <njs> BenB: http://www.paypalwarning.com/Alternatives/Default.htm
[09:33:10] <rajan> starseeker: KGI: made for the Linux kernel. GGI: not made for the Linux kernel specifically
[09:33:29] <neiljp> stefan: I brought up the somewhat interesting ( ahem) idea, depending how much money we got...if we *needed* an omni feature, we could get omni to make it...but that's purely my imaginings :)
[09:33:36] <philbo> starseeker: KGI kernel level interface, GGI user level interface supporting KGI and many others
[09:34:12] <njs> starseeker: GGI is the _general_ graphics interface -- it's a generic 2d imaging API, that you can write your programs to use, and they'll display on most anything.
[09:34:17] * stefan waits impatiently for nicholas to join in
[09:34:18] <neiljp> philbo: so KGI will support more than linux? :)
[09:34:25] <rajan> well, if paypal if out of the question, i would push billpoint because it is the only altenative that have support for malaysian donors
[09:34:33] <starseeker> So it works like KGI->GGI->Fresco on Linux?
[09:34:40] <BenB> njs: hehe, thanks
[09:34:40] <njs> starseeker: KGI is a set of kernel drivers that GGI will hopefully be able to use at some point to get accelerated console display.
[09:34:42] <philbo> neiljp: there is FreeBSD and OpenBSD port being worked on actuvely
[09:34:51] <neiljp> philbo: cool :)
[09:34:59] <starseeker> Neat.
[09:35:00] <neiljp> philbo: the drivers are independent modules?
[09:35:00] <rajan> philbo: really? cool
[09:36:06] <starseeker> Now that people are getting close to having threads on Hurd, does anyone know what other barriors there would be to running there?
[09:36:28] <philbo> neiljp: yes, kgi is setup so that the drivers are perfectly portable. Right now there are bits here and there that are linux specific but that's mostly because it really runs on Linux only right now. Once other ports are functional I'm sure the maintainers will come after the people writing the dirvers and get them to fix it
[09:36:31] <hunger> starseeker: Markus brinkman said a port should be possible after looking into Prague.
[09:37:27] <starseeker> Cool. Now that would be a real next generation system :-)
[09:37:28] <BenB> rajan: ebay = paypal (now), ebay = billpoint
[09:37:30] <stefan> is any of you actively working on fresco right now ? If so, on what ? If not, what would you like to be worked on ? (short and medium term)
[09:37:49] <neiljp> stefan: stability :)
[09:37:59] <oxygene> starseeker: let them fix their microkernel first - but well, different topic
[09:38:01] <stefan> neiljp: yeah, those darn cleanup things
[09:38:01] <rajan> stefan: as i said on the mailing list, i'm working on a UI proposal...
[09:38:03] <neiljp> stefan: aka asynchronous client calls...[digs out bug number]
[09:38:16] <hunger> stefan: I'm still fixing Babylon and merging the bidir stuff I hacked into the commandkit into Babylon.
[09:38:27] <starseeker> oxygene: yes, they need L4.
[09:38:31] <stefan> neiljp: by the way, I experimented a bit last night, and can confirm the problem with uncought TRANSIENT exceptions. Dunno how that slipped in...
[09:38:44] <njs> I'd like to get that test framework up and running, and in the longer term work out the deCORBAfication of the scene graph
[09:38:50] <neiljp> stefan: from what/where?
[09:38:52] <stefan> neiljp: possibly because at the time I made the code exception safe omniORB only threw OBJECT_NOT_EXIST
[09:39:01] <neiljp> stefan: oh! *that*!
[09:39:22] <neiljp> stefan: we solve that how? do we want to support only omni4?
[09:39:38] <stefan> neiljp: well, one thing to do is go over *all* the code, and wherever we catch CORBA::OBJECT_NOT_EXIST, catch TRANSIENT, too.
[09:39:42] <stefan> neiljp: ...as a start
[09:39:45] <BenB> stefan: well, you know my state, I'd like to work on widgetkit, esp. trees/lists and related stuff, but that's mid-to-long-term, if anything
[09:39:54] <neiljp> ah, task77, I'd like that...after bug82/task57 ;)
[09:39:57] <stefan> neiljp: huh ? There's nothing omni4 specific
[09:39:59] <hunger> afterwards I'd like to fix bug9 (have a fix for that lying around somewhere, need to update it a bit).
[09:40:18] bigthor has joined #fresco
[09:40:20] <neiljp> stefan: true...I suppose...so catch for *both* in all places?
[09:40:25] <stefan> neiljp: yes
[09:40:37] <neiljp> stefan: fine
[09:40:59] <stefan> neiljp: in fact, we have to catch even more. As you may know from python scripting, we have to be prepared for things as bad as marshall errors
[09:41:04] <neiljp> stefan: do you have a bug/task for that? :)
[09:41:14] <njs> oh, and also on my list for after I get some breathing room: write the big rant the convinces everyone once and for all about what the Right Way to do server resolution is :-)
[09:41:28] <stefan> neiljp: that can happen when the server calls into the client with a method that returns non-void, and the return value is incorrect.
[09:41:29] <njs> s/rant the/rant that/
[09:41:54] <neiljp> stefan: I sense a function wrapper of some sort being useful :)
[09:42:12] <hunger> stefan: We usually do not catch everything H&V say can be thrown... We should make sure about that when going over those exceptions anyway.
[09:42:12] <stefan> njs: do you have any ideas as to your availability ? Specifically, for the qmtest stuff...
[09:42:20] * neiljp readies his lightsaber for battle with njs ;)
[09:42:24] <stefan> njs: I think that would really be a booster
[09:42:27] <njs> stefan: well, my last paper is due Wednesday.
[09:42:34] <stefan> njs: (think about how much we gain from the new website/infrastructure)
[09:42:43] <njs> stefan: so end of this week/this weekend, I'm hoping.
[09:43:21] <njs> stefan: getting it minimally functional really shouldn't be that hard, though I may want some handholding to figure out where stuff goes in the build system and how to make sure it works.
[09:43:36] <stefan> njs: cool. Just make a proposal as to how people (hunger and me, in particular) could hook up unit tests to such a framework.
[09:43:58] <stefan> njs: Prague already contains a couple of examples that could easily be converted to tests, and I think Babylon isn't that far off either.
[09:44:13] <starseeker> If I might insert one more dumb question... I was wondering how one does secure communication between Fresco clients?
[09:44:14] <hunger> stefan, njs: So does Babylon.
[09:44:26] <stefan> njs: then we can think about how to set that up on volunteer machines, so we can test on different platforms.
[09:44:38] * hunger thinks it would be nice to have a tested and known-stable base to build on;-)
[09:45:03] <hunger> starseeker: CORBA has a security service for that.
[09:45:23] <neiljp> so...talking of donations...security service impl? ;D
[09:45:23] <njs> starseeker: currently we have no systematic way for clients to communicate with each other; it's something we've hardly thought about, though we know we'll have to eventually.
[09:45:31] <stefan> starseeker: depends. You can do it low level, with CORBA-over-ssl, or you can add high-level mechanisms to add authentication etc. to the interfaces.
[09:45:47] <hunger> starseeker: Basically there's not much fresco can do itself: The communication is encapsulated in the ORB, so that's the instance that has to make sure encryption is used and objects are properly authenticated.
[09:46:02] <stefan> starseeker: also, there are CORBA 'interceptors' that can be used per request. Thought they are pretty expensive performance-wise
[09:46:07] <njs> stefan: nod
[09:46:26] <hunger> stefan: You cannot add authentication to the fresco interfaces in any meaningful way.
[09:46:41] <BenB> starseeker: first step would be to define what "secure" means for Fresco.
[09:46:46] <starseeker> hunger: Isn't that a problem?
[09:46:56] <hunger> starseeker: What?
[09:47:10] <BenB> starseeker: for example, does the server trust clients? how far? like Windows? like X11? like webbrowser? like emacs?
[09:47:13] <stefan> njs: I'd prefer a simple 'HOWTO' to be able to set up qmtest on any machine, and hook it up with fresco. All the other jazz for automatically generate tests (did you suggest synopsis ?) could follow once that is settled.
[09:47:20] <njs> stefan: qmtest should be able to handle that well. Also, Mark Mitchell is looking for success stories, and Zack (zwol) (who I know IRL, for those following along at home) is one of the developers, so I suspect we'll have good support on that end.
[09:47:24] <starseeker> hunger: Wouldn't you want to be able to authenticate interfaces?
[09:47:44] <hunger> starseeker: The CORBA security service can be set up to authenticate each object.
[09:47:49] <stefan> njs: yes, figured.
[09:47:56] rajan changes name to rajanBRB
[09:48:07] <stefan> njs: that's very good, and we should take advantage of that situation
[09:48:11] <starseeker> BenB: I was mainly thinking avoiding someone being able to spoof a client between your server and terminal, or read the Corba communications to get/subtly alter your information.
[09:48:17] <njs> stefan: well, the idea is to use synopsis to make writing tests _really easy_ for developers -- just a matter of creating a single standard C++ file, and letting the framework do all the annoying boilerplate.
[09:48:19] <hunger> starseeker: Since fresco has no control of what is actually send over the wire (not even when something is send over the wire) a encryption layer in fresco is not possible.
[09:48:46] <stefan> njs: do you think anything of that could be done for the next milestone ? Or is that something to be done in parallel, but without much visibility ?
[09:48:49] <BenB> starseeker: connection-level security should fix that, not?
[09:48:50] <njs> (hmm. If I disappear suddenly, it's probably just a brownout and I'll be back shortly. Unless the magic smoke gets out, anyway.)
[09:49:02] <starseeker> hunger: so it's up to the ORB then?
[09:49:41] <hunger> starseeker: That's the only option I see. At least there is a formal specification for that (although I'm not aware of any free implementation).
[09:49:49] * sdt sneaks in
[09:49:52] <starseeker> BenB: In theory yes, if it is used all the time. I was wondering if it would be used internally as well as over the net. If the calls are expensive there would be a temptation to not use them on a local system.
[09:49:53] <oxygene> hi sdt :)
[09:49:54] <njs> stefan: you mean the synopsis specific part? sure. To be minimally functional, all I need to write is a little python class that scans a synopsis AST to figure out the names of classes/methods, and then fills those into a template.
[09:50:16] <oxygene> hunger: omni knows ssl...
[09:50:18] <stefan> ok, let's try to fix 'M2' to be released end of February. What do we want to ship it with ? What bugs should be fixed by then ? What features added ?
[09:50:26] <njs> stefan: the C++ part of the framework is written, as is the qmtest "Test" module that lets qmtest talk to the tests I create.
[09:50:30] <hunger> oxygene: That's *NOT* a security service.
[09:50:38] <oxygene> hunger: well, for tapping the line it's enough
[09:50:43] <hunger> oxygene: That's just tunneling the normal connection over SSL.
[09:51:03] <starseeker> hunger: It might pay to bother the omni people about adding that someday - if Fresco every goes production its going to need good security.
[09:51:04] <hunger> oxygene: It does not do authentication on object level, etc.
[09:51:08] <stefan> njs: well, I'd actually propose to wait with that part. I for one would prefer to experiment with qmtest manually, before automatizing anything.
[09:51:27] <njs> stefan: well, if you like.
[09:51:34] <starseeker> s/every/ever
[09:51:54] <njs> stefan: the files I generate are really simple; they mostly just avoid the horrible macrology required by every other C++ unit testing framework.
[09:52:04] <neiljp> stefan: for me, I'd go with server stability :)
[09:52:14] <stefan> njs: I'm not trying to stop you to work on anything, by all means. But - as always - I'd like to make the underlying mechanisms transpareny before adding convenience layers.
[09:52:15] <hunger> njs: I'd like to be able to write some simple tests (mostly shellscripts diffing the output of a programm against a file) for Babylon asap.
[09:52:16] <njs> stefan: but we can talk about the technical details some other time; I'd be happy to tell you about it.
[09:52:30] * neiljp wonders what else to look at
[09:52:34] * sdt suggests fixing the current visual bugs
[09:52:39] <stefan> njs: sure
[09:52:41] <sdt> (I will be happy to help with this)
[09:52:48] <stefan> sdt: visual bugs ?
[09:52:58] <stefan> sdt: clipping etc. ?
[09:53:01] <neiljp> stefan: eg rotations being wrong...
[09:53:03] <sdt> well, all the problems with rotation, etc.
[09:53:08] <sdt> clipping might be a little more difficult
[09:53:09] <stefan> ah
[09:53:09] <neiljp> sdt : :)
[09:53:15] <njs> hmm, that'd be nice. Clipping is hard, though.
[09:53:20] <starseeker> Is anyone else able to crash Fresco fairly easily if they rotate a terminal in 3D enough?
[09:53:21] <sdt> although perhaps we could get clipping working at least on OpenGL...
[09:53:30] <hunger> sdt: I'd like to see some debugging/testing tools first. That would make debugging so much easier.
[09:53:40] <sdt> starseeker: I can crash fresco pretty easily by rotating most things enough...
[09:53:44] <philbo> I'm curious how far has text support progressed. Last time I tried writing a Fresco application it wasn't even possible to change the text of a text widget
[09:53:46] <stefan> yeah, and please don't forget that libart has only limitted support for clipping.
[09:53:50] <hunger> starseeker: Happens with the LibArtDK. Bug in libart:-(
[09:53:56] <neiljp> stefan: ooh, task68: update python module for new server-resolution :)
[09:53:57] <sdt> stefan: exactly.
[09:54:00] <starseeker> hunger: Ah.
[09:54:19] <starseeker> Has anyone else tried the Debian packages?
[09:54:31] <stefan> sdt: I wouldn't try to compensate for libarts limitations. It would be more interesting (if the time has come) to write a 'FitzDrawingKit
[09:54:31] <hunger> philbo: No progress at all in that area:-(
[09:54:36] <starseeker> For me the fonts are messed up.
[09:54:57] <sdt> hunger: well, at least for the rotation bugs, I'm fairly sure I have some idea of what's going on
[09:55:00] <hunger> starseeker: It uses the first font it finds... even if that's broken:-(
[09:55:12] <stefan> I for one would love to work on event and focus management stuff. (daVinci will help me there)
[09:55:18] <sdt> stefan: yes, yes, I fully agree. Which is why I said, we could at least fix the clipping for OpenGL
[09:55:24] <neiljp> hunger: well, excepting BERLIN_FONT_CHOOSER, but that's hacky...
[09:55:25] <stefan> but that's long term goal and I don't know how much I can line that up with M2
[09:55:31] <njs> it _might_ make sense to push clipping and such off to be done after the Great DeCORBAification of the scene graph, since that'll require some rewriting of the layout stuff anyway, and let us be much more flexible if we like (since we won't be stuck using exposed CORBA interfaces for everything). But putting things off forever isn't good...
[09:55:38] <starseeker> hunger: Oh, no wonder...
[09:55:50] <hunger> sdt: I had a graph-dumper a while back that turned the scenegraph into a dot-generated PS-file. That was a real help to see where things went astray.
[09:55:52] <stefan> at some point I'd love to fix the focus stuff at least enough so we can work on menus
[09:56:00] <njs> (and I'm not sure that we've fully committed to the great deCORBAification plan, though I know I'm convinced.)
[09:56:09] <stefan> njs: :-)
[09:56:14] * sdt agrees strongly with stefan
[09:56:19] <stefan> njs: indeed, we have to discuss about that.
[09:56:25] <sdt> anyone care to answer philbo's question about text?
[09:56:28] <hunger> sdt: I'd like to add that to the server, but without a meaningful description attached to each graphic it does not make sense to have it.
[09:56:36] <neiljp> njs knows how to be controversial :)
[09:56:38] <philbo> sdt: hunger did
[09:56:43] <sdt> oh, I missed it:)
[09:56:51] <stefan> sdt: I wonder whether we have a task for that focus stuff. We may discuss there...
[09:56:51] <sdt> oh, ok.
[09:56:59] * sdt looks
[09:57:07] <hunger> sdt: And stefan is dead set against adding 'debug methods' to the interfaces.
[09:57:21] <stefan> sdt: collect use cases etc....just to see what situations we need to support as far as focus arbitration goes.
[09:57:42] * sdt notes the CSS doesn't seem to be working on issues for him
[09:57:43] <stefan> sdt: it's a bit tricky, but I believe there is a clean and concise solution
[09:57:46] <njs> hunger: you should be pushing for the GdCification, then, since non-CORBA-exposed interfaces will give you more flexibility with things like that :-)
[09:57:47] rajanBRB changes name to rajan
[09:57:51] <rajan> what did I miss?
[09:58:05] rajan changes name to rajanr
[09:58:11] <njs> rajanr: just read your scrollback :-)
[09:58:18] <hunger> njs: It needs to be CORBA exposed! Or it will not work with remote objects which would be a shame.
[09:58:23] <njs> Should we pause for a moment to propose things we want to talk about today?
[09:58:37] <rajanr> njs: right... :-)
[09:58:40] <stefan> njs: good idea.
[09:59:09] <stefan> njs: should we work on a wiki page in parallel to generate a list of bugs/tasks ?
[09:59:22] <neiljp> stefan: for m2?
[09:59:25] <stefan> njs: (in parallel == write and save it while we are talking)
[09:59:43] <stefan> neiljp: yes, and possibly m3, if the stuff is too involved to fit into a timeframe for M2
[09:59:45] <sdt> is there a task for this deCORBIification?
[10:00:03] <njs> hunger: well, my counterargument is that 1) remote objects are never a good idea anyway, for all sorts of reasons (stability, speed, etc.), beyond simple prototyping, and 2) there are robustness issues that just _can't_ be solved while the scene graph is exposed via CORBA. But now you're distracting me from the agenda-making :-)
[10:00:17] <stefan> sdt: no. We only agreed that we need to reconsider the whole traversal stuff. It's highly non-efficient.
[10:00:20] <njs> stefan: might be tricky; the wiki doesn't deal well with multiple concurrent writers. Someone just take notes?
[10:00:26] <stefan> velco: remember, you were already looking into it years ago :-)
[10:00:34] <hunger> njs: Agreed. But certainly you want to be able to debug your prototype?
[10:00:41] <sdt> stefan: ah, good idea.
[10:00:41] <stefan> velco: (a global scene graph lock, etc.)
[10:01:20] <stefan> sdt: there is one thing we may have to do, but I'm a bit reluctant (for obvious reasons):
[10:01:26] <hunger> Too bad chalky is not here...
[10:01:41] <stefan> sdt: right now the traversal is a visitor, i.e. with a whole round-trip per visit.
[10:01:44] rubberpaw has joined #fresco
[10:01:53] * njs is dubious about the global scene graph lock too, but deCORBAifying at least fixes the more obvious problems, maybe someone cleverer than me can fix the other ones... I think we'll hit horrible contention, though.
[10:02:03] * hunger wants to talk about debugging/testing, text in the scenegraph and new traversal. Not necessarily in this order.
[10:02:10] <stefan> sdt: in fresco (orig) the traversal 'type' is an enum. That is less clean, but avoids two methods per node.
[10:02:31] <hunger> Shall we start with the scnegraph global locking/deCORBAification?
[10:02:34] * sdt nods
[10:02:36] <stefan> sdt: there's still a 'visit', but that's only used if the enum is 'other'. Read: 'draw' and 'pick' are 'fast paths'.
[10:03:05] <stefan> hunger: no, I don't think today is the right time to talk about that. We could brainstorm that, but an irc meeting doesn't seem a good place.
[10:03:59] * njs adds "write up big rant about why we want to deCORBAify" to his list of things to do this vacation
[10:04:01] * bughunter is curious, when bug183 and bug89 will get closed... :-)
[10:04:07] <stefan> hunger: ok, let's talk about debugging/testing and the requirements this puts on traversals. But let's be specific to that problem. We won't come up with a generic solution
[10:04:14] <hunger> stefan: There's talk about it for a while, haven't seen much on the ML about it and not a single page in the wiki.
[10:04:15] * neiljp looks at bughunter bugs...
[10:04:28] <hunger> stefan: We should come out in the open with it for a change;-)
[10:04:36] <njs> hunger: well, I'm the main one arguing for it, IIRC, and I haven't had a chance to write down the arguments.
[10:04:59] <hunger> njs: nicholas (where is he?) has some issues too.
[10:05:04] * njs hopes he hasn't _forgotten_ the arguments
[10:05:19] <BenB> njs: lol
[10:05:21] <hunger> OK, so it's debugging/testing then:-)
[10:05:37] <njs> hunger: nod. IIRC we had different approaches, though; he was more worried about speed (which I think is not a real worry), and I'm more worried about robustness.
[10:05:51] <hunger> Anyone knows what those named objects are I stumbled over recently? I think Chalky introduced those.
[10:06:05] <stefan> hunger: yes, they add some verbosity for logging
[10:06:13] <hunger> stefan: How so?
[10:06:19] rubberpaw has left #fresco
[10:06:23] <stefan> hunger: I don't like much how it is done, but I didn't come up with anything better
[10:06:44] <stefan> hunger: look into the Tracer stuff, that's where it is used
[10:06:56] <stefan> hunger: (and then look into Berlin/modules/Layout/Box.cc)
[10:07:16] <hunger> stefan: The Tracer is not very useful anyway...
[10:07:33] <stefan> hunger: you don't find it very useful. That's not the same.
[10:07:35] <hunger> stefan: Slows things down so much that all the problems I see don't happen with the tracer turned on:-(
[10:08:06] <stefan> hunger: ok, there is a bug/task for that. Let's keep the discussion there.
[10:08:30] <hunger> stefan: OK.
[10:08:33] <neiljp> so what *are* we discussing ? :)
[10:08:59] <njs> So, the things I've heard suggested for talking about today: (1) M2 goals, (2) M3 goals, (3) debugging/testing support, (4) text in the scene graph, (5) new traversal, (6) decorbaification/global locking, (7) testing
[10:09:03] <stefan> hunger, neiljp: what changes you think the traversal needs to add debugging features (generate a scene graph diagram, for example)
[10:09:09] <hunger> stefan: So how can we identify Graphics we hold a reference to?
[10:09:14] <rajanr> neiljp: on useless debates that never change anything...
[10:09:36] <neiljp> rajanr: ooh, harsh :)
[10:09:37] <hunger> stefan: Only one: Some way to get a description of the graphc traversed.
[10:09:53] <neiljp> stefan: mebbe you'd like to change the topic...
[10:10:03] <njs> Of these, (6) is probably better to hold off on, (7) likewise except as a part of (1)/(2). opinions on the rest?
[10:10:17] <oxygene> hunger: a type attribute?
[10:10:25] starseeker has quit ("Client Exiting")
[10:10:27] <oxygene> njs: for (4) it would probably be useful to have mourad around...
[10:10:35] <hunger> oxygene: More a label like "hbox", ...
[10:10:51] <hunger> oxygene: You can figure out the type (Controller or Graphci) allready.
[10:11:14] <njs> oxygene: nod. I'm not sure about the utility of full meetings for technical discussions; it seems like policy and making sure everyone is on the same page are the main things they're good for.
[10:11:19] <oxygene> hunger: that's what I meant
[10:11:42] <oxygene> njs: right...
[10:12:17] <njs> hunger: is this discussion something that you and stefan should rather discuss some other time?
[10:13:02] <oxygene> njs: for the technical discussion we sould probably establish some rfc-like protocol, to push them forward
[10:13:33] <hunger> stefan: Everything else can be done without a change to the traversal code, even though changing it to allow for 'generic traversal' like nicholas proposed is certainly the nicer solution.
[10:13:52] <njs> oxygene: well, not sure about that; highly formal processes can hurt more than they help. The Wiki and tracker seem to be working okay so far, when people find time to actually write their ideas down...
[10:14:25] crimsun has quit (""Woman who cooks carrots and pees in same pot is unsanitary."")
[10:14:25] <sdt> oxygene: I've seen that idea fail miserably before...
[10:15:03] <njs> Ok... I suggest that for the bulk of this meeting, we focus on the question of "What do we want to do with M2 (and maybe M3)?".
[10:15:35] * sdt nods
[10:15:42] <hunger> Can someone change the topic then?
[10:15:57] sdt changed the topic to The Fresco Windowing System -- IRC meeting: Goals for M2 (and perhaps M3)
[10:16:34] <njs> What should be the focus for M2? Lots of little fixes? should we throw in some small but noticeable feature additions? if so, which should we be targeting? And for post-M2, what are the longer-term projects and how do we want to fit them into milestones?
[10:16:47] <njs> (that's a lot of questions, and hopefully we can discuss all of them in turn?)
[10:16:53] <hunger> njs: I'd like to focus on stabelising things.
[10:17:10] <njs> hunger: what do you mean by that?
[10:17:15] * neiljp agrees with hunger
[10:17:28] <neiljp> njs: making server more stable/robust
[10:17:32] <hunger> njs: Add debugging, testing, fix bugs.
[10:17:34] <njs> hunger: fixing annoying crashes and silly bugs, getting better error output when possible, etc.?
[10:17:47] <neiljp> njs: eg. catching more exceptions in server (from clients and elsewhere)
[10:17:59] <hunger> njs: So that we have a more stable basis to build upon.
[10:17:59] * neiljp wonders if anyone is making a list
[10:18:03] <njs> hunger: and are you thinking of this as a goal for M2 in particular, or just your feeling for the sort of work we should be doing these days?
[10:18:03] * neiljp nods
[10:18:14] <njs> neiljp: trying, sorta :-)
[10:18:21] <neiljp> njs: good :)
[10:18:43] <hunger> njs: Whenever I touch something I find some annoying bugs in some other code that keep distracting me:-)
[10:18:56] <neiljp> njs: task77, task68 :)
[10:19:16] <hunger> njs: You cannot get that out of the way completly of course, but right now I'm flying on the assumption that something else is broken whenever my code does not work right away;-)
[10:19:39] <njs> hunger: nod
[10:19:48] <njs> hunger: so I think that makes testing a priority for M2 :-)
[10:19:48] <hunger> njs: I'd like to get that a bit reduced and have some better ways to debug things.
[10:19:59] <hunger> njs: To me it does, yes.
[10:20:17] <neiljp> njs: list of bugs/tasks to be added to m2/3, you are making?
[10:20:26] <njs> neiljp: okay
[10:20:40] <hunger> njs: My graph-dumper showed me at one glance where some coordinates went astray... That's nearly impossible to spot without that tool.
[10:20:57] <njs> hunger: nod, right
[10:21:17] <hunger> njs: We should introduce some better tools for debugging before extending the codebase IMHO.
[10:21:23] <njs> hunger: of course, I think better debugging/visualization tools will be something we're always working on. But if you have some particular ones for this milestone...
[10:21:43] * sdt wouldn't mind a scene graph dumper.
[10:21:44] <hunger> Sure.
[10:21:58] <neiljp> bug92 is something I'd like to get sorted: afaict its causing all kinds of problems with using clients...[Kit/POA garbage-collection]
[10:22:01] <njs> hunger: (is there a task for making your graph visualizer work?)
[10:22:09] <neiljp> (whether by me or other :)
[10:22:52] <hunger> njs: Dunno.
[10:23:04] <njs> hunger: well, if not, then file it so we can put it on the list :-P
[10:23:04] <stefan> sorry, got distracted (by work :-)
[10:23:14] <stefan> njs: I'
[10:23:18] * neiljp wonders if nicholas is going to turn up
[10:23:20] <rajanr> well, guys, love to start and die of boredom, but gotta go
[10:23:25] <njs> stefan: figured :-)
[10:23:30] <stefan> d like to work on an alternative WidgetKit (OpenLook). That's just for pleasure, though.
[10:23:31] <neiljp> rajanr: ;)
[10:23:32] <hunger> njs: I think not. For it to be useful I need some way to identify graphics (aka. add a attribute to the CORBA interface) which stefan is dead set against.
[10:23:43] <neiljp> stefan: got any clue on bug92? ;)
[10:23:56] <BenB> does anybody have a cellphone number for nicolas? I could call him...
[10:24:00] <njs> stefan: is that supposed to be an alternative, or a replacement? It seems a waste to maintain multiple widgetkits ATM
[10:24:22] <stefan> njs: as far as important fixes go, I'm totally with everybody else: stability. That's most importantly exception-safety, and cleanup stuff.
[10:24:40] * neiljp nods
[10:24:56] <stefan> njs: no, not a replacement. We should be able to (visually) demonstrate that we are 'themable', and how we achieve that.
[10:25:25] <BenB> stefan: and nice looks make people take notice :)
[10:25:28] <njs> stefan: hmm, okay. just don't let it get wet, or it'll bit-rot, though :-)
[10:25:51] <hunger> Oh, I'd like to get on the way with the codeing-standardisation;-)
[10:25:58] <stefan> hunger: what about a dictionary ? And as far as debugging goes, you could always use to find out about type names.
[10:26:00] <neiljp> hunger: oh yes!
[10:26:15] <hunger> stefan: Via CORBA?
[10:26:21] <stefan> hunger: no
[10:26:36] <hunger> stefan: Well, I only hold a CORBA reference to the objects.
[10:26:38] <njs> hunger: heh, that was the next thing I was going to bring up :-)
[10:27:28] <stefan> hunger: but you are inside the server, where you could keep another global 'object map', similar to the AOMs the POAs keep
[10:27:47] <stefan> hunger: this would be non-intrusive
[10:27:52] <njs> How do we want to do the transition to the coding standard? Spread out gradually over the next few milestones, or in one big push before M2? (I'm assuming that there are parts that will require manual intervention, so it won't be just a matter of invoking a giant 'indent' on the tree)
[10:27:57] <stefan> hunger: or at least only minimally so
[10:28:12] <hunger> stefan: ... und much more ugly then just adding a attribute to the interfaces:-)
[10:28:15] <neiljp> njs: IMO a 'giant indent patch' would be completely hellish
[10:28:35] <hunger> stefan: At least till we have changed the Traversal to use less CORBA;-)
[10:28:40] <stefan> njs: right. As far as I'm concerned, I did the transition for the code I touched. (_foo -> my_foo, etc.)
[10:28:40] <njs> neiljp: well, yes, but 1000 tiny indent patches would also be pretty annoying...
[10:28:59] <stefan> hunger: ugly ? Are you serious ? We don't have the same definition of uglyness then.
[10:29:24] <hunger> stefan: I don't want to write a object dictionary!
[10:29:32] <neiljp> njs: depends how much you trust indent...
[10:29:45] <stefan> hunger: you have to.
[10:30:03] <hunger> stefan: I didn't so far;-)
[10:30:12] <stefan> hunger: adding a type system on top of the CORBA type system is just ugly. Much more so than an object dictionary :-)
[10:31:06] <hunger> stefan: Let me sleep this over...
[10:31:07] <stefan> hunger: anyways, I'd much prefer to discuss this on issues.fresco.org in the appropriate task
[10:31:24] <stefan> do we agree that this is important enough to go into M2 ?
[10:31:33] <stefan> I don't think it is much work, once we agree on how to do it.
[10:31:40] <stefan> so it can be done in time for M2
[10:31:47] <hunger> stefan: As I said to njs earlier: IMHO we should focus on testing and debugging for M2.
[10:31:47] <njs> grr, stupid bug200
[10:32:09] <sdt> that would be task40...
[10:32:12] <neiljp> njs: lol :)
[10:32:17] <stefan> hunger: of course. Isn't that testing / debugging ? Or at least that's the context I see it in.
[10:32:36] <hunger> stefan: Sure it is:-)
[10:33:25] <njs> Part of making the code debugable, incidentally, would be better comments.
[10:33:45] <stefan> njs: yes, right.
[10:33:47] <njs> do we have a task "write up a synopsis-comment-writing HOWTO" yet?
[10:34:10] <neiljp> njs: apparently not
[10:34:10] <stefan> njs: don't think we have. Should go into the coding standard, no ?
[10:34:56] <njs> stefan: well, the standard says "write synopsis comments"; we need some documentation on _how_. (And, honestly, some more support from synopsis for basic formatting stuff, @ref and all that.)
[10:35:09] <njs> stefan: so probably that should go in another document. But it doesn't really matter either way.
[10:35:54] <hunger> How shall we switch over to the coding standard?
[10:36:09] <hunger> I'd propose doing this one subsystem at a time.
[10:36:41] <hunger> Like Prague first, then Babylon (which will be mostly converted by my next commit anyway), etc.
[10:37:33] * neiljp sees the new task interface and thinks its cool :)
[10:37:57] <hunger> stefan: If we all agree to concentrate on debugging/testing/porting for M2, then I'd move task63 (OPenlook) to M3.
[10:38:10] rajanr has quit ()
[10:38:18] <sdt> er
[10:38:22] <sdt> sure you mean task63?
[10:38:29] <sdt> "port fresco to FreeBSD"
[10:38:40] <neiljp> task62 methinks
[10:38:44] <hunger> s/task63/task62/
[10:38:49] <sdt> ok
[10:39:26] <sdt> any thought on those "visual bugs"?
[10:39:40] <stefan> ok, please have a look at http://wiki.fresco.org/M2
[10:39:45] <stefan> and edit to your heart's content
[10:40:17] <stefan> please also identify what you would like to work on, just so we know which things will evolve fastest :)
[10:40:19] <hunger> stefan: can we edit Milestones now?
[10:40:23] <neiljp> stefan: uh, milestone2? :)
[10:40:52] <hunger> stefan: You said you'd need to be coordinator to edit it.
[10:40:56] <stefan> please insert links to all bugs and tasks you see fit
[10:41:18] <stefan> hunger: dunno, haven't looked at that.
[10:41:51] <stefan> oh, this brings up another topic: the issue tracker schema. I'd like to explain what I mean by 'bug' and 'task':
[10:41:59] <hunger> stefan: I liked the idea of some central instance setting the milestones.
[10:42:09] neiljp has quit (Read error: 104 (Connection reset by peer))
[10:42:28] <stefan> for me, a 'bug' is a concept a user refers to when communicating things to us. That can be a crash, or an enhancement.
[10:42:41] <stefan> 'tasks', on the other hand, are means of the developers to coordinate their work.
[10:43:13] <hunger> stefan: Can you please add that to the TrackerFAQ in the wiki (or some documentation in the tracker) so it won't get lost?
[10:43:45] <stefan> it's a bit the same as with 'severity' and 'priority': 'severity' is used to quantify the impact on the user, while 'priority' is a way for developers to express how important a fix is, so it can be scheduled for a given milestone.
[10:44:05] <BenB> stefan: I thought that you introduced "task" specifically not to abuse the word "bug" for enhancements.
[10:44:11] <stefan> hunger: yes. I'd like to discuss with you so we can agree on that, then I'll add it to the issues site itself, as a doc page.
[10:44:26] <njs> I understand the distinction, more or less; in practice, though, it seems to just be annoying. I find that for almost all operations I want to perform (look at recent work, file suggestions, look for things that need doing), they're interchangeable -- I'm not convinced the distinction is the relevant one for actually working with the tracker.
[10:44:33] <stefan> BenB: hmm, well, may be I did. Then it shifted in my head :)
[10:44:43] <hunger> stefan: I like that definition, it fits in well with my current practice to use the tracker;-)
[10:45:09] <stefan> hunger: glad to hear that :)
[10:45:10] <oxygene> njs: the freebsd port is a nice example for a task imho
[10:45:33] <hunger> stefan: The bugtype RFE is a bit confusing then though...
[10:45:34] <stefan> njs: I see your point. There is often a 1-1 mapping.
[10:45:58] <njs> oxygene: sure, I realize that there's a difference. But there's also a difference between "design" and "porting" tasks, and we don't enshrine that difference in two separate database types.
[10:46:15] <stefan> hunger: no, a user can ask us to enhance fresco. But we'll then create a task that coordinates the efford to solve it.
[10:46:19] <hunger> stefan: Or are you suggesting that userrs fill in bugs while developers add tasks?
[10:46:32] <stefan> hunger: yes, more somehting like that.
[10:46:38] <hunger> stefan: With a mapping betwen both.
[10:46:51] <stefan> hunger: yeah, though the mapping doesn't need to be 1:1
[10:46:57] <BenB> stefan: so, by your definition, almost all bugs would have 2 entities? the bug thatr the user reported and the task the develop uses to track the work on the bug?
[10:47:09] <stefan> hunger: we don't need bug reports to create tasks.
[10:47:21] <njs> in practice, for me, it mostly means that everytime I want to do perform some operation, I have to do it twice in identical ways -- once for bugs, once for tasks.
[10:47:24] <stefan> BenB: well, not necessarily. The two sides are not isomorphic
[10:47:30] <sdt> hrm, wouldn't it be better to keep everything in one place?
[10:47:35] <hunger> stefan: Of course not... but you mandate a task for each bug?
[10:47:41] <stefan> sdt: 'one place' ?
[10:47:46] <sdt> well, either as a bug or a task
[10:48:06] <BenB> stefan: say, I find a real bug in fresco and file it as bug. a develop wants to fix it. does he now also file a task to track his work?
[10:48:09] <stefan> hunger: no, I don't mandate anything. The tracker is there to support the way we like to work, not to force us into anything.
[10:48:19] <stefan> hunger: if you don't like it, don't use it.
[10:48:28] <oxygene> BenB: he might also assign it to some existing task
[10:48:33] <oxygene> BenB: like "porting to architecture foobar"
[10:48:51] <njs> and then you have to manage the mapping, and it doesn't work very well, and we have quasi-arbitrary requirements on which relationship links can point which ways...
[10:48:57] <BenB> oxygene: I am talking about real bugs, and in many cases, there is nothing bigger to link it to.
[10:49:01] <hunger> stefan: Give up on the tracker? NEVER;_)
[10:49:06] <stefan> BenB: depends. If the efford is short lived, no task is needed. But if the thing needs some long term coordination, a task would be a good idea.
[10:49:35] <njs> and I notice that in practice, I've never heard of another BTS that had two separate entity types like this; everyone else calls them both "issues" and throws them in the database together.
[10:50:11] <njs> stefan: but functionally, a task is just like a bug; any coordination you can do via a task you could do via a bug just as well. Or you could just call them both "issues" and be done.
[10:50:20] <stefan> njs: well, nobody did use scene graphs the way we do. What's your conclusion ? :-)
[10:50:39] neiljp has joined #fresco
[10:50:41] <njs> stefan: well, Fresco did :-)
[10:50:48] <sdt> heh. I was just about to say that.
[10:50:49] <BenB> I agree with njs in general, but looking at bugzilla.mozilla.org, some barrier from users can be a good idea, if fresco has lots of users.
[10:50:54] <neiljp> bah, what just happened which was interesting? ;)
[10:50:56] <BenB> (lots = 100000 and more)
[10:51:10] <stefan> njs: ok, well, I already identify 'we' with 'fresco' :-)
[10:51:12] <sdt> is it really such a big deal right now?
[10:51:48] <BenB> sdt: users? no.
[10:51:55] genesfra has joined #fresco
[10:52:06] <hunger> Hi genesfra.
[10:52:08] <sdt> well, even the whole task/bug distinction? it seems to be working quite well...
[10:52:08] <njs> BenB: but I think you can implement that barrier by just adding some field that you can screen on, no? We already have the distinction between "new" and "open" bugs, where the latter is supposed to be things that developers have actually decided are valid (though ATM we don't bother)
[10:52:15] <BenB> sdt: but I do need to know the policy for the tracker, I don't know how to file RFEs.
[10:52:38] <sdt> RFEs=?
[10:52:38] <hunger> njs: open are bugs somebody works on, isen't it?
[10:52:42] <BenB> njs: agreed
[10:52:49] <BenB> sdt: request for enhancement
[10:53:00] <njs> BenB: and splitting the two actually makes more work for me in practice; I often find myself searching first the bugs, and then the tasks, to find a particular issue that I remember, but don't remember whether it was filed as a bug or as a task.
[10:53:20] <sdt> those sound like tasks to me... anyways, do you really need policy to dictate that? the tracker's just a tool to provide convenient tracking of issues, yes?
[10:53:23] <hunger> njs: That's a good point.
[10:53:53] <stefan> njs: hmm, we could automatize quite a bit there, with detectors
[10:53:56] <BenB> njs: yes, I understand your point (weeks ago when we first talked about it) and I gree.
[10:54:18] <sdt> how about just being able to search for both bugs and tasks then?
[10:54:28] <hunger> stefan: Some detectors to setup default values and enforce some standards would help a lot.
[10:54:31] <stefan> sdt: yes, that would help, too.
[10:54:37] <BenB> sdt: well, for a start, I can't file tasks right now. and I thought that rfes are supposed to be tasks.
[10:54:37] <stefan> hunger: yes
[10:55:05] <hunger> stefan: What is the semantic for milestones? As I understood it first a coordinator set those. Now it looks like I (developer) can do so.
[10:55:28] <stefan> BenB: no, 'rfe's are 'requests'. I.e. a user wants something. The 'task' is created and processed by developers. Because they know what they want / are able to work on.
[10:55:28] <hunger> stefan: Why did you change that? All I asked was for a message field so I could comment on what you did inside the tracker.
[10:55:44] <njs> Basically, my point is just that when it came down to getting work done, I have never found the distinction between bugs and tasks to be useful, and I have often found it to be REALLY ANNOYING. So.
[10:55:49] <stefan> hunger: dunno whether I changed that or somebody else.
[10:56:07] <hunger> stefan: I still can't edit the milestones.
[10:56:11] <hunger> stefan: Just tried.
[10:56:24] <stefan> hunger: so what did I change then ?
[10:56:26] * stefan is confused
[10:56:33] <hunger> stefan: Could you please add that message field? Then we could move the complete milestone discussions into the tracker.
[10:56:47] <stefan> hunger: yes, will do.
[10:57:22] <hunger> stefan: I used to get a list of bugs/tasks only. Now I get the buttons to actually change things with (und an error message if I try;-)
[10:57:26] <neiljp> either included in that or separately a 'please add/remove this task/bug' request :)
[10:57:35] <stefan> ok, could everybody who is going to do some work please add that to the wiki page ? Just so we get an idea of where we are heading
[10:57:47] <stefan> hunger: oh.
[10:57:47] <neiljp> stefan: what page?
[10:57:58] <stefan> neiljp: uh, I created 'M2', didn't I ?
[10:58:03] <njs> I propose task82, task83, task84, task85 (write a synopsis HOWTO and create indent/emacs/vim configs for the new style guide) for M2.
[10:58:22] <stefan> njs: please make that proposal persistent in the wiki.
[10:58:32] <stefan> njs: (and add yourself to the tasks you want to work on)
[10:58:54] <njs> stefan: well, part of the point of the discussion is to decide what we should work on, no? :-)
[10:59:05] <hunger> njs: Add them to the milestone.
[10:59:09] <neiljp> stefan: wiki?
[10:59:15] <hunger> njs: ... once there's the message field.
[10:59:25] <sdt> neiljp: http://wiki.fresco.org/M2
[10:59:28] Phython has joined #fresco
[10:59:30] <neiljp> ah...
[10:59:43] <njs> message fields are all well in good, but I still think we should discuss now while we're together :-)
[11:00:24] <hunger> stefan: I'd prefer task62(OpenLook) to be in M3.
[11:00:27] <sdt> just a moment
[11:00:28] <stefan> njs: indeed. That's why we sit together :)
[11:00:33] <stefan> hunger: why ?
[11:00:56] <hunger> stefan: Didn't we decide to concentrate on testing/debugging/porting with M2?
[11:01:33] <hunger> stefan: What has openlook to do with that? And it should be easier to do once you can dump a graph and see where you blotched up the coordinates too:-)
[11:01:56] * sdt suggests bug82 and task38 (which, incidentally, work really well together)
[11:02:19] <neiljp> sdt: ...as long as you don't hit ESC on desktop...see last comment just added ;)
[11:02:34] <neiljp> sdt: please try and replicate...later perhaps ;)
[11:02:55] <sdt> ok
[11:03:22] <sdt> gah, now I can't find the bugs I was hoping to fix
[11:03:24] <hunger> stefan: I'd like task30 (unit test framework) and task40 (scenegraph debugging).
[11:03:47] <sdt> ah yes
[11:04:05] <sdt> bug190, possibly bug191
[11:04:14] <njs> *skimming scrollback* So how _are_ we planning to do the coding guidelines transition?
[11:04:23] <sdt> I'm willing to work on those
[11:04:26] <sdt> and related issues
[11:04:27] <hunger> stefan: And bug9
[11:04:32] <njs> one component at a time, as hunger suggested?
[11:04:36] <neiljp> njs: uh, is there a bug for that? :)
[11:04:41] <neiljp> njs: :)
[11:04:59] <neiljp> njs: add that to the list for m2, then discuss there...but one per module sounds fine to me
[11:05:10] <hunger> njs: One component at a time, no changes but the reformating in the same commit would be the best way to go IMHO.
[11:05:24] <njs> hunger: okay. let's go with that, then, if there are no objections.
[11:05:26] * neiljp plans to do lots of little tidying
[11:06:21] <neiljp> eg. perhaps 176, 178, 188, 192...depends how many 'simple' bugs we want to leave open for newbies, and how much we want to get, er, working :)
[11:06:36] <neiljp> 153, 143
[11:08:33] <sdt> wow, those really are easy
[11:08:40] * hunger wonders where the task for implementing the coding style guide went.
[11:08:46] <neiljp> well, some are bitesize...
[11:08:52] <njs> hunger: task8, task9
[11:11:06] <stefan> any *bsd people here ?
[11:11:11] <hunger> stefan: I'd like tasks8, 9, 30, 40 added and task62 moved to M3.
[11:11:37] <neiljp> hunger: hum...wiki page?
[11:11:45] <stefan> the freeBSD port should be done, but there are some bugs left. However, they seem to be the same bugs we see elsewhere, i.e. we may as well consider the FreeBSD port to be complete.
[11:12:15] LordVan has quit (Excess Flood)
[11:12:20] <stefan> hunger: ok. Well, we can always remove a task when it blocks the release of M2.
[11:12:34] LordVan has joined #fresco
[11:12:46] <hunger> stefan: That sucks! We do have the tracker to be able to do some planing.
[11:13:02] <njs> stefan: did they ever manage to get the demo window to appear on bsd?
[11:13:07] <hunger> stefan: Shifting things around when they become inconvininet is not the way to go.
[11:13:18] <stefan> hunger: sure. I didn't say the contrary. But I still hope to be able to work on that. Or better: I *want* to work on that, so why should I remove it ?
[11:13:39] <hunger> stefan: You can work on it, no problem with that!
[11:13:40] <njs> stefan: well, is it a goal of yours to have it done by m2?
[11:13:49] <njs> stefan: that's the question, really.
[11:13:51] <waldi> hi
[11:14:03] <stefan> njs: yes, though I'm ready to drop that goal when I see the M2 can't be released because of it.
[11:14:16] <hunger> stefan: Nobody is arguing that it shouldn't be done. I'm just arguing that it shouldn't be part of M2.
[11:14:20] <hunger> waldi: Hi!
[11:14:23] <BenB> somebody fixed the bug that the scrollbar thumb is not in sync with the mouse, right?
[11:14:31] soyt has quit ("Client Exiting")
[11:14:44] <hunger> stefan: Nobody stops you working (or even closing) tasks later then the current one, do they?
[11:14:44] <neiljp> BenB: a while back iirc...though not sure about rotated windows and that...or is that a separate bug?
[11:14:55] <stefan> hunger: I'd like to have at least a *bit* of visual change for the next release, so we can show something to people, beside reiterating how much it got enhanced internally.
[11:15:03] <sdt> BenB: I fixed that bug for most cases
[11:15:08] <BenB> neiljp: dunno, just going through the old SF bug (most of them mine)
[11:15:11] <sdt> BenB: it's still there for y rotation (bug190)
[11:15:21] <hunger> stefan: I'd prefer to get M2 out asap.
[11:15:23] <BenB> sdt: nod, thanks. Great that you fixed it! ;-)
[11:15:23] <neiljp> BenB: the exception-catching bug is ported already :)
[11:15:25] <njs> This brings up the thing that I think we still should talk about, before totally dissolving the meeting: what's the relation between big ongoing tasks (text, events, etc.) and milestones?
[11:15:38] <stefan> hunger: well, we aligned for February, didn't we ?
[11:15:50] <BenB> neiljp: I know about bug 180, that made me start :)
[11:15:53] <hunger> stefan: Did we? Never knew that.
[11:15:55] <neiljp> BenB: ah :)
[11:15:58] <stefan> njs: hmm, tricky.
[11:16:08] <neiljp> stefan: well, you proposed, iirc ;)
[11:16:17] <njs> stefan: well, arguably, that's something we could do for M3 -- M1 is our "okay, let's get going again" release, M2 is where we show that we can release again in a few months with actual fixes in, M3 is where we start getting more ambitious. But that's just one possible story :-)
[11:16:38] <stefan> njs: almost none, I'd say. I think it is important to state what (long term) tasks we are working on, but they don't need to show up in a milestone (we have http://issues.fresco.org/reports/tasks.html for that)
[11:16:39] <neiljp> njs: sounds feasible...just as long as you don't want exponential growth ;)
[11:17:04] <BenB> neiljp: actually, that bug180 sounds like a task, while my bug would be a real bug :)
[11:17:13] <neiljp> BenB: argh!
[11:17:16] * neiljp runs from BenB
[11:17:20] <hunger> stefan: We could just have more milestones in the tracker and assign the longterm goals to them...
[11:17:21] <BenB> neiljp: lol
[11:17:21] <njs> (Maybe I'm being silly, but I sorta feel like doing right M2 is Important -- that it'll "set our rhythm" for future milestones.)
[11:17:45] <stefan> njs: of course, at some point we want to have even the most long term tasks fixed, so may be M12 will contain the 'get text working' task :-)
[11:17:52] <njs> stefan: well, but part of the point of milestones is to have concrete goals to work towards, and measurable steps.
[11:18:07] <stefan> njs: yes. I don't see your point.
[11:18:08] <hunger> stefan: A bit of longterm planning wouldn't hurt. Which release should have font selection, which full support for styled text, which a complete TextKit, etc.
[11:18:18] <stefan> njs: how can we measure advancements with the TextKit *now* ?
[11:18:19] <njs> stefan: so I think we should try to have _some_ connection between those giant tasks and milestones, or we're likely to let them slip.
[11:18:29] <njs> stefan: well, it's hard.
[11:18:40] <stefan> njs: well, yes. We need 'deliverables', as management likes to call them :-)
[11:18:52] <neiljp> stefan: developers cannot change milestones, right?
[11:18:58] <njs> stefan: my proposal on -devel a while back was; for M, have _some_ revamped text system, _some_ revamped event system.
[11:19:05] <stefan> njs: but that can be requirement specs, design specs, whatever.
[11:19:15] <BenB> hunger: but without anybody working on it, it's hard. same effect in bugzilla.mozilla.org. milestones are set and routinely pushed forward, and people complain, because it looks like an unkept promise.
[11:19:35] <stefan> njs: well, that makes sense as soon as you can replace 'some' with something less fuzzy
[11:19:44] <njs> stefan: ie, not complete solutions that are perfect, but it seems to me that these tasks are so big and so hard that we can't even begin to see where to go next.
[11:19:58] <sdt> er, so should task40 be added to M2
[11:20:12] <njs> stefan: so what we should be doing is building the ones we'll throw away, and that way learn how to the real system will work.
[11:20:22] <neiljp> sdt: well hunger mentioned that one, didn't he? hunger?
[11:20:38] <njs> stefan: hence the "some" -- I'm not looking for something perfect, but something that plausibly tries to solve some of the problems, and actually works, and I don't care about warts.
[11:20:45] <neiljp> njs: 'code to requirements, nothing more' ?
[11:20:56] <sdt> yes, he did
[11:20:56] <neiljp> njs: for now ;)
[11:21:05] <njs> neiljp: is that another way of saying YAGNI? :-)
[11:21:10] <sdt> it just seems like you (neiljp) and I are the only ones adding stuff to that page
[11:21:23] <neiljp> njs: YAGNI?!
[11:21:30] <neiljp> sdt: seems like it :)
[11:21:30] <njs> neiljp: it's not even that; we can't even figure out what the requirements _are_, in some sense.
[11:21:47] <neiljp> njs: oh sure
[11:22:00] <njs> neiljp: part of the XP philosophy: http://www.c2.com/cgi/wiki?YAGNI
[11:22:15] <njs> stefan: any opinion on this approach?
[11:22:21] <neiljp> njs: well maybe nicholas will spur that, since he has the FontKit idea following from the FT port
[11:22:55] <neiljp> njs: uh, that page is empty?
[11:23:15] <njs> Here's my list of bugs/tasks proposed for M2: task77, task68, bug92, task40, task82, task83, task84, task85, task30, bug190, bug191, bug9, bug176, bug178, bug188, bug192, bug153, bug143
[11:23:30] <njs> hmm, so it is; I just grabbed it out of my browser history :-
[11:23:48] <bughunter> njs: You missed bug183 and bug89 :)
[11:23:49] <neiljp> njs: please add to M2 page :)
[11:23:50] <stefan> njs, sdt: actually, as far as text is concerned, chances are I'm going to meet with nicholas in Toronto or nearby. There are a couple of fresco related people...
[11:23:58] <njs> here: http://www.c2.com/cgi/wiki?YouArentGonnaNeedIt
[11:23:59] <sdt> oh, yay
[11:24:01] <stefan> njs: so we may come up with a more detailed plan to attack all that...
[11:24:13] <sdt> stefan: I've been asked to ask you to give a talk here at waterloo :)
[11:24:25] <stefan> njs: nicholas has already some good ideas...
[11:24:34] <stefan> sdt: oh ?
[11:24:44] <sdt> yeah, for the computer science club. if you'd like
[11:25:05] * neiljp wonders if he ought to move to Canada...
[11:25:10] <stefan> sdt: well, we should by all means organize a meeting, at least with nicholas, golbez, graydon, and other local geeks that want to join in.
[11:25:20] <sdt> sure
[11:25:22] <neiljp> njs: I know about XP...sorta :)
[11:25:25] <stefan> sdt: why not ? Let's see...
[11:25:26] <njs> neiljp: heh, I've been wondering the same thing lately... though partly for political reasons, I'll admit :-)
[11:25:43] <sdt> philbo won't be here next term, unfortunately, but golbez will.
[11:25:47] nicholas has joined #fresco
[11:25:50] <sdt> yay
[11:25:51] * hunger feels left out just because he's german.
[11:25:51] <neiljp> njs: well, there are negative changes...but uk is getting equivalent bad for some reasons
[11:25:54] <stefan> nicholas: !!!
[11:25:56] * neiljp cheers for nicholas arriving :)
[11:25:57] * philbo has a car and a will to participate
[11:26:00] <nicholas> zZzzZzzZz
[11:26:10] <sdt> ah, well, even better
[11:26:12] <nicholas> I'm really really really sorry.
[11:26:14] * neiljp feels left-out because he's English
[11:26:14] <stefan> hey philbo, you, too, of course :)
[11:26:20] <neiljp> nicholas: [fwap] :)
[11:26:26] <sdt> nicholas: http://wiki.fresco.org/M2 <-- add here
[11:26:32] <njs> neiljp: it's interesting stuff, worth reading about, if you're interested in process. Not directly relevant to OSS development, because they assume a _really_ different development context, but really interesting ideas.
[11:26:33] <hunger> stefan: It all boils down on how to represent text in the scengraph to me.
[11:26:46] <sdt> nicholas: and the topic of a meeting somewhere around waterloo/toronto came up
[11:26:49] <sdt> just now
[11:26:57] <nicholas> sdt: oh fantastic.
[11:27:04] * njs really wishes he could attend such a meeting. Alas.
[11:27:16] <neiljp> [aol] me too [/aol] :(
[11:27:27] <stefan> nicholas: well, I mentioned that we discussed that, i.e. discussing TextKit related stuff.
[11:27:38] <nicholas> stefan: nod.
[11:27:41] <stefan> hunger: well, no, it's quite a bit more involved.
[11:27:47] <nicholas> stefan: is it any closer to becoming a reality?
[11:28:00] <neiljp> well just now that nicholas is here, I'm going to have to get ready for work ;|
[11:28:07] <stefan> hunger: for example, how much are glyphs / fonts encapsulated within the DrawingKits ?
[11:28:16] * sdt wonders if the CSC could obtain money to pay for people to come over to have a fresco "conference" :)
[11:28:17] <hunger> stefan: Sure. But once you have a good idea on how to store things in the SG much falls into place automatically.
[11:28:25] <stefan> hunger: i.e. how 'portable' can it be done without compromizing quality ?
[11:28:37] <stefan> hunger: I doubt. But we'll see...
[11:28:58] <sdt> njs: wanna add your list to M2?
[11:29:23] <hunger> stefan: It all boils down to "How much layout information do we need to store" which in turn is directly related to how the stuff gets stored in the SG.
[11:29:42] <hunger> stefan: ... or in a Graphic in the SG for that matter,.
[11:30:40] JonasAm has left #fresco
[11:30:43] <stefan> nicholas: could you tell us a bit about your goals for M2 ?
[11:30:53] <nicholas> stefan: I'm playing with fonts.
[11:30:57] <stefan> nicholas: (M2 == milestone to be released in about two months)
[11:31:00] <nicholas> stefan: that and task38 of course.
[11:31:07] * neiljp grins
[11:31:13] <nicholas> stefan: I doubt if I can do a full FT2-->PSDK system in that time.
[11:31:20] <njs> hmm, nicholas should really read the logs, if someone has them...
[11:31:35] <neiljp> nicholas: oh and btw, see the task38 comment I made...
[11:31:37] <stefan> nicholas: njs suggested we get a more fine-grained definition of 'make text work'...
[11:31:41] <nicholas> neiljp: yeah i got it.
[11:31:50] <nicholas> stefan: i'm starting with just fonts.
[11:32:08] <nicholas> stefan: the deal being that everything will revolve around using a freetype2 face to render.
[11:32:16] <BenB> why is the comment field so small (5 rows)?
[11:32:18] <sdt> neiljp: I can't reproduce that
[11:32:32] <sdt> neiljp: pressing ESC doesn't quit the client though, but I don't remember if that's normal.
[11:32:37] <njs> nicholas: wait, freetype solves font unification?
[11:32:38] <nicholas> stefan: what we're going to do after that, is pull the freetype2 face out of the drawingkit, and into corba-space, by writing a wrapper around nearly *all* of the face functions.
[11:32:48] <njs> nicholas: (I'm assuming that's what a "face" is)
[11:32:51] <neiljp> sdt: no, that's task57 iirc
[11:32:52] <hunger> njs: Nope.
[11:32:56] <nicholas> njs: no, a face is just a font.
[11:32:57] <sdt> ok.
[11:33:00] <sdt> then I can't reproduce
[11:33:03] <njs> nicholas: oh, okay.
[11:33:13] <hunger> njs: STSF and some others do.
[11:33:18] <njs> hunger: nod
[11:33:19] <neiljp> sdt: ok, I'll have to try again...later ;|
[11:33:29] <nicholas> stefan: then, we have ourselves a FontKit which prouces these CORBAized objects for the DrawingKits to use. This might also be the place to put font virtualization in, I'm not sure yet.
[11:33:29] <njs> (yay, stow got installed on purcel)
[11:34:08] <nicholas> stefan: then either the textkit or fontkit will provide decorators for font selection. (probably the textkit.)
[11:34:29] <hunger> nicholas: What is the task the fontkit solves?
[11:34:43] <nicholas> hunger: unified rendering across CORBA-space.
[11:34:57] <nicholas> hunger: all drawingkits render that corba object, basically.
[11:34:57] <hunger> nicholas: CORBA space?
[11:35:16] <nicholas> hunger: right. so you can load a font on a different machine than the one that renders it.
[11:35:19] * njs starts editing the M2 page, nobody else touch it for a bit...
[11:35:48] <hunger> nicholas: That assumes all DKs can render the same fonts exposed via the FontKit?
[11:35:53] <nicholas> hunger: because you just call "rendertobitmap" on the corba object. (or whatever the ft2 people called it, i forget.)
[11:36:00] <nicholas> hunger: yes. they all will, by definintion.
[11:36:15] <nicholas> hunger: that's what i'm doing. making everything render freetype2 fonts and discarding anything else.
[11:36:21] <hunger> nicholas: Is rendertobitmap enough?
[11:36:25] <nicholas> hunger: no.
[11:36:35] <nicholas> hunger: which is why we're wrapping *all* of the FTFont API.
[11:36:42] <hunger> nicholas: How do you want to habdle effects on fonts?
[11:36:50] * njs shudders at the amount of stuff that has to be exposed via CORBA if we continue to insist on rendering over it... it's even worse if we want color support too.
[11:37:08] <nicholas> hunger: not sure. you mean like underlined text?
[11:37:35] <hunger> nicholas: Like perspective projection of text, etc.
[11:37:52] <nicholas> hunger: oh! oh. Like we (don't currently) support perspective projection of anything else.
[11:37:53] <hunger> nicholas: All those nasty non-affine transformations Corel Draw allows:-)
[11:38:02] <njs> what's the "no font -> weird crash" bug?
[11:38:08] <nicholas> hunger: which will be to set the projection matrix in the drawingkit3d.
[11:38:34] <stefan> nicholas: ah, speaking of projection...
[11:38:55] <hunger> nicholas: I don't think it's such a good idea to leave that to the 3DDK...
[11:38:59] <stefan> does anybody have plans for work on 3D stuff (picking, perspective drawing, PrimitiveKit, etc.)
[11:39:02] <nicholas> hunger: wrapping text around a circle isn't really well defined, as far as I can find.
[11:39:14] <nicholas> stefan: not me, not soon.
[11:39:23] <hunger> nicholas: You will want to have a voctor drawing application outside the 3DDK too, don't you?
[11:39:38] <stefan> steveh: want to get involved in fresco ? :-)
[11:40:02] <nicholas> hunger: Well, if you want to be the guy who supports this in libartDK, go right ahead...
[11:40:38] <steveh> stefan: maybe :) I'll see if I have time.. need to see how big a job it is to add the OBBs
[11:40:54] * neiljp wonders what an OBB is
[11:40:56] <oxygene> njs: change your font path to an empty directory
[11:41:02] <steveh> Oriented Bounding Box
[11:41:02] <oxygene> njs: try to start a client using fonts
[11:41:07] <neiljp> steveh: ah :)
[11:41:24] <njs> oxygene: I know what happens, I'm wonderin gthe bug number :-)
[11:41:25] <stefan> steveh: if so, let us know, so we can work out 'bytesize' chunks so it can be done one thing at a time.
[11:41:48] neiljp changes name to neilp_afk
[11:41:50] <stefan> steveh: i.e. you don't need to commit to a work that takes months
[11:42:01] <steveh> stefan: will do
[11:42:05] <nicholas> stefan: we need to change the region to be an obb anyways.
[11:42:06] <stefan> steveh: ...and others can join in, too.
[11:42:08] <nicholas> stefan: to fix clipping.
[11:42:09] <hunger> nicholas: Why do you want to keep the FontKit separate from the DrawingKit? Code reuse?
[11:42:10] <stefan> steveh: excellent !
[11:42:23] <stefan> nicholas: yeah, I know.
[11:42:39] <njs> hunger: device independent rendering?
[11:42:46] <nicholas> hunger: no. Because a Real Client should be able to get access to these things.
[11:42:54] <hunger> nicholas: Is that really a Kit at all? We'll want to have several such 'Kits' I think.
[11:43:01] <njs> nicholas: that's not enough to fix clipping; we need basically arbitrary clipping regions for that...
[11:43:02] <nicholas> hunger: and they're not drawingKit specific anyways. So why hide them in that interface?
[11:43:15] <nicholas> njs: true. i know. i don't know what to do about it.
[11:43:17] <stefan> njs: right, but there is no clipping without.
[11:43:17] <hunger>