Session Start: Sat Jan 10 22:02:26 2004
Session Ident: #LainOS
* Logging #LainOS to 'LOGS\Otherside\#LainOS.log'
([22:00:45] @Neovanglist|Work) topic.push("Meeting Start");
([22:00:57] hunger) minddog: I can give a synopsis... I hope it will be brief;-)
([22:01:09] @minddog) hunger: refine it to under 5 minutes maybe?
([22:01:10] @minddog) =)
([22:01:58] hunger) Fresco is a project that's been around for ages. It's predecessors reach back for about 18years now.([22:02:43] hunger) It always was a project in research institutions and that shows. I love the ideas behind the project:-)
([22:02:43] hunger) It always was a project in research institutions and that shows. I love the ideas behind the project:-)([22:03:23] hunger) The basic idea is to not use pixels but vector graphics, building up the complete GUI by combining and arranging simple graphics.
([22:03:36] hunger) A bit like lego;-)
([22:04:16] hunger) Let me throw around a couple of buzzwords: It's OO, network transparent, language transparent,
([22:04:29] hunger) 3d capable, vector based,
([22:04:50] hunger) modular, configurable yet garantees a cionsistent user experience,
([22:05:09] hunger) it is supposed to be scaleable (even though it has problems on my PDA;-)
([22:05:18] @Neovanglist|Work) hunger: taking screencaps of Fresco on BSD as we speak
([22:05:22] @minddog) need some handheld help?
([22:05:54] hunger) Should I explain the technical details a bit?
([22:06:03] @Neovanglist|Work) hunger: please do
* ([22:06:11] @minddog) hopes others are listening =)
[22:06:32] * @Xuric is
([22:06:37] hunger) OK: The central concept is a so called scenegraph.
([22:07:18] hunger) Lets simplify and assume that to be a tree of graphics:
([22:07:37] hunger) You take a line (onegraphic) and a letter (
([22:08:21] @Neovanglist|Work) http://neovanglist.thefrontnetworks.net:8080/Fresco-FreeBSD.png
([22:08:32] hunger) You take a line (graphic A) and a letter (graphic B) and some other graphic that arranges its children (C) and arrange them:
([22:08:39] hunger) C--->A
([22:08:49] hunger) +-->B
([22:09:03] hunger) Damn... this is hard to explain on IRC!
([22:10:34] @minddog) C contains A & B ?
([22:10:47] hunger) http://www.tu-chemnitz.de/linux/tag/lt5/vortraege/folien/fresco/img17.html
([22:10:48] @minddog) or A contains B & C
([22:10:59] hunger) That slide has a simple scenegraph
([22:11:24] @minddog) ahhh familiar hbox =)
([22:11:34] hunger) There is a hbox at the top, which is a graphic that arranges it's children next to each other, etc.
([22:12:18] hunger) Basically you take a couple of simple graphics, use some other graphics to arrange them, building up more and more complex graphics.
([22:12:27] @minddog) very familiar concepts from ASTs
([22:12:46] hunger) minddog: Yeap. Fresco has lots of familiar concepts:-)
([22:12:47] @minddog) do you have some sort of engine that generates and reads these trees
([22:13:11] @minddog) any abstraction on that level?
([22:13:16] hunger) minddog: Not yet.
([22:13:31] hunger) minddog: The applications build up those trees for their GUI.
([22:13:49] @minddog) Then how are the trees interpreted/walked ?
([22:14:17] hunger) minddog: The server stores that tree.
<§> [22:14:52]  #LainOS:  zero_one has quit: Ping timeout
([22:15:07] hunger) It walks that tree at rendertime and generates the output from it.
([22:15:24] @minddog) the client handles this through a stream from the server, i assume
([22:15:46] hunger) Client and server communicate through corba.
* ([22:16:10] @minddog) keeps reminding himself , corba
([22:16:32] hunger) So the client calls a method on an factory object to have a graphic generated and then calls another method on another graphic to append the new one to the it.
([22:17:19] hunger) The scenegraph lives in the server's address space so that the CORBA overhead does not weight too heavy at rendertime.
([22:18:01] hunger) That way the server always has all information needed to redraw too, so there is very little bandwith used for client/server communication.
([22:18:11] @minddog) how large is the memory in use by say an application like a web browser
([22:18:28] @minddog) whats being stored might be a better question
([22:18:39] hunger) minddog: We don't have such a big application:-)
([22:19:05] @minddog) =) maybe that needs to change
([22:19:06] hunger) minddog: Papers suggest that the memory overhead is acceptable.
([22:19:58] hunger) minddog: Fresco always was a research project. You can find lots of papers on it and similar things.
([22:20:02] @minddog) Probability of a full desktop running on a remote server and being accessed via the internet plausible with minimal bandwidth (?)
([22:20:28] @minddog) that was a run-on, but you get the gist
([22:20:29] hunger) minddog: The fresco demo takes 1.5kBit/s running remotely.
([22:20:38] @minddog) excellent
([22:21:03] hunger) minddog: That's mostly for pings to see whether the app is still alive.
([22:21:06] @minddog) I'm thinking handhelds/phones via 4G networks
([22:21:27] hunger) minddog: I had fresco installed on my PDA (Sharp Zaurus).
([22:21:38] hunger) minddog: It is *NO* fun without a FPU!
([22:21:48] @minddog) yeah, but thats ever-changing
([22:21:49] @Neovanglist|Work) all that vector uses floats
([22:21:50] @Neovanglist|Work) :P
([22:22:50] hunger) Now, all those graphics forming the scenegraph are comming from Kits: Those are dynamically loadable modules providing a collection of related graphics.
([22:23:18] hunger) There is a DesktopKit providing "Windows", a layoutkit for hboxes etc.
([22:23:39] @minddog) so what layers of drawing abstraction do you have
([22:23:49] @minddog) from actual pixel drawing to the api calling it
([22:24:09] hunger) Those implement basically all the functionality. All the server does is store the scenegraph and load kits.
([22:24:23] hunger) minddog: The API is the graphics provided by the Kits.
([22:24:45] hunger) minddog: Those are device independent, using real world units, etc.
([22:25:22] hunger) minddog: At rendertime the tree gets traversed and all graphics render themselves using a DrawingKit.
([22:25:23] @minddog) (Server) -> (Client) -> (kit) -> (SDL - screen)
([22:25:43] @minddog) the kits interpret the tree the way they want to
([22:26:01] hunger) minddog: That turns it into a devicedependent form and hands it to the HW.
([22:26:14] hunger) minddog: The kits have nothing to do with this process.
([22:26:20] hunger) minddog: Neither has the client.
([22:26:45] cinap_lenrek) kits are just factorys for objects like windows... hboxes...
([22:26:46] hunger) minddog: The server calls into the Graphic -> DrawingKit -> screen
([22:27:24] hunger) DrawingKit provides "turn into OpenGL and push it on"
([22:27:56] hunger) SDL is not really used in the GL case either: That just sets up GL.
([22:28:14] hunger) In the pixelbased case its a bit more involved, looking something like
([22:28:20] @minddog) so what is called by the client?
([22:28:28] @minddog) Doesn't is called the DesktopKit?
([22:28:33] @minddog) call rather
([22:28:36] hunger) graphic->DrawingKit->libArt->SDL
([22:28:50] hunger) minddog: The client sets up the scenegraph once.
([22:28:50] @minddog) oh I see
([22:29:14] hunger) minddog: Then it idles till the server tells it that something happened to its data.
([22:29:47] hunger) minddog: The whole thing is strictly MVC.
([22:29:48] @minddog) what you move an object, how about updating to the server?
([22:30:04] @minddog) when rather, getting tired over here
([22:30:16] hunger) minddog: Moving a window mens that it's transformation matix got changed.
([22:30:35] @minddog) will graphic report back to Client ?
([22:30:44] hunger) minddog: The server traverses the scenegraph again, using that new matrix.
([22:30:58] hunger) minddog: The client is not involved at all.
([22:31:17] hunger) minddog: s/involved/informed/
<§> [22:31:18]  #LainOS:  FireSlash has quit: Ping timeout
([22:31:28] @minddog) client is more like a read-only pipe
([22:31:41] hunger) minddog: Do you know MVC?
([22:31:49] @minddog) nope
([22:31:51] hunger) minddog: It's an old smalltalk thing:
([22:32:05] hunger) minddog: The idea is to split up an application into three parts:
([22:32:22] hunger) The model is the state of the program (the data etc.)
([22:32:41] hunger) You can then attach a View to that model that visualizes that state.
([22:32:57] hunger) Finally there are controllers that can modify the model.
([22:33:33] hunger) In the case of a color mixer applet you have a model: the color value that is currently selected.
([22:33:35] @minddog) so you have the scenegraph as the state, and views are the DrawingKit ?
([22:34:00] hunger) You attach a view to it: Some rectangle drawn in the model's color.
([22:34:15] hunger) minddog: And an controller: Some inputfield to change the color.
([22:34:28] hunger) minddog: That's how Fresco works too: The model is in the client.
([22:34:51] hunger) minddog: The View is the complete GUI.
* ([22:35:04] @minddog) gives up
([22:35:07] @minddog) ill stick to compilers
([22:35:18] hunger) As long as the model is not changed the view does not need to communicate with the model.
([22:35:46] hunger) minddog: I'm not too good at explaining things anyway... and even worse than usual at 4:30am
([22:35:50] @Neovanglist|Work) kik
([22:35:52] @Neovanglist|Work) err
([22:35:52] @Neovanglist|Work) lol
([22:36:17] @Xuric) wow
([22:36:18] @minddog) and not to mention its written in C++
([22:36:37] hunger) minddog: So what? It is language transparent;-)
([22:36:44] @minddog) not when debugging ;)
([22:37:03] hunger) minddog: There are no bugs;-)
([22:37:19] @minddog) until someone tells you that
([22:37:38] cinap_lenrek) *g*
([22:37:42] @minddog) okay cool, i understand, its just going to take some code and hacking it to set in =)
([22:37:53] @minddog) like any project
([22:37:55] hunger) minddog: You stumbled over the biggest issue with fresco by the way:
([22:38:18] hunger) !!!!!IT IS DIFFERENT!!!!!
([22:38:28] @Xuric) isn't that the idea, though?
([22:38:40] hunger) Xuric: Of course:-)
([22:38:44] @minddog) this is why i asked you to briefly explain, not possible
([22:38:48] @Xuric) lol
([22:38:53] hunger) Xuric: Why redo something that is already done?
([22:38:54] @Xuric) i guess we got the long-version then
([22:39:03] @Xuric) wow, you sound like we do :P
([22:39:10] @Xuric) ok.
([22:39:21] @minddog) make it work, make it work better
([22:39:25] @Xuric) heh
([22:39:25] hunger) But it is REALLY DIFFERENT! It takes a long time to get used to.
([22:39:36] @Xuric) from the coding-side of things, especially
([22:39:54] hunger) Xuric: The coding style is not really fixed nor implemented;-)
([22:40:11] @minddog) hunger: I'd like to see how your trees are traversed, thats probably the most interesting portion to me =)
([22:40:23] hunger) Xuric: If you have improvements that do not run counter to all we have feel free to suggest them.
([22:40:36] @minddog) hunger: have you heard of TreeCC ?
([22:40:38] @Xuric) i don't have any
([22:40:51] hunger) minddog: Check out the Traversals in Belrin/src
([22:40:54] @Xuric) from what i understand of it .. it sounds quite amazing
([22:41:21] hunger) minddog: There's a DrawTraversal for the rendering and a PickTraversal to figure out which graphic should recieve an event.
([22:41:53] hunger) Xuric: It is... muttering "this is device independent" under your breath when working on it helps by the way:-)
([22:42:12] @minddog) are all the semantics hand built?
([22:42:26] @minddog) hunger: ill check out the tree either tonight or tomorrow
([22:42:33] @minddog) ill need a bsd build from my good friend Neovanglist
([22:42:35] @Xuric) yeah.. i really like the independance
([22:42:38] hunger) minddog: Handbuild?
([22:42:50] @minddog) did you use any tools to generate the tree walking?
([22:43:04] hunger) minddog: Nope. We stole the code;-)
([22:43:07] @minddog) haha
([22:43:23] @minddog) you "borrowed"
([22:43:28] hunger) minddog: There used to be a Toolkit for X called fresco.
([22:43:42] hunger) minddog: We are officially the successor to that by the way.
([22:44:11] hunger) minddog: You might even find some rather bitrotten fresco code in XFree...
([22:44:20] @minddog) hrmm
([22:44:37] @minddog) well ill take a look at your traversal engines and do my best to break it =)
([22:45:05] hunger) OK, that's what we are offering you: A really good architecture and an environment open for new ideas.
([22:45:29] @Xuric) yeah
([22:45:31] hunger) At least I hope that we can provide the latter;-) You'll have to judge for yourself of course.
([22:45:47] @minddog) i'm sure we could get a window manager off the ground on fresco
([22:45:50] @Xuric) what i want to ask Neo and Minddog is: do you think we can use this for our project?
([22:46:08] hunger) On the other hand we do have our problems. You will need to know those too for an informed decission.
([22:46:09] @Xuric) i fully admit, it's not an issue to me, because i can't code for it :(
([22:46:26] @Xuric) from what i've heard, it sounds PERFECT
([22:46:45] @minddog) whatever gets us closer to the wired
([22:46:53] cinap_lenrek) lol
([22:46:54] @Xuric) lol
([22:47:00] @Xuric) a psyche :P
([22:47:02] hunger) We are really moving slowly for a while now. Mostly that's due to people having other things on their hands and in my case it is a sever depression in addition to that.
* ([22:47:21] hunger) has spend to much time on tradeshows presenting fresco.
([22:47:27] @Neovanglist|Work) #0 0x293384fc in art_rgb_svp_alpha () from /usr/X11R6/lib/libart_lgpl.so.5
([22:47:27] @Neovanglist|Work) #1 0x293181c8 in Berlin::DrawingKit::libArt::DrawingKit::draw_path(Fresco::Path const&) () from /usr/local/lib/Berlin/LibArtDrawingKit.so
([22:47:28] @Neovanglist|Work) hrmm
([22:47:32] @Neovanglist|Work) that segfaults
([22:47:33] hunger) The reactions you get there are really *DEPRESSING*
([22:47:51] @Neovanglist|Work) I'm guessing that draw_path is sending bad data to art_rgb_svp_alpha?
([22:47:54] hunger) Neovanglist: LibArt has some bugs, it could well be those.
([22:47:57] @Neovanglist|Work) ah
([22:47:59] @Neovanglist|Work) maybe..
([22:48:00] @minddog) hunger: don't worry, i presented DotGNU at a web services convention, they are like "where are the web services"
([22:48:02] @Neovanglist|Work) but why only on BSD >_<
([22:48:06] @minddog) &*$%&*#$%
([22:48:21] @Xuric) lol
([22:48:30] @Xuric) maybe i should try it on my Mandrake?
([22:48:32] @Xuric) or cygwin :P
([22:48:42] @Xuric) (talk about a bastard-child)
([22:48:55] hunger) minddog: The most upsetting comment I got so far was "We don't need no strange corba based opengl rendering windowing systems." from a fellow free software developer in his presentation on freedesktop.org.
([22:48:56] @Xuric) (better yet, lets not)
([22:49:09] @Xuric) lol
([22:49:30] @minddog) hunger: i would have stabbed that guy in the eye
([22:49:36] @minddog) you can code from prison right?
([22:49:43] @Xuric) lol
([22:49:43] hunger) I wouldn't mind such a comment in private, but in a presentation it fealt way out of place!
([22:50:12] hunger) minddog: Neovanglist doesen't think too much of that guy either from what I heared so far;-)
([22:50:39] @Neovanglist|Work) nope
([22:50:44] @Neovanglist|Work) bugs >.>
([22:50:45] @Neovanglist|Work) so many!
([22:50:46] @Neovanglist|Work) why!
([22:50:53] hunger) minddog: and don't forget thousands of "Why would I want to rotate my windows? That's stupid."
([22:50:54] @Neovanglist|Work) like 1/2 of fresco-demo is non-functional >_<
([22:51:17] hunger) Neovanglist: Everything (but the termdemo) works for me.
([22:51:49] hunger) OK. The next downside: Fresco is incompatible to everything else and currently there are only longterm plans to change that.
([22:52:09] @Neovanglist|Work) well we were already talking about an libX11 -> Fresco wrapper
([22:52:57] @Xuric) how hard would that be, though?
([22:53:02] hunger) I figure that people would only run Xterm on Fresco and then tell their friends that it is just a slow xserver... plus we do have enough to do with fresco and don't care about anouther construction side.
([22:53:03] @minddog) hunger: that really doesn't matter if theres an OS behind fresco
([22:53:46] hunger) Xuric: !!!!FRESCO IS DIFFERENT!!!!! A wrapper should be doable, but it won't be trivial.
([22:54:01] @Xuric) that's not the thing
([22:54:18] @Xuric) ya see, as the guy who has to answer questions, i need to ask them first
([22:54:18] hunger) Xuric: For example Fresco *NEVER* passes eventas to the client.
([22:54:49] @Xuric) i'm just wondering how far back the wrapper will set our project, should Neovanglist and Minddog decide to take that path next
([22:54:52] hunger) ...something which we will need to change for an Xlib wrapper I'm afraid.
([22:55:55] hunger) We do have a couple of showstoppers in fresco and have set an IRC meeting to discuss how to *finaly* overcome those.
([22:56:24] hunger) For example: Text rendering is rather crude/broken and we don't know yet how to do that right in a devide independent way.
<§> [22:56:48]  #LainOS:  E0x has quit: Quit: i waiting for a good log cya guy from #Lainos
<§> [22:57:28]  #LainOS : cinap_lenrek changes to reppotswohs
([22:57:39] @Xuric) heh
([22:58:03] hunger) You will need to invest a lot of time to help get fresco of the ground before it is fit to become a X-rendering FX mashine for a window manager;-)
([22:58:13] @Xuric) yeah
([22:58:17] @Xuric) that's the way it sounds
([22:58:28] @Xuric) i'm sure our community (such as it is) would love to hear that...
([22:58:32] @Xuric) -.-'
([22:59:24] hunger) I do think it is worthwhile... though. Fresco is designed with the idea of making 3D guis possible (even though we do have some problematic implementations wrt. that).
([23:00:06] hunger) X is not... so XFreeGL will be really hard to realize.
* ([23:01:00] hunger) is not convinced that it even can be done without some changes to the protocol (aka. breaking compatibility).
([23:01:21] @Xuric) i'm not very sure about it
([23:01:31] @Xuric) XFreeGL was/is a great idea.
([23:01:37] hunger) But then I try hard not to be an expert on X, so I might be wrong:-)
([23:01:40] @Xuric) but it probably won't help the 3-D aspects
([23:02:38] hunger) Xuric: I'n mot saying that XFreeGL is a bad idea, only that X was never designed for more than an monochrome pixel array.
([23:02:50] @Xuric) right
([23:03:20] @Xuric) i still wonder about true three-dimensional...
([23:03:28] hunger) Xuric: ... everything but that is stretching the abilities of X... adding OpenGl might tear the design.
([23:03:39] @Xuric) because no matter HOW you do it, navigating the Z-axis has to be made as simple as possible
([23:04:31] @Xuric) and that might have a higher learning curve that most  users  might be willing to put forth
([23:04:49] hunger) Xuric: http://www.3dwm.org/sshots/
([23:04:54] @Xuric) present interface devices make it really difficult
([23:05:13] hunger) Xuric: 3dwm is a project by some graduate students in sweden, based on the architecture of fresco.
([23:06:39] @Xuric) man, all of the good shots don't load
([23:06:53] hunger) We worked closely together with those guys for a while, there even was some talk about merging the projects after 3dwm was graded. Unfortunately they just vanished... and the site is rather broken by now:-(
([23:06:56] @Xuric) n/m
([23:07:18] @Xuric) hmm
([23:07:29] @Xuric) http://www.3dwm.org/sshots/images/sshot-20011106-3.jpg <-- that poses some interesting ideas
([23:07:50] @Xuric) but an intuitive navigation method would definately be necessary
<§> [23:08:06]   #LainOS : zero_one joins.
<§> [23:08:06]   #LainOS : ChanServ has Voice'd zero_one
([23:08:08] @Xuric) wb
([23:08:27] hunger) Xuric: I had a user once at a tradeshow who was really excited about rotateable windows (the only one by the way)
([23:09:01] hunger) Xuric: He suggested putting the kill button and some statistics (PID, a CPU usage chart, etc.) on the backside of the window.
* ([23:09:13] +zero_one) is back (gone 00:00:55)
([23:09:33] +zero_one) did i miss the meeting?
([23:09:41] @Xuric) still going on
([23:09:48] hunger) Xuric: ... so you can't accidentally kill a window by clicking onto that stupid X in the upper right corner.
([23:09:57] @Xuric) right
([23:10:19] @Xuric) good idea, except for when you actually wanted to close it with the little x
* ([23:10:23] hunger) has turned of titlebars to get rid of that problem.
([23:10:32] @Xuric) heheh
([23:10:32] hunger) s/of/off/
([23:10:52] hunger) It does save screenestate too!
* ([23:11:04] hunger) only got 1600x1200 pixels!
([23:11:11] @Xuric) is that all?
([23:11:24] hunger) Xuric: Unfortunately yes:-(
([23:12:09] hunger) Any more questions?
* ([23:12:17] hunger) is nearly falling asleep.
([23:12:19] @Xuric) heh
* ([23:12:28] reppotswohs) too
<§> [23:12:34]  #LainOS : reppotswohs changes to cinap_lenrek
([23:12:41] @Xuric) hmm
([23:12:56] @Xuric) nothing more from me
([23:12:59] @Xuric) not for y'all, anyway :P
([23:13:06] @Xuric) Neo, Minddog.. ya still with us?
([23:13:14] hunger) OK, I'll head for bed then.
([23:13:20] cinap_lenrek) byebye
([23:13:25] @Xuric) thanks for coming, guys
<§> [23:13:28]  #LainOS:  cinap_lenrek has quit: Quit: close the world, txEn eht nepo
([23:13:37] @Xuric) (nice msg)
([23:13:50] hunger) One more thing: If you should decide to use fresco, I'd recommend waiting till after our IRC meeting on Monday, Jan. 19th 23:00GMT
([23:14:01] @Xuric) ok
([23:14:11] @Neovanglist|Work) sorry I Was afk for a bit
([23:14:14] @Xuric) heh
([23:14:14] alex) Fresco.
([23:14:14] hunger) before commiting. We will discuss how we want to go on then.
([23:14:21] @Xuric) right
([23:14:58] alex) You know what, I have met one guy who develops kernel for NetBSD.
([23:15:01] hunger) Our meeting will be help over on freenode, #fresco
([23:15:21] @Xuric) irc.freenode.net#fresco?
* ([23:15:28] hunger) nods.
([23:15:30] @Xuric) k
([23:15:48] @Xuric) I'll have this log up tonight (pending the control codes have been properly stripped)
([23:16:00] alex) and... he may be interested to help. But what should I really ask him?
([23:16:39] hunger) alex: My wish would be to have KGI or something similar integrated into the kernel.
([23:17:02] hunger) OK, I really need to get some sleep now. Need to work tomorrow.
([23:17:08] alex) Ok. I'll speak to him about that on the LUG meeting.
([23:29:28] hunger) OK, 5:30 now. Definitly time for bed.
([23:29:32] @Xuric) g'night mate
([23:29:36] +zero_one) lol
([23:29:39] +zero_one) g'nite
([23:32:23] @Neovanglist|Work) ok
([23:32:26] @Neovanglist|Work) gnight hunger
([23:32:34] @Neovanglist|Work) sorry, having a discussion with minddog
([23:33:14] @Xuric) ahh
<§> [23:35:29]  #LainOS:  zero_one has quit: Ping timeout
([23:38:01] @Xuric) ok
([23:38:06] @Xuric) I'll declare this meeting over.
([23:38:16] @Xuric) next meeting will be Sat. Jan 17th.
([23:38:24] @Xuric) pending topics: to Fresco, or not to Fresco
([23:38:37] @Xuric) .topic.push('end')