| | #fresco 33 The fresco (formerly Berlin) windowing system. || IRC meeting: 2004-01-19 at 23:00UTC - njs at least would appreciate it if people could read his messages to the list beforehand || http://www.jacksonh.net/jackson/images/godkills_bugs.jpg |
| stefans: | starseeker: that was a pretty abstract one. I was more thinking of a concrete list: 'location transparency', 'object model', 'imaging model', etc. |
| hunger: | njs: Good. |
| mourad: | (Im still catching up with ReFresco01 - very interesting) |
| stefans: | nicholas: do you have any suggestions ? Want to coordinate the meeting ? |
| stefans: | nicholas: (you called for the meeting first :-) |
| nicholas: | stefans: well, I suppose I want to know whether a) are we still supposed to be a replacement for X? |
| hunger: | stefan: Shall we use the list on http://www2.fresco.org/introduction.html as a guideline? |
| | rapha_ (~Raphael@p5085C3AC.dip0.t-ipconnect.de) has joined channel #Fresco |
| njs: | Well, you know what the biggest topic I want to talk about is :-) |
| nicholas: | I want some very broad direction of what are and what aren't our goals! |
| stefans: | nicholas: I believe yes, though we obviously ought to define what that actually means |
| nicholas: | X offers a lot. Surely we aren't about display drivers. |
| njs: | nicholas: not if we can help it ;-) |
| stefans: | nicholas: oh. Well, we want to offer something equivalent in terms of usability. How we achieve this, i.e. whether we delegate to other tools is a different matter (even though very important to discuss) |
| starseeker: | Do we take up the Corba thing? |
| nicholas: | I wasn't specific enough. Are we a project working to produce an X replacement, or are we working to provide a research vehicle for future 3D GUI work? |
| ShelterIt: | Yeah, let us jump into the deep end. CORBA is the one of the most importance right now. |
| stefans: | nicholas: ah, that's already much more difficult :-) |
| njs: | nicholas: I don't care about being a research vehicle for future 3d GUI work. In particular since I'm not all that interested in 3d GUIs :-) |
| starseeker: | That's my personal feeling |
| stefans: | hmm, to CORBA or not to CORBA. Is that really the central question ? Shouldn't we rather talk about location transparency, whether we want it, and if so, where ? |
| hunger: | nicholas: I'm in favour of a exxperimental (3D) GUI system. |
| starseeker: | After all, the monitor is 2D |
| BenB: | nicholas: I haven't seen a 3D gui in fresco (not what I think of it, anyways) :) |
| hunger: | nicholas: What good is it to do something similar to what is already there? |
| BenB: | starseeker: most of them are, but there are 3d ones .) |
| rohara: | perhaps we should start with hunger's suggestion as it will answer these questions. |
| hunger: | nicholas: And an experiment can always turn into an replacement. |
| cow: | hunger, that would be interresting, agree |
| nicholas: | All I've seen of 3D GUIs, which amounts to computer game interfaces really, is using the 3D hardware to render a pretty 2D interface. |
| mourad: | hunger: yes but the question becomes: do you want your implementation to be used by real users, in the end? |
| starseeker: | BenB : Since a human being can only directly see 2D at any one time (3D is deduced) how does 3D help? Multiple simultaneous viewers? |
| njs: | I think our goal is to design a clean, powerful, and practical system for running GUIs. One test of whether we've achieved that is if 1) people who want to build fancy new stuff find it easier because they base it off us, 2) we can accomodate fancy new stuff once it gets figured out |
| | hunger agrees with njs. |
| | stefans too |
| nicholas: | Accomodate at what expense? Full backwards compatibility? |
| njs: | That's just a test, though; I'm not really planning on doing it myself, at least not yet... |
| mourad: | Personally, I'd like to see a GUI that could scale well from small limited displays ala picogui to fullon 3D. ie abstraction, and the semantic thing |
| stefans: | mourad: yeah, I believe that should remain one central goal. |
| starseeker: | My thought on that: Fresco is being developed on very powerful hardware, unlike X - we can build in much more abstraction |
| | njs is not as worried about tiny tiny displays as picogui. But then, I would say that, seeing as I'm proposing a protocol that requires holding lots of long random numbers in memory all the time :-) |
| stefans: | mourad: make fresco scale well and adapt to very different hardware (and people's requirements) |
| nicholas: | X scales to any framebuffer. Yes? |
| ShelterIt: | So the question is whether we will innovate something cool or streamline something already done, or perhaps a merge of the two? |
| hunger: | How about some brainstorming? What is the most important aspect that fresco should archive (in one word)? |
| starseeker: | stefans: Question - adapting to different hardware a matter of drivers primarily or of design? |
| oxygene: | nicholas: its primitive list is small enough to do in slow software, yes |
| BenB: | njs: CORBA is not really fitting for cell phones eithe r:) |
| njs: | nicholas: well, I dunno how well it'd work at 16000x12000 resolution... |
| mourad: | nicholas: yes, but is it useful with tiny (albeit high res) displays? |
| BenB: | (not yet) |
| oxygene: | hunger: vector graphics + compositing |
| starseeker: | hunger: flexibility? |
| stefans: | nicholas: oh, by 'scaling' I mean not only that. It should also adapt in terms of what kind of GUI is used. The whole 'tasket' idea, remember ? |
| oxygene: | hunger: scalability of hardware (display + cpu) |
| | hunger votes for consistence. |
| mourad: | semantic abstraction |
| nicholas: | stefans: that's neat! I never thought we would make that a central goal of Fresco! |
| starseeker: | hunger: Across toolkits, or platforms? |
| oxygene: | starseeker: both? :) |
| stefans: | starseeker: design. Because different hardware has different capabilities. |
| BenB: | hunger: usability |
| nicholas: | stefans: so that smaller systems follow GUI designs intended for smaller systems. Like how PalmOS has only one program window at a time. |
| mourad: | nicholas: right! |
| hunger: | starseeker: A consisitent UI. |
| nicholas: | We we are indeed a desktop system, capable of displaying onto some sort of backend. |
| njs: | Overall I think that being scalable to small (in cpu and memory) systems is nice, and I think if we focus on making our architecture concise and simple, we'll probably do fairly well here. But I think it's a lower priority than making a good clean system for everyone else. |
| starseeker: | stefans: OK. How does one approach that then - break down the capibility of various hardware components and fit them into an abstraction? |
| cow: | starseeker, fresco should imo not care about drivers |
| nicholas: | And we should have different "policies" for different target systems. |
| starseeker: | _cow: I agree |
| stefans: | nicholas: yeah, that was always one of the more interesting aspects |
| BenB: | hunger: though mourad's "semantic abstraction" is also near to my ideas of fresco |
| oxygene: | BenB: ooui? |
| starseeker: | I like "semantic abstraction" |
| njs: | It's also one of the more "more fundamental research needed" aspects; I'd like to have a better idea of our foundations before trying to figure out to what extent we can make clients magically adapt to their environment... |
| hunger: | Shall we go down the list of those important things (plus those from the website) now one after another? |
| stefans: | mourad: with 'semantic abstraction' do you mean what we discussed as 'taskets', i.e. abstractions of widgets into hardware specific user interaction ? |
| oxygene: | hunger: sounds good, to get some structure |
| stefans: | njs: er, did you say 'clients' ? |
| njs: | I don't like "semantic abstraction", because "semantic" means "meaning", and with current state of the art we can't actually do anything that begins to live up to that. So talking about "semantic abstraction" tends to send one down the path towards the impracticalities of AI. |
| BenB: | oxygene: I think ooui is close to fresco's ideas, but not quite the same, stefan convinced me of that, I think ooui is one level higher in abstraction. |
| hunger: | ok, Let's start with "VECTOR GRAPHICS" and in that context "DEVICE INDEPENDENCE". |
| | rapha__ (~Raphael@p5085C88C.dip0.t-ipconnect.de) has joined channel #Fresco |
| oxygene: | BenB: above taskets? |
| stefans: | njs: I thought that this adaptability should be done server - side, i.e. without the client's need to care. (It obviously should be able to, just not required) |
| nicholas: | On that note, how important is "beautiful rendering"? |
| mourad: | stefans: I mean, designing the interface so that the server can decide (if it wants to) how to layout the widgets/ui etc |
| BenB: | oxygene: ooui rearranges the whole UI, includes windows (or the absense of them) etc. |
| njs: | stefans: that's what I meant; adapting the client's onscreen appearance, if you like. |
| | cinap agrees with njs |
| starseeker: | nicholas: I'd say very important for acceptance |
| hunger: | BenB: Could you wait with OOUI till we get to that topic? |
| BenB: | oxygene: I don't see how fresco's scene graph could map that level of abstraction. |
| stefans: | nicholas: beautiful ? Or correct (as in 'as intended') ? |
| BenB: | hunger: yeah, sure, just answering oxygene |
| nicholas: | stefans: Well, correct... as the font designer intended for example. |
| njs: | stefans: but I will observe that it's not actually clear whether that's possible -- I'm sure the server can do something, but perhaps it will require client help. I dunno. |
| | Signoff: rapha_ (Read error: 60 (Operation timed out)) |
| hunger: | Device independance is a key feature to me. |
| nicholas: | but there's more than that. Palm's, for example, don't have Open/Save buttons. Why? no filesystem. |
| | Signoff: rapha (Connection timed out) |
| stefans: | nicholas: yep, I think that is important. Or else nobody will use fresco. |
| | rapha__ is now known as rapha |
| czw: | device and resolution independence is probably a must-have. |
| nicholas: | stefans: ok then then rendering must know the DPI of the display. |
| starseeker: | czw: I agree |
| | Signoff: icebird (Connection timed out) |
| hunger: | nicholas: Can we hide the resolution inside the DrawingKit? |
| njs: | I think we should be somewhat less militant about device abstraction than we have been; we should accept that there are times when you need to find out about pixels. |
| nicholas: | hunger: no. Layout is resolution-dependent. |
| stefans: | njs: I think I agree with you that all that tasket business is a bit abstract, at least at this point. However, designing for such kind of flexibility has to be thought about upfront. |
| mourad: | In the end, what I'd like is that if the client isn't usinig specific kits (choosing the level of abstraction) that it stays general enough to be completely usable on a Palm, or a 3D workstation (single-task vs multitask, different widgets etc) |
| czw: | nicholas: not dependent on pixel-positions |
| nicholas: | czw: uh, yes it is.' |
| starseeker: | nicholas: You mean, for example, that a word processor interface can't scale down to a palm and still be usable? |
| oxygene: | njs: in that case people will be using pixels - drop vectors then |
| stefans: | mourad: yes, that makes sense. The 'basic kits' should be supported everywhere. |
| hunger: | nicholas: Sure. But can we hide that from the client? |
| nicholas: | starseeker: well it can, but you have to know what to drop. |
| nicholas: | hunger: Almost certainly. |
| hunger: | nicholas: That's what is important to me:-) |
| nicholas: | hunger: We win because the client will simply ask (something) for text layout to be done (say, when displaying a readme file.) |
| starseeker: | nicholas: Right. But isn't that an example of pixel sensivity? |
| njs: | mourad: that sounds nice. But I don't think we can say whether that's a reasonable goal yet. |
| nicholas: | hunger: but if you're writing a full word processor, then you need to know. You are a pixel sensitive application and no amount of design can prevent it; with or without Fresco. |
| hunger: | nicholas: That the server (be it up to the DKs or maybe even some other kits too) need to know the resolution is undisputed (by myself). |
| oxygene: | nicholas: actually you need some kind of layout, not necessarily pixels |
| mourad: | njs: I understand... but we shouldn't sweep it under the carpet because it comes up quite often... (picogui semantics vs device independence, taskets, ooui, ...) |
| czw: | nicholas: isn't a word processor more interested in inches and millimeters? |
| oxygene: | nicholas: text layout worked pretty good in the pre-pixel era, too |
| starseeker: | wouldn't the most relevant information to have be the physical size of the display, and density of pixels? |
| stefans: | nicholas: can we get a little more into detail as to what 'being a pixel sensitive application' actually means ? I think that's a key issue |
| hunger: | nicholas: I disagree somewhat. You need to be able to do layout in some units. Wether the server or the wordprocessor maps that to pixels is irrelevant. |
| nicholas: | czw: only when printing. In fact, in MS-Word, when you change the printer, it relays out the document according to the printer you just selected. |
| njs: | hunger: that's just not true when it comes to things like fonts; at least if you want reasonable display and suchlike. |
| oxygene: | there are applications that really work on pixels (bitmap editors) - apart from that, pixels should generally be a non-issue |
| stefans: | hunger: but that assumes that some behind-the-scene tool will compensate for the pixel rounding. That's not always possible. |
| nicholas: | Many things are pixel-sensitive. All text layout is pixel sensitive, for example. You must hint your font to the pixel grid or it will look like crap. |
| hunger: | nicholas: ... which was a bug that got fixed in recent versions of word (even though that fix is turned of by default to be backward compatible) |
| nicholas: | Placing widgets is pixel-sensitive. You want the edges to line up with the pixel grid or again, it looks like crap. |
| njs: | nicholas: that one I'm less convinced of, but maybe. |
| nicholas: | hunger: ... and the fix was to not re-layout until you actually hit print instead of changing the printer? |
| mourad: | nicholas: I know that this is a standard response, but hinting is used less an less: On my screens I switch off all hinting, I just use AA. |
| starseeker: | Are we talking about screen dimension in pixels or pixel density? |
| nicholas: | But in both of those cases the Fresco client should be able to avoid caring how the Fresco internals did the layout. |
| stefans: | nicholas: indeed. But why does that matter ? I think it matters only if you attach some constraints to the layout, i.e. if you really want to control it. Read: for an arbitrary text editor (email tool, say) the layout isn't all that important. |
| hunger: | nicholas: Nope, using a different data type. |
| oxygene: | nicholas: aligning widgets to pixel grid could be a policy in the drawing kit, or not? |
| hunger: | nicholas: Even TeX manages a non-printer resolution dependent layout. |
| njs: | mourad: raph levien says that hinting is still needed; therefore I believe it ;-) |
| nicholas: | hunger: no it doesn't. |
| nicholas: | oxygene: too late. DrawingKit happens after the layout. |
| mourad: | njs: Ah :) surprising, I think I've heard him advocating the opposite at one point... |
| stefans: | oxygene: the drawingkit ? No, because that would lead to crappy renderings, i.e. the typical artifacts you observe with unhinted text. |
| stefans: | oxygene: (for example for small details such as beveled edges etc.) |
| oxygene: | stefans: hmm.. okay |
| nicholas: | hunger: or does it? I thought it defered to the post-metafonted DPI-dependent glyphs? |
| hunger: | nicholas: It does. |
| njs: | mourad: don't think so. |
| hunger: | nicholas: The DVI-file contains the layout only. |
| hunger: | nicholas: The fonts get rendered at the right resolution and inserted once you convert DVI to whatever. |
| nicholas: | hunger: ok. fine. at high resolutions that should look fine. |
| njs: | TeX also targets very high resolution output |
| njs: | nicholas: jinx :-) |
| nicholas: | hunger: try it on a palm with 24dpi... |
| nicholas: | hunger: or, we could just decide to not support low-dpi environments. |
| stefans: | anyways, I don't think we have to nail down whether or not to abstract the pixel grid tonight. What is important is to agree on whether high quality rendering is important or not. Whether we have to hint (and thus make the layout dependent on the h/w should be a result of that requirement) |
| njs: | even for display on my desktop, TeX and PDF files look kinda wonky |
| nicholas: | hunger: that's what we're here to decide. |
| mourad: | I'm assuming that really tiny hardwate (with a couple of lines of text, or a terminal for instance) won't be supported by fresco? |
| hunger: | nicholas: I'm not arguing that we don't need to do pixel aligning. |
| starseeker: | I'd say high quality rendering is the more important thing |
| hunger: | nicholas: All I'm saying is that I prefer that to be transparent to the client (as the rest of the layout is) |
| nicholas: | hunger: I agree with you. As transparent as possible. |
| mourad: | I mean: can a base Fresco app be displayed on a text-only screen? |
| njs: | stefans: agree. I also think that if we're doing any radical shifts to the architecture -- "pulling the scene graph out of CORBA", for instance -- then it really changes what's possible and what's easy wrt rendering. |
| starseeker: | mourad: Personally I'd say that problem is solved by other tools |
| nicholas: | hunger: that doesn't mean we should hide it deliberately. Just that we should make certain they don't need to know about it. |
| njs: | mourad: no, I don't think that's a goal. |
| hunger: | nicholas: Agreed. |
| stefans: | njs: right. So lets focus on the requirements and not on the how-to-achieve-this. |
| oxygene: | njs: would be nice (wrt accessibility, too) - but it needs some non-visual widgets for grouping... |
| mourad: | njs: just making things clear... If an app is general enough, and the abstraction level high enough, what's to prevent it from running on text-only? |
| starseeker: | Maybe this is a better question - what benefits do we get teaching fresco to render at very low resolution that can't be gained by current tools? |
| stefans: | starseeker: application portability. |
| hunger: | OK, so lets nail this down: |
| njs: | mourad: I dunno. The non-existence of a high enough abstraction layer, would be my first guess. In any case, there's a reason I said "that is not a goal" rather than "we will not allow it if it turns out to be possible" |
| nicholas: | mourad: ok, i see your point, but i don't want to make it a *requirement*. |
| hunger: | * Pixel alignment should be transparent to the client. |
| hunger: | Whast kind of hardware do we need to support? |
| nicholas: | mourad: so a program that uses only menus and displays a text-file could work, but a ms-paint program wouldn't. |
| starseeker: | stefans: But if the application wants to run on such a low resolution device, doesn't that mean the client has to design the GUI to work that way? |
| mourad: | nicholas: right now a 3D app isn't required to only use 2D widgets either is it? |
| starseeker: | stefans: From what I understand small screen application design is a whole field by itself |
| hunger: | It will be a couple of years till fresco con be deployed: So a lowres PDA is not a priority to me. |
| mourad: | nicholas: absolutely! |
| nicholas: | starseeker: we should really say that the application should support certain "profiles", or somesuch. We haven't worked it out. |
| njs: | PDAs these days actually have the highest resolution of anything. |
| stefans: | hunger: 'should be transparent' is vague. I would say 'clients can ignore the pixel grid if they don't need any specific control'. |
| hunger: | stefan: OK. |
| njs: | stefans: I like that phrasing. |
| oxygene: | starseeker: you need to adapt it somewhat, but tasket like approaches can reduce the effort in the client |
| mourad: | stefans: me too |
| hunger: | * clients can ignore the pixel grid if they don't need any specific control |
| starseeker: | nicholas: OK, if the application is to support profiles (which fits the tasket model) then isn't it true that rendering at each reasolution is a different problem? |
| hunger: | So which hardware do we target? |
| mourad: | hunger: speech output? :) |
| stefans: | hunger: well, mainstream first. The stuff we are working on. |
| oxygene: | hunger: hmm.. that depends on the layer fresco wants to provide |
| starseeker: | hunger: PCs |
| hunger: | As I said before lowres PDAs are not important to me. We need a system with FPU anyway. |
| nicholas: | starseeker: sort of. A Fresco program is a composite of Fresco provided components, allowing the process of scaling to be as transparent as possible. |
| oxygene: | hunger: stop with vectors, widgets, taskets, OOUI? |
| stefans: | hunger: next comes high end hardware (so those 3D people can see whether fresco is good for them) |
| nicholas: | heh, yeah. |
| cinap: | :) |
| starseeker: | nicholas: But in application design, some parts of the program tend to be custom. Abstract things like scroll bars, menus, etc. can be provided, but things like a 3D interactive environment are custom. |
| hunger: | stefan: I would like to see high end PDA (Sharp Zaurus and upwards) supported too provided they have a FPU. |
| stefans: | I mean, 3dwm targetted an interesting audience. I believe that's where a scene graph based display server has lots of potential. |
| starseeker: | nicholas: So I'm not sure the process CAN be transparent in any nontrivial way |
| stefans: | hunger: heh, who would not :-) |
| | rapha_ (~Raphael@p5085C23F.dip0.t-ipconnect.de) has joined channel #Fresco |
| nicholas: | starseeker: then we need to be exceedingly careful about the design of our abstraction. If you have a 3d interactive environment, who needs scrollbars? A file can be written on an infinite expanse of floor. But your app just asked for a text-displayer tasket. |
| hunger: | So can we agree on a "target Hardware" of highend PDA's and up? |
| nicholas: | we'll require an FPU? |
| hunger: | That would rule out 24dpi Palms, too;-) |
| hunger: | nicholas: Definitly. |
| nicholas: | shucks. |
| oxygene: | nicholas: at least with CORBA |
| njs: | I'm not sure about 3d as being a useful target market. That'll get us gee whiz points, but will it actually help anyone? |
| hunger: | nicholas: Fresco renders with less then 0.2 FPS on a Zaurus. |
| stefans: | nicholas: well, else it's unusably slow. Should we really support integer math for the vector graphics ?? |
| oxygene: | nicholas: floats are transmitted as base10 stuff - conversion is expensive |
| starseeker: | nicholas: It depends on how you interact with the 3D environment - I've seen side scrollbars used to control X and Y rotation, for example. |
| nicholas: | well, look, freetype manages to use integer math everywhere. |
| hunger: | nicholas: Foating point math takes more than 30 times as long as on a 120MHz PI! |
| nicholas: | and they've got more work to do (and done) than we have! |
| oxygene: | hunger: fixpoint? |
| stefans: | njs: the question is whether targetting 3D will have a negative impact on other requirements |
| starseeker: | nicholas: One possibility is the Garnet model of interface design - it was possible to have the size of components depend on other components |
| hunger: | oxygene: Breaks the highend vector thingy. |
| oxygene: | hunger: implementation detail, really |
| nicholas: | starseeker: ah, we already have that. (So does Java.) |
| cow: | i like the idea of taskets as a base as they would provide simple means of providing e.g. a cylinder for (lets say) 3D representation of a scrollbar as well as a 2D conventional representation |
| hunger: | oxygene: Not really, as the datatype of the coordinate system is in the API. |
| starseeker: | nicholas: Perhaps some kind of sane defaults could be decided at each level of "zoom" for relational sizes between components fresco provides |
| njs: | I've been following Raph Levien/Tor Andersson's "fitz" stuff, and they seem to think that it might actually be possible to do real vector graphics using integers. I dunno how, seems crazy to me, but... |
| stefans: | nicholas: well, using a fixed point as FT is hard to map to h/w that actually supports openGL or somesuch, no ? |
| mourad: | Personally I don't think hardware targets are extremely important for the design: apps running on hardware that don't have FPU/3D etc, could just choose not to use certain things (vector/3D graphics) and provide an alternative implementation (on the display side) for their textlayout for instance |
| mourad: | But yeah initially we need to know where the implementation needs to be |
| nicholas: | stefans: not really, can't we just throw in a transformation matrix that does the appropriate divide? |
| njs: | FPU is kinda hard to avoid, what with matrix multiplies at the layout level. |
| hunger: | mourad: I am asking since wether we need 24dpi displays or not does matter. |
| starseeker: | nicholas: I don't know if we want to decide this or not at the fresco level, but we might take the position that at each resolution there is some ideal "useful" size for a given component, and use that size unless explicitly told otherwise by the program |
| mourad: | hunger: for the implementation, yeah, but for the design? |
| stefans: | nicholas: well, we have to cast the int to a float, somehow. Ideally that can be done by some sort of reinterpret_cast, but I don't know whether that's possible... |
| nicholas: | starseeker: well, we currently follow the TeX model, what with alignment and relational sizing and whatnot. We don't consider components with respect to the screen. In fact, we assume, in Fresco, that all screens are equal. |
| nicholas: | stefans: hm... yes... |
| stefans: | nicholas: probably only if we designed our fixed point data type for a particular h/w :-) |
| hunger: | mourad: See the pixelgrid discussion. |
| | stefans needs to look up the ieee float specs |
| starseeker: | nicholas: Isn't that a bad assumption when it comes to intracting with components at unusual resolutions? |
| mourad: | hunger: I'm assuming there's apps that don't need access to the pixelgrid... |
| nicholas: | starseeker: naw, really? why do you think i'm here arguing it? :) |
| hunger: | mourad: I was trying to point out that this might influence the design. |
| starseeker: | nicholas: Ah, of course :-). But we can still have resolution and pixel independance as far as the clients are concerned, if they use fresco components |
| stefans: | ok, so did we get a prioritized list of h/w to focus on ? |
| starseeker: | nicholas: We just have to make intelligent choices |
| nicholas: | starseeker: exactly. you got it. |
| stefans: | what are the niches fresco would be well received, i.e. where conventional display servers fail ? |
| mourad: | 1) current 2D workstations 2) 3D 3) PDA's 4) everything else ?? |
| hunger: | * Fresco will target PCs, high end (3D) hardware and PDAs with FPU and a good screen last. |
| starseeker: | nicholas: Then I'm a little confused - why all the fuss about pixels? Fresco has to deal with them at some point anyway, since the screen is made up of them. Are we arguing about where to deal with them? |
| | _cow nods hunger |
| BenB: | stefans: I think conventional display systems fail misreably on modern hardware :) |
| | starseeker agrees with hunger |
| BenB: | it has so much to offer, and all unused. |
| BenB: | I mean modern PCs |
| nicholas: | starseeker: yes. Previously, we had designed such that nobody responsible for layout was allowed to know about the final display. |
| stefans: | yeah |
| | Signoff: ShelterIt ("Leaving") |
| nicholas: | ok. that's settled then. |
| mourad: | I've heard there's now hardware acceleration of Glyphs/fonts :) Matrox i think |
| stefans: | hmm, what about location transparency ? |
| njs: | I still don't see how 3D is that high a priority, but whatever, we can figure out how to support current desktops and then see if that needs revisiting :-) |
| nicholas: | mourad: Really? I'd need to look at that... |
| nicholas: | oh, location transparency. |
| njs: | stefans: you mean, the ability to run clients from anywhere? |
| hunger: | I guess this was the SCALABILITY discussion then;-) |
| hunger: | Let's get on to LOCATION TRANSPARENCY: |
| stefans: | njs: well, the ability to have some objects be either in the server or the client. |
| starseeker: | nicholas: Oh, I see. |
| starseeker: | nicholas: I guess I've made it to the starting point :-/ |
| njs: | stefans: ah. Seems to me that should mostly be aon a case-by-case basis? |
| hunger: | We definitly need network transparnecy with client and server running on different system. I guess that's undisputed, isen't it? |
| nicholas: | starseeker: and it's not exactly some sort of easy fix either. The scene is layed out once, then rendered by different screens... so... we'd need to make it such that we do layout once per screen. |
| stefans: | njs: yes, transparency in the generic sense we have now can probably be dropped. |
| stefans: | hunger: right |
| nicholas: | hunger: right. |
| BenB: | njs: a main advantage of location transparency is that you don't need to rewrite or even rearchitecture your whole app when you change the location of objects later. |
| mourad: | stefans: you mean the client should be able to send some code to the server? |
| starseeker: | nicholas: Is the concern that would be too expensive, or that it's a major change in the system? |
| czw: | hunger: both different systems and different processes |
| BenB: | njs: and we do that a lot, not? |
| hunger: | czw: Of course. |
| nicholas: | starseeker: very major change to the system. Nearing rewrite status. |
| njs: | BenB: except that in practice you usually do, because pretending that local and remote are the same doesn't make it so. |
| stefans: | mourad: no, 'sending code to the server' sounds like an implementation serving such a requirement. But there are others... |
| BenB: | (i.e. we can'T decide, where the HTML rendere is supposed to be= |
| hunger: | Do we need to be able to have the server distributed over several systems? |
| starseeker: | nicholas: Wow. I didn't know it was in that deep. |
| nicholas: | starseeker: neither did I until I tried it :( |
| njs: | BenB: ah, yeah, in some cases that's helpful. |
| stefans: | distributed server ? No ! |
| hunger: | What about student/teacher scenarios? |
| czw: | hunger: p2p fresco? :-) |
| nicholas: | czw: lol |
| mourad: | hunger: good question, you're thinking about some kind of multi head? |
| hunger: | What about coupling several servers into one "virtual server"? |
| njs: | stefans: the trader scenario is actually sorta like that; "Hey, server, gimme an HTML renderer" "err, well, here, talk to mozilla" |
| stefans: | hunger: er, is that really on our priority list ? I mean, in what way is that at all related to display servers ? |
| starseeker: | nicholas: Ah. I don't suppose Z would have helped that problem. |
| | jon has left channel #fresco because () |
| hunger: | stefans: I'm asking everyone;-) |
| nicholas: | starseeker: Z? you mean a depth-axis? we already have one. ?? |
| stefans: | njs: er, yes. I don't see your point, though, sorry. |
| njs: | stefans: <stefans> distributed server ? No ! |
| starseeker: | nicholas: No - mapping out the arch with the Z language |
| hunger: | stefan: I think it would be nice to tie up several of my PCs and have a huge virtual desktop over all of them. |
| nicholas: | One display server runs one display, yes? |
| njs: | nicholas: define "one display"? |
| nicholas: | starseeker: not familiar with Z. At this point, any arch work would help. |
| starseeker: | nicholas: Rather then coding, mapping out the ideas in logic. |
| nicholas: | njs: well, I'm temped to say one physical monitor, but that's not quite right. A two-head system where one screen pans over both is still one display. ok? |
| hunger: | stefan: Currently we should be able to do somehitng like that thanks to CORBA and it is a "distributed server";-) |
| stefans: | nicholas: yes, I think so. And gets input from one console (set of input devices). |
| njs: | nicholas: yeah |
| starseeker: | nicholas: Then when logic is clear, code it up. Or at least I think that's how it is supposed to work |
| nicholas: | starseeker: or like UML. |
| stefans: | hunger: well, isn't that by accident ? I mean, it wasn't really designed in, or was it ? |
| | njs has two monitors on his desk, so you can count on him to champion multihead :-) |
| nicholas: | starseeker: yes, this is what I'm saying should've happened a long, long time ago before the code came. :( |
| njs: | hunger: and will it really work right? :-) |
| starseeker: | nicholas: yes, I think that's another technique. |
| cow: | stefans, is this a current hard limit? |
| | Signoff: rapha (Connection timed out) |
| hunger: | stefan: Is it an accident to have a nifty feature? |
| stefans: | _cow: ? |
| BenB: | hunger: I think it would be neat to have a "smart display", a computer devoted to rendering only, basically a terminal, but severl onf them togehter. |
| starseeker: | nicholas: So maybe, if we're looking at rewrite, this is the time to do it? |
| nicholas: | Notice that i never said 1 program to 1 display or anything. :) |
| stefans: | hunger: no, but now we are talking about requirements. :-) |
| cow: | stefans, he server serving only one input/output set? |
| BenB: | hunger: imagine fresco built into your TFT :) |
| hunger: | njs: Who knows? |
| nicholas: | starseeker: we'll see. Let us continue requirements analysis for now. I expect we'll be hashing all sorts of stuff out over the mailing list in the near future. |
| stefans: | _cow: yes |
| hunger: | stefan: So you say multi-server is not a requirement. |
| starseeker: | nicholas: Right. Thanks for explaing it :-) |
| hunger: | stefan: What about multihead? |
| cow: | stefans, not ideal :) |
| | rapha (~Raphael@p5085C0EF.dip0.t-ipconnect.de) has joined channel #Fresco |
| stefans: | hunger: well, unless I misunderstood the sense of that term, no. |
| stefans: | hunger: multihead ? Yeah, absolutely. |
| hunger: | stefan: I do think multihead is a must. |
| stefans: | hunger: but those 'heads' are coordinated by a single server (how it does that doesn't matter tonight). |
| njs: | multihead quickly gets into complicated issues (what if the monitors have different resolutions or color profiles?) that we don't want to worry about now, but definitely they should be worried about sometime. |
| nicholas: | njs: it's good to deal with that now. |
| cow: | nfs, fine |
| hunger: | * Fresco will support multihead. |
| njs: | nicholas: I mean, "in this meeting" |
| hunger: | OK, that's settled;-) |
| nicholas: | njs: because if they have different DPI's in a word processor, doesn't that mean different layout on each screen?? |
| nicholas: | njs: am I setting myself up for a serious mess? |
| hunger: | Multiserver is an extension of that idea... we will not support that? |
| stefans: | njs: how is that different from having the same app running on different display servers (serving on different monitor types) ? |
| cinap: | hunger: the lainos-people will love it... |
| nicholas: | njs: perhaps we should allow multihead only when the DPIs match? |
| cinap: | hunger: ;) |
| mourad: | cinap: lainos? |
| stefans: | hunger: sorry, but I don't see how 'multi server' is just an extension from 'mult head'. Again, as I understand that term. |
| stefans: | nicholas: heh, sounds like a deal :-) |
| oxygene: | nicholas: hmm.. how do these layouts differ - mostly by rendering decisions in font hinting, yes? |
| hunger: | nicholas: We are supposed to be device independnet, aren't we? So requiring the same resolution sounds starnge to me... |
| stefans: | nicholas: (where 'match' could be relaxed to 'are compatible') |
| maus-: | im a total newbie, but i couldn't think of a use for this multiserver-stuff |
| mourad: | stefans: I think he means, having two different machines act as two heads of one "display" |
| njs: | nicholas: no, I can't afford to upgrade my smaller monitor right now, so that's out ;-) |
| oxygene: | nicholas: weird restriction |
| cinap: | mourad: they want to create a user-enviroment like in the anime "serial experiments lain" |
| nicholas: | oxygene: sure! Or because you have a 1in button and the pixel-grid alignment of its edges is different across the two displays. |
| hunger: | stefan: Yeap... what mourad said. |
| mourad: | cinap: fun :) |
| stefans: | hunger: oh, device independent ? Did we really say that ? I thought we disputed that in the first point. |
| cinap: | mourad: jup... |
| oxygene: | nicholas: I took the font as example because it's a common issue today |
| nicholas: | oxygene: it's not that surprising. You must allow us to pretend that your two heads are interchangable. Why not? |
| njs: | nicholas: because so often they just won't be in practice. |
| hunger: | stefan: Basically that meens exporting the scenegraph... which would be handy in a student/teacher scenario and other situations too. |
| njs: | Think of all the professional 3d modellers who have one super-fancy display and one low-res one. Or giving presentations with a laptop and projector -- projectors have way lower resolution than your laptop screen. |
| oxygene: | nicholas: could objects be layouted twice - once in the scene graph, adding hints to the stream down to the DK/Console which help how to handle such corner cases? |
| stefans: | njs: well, there are always ways: you may have your application talk to two display servers (one on each monitor), or you may settle on the lesser resolution. |
| nicholas: | njs: I agree... but would we be any worse off than our competitors? |
| nicholas: | njs: well, those are totally two displays. |
| | stefans agrees |
| nicholas: | njs: projector and screen is not multihead. |
| njs: | nicholas: mm, okay, perhaps |
| njs: | nicholas: you should be able to address them both with one display server, though, I think. |
| nicholas: | njs: but, duh, we'd need multiple displays per server then. |
| stefans: | 'multi head' would mean to fool the user into thinking that the two displays are just one big |
| hunger: | nicholas: Apple works with screens in different resolutions/color depth. |
| nicholas: | njs: so one scene graph, multiple renderings. |
| nicholas: | hunger: seriously? man, Apple is so cool!! |
| njs: | shrug Apple's customers need that :-) |
| hunger: | nicholas: At least they did when they did a presentation about the first power macs in 199x... |
| stefans: | nicholas: and again, multiple renderings (with different resolutions) is only hard if the app has specific requirements such as high quality fonts. |
| oxygene: | hunger: amiga worked with screens in different resolutions/color depths per rasterline shrug |
| BenB: | I think that most multihead setups have different resolutions |
| nicholas: | njs: but apple cheats, don't they? "0.1units" = "1px" for apple. |
| nicholas: | njs: so you can't get a 1in bar on an Apple multihead display with different resolutions, right? |
| BenB: | in my current case, that's a TV and a monitor. or one big TFT and 2 smaller left and right. |
| njs: | nicholas: I dunno. |
| nicholas: | See, multihead is easy if your rendering system is pixels. |
| nicholas: | So we have a choice: multihead support versus real-world units. |
| hunger: | We are getting off topic... |
| czw: | using standard apps like quicktime on my mac, it's not resolution independent (screen vs tv) |
| | stefans thinks 'real world units' is a must |
| hunger: | Do we want multiserver? Seems like the tenor is No. |
| nicholas: | hunger: no. |
| cinap: | hunger: i'm skeptic about security and performans from the milti-server-idea... it's cool... no question... |
| nicholas: | hunger: well, wait. define multiserver. |
| | stefans agrees |
| njs: | what does "multiserver" even mean? |
| stefans: | again, not making it a requirement doesn't imply it won't be possible |
| nicholas: | hunger: 1 program should be able to connect to multiple servers, just like in X... |
| hunger: | Do we want to couple several servers (running on multiple hosts) into one "virtual server". |
| stefans: | nicholas: nah. That is always possible (and doesn't even touch the fresco architecture) |
| nicholas: | hunger: nope. |
| stefans: | hunger: ah. That one I can clearly refuse :-) |
| mourad: | lol :) |
| hunger: | Basically a "multiheaded" environment with each head being managed by its own server. |
| BenB: | hunger: I'd find it nice, and may find applications for it, but I don't feel strongly about it. |
| hunger: | * No multiserver with the above definition. |
| oxygene: | sounds like a big proxy |
| njs: | hunger: no, that seems silly for now |
| | cinap feels like BenB |
| stefans: | hunger: well, but 'multi head' implies a single big scene graph distributed across multiple monitors. That should be managed by a single server |
| stefans: | in fact, I would say 'one scene graph per display server'. |
| stefans: | at least to start with. |
| nicholas: | stefans: agreed. |
| mourad: | okay |
| hunger: | OK, then let's decide on that... |
| hunger: | * One scenegraph per server |
| cinap: | ok |
| oxygene: | and one server per scenegraph |
| cow: | stefans, right, i still want to drive all 3 'graphic cards' with one server to render one scene.. anyways |
| stefans: | can we come back to the location transparency question please ? :-) |
| | hunger sues * so he can find the decissions easily later on. |
| nicholas: | oh, the big one. To CORBA, or not to CORBA? |
| oxygene: | stefans: wrt njs' mails? |
| hunger: | stefan: So far we decided that the server will run ine one machine and a client can connect from another. |
| stefans: | oxygene: yes |
| BenB: | hunger: sounds like X :) |
| stefans: | nicholas: not yet. I think CORBA (or not) could be the answer to the requirements we'll have to settle on |
| nicholas: | BenB: that's because X got it right. |
| hunger: | Do we need to allow for clients being distributed over several hosts? |
| | hunger thinks not. |
| nicholas: | stefans: oops, sorry |
| stefans: | hunger: er, how does that affect fresco ? |
| nicholas: | hunger: huh? |
| mourad: | hunger: why not? |
| | Signoff: rapha_ (Connection timed out) |
| BenB: | hunger: I think you need to be more specific.... |
| BenB: | hunger: do you mean app-app cooperation or ... |
| stefans: | hunger: I mean, if you connect from different addresses to the display server, you'll need different 'server contexts', so the server thinks of you as multiple clients. Whether they are just one (logical) or not doesn't matter. |
| hunger: | mourad: Lets rephrase: Do we need several hosts to talk to the server as one "application" |
| BenB: | display components (ala HTML renderer) |
| stefans: | hunger: why should the server care ? |
| nicholas: | hunger: oh no, are we discussing the definition of application? |
| hunger: | stefan: That's what I meant. |
| stefans: | hunger: what ? |
| hunger: | stefan: I'm trying to come up with requirements we have so that we knwo what we want when we get into the CORBA or not discussion later. |
| nicholas: | stefans: so a client is an application. |
| njs: | hunger: in my model, they'd each have their own connection to the server, but if they share caps freely, then any of the connections can do the same thing. |
| hunger: | stefan: hunger: I mean, if you connect from different addresses to the display server, you'll need different 'server contexts', so the server thinks of you as multiple clients. Whether they are just one (logical) or not doesn't matter. <hunger> stefan: That's what I meant. |
| stefans: | nicholas: hmm, ok |
| nicholas: | njs: hm....... so I could give "permission" to another program to goof with my window on my behalf? |
| stefans: | hunger: the server shouldn't care whether the different contexts it serves are coming from one address space or not, or whether they both talk to each other |
| nicholas: | njs: s/program/client/ |
| njs: | nicholas: if you felt like it. |
| stefans: | hunger: and for that matter, neither does CORBA care |
| hunger: | So is a client an applicaiton? |
| | stefans doesn't care how it is called |
| njs: | I would argue that for the server, a client is a connection. |
| starseeker: | Is this were we get into several programs making up one "interface" for the user? |
| stefans: | njs: fine with me. |
| nicholas: | Yes. |
| hunger: | stefan: We are going to have a CORBA or not debate I think... so wether CORBA can do it or not is not important to me at this point. |
| stefans: | njs: but whether that coincides with 'socket connection' or any other tcp related term is yet to discuss ;-) |
| njs: | stefans: right :-) |
| hunger: | stefan: What do we need? |
| nicholas: | stefan: because you've just precluded the possibility of composition involving components implemented on different machines in the network. |
| stefans: | nicholas: composition of what ? |
| nicholas: | stefan: composition of my GUI. |
| stefans: | nicholas: huh ? Did I ? I didn't mean to. |
| njs: | nicholas: what do you mean "components implemented on different machines"? |
| nicholas: | stefan: I think you did. Did I misread you? about how one client is one connection? |
| nicholas: | njs: my application is on machine "a" but the embedded word document viewer is only available on machine "b". |
| mourad: | okay, so a UI can be made up from components running on different machines? |
| njs: | nicholas: I think that's a totally separate issue. |
| stefans: | nicholas: right now we use that model, right ? One app ('client') holds one 'server context'. It's possible to hook different scene graph chunks up into each other, thus having 'graphical embedding'. |
| starseeker: | nicholas: Is this a reasonable scenario? I want a GUI for my Maxima program, and to build it up I run the framework interface on my machine, a plotting component on another machine, and a PDE package interface on a third - building them all into one GUI which displays on my desktop? |
| nicholas: | stefan: so two clients (different machines) can't come together to provide one ui? |
| hunger: | nicholas: Is the embedded word processor it's one client/application/connection or not? |
| nicholas: | stefans: oh, right. sorry. :) |
| stefans: | nicholas: I don't see any problem with that. Of course, we'll have to talk about security and stuff... |
| nicholas: | starseeker: thus far, Fresco can handle it just fine. |
| nicholas: | starseeker: I mean, as implemented today. |
| mourad: | okay |
| mourad: | what about finding the server? |
| starseeker: | nicholas: Right. I was just trying to illustrate the behavior you were arguing for (I think?) |
| nicholas: | hunger: Uh... no. |
| nicholas: | starseeker: yes. |
| BenB: | it's still unclear where the HTML renderer (or the like) is supposed to be, or if we can even decide/require that offhand. |
| starseeker: | nicholas: It took forever for me to get my head around that. It still feels fragile, even though I suppose there's no reason it should be |
| hunger: | nicholas: It's not? How do you start it then? |
| nicholas: | starseeker: I'm imagining public document viewers (translators even?) that you could plug in to your UI over the internet. (Hey web, move over!) |
| nicholas: | hunger: the servercontext is my program. what's embedded doesn't need a servercontext. |
| stefans: | in X, there is a fixed set of 'objects' the protocol knows about. Fresco is much more extensible. I believe this extensibility implies some form of location transparency. |
| BenB: | I may want to have a PNG renderer (or whatnot) on the display server, but I won't want to have Mozilla running on a pure terminal. |
| starseeker: | nicholas: Our security would have to be darn good for me to trust something like that |
| hunger: | nicholas: How do you have it connected? |
| nicholas: | hunger: I haven't decided. Thus far, it's a CORBA node in my scene graph. After this meeting? Who knows. :) |
| njs: | I think the ability for apps to cooperate like that is nice (though not, I think, as important as the original opendoc/fresco types thought it was), and will probably come out for free if we aim for other desirable features like composability. |
| nicholas: | starseeker: indeed, but CORBA fails to offer us the necessary security. That being a major issue against CORBA. But we're not on that discussion yet. |
| nicholas: | Fresco was originally up against OpenDoc as a compound document architecture. |
| | Signoff: icebird_ () |
| hunger: | nicholas: I think a special "window" to embedd some other client into an application is a reasonable way to go. |
| starseeker: | nicholas: OK. My other concern - are there any application environments out there that could actually make use of such an idea? |
| nicholas: | I'm curious to know whether any of that is going to live on. |
| stefans: | nicholas: yes, and I still think that's a goal (not the competition, but the feature :-) |
| njs: | nicholas: I don't think anyone has proposed changing it |
| hunger: | nicholas: That way the embedded client would get its own servercontext and the server has better control. |
| nicholas: | starseeker: well, read about CDAs, compound document architectures. Even MS-Windows does it with OLE and now COM. |
| hunger: | starseeker: Kparts, bonobo in the free SW world. |
| nicholas: | hunger: ok. we should consider that at some point (soon). |
| njs: | I note that the gnome folks have decided that bonobo was stupid and are killing it |
| nicholas: | lol |
| starseeker: | hunger: Ah. So they would migrate successfully to this type of system? |
| starseeker: | njs : Yep :-) |
| oxygene: | njs: hopefully they kiill the entire project because of stupidity shrug |
| | rapha is now known as rapha|zZZzz |
| hunger: | Can do agree on this: |
| njs: | (not just because it sucked technically, but also because they decided that from a UI point of view, mixing up apps like that was extremely confusing.) |
| starseeker: | nicholas: My main concern is if we don't have some idea in the back of our heads how all the work out there now can migrate without immense pain to Fresco, we get ignored. |
| stefans: | what about extensibility ? New types, etc. I believe that fits into the 'location transparency' issue, I'm just not sure how. |
| starseeker: | nicholas: I figured KDE would like it, given what they've done with koffice and konqueror, but I wasn't sure about Gnome. |
| njs: | starseeker: note that Gnome and KDE didn't exist just a few years ago. And think about how many GTK+/Qt apps there are now... I don't think migration is actually critical. |
| nicholas: | starseeker: that's another point. Fresco has claimed in the past that backwards compatibility was impossible due to the complete redesign of the software involved, therefore there should be no attempt to provide support for legacy applications. |
| hunger: | A client will hold one "connection" to the server (call it servercontext if you want) and can embedd other clients through some special graphic which holds its own "connection"? |
| njs: | as for providing support for legacy applications, that's an entirely different matter; all you really need is a vnc viewer. Better would be to have a rootless X server. But neither really depends on anything special from the Fresco server. |
| hunger: | starseeker: At least not at this point... |
| starseeker: | njs: Yes, but the momentum and work put in in those few years is monumental. |
| stefans: | hunger: er, is it really the client that 'can embedd other clients' ? |
| oxygene: | hunger: that would indicate some serialization of the scene graph as render stream which can be further processed |
| BenB: | hunger: doesn't that break the whole composition idea? |
| starseeker: | nicholas: Eeeep. |
| nicholas: | hunger: should we have a differing notion of clients and components? |
| njs: | starseeker: sure. But they've thrown away most of that work already; that's how it works in software :-) |
| starseeker: | njs: Gnome has. AFAIK, KDE has actually stuck with it for quite a while now. Or did I miss something? |
| hunger: | stefans: well, someone requests something else to be embedded. I think that a client will do that most of the time, don't you? |
| njs: | hunger/nicholas/stefans: I think we're getting confused about this. Talking about connections in a vacuum, with no networking architecture around them, doesn't make any sense. |
| | nicholas is with njs. |
| hunger: | nicholas: I think it would be better if a client wouldn't need to care wether it is run in a window or embedded. |
| stefans: | hunger: hmm, right, the request comes from the client. But the embedding is really about scenegraphs, no ? |
| nicholas: | hunger: yeah, but that's not gonna work... |
| BenB: | njs: well, i think it's important to define the requirements fot eh archtiecture... |
| starseeker: | hunger: But mightn't the client want to present a different interface for embedded vs. standalone? |
| njs: | BenB: yes, but we're not doing that :-) |
| stefans: | nicholas: what's not going to work ? |
| nicholas: | stefans: pretending that clients and components are indistinct. |
| stefans: | nicholas: you mean the application has to care about whether it is stand alone or embedded ? |
| nicholas: | stefans: yes. |
| starseeker: | stefans: Whether is has to or not, some of them probably will |
| stefans: | nicholas: hmm, I don't see that. But that's dragging us even further off topic. May be another time (or later). |
| hunger: | nicholas: It needs to present its menu, statusbar, etc. differntly. |
| BenB: | njs: I think that my question of where the componets actually practically are, would be part of those requirements. |
| hunger: | nicholas: I think we could handle that in a generic way so that both embedded and non-embedded usage is possible. |
| nicholas: | hunger: OLE worked by taking the embedded apps menu bar and adding it to the parents menubar. Similarly with the statusbar (multi-part status bars). |
| nicholas: | hunger: but we need some decision on how to handle it. |
| stefans: | hunger: well, the server just provides some 'context' into which the client can hang these resources. Whether they are global or embedded shouldn't make a difference. |
| hunger: | stefans: That's what I was trying to say in my laymen's terms. |
| mourad: | okay I think everyone agrees: * embedding is a good thing to have |
| stefans: | nicholas: I'd keep that open. I think it would be good to think further about it, but I don't believe the ramifications are as critical as the other questions |
| stefans: | mourad: thanks :-) |
| | BenB gets tired, 1:30 here. |
| hunger: | So no consnsus on: |
| hunger: | A client will hold one "connection" to the server (call it servercontext if you want) and can embedd other clients through some special graphic which holds its own "connection"? |
| nicholas: | stefans: if nothing else, it changes how a client connects. (How can I embed a program that doesn't know it's supposed to be embedded? It'll simply connect to the server as a standard app!) |
| hunger: | But * embedding is good? |
| njs: | hunger: I just don't know what you're talking about, if I'm supposed to pretend that we have no other network architecture in mind. |
| stefans: | nicholas: indeed, good point. That needs some special support. |
| stefans: | nicholas: may be just a special convention as to how to start embeddable applications to be really embedded. |
| mourad: | we are talking about requirements still, right... lets' fill in the details later |
| hunger: | Is there consensus on "We want embedding but need to think further about the details"? |
| nicholas: | stefans: sure. and how a loading embedded application will inform the server that it is the requested resource. |
| nicholas: | hunger: i vote yes. |
| mourad: | yes |
| | cinap too |
| stefans: | ok, so I think some form of embedding is a requirement, albeit the exact mechanism to support that isn't designed yet. |
| stefans: | heh |
| hunger: | OK. Let's move on then... |
| njs: | maybe "Embedding is a nice thing to have, but the details will depend on other aspects of the architecture" |
| nicholas: | mind you, CDA (OpenDoc) fell flat on its face... |
| stefans: | nicholas: right |
| hunger: | * Embedding is a nice thing to have, but the details will depend on other aspects of the architecture |
| nicholas: | mind you twice, so did Fresco (OpenDoc's competitor)... |
| stefans: | nicholas: heh |
| starseeker: | What's next hunger? |
| hunger: | What about FLEXIBILITY/EXTENSIBILITY? |
| stefans: | hunger: yeah, thanks. |
| nicholas: | MODULARITY? |
| hunger: | How can a application extend what is there? |
| BenB: | yes |
| nicholas: | 1. by providing an embeddable component? |
| starseeker: | In what sense? Custom rendering? |
| stefans: | by that I mean what kind of data should be exchanged between client and server ? object model ? type system ? How is the interface (protocol) be defined ? |
| BenB: | nicholas: how do other apps discover and use it? |
| mourad: | ah? like a tree widget :)? |
| nicholas: | BenB: uh oh. :) |
| BenB: | nicholas: where does it live? |
| nicholas: | BenB: spaghettios! :) |
| BenB: | heh |
| hunger: | Can an application create new graphics (that are not built up from existing ones)? |
| cinap: | hunger: i think this is like embedding... providing it's own objects... like the clock-demo... but maybe not on the scene-graph-layer... |
| njs: | stefans: that's not a requirements question |
| stefans: | hunger: that one I would rule out. Because it requires a distributed scene graph. Does it not ? |
| starseeker: | hunger: I would say yes - existing ones may not be comphrensive enough |
| njs: | stefans: you can't infer that sort of thing from first principles :-) |
| stefans: | njs: ok, you cought me :-) |
| hunger: | cinap: This heavily influences the communication architecture. |
| njs: | stefans: :-) |
| starseeker: | hunger: opps, nevermind :-) |
| rohara: | is this extensiblility of the client or the server or both? |
| hunger: | stefan: I'm strongly leaning that way too, if only for securioty/robustness reasons. |
| stefans: | hunger: ok, you could upload some script, so it's not entirely impossible |
| cinap: | for the requirements: * extensibility? yes! of course! |
| nicholas: | (for example, if they need custom rendering, what makes it necessary that they have a Graphic? why could they simply use a Path?) |
| njs: | I think apps do need to be able to, say, add new widgets; this should happen very rarely, but sometimes it will be necessary. I think the proper way to do this is to have a server-side widget that acts as a slave to the client, and insulates the scene graph from the nastiness of remoteness. |
| hunger: | stefan: That's using an existing graphic... ;-) |
| nicholas: | Graphics are for custom Layout. |
| stefans: | nicholas: hmm, paths can only be drawn inside graphics |
| hunger: | njs: We are not yet talking about widgets. |
| njs: | (i.e., it should be possible, but as something bolted on later. For the basic design, we can and should assume that the scene graph lives entirely in the server.) |
| nicholas: | stefans: Berlin::Path, yes, but not Figure::Path. Figure::Path is a Graphic that draws a Berlin::Path. :) |
| stefans: | nicholas: whoever wants to draw a path needs a DrawingKit |
| | TheFifthPope (~axis@dhcp024-209-224-088.cinci.rr.com) has joined channel #fresco |
| hunger: | So we will not support client-side graphics? |
| | cinap agrees to njs |
| stefans: | nicholas: indeed. But if you are requesting a Figure::Path you are talking about composition, which is not what hunger asked about. |
| nicholas: | right. My comment was simply that the only need for a custom Graphic is for custom Layout. |
| stefans: | hunger: right. I believe that's our first big change. Isn't it ? |
| BenB: | hunger: the question is: do we have to? |
| njs: | hunger: not directly, seems to be the consensus? I've certainly been advocating that for months now :-) |
| cinap: | hunger: of course... but maybe not on this generic level like the scene-graph... maybe some proxy-graphic... |
| hunger: | * No clientside graphics. |
| nicholas: | Hold on... |
| BenB: | hunger: wait... |
| mourad: | :) |
| hunger: | BenB: Sorry, I don't get what you are trying to say. |
| BenB: | hunger: there were cases where I had to implement graphics to do what I need, ... |
| nicholas: | Can we make client-side graphics a possibility for when the user allows them? Suppose the user understands that they're allowing something insecure, but will allow it anyways. hm? |
| stefans: | well, we may still have some 'direct rendering' infrastructure, but that one would bypass the 'official' communication protocol (CORBA or not) |
| BenB: | because the server simply didn't provide a way to do it. |
| hunger: | BenB: Like what? |
| BenB: | hunger: simple example: reaction to key presses (atm) |
| stefans: | BenB: the current server is totally incomplete, don't forget that. |
| BenB: | stefans: yes, sure. |
| BenB: | stefans: but at one point, you argued (IIRC) that the client should be able to react to key presses directly. |
| nicholas: | Client-side graphics are good for me, purely for debugging. Could I simply have written my own small Kit? |
| hunger: | BenB: clientside graphics are a hazard for robustness... |
| stefans: | nicholas: good point. Well, can that be restricted to the local case (similar to Xshm ?) |
| njs: | nicholas: I don't see the point of that. a proxy graphic approach needn't be insecure, and it makes life simpler to not have to support any other way of doing client-side graphics... |
| BenB: | hunger: I realize that. |
| stefans: | BenB: yes, and I'm still thinking that event handling may be done by the client. |
| ryanarn: | is someone logging this meeting? It is out of my league but I'd like to read it later. |
| | cinap thinks of building something like a seperate and protected extension layer |
| nicholas: | stefans: perhaps instead, we should allow users to register their own kits. |
| hunger: | ryanarn: Yes. |
| ryanarn: | hunger: thanks |
| nicholas: | njs: I changed my mind, i don't want clientside graphics again. But I do want user-provided Kits. :) |
| BenB: | but still there were a ton of things the server can't do and the app wants to do. can we be sure ther won't be any of those? |
| stefans: | nicholas: hmm, tasty. You may kits that provide graphics with back-ports designed for the client to get in ? |
| hunger: | nicholas: That brings in the same robustness problems. |
| stefans: | s/may/mean/ |
| BenB: | (after the server is complete) |
| nicholas: | stefans: well, Kits that contain those fancy Foomatic Graphics my client needs. |
| nicholas: | hunger: no worse than the rest of Fresco code. |
| stefans: | nicholas: oh, sure. |
| stefans: | well, so we are talking about extensibility. |
| nicholas: | extensiblity through Kits is something we got Right. |
| stefans: | kits can provide new implementations of known interfaces. Can they also add new interfaces ? |
| stefans: | nicholas: yes ! |
| njs: | nicholas: I suppose, thought it doesn't seem to be a common need, or a big deal to support. (Kits are currently extensions anyway, why not let people drop in their own if they want, it's not like we run as root...) |
| hunger: | stefan: Sure, you can always add your own Kit:-) |
| njs: | nicholas: I think we agree :-) |
| hunger: | Consensus on "No clientside graphics but the suer should be able to install kits for himself"? |
| BenB: | the problem is that the app has no access to the server. |
| stefans: | njs, nicholas, hunger: I think the key issue here is that the protocol has to be designed to support extensibility. It needs some form of type system / object model. |
| nicholas: | BenB: That's not a problem, that's the good part! |
| nicholas: | BenB: that allows the user to decide whether to accept the potentially unsafe code for themselves. |
| stefans: | heh, I agree |
| BenB: | if we have display and app running on different machines, there is no practical way (in the general case) to install anything app-specific on the display |
| stefans: | BenB: right. But don't forget that the user is local with respect to the display server, not (necessarily) the app. |
| nicholas: | There's a worse issue. |
| nicholas: | Should we allow Kits to run on foreign computers? |
| stefans: | BenB: so if he wants to run an app that has special requirements, he can upgrade his display server. (such as installing a new mozilla plugin) |
| nicholas: | (Say the Kit is written for Solaris, but my server is Linux.) |
| stefans: | nicholas: 'foreign' ? |
| BenB: | stefans: yes, that's important for customization to user needs (did you mean that?), but it doesn't help apps with extending server missing functinality. |
| nicholas: | Now what do we do? Who loads the Kit? Servers load kits. But we already decided against allowing servers to group together and form 1 virtual server. |
| njs: | I think it should only be the very most nasty apps that need custom kits, and everyone should glare at them a lot. Like, what you'd think of an X app that required you to install a special server extension. |
| BenB: | stefan: I disagree that you can force the display to have certain extensions just to use a certain app. |
| | ryanarn is now known as ryanarnZz |
| hunger: | We decided on "one scenegraph per server", so the kits providing those graphis need to be with the server. |
| stefans: | njs: of course, the assumption is that the set of available kits is already fairly complete |
| BenB: | stefan: this will end up being a hassle, then you can just as well have the app on the local machibe. |
| stefans: | njs: (i.e. well tested and all) |
| njs: | stefans: right |
| stefans: | nicholas: what do you mean by 'written for solaris' ? |
| oxygene: | stefans: compiled on for solaris/sparc64 instead of linux/arm |
| stefans: | nicholas: I think that there should be a specific and explicit procedure to install new kits for a given server. |
| nicholas: | stefans: I was worried about a Kit running on computer 'a' collaborating with a Fresco server on machine 'b'. |
| njs: | It seems to me that something like mozilla won't require a new kit anyway, since it probably won't need any new server side graphics, it could just be a client that interacts with other clients, and creates graphics in the server on their behalf. |
| oxygene: | stefans: no sources available |
| stefans: | nicholas: the user has to be aware of that, if only it is a potential security issue. |
| nicholas: | stefans: ok, so then it simply won't be possible. That's fine. |
| stefans: | oxygene: oh, binary (in)compatibility |
| stefans: | nicholas: I thought kits were running in-process. Isn't that so ? |
| nicholas: | stefans: Yes they are. So that's fine. |
| stefans: | nicholas: yes |
| BenB: | njs: I'm not so sure, if mozilla can run remotely. mplayer most likely can't. |
| BenB: | njs: (remember, mozilla is nasty, assumes pixel layout etc) |
| stefans: | nicholas: so each application that requires non-installed kits will raise a flag and ask the user to install a kit from url x.y.z |
| nicholas: | BenB: even MPlayer uses, say, GLX or XVideo which are "extensions" that ship with X. |
| stefans: | nicholas: the rest is up to the user |
| hunger: | * No clientside graphics but the user should be able to install kits for himself. |
| nicholas: | stefans: yep. |
| nicholas: | sold. |
| stefans: | fine |
| njs: | BenB: eh, I'm actually okay with letting clients get at pixel information if they want it. vncviewer is going to want the same thing... |
| BenB: | the question is: can the fresco server have such a complete API and functionality that almost no app will need kits to be installed? |
| stefans: | though I very much like the ability to prototype in python. But that's a different issue, and can be solved differently. |
| nicholas: | the answer is yes, or we haven't done our jobs. |
| BenB: | njs: but it will need lots of bandwidth. I just say I don't know, I surely want mozilal to run remotely. |
| hunger: | Sorry to be hurrying all of you, but I'm getting tired;-) |
| | E0x (~moya@147satb5.codetel.net.do) has joined channel #fresco |
| hunger: | Hi E0x. |
| E0x: | hi hunger |
| njs: | one of the goals I had in mind for my protocol, actually, was to be sufficiently efficient that when push came to shove, remote widgets implemented X-style would actually be possible. Rare and comparatively inefficient, but not dramatically worse than X performance-wise. |
| stefans: | hunger: hmm, ok. We are making good progress, though, no ? |
| hunger: | Clientside widgets that are compositions of existing graphics are no problem... |
| | nicholas is very pleased with what we've accomplished! |
| | hunger is too. |
| stefans: | njs: well, a 'remote widget' could just be a hook into the server holding a little scene graph |
| nicholas: | njs: that'd be wicked, of course! |
| hunger: | Anything about extensibility/flexibility I forgot? |
| BenB: | nicholas: I am not so sure about being so complete. |
| hunger: | BenB: Neither am I... but it seems to work pretty well with X. |
| BenB: | nicholas: what about games, for example? they'll want to have precise control over UI and input. does fresco give that? |
| nicholas: | BenB: well, we're aren't today. in theory that's because we're not finished. in practice... we may never find out... |
| stefans: | hunger: well, we have to get closer to the protocol, and extensibility is an important requirement for it. It's not done yet. |
| nicholas: | BenB: then provide them with an API, in Fresco, that does! |
| BenB: | hunger: X works totally differently, everything is done by the client. |
| hunger: | stefanS_ So bring up the next issue, please. |
| njs: | BenB: that's th |