[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.
[15:42:31] <stefan> nicholas: I don't understand that quote (from scanline)
[15:43:03] <stefan> nicholas: well, it's not mandatory, but I think the current culture around X just proves what's wrong:
[15:43:04] <njs`> nicholas: separating presentation from content is a nice thing; I think core Fresco would be an excellent thing to build such a layer on :-)
[15:43:21] <stefan> nicholas: you hand over responsibility to clients to use the insight they get by querying the renderer.
[15:43:25] <hunger> nicholas: I'd prefer to add some layer above the scenegraph then compromising the encapsulation.
[15:43:35] <stefan> nicholas: we shouldn't do that, that knowledge is best kept inside the server.
[15:43:56] <nicholas> stefan: so is the server responsible for graphical layout decisions?
[15:44:16] <stefan> nicholas: beside, you have to define what 'content' mean. The 'content' of one domain could well be the 'look' of another.
[15:44:54] <stefan> nicholas: like what ? as much as 'device space' is involved, yes, of course.
[15:45:10] <nicholas> njs`, hunger: well, yes. But then we might have to worry about the toolkit-on-X problem. Your layer isn't much use if some people bypass it.
[15:45:19] <njs`> scanline: and people are attacking your quote, too. you're famous! :-)
[15:45:23] <scanline> wow :)
[15:45:36] * stefan grins
[15:45:38] <nicholas> stefan: well, for a PDF I understand how the look is the content. That's what Fresco, today, allows for.
[15:45:48] <nicholas> stefan: Graphics designers will love it.
[15:45:50] <njs`> nicholas: well, we have that hole already, in that someone can always use the ToolKit to create their own widgets.
[15:46:08] <nicholas> njs`: or clientside Graphics.
[15:46:17] LordVan changes name to LV|off
[15:46:17] <nicholas> njs`: should we support client side Graphics?
[15:46:21] <njs`> nicholas: but having a safety valve of that sort is probably important, even as we try to minimize the need for it.
[15:46:25] <stefan> exactly. It's a matter of choosing the right abstraction. Aka, whether to use WidgetKit or TasketKit (say)
[15:46:29] <njs`> nicholas: you know my opinion on that :-)
[15:46:56] <nicholas> njs`: I don't think we should like them, but I can still imagine applications that can't live without them.
[15:48:17] <nicholas> stefan: so if we keep the Graphics separate from the rendering backend, through a generic interface... should we provide generic Models that our client must use to interface with them?
[15:48:26] <hunger> nicholas: Agreed. They'll generate something like what we have describing our widgets with htose building blocks.
[15:48:26] <njs`> nicholas: you can
[15:48:38] <njs`> 't get reasonable performance with client-side graphics. I just don't see it.
[15:48:52] <nicholas> stefan: for example, in Java, the JTable requires that the client provide a TableModel for the JTable to use.
[15:49:00] <hunger> nicholas: We should have something to allow for changing kits (especially widgetkit) at runtime above that,
[15:49:00] <stefan> nicholas: why do you need generic models to interface with graphics ?
[15:49:19] <nicholas> stefan: so that the Graphics know what content they're responsible for laying out, so that they can do so intelligently.
[15:49:51] <stefan> nicholas: can't that be covered with composition ?
[15:50:00] <stefan> nicholas: (as a paradigm, I mean)
[15:50:01] <nicholas> hunger: ok, so a SwitcherKit that maintains what widgets were constructed, and is prepared to switch to a different kit at any time?
[15:50:16] <stefan> nicholas: ???
[15:50:18] <nicholas> stefan: that's an interesting statement, unless I forget what composition is. How so?
[15:50:36] <stefan> nicholas: well, isn't that just our mantra ?
[15:50:38] <hunger> nicholas: I'd prefer to have some support for that inside the server. Dunno how a Kit is supposed to figure out how to change other kits.
[15:50:53] <nicholas> stefan: I thought "lightweight decorators allow for code reuse" was our mantra. :)
[15:51:06] <nicholas> hunger: ok.
[15:51:28] <stefan> nicholas: individual graphics are primitive, but you get complexity by building the SG in specific ways that reflect the state of your application.
[15:51:30] <hunger> nicholas: PicoGUI uses a "widgetGraph"... soemthing like that.
[15:51:38] <nicholas> hunger: Right. Like that.
[15:52:22] <hunger> nicholas: So far I'd prefer to concentrate on making the scenegraph work.
[15:53:31] <nicholas> stefan: So the client makes all decisions for how its GUI is composed.
[15:53:52] <stefan> nicholas: not all, but the part that reflects the application's state.
[15:54:09] <stefan> nicholas: (the rest is configurable and only reflects the currently selected 'style'
[15:54:11] <stefan> )
[15:54:11] <hunger> nicholas: I was thinking wether it would be possible to shortcuircit CORBA using the data from the GraphicDictionary for serverside graphics. That could reduce the overhead for the decorators quite a bit that seems to be worrying you.
[15:54:35] <nicholas> hunger: I've lost sight of what the gain of it is.
[15:54:36] <stefan> hunger: how that ?
[15:54:40] <njs`> is it the traversal cost that worries you about decorators? it's really not that high, I think.
[15:54:42] <nicholas> Wasn't it supposed to be extended code reuse?
[15:54:47] <nicholas> and how big is Fresco now?
[15:54:57] <stefan> hunger: the traversal still traverses Graphic_ptrs, not ServantImpls...
[15:55:00] <nicholas> and wasn't more code reuse supposed to reduce bugs over all?
[15:55:15] <nicholas> and why are we spending so much time tracking down our bugs?
[15:55:30] <nicholas> Wasn't CORBA supposed to save us from creating a new client binding for every language we'd like to support?
[15:55:36] * stefan is *very* curious to try fresco with the new thread library (glibc 2.3), and measure performance
[15:55:42] <hunger> stefan: Basically a "shadowgraph" using GraphicImpl* instead of the Graphic_ptr (or falls back to the 'normal SG" if the graphic is remote).
[15:55:51] <nicholas> How come we only support C++, have broken python support and maybe Java?
[15:55:53] <njs`> nicholas: umm, the fact that we have bugs does not prove that we have a bad architecture. _everyone_ spends time tracking down bugs.
[15:56:02] <stefan> hunger: sounds horribly memory hungry
[15:56:24] <stefan> nicholas: heh, you sound so negative...:-)
[15:56:29] <hunger> stefan: It probably is. But then I see memory as less a problem then speed right now.
[15:56:40] <nicholas> stefan: I'm trying to thwack against the tree *really hard* and see what falls out. :-)
[15:56:54] <njs`> nicholas: in Fresco's case, I get the impression that for a long time, nobody ever bothered with bugs... the bugs we fix now have been accumulating for literally years :-)
[15:56:55] <stefan> hunger: I don't believe your GraphicDictionary is a solution for anything than debugging
[15:57:06] <hunger> nicholas: Anyway: I just love the idea of decorators.
[15:57:12] <nicholas> njs`: that's a good point. I'll take it. :)
[15:57:33] <nicholas> hunger: But would you object to more complicated Graphics that didn't use Decorators?
[15:57:52] <hunger> stefan: We'll see. It's a bit of information, nothing more, nothing less. I'm just trying to put it to good use.
[15:57:54] <njs`> nicholas: I'm not going to argue with the CORBA points; I'm personally pretty convinced that CORBA needs to go altogether :-). But not ready to argue it in this channel yet.
[15:58:01] <stefan> nicholas: honestly, I love to shake the tree with you. But I still have some ideas of what is fundamentally right and what isn't :-))
[15:58:14] <hunger> nicholas: Yes.
[15:58:35] <nicholas> njs`: well, let's do it now. :)
[15:58:38] <hunger> nicholas: The idea of having simple things and building more complex graphics out of those is very important to me.
[15:58:53] <nicholas> What do we want in a communications protocol? Asynchronous communication? Bindings that use C++ STL?
[15:59:05] <nicholas> hunger: hm.
[15:59:16] <nicholas> hunger: I agree, that's what OO programming is about. That's why we have libraries.
[15:59:39] <njs`> nicholas: I'm not sure, though I've been putting a fair amount of thought into it.
[15:59:52] <hunger> nicholas: Many people seem to think OO is about inheriting stuff to make even more complex stuff:-)
[15:59:53] <nicholas> hunger: but there's something plain wierd about the Fresco SG. I'm not willing to make a final judgement or anything.
[16:01:02] <nicholas> njs`: I mean, if we were to design a comm protocol from scratch today, how many features would it share with CORBA? How many of them would be things that omniORB doesn't offer us?
[16:01:20] <nicholas> njs`: I'm just concerned that we've got a bad fit already, as of today.
[16:01:20] <hunger> nicholas: I'm not trying to stop you. Please keep arguing, that's a very valuable contribution to fresco IMHO.
[16:01:30] icebird has joined #fresco
[16:01:41] <nicholas> hunger: well, let's suppose that I'm playing the devil's advocate. :)
[16:02:07] <nicholas> hunger: and nicholas_evil has decided that the SG is a lousy was of describing object relationships.
[16:02:37] <hunger> nicholas: What is a better way according to nicholas_evil then?
[16:02:50] <njs`> nicholas: eh, "design a comm protocol from scratch today" is not the question, so much as "design a comm protocol that's a good fit to our problem domain". If you want a modern CORBA, use ICE :-) But I don't think we want a modern CORBA, exactly.
[16:02:51] <hunger> nicholas: Having komplex graphics?
[16:02:59] <nicholas> hunger: because the colour that I want the next object to be drawn in is a property of that object.
[16:03:17] <nicholas> hunger: not a wrapper around it.
[16:03:25] <njs`> oops, there's a talk now I should go to
[16:03:30] nicholas_devil has joined #fresco
[16:03:34] <njs`> back later
[16:03:35] <nicholas_devil> someone called me ?
[16:03:40] <nicholas> njs`: oh. bye.
[16:03:40] <hunger> nicholas: With that argumentation we end up with something like QT pretty fast.
[16:03:42] nicholas_devil has quit (Client Quit)
[16:03:55] <njs`> nicholas_devil: so you'll be handling the BSD port?
[16:04:00] <nicholas> hunger: what's wrong with that? Qt is quite popular.
[16:04:12] * nicholas notes that nicholas_devil isn't me.
[16:04:23] <njs`> vintage fresco is closer to what nicholas is arguing for than modern fresco, incidentally.
[16:04:24] <hunger> nicholas: I don't want to redo something that's allready there.
[16:04:27] <stefan> njs`: did you have a look into ice ?
[16:04:52] <njs`> stefan: yes, I can tell you all about it. It's GPL, though, so probably not useful to us directly.
[16:04:55] <hunger> nicholas: And the decorator concept is pretty consistent IMHO.
[16:05:03] <nicholas> njs`: vintage fresco seems a better fit for the Fresco design. In fact, sometimes I wish Java was closer to vintage Fresco.
[16:05:15] <hunger> nicholas: I admit that it is slower then just having a call to the DK.
[16:05:16] <stefan> njs`: I noted that Michi Henning is working on it.
[16:05:22] <nicholas> hunger: you mean that we apply it consistently throughout our code?
[16:05:30] <njs`> stefan: yes, it's quite nice, for what it is.
[16:05:44] <hunger> nicholas: That and it is the one way to change a color.
[16:06:13] <hunger> nicholas: It's not button->foreground(), label->color(), ...
[16:06:39] <nicholas> hunger: that would make much cleaner looking C++ code.
[16:07:31] <nicholas> hunger: and either way, the core is just a Color object, but why the entirety of wrapping the Color object in a Graphic?
[16:07:33] <hunger> nicholas: Maybe. But that's not what I am after.
[16:08:19] <nicholas> hunger: further, what about Graphics that have complex modifications? You don't want to apply a simple rotation to a spreadsheet (a table with headings) because you wouldn't want the text to get rotated.
[16:08:50] <hunger> nicholas: You need to have one object type to make C++ happy.
[16:09:05] <nicholas> hunger: but maybe that's just me being wrong-headed; after all, rotating the view and rotating the content are entirely different. (For no good reason I can find.)
[16:09:33] <hunger> nicholas: At the SG-level I'm mostly concerned that things are possible, not that it's trivial for a programmer to do whatever he wants to do.
[16:10:16] <nicholas> hunger: well, right now it's possible for any Graphic to do anything that the DrawingKit interface allows. Remember that any Graphic can reset the transformation and do whatever it likes.
[16:10:36] <hunger> nicholas: That's not good, agreed.
[16:10:38] <nicholas> hunger: then there's the question of what a well-behaved Fresco Graphic should be doing, which deserves documentation.
[16:11:03] <hunger> nicholas: Agred again. But that won't change with making graphics heavier, will it?
[16:11:43] <nicholas> hunger: But should it be disallowed? Maybe we should force clipping to the extent. But some Graphics deserve changing the transformation in strange ways before they pass it to their clients. A 90-degree rotated table was my first example; it should un-rotate the text labels before traversing them.
[16:11:56] <nicholas> hunger: no it won't.
[16:12:30] <nicholas> hunger: although, finding a way to force clipping to the extent such that the Graphic can't reset it would involve a chunk more complexity on the part of the DrawingKit.
[16:12:39] <hunger> nicholas: Maybe the user wants the text rotated too? You cannot just automate this anyway.
[16:12:52] <nicholas> hunger: user? we're talking about the developer.
[16:12:58] <nicholas> hunger: users don't create Graphics.
[16:13:25] <hunger> nicholas: Well, the developer will need to handle both cases if he wants his users to be happy.
[16:14:35] <hunger> nicholas: As long as both is possible I'm happy.
[16:14:50] <hunger> nicholas: What we need to talk about is the DrawingKit's interface.
[16:15:13] <nicholas> hunger: well. At the moment, we'd need to: 1. create the text labels. 2. wrap them in an un-rotating wrapper. 3. put those wrappers in the table.
[16:15:17] <hunger> nicholas: Not only to make clipping possible but also to allow for caching areas.
[16:15:27] <nicholas> hunger: doing it the other way, where text gets rotated, just leave out step two.
[16:15:41] <nicholas> hunger: well, nobody knows how areas will be cached.
[16:15:50] <nicholas> hunger: actually, Fresco is already very good at that.
[16:15:55] <hunger> nicholas: It is?
[16:16:17] <hunger> nicholas: It gets considerably slower the more windows you open.
[16:16:21] <nicholas> hunger: iff you assume that the output device can save a rectangular area of pixel-space, yes.
[16:17:09] <nicholas> hunger: hopefully we aren't drawtraversing unmapped windows... ;-)
[16:17:38] <hunger> nicholas: How much work is it to generate a table with rotated text lables in QT or GTK?
[16:17:49] <hunger> nicholas: I doubt that it is much less...
[16:18:23] * stefan notes that another thing to work on is a DamageManager. Something to port over from Fresco98, actually.
[16:18:47] <nicholas> hunger: well it makes more sense to most programmers to say, "create me the table, now setDoRotateContents(true) (or false)" than it does to have all this wrapper stuff.
[16:19:05] <nicholas> hunger: even if we grant that Fresco can do everything GTK, Qt and Java can do
[16:19:13] <nicholas> hunger: we still have a *terrible* interface!
[16:19:34] <hunger> nicholas: Agreed again. But I don't hink it's terrible because of the idea of decorators.
[16:19:56] <nicholas> hunger: then why is it?
[16:20:21] <hunger> nicholas: I keep looking for the kits to generate the graphics I need... but that's just an implementation detail.
[16:20:30] <stefan> nicholas: what do you find 'terrible' ? The style ?
[16:20:59] <hunger> nicholas: As I see it we are working to get a flexible way to describe generic things.
[16:21:23] <nicholas> stefan: basically, yes. I find it horribly counter-intuitive to create my "x" then say, now create a colouring-decorator and putting my "x" in the constructor. All I really wanted was x->set_color(rgb);
[16:21:34] <hunger> nicholas: That's fairly low-level or it wouldn't be as generic. We need some layer above that.
[16:22:00] <stefan> nicholas: hmm, that's because you are trained that way.
[16:22:05] <hunger> nicholas: We used to have "Moscow" for all that high-level stuff.
[16:22:14] <nicholas> hunger: so it's possible-but-ugly without this layer, and nicer with another layer? Too bad that higher layer won't be available in every language like CORBA is.
[16:22:26] <hunger> nicholas: Why not?
[16:22:43] <hunger> nicholas: Write a "tablekit" that does all the low-level magic for you.
[16:22:55] <nicholas> hunger: because I thought it was going to be a client-side library, but I guess I was wrong. :)
[16:23:01] <nicholas> stefan: so indeed I am.
[16:23:27] <hunger> nicholas: You are not using the ToolKit to draw your buttoms either, are you?
[16:23:34] <nicholas> stefan: but isn't that the way the language designers intended?
[16:23:49] <nicholas> hunger: no.
[16:23:52] <nicholas> hunger: I see.
[16:24:16] <nicholas> hunger: can't really argue there.
[16:24:31] <nicholas> hunger: except that CORBA/C++ not using the STL is, uh, unfortunate.
[16:24:42] plfiorini changes name to pl_afk
[16:24:44] <hunger> nicholas: My concern is making things possible now. That's bound to be rather low-level stuff.
[16:24:49] <hunger> nicholas: I fully agree.
[16:25:15] <hunger> nicholas: But I don't see anything else we could use without sacrifycing something.
[16:26:22] <nicholas> stefan: when I look at a refmanual, I see which method call takes what, and that tells me what I need to create first. It shows me how to build my object. (Ie., JFrame.setJMenuBar takes... a JMenuBar! Which has a method that takes a JMenu! Then a JMenuItem! and that takes a simple String and an ActionListener. Well, I can see what's going on from there. But with Fresco? Realize that we've basically destroyed types
[16:26:26] <nicholas> uld get lost.)
[16:26:30] <stefan> nicholas: sorry, what language are you talking about ?
[16:26:37] <nicholas> stefan: Java.
[16:26:52] <stefan> nicholas: oh
[16:27:08] <stefan> nicholas: I was talking about building the scene graph using decoration
[16:27:21] <nicholas> stefan: mmhmm.
[16:27:30] <stefan> nicholas: there you basically need to understand the kit interface
[16:28:25] <hunger> nicholas: Well, that's the idea, isen't it? A Decorator is pretty generic and can go around anything.
[16:28:32] <stefan> nicholas: and I could well see a method widgetKit::create_label(const Unistring &, const Color &) if that's desired. That d'oesn't prevent it being implemented with decorators.
[16:28:42] <hunger> nicholas: I see that as a advantage (consistency).
[16:29:06] <nicholas> stefan: no it doesn't. Maybe we should think about that, improving our interfaces so that they're more developer-friendly.
[16:29:24] <nicholas> stefan: what they do under the hood doesn't matter as long as it works. And Decorators are good, aren't they?
[16:29:46] <hunger> nicholas: That's a higher-level issue again, isen't it?
[16:29:56] <nicholas> hunger: It's an important issue.
[16:30:09] <hunger> nicholas: I agree in principle.
[16:30:37] <hunger> nicholas: It's an very important issue once we have the functionality to actually support some application.
[16:31:14] <hunger> nicholas: Till then it's just a convinience thing for our demos:-)
[16:31:20] <nicholas> hunger: We have most of the functionality. What are we missing? curves? font selection? gradients? Anything an application author can't live without?
[16:31:39] <chrisime_> stefan, got a short question
[16:31:58] <chrisime_> stefan, i got synopsis running, it works but in the end there's an error
[16:32:00] <hunger> nicholas: We have no menus yet, so we don't need to make those easy to use yet.
[16:32:26] <hunger> nicholas: fonts are a big issue too, of course. Without those we can't do too much.
[16:32:33] <nicholas> hunger: well, by your principle, we just need to implement the DesktopKit---transient was it?---and call menus done.
[16:32:55] <hunger> nicholas: Basically yes:-)
[16:33:09] <nicholas> hunger: and how do you feel about implementing it? :-)
[16:33:19] <hunger> nicholas: We should start at some conviniece things at that point though.
[16:33:37] <hunger> nicholas: Not too well, because I'm a clueless idiot.
[16:33:49] <nicholas> hunger: please. So am I. :-)
[16:34:01] <nicholas> mm, DesktopKit::pulldown I think
[16:34:29] <nicholas> What's funny is that there's already code there. It looks complete too.
[16:34:32] pl_afk changes name to plfiorini
[16:35:05] <nicholas> Indeed, there's an entire Pulldown.cc.
[16:35:27] <stefan> chrisime_: ?
[16:36:22] <stefan> nicholas: well, the point about pulldowns is (as I have repeatedly pointed out) that there is no working focus management
[16:36:59] <nicholas> stefan: oh right. Hm :(
[16:37:05] * nicholas has dinner now, actually.
[16:37:31] <stefan> nicholas: ok, let's call it an end and continue this another time. It's starting to get a bit out of hand anyways
[16:37:52] <hunger> stefan: Something else: Have you thought about how we can "stack" contorllers?
[16:38:16] <hunger> stefan: Like "raise window when titlebar is clicked, move it when dragged"?
[16:38:55] <stefan> hunger: what do you mean by 'stack' ? As in 'decorate' ?
[16:39:18] <hunger> stefan: I'd prefer the decorator approach.
[16:39:32] <hunger> stefan: I don't knwo wether it will work out though,.
[16:39:59] <hunger> stefan: How can we have one area that reacts to clicks and draggs?
[16:40:31] phoen][x has joined #fresco
[16:40:38] <hunger> stefan: Who is respnsible to figure out wether a event is a drag or a click?
[16:40:48] <stefan> hunger: that's quite hard. You need to *interpret* events, or gestures more generally.
[16:41:01] * phoen][x says aloha
[16:41:06] <hunger> stefan: That's why I'm asking you:-)
[16:41:09] <hunger> phoen][x: Hi!
[16:41:26] <phoen][x> heyas hunger and everyone else
[16:41:55] <stefan> hunger: as I said, event handling and focus management are two issues that are very hard to get right. I'd like to work on that, but this is a complex issue and it will take time.
[16:42:04] <hunger> stefan: Having a drag-click controller would be very ugly IMHO. But I couldn't think of an other way to do it.
[16:42:28] <stefan> hunger: well, chain-of-responsability comes to mind.
[16:42:44] <hunger> stefan: Except having controllers in a "controllerchain" talk to each other.
[16:42:57] <stefan> hunger: but as this is about gestures ('composite events'), you can't pass individual events, but need a full event sequence.
[16:43:05] <stefan> hunger: 'talk to each other' ?
[16:43:15] <stefan> hunger: no, just pass an even sequence down if they can't handle it.
[16:43:58] <hunger> stefan: Like the first controller (buttom) sees a move and passes the complete event that it has seen so far on to the dragger?
[16:45:08] <stefan> hunger: yes, if it is a 'move' and the button can't handle a 'move'.
[16:45:19] <stefan> hunger: s/complete event/gesture/
[16:45:34] <stefan> hunger: (just to stick to terminology :-)
[16:45:43] <hunger> stefan: Sorry.
[16:46:16] <stefan> hunger: well, 'gesture' is what I used for that. I'd like to keep that, not because it's the best term, but because it's more precise than 'event' or 'event sequence'.
[16:47:46] <hunger> stefan: That's fine with me.
[16:50:10] * nicholas has returned
[16:50:20] <nicholas> Has anyone got an IRC log of this?
[16:51:51] <hunger> Aehm... maybe...


NickFirst occurence atNumber of messages