[14:27:31] <stefan> nicholas: hmm, should we start ?
[14:27:40] <nicholas> stefan: yeah, looks like about time.
[14:27:49] <nicholas> stefan: njs says he'll show up in about one half hour from now.
[14:28:02] <stefan> nicholas: ok, fine.
[14:28:37] <nicholas> Alright! First on the agenda!
[14:28:43] <stefan> who thinks he will work on fresco in the near future ?
[14:29:12] <nicholas> ook. That's a toughie. :)
[14:29:28] <scanline> ooh, meeting
[14:29:33] <stefan> nicholas: heh. Well, we should align the goals for M3 with that. Doesn't look good. :/
[14:30:00] <nicholas> I am planning to wipe up the FontKit because it's a total mess. But besides that, I have exams followed directly by a full day long job for summer.
[14:30:20] <stefan> nicholas: ouch
[14:30:22] * hunger wants to get those redraw bugs fixed.
[14:30:35] <hunger> Even though I'm going mad over the whole exercise:-)
[14:30:45] <stefan> nicholas: ok, beside the FontKit stuff, are there other things you'd like to work on ? What about the Path stuff ?
[14:30:46] <nicholas> Yeah. The "crap on the screen" bugs are amazingly annoying. They shouldn't be there.
[14:30:59] <nicholas> stefan: Oh, I'd like to. :)
[14:31:08] <nicholas> stefan: I'd like the coordinate system rejiggered, too.
[14:31:16] <stefan> nicholas: actually, I think the Path stuff could be the single most important feature in the short term future.
[14:31:27] <stefan> nicholas: ??
[14:31:39] * stefan goes to grab a coffee
[14:31:56] <nicholas> stefan: the coordinate system? You remember that the WidgetKit is oversized, then the Consoles are running in 24dpi to make up for it? That's gotta change.
[14:32:21] * hunger agrees.
[14:32:34] <nicholas> hunger: yeah. I found a couple problems with the Viewport Demo, but there's still a lot of stuff (find bugs filed by kentyman).
[14:33:27] <nicholas> The thing with the coordinate system is that we don't need to fix it now, since it looks just fine. But I don't want to accrue even more bad code. It must be fixed before we ask for client authors to start work.
[14:36:03] <stefan> nicholas: oh, yeah, getting the global CS right is a serious bug.
[14:36:31] <nicholas> stefan: ok. I'll bump the priority on Paths so I do them before FontKit work.
[14:37:29] <nicholas> stefan: but rendering/picking errors are nasty. I don't understand why we have so many...
[14:38:00] <scanline> blame libart ;)
[14:38:14] <hunger> nicholas: It's probably just a few bugs appearing all over the place.
[14:38:26] <nicholas> hunger: Hopefully.
[14:39:38] <nicholas> hunger: One thing with picking, I don't believe we transform the coordinates before delivering them? Or something like that, due to dragging. Kentyman has a bug for scrollbars misbehaving when y-rotated... I'd like to fix it, but the system needs documentation.
[14:40:28] <hunger> nicholas: Tell that to stefan:-) I'm only trying to figure out what he was doing and wether there might have been a bug somewhere.
[14:41:53] <stefan> nicholas: right, the event handling needs to be thought over, especially the CS of the positional events.
[14:42:42] <stefan> nicholas: there are some issues, notably when you drag a window, i.e. the transformation from the global CS to the local one changes *while* the events are handled.
[14:43:12] <stefan> nicholas: ah, documentation should be a high priority task.
[14:43:18] <nicholas> stefan: well, I question whether that should be happening; the CS the events should be translated to shouldn't be that of the window, but of the desktop.
[14:43:19] <stefan> nicholas: we should work on the tutorial.
[14:43:31] <nicholas> stefan: I was thinking of something a little closer to javadoc.
[14:43:38] <scanline> doxygen?
[14:43:50] <stefan> nicholas: I got a nice pdf generated, only need to upload the necessary infrastructure to purcel so the pdfs can be generated there, too (in the nightly build)
[14:43:54] <nicholas> well, the tool itself doesn't matter. It would probably be synopsis.
[14:43:59] <nicholas> stefan: ok
[14:44:05] <stefan> nicholas: what do you mean ?
[14:44:18] <stefan> nicholas: what kind of document do you have in mind ?
[14:44:20] <nicholas> stefan: a reference manual, not simply a tutorial.
[14:44:27] njs` has joined #fresco
[14:44:29] <stefan> nicholas: 'not simply a tutorial' ?
[14:44:33] <nicholas> njs`: hello!
[14:44:39] <hunger> nicholas: Something like the refmanuals?
[14:44:43] <scanline> hi njs`
[14:44:46] <stefan> nicholas: writing a tutorial is a thousand times more difficult (for me at least) than generating a ref manual.
[14:44:52] <stefan> nicholas: ...and much more useful, too.
[14:44:55] <hunger> nicholas: Do you wish to improve those or write something new?
[14:45:01] <nicholas> stefan: probably, yes.
[14:45:03] <nicholas> Well.
[14:45:35] <stefan> nicholas: picking for example can't be understood just by looking at the ref manuals. A tutorial has to explain the whole context.
[14:45:48] * njs` ssh's to the host "njs" is logged in from to read logs
[14:45:54] <nicholas> stefan: I agree, the tutorial is necessary.
[14:45:55] <stefan> nicholas: and in fact the current tutorial does a bit of it. It's far from complete, I admit.
[14:46:15] <stefan> njs`: hi there
[14:46:56] <nicholas> stefan: but so are particulars, like exactly which object does what, and how internal pieces work. A refmanual for the DesktopKit that explains how it does things like move windows. Stuff like that.
[14:46:57] <hunger> stefan: What's the status of SXR? Is chalky on it?
[14:47:00] <stefan> nicholas: so, if for example you design a new path API, I'd suggest that you write a chapter on that in the tutorial *in parallel*
[14:47:12] <nicholas> stefan: that's a very good plan!
[14:47:24] <stefan> nicholas: yes, agreed. But for a start I believe it's better to get the big picture than to start with the details.
[14:47:39] <nicholas> stefan: oh. Well, when bughunting, I need details. :-)
[14:47:42] <njs`> or write the tutorial first :-)
[14:48:02] <stefan> hunger: no. I should really get off my butt and finish sxr.
[14:48:19] <hunger> stefan: So should I:-)
[14:49:01] <stefan> ok, so we have identified a couple of tasks: the path stuff, work on the tutorial, more work on the website (sxr !)
[14:49:14] <hunger> stefan: I have some time at my hand, but somehow I allways manage to find something less productive to do then sitting down and work on fresco.
[14:49:17] <nicholas> Coordinate system and UI bugs.
[14:49:24] <stefan> njs`: do you have some time to spend on the unit tests ?
[14:49:33] <stefan> nicholas: yeah, the usual stuff...:-)
[14:49:44] <nicholas> njs`: how can I build unit tests for the FontKit? I need a running server, don't I?
[14:50:04] <stefan> nicholas: of course, I *want* to work on event handling and focus management. But I have been saying that for a long time...:-/
[14:50:27] <nicholas> stefan: I've been counting on you to work on it. :-)
[14:50:30] <njs`> stefan: not to get sidetracked, but now that gcc's new C++ parser has landed, are you thinking of stealing it? (since it seems from what little I've seen that half the SXR work is fixing bugs in openc++)
[14:51:23] <stefan> njs`: may be. Is it LGPL ? Or, even better, does gcc provide access to the parse tree (or even the syntax tree) ?
[14:51:54] <nicholas> gcc doesn't actually build a full AST does it? Or was that the old parser?
[14:52:02] <njs`> stefan: talk to zwol. I'd guess it's GPL, though.
[14:52:15] <stefan> njs`: part of the problem was that the old gcc didn't allow to hook into it, because they feared the GPL could be circumvented
[14:52:58] <njs`> stefan: nod. you could always rip it out of the source tree, I suppose :-)
[14:52:59] <stefan> njs`: hmm, well, I think GPL isn't even the issue. But anyways, that's offtopic...:)
[14:53:32] <stefan> njs`: openC++ works well enough for me, I don't think I'd touch it any time soon.
[14:53:50] <njs`> re: my time: I seem to have way overcommitted on school/research stuff for the next months, so I don't know if I'll have much if any time for Fresco :-(
[14:54:07] <stefan> njs`: oh well
[14:54:10] <nicholas> hm.
[14:54:29] <njs`> sorry guys :-(
[14:54:35] <nicholas> I guess what we could do, is have a lightweight release in three months, then something more serious than that for M4?
[14:54:45] <stefan> nicholas: we should discuss the path stuff in a different meeting. Outline what is needed, what issues need to be addressed (such as unwinding, tesselation, etc.)
[14:54:52] <nicholas> "M3: the largely dormant period?"
[14:55:10] <scanline> "M3: thinly sliced banana"
[14:55:18] <stefan> nicholas: well, I honestly believe a tight release schedule of 3-4 months is important.
[14:55:28] <nicholas> stefan: all right.
[14:55:35] <stefan> what do others think about that ? Is 4 months enough for a release ? Is it 'too often' ?
[14:55:48] <nicholas> stefan: I can't see us getting too much done in the timeframe.
[14:55:57] <njs`> nicholas: if you can write code that figures out whether the fontkit works, then you can have unit tests for it.
[14:56:06] <hunger> stefan: I don't really care.
[14:56:19] <njs`> stefan: I agree on the importance.
[14:56:35] <hunger> stefan: Having no releases is bad, having releases without any user-visible changes is not much better though.
[14:56:38] <njs`> nicholas: does it matter? it's not like you'll get more done if you put off the release farther.
[14:56:41] <nicholas> njs`: well, I can test most of it I guess. I mean, it won't tell me if the data is correct, but ...
[14:56:47] <stefan> nicholas: well, if a given task doesn't fit into such a scheme, split it up. That's a good idea anyways, just to measure the progress. That's what milestones are all abuot anyways.
[14:56:51] <nicholas> njs`: no, but the later the release, the more there is in it. :)
[14:57:14] <stefan> hunger: I don't care about users or what they think right now.
[14:57:35] <stefan> hunger: the point is to keep *us* on track, and provide some measures to see how or whether we progress.
[14:57:37] <hunger> stefan: Users == fellow developers too.
[14:57:42] <nicholas> Right. We're still pre-users at the moment.
[14:57:51] <nicholas> But some people do clamour for screenshots...
[14:57:57] * scanline agrees with hunger's comment
[14:58:21] <stefan> hunger: well, that doesn't change anything. I don't make milestones because I want to show anybody 'outside' that we are making progress. It's a measure for *insiders*.
[14:58:34] <stefan> hunger: that aren't very many these days, I admit. But well, that's life.
[14:58:38] <hunger> stefan: It's a PR issue... not important to what we do, but important to how other poeple think about fresco.
[14:58:42] zwol has quit (Remote closed the connection)
[14:58:52] <stefan> hunger: sorry, I couldn't care less about PR.
[14:58:52] <scanline> stefan: getting "outsiders" interested is the only way to get more defelopers. Mindshare does matter
[14:58:54] <njs`> If it takes a year to get visible changes, then it takes a year to get visible changes; the release schedule won't effect that. So the question is, is it better or worse to make extra releases without them...
[14:58:55] <scanline> err, developers
[14:59:21] <sdt> stefan: you can "piggyback" on gcc. but that requires patching it
[14:59:29] <njs`> I don't think that developers (that would be useful to us) care only about neat themes when they look to see if progress is being made :-)
[14:59:38] <sdt> the developers are somewhat resistant to making the parse tree available easily
[14:59:44] <hunger> njs: Agreed. The releasecycle has little influence on what we do anyway.
[14:59:49] <stefan> njs`: exactly. And I think that extra releases don't matter to anybody. Who noted that M2 was done anyways ? Those who contributed did, (almost) nobody else. That's fine !
[14:59:51] <nicholas> Exactly. We need to build core feature set. Hence things like Paths and Fonts.
[14:59:55] <scanline> njs`: well, there's that... but at the moment, it's not obvious there's any progress at all based on the web site
[14:59:58] <sdt> because some of them think that proprietary software will then steal the parser.
[15:00:01] plfiorini has joined #fresco
[15:00:21] <njs`> stefan: well, yes, that's largely because we suck and never announced it anywhere :-)
[15:00:34] <scanline> however, pretty themes and such that would interest the average person are more likely to get fresco mentioned to developers that would be useful
[15:00:41] <nicholas> Indeed. We should've posted it to fresco-announce for God's sake! That's what it's there for~!
[15:00:45] <stefan> hunger: I don't agree. Knowing that a release is due in about three weeks does create some pressure to finish things.
[15:00:49] <stefan> hunger: at least for me.
[15:01:20] <hunger> stefan: Hmmm... that's a argument.
[15:01:28] <stefan> hunger: that's *the* argument.
[15:01:33] <nicholas> :-)
[15:01:43] <stefan> hunger: well, not the pressure, but the need to align things, prioritize tasks, etc.
[15:02:02] <stefan> hunger: that's what is usually called 'planning' :-)
[15:02:17] <hunger> stefan: You are getting organized again! ;-)
[15:02:39] <hunger> stefan: I wish I'd be half as organized as you are! Maybe I'd get something done then.
[15:02:44] <njs`> scanline: how many developers have your pretty themes gotten you, btw? :-)
[15:02:53] <stefan> plfiorini: do you think you'll be able to look into the python stuff in the near future ?
[15:03:22] <plfiorini> stefan: no i don't - i'm too busy
[15:03:26] <scanline> njs`: hard to tell.. I actually don't know how most of the people that contribute to picogui heard about it
[15:03:28] <stefan> ok
[15:03:42] <stefan> sdt: what about you ?
[15:03:45] <stefan> hunger: and you ?
[15:03:46] <plfiorini> stefan: i am sorry :(
[15:03:46] <stefan> :-)
[15:03:55] <hunger> stefan: I have time on my hands right now.
[15:04:07] <stefan> hunger: ok. Any plans ?
[15:04:07] <hunger> stefan: Dunno for how long, but I got some now.
[15:04:21] <hunger> stefan: I'd like to find those redrawing bugs.
[15:04:24] <nicholas> hunger: be careful how you phrase that, or you'll be getting my bug list. :-)
[15:04:37] <hunger> stefan: ... which is a very depressing job:-(
[15:04:47] * sdt looks up
[15:05:03] <hunger> stefan: Then I urgently need to redo Babylon/bidir stuff in the TextBuffer.
[15:05:05] * sdt is busy till end of april
[15:05:17] <sdt> and then around end of may (wedding....)
[15:05:24] <stefan> sdt: what about the summer ?
[15:05:37] <hunger> sdt: Is it you getting married?
[15:05:39] <sdt> in the summer I should have more time. I'll be working
[15:05:41] <sdt> hunger: yes
[15:05:47] <hunger> sdt: Congratulations!
[15:05:50] <sdt> thanks :)
[15:05:55] <njs`> sdt: congrats
[15:05:55] <stefan> sdt: define 'should' :-)
[15:06:30] <sdt> stefan: well, I'm hoping to. but you never know what might come up.
[15:06:42] <stefan> sdt: indeed
[15:06:42] <sdt> I'll certainly have much more time than I do now :)
[15:07:06] <stefan> sdt: well, that doesn't mean much, at least not to us outsiders :-)
[15:07:50] <sdt> heh. well, right now I probably shouldn't even be having this conversation
[15:10:31] <nicholas> sdt: hypothetically, if you have more time to spend on Fresco, which part of Fresco gets the attention?
[15:10:35] <stefan> nicholas: do you want to create a task for the Path stuff ?
[15:10:39] <nicholas> stefan: ok
[15:11:15] <chrisime_> hunger, isn't there a v0.5 of synopsis available?
[15:11:28] <hunger> chrisime_: Ask stefan, I don't know.
[15:11:30] <stefan> chrisime_: not yet. It's planned.
[15:11:46] <stefan> chrisime_: it isn't missing much, just some cleanup and documentation.
[15:12:13] <chrisime_> stefan, i read the docu
[15:12:20] <chrisime_> there's so much to configure
[15:12:24] <nicholas> stefan: should I just adopt task61?
[15:12:25] <chrisime_> where should i start now ;)
[15:12:48] * chrisime_ wants to get rid of doxygen
[15:13:27] <sdt> nicholas: right now, I think I'd like to work on the coordinate stuff
[15:13:34] <sdt> because it's a little embarrassing.
[15:13:35] <nicholas> sdt: yay! :-)
[15:14:00] <sdt> and I don't think I know enough fresco to do much more at this moment :)
[15:16:45] <nicholas> ok, so I guess that covers M3 and part of M4!
[15:16:56] <stefan> nicholas: no, I'd suggest a new one.
[15:17:06] * nicholas hears the drum roll.
[15:17:23] <stefan> nicholas: yeah.
[15:17:45] <nicholas> stefan: then which is more important? the new one or task61?
[15:17:55] <stefan> nicholas: I'll try to get sxr up and running, try to generate tutorial pdfs on purcel
[15:17:58] <stefan> nicholas: the new one
[15:18:31] <stefan> nicholas: I only added task61 to get to the OpenLook style. But I could do that with a better path API, too.
[15:19:08] <nicholas> stefan: ok, it's task139
[15:19:26] <stefan> nicholas: and I'd like to get hte daVinci stuff a *bit* usable, for example make objects selectable (and manipulatable), and save and load the stuff into svg.
[15:19:45] <stefan> nicholas: fine. I'll add it to M3
[15:22:11] <nicholas> ok. Is there a task for the coordinate system stuff?
[15:24:06] <stefan> nicholas: well, that should be a bug first, no ?
[15:24:16] <nicholas> hehehe :)
[15:24:19] <nicholas> stefan: if you say so.
[15:25:07] <stefan> nicholas: I'm serious: a task is good if there is some project to track. But this is a bug, i.e. there isn't much to be done, beside finding the spot where the wrong computation is done.
[15:25:32] <nicholas> stefan: hm? no, you have to change every instance of a coordinate in the widgetkit!
[15:25:42] <stefan> nicholas: well, there is: once the bug is fixed, all the code that hardcodes sizes needs to be adjusted.
[15:25:46] <stefan> nicholas: yeah
[15:26:14] <nicholas> stefan: actually, I should've realized that there already is such a task: task138.
[15:26:30] <nicholas> stefan: of course, we can still argue that it should've been a bug. :-)
[15:26:54] <stefan> sdt: do you know (by chance) anything about posix rwlocks ?
[15:27:00] <sdt> stefan: sorry, no
[15:27:40] <stefan> I wrote a test but that behaves wrong, so I'm wondering whether linux' implementation is buggy...
[15:30:38] <nicholas> stefan: are we done with the first item on the agenda?
[15:31:27] <stefan> nicholas: looks so, yes.
[15:31:33] <nicholas> stefan: what's left?
[15:31:46] <nicholas> stefan: just my Q&A period?
[15:32:00] <stefan> nicholas: heh
[15:32:29] <stefan> nicholas: well, do you want to talk about 'quo vadis' ?
[15:33:07] <nicholas> ... quo vadis?
[15:33:31] <nicholas> "whither are you going?"
[15:33:32] <nicholas> sure.
[15:33:41] <stefan> nicholas: I'd like to see how the path stuff comes along. It may shift the way we look at fresco quite a bit. Oh, and I'd like to look into OpenSceneGraph. They do quite advanced stuff, and it would be interesting just to ponder about how to use one within the other.
[15:34:05] <nicholas> stefan: Yes indeed. The scene graph core, from Fresco, looks very nice for what Fresco was--an X toolkit.
[15:34:16] <stefan> nicholas: read: the 'encapsulate the traversal' stuff...
[15:34:47] <nicholas> stefan: but I'm worried. Things like our decorators seem like really fat ways to do what should just be a call to the drawingkit->set_whatever function.
[15:35:04] <stefan> nicholas: agreed
[15:35:28] <njs`> nicholas: how should they "just be a call to the drawingkit->set_whatever function"? they're different sorts of things.
[15:35:30] <nicholas> stefan: And I'm worried that the decorators aren't tied closely enough to the rendering backend any more, and that the design was never intended to support this.
[15:35:34] <stefan> nicholas: well, or use at postscript (NeWS): it's basically a programming language.
[15:35:44] <njs`> nicholas: a decorator is declarative, calling a function is imperative.
[15:35:51] <nicholas> njs`: not really. An RGBDecorator just calls drawing->rgb().
[15:36:03] <stefan> nicholas: so I'd like to see whether the Path API will evolve into something like a tiny embedded programming languages (for a very constrained domain, I admit).
[15:36:04] <nicholas> njs`: and a lot of extra fluff at the cost of code size performance and bugs.
[15:36:24] <stefan> njs`: yeah, we all agree on that.
[15:36:29] <njs`> nicholas: well, but you can't stick a call to drawing->rbg() in the scene graph as is, because a call to drawing->rgb() is not an object!
[15:36:51] <nicholas> njs`: exactly my point. It seems that the scene graph idea is busted, at some level.
[15:36:52] <njs`> nicholas: so I don't exactly follow what you think is wrong
[15:36:59] <njs`> nicholas: ???
[15:37:08] <nicholas> njs`: you heard me correctly.
[15:37:19] <njs`> nicholas: no, I didn't, unless what you're saying makes no sense :-)
[15:37:42] <njs`> nicholas: what's wrong with the scene graph idea?
[15:37:49] <nicholas> stefan: well, we could just define our own language for everything. OpenGL is going down that path. PostScript is already there. But do we really want to do another one? What specifications are we even looking for? Maybe we should say that Fresco is like TeX with GUI components?
[15:38:14] <njs`> TeX is a pretty sucky language, as languages go :-)
[15:38:27] <nicholas> njs`: the Graphics in the scene graph know too little about the content they're charged with rendering, and too little about the medium they're rendering to.
[15:38:32] <hunger> njs: It's not really meant to be a programming language.
[15:38:35] <nicholas> njs`: well, I wouldn't dare keep the syntax. :)
[15:38:43] <njs`> hunger: I understand. It
[15:38:54] <njs`> 's still a pretty sucky language
[15:38:58] <stefan> nicholas: yes. Well, I guess it's a matter of granularity / domain.
[15:39:22] <stefan> nicholas: defining a highly specialized language for a very well defined (small) domain is fine.
[15:39:25] <njs`> nicholas: in what sense? can you explain what more they should know, and how this is connected to wanting procedures to be data?
[15:40:07] <nicholas> stefan: can we just repair the problem by allowing the graphics to query the traversal/drawingkit for more information about the rendering device? Allow our WYSIWYG design to be default, but allow "fancy" activities where warrented?
[15:40:33] <nicholas> njs`: scanline said it best: "fresco separates device from look rather than separating presentation from content"
[15:40:57] <njs`> drawing probably does need more information about the device being rendered too -- you need "level of detail" info, for one thing, when doing curves. And damage needs to care about resolution too.
[15:41:03] <hunger> nicholas: I see the scenegraph as a description of what is on the screen.
[15:41:07] <nicholas> njs`: if the content is an email compose window, it should look like one on a desktop or on a PDA.
[15:41:10] <stefan> njs`: I think the issue is not imperative vs. functional but instead of fine-grained scene graph nodes should be, or in general, what the object model for sg nodes is. Is the scene graph to be accessed concurrently ? Is it to be location transparent ?
[15:41:11] <scanline> ooh, people are quoting me :)
[15:41:12] <nicholas> hunger: indeed, that it is.
[15:41:31] <njs`> nicholas: what scanline says is silly, though. those are orthogonal domains.
[15:41:36] <nicholas> scanline: indeed. it's an excellent quote. :)
[15:41:39] <hunger> nicholas: That's below the content area anyway.
[15:41:46] <stefan> nicholas: no, I'm strictly against such an approach. Querying the renderer for specifics breaks the encapsulation.
[15:41:56] <stefan> nicholas: or else we are back in X
[15:42:01] <nicholas> stefan: why is that encapsulation manditory?
[15:42:17] <nicholas> stefan: well.