From seefelds at MAGELLAN.UMontreal.CA Tue Jun 15 14:30:08 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: docs: a reference manual In-Reply-To: References: Message-ID: <37666370.39CC399F@magellan.umontreal.ca> Eugene wrote: > Mmmkay. Can you let me know some URL's for docbook, or pass me on some > information so that I can have a play, and get it generating docs in the > right format. Here are a couple of links which might be of interest: beside these, I think the GNOME pages contain information about docbook, too Regards, Stefan > Also, when are the new deb's hitting the web? once the release is finished :-) Should be a matter of weeks, probably by the end of this month. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 15 21:21:27 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: update Message-ID: <3766C3D7.348B565@magellan.umontreal.ca> Ok, I finished yet another step towards the next release. I just commited the changes containing among others the MVC approach we were discussing recently. To build, please set the LD_LIBRARY_PATH variable *before* compiling so it contains berlin's /lib directory. Then run make config and make. This should create within /test the server and two clients, namely button and draggable. Try them. Button is now quite a bit faster due to the fact that all the objects reside within the server. Draggable is merely a test for some 'shell' like widget we could put into the ApplicationKit. Anyway, I think with this we are really ready for a release, I don't know whether Graydon wants to put in his TextKit before. Best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Wed Jun 16 07:33:01 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:33 2005 Subject: rpath Message-ID: <19990616003301.A4404@localhost> It seems that some libraries are linked with -rpath. I don't know exactly what this does, but Debian policy frowns bitterly upon it. Anyway, it doesn't need to be changed, the configure script just needs to figure out a more intelligent -rpath ;). I can't find any docs on the subject, otherwise I'd change the thing myself. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From leslie at village.vu.edu.au Wed Jun 16 07:41:13 1999 From: leslie at village.vu.edu.au (Alistair Leslie) Date: Fri Feb 25 22:23:33 2005 Subject: rpath In-Reply-To: <19990616003301.A4404@localhost> References: <19990616003301.A4404@localhost> Message-ID: On Wed, 16 Jun 1999, Aaron Van Couwenberghe wrote: > It seems that some libraries are linked with -rpath. I don't know exactly > what this does, but Debian policy frowns bitterly upon it. > Anyway, it doesn't need to be changed, the configure script just > needs to figure out a more intelligent -rpath ;). I can't find any docs on > the subject, otherwise I'd change the thing myself. rpath is really a linker option. All it does is adds a path in the executeable so it can find the dynamic libraries it needs, at runtime, that arent in the usual spots. Hope this helps Alistair -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Wed Jun 16 12:29:23 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: rpath In-Reply-To: <19990616003301.A4404@localhost> References: <19990616003301.A4404@localhost> Message-ID: <376798A3.2C72C871@magellan.umontreal.ca> Aaron Van Couwenberghe wrote: > > It seems that some libraries are linked with -rpath. I don't know exactly > what this does, but Debian policy frowns bitterly upon it. Could you please provide more details ? What has the Debian policy to say about this ? -rpath is passed to the linker for the following reasons: We have now hierarchies of libraries, i.e. the plugins (mudules) need different libraries to build and run. I'd really like to hide those dependencies in the sense that I'd like to link my final executable only to those libraries it directly depends on. Example: libDrawing depends on libGLtt. server, which needs to link to libDrawing, should not care what libraries libDrawing is implemented upon. As I understand this is possible since the linker finds the dependencies himself. Though we have to provide information about where to find these libs. And that's exactly the purpose of '-rpath'. It works like LD_LIBRARY_PATH. Now there are two problems. First, as you might have detected, I didn't set the rpath variable as used by our build process via configure. So it now contains garbage (my path when I build it). Second, for some reason it seems not to work. If anyone could figure that out, that would be fine. The linker complains that he can't find the libraries (libGLtt for example) and that I should have used '-rpath'. But I did !! However, if I set the LD_LIBRARY_PATH variable so it points to the correct directory the linker uses this info and gets to the libs. Anyway, that's a work around and not a solution. So, please, if you see what's wrong with my Makefiles, please let me know or correct it yourself. Thanks, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Wed Jun 16 14:56:13 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:33 2005 Subject: und nochmal... In-Reply-To: <376798A3.2C72C871@magellan.umontreal.ca> References: <376798A3.2C72C871@magellan.umontreal.ca> Message-ID: <99061616585801.05596@alcatraz168> Hallo! Das C++-Buch, das Du mir empfohlen hast, ist grossartig! Ich hab's mir heute gekauft. Es hat nur einen einzigen Nachteil: Es steht soviel drin das ich nicht wusste, das ich am Besten nochmal ganz von Vorne anfange :-) Gruss, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Wed Jun 16 15:03:50 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:33 2005 Subject: und nochmal... In-Reply-To: <99061616585801.05596@alcatraz168> References: <99061616585801.05596@alcatraz168> Message-ID: <99061617042102.05596@alcatraz168> Sorry, this was not meant to end up here,,, -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From tim at desert.net Wed Jun 16 18:48:36 1999 From: tim at desert.net (Thimble Smith) Date: Fri Feb 25 22:23:33 2005 Subject: rpath In-Reply-To: <376798A3.2C72C871@magellan.umontreal.ca> References: <19990616003301.A4404@localhost> <376798A3.2C72C871@magellan.umontreal.ca> Message-ID: <19990616114836.B84504@desert.net> At 08:29, 19990616, Stefan Seefeld wrote: >-rpath is passed to the linker for the following reasons: I've seen other projects use the GNU libtool to make using shared libraries clean and portable. I have not used it in anything, but I think it might be worth looking into. Tim -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Wed Jun 16 23:09:55 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:33 2005 Subject: Congratz! In-Reply-To: <3766C3D7.348B565@magellan.umontreal.ca> References: <3766C3D7.348B565@magellan.umontreal.ca> Message-ID: <99061701123200.06237@alcatraz168> Hi! I just got button and draggable to run! Great work, guys. Both work nice and fast. Just on question: Are they supposed to run at the same time? If I start draggable and the button the draggable stops working. What is still missing for the second berlin release? Best Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Thu Jun 17 00:46:23 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: Congratz! In-Reply-To: <3766C3D7.348B565@magellan.umontreal.ca> References: <3766C3D7.348B565@magellan.umontreal.ca> <99061701123200.06237@alcatraz168> Message-ID: <3768455F.76BE9E23@magellan.umontreal.ca> Tobias Hunger wrote: > I just got button and draggable to run! Great work, guys. Both work nice and > fast. > > Just on question: Are they supposed to run at the same time? If I start > draggable and the button the draggable stops working. Yeah, that's something we have to investigate further. However, there are problems which I can only fix after we decided the exact strategy/design we use for shared resource management. Things like pointer grab etc... I'm not yet there, I need to think about it further. Yet I consider the current state sufficiently stable and the design self contained to make it a release. Graydon may or may not finish the next step for the TextKit (it looks quite close already) so we could equip the buttons with real labels. That would certainly be catchy. > What is still missing for the second berlin release? I think that's it. Just removing the obsolete parts of the old release and updating the home page to reflect the current state and we can ask Aaron to upload the stuff to debian. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Thu Jun 17 22:07:01 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff Message-ID: <19990617180701Q.graydon@pobox.com> hey y'all, I met with mike shaver who is a big cheeze with mozilla.org last night with a bunch of local geeks, and we talked a little about what berlin can rip out of mozilla. thought I'd pass along the findings: (1) libNSPR has some very interesting sounding stuff in it with respect to system level wrappers. mozilla is ported to just about everything you can possibly imagine, and NSPR is their equivalent to our libPrague. Worth looking at. (2) the XPCom-object-as-a-Corba-object approach sounds perfectly reasonable for embedding a mozilla HTML frame as a berlin widget, and it mirrors what gnome's fiddling with. however the low level layout protocol (interfacing the gecko layout with fresco layout) sounds a little more complex than I'd like. Not sure if that'll work. needs much reading. (3) they have a very cool sounding out-of-process JVM component which thunks through a shared memory segment or some such fun trick for doing really safe almost-as-fast-as-in-process-but-not-so-dangerous java. This sounds extremely cool and I want to look into it. I'm quite concerned that we're endangering our server by loading it up with too much stuff. (4) mike is quite proud of their javascript engine, especially the XPConnect mechanism, which apparantly does some fancy automatic wrapping of XPCom objects to let you make javascript calls into their vtbls. (5) apparantly their netlib is very nice and encapsulated, and has some good content loaders for various internet protocols. (6) same for their image library. brent: might want to try stealing it for another future imageKit. (7) we didn't get very far into discussing XUL, which is their XML DTD for defining the user interface as a nice little XML document, but it sounded pretty mature (though highly javascript dependent). -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Thu Jun 17 22:49:20 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff Message-ID: <21D757CECBD2D211AD5D00105A2974A73487A9@EXCHANGE> > > hey y'all, I met with mike shaver who is a big cheeze with > mozilla.org > last night with a bunch of local geeks, and we talked a little about > what berlin can rip out of mozilla. thought I'd pass along the > findings: > I've worked with Mozilla a bit during Josip Rodin and my work to build a set of Debian packages for it. I know Jordan is also very familiar with Mozilla's inner workings. > (1) libNSPR has some very interesting sounding stuff in it with > respect to system level wrappers. mozilla is ported to just about > everything you can possibly imagine, and NSPR is their equivalent to > our libPrague. Worth looking at. > It's a pretty neat idea. If you visit their website, you can see the basic design. A few things seem to be implemented sub-optimally, mainly because of the lack of consistency between C++ compilers on different platforms. > (2) the XPCom-object-as-a-Corba-object approach sounds perfectly > reasonable for embedding a mozilla HTML frame as a berlin widget, and > it mirrors what gnome's fiddling with. however the low level layout > protocol (interfacing the gecko layout with fresco layout) sounds a > little more complex than I'd like. Not sure if that'll work. needs > much reading. > Would this mean wrapping their XPCom objects inside a Corba widget of some kind? As you have pointed out before, Mozilla's XPCom is *not* CORBA :) > (6) same for their image library. brent: might want to try > stealing it > for another future imageKit. > Absolutely. Anything to avoid having to program myself :) > (7) we didn't get very far into discussing XUL, which is > their XML DTD > for defining the user interface as a nice little XML document, but it > sounded pretty mature (though highly javascript dependent). Okay -- I agree that this sounds like a neat idea, and it is an excellent way of providing configurable user interfaces. However, my experience with this implementation (mozilla's) is that it is extremely slow. I mean it is SLOWWWW. I can open up my GTK mozilla (built from a current CVS pull) and watch as it leisurely resizes widgets and windows until it builds the normal Netscape screen. It looks nice when done, but I think it will be a problem performance-wise, unless they create a nice little JIT-compiler for their javascript.... -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Fri Jun 18 00:33:23 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:33 2005 Subject: IRC Issues Message-ID: <21D757CECBD2D211AD5D00105A2974A73487DB@EXCHANGE> I'd like to chime in regarding the Python test scaffold issue from the IRC chat. I think this would be a great idea. I'm in the process of learning Python now, hoping to implement something similar for work. This is cool for at least two (2) reasons -- our good friend Duncan of OmniORB fame is in the process of creating Python bindings for good 'ol omniorb, and will be releasing them when they work. (I know this because he posted it to the Python-ORB list that I also keep an eye on.) The other (of the two) reasons this is cools is that we can use JPython to generate real-live Java bytecode from python, which means we could use an existing Java ORB, bound to Python output by JPython. So between this and Duncan's work, I think we may have a good contender for an object-oriented, CORBA-savvy scripting tool. Plus, it's open source (so a third cool thing) and not under the control of Sun or MS and should be closer to "The Right Thing (TM)" because it is not beholden to marketing droids. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 18 01:14:01 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <19990617180701Q.graydon@pobox.com> References: <19990617180701Q.graydon@pobox.com> Message-ID: <37699D59.235A887D@magellan.umontreal.ca> Graydon Hoare wrote: > (1) libNSPR has some very interesting sounding stuff in it with > respect to system level wrappers. mozilla is ported to just about > everything you can possibly imagine, and NSPR is their equivalent to > our libPrague. Worth looking at. Good. I'll do that and see what I can use. You are all invited to do the same. Luckily most of Prague is about quite independant concepts so modifying and enhancing them doesn't disturb too much at a time. > (2) the XPCom-object-as-a-Corba-object approach sounds perfectly > reasonable for embedding a mozilla HTML frame as a berlin widget, and > it mirrors what gnome's fiddling with. however the low level layout > protocol (interfacing the gecko layout with fresco layout) sounds a > little more complex than I'd like. Not sure if that'll work. needs > much reading. I sure have to look into that but as we already discussed, I'v no idea what a widget is really. I mean, as I see it a 'HTML widget' in Berlin would be (much like any other widget) just a part of the scene graph. The only reason for which we call it 'one thing' is that there might happen to exist some 'constructor' in terms of a factory method which returns the root node of that particular thing. So, an XML parser would read a HTML file and build a standard Berlin DAG of Graphics out of it which we then link in somewhere. Is this what you call a HTML widget ? Then I don't know what your concern about layout is since all graphics behave well as citicens in the berlin community. > (3) they have a very cool sounding out-of-process JVM component which > thunks through a shared memory segment or some such fun trick for > doing really safe almost-as-fast-as-in-process-but-not-so-dangerous > java. This sounds extremely cool and I want to look into it. I'm quite > concerned that we're endangering our server by loading it up with too > much stuff. Yeah. We could start this as a subproject. Whether this will end up as a coprocess which uses SHM for efficiency or just another thread is a technical detail at this point. I think a coprocess makes a lot of sense since a buggy JVM can't hurt Berlin this way and there is not much data to be shared anyway between it and the display server. > (4) mike is quite proud of their javascript engine, especially the > XPConnect mechanism, which apparantly does some fancy automatic > wrapping of XPCom objects to let you make javascript calls into their > vtbls. well, since we use CORBA, this looks easy, no ? > (5) apparantly their netlib is very nice and encapsulated, and has > some good content loaders for various internet protocols. Great. The protocol classes in Prague are a bit rudimentary. I basically wrote down the interfaces (based on sockstream). Would be nice to finish this stuff up. > (6) same for their image library. brent: might want to try stealing it > for another future imageKit. > > (7) we didn't get very far into discussing XUL, which is their XML DTD > for defining the user interface as a nice little XML document, but it > sounded pretty mature (though highly javascript dependent). Nice. Sounds all pretty reasonable and well worth some efford for release 0.2 :-) Regards, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Fri Jun 18 04:30:19 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:33 2005 Subject: Congratz! In-Reply-To: <3768455F.76BE9E23@magellan.umontreal.ca> References: <3768455F.76BE9E23@magellan.umontreal.ca> <3766C3D7.348B565@magellan.umontreal.ca> <99061701123200.06237@alcatraz168> Message-ID: <19990617213019.A1399@localhost> On Wed, Jun 16, 1999 at 08:46:23PM -0400, Stefan Seefeld wrote: > > What is still missing for the second berlin release? > > I think that's it. Just removing the obsolete parts of the old release > and updating the home page to reflect the current state and we can ask > Aaron to upload the stuff to debian. > > Stefan Basically. I'm doing a dist-upgrade tonight so maybe berlin will build for me again tomorrow. Perhaps my tree is messed up, but I've net been able to build a working berlin for about a week now. Anyway, I've got all the packaging scripts ready to go. As soon as I've got a building tree I've got debian packages. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 18 07:16:42 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <19990617180701Q.graydon@pobox.com> References: <19990617180701Q.graydon@pobox.com> <37699D59.235A887D@magellan.umontreal.ca> Message-ID: <3769F25A.B2FED7B4@wserv.com> Stefan Seefeld wrote: > > Graydon Hoare wrote: > I sure have to look into that but as we already discussed, I'v no > idea what a widget is really. I mean, as I see it a 'HTML widget' > in Berlin would be (much like any other widget) just a part of the > scene graph. The only reason for which we call it 'one thing' is > that there might happen to exist some 'constructor' in terms of a > factory method which returns the root node of that particular thing. There are actually three peices to the 'HTML widget', a parsing engine, a layout engine and a rendering engine. The layout engine is the ultimate in mixing, moving, growing, shrinking, packing and pushing visable objects. Their layout engine could be used by basically everything including the actual desktop widget (place icons on desktop), folders (place icons & text in an area), dialogs (place other widgets and text in a space), a text system (format text in a space), etc. Basically, we could make Mozilla the interface everything runs from. I'm sure you've seen the whole broadway, "run X inside your web browser" idea, well this is just one step further and saying, "run berlin as your object browser". I'd almost go as far as to say, Mozilla (or rather a mutation of it) could handle all aspects of the scene graph itself. Mozilla has done a fairly good job at modularization as well, we could use their libraries without having to change them and eliminate the problem of merging changes from them as time goes on. > > (4) mike is quite proud of their javascript engine, especially the > > XPConnect mechanism, which apparantly does some fancy automatic > > wrapping of XPCom objects to let you make javascript calls into their > > vtbls. > > well, since we use CORBA, this looks easy, no ? Actually their JavaScript engine is nice, I have to admit. I'm not big on scripting languages in general, however JavaScript is easy to write for and is quite powerful. They have compltely seperated the JavaScript engine from Mozilla. I remember hearing about someone running a standalone javascript parser. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From j.w.greven at student.utwente.nl Fri Jun 18 15:02:47 1999 From: j.w.greven at student.utwente.nl (Wilco Greven) Date: Fri Feb 25 22:23:33 2005 Subject: build problems Message-ID: <19990618170247.A2996@wicky.lostparadise.nl> I'm having problems comiling Warsaw. When the build process wants to compile ServerContextSK.cc it gives a lot of errors starting with: ServerContextSK.cc: In method `void _0RL_pc_1125adfc4b2d2d3b_00000000::unmarshalReturnedValues(class GIOP_C &)': ServerContextSK.cc:133: no method `ClientContext::unmarshalObjRef' The same errors show up for classes Stage LifeCycleObject and FactoryFinder. I've looked in the ServerContextSK.cc and saw that these classes are only declared. What should I do to fix it? I'm using Debian potato which is completely up to date. Wilco -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 18 13:56:51 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: build problems In-Reply-To: <19990618170247.A2996@wicky.lostparadise.nl> References: <19990618170247.A2996@wicky.lostparadise.nl> Message-ID: <376A5023.E1DE1B4A@magellan.umontreal.ca> Wilco Greven wrote: > > I'm having problems comiling Warsaw. When the build process wants to > compile ServerContextSK.cc it gives a lot of errors starting with: > > ServerContextSK.cc: In method `void >_0RL_pc_1125adfc4b2d2d3b_00000000::unmarshalReturnedValues(class GIOP_C &)': > ServerContextSK.cc:133: no method `ClientContext::unmarshalObjRef' > > The same errors show up for classes Stage LifeCycleObject and FactoryFinder. > I've looked in the ServerContextSK.cc and saw that these classes are only >declared. > What should I do to fix it? > > I'm using Debian potato which is completely up to date. seems not. what you see is a problem with the old omniidl2 which didn't manage to handle interdependencies. The current version (2.7.1) however does. We had a couple of discussions since we applied different patches which accidentally removed this patch, so if I recall correctly it is something like 2.7.1-4 from debian which corresponds to a correct package. Good luck, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Fri Jun 18 13:58:40 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:33 2005 Subject: build problems In-Reply-To: <376A5023.E1DE1B4A@magellan.umontreal.ca> References: <376A5023.E1DE1B4A@magellan.umontreal.ca> Message-ID: <99061816010500.07875@alcatraz168> On Fri, 18 Jun 1999, Stefan Seefeld wrote: > Wilco Greven wrote: > > > > I'm having problems comiling Warsaw. When the build process wants to > > compile ServerContextSK.cc it gives a lot of errors starting with: > > > > ServerContextSK.cc: In method `void >_0RL_pc_1125adfc4b2d2d3b_00000000::unmarshalReturnedValues(class GIOP_C &)': > > ServerContextSK.cc:133: no method `ClientContext::unmarshalObjRef' > > > > The same errors show up for classes Stage LifeCycleObject and >FactoryFinder. > > I've looked in the ServerContextSK.cc and saw that these classes are only >declared. > > What should I do to fix it? > > > > I'm using Debian potato which is completely up to date. > > seems not. what you see is a problem with the old omniidl2 which didn't >manage > to handle interdependencies. The current version (2.7.1) however does. > We had a couple of discussions since we applied different patches which >accidentally > removed this patch, so if I recall correctly it is something like 2.7.1-4 >from debian > which corresponds to a correct package. > > Good luck, Stefan> Wilco Greven wrote: Actually you need the omniorb, omniorb-dev, omniorb-doc 2.7.1-6 debs. I got it from debian incomming a while ago and don't know wether it is in the unstable release yet. Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 18 15:30:14 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <3769F25A.B2FED7B4@wserv.com> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <37699D59.235A887D@magellan.umontreal.ca> Message-ID: <376A6606.93754EDC@magellan.umontreal.ca> Jordan Mendelson wrote: > > Stefan Seefeld wrote: > > > > Graydon Hoare wrote: > > I sure have to look into that but as we already discussed, I'v no > > idea what a widget is really. I mean, as I see it a 'HTML widget' > > in Berlin would be (much like any other widget) just a part of the > > scene graph. The only reason for which we call it 'one thing' is > > that there might happen to exist some 'constructor' in terms of a > > factory method which returns the root node of that particular thing. > > There are actually three peices to the 'HTML widget', a parsing engine, a >layout > engine and a rendering engine. The layout engine is the ultimate in mixing, > moving, growing, shrinking, packing and pushing visable objects. Their >layout > engine could be used by basically everything including the actual desktop >widget > (place icons on desktop), folders (place icons & text in an area), dialogs > (place other widgets and text in a space), a text system (format text in a > space), etc. Well, their 'layout engine' is definitely doing what we do (want do to) in a more 'scene graph embedded' way. How do both compare ? Berlin does layout on the fly (better: on the traversal :) so we don't have an engine for that. Do you see advantages in either way ? I think we all agree that good layout management is at the heart of every modern GUI. > Basically, we could make Mozilla the interface everything runs from. I'm >sure > you've seen the whole broadway, "run X inside your web browser" idea, well >this > is just one step further and saying, "run berlin as your object browser". that was exactly my point. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Fri Jun 18 16:14:01 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:33 2005 Subject: build problems Message-ID: <21D757CECBD2D211AD5D00105A2974A734B45C@EXCHANGE> > > Actually you need the omniorb, omniorb-dev, omniorb-doc > 2.7.1-6 debs. I > got it from debian incomming a while ago and don't know > wether it is in the > unstable release yet. > Actually, they can be gotten from: http://www.debian.org/~bfulgham. Use the -4 debs if you are on a glibc2.0 system, use 2.7.1-6 if you are potato. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 18 16:50:17 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <376A6606.93754EDC@magellan.umontreal.ca> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <37699D59.235A887D@magellan.umontreal.ca> <376A6606.93754EDC@magellan.umontreal.ca> Message-ID: <376A78C9.EDFB5322@wserv.com> Stefan Seefeld wrote: > > Jordan Mendelson wrote: > > > > Stefan Seefeld wrote: > > > > > > Graydon Hoare wrote: > > > I sure have to look into that but as we already discussed, I'v no > > > idea what a widget is really. I mean, as I see it a 'HTML widget' > > > in Berlin would be (much like any other widget) just a part of the > > > scene graph. The only reason for which we call it 'one thing' is > > > that there might happen to exist some 'constructor' in terms of a > > > factory method which returns the root node of that particular thing. > > > > There are actually three peices to the 'HTML widget', a parsing engine, a >layout > > engine and a rendering engine. The layout engine is the ultimate in >mixing, > > moving, growing, shrinking, packing and pushing visable objects. Their >layout > > engine could be used by basically everything including the actual desktop >widget > > (place icons on desktop), folders (place icons & text in an area), dialogs > > (place other widgets and text in a space), a text system (format text in a > > space), etc. > > Well, their 'layout engine' is definitely doing what we do (want do to) in > a more 'scene graph embedded' way. How do both compare ? Berlin does layout > on the fly (better: on the traversal :) so we don't have an engine for that. > Do you see advantages in either way ? I think we all agree that good layout > management is at the heart of every modern GUI. Currently, Mozilla also does layout on the fly. Mozilla actually has some information about their layout engine (NGLayout, Raptor, Gecko, whatever you want to call it) over at http://www.mozilla.org/newlayout/. As far as I can tell, to move the layout engine over to Berlin would require us to do one of two things, either clone XPCOM's function calls in CORBA or throw a CORBA wrapper around it as Graydon mentioned. Really what we need to do is talk to the layout engine people and see if this is feasible. On another note, I wonder how much press we'd get from doing such an insane thing? :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 18 17:00:40 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <376A78C9.EDFB5322@wserv.com> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <37699D59.235A887D@magellan.umontreal.ca> <376A6606.93754EDC@magellan.umontreal.ca> <376A78C9.EDFB5322@wserv.com> Message-ID: <376A7B38.6D7C52BB@wserv.com> Jordan Mendelson wrote: > Currently, Mozilla also does layout on the fly. > > Mozilla actually has some information about their layout engine (NGLayout, > Raptor, Gecko, whatever you want to call it) over at > http://www.mozilla.org/newlayout/. > > As far as I can tell, to move the layout engine over to Berlin would >require us > to do one of two things, either clone XPCOM's function calls in CORBA or >throw a > CORBA wrapper around it as Graydon mentioned. Oh, if we wanted to use their rendering engine we'd have to port XPFE over as well. I think we have almost all the primitives they need, we just need a few of the higher level things. If we use their layout engine we will want to use their rendering engine. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 18 17:08:02 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <3769F25A.B2FED7B4@wserv.com> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <37699D59.235A887D@magellan.umontreal.ca> <376A6606.93754EDC@magellan.umontreal.ca> <376A78C9.EDFB5322@wserv.com> Message-ID: <376A7CF2.D5BD2CAD@magellan.umontreal.ca> Jordan Mendelson wrote: > Currently, Mozilla also does layout on the fly. > > Mozilla actually has some information about their layout engine (NGLayout, > Raptor, Gecko, whatever you want to call it) over at > http://www.mozilla.org/newlayout/. > > As far as I can tell, to move the layout engine over to Berlin would >require us > to do one of two things, either clone XPCOM's function calls in CORBA or >throw a > CORBA wrapper around it as Graydon mentioned. well, you seem quite keen on using their code. (as a side note: they use the NPL which is not quite the same as GPL). But you didn't actually respond to my question: could you point out the differences between their and our approach ? Why do you think what they do works better ? Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From arrow at magenta.com Fri Jun 18 17:44:32 1999 From: arrow at magenta.com (Dave Archer) Date: Fri Feb 25 22:23:33 2005 Subject: Question mozilla stuff In-Reply-To: <376A78C9.EDFB5322@wserv.com> References: <376A78C9.EDFB5322@wserv.com> Message-ID: Hi all... Doesn't Berlin already have most/all the Fresco code built in? This seems to be the "right" way to go. I recall that you can run Fresco 'inside' Fresco. The documentation I was reading on Fresco had a drawing application inside itself twice...Just a demonstration of scene graph..:) With Berlin and Corba...shouldn't that obviate the need for a heavy pile of dupilcate software of a mozilla browser? If it's built into the server (as a loadable module) like all kits that's fine. Gotta watch that bloat control...:) I'm all for reusing good code where it can be found...:) I think the GGI - GGI-Mesa - Berlin(Fresco) - Corba route is absolutly the right way to go. Just 2 cnts... Dave A. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 18 18:09:14 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <3769F25A.B2FED7B4@wserv.com> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <376A7CF2.D5BD2CAD@magellan.umontreal.ca> <37699D59.235A887D@magellan.umontreal.ca> <376A6606.93754EDC@magellan.umontreal.ca> <376A78C9.EDFB5322@wserv.com> Message-ID: <376A8B4A.A2DBED8D@wserv.com> Stefan Seefeld wrote: > > Jordan Mendelson wrote: > > > Currently, Mozilla also does layout on the fly. > > > > Mozilla actually has some information about their layout engine (NGLayout, > > Raptor, Gecko, whatever you want to call it) over at > > http://www.mozilla.org/newlayout/. > > > > As far as I can tell, to move the layout engine over to Berlin would >require us > > to do one of two things, either clone XPCOM's function calls in CORBA or >throw a > > CORBA wrapper around it as Graydon mentioned. > > well, you seem quite keen on using their code. > (as a side note: they use the NPL which is not quite the same as GPL). > But you didn't actually respond to my question: could you point out the >differences > between their and our approach ? Why do you think what they do works better >? They are equally good approaches, but the reason theirs would work better is simply because it's more complete. It's really a matter of utilizing existing code and a horde of developers for our own gain. If you want a technical description of the features and architecture of the layout engine, we'll really need to talk to the layout people because I'm not up-to-date on it. I am familiar with their older layout engine more so than the new one. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 18 18:30:36 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: mozilla stuff In-Reply-To: <3769F25A.B2FED7B4@wserv.com> References: <3769F25A.B2FED7B4@wserv.com> <19990617180701Q.graydon@pobox.com> <376A7CF2.D5BD2CAD@magellan.umontreal.ca> <376A8B4A.A2DBED8D@wserv.com> <37699D59.235A887D@magellan.umontreal.ca> <376A6606.93754EDC@magellan.umontreal.ca> <376A78C9.EDFB5322@wserv.com> Message-ID: <376A904C.E37F325E@magellan.umontreal.ca> Jordan Mendelson wrote: > > Stefan Seefeld wrote: > > well, you seem quite keen on using their code. > > (as a side note: they use the NPL which is not quite the same as GPL). > > But you didn't actually respond to my question: could you point out the >differences > > between their and our approach ? Why do you think what they do works >better ? > > They are equally good approaches, but the reason theirs would work better is > simply because it's more complete. Well, just for fairness, you need to compare not Mozilla and Berlin but Mozilla and Fresco since, as you said, we would need to port it. > It's really a matter of utilizing existing > code and a horde of developers for our own gain. The number of people working for it can't be the major point. If not, we would use X/gtk instead, eh ? > If you want a technical > description of the features and architecture of the layout engine, we'll >really > need to talk to the layout people because I'm not up-to-date on it. But that's all I want to get at ! If you propose to use their code instead of Fresco's, please argue in terms of technical supremacy. I thought we were looking for the 'right' long term way, not for the most popular one. The development of Fresco is coupled to serious research, which is documented throughout all the years of it's evolution. See our doc page for a bunch of papers discussing the different aspects which led to the current design. These are the arguments I find most convincing. Please don't get me wrong. I'm *very* interested in constructive arguments about different possible architectures. I'm not argueing for using Fresco just for the sake of using Fresco. So let's get really to the point. And last but not least, we can't simply use their code, it's not a GPLed project. We might look into it to find inspiration though. Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From crosby at qwes.math.cmu.edu Sat Jun 19 02:11:26 1999 From: crosby at qwes.math.cmu.edu (Scott A Crosby) Date: Fri Feb 25 22:23:33 2005 Subject: Registrar In-Reply-To: References: Message-ID: > > Well, since it's a simple filesystem, I suppose you could : > > > > /applications/Berlin Consortium/Berlin/definition/option = value > > /applications/Berlin Consortium/Berlin/definition2/option = value > > /applications/Berlin Consortium/Berlin/definition3/option = value > > /applications/Berlin Consortium/Berlin/settings/Current Defininition = > > definition2 > > > > Or something similar to that. Scope would be determined by a particular > > level in your heirarchy, and really this is all application specific. We > > lay out for application developers the "correct" way to add entries to > > the Registrar and hope they follow through. > > Hmmm, I don't know whether that always maps easily (and efficiently !) to > a file system structure. Take a simple Button widget. The widget has > (statically) the style "Button" associated to it but this can be > overridden on a per instance basis. So you could set the Buttons color > with > .../Button/color = gray > or your special instance specifically with > .../MyButton/color = lightgray > so the precedence is well defined. First read class specific definitions, > then override with instance specific. Furthermore, to address only > Buttons within some scope (context) "ColorDialog" you could write it > .../ColorDialog/Button/color = rose > and so on. Now you could have this last line in the system preferences, > while the other line (.../MyButton/color = lightgray) within the user > preferences data base. Clearly, the latter should override the former and > your button (which happens to live within a ColorDialog and have the > instance name 'MyButton' should get the value lightgray, even though the > scope ColorDialog doesn't exist in the user DB. This is what I ment with > wildcards. I think this is something *very* useful and if you are looking > for inspiration, Fresco as well as the Xlib come with implementations of > this kind of functionality. > > (Do you really think that it's worth to create an inode for each key ?) > This would only make sense if you could keep the associated data block > as small as the string size taken by the value. That, in turn, would imply > that we make extra partitions for those data bases, which is quite an > efford if you immagine that every user has his/her own data base... > Represent it as a heirarchial filesystem, (with symlinks) where a search is made based on a pair of paramaters: a 'current working directory' and a 'keypath'.. A key path is composed of a subpath and an key For instance, 'OK/Button/Image' is 'Ok/Button/' and 'Image' is the key.. Application-CLASS/Application/Errorwindow/OK/Button/Image = ... Application-CLASS/Application/Errorwindow/OK/Button/Background = ... Application-CLASS/Application/Button/BorderWidth = ... When a keypath is searched, it is searched for in the CWD, if not found then successive parent directories are searched.. If this fails to match, then move the first component from the keypath and append it to the end of the CWD. Then repeat the above. So, to find '4/5/6' (key is '6' with CWD '1/2/3', the following would be checked in this order: (extra / to signify the component that is part of the CWD and the keypath) 1/2/3//4/5/6 1/2//4/5/6 1//4/5/6 //4/5/6 1/2/3/4//5/6 1/2/3//5/6 1/2//5/6 1//5/6 //5/6 1/2/3/4/5//6 1/2/3/4//6 1/2/3//6 1/2//6 1//6 //6 [FAIL] To be similar to X, make the CWD be APPLICATION-CLASS/APPLICATION-INSTANCE and the keypath be the path to the resource.. Its not quite as powerful as X-style resources, but it has the advantage of being very filesystem like, (which means that with reiserFS (see below) it could be implented on the disk AS a filesystem). It also has a well-defined search order, so one does not need to guess what will be searched. Its also fast, no recursive search. Also throwing in symbolic links may be a good idea to offer more flexibility. (You get that for free if ya use a real FS.) I think this works fine for simpler registrars. For a more complicated one it fails: /UserName/System-name/App-class/App-instance/App-documentname/ PS: One can throw in a Visual-type at the beginning there if one likes. :) This fails. If the system manager puts an 'Application/[1]' in /, it would be used in preference to a global (per-user) '/Username/[1]' One would want to have a prefix which is always used and trailing compoenents are only removed upon last resort... Like the keypath, but applied to the root, where a component is only removed from the root as a last resort if the above rules fail.. C-like code is something like: // Not using the STL, I need the length and the ability to pop // the last element. check (Sequence root, Sequence cwd, Sequence keypath, Item key) { Sequence savedkeypath = keypath; Sequence savedcwd = cwd; Sequence savedroot = root; do { do { do { if (Exists (root + cwd + keypath + key)) return SUCCESS; if (keypath.size() == 0) break; keypath.pop(); } if (path.size() == 0) break; keypath = savedkeypath + cwd.pop(); } if (root.size == 0) return FAILURE; // Which of the two below is better? #if ??? root.pop(); cwd = savedcwd; #else cwd = root.pop() + savedcwd; #endif } } ///////////////////////////////////////////////////// Its a lot more complex and less intuitive compared to the first design. It may be easier to just run the first design and have a searchlist of seperate databases. What do youall think? > > Well, another way to look at the Registrar, other than a traditional > > filesystem is like: > > > > Application { > > Font Size = "2"; > > Head { > > Font Size = "+1"; > > Font Foreground Color = "Red"; > > Text = "Alpha Numeric"; > > } > > } > > > > This would look like this in the registrar: > > > > /temp/Application/ > > /temp/Application/Font Size = "2" > > /temp/Application/Head/ > > /temp/Application/Head/Font Size = "+1" > > /temp/Application/Head/Font Foreground Color = "Red" > > /temp/Application/Head/Text = "Alpha Numeric" > > Exactly. If someone looking for 'Application::Body::Font Size' would be > directed to 'Application::Font Size' (since this is the 'next match') this > would be part of the solution. > BTW, for implementing these, I suggest looking into ReiserFS, its a new filesystem optimized for small ~200 byte objects.. One current test (which isn't going very well) is to create a directory with 50,000,000 seperate files in it!! Currently someone has it up to 10 million files. Its also faster than ext2fs in almost all paramaters, being beaten by ext2 for objects in the single-digit kilobyte range. (But not by much.) So, storing this physically on a filesystem is no real problem. (ReiserFS has reasonble odds of becoming ext3fs) Scott Crosby -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Sun Jun 20 17:09:33 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:33 2005 Subject: Registrar In-Reply-To: References: Message-ID: <376D204D.E79E466B@magellan.umontreal.ca> I don't think that storing styles in terms of a file system is a good idea for different reasons. The first, most obvious one, is, that we would need a special file system for the Registrar to work efficiently (one where the ratio of inodes to space is tuned for the mean number styles in a given context. The second reason is much more important: a file system has no means to allow to define semantic contexts. I really think that the emerging XML/XSL standard does provide much better means for storing and querying data bases as the ones we need. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Mon Jun 21 06:40:42 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:34 2005 Subject: Debian packages Message-ID: <19990620234042.A293@localhost> Hey all - I just started trying to finalize debs on the head branch today. I just built the server and all of its libraries successfully, but attempting to run it yields no output whatsoever (and nothing works). I'd try to figure out what the problem is, but I'm kind of tired right now. good night ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mental at kludge.org Mon Jun 21 19:16:22 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:23:34 2005 Subject: focus model Message-ID: I apologize if something similar to this has already been suggested; I've been pretty busy with other things and I've been "processing" a lot of my email with the 'D' key. ISTR, though, that the issue of exactly what we want to do with the focus model, particularly when dealing with multiple input devices, is still more or less up in the air. I'd like to suggest an approach that I came up with the other night when I was working on the input subsystem for a game -- essentially, instead of treating "focus" as an exclusive tap on a particular input device, rather have a "stack" of listeners associated with each input device. Incoming events descend throught the stack, giving each listener an opportunity to either consume the event, or allow it to pass through to the listener below. A widget or other entity interested in gaining the "focus" would push itself (as a subclass of EventListener or similar) onto the top of the input device's listener stack, so it would get "dibs" on any events it was interested in (relative to anything below it on the stack, anyway; anything pushed on top of it later would have more priority). Typically, the root window would be near the bottom of the stack, so it'd usually consume any events that fell all the way through -- those events would of course get propagated to its children in the normal fashion. Any events that fall all the way through the stack without being consumed are discarded (although several listeners may have made copies/references along the way). This is actually relatively similar to what GGI Console (nee EvStack) does in some cases (and indeed, you may want to have a look at some of the GGI Console design; it's got a very interesting approach to input stuff in general). -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Mon Jun 21 19:42:23 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: focus model In-Reply-To: References: Message-ID: <376E959F.6998CEFE@magellan.umontreal.ca> MenTaLguY wrote: > ISTR, though, that the issue of exactly what we want to do with the focus > model, particularly when dealing with multiple input devices, is still more > or less up in the air. Right. > I'd like to suggest an approach that I came up with the other night when I > was working on the input subsystem for a game -- essentially, instead of > treating "focus" as an exclusive tap on a particular input device, rather > have a "stack" of listeners associated with each input device. > > Incoming events descend throught the stack, giving each listener an > opportunity to either consume the event, or allow it to pass through to the > listener below. A widget or other entity interested in gaining the "focus" > would push itself (as a subclass of EventListener or similar) onto the top > of the input device's listener stack, so it would get "dibs" on any events > it was interested in (relative to anything below it on the stack, anyway; > anything pushed on top of it later would have more priority). > > Typically, the root window would be near the bottom of the stack, so it'd > usually consume any events that fell all the way through -- those events > would of course get propagated to its children in the normal fashion. Any > events that fall all the way through the stack without being consumed are > discarded (although several listeners may have made copies/references along > the way). > > This is actually relatively similar to what GGI Console (nee EvStack) does > in some cases (and indeed, you may want to have a look at some of the GGI > Console design; it's got a very interesting approach to input stuff in > general). ok. I discussed 'Focus' as two things: first (and that's what you are referring to here) a filter which let's different controllers 'have' the focus. I fully agree that your scheme with filtering seems quite appropriate. It's the way most GUI toolkits manage events. So for every input device we could install a stack which Event filters are pushed on within some 'grab' function. The more tricky part seems the second question: A Controller which gets the focus might want to set/manipulate some shared resources. How are we going to do this ? These shared resources are something like: * a visual representation of the device & controller such as 'cursor', 'pointer' etc. * toolbars, pulldown menus etc. Now, what I proposed was the following: Every Controller contains a 'Focus' object. Once the Controller gets the focus, it's Focus object is asked to install all global resources it wants to (probably on a per device basis). Then device grab/ungrab would cause the Focus objects of the old and the new Controller having focus to be called with something like install/uninstall. Thus we keep full flexibility as to what exactly is to be installed for a given device/controller. The Focus management would go into the Controller interface (methods like hasFocus, acceptsFocus, enterFocus, leaveFocus or so) and a pluggable component which actually implements the Focus policy which may heavily vary (see window managers under X to see how different that could be). What do you think ? Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 22 15:03:11 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL Message-ID: <376FA5AF.F51F6382@wserv.com> Alright, I've done some homework: NPL is the Netscape Public License. MPL is the Mozilla Public License. Mozilla source appears to be dual-licensed under both the MPL and NPL. LGPL and MPL appear to both be compatible. MPL is a bit more strict than LGPL. MPL requires all modifications of the source code be documented. The NPL in is almost identical to the MPL except the NPL includes some provisions for Netscape to keep control over licensing, keep control over their own logos, and "Netscape branded" code. The NPL allows Netscape to create specialized versions of the code not covered by the NPL. As for the GPL. GPL is an odd thing. It defines all derivative works must be licensed under GPL. Now, GPL is compatible with LGPL because LGPL allows licensing under a more restrictive license, so when LGPL code is linked to a GPL binary, the binary and library become GPLed. The same goes for the BSD license. MPL/NPL do not allow this relicensing, so you may not link MPL/NPL code to a GPL source base. Now unless I'm mistaken, all of our code is under LGPL right now including executable source (which is quite confusing if you read the LGPL as it explicitly talks about libraries). It apears we can take Mozilla code and incorporate it without fear as long as we don't try to include any GPL'ed source. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 15:29:08 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FA5AF.F51F6382@wserv.com> References: <376FA5AF.F51F6382@wserv.com> Message-ID: <376FABC4.49DB5368@magellan.umontreal.ca> Jordan Mendelson wrote: > > Alright, I've done some homework: > > NPL is the Netscape Public License. > MPL is the Mozilla Public License. > > Mozilla source appears to be dual-licensed under both the MPL and NPL. > > LGPL and MPL appear to both be compatible. MPL is a bit more strict than >LGPL. > MPL requires all modifications of the source code be documented. > > The NPL in is almost identical to the MPL except the NPL includes some > provisions for Netscape to keep control over licensing, keep control over >their > own logos, and "Netscape branded" code. The NPL allows Netscape to create > specialized versions of the code not covered by the NPL. > > As for the GPL. GPL is an odd thing. It defines all derivative works must be > licensed under GPL. Now, GPL is compatible with LGPL because LGPL allows > licensing under a more restrictive license, so when LGPL code is linked to >a GPL > binary, the binary and library become GPLed. The same goes for the BSD >license. > MPL/NPL do not allow this relicensing, so you may not link MPL/NPL code to >a GPL > source base. > > Now unless I'm mistaken, all of our code is under LGPL right now including > executable source (which is quite confusing if you read the LGPL as it > explicitly talks about libraries). Well, after recent discussions about this issue (GPL vs. LGPL) I tend to think that we should release under GPL, all, binaries, libraries, protocols. Back to the main issue. You still don't compare anything. I really want to avoid religious debates about how to do things. I'd rather base our discussions on facts and serious investigation. So please, in the sake of the efford we all have done so far and are going to do in the future, lets restrict to points like efficiency, extensibility, maintainability etc. Can you argue in these terms please ? Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 22 15:48:13 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FABC4.49DB5368@magellan.umontreal.ca> References: <376FA5AF.F51F6382@wserv.com> <376FABC4.49DB5368@magellan.umontreal.ca> Message-ID: <376FB03D.FB0E783B@wserv.com> Stefan Seefeld wrote: > > > > > Now unless I'm mistaken, all of our code is under LGPL right now including > > executable source (which is quite confusing if you read the LGPL as it > > explicitly talks about libraries). > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend to >think > that we should release under GPL, all, binaries, libraries, protocols. If we released libraries and protocols under GPL, there would be 0 commercial applications for Berlin. We would basically exclude everything but other GPL, BSD and LGPL projects. > Back to the main issue. You still don't compare anything. I really want to >avoid > religious debates about how to do things. I'd rather base our discussions > on facts and serious investigation. So please, in the sake of the efford we >all have > done so far and are going to do in the future, lets restrict to points like > efficiency, extensibility, maintainability etc. Can you argue in these >terms please ? I needed to research the licenses to make sure that what was proposed was even possible. I'll try to summarize the benefits and features of Mozilla's layout engine as soon as I do a bit more research on it. I don't want to come out and list features without having a clear understanding of their new layout engine. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Tue Jun 22 16:00:23 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FB03D.FB0E783B@wserv.com> References: <376FB03D.FB0E783B@wserv.com> Message-ID: <99062218063500.02175@alcatraz168> On Tue, 22 Jun 1999, Jordan Mendelson wrote: > Stefan Seefeld wrote: > > > > > > > > Now unless I'm mistaken, all of our code is under LGPL right now >including > > > executable source (which is quite confusing if you read the LGPL as it > > > explicitly talks about libraries). > > > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend to >think > > that we should release under GPL, all, binaries, libraries, protocols. > > If we released libraries and protocols under GPL, there would be 0 >commercial > applications for Berlin. We would basically exclude everything but other >GPL, > BSD and LGPL projects. > I'm affraid Jordan is right here. I think switching to LGPL would be better in the long run... Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 16:31:22 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <99062218063500.02175@alcatraz168> References: <99062218063500.02175@alcatraz168> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FBA5A.689002BF@magellan.umontreal.ca> Tobias Hunger wrote: > > On Tue, 22 Jun 1999, Jordan Mendelson wrote: > > Stefan Seefeld wrote: > > > > > > > > > > > Now unless I'm mistaken, all of our code is under LGPL right now >including > > > > executable source (which is quite confusing if you read the LGPL as it > > > > explicitly talks about libraries). > > > > > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend >to think > > > that we should release under GPL, all, binaries, libraries, protocols. > > > > If we released libraries and protocols under GPL, there would be 0 >commercial > > applications for Berlin. We would basically exclude everything but other >GPL, > > BSD and LGPL projects. > > > > I'm affraid Jordan is right here. I think switching to LGPL would be better >in > the long run... Well, yeah, at least for the protocol part. I'm not sure what (L)GPL would mean for a protocol such as Warsaw. So I guess we have to decide something in between LGPL for client libs and Warsaw and GPL for server + plugins and clients on the one side and all LGPL on the other. Right ? It seems to me as this point has not much substance since our design makes tinny applications and large libs where 99.99% of the code are reusable in the libs. So both possibilities are quite close together. In fact, when I proposed GPL for the protocol(s), I had something in mind to protect the protocols not from being used commerically but from being 'extended' as this word is understood by Microsoft (see halloween 1 - 3). Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 22 16:50:20 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FB03D.FB0E783B@wserv.com> References: <376FA5AF.F51F6382@wserv.com> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <19990622095020.A28597@localhost> On Tue, Jun 22, 1999 at 11:48:13AM -0400, Jordan Mendelson wrote: > Stefan Seefeld wrote: > > > > > > > > Now unless I'm mistaken, all of our code is under LGPL right now >including > > > executable source (which is quite confusing if you read the LGPL as it > > > explicitly talks about libraries). > > > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend to >think > > that we should release under GPL, all, binaries, libraries, protocols. > > If we released libraries and protocols under GPL, there would be 0 >commercial > applications for Berlin. We would basically exclude everything but other >GPL, > BSD and LGPL projects. This isn't quite true. We don't have control over Warsaw's licsensing as long as we are using omniorb. Check the omniorb license, which specifies that all stubs generated by omniidl2 are explicitly LGPL. And again, whatever license the other components of berlin are under, network connections are *not* considered linking, so commercial apps would be unscathed. So, technically, we can link in *anything* compatible with LGPL, so long as incompatible portions are given their own Warsaw and made to communicate only by IIOP. Of course, if we make berlin ORB-independent, this becomes a much more complicated issue. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 17:02:21 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FA5AF.F51F6382@wserv.com> References: <376FA5AF.F51F6382@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FC19D.7EC1AF0C@magellan.umontreal.ca> Aaron Van Couwenberghe wrote: > This isn't quite true. We don't have control over Warsaw's licsensing as > long as we are using omniorb. Check the omniorb license, which specifies > that all stubs generated by omniidl2 are explicitly LGPL. I think we must distinguish between the generated stubs which basically add the marshalling and generall communication facilities to our code, and the protocols as specified within the Warsaw IDL. I don't think that the above specification concerning the generated stubs affects in any way the license of Warsaw itself. > And again, whatever > license the other components of berlin are under, network connections are > *not* considered linking, so commercial apps would be unscathed. > > So, technically, we can link in *anything* compatible with LGPL, so long as > incompatible portions are given their own Warsaw and made to communicate > only by IIOP. Of course, if we make berlin ORB-independent, this becomes a > much more complicated issue. Hmm, yes. This whole discussion shows how the current legal system is completely inadequate to describe reality as it presents itself today. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 22 17:03:37 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FBA5A.689002BF@magellan.umontreal.ca> References: <99062218063500.02175@alcatraz168> <376FBA5A.689002BF@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <19990622100337.B28597@localhost> On Tue, Jun 22, 1999 at 04:31:22PM +0000, Stefan Seefeld wrote: > In fact, when I proposed GPL for the protocol(s), I had something in mind to > protect the protocols not from being used commerically but from being >'extended' > as this word is understood by Microsoft (see halloween 1 - 3). > > Stefan This is quite easy. GPL the IDL sources. This would keep individuals from extending the distributed interfaces (except by direct modification of the stubs, which renders this more protection by obscurity...), but would allow them to create their own custom interfaces. However, their own custom interfaces could not have implementations linked in to libBerlin (if it went GPL); so with this approach Berlin's core would still be solidly protected. I don't quite know what this kind of an arrangement would mean. After thinking more, I also don't know if stubs from IDL are considered a "derivative work" and hence, whether it's really possible to put the sources under GPL. We might have to make an explicit exclusion on the derivative works clause, and declare it conditional. This is something a lawyer would have to look at. I agree completely with steffen. Berlin must not put itself into a position where its core featureset can be coerced by big business. Take a look at X's history and see TOG's exploits. However, I also agree with Jordan; Berlin *does* need certain kinds of commercial interest. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 22 17:04:08 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <19990622095020.A28597@localhost> References: <376FA5AF.F51F6382@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FC208.F2BE4423@wserv.com> Aaron Van Couwenberghe wrote: > > On Tue, Jun 22, 1999 at 11:48:13AM -0400, Jordan Mendelson wrote: > > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend >to think > > > that we should release under GPL, all, binaries, libraries, protocols. > > > > If we released libraries and protocols under GPL, there would be 0 >commercial > > applications for Berlin. We would basically exclude everything but other >GPL, > > BSD and LGPL projects. > > This isn't quite true. We don't have control over Warsaw's licsensing as > long as we are using omniorb. Check the omniorb license, which specifies > that all stubs generated by omniidl2 are explicitly LGPL. And again, >whatever > license the other components of berlin are under, network connections are > *not* considered linking, so commercial apps would be unscathed. > > So, technically, we can link in *anything* compatible with LGPL, so long as > incompatible portions are given their own Warsaw and made to communicate > only by IIOP. Of course, if we make berlin ORB-independent, this becomes a > much more complicated issue. Well I think Stefan was hinting at licensing libraries as GPL (not LGPL). If we add any GPL code to the library itself (not the stubs), the entire thing becomes GPL'ed. That's the infectious agent of GPL. The problem is that if anyone links to a GPL (not LGPL) library, their source ALSO becomes GPL'ed and they must release code. There is a special provision in things like the Linux kernel which allow binary linking without the infectious agent. The opposite is also true. If my GPL'ed source foo.c is linked against an LGPL library, libc the resulting executable 'foo' is under GPL license, not LGPL license. At least, that is my intepretation of the GPL. This is why you can't link a MPL'ed library with a GPL'ed program, because MPL does not allow relicensing. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 17:22:49 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FA5AF.F51F6382@wserv.com> References: <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FC669.D56B4F9C@magellan.umontreal.ca> Jordan Mendelson wrote: > Well I think Stefan was hinting at licensing libraries as GPL (not LGPL). >If we > add any GPL code to the library itself (not the stubs), the entire thing >becomes > GPL'ed. That's the infectious agent of GPL. > > The problem is that if anyone links to a GPL (not LGPL) library, their >source > ALSO becomes GPL'ed and they must release code. There is a special >provision in > things like the Linux kernel which allow binary linking without the >infectious > agent. > > The opposite is also true. If my GPL'ed source foo.c is linked against an >LGPL > library, libc the resulting executable 'foo' is under GPL license, not LGPL > license. At least, that is my intepretation of the GPL. This is why you >can't > link a MPL'ed library with a GPL'ed program, because MPL does not allow > relicensing. Ha, now we are at the crucial point ! A LGPL'ed library allows to ship it as GPL or part of a GPL'ed work (GPL is a subset of LGPL if you like). MPL doesn't allow this. And it's exactly this point which makes it incompatible with our goals (at least mine). Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 22 17:26:03 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC208.F2BE4423@wserv.com> References: <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <19990622102603.C28597@localhost> On Tue, Jun 22, 1999 at 01:04:08PM -0400, Jordan Mendelson wrote: > Aaron Van Couwenberghe wrote: > > > > On Tue, Jun 22, 1999 at 11:48:13AM -0400, Jordan Mendelson wrote: > > > > Well, after recent discussions about this issue (GPL vs. LGPL) I tend >to think > > > > that we should release under GPL, all, binaries, libraries, protocols. > > > > > > If we released libraries and protocols under GPL, there would be 0 >commercial > > > applications for Berlin. We would basically exclude everything but >other GPL, > > > BSD and LGPL projects. > > > > This isn't quite true. We don't have control over Warsaw's licsensing as > > long as we are using omniorb. Check the omniorb license, which specifies > > that all stubs generated by omniidl2 are explicitly LGPL. And again, >whatever > > license the other components of berlin are under, network connections are > > *not* considered linking, so commercial apps would be unscathed. > > > > So, technically, we can link in *anything* compatible with LGPL, so long >as > > incompatible portions are given their own Warsaw and made to communicate > > only by IIOP. Of course, if we make berlin ORB-independent, this becomes a > > much more complicated issue. > > Well I think Stefan was hinting at licensing libraries as GPL (not LGPL). >If we > add any GPL code to the library itself (not the stubs), the entire thing >becomes > GPL'ed. That's the infectious agent of GPL. I was just pointing out that we *could* make the core GPL, implicitly converting Warsaw to GPL, and make connections to other Warsaws that were linked against anything. This is if we were to declare the stubs generated from our IDL (which *should* be GPL of course) licenseable by the end user, at their leasure, in whatever way they please. In omniorb's case, they become LGPL. So, in effect, the licensing of the berlin core becomes moot, because anything can make an IIOP connection (CORBA connection, exposing interfaces to the other end) without being considered "linked". Commercial apps are quite safe, whatever license they are under: they just have their own stub library, like any other client, and use berlin over the network like any other client. Everyone is happy with this approach: Berlin is unchangeable, but commercial interests are preserved. Of course, where you've got components whose licenses are incompatible running on the same machine, you need multiple copies of the stub library (if you feel like being legal). Or you could somehow disable the shared library mechanisms in an OS, forcing it to load the same LGPL stub library into memory multiple times. This is how you would effectively be able to circumvent (via CORBA) any license clause that restricts linking. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 22 17:28:30 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC669.D56B4F9C@magellan.umontreal.ca> References: <376FC669.D56B4F9C@magellan.umontreal.ca> <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <19990622102830.D28597@localhost> On Tue, Jun 22, 1999 at 05:22:49PM +0000, Stefan Seefeld wrote: > Ha, now we are at the crucial point ! A LGPL'ed library allows to ship it >as GPL > or part of a GPL'ed work (GPL is a subset of LGPL if you like). > MPL doesn't allow this. And it's exactly this point which makes it >incompatible > with our goals (at least mine). > > Stefan Ok, yes. My argument was all from the client side and had no bearing on server side licensing. I would be in favor of a 100% GPL berlin core (save Warsaw), for reasons expressed in previous mails. I know this is hard, and ony the programmer dictates what goes in, so just consider this a suggestion ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 22 17:29:39 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC669.D56B4F9C@magellan.umontreal.ca> References: <376FC669.D56B4F9C@magellan.umontreal.ca> <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FC803.66F6393@wserv.com> Stefan Seefeld wrote: > > Jordan Mendelson wrote: > > > Well I think Stefan was hinting at licensing libraries as GPL (not LGPL). >If we > > add any GPL code to the library itself (not the stubs), the entire thing >becomes > > GPL'ed. That's the infectious agent of GPL. > > > > The problem is that if anyone links to a GPL (not LGPL) library, their >source > > ALSO becomes GPL'ed and they must release code. There is a special >provision in > > things like the Linux kernel which allow binary linking without the >infectious > > agent. > > > > The opposite is also true. If my GPL'ed source foo.c is linked against an >LGPL > > library, libc the resulting executable 'foo' is under GPL license, not >LGPL > > license. At least, that is my intepretation of the GPL. This is why you >can't > > link a MPL'ed library with a GPL'ed program, because MPL does not allow > > relicensing. > > Ha, now we are at the crucial point ! A LGPL'ed library allows to ship it >as GPL > or part of a GPL'ed work (GPL is a subset of LGPL if you like). > MPL doesn't allow this. And it's exactly this point which makes it >incompatible > with our goals (at least mine). Which is why I did the research in the first place :) Of course Aaron made a good point about CORBA. If you use CORBA to call functions, you are not linking, so if Mozilla was exposed via CORBA it wouldn't matter what license it was under. Really, at this point Mozilla is not suitable for inclusion. The only thing which we can actually use is their JavaScript library, which we really don't need at this point. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 17:50:22 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC803.66F6393@wserv.com> References: <376FC803.66F6393@wserv.com> <376FC669.D56B4F9C@magellan.umontreal.ca> <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FCCDE.23BD3BD1@magellan.umontreal.ca> Jordan Mendelson wrote: > > Ha, now we are at the crucial point ! A LGPL'ed library allows to ship it >as GPL > > or part of a GPL'ed work (GPL is a subset of LGPL if you like). > > MPL doesn't allow this. And it's exactly this point which makes it >incompatible > > with our goals (at least mine). > > Which is why I did the research in the first place :) > > Of course Aaron made a good point about CORBA. If you use CORBA to call > functions, you are not linking, so if Mozilla was exposed via CORBA it >wouldn't > matter what license it was under. > > Really, at this point Mozilla is not suitable for inclusion. The only thing > which we can actually use is their JavaScript library, which we really don't > need at this point. And to sum up this little thread, we can (after considering our arguments) safely put most of our efford under GPL since commercial applications always can bind to berlin/warsaw via CORBA. Since 'extensions' can be put into other libraries which only interact CORBA wise with Warsaw, even a GPLed Warsaw would be possible without offending potential commercial development. So you see, to give a complete copyright/license definition, we would need to either redefine what 'linking' is or add a special clause for 'CORBA binding'. However, I browsed a bit through the mozilla sources and found that the code is much less well structured than I would like. I looked especially at the network / protocol stuff and I think to continue work on the Prague::Network stuff we should base much more on what is in now (Connector, sockbuf, sockstream, ftp, smtp...) plus patterns and code from the ACE. If anyone feels attracted by this task, I would be happy to hand over the appropriate Prague parts ! Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Tue Jun 22 20:05:16 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FCCDE.23BD3BD1@magellan.umontreal.ca> References: <376FCCDE.23BD3BD1@magellan.umontreal.ca> Message-ID: <19990622160516L.graydon@pobox.com> > And to sum up this little thread, we can (after considering our arguments) >safely > put most of our efford under GPL since commercial applications always can >bind > to berlin/warsaw via CORBA. Since 'extensions' can be put into other >libraries > which only interact CORBA wise with Warsaw, even a GPLed Warsaw would be >possible > without offending potential commercial development. > > So you see, to give a complete copyright/license definition, we would need >to > either redefine what 'linking' is or add a special clause for 'CORBA >binding'. my $0.02 worth : I like the "GPL Warsaw (the .idl's), LGPL berlin (the impl.cc's)" approach. but if anyone files a bug that we broke compatibility with their binary-only module, it will be sent to /dev/null cause it's their own damn fault. -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 22 20:05:56 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC803.66F6393@wserv.com> References: <376FC803.66F6393@wserv.com> <376FC669.D56B4F9C@magellan.umontreal.ca> <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <19990622095020.A28597@localhost> <376FCCDE.23BD3BD1@magellan.umontreal.ca> <376FABC4.49DB5368@magellan.umontreal.ca> <376FB03D.FB0E783B@wserv.com> Message-ID: <376FECA4.224E72@wserv.com> Stefan Seefeld wrote: > > Jordan Mendelson wrote: > > > > Really, at this point Mozilla is not suitable for inclusion. The only >thing > > which we can actually use is their JavaScript library, which we really >don't > > need at this point. > > And to sum up this little thread, we can (after considering our arguments) >safely > put most of our efford under GPL since commercial applications always can >bind > to berlin/warsaw via CORBA. Since 'extensions' can be put into other >libraries > which only interact CORBA wise with Warsaw, even a GPLed Warsaw would be >possible > without offending potential commercial development. I guess it really depends on if code generated off other code inherits the license of the original code. If you are talking Java where source is translated into Java byte code, the answer is yes. If you are talking Yacc/Bison which takes a .y file and turned it into a .tab.c and .tab.h file generated source is under the original license as well. So here is the problem, GPL defines that all derivatives are infected with GPL. Simply converting a file from one format to another does not change it's origin, it's still derivative of the original source. The omniidl2 line about outputed source being under LGPL may not be legal, not to mention omniidl2 is *NOT* the only IDL parser people will use. There are also other headers containing various #define's and what not that should not being under GPL. I think in general, GPL'ing any files which may be linked against or #included in another program is a bad idea and while the LGPL doesn't protect as well as the GPL, it isn't completely void of protection for the original programmers. We probably shouldn't switching to GPL until necessary. It would be a good idea to contact a lawyer in the open source field before we commit to anything and in the mean time, just stick to LGPL. > However, I browsed a bit through the mozilla sources and found that the code > is much less well structured than I would like. I looked especially at the > network / protocol stuff and I think to continue work on the Prague::Network > stuff we should base much more on what is in now (Connector, sockbuf, >sockstream, > ftp, smtp...) plus patterns and code from the ACE. If anyone feels >attracted by > this task, I would be happy to hand over the appropriate Prague parts ! Actually, take a look at ASPR from Apache. They basically have the same thing as the NSPR from Mozilla, but under the Apache license. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 22 22:36:53 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: NPL, MPL, GPL and LGPL In-Reply-To: <376FC669.D56B4F9C@magellan.umontreal.ca> References: <376FC669.D56B4F9C@magellan.umontreal.ca> <376FA5AF.F51F6382@wserv.com> <376FC208.F2BE4423@wserv.com> <376FCCDE.23BD3BD1@magellan.umontreal.ca> <376FABC4.49DB5368@magellan.umontreal.ca> <376FC803.66F6393@wserv.com> <376FECA4.224E72@wserv.com> <19990622095020.A28597@localhost> <376FB03D.FB0E783B@wserv.com> Message-ID: <37701005.99C11EAD@magellan.umontreal.ca> Jordan Mendelson wrote: > The omniidl2 line about outputed source being under LGPL may not be legal, >not > to mention omniidl2 is *NOT* the only IDL parser people will use. right, good point. > I think in general, GPL'ing any files which may be linked against or >#included > in another program is a bad idea and while the LGPL doesn't protect as well >as > the GPL, it isn't completely void of protection for the original >programmers. hmm, just for the record. I don't interpret GPL as protection for the programmer. Rather protection for the community. That may look like nitpicking but it makes all the difference. Often people speak of GPL as somewhat restrictive as it would restrict someone's freedom. On the contrary. It restricts the restriction ! To cite Eben Morgan: "Resist the resistance !" Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Tue Jun 22 23:23:27 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? In-Reply-To: <376FECA4.224E72@wserv.com> References: <376FECA4.224E72@wserv.com> Message-ID: <99062301255100.06942@alcatraz168> Hi! Does someone know where on earth the omniorb developers hid the declarations of Unicode and Unistring? I had them a while back, but I can't find them any longer:-( Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Wed Jun 23 01:04:38 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? In-Reply-To: <99062301255100.06942@alcatraz168> References: <99062301255100.06942@alcatraz168> <376FECA4.224E72@wserv.com> Message-ID: <377032A6.70829DE2@magellan.umontreal.ca> Tobias Hunger wrote: > > Hi! > > Does someone know where on earth the omniorb developers hid the >declarations of > Unicode and Unistring? I had them a while back, but I can't find them any >longer:-( Unicode ? Unistring ? in CORBA ? Seriously, CORBA knows about wchar, wstring (IDL) and WChar, WString_var (C++). I don't think that these are implemented in omniORB though. By the way, omniORB is said to release version 2.8.0 shortly, I'm curious what new features they will support... Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From anoq at HardcoreProcessing.com Wed Jun 23 10:56:29 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? In-Reply-To: <99062301255100.06942@alcatraz168> References: <99062301255100.06942@alcatraz168> <376FECA4.224E72@wserv.com> Message-ID: <3770BD5D.DB7B7800@HardcoreProcessing.com> Tobias Hunger wrote: > > Hi! > > Does someone know where on earth the omniorb developers hid the >declarations of > Unicode and Unistring? I had them a while back, but I can't find them any >longer:-( At least there's some "emulation code" in the DOM stuff I wrote - maybe that's useful... I believe the class is called domString or something - in the final DOM-spec it's DOMString. Cheers -- http://www.HardcoreProcessing.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From alain at mbz.org Wed Jun 23 15:11:25 1999 From: alain at mbz.org (Alain Toussaint) Date: Fri Feb 25 22:23:34 2005 Subject: need advice for computer hardware -- offtopic Message-ID: <3770F91D.AC6BBDB2@mbz.org> Hello lister's, the reason i write is because someone at buzz.builder.com asked me in a private mail what is the best computer to act as workgroup server for 10K$ australian dollars,here's some of his word: ----- You wrote a piece on the items needed for a PC...you also said that you may be able to help me further if I gave you a budget to work with... Well after doing a little revising I think I'll scale back to just a http and mail server to begin with but with the ability to scale for the other mentioned componentss...... The nominal budget I have appears to be about $10000 AUS or about $6000 US (i think, dont quote me on that).... ----- the OS considered would be linux and NT,but for 10 000$ AUS,i don't have any recommendation since i never even though of buying something near the 10K AUS price cap,could some of you give me advices privately (don't mail back to the list) on the best setup for this budget ?? Thanks a lot Alain Toussaint -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Wed Jun 23 15:57:06 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? Message-ID: <21D757CECBD2D211AD5D00105A2974A7368E8C@EXCHANGE> > > Does someone know where on earth the omniorb developers hid > the declarations of > > Unicode and Unistring? I had them a while back, but I can't > find them any longer:-( > > Unicode ? Unistring ? in CORBA ? > Seriously, CORBA knows about wchar, wstring (IDL) and WChar, > WString_var > (C++). > I don't think that these are implemented in omniORB though. > I think he's talking about the original unicode implementation that was in the berlin tree. It used to be under the berlin-tree/src/libunicode branch, but I haven't had call to look at it lately. Perhaps it was "pruned" from the tree? -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Wed Jun 23 16:18:52 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:34 2005 Subject: input event filtering In-Reply-To: References: Message-ID: <377108EC.F2B5C02F@magellan.umontreal.ca> ok, some thoughts on the topic: there are quite different possibilities to deal with even filtering: X allows displays to subscribe to any events for any window. That is, you can write applications which get almost all the interaction between the server and arbitrary clients (given that in X interaction is almost exclusively event based). Do we want that ? What are the pros, what are the cons ? The reason I discuss this is that Graydon objected to a proposition for implementing event delivery based on exclusive grabs since toys (and possibly real tools) like xeyes are only possible if *everyone* gets informed about all the events. What are the alternatives ? We could classify events in 'private' and 'public', i.e. which are exclusive and should not be seen by anyone but the grabber. Something I did (may be some third way) in OffiX is the following: based on the X protocol, which allows basically anything to be observed, I used the multicast pattern (see 'Pattern Hatching') to let an Event dispatch itself to subscribers. Subscribers are registered in one of three lists: * filters * handlers * fallbacks handlers are the event handlers mainly used. They return a boolean value to indicate if the event was 'consumed', i.e. whether it should be processed further. Filters are essentially for observers which see the event *before* it is 'handled'. However, they too may consume the event (useful for communication protocols such as select, DND etc.). Lastly, there are the fallbacks which are essentially there for symmetry (you may want to log all not consumet events). To reiterate, this scheme is based on the assumption that events are 'observable', i.e. public in the above notation. And, in the sake of completeness: X allows to grab pointer, keyboard and individual buttons/keys. The grab action takes parameters to specify exclusiveness etc. So even in X you can restrict the delivery of events to single clients (but the very design proposes this to be a very temporal situation, like 'modal' dialogs, pull down menus etc.). What do you think ? Who should be able to receive / filter events ? Remembering back discussions we had, Graydon proposed to let each Controller decide. That is, we would figure out iteratively which Controller should get the event (starting at root==screen) and then let the Controller do whatever it wants with the event, including forwarding to the child Controller, handling itself or broadcasting. When we discussed this, all was done via broadcasting (commands/messages). Now we are working mainly with Traversals and the Event is delivered to the 'picked' Controller. Should the Controller then broadcast a Message the way you were doing that in the 0.0.1 release ? Currently, Event delivery is done as follows: we have positional and focus input events. For both, there is a stack of Controllers who eventually will see the event. For positional events, the stack is traversed simply in looking up the next controller in the scene graph via PickTraversals. The controller receives the event and starts a new PickTraversal to find the next (child) controller to handle the event. This is repeated untill the receiveing controller wishes not to forward the event further or there simply is no child controller. Same for focus events: the only difference is that there isn't a PickTraversal. the event is delivered to the top most controller having input focus. This controller then can forward the event to the child controller having focus etc. Since focus already is based on exclusiveness, we don't need to grab (getting the focus is the grab if you like). positional events need to be grabbed if a controller wishes to get the event even though the pointer is not over it. (pressed controllers most probably want to receive the release too, so all in between should be send to that controller). Best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Wed Jun 23 16:20:53 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:34 2005 Subject: need advice for computer hardware -- offtopic In-Reply-To: <3770F91D.AC6BBDB2@mbz.org> References: <3770F91D.AC6BBDB2@mbz.org> Message-ID: <37710965.D0711A42@wserv.com> Alain Toussaint wrote: > the OS considered would be linux and NT,but for 10 000$ AUS,i don't have > any recommendation since i never even though of buying something near > the 10K AUS price cap,could some of you give me advices privately (don't > mail back to the list) on the best setup for this budget ?? Now, I don't usually recommend going to commercial vendors like Dell, but. If you have this kind of money to play around with, take a look at VA Research, Compaq or Dell, which should all be able to preload Linux on. What you might also want to do is just get the specs for the VA Research box and buy the parts individually that match. You can insure compatibility and stability this way. They use pretty standard parts, intel motherboards, mylex raid, etc. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Wed Jun 23 17:11:11 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:34 2005 Subject: input event filtering Message-ID: <21D757CECBD2D211AD5D00105A2974A7368EDF@EXCHANGE> > X allows displays to subscribe to any events for any window. > That is, you can write applications which get almost all the > interaction between the server and arbitrary clients (given > that in X interaction is almost exclusively event based). > > Do we want that ? What are the pros, what are the cons ? > The reason I discuss this is that Graydon objected to a > proposition for implementing event delivery based on exclusive > grabs since toys (and possibly real tools) like xeyes are only > possible if *everyone* gets informed about all the events. > The other problem with exclusive grabs is that I could write a buggy or malicious program that was an "event hog". It could register itself (possibly early in whatever container holds the listeners) and consume all events, preventing other applications from functioning (or responding to user input, rather). > based on the X protocol, which allows basically anything to > be observed, I used the multicast pattern (see 'Pattern Hatching') > to let an Event dispatch itself to subscribers. Subscribers are > registered in one of three lists: > > * filters > * handlers > * fallbacks > This arrangement seems like a good design, at least for "public" events. I wonder if there would be a reason to have two classes -- public and private for events? A private event might be something like a modal dialog box button-press that prevents any other activity until its message is replied to? No one else may consume this event. But this might allow someone to write a program that generates a modal dialog that does not permit exit and lock your system... Under this scenario, it seems like pointer movements should be "public" while button press/release might be either "public" or "private". -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Wed Jun 23 21:52:29 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? In-Reply-To: <21D757CECBD2D211AD5D00105A2974A7368E8C@EXCHANGE> References: <21D757CECBD2D211AD5D00105A2974A7368E8C@EXCHANGE> Message-ID: <19990623175229W.graydon@pobox.com> I think our ship might have come in -- IBM releases unicode utility library under (what looks like, correct me if I'm wrong) a compatible license. http://www.alphaworks.ibm.com/tech/icu/ I've downloaded it and am browing now. it looks very fine. it's got everything. every possible textual feature you could want in a unicode library is here. hooray alphaworks. this saves us years of work if it's useable. any license-gurus around to confirm? -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Wed Jun 23 22:22:04 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:34 2005 Subject: Unistring & Unicode? In-Reply-To: <19990623175229W.graydon@pobox.com> References: <19990623175229W.graydon@pobox.com> Message-ID: <99062400225000.03819@alcatraz168> On Wed, 23 Jun 1999, Graydon Hoare wrote: > I think our ship might have come in -- IBM releases unicode utility > library under (what looks like, correct me if I'm wrong) a compatible > license. > > http://www.alphaworks.ibm.com/tech/icu/ > > I've downloaded it and am browing now. it looks very fine. it's got > everything. every possible textual feature you could want in a unicode > library is here. hooray alphaworks. this saves us years of work if > it's useable. any license-gurus around to confirm? > > -graydon > I'll look into the code this weekend. The license looks acceptable to me. Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Thu Jun 24 16:11:39 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: focus model In-Reply-To: <199906240035.UAA05919@dirk.holoweb.net> References: <199906240035.UAA05919@dirk.holoweb.net> <376E959F.6998CEFE@magellan.umontreal.ca> Message-ID: <377258BB.637D7845@magellan.umontreal.ca> Laurie Harper wrote: > > Stefan wrote '>' stuff, MenTaLguY wrote '>>' stuff: > > > > ISTR, though, that the issue of exactly what we want to do with the >focus > > > model, particularly when dealing with multiple input devices, is still >more > > > or less up in the air. > > Right. > > Now might be a good point to suggest a distinction between 'focus model' > and 'focus policy' (it's probably a good time to pick more distinctive > terms too, really, but bare with me). There's a difference between 'What > should Warsaw specify / Berlin implement as supported functionality?' and > 'What behaviour should the user see when interacting with Berlin?' Right. However, in all my mails I was exclusively addressing the supported functionality. The actual policy is something we should be able to plug in as a strategy. It is good though to think about possible policies since it defines the required functionality. > I'd certainly like there to be a mechanism for ignoring events and allowing > them to propogate up the scene graph, at the implementaion level; but as a > user I'd be very upset if I clicked in a window that I didn't realise had > chosen not to receive mouse events, if the application running in the > window hiden underneath received that mouse click and interpreted it as > a request to re-format my file system... That's definitely a policy issue. I mean, if we allow events to be filtered and not directly delivered to the topmost controller under the pointer, there is always the possibility for a malicious controller to intercept the event and do insane things. > As I understand things, this is the Warsaw vs. Moscow separation, and we > should be sure of which context we're talking about while discussing focus. Hmm, not sure whether it helps much to distinguish at this point Warsaw and Moscow. If you insist, Moscow should define how to install a concrete policy (as part of a window manager or so) while the functionality for all this to work has to be defined in Warsaw. Controllers are the correct context to discuss this I think and since Controllers are a quite basic and central notion for input event handling (therefor coupled to PickTraversals) it has to stay in Warsaw. > This sounds like the right model for event propogation and the wrong model > for focus policy, given the distinction I drew above. (In fact, event > propogation vs. focus policy is probably a good terminology distinction > to adopt, too...). Hmm, it seems to me that event filtering and focus policy are two things. There is a high level policy (the one discussed above) which for example determines the keyboard focus vs. pointer event dependance, and there is the low level issue about input event (pointer) grabs. The reason I make this distinction is that while the former only influences the user's interaction with the UI, the latter changes the controller behavior itself. > > > Incoming events descend throught the stack, giving each listener an > > > opportunity to either consume the event, or allow it to pass through to >the > > > listener below. A widget or other entity interested in gaining the >"focus" > > > would push itself (as a subclass of EventListener or similar) onto the >top > > > of the input device's listener stack, so it would get "dibs" on any >events > > > it was interested in (relative to anything below it on the stack, >anyway; > > > anything pushed on top of it later would have more priority). > > Assuming this is a description of event propogation, then pushing and > popping would presumably occur whenever the stacking order changed; in other > words, it could probably be implicit in the extrinsic state of the scene > graph. No. I think pushing and popping in the event filtering context means a history stack of controllers holding the grab. If one controller releases the grab the last which had the grab before will get it again. This stack has nothing to do with the scene graph. > Speaking of 'event propogation listeners' making copies along the way, does > Warsaw offer (or if not, should Warsaw offer) a mechanism for *re-writing* > events on their way through? (I know, I should know the answer to this > from reading the IDL...) > > A GUI toolkit I was writing a few years ago had a (hugely overly) complex > event processing model which included the ability for an application to > re-write events. So, for example, a mouse click on a button could be re- > written by the button as an Enter key-press and re-inserted into the event > queue; the button might then say 'I don't listen to keyboard events' and > let it propogate up to the parent widget. > > I abandoned the toolkit when I got interested in learning Java instead, > but I've been trying to decide whether this idea was sane ever since :) > It offers interesting posibilities for application writers, but I suspect > it'd be too easy to abuse in horrible ways... Comments? Right, it's an invitation for abuse. I think the problem is the lack of a distinction between raw and semantic events. While the mapping between the two should be flexible, there should be no need to emulate event sending by any receiver. However, I understand the interest: what about 'accelerators' ? Wouldn't it be nice to design the event handling so that a key event or a combination thereof would generate the same semantic event as a pointer event. May be we should reclassify all this raw events, semantic events, commands. Or, while (sequences of) events should result in commands to be executed (bound to buttons of all kind like pushbuttons, menu items etc.) there could be event combinations (shortcuts, accelerators) which directly map to those commands. I think this is something to be discussed in the context of Model-Controller separation. Anyway, I'm getting off topic a bit. Sorry. > > > > This is actually relatively similar to what GGI Console (nee EvStack) >does > > > in some cases (and indeed, you may want to have a look at some of the >GGI > > > Console design; it's got a very interesting approach to input stuff in > > > general). > > Am I right in thinking GGI (or GII) has some design-level support for > less-common i/o devices, like VR gloves for example? the interesting aspect is that when thinking of event propagation and focus handling, it is easy to think of mice and keyboards since it has been done in every toolkit. Now, if we want to make things more abstract like allowing any input devices to have its own focus and its own shared resources associated to it, it becomes utterly complex. Yet I think it is at this level that we should try to resolve the problems. > > ok. I discussed 'Focus' as two things: first (and that's what you are >referring > > to here) a filter which let's different controllers 'have' the focus. I >fully > > agree that your scheme with filtering seems quite appropriate. It's the >way > > most GUI toolkits manage events. So for every input device we could >install > > a stack which Event filters are pushed on within some 'grab' function. > > This would be what I'm referring to as 'event propogation' and suggesting > an implicit push/pop as part of the scene graph. But I'm not comfortable > with the term 'grab' here, since it has a somewhat different meaning in X. Not at all. > Look at what happens to your mouse pointer if you bring up a menu in > Netscape; you can't click something in some other application's window, > because that click would dismiss the Netscape window instead. Why? > Netscape (or, more accurately, Motif) did a 'mouse grab'. In X, a > grab means 'gain exclusive control, regardless of the focus policy or > anything else. X has different levels of grab. There is a call to 'XGrabPoiner' which takes parameters to specify the policy of the grab. And there is an implicit grab done by the server itself for every button press. An XWindow will receive all following pointer events untill the button is released. (button here means mouse button). We have to deal with both. > > The Focus management would go into the Controller interface (methods like > > hasFocus, acceptsFocus, enterFocus, leaveFocus or so) and a pluggable >component > > which actually implements the Focus policy which may heavily vary (see >window > > managers under X to see how different that could be). > > > > This sounds like the bridge between the available functionality, as >specified > by Warsaw, and the active policy as described by Moscow. I'd say that puts > it into Moscow rather than Warsaw, and as such it shouldn't be in the API; > focus is a higher-level concept than Warsaw is dealing with, IMHO. It is the functionality of Warsaw, which lets Controllers specify how it *can* deal with focus. It's not imperative. Controller::acceptsFocus() is a query whether the Controller has a meaningful way to deal with focus. And Focus objects may request some shared resources to be set. It is the Focus Manager's job to implement a policy which then decides whether to acknowledge all requests or else how to deal with them. Regards, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Thu Jun 24 16:43:28 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:35 2005 Subject: Sonames Message-ID: <19990624094328.A2039@localhost> Hello all - I am just going over the build tree to add an install target and sonames once again. Now, I can't seem to find docs anywhere that specify the flag you use to set the library's soname. As I remember, it was something like: -Wl,-soname $(major).$(minor) or something like that. I don't know if ldconfig can interpret .so's that weren't compiled with this flag. I suppose I'll just try and see. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Thu Jun 24 17:04:41 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: Sonames In-Reply-To: <19990624094328.A2039@localhost> References: <19990624094328.A2039@localhost> Message-ID: <37726529.E81DC7D3@magellan.umontreal.ca> Aaron Van Couwenberghe wrote: > > Hello all - > > I am just going over the build tree to add an install target and > sonames once again. Now, I can't seem to find docs anywhere that specify the > flag you use to set the library's soname. As I remember, it was something > like: > > -Wl,-soname $(major).$(minor) > > or something like that. I don't know if ldconfig can interpret .so's that > weren't compiled with this flag. I suppose I'll just try and see. I think its the right option. However, is it really worth the efford ? I mean, if I understand that right, it's all to make it possible to later install newer libraries without having applications to care about it. Since we are changing way too much stuff for this to make sense, I don't see any advantage in adding this. Regards, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Thu Jun 24 18:12:07 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:35 2005 Subject: TAO Message-ID: <21D757CECBD2D211AD5D00105A2974A7373C72@EXCHANGE> Has anyone looked at the TAO ORB? I see that it has been modified to work with Flick, which can now produce C and C++ stubs from IDL. The main advantage is that Flick is completely unencumbered, so it doesn't have the SUN license foo in it. An even better alternative would be a modified omniORB that could use Flick. Duncan, if you are listening, is there any hope? -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Thu Jun 24 20:51:20 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: input event filtering In-Reply-To: <21D757CECBD2D211AD5D00105A2974A7368EDF@EXCHANGE> References: <21D757CECBD2D211AD5D00105A2974A7368EDF@EXCHANGE> Message-ID: <37729A48.6C8F8659@magellan.umontreal.ca> Brent Fulgham wrote: > The other problem with exclusive grabs is that I could write a > buggy or malicious program that was an "event hog". It could > register itself (possibly early in whatever container holds > the listeners) and consume all events, preventing other > applications from functioning (or responding to user input, rather). Hmm. The question is whether we can avoid this. Sometimes it might even be necessary to filter out events, for whatever reason. The argument that evil clients could abuse this feature doesn't address a problem introduced here. Since lots of features are handled decentralized (all the traversals...) there is in fact much room for abuse. The question is really to find a good trade off between functionality and security. > > > based on the X protocol, which allows basically anything to > > be observed, I used the multicast pattern (see 'Pattern Hatching') > > to let an Event dispatch itself to subscribers. Subscribers are > > registered in one of three lists: > > > > * filters > > * handlers > > * fallbacks > > > This arrangement seems like a good design, at least for "public" > events. I wonder if there would be a reason to have two classes -- > public and private for events? A private event might be something > like a modal dialog box button-press that prevents any other > activity until its message is replied to? No one else may consume > this event. But this might allow someone to write a program that > generates a modal dialog that does not permit exit and lock your system... > > Under this scenario, it seems like pointer movements should be > "public" while button press/release might be either "public" > or "private". Yes, may be. However, I can't help, it all looks like an awful hack. I mean, there are lots of possibilities to do whatever we want, but it's always like a rule with more exceptions than normal cases. I'd really prefer some clean and intuitive protocol which is simple but includes in a straight forward manner all the special cases we need to consider. I must say, concering the deadlock situation with modular dialogs which won't die. I think since pointer grabs are necessary (also I don't like at all this special case of grabs for dialogs) all we need to ensure is that there is some way to force a pointer release. In X often you need to restart the server (killing all X clients). If there was a way to signal to the server that it should remove the client, it would be less a problem. May thing like the ServerContext's ping method which tests whether the client is still active. May be a timeout or something should test regularly the validity of the current grab... ...just thinking aloud... Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Thu Jun 24 21:09:54 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:35 2005 Subject: input event filtering Message-ID: <21D757CECBD2D211AD5D00105A2974A737845E@EXCHANGE> > > The other problem with exclusive grabs is that I could write a > > buggy or malicious program that was an "event hog". It could > > register itself (possibly early in whatever container holds > > the listeners) and consume all events, preventing other > > applications from functioning (or responding to user input, rather). > > Hmm. The question is whether we can avoid this. Sometimes it might > even be necessary to filter out events, for whatever reason. > The argument > that evil clients could abuse this feature doesn't address a problem > introduced here. Since lots of features are handled decentralized > (all the traversals...) there is in fact much room for abuse. > The question is really to find a good trade off between functionality > and security. > We could always go with the X-ish approach (or rather Xlib's) which can be configured such that certain hosts are considered trusted vs. others. So I could specify that your machine is trusted, login and run stuff on your end. While I might be more suspicious of Graydon ;) and set his trust level lower. In fact, perhaps there could be a tiered-trust approach, where I might give you a trust of "10" meaning complete trust, vs. Graydon at "5", while all of the rest of you don't trust me at all, giving me a trust of "0". At "10" you can perform any actions you want -- i.e., consume any event, etc. While at "5" you might be limited to only "see" events and not consume, or only consume 1 event per 20 seconds, or somthing. (Now I'm just thinking aloud). At "0" you wouldn't even let an app on my machine connect to Berlin service on your end. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From dgrisby at uk.research.att.com Fri Jun 25 13:32:27 1999 From: dgrisby at uk.research.att.com (Duncan Grisby) Date: Fri Feb 25 22:23:35 2005 Subject: TAO In-Reply-To: <21D757CECBD2D211AD5D00105A2974A7373C72@EXCHANGE> References: <21D757CECBD2D211AD5D00105A2974A7373C72@EXCHANGE> Message-ID: <199906251332.OAA24973@pineapple.cam-orl.co.uk> On Thursday 24 June, Brent Fulgham wrote: > I see that it has been modified to work with Flick, which can now > produce C and C++ stubs from IDL. The main advantage is that > Flick is completely unencumbered, so it doesn't have the SUN > license foo in it. > > An even better alternative would be a modified omniORB that > could use Flick. Duncan, if you are listening, is there any > hope? Work is currently underway on a new IDL compiler, although it's likely to be quite a while before it's done. There would be very little to gain by creating a Flick back-end for omniORB, since Flick's main selling point is that it produces "highly optimised" stubs. omniORB already does almost all [1] of its optimisations, as well as a few more. The only reasons for not sticking with the current IDL compiler front end are 1. it's horrid, and 2. the Sun license. The only one of these which bothers us is 1. It's my personal opinion that Sun's license causes no operational difficulties whatsoever, and the Debian people are being over-the-top in objecting to it. Duncan. [1] The only optimisation which Flick does which omniORB doesn't is to combine the string comparisons performed during operation dispatch into more cunning arrangements. We don't do this because its impact on the total operation dispatch time is minimal, and there's a danger that it might actually go slower on some machines, due to interactions with things like branch prediction. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Fri Jun 25 16:16:43 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:35 2005 Subject: TAO Message-ID: <21D757CECBD2D211AD5D00105A2974A737C609@EXCHANGE> Thanks for the info. We'll look forward to the new front end when it's ready. :) > The only reasons for not sticking with the current IDL compiler front > end are 1. it's horrid, and 2. the Sun license. The only one of these > which bothers us is 1. It's my personal opinion that Sun's license > causes no operational difficulties whatsoever, and the Debian people > are being over-the-top in objecting to it. > Yes -- the restriction is really only in place to require conformance with standards. This seems like a reasonable restriction in order to encourage interoperability, etc. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 25 19:36:20 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press Message-ID: <3773DA34.ED848C1E@wserv.com> Hello all, With the new development release coming out, I think we should probably try to get a little more press for the project. It wouldn't help to get a few more developers and a little funding. Over the past 6 months, I've seen the opinions for Berlin go from, "it's vapourware and it'll never happen" to "well berlin has that feature, but it's not done yet", which tells me people are interested. I also think it might be a good idea to update Berlin's development patch number to 0.1.0 instead of 0.0.2, mainly because the tree itself has changed radically from 0.0.1. Anyway, I just thought I'd mention it. Btw - that Unicode library works pretty well, it compresses those data files down pretty well and caches them, but I don't see any uncaching routines (probably good to unload a map if not used within x hours to save a little ram). As IBM seems to have a Java VM for Linux on alphaworks as well, it might be interesting to port a few more of the Java environment over to C++ (basically that's what the Unicode library is from what I can tell, the API is identical to Java). There are a few nifty little things in Java which might be nice to have, the security manager sandbox, the rest of the i18n, etc would be good for inspiration. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mars at lysator.liu.se Fri Jun 25 19:42:17 1999 From: mars at lysator.liu.se (Stefan Mars) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press In-Reply-To: <3773DA34.ED848C1E@wserv.com> References: <3773DA34.ED848C1E@wserv.com> Message-ID: On Fri, 25 Jun 1999, Jordan Mendelson wrote: > I also think it might be a good idea to update Berlin's development patch >number > to 0.1.0 instead of 0.0.2, mainly because the tree itself has changed >radically > from 0.0.1. Technically that would mean a beta instead of an alpha version. A bit early, wouldn't you say? > Anyway, I just thought I'd mention it. Same here :-) /Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering || | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology || | S-584 36 Linkoping | || | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 || |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at || | http://www.lysator.liu.se/%7Emars/thxguide.html || \--------------------- PGP key available through finger ----------------------/ -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 25 19:47:19 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: bugs.berlin-consortium.org Message-ID: <3773DCC7.70853624@wserv.com> Alright, I really should get the bugzilla database setup correctly, but I need a few suggestions. Bugzilla has two types of listings, products & components. Products right now would just be Berlin, as it's really the only project we are working on. Later down the road if we ever split the packages into peices, we could add say, a Notepad product for an editor we are working on, etc. Components can be assigned several different proptiers, a maintainer email address which new bugs are cc'ed to and updates are cc'ed to, a description, and a version number. What we should really do is get a second development mailing list since I doubt many of you want to look at every single bug report that comes in and we really don't have set maintainers right now. So can anyone suggest a few components I can add? Right now I can think of a few: Build System - Makfiles, Autoconf, etc. Registrar - Persistant configuration storage database Display Server - OpenGL display server Unicode - I18N text handling system Samples - Sample Berlin applications (maybe seperate this oen) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 25 19:54:34 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: reference manual Message-ID: <3773DE7A.AC1AEA4A@magellan.umontreal.ca> Hi, I played around a bit with perceps and got it to produce html. Have a look at As you will notice, there isn't a single bit of documentation in it, it's just raw output from a scan over the class definitions. Also, since IDL isn't supported yet, I couldn't add Warsaw to it. The use of namespaces in different places has created buggy output too but the author of perceps confirms that he is working on namespace support. I'll now try to play a bit with the 'templates' which define how all the data should be written down. If this is done, the output will be docbook conformant so we can process it with the sgml-tools. Simultaniously, I'll start writing down the docs into the header files. Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 25 19:55:47 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press In-Reply-To: References: Message-ID: <3773DEC3.D4866DC8@wserv.com> Stefan Mars wrote: > > On Fri, 25 Jun 1999, Jordan Mendelson wrote: > > > I also think it might be a good idea to update Berlin's development patch >number > > to 0.1.0 instead of 0.0.2, mainly because the tree itself has changed >radically > > from 0.0.1. > > Technically that would mean a beta instead of an alpha version. A bit > early, wouldn't you say? Oh, I really never thought of that :) I've always thought of it like this for source: Major.Minor.Patch Patch updates when minor updates to the source tree happen which do not require any radical changes. Minor updates when library updates and a bit larger updates happen to the tree Major updates when complete library incompatibility updates and major tree changes or stable releases. For binaries, I've always thought of: Major.Minor.Patch.Build or Major.Minor.Patch-Build or Major.Minor.Patch (Build) or #Build The first is what a lot of commercial applications use, the second is what debian uses, and the third is what a lot of Unices use for kernel versions. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 25 20:05:37 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: bugs.berlin-consortium.org In-Reply-To: <3773DCC7.70853624@wserv.com> References: <3773DCC7.70853624@wserv.com> Message-ID: <3773E111.90680BF1@magellan.umontreal.ca> Jordan Mendelson wrote: > > Alright, I really should get the bugzilla database setup correctly, but I >need a > few suggestions. > > Bugzilla has two types of listings, products & components. Products right >now > would just be Berlin, as it's really the only project we are working on. >Later > down the road if we ever split the packages into peices, we could add say, a > Notepad product for an editor we are working on, etc. > > Components can be assigned several different proptiers, a maintainer email > address which new bugs are cc'ed to and updates are cc'ed to, a >description, and > a version number. > > What we should really do is get a second development mailing list since I >doubt > many of you want to look at every single bug report that comes in and we >really > don't have set maintainers right now. > > So can anyone suggest a few components I can add? Right now I can think of a > few: Hmm I suspect if speaking of components you mean something like sub projects which bugs could associated to so the people involved into those sub project could pick it up. I agree that we should fragment the project a bit, i.e. assign people to the various kits etc. since this makes it easier to work on it. > Build System - Makfiles, Autoconf, etc. > Registrar - Persistant configuration storage database > Display Server - OpenGL display server > Unicode - I18N text handling system > Samples - Sample Berlin applications (maybe seperate this oen) I would split Berlin into these sub projects / responsabilities: * build system * Prague * Berlin * TextKit * (GL)DrawingKit * LayoutKit * FigureKit * WidgetKit * ImageKit * CommandKit * StyleManager (incl. Registrar) * Unicode (if it's too large to be put into Prague) * new projects to be created, such as XML/DOM, special clients etc. (did I miss something ?) Actually, I think this splitting would be quite useful not only for bug tracking. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 25 20:06:21 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: reference manual In-Reply-To: <3773DE7A.AC1AEA4A@magellan.umontreal.ca> References: <3773DE7A.AC1AEA4A@magellan.umontreal.ca> Message-ID: <3773E13D.5EF6BAE8@wserv.com> Stefan Seefeld wrote: > > Hi, > > I played around a bit with perceps and got it to produce > html. Have a look at > > > As you will notice, there isn't a single bit of documentation > in it, it's just raw output from a scan over the class definitions. > Also, since IDL isn't supported yet, I couldn't add Warsaw to it. > The use of namespaces in different places has created buggy > output too but the author of perceps confirms that he is working > on namespace support. > I'll now try to play a bit with the 'templates' which define > how all the data should be written down. If this is done, the output > will be docbook conformant so we can process it with the sgml-tools. > Simultaniously, I'll start writing down the docs into the header files. Not bad. The formatting needs a little work. I'd really like each superclass was listed on a single page with general definitions and I could click the superclass and view functions & variables with descriptions, and then click on the description to get a in-depth information on the function (we should really put in examples in the function definitions as well :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 25 20:14:44 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: reference manual In-Reply-To: <3773E13D.5EF6BAE8@wserv.com> References: <3773E13D.5EF6BAE8@wserv.com> <3773DE7A.AC1AEA4A@magellan.umontreal.ca> Message-ID: <3773E334.CF365731@magellan.umontreal.ca> Jordan Mendelson wrote: > > Stefan Seefeld wrote: > > > > Hi, > > > > I played around a bit with perceps and got it to produce > > html. Have a look at > > > > > > As you will notice, there isn't a single bit of documentation > > in it, it's just raw output from a scan over the class definitions. > > Also, since IDL isn't supported yet, I couldn't add Warsaw to it. > > The use of namespaces in different places has created buggy > > output too but the author of perceps confirms that he is working > > on namespace support. > > I'll now try to play a bit with the 'templates' which define > > how all the data should be written down. If this is done, the output > > will be docbook conformant so we can process it with the sgml-tools. > > Simultaniously, I'll start writing down the docs into the header files. > > Not bad. The formatting needs a little work. > > I'd really like each superclass was listed on a single page with general > definitions and I could click the superclass and view functions & variables >with > descriptions, and then click on the description to get a in-depth >information on > the function (we should really put in examples in the function definitions >as > well :) Ok, ok. I'll keep that in mind. May be we could assemble a wish list for the manual format so I (or whoever happens to work on the formatting templates) can look into it. As I said, it's really very raw material, it needs major modification to become useful. But it's a start ! I will commit perceps in the berlin-tree/bin directory and the templates into berlin-tree/etc/perceps so whoever wants can work on that. Since the new maintainer of perceps is himself working on perceps I think it's not worth doing the same here. Whoever wants to accelerate the perceps development (especially IDL parsing which isn't possible at all right now) should probably join it's maintainer. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Fri Jun 25 20:15:38 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press In-Reply-To: <3773DEC3.D4866DC8@wserv.com> References: <3773DEC3.D4866DC8@wserv.com> Message-ID: <3773E36A.68E1B612@magellan.umontreal.ca> Jordan Mendelson wrote: > > Stefan Mars wrote: > > > > On Fri, 25 Jun 1999, Jordan Mendelson wrote: > > > > > I also think it might be a good idea to update Berlin's development >patch number > > > to 0.1.0 instead of 0.0.2, mainly because the tree itself has changed >radically > > > from 0.0.1. > > > > Technically that would mean a beta instead of an alpha version. A bit > > early, wouldn't you say? > > Oh, I really never thought of that :) > > I've always thought of it like this for source: > > Major.Minor.Patch > > Patch updates when minor updates to the source tree happen which do not >require > any radical changes. > Minor updates when library updates and a bit larger updates happen to the >tree > Major updates when complete library incompatibility updates and major tree > changes or stable releases. > > For binaries, I've always thought of: > > Major.Minor.Patch.Build or Major.Minor.Patch-Build or Major.Minor.Patch >(Build) > or #Build > > The first is what a lot of commercial applications use, the second is what > debian uses, and the third is what a lot of Unices use for kernel versions. I agree that we should use 0.1.0 for the next release. Since it is another CVS branch, we initiate it with number 0.1.0 adding patches and features to it. It is, after all, a 'development' release, only even numbers (0.2.0) are for public use. I think that naming it 0.1.0 indeed indicates that it is not compatible with the old one. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Fri Jun 25 20:24:44 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:35 2005 Subject: focus model Message-ID: <199906252024.QAA16953@hendrix.cs.rit.edu> First, a short introduction. My name is Aaron Gaudio (aka Prothonotar), a student at the Rochester Institute of Technology. When I first heard of the Berlin Project, I though to myself that there was really no point, that X was it in the UNIX world and even if Berlin was a better system, X would continue to be it. Well, after taking a look at some of the ideas, ideals and design concepts of the Berlin Project, I have gotten the impression that the design that is there is very well thought out (unlike most open source projects) and that there is obviously some folks involved who are not only intelligent but capable of some real software engineering. With the deficiencies of X becoming more apparent day by day as other non-UNIX operating systems continue to outpace the UNIX world in terms of graphical environments (and the functionally irrelevant CDE being the flagship of the UNIX desktop while the KDE and GNOME rogues beat themselves to death), the need for a clean sweep is clear. Berlin seems to me to be the best chance for that clean sweep. I don't usally have alot of time to be able contribute code to projects, but often I'll offer my thoughts on some issue or another, and I think Berlin is important enough of a project to grab my attention. Sometime I need to take the time to actually catch up with Berlin (that is, build it, run it, look at some code and design stuff in it, etc.), but in the meantime I can offer my half-informed ideas ;-) Now, I have just subscribed (hopefully, I tried it before but it didn't take) to the mailing list, but would like to respond to some messages put out before I subscribed, so please bare with me.... Stefan Seefeld wrote: > ok, some thoughts on the topic: > > there are quite different possibilities to deal with > even filtering: > > X allows displays to subscribe to any events for any window. > That is, you can write applications which get almost all the > interaction between the server and arbitrary clients (given > that in X interaction is almost exclusively event based). > > Do we want that ? What are the pros, what are the cons ? > The reason I discuss this is that Graydon objected to a > proposition for implementing event delivery based on exclusive > grabs since toys (and possibly real tools) like xeyes are only > possible if *everyone* gets informed about all the events. > > What are the alternatives ? > We could classify events in 'private' and 'public', i.e. > which are exclusive and should not be seen by anyone but > the grabber. > How about the ability for a client to install a so-called "glass pane" in another arbitrary client which can receive any positional events which would normally be received to the client below it? In terms of implementation, adding a filter to the top of the event receiver stack. If the "glass pane" is "transparent", then it the filter does not consume the event, but if it is "opaque" then it may filter the event. These panes would be treated as if they were just normal components within the top-most component in the window in question, but just that they may not actually belong to the same client (which should be trivial, since CORBA was designed to be distributed). Once a filter is installed, the event dispatch needn't know that the component region doesn't belong to the same client. Such glass panes could be installed at any level on a per-container basis, meaning that you could filter events to a button, a window or the entire screen. The main difference between such components and normal GUI components would be that rather than "stacking up" from root, these would exist at a higher level than all normal components. When I install a normal button over a window frame and then a text label over the button, the text label will be "on top", the button beneath it and the frame on the bottom. When I then install a glass pane over the frame, the glass pane is "above" the button and text, even though it is installed in a lower level container. Similarly, if I install a glass pane on the root window, it will be "above" all other normal windows. If multiple glass panes are installed, they are stacked as normal. To get even more complex, I could install normal components on a glass pane, the normal components would receive events (and presumably consume them) before those of the normal containers below them, but I could install a glass pane on a glass pane, which would in turn filter the events of those "normal" components. The "stacking order" of the glass pane could be explicitely altered, so that it may not be "on top" of other containers after all, in much the same way windows can be raised and lowered; it's just that the glass pane will by default be above all non-glass pane components. To protect oneself, a client can choose to allow or disallow a third party to install a glass pane on it (just as, presumably, it could allow or disallow a third party to install normal components in it). If a third party tries to install any component into a client, that client will receive that message in the form of an event and do what it will with it (ignore it, raise an exception, install it, etc), so that I could have a container (such as the root window, for example) which will allow clients to install glass panes on it (for an Xeyes-like effect, or to go into "screenshot" mode to select a region of the screen, etc) but might make sure that its own internal glass pane is always on the top of the stack. In the case of the root window, this could be used to capture special key-sequences (Ctrl-Alt-Bksp, for example) to make sure that no other client can override them (so that if a client with a root glass pane freezes up but keeps consuming all events, I can still get out [either get something to allow me to kill the client or at least kill Berlin]). Modal windows would be installed on a glass pane to the root window. Events hitting the glass pane (those not consumed by the modal window- I'm looking at the event dispatch as falling from top to bottom, which is conceptually how it will be, although internally it's the other way around) will be handled by the window manager. This way, the window manager can decide whether or not to lower the glass pane (for instance, I prefer modal windows to only act modal for windows of the same client, not all windows). Xeyes (or rather, Beyes, as the case may be) would install a glass pane on the root window which simply receives all mouse motion events and then lets them pass on unscathed (i.e. the root window will first give the event to Beyes, then when Beyes is done with it, it will pass it to the next container the event is destined for). This mechanism could be altered so that certain clients can inform Berlin not to allow any glass pane over their components (for security/privacy), so that even if a glass pane is installed on the root window, it wont get any events that are heading for the client below), this could be implemented behind the scenes by using another glass pane managed by the Berlin server itself which "circumvents" the offending glass pane by delivering the event directly and then marking it as consumed (only for the exposed region of the paranoid client's window, of course). -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Fri Jun 25 20:34:24 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press Message-ID: <199906252034.QAA17037@hendrix.cs.rit.edu> And lo, the chronicles report that Aaron Gaudio spake thusly unto the masses: >From adg1653 Fri Jun 25 16:33:04 1999 Subject: Re: Berlin 0.0.2 Press To: jordy@wserv.com (Jordan Mendelson) Date: Fri, 25 Jun 1999 16:33:04 -0400 (EDT) In-Reply-To: <3773DEC3.D4866DC8@wserv.com> > from "Jordan Mendelson" at Jun 25, 99 03:55:47 pm From: Aaron Gaudio X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1361 And lo, the chronicles report that Jordan Mendelson spake thusly unto the masses: > > I've always thought of it like this for source: > > Major.Minor.Patch > > Patch updates when minor updates to the source tree happen which do not >require > any radical changes. > Minor updates when library updates and a bit larger updates happen to the >tree > Major updates when complete library incompatibility updates and major tree > changes or stable releases. > > For binaries, I've always thought of: > > Major.Minor.Patch.Build or Major.Minor.Patch-Build or Major.Minor.Patch >(Build) > or #Build > Further, for binary libraries, libraries with the same major revisions should be binary-compatible (that is, binaries using an older patch release of a library should work with a newer patch release without recompile), IIRC. Are equal minor numbers supposed to imply source-level compatibility (recompile without altering the source)? -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mars at lysator.liu.se Fri Jun 25 20:57:08 1999 From: mars at lysator.liu.se (Stefan Mars) Date: Fri Feb 25 22:23:35 2005 Subject: Berlin 0.0.2 Press In-Reply-To: <3773DEC3.D4866DC8@wserv.com> References: <3773DEC3.D4866DC8@wserv.com> Message-ID: On Fri, 25 Jun 1999, Jordan Mendelson wrote: > I've always thought of it like this for source: > > Major.Minor.Patch There are different schools I guess, and it doesn't really matter that much. But you shouldn't bump it up to 0.1.0 just because a lot have changed since 0.0.1, because Berlin is nowhere near being called a beta, and at least I expect alpha versions to change much. It is better to call it 0.0.2 than to confuse people who might think Berlin just became usable. /Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering || | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology || | S-584 36 Linkoping | || | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 || |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at || | http://www.lysator.liu.se/%7Emars/thxguide.html || \--------------------- PGP key available through finger ----------------------/ -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Fri Jun 25 21:11:39 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:35 2005 Subject: bugs.berlin-consortium.org Message-ID: <21D757CECBD2D211AD5D00105A2974A7381AD5@EXCHANGE> I just wanted to second Stefan's motion on this breakdown: > I would split Berlin into these sub projects / responsabilities: > > * build system > * Prague > * Berlin > * TextKit > * (GL)DrawingKit > * LayoutKit > * FigureKit > * WidgetKit > * ImageKit > * CommandKit > * StyleManager (incl. Registrar) > * Unicode (if it's too large to be put into Prague) > * new projects to be created, such as XML/DOM, special clients etc. > -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Fri Jun 25 23:52:48 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: Woops Message-ID: <37741650.BB4DEFA3@wserv.com> Sorry about the bugzilla stuff, I was just testing the email notifications and accidently changed all of them and didn't realize it until the mail was out the door. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From zodiac at holoweb.net Sat Jun 26 01:27:00 1999 From: zodiac at holoweb.net (Laurie Harper) Date: Fri Feb 25 22:23:35 2005 Subject: Unistring & Unicode? In-Reply-To: <19990623175229W.graydon@pobox.com> References: <21D757CECBD2D211AD5D00105A2974A7368E8C@EXCHANGE> <19990623175229W.graydon@pobox.com> Message-ID: <199906260127.VAA06666@dirk.holoweb.net> Graydon Hoare speakificated the following: > I think our ship might have come in -- IBM releases unicode utility > library under (what looks like, correct me if I'm wrong) a compatible > license. > > http://www.alphaworks.ibm.com/tech/icu/ Hmm... the alphaWorks site seams to have been BC'd (like being /.'d but generally comes as more of a surprise ;) so I can't check the license, but: If it's the same one they released Jikes and their XML tools under, it has a revocation clause that probably makes it non-GPL compatible. Basically, they reserve the right to revoke your license and require you delete any and all copies. If you've distributed software with the alphaWorks component, you're then responsible for recalling all copies... :-( Nasty! -- Leave it to the computer programmers | zodiac @ holoweb . net or ^.^ to shorten the "Year 2000 Millennium | laurieh @ groveware . com v Bug" to "Y2K." Isn't that what caused | http://www.groveware.com/ this problem in the first place? | http://www.holoweb.net/~zodiac/ -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From zodiac at holoweb.net Sat Jun 26 02:01:00 1999 From: zodiac at holoweb.net (Laurie Harper) Date: Fri Feb 25 22:23:35 2005 Subject: focus model In-Reply-To: <377258BB.637D7845@magellan.umontreal.ca> References: <377258BB.637D7845@magellan.umontreal.ca> <199906240035.UAA05919@dirk.holoweb.net> <376E959F.6998CEFE@magellan.umontreal.ca> Message-ID: <199906260201.WAA06686@dirk.holoweb.net> Stefan Seefeld speakificated the following: > Laurie Harper wrote: > > Right. However, in all my mails I was exclusively addressing the > supported > functionality. The actual policy is something we should be able to plug > in > as a strategy. It is good though to think about possible policies since > it > defines the required functionality. I agree, the policy is higher level; it's the distinction between policy and available functionality I was tring to draw attention to. > Hmm, not sure whether it helps much to distinguish at this point Warsaw > and Moscow. If you insist, Moscow should define how to install a > concrete policy (as part of a window manager or so) while the > functionality for all this to work has to be defined in Warsaw. Yes, that's what I was getting at. > There is a high level policy (the one discussed above) which for example > determines the keyboard focus vs. pointer event dependance, and there is > the low level issue about input event (pointer) grabs. The reason I make > this distinction is that while the former only influences the user's > interaction with the UI, the latter changes the controller behavior > itself. Yes; the first is just adding semantic meaning to the event processing mechanisms. > No. I think pushing and popping in the event filtering context means a > history stack of controllers holding the grab. If one controller > releases the grab the last which had the grab before will get it again. > This stack has nothing to do with the scene graph. Hmm, yes, makes sense... I was thinking too literally in terms of mouse pointer manipulation, rather than more general cases... > Right, it's an invitation for abuse. I think the problem is the lack of > a distinction between raw and semantic events. While the mapping between > the two should be flexible, there should be no need to emulate event > sending by any receiver. However, I understand the interest: what about > 'accelerators' ? That was the motivation; it allows you to handle 'semantically equivalent' events in one place. The obvious alternative here is an subject/observer mechanism for binding code to events, and allowing a single event handler to observe various events. > the interesting aspect is that when thinking of event propagation and > focus > handling, it is easy to think of mice and keyboards since it has been > done > in every toolkit. Now, if we want to make things more abstract like > allowing > any input devices to have its own focus and its own shared resources > associated > to it, it becomes utterly complex. Yet I think it is at this level that > we > should try to resolve the problems. Well, think more about the VR glove example. Imagine you had a fully immersive UI built around Berlin, and you wanted to use your glove as a 3-space equivalent of the mouse... OK, so give the pointer a 3-space coordinate instead of a screen-space coordinate system, and have it at fixed Z, not too hard... but those sort of abstractions (and much less obvious ones too) need to be designed in early to be effective. > X has different levels of grab. There is a call to 'XGrabPoiner' which > takes parameters to specify the policy of the grab. And there is an > implicit > grab done by the server itself for every button press. An XWindow will > receive all following pointer events untill the button is released. > (button here means mouse button). > > We have to deal with both. Ah, yes; you're using the term 'grab' in a more general way then I tend to think of it. > It is the functionality of Warsaw, which lets Controllers specify how it > *can* > deal with focus. It's not imperative. Controller::acceptsFocus() is a > query > whether the Controller has a meaningful way to deal with focus. And > Focus > objects may request some shared resources to be set. It is the Focus > Manager's > job to implement a policy which then decides whether to acknowledge all > requests > or else how to deal with them. OK, I was too busy thinking focus policy vs. event passing mechanism. This might well be a more sensible API which causes the focus-related event handling to be done by the controller; I had in mind something where a controller would say 'I will do X if I get a mouse-click event' and having a separate mechanism decide whether the controller should actually see some particular click... -- Leave it to the computer programmers | zodiac @ holoweb . net or ^.^ to shorten the "Year 2000 Millennium | laurieh @ groveware . com v Bug" to "Y2K." Isn't that what caused | http://www.groveware.com/ this problem in the first place? | http://www.holoweb.net/~zodiac/ -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Sat Jun 26 06:34:14 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:35 2005 Subject: Surgery Message-ID: <19990626023414Z.graydon@pobox.com> ok, I posted a new snapshot, added in a link to the BTS, posted last IRC meeting's logs in formatted HTML, and rewrote the "people" page to better reflect who's working on what (if you feel I misrepresented you just mail me and I'll change it, no offense intended). by the by, the job of webmaster is (as you no doubt have noticed) not really my favourite and I would be happy as always to hand it off to a competent perl geek with debian authorization and some free time. It's not really too tricky in principle, there's just an increasingly large quantity of stuff there and I have dramatically less free time this summer than I'd expected. It has been a real hope & goal imo to get this thing packaged and out the door with the new drawing & layout protocol and all the fantastic stuff stefan has poured into it, and I'm afraid I'm simply not going to have the time in the next couple weeks to finish up the textKit. it would be time better spent for everyone debugging the package as it stands now rather than holding their breath waiting for the day when I get enough free time to do it. I've taken the remaining superfluous directories from 0.0.1 out of the tree. You need to delete your tree and re-checkout. they're gone. if you really want to see their contents for posterity / porting, you can take a look at todays snapshot, cause the real contents of the directories is no longer in the CVS server at all. dead dead. I vote for a package and release pronto. We've been dicking around too long. "release early & often" isn't being payed its proper heed. this is only our second release in 6 months. We need to get them up around one a month. anyone have things they want to try to "sneak in" to this release before we post it? Aaron: how close are you to getting it to build & run? I think it'd be really cool to have it out there in .deb form by the end of the month, i.e. some time in the next 4-5 days.. is this plausible? -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Sat Jun 26 07:26:02 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: Surgery In-Reply-To: <19990626023414Z.graydon@pobox.com> References: <19990626023414Z.graydon@pobox.com> Message-ID: <3774808A.F814B800@wserv.com> Graydon Hoare wrote: > I vote for a package and release pronto. We've been dicking around too > long. "release early & often" isn't being payed its proper heed. this > is only our second release in 6 months. We need to get them up around > one a month. anyone have things they want to try to "sneak in" to this > release before we post it? Aaron: how close are you to getting it to > build & run? I think it'd be really cool to have it out there in .deb > form by the end of the month, i.e. some time in the next 4-5 days.. is > this plausible? Definately. We should simply make a habit of releasing a version every time we accomplish a goal and everything builds & runs like it should. I've added some documentation to the toplevel README.FIRST on the exact commands needed to bring a Debian system to the point where you can compile the berlin tree sucessfully. I tested them out briefly and I'm fairly sure I got most of the dependancies down. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Sat Jun 26 09:31:02 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:35 2005 Subject: Various Updates: Bugzilla, Install Paths, READMEs, Debs, Etc Message-ID: <37749DD6.E65A9107@wserv.com> Alright, I've updated Bugzilla system to have components listed, so now you can report problems with your favorite components. I've updated the toplevel README.FIRST file and included a fairly complete way to upgrade a Debian Slink or previous Debian distribution to Potato w/ packages you need to install, it may or not be accurate, it would be nice if someone checked :) With the introduction of 0.0.2, I propose we do use the following directory structure (which is as close to FSSTND as possible, I consider Berlin to be an entire different environment just like X and needs it's own directory on /usr): /usr/Berlin/bin - Various binaries /usr/Berlin/include - Headers & IDL source for reuse in other programs /usr/Berlin/include/idl - Where actual IDL's go? /usr/Berlin/lib - The libraries /usr/Berlin/man - Man pages (whenever we get any :) /usr/Berlin/share - Unicode data files, registrar database, fonts, etc /usr/Berlin/doc - What doesn't go into man pages /usr/Berlin/opt - Non-Consortium Berlin files (organization/product/* ?) When we are done we are going to have a lot of data, too much to pollute /usr/ itself and like I said, it is an entirely different environment (which was really the argument for /usr/X11R6/). Now from what I understand, Aaron is doing the deb's right? There are a few things which probably should be done, set the libraries back to libfoo.major.minor.patch and probably build with libtool, add install rules to the makefiles and we might as well import the entire debian/rule|control files in. Now if Aaron isn't doing the debs, I built a few of the debian files required to build debs real quick to see how they worked, but I held off doing any big work. We want to get those debs out the door as soon as possible, the tree builds and runs and is ready for export. Fonts, Graydon mentioned that textkit is in the works. I was browsing freetype and playing around with the library and realized we really don't have any of the basic fonts. Microsoft actually released a few Truetype fonts for free distribution, but I'm really not sure what license they are under. Really we just need Arial/Helvitica, Times New Roman and Courier New initially. If someone can find regular, bold and italic versions in a good license, we should import them in. I killed a few more empty directories, you don't need to clear your trees, just rm -rf them on your side if you get errors or try cvs co -P berlin-tree to prune the empty directories. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mental at kludge.org Sat Jun 26 17:14:10 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:23:35 2005 Subject: Microsoft fonts Message-ID: ISTR Jordy was commenting on the free core fonts from Microsoft... The free fonts are availible here: http://www.microsoft.com/typography/fontpack/default.htm And a copy of the the EULA is availible here: http://www.microsoft.com/typography/fontpack/eula.htm A partial summary of the EULA from their page runs thusly: --- snip --- * Anyone can download and install these fonts for their own use. * Designers can specify the fonts within their Web pages. Our guide to specifying fonts in Web pages explains how to do this. * You can distribute the files from your Web site as long as you complete our Web font registration form. You can only redistribute the fonts in their original form (.exe or .sit.hqx) and with their original file name. * You must not supply the font outlines in any form that adds value to commercial products, such as CD-ROM or disk based multimedia programs, application software or utilities. See Microsoft's permissions site for more details. --- snip --- Anyway, I'm not sure we'd be able to use them. They're really not too friendly towards third-party redistribution. -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Sat Jun 26 18:13:47 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:35 2005 Subject: shared resources and focus: two use cases Message-ID: <3775185B.ECA9E244@magellan.umontreal.ca> Hey all, I'm still puzzled with focus management and I'd like to present you two scenarios which are at least logically quite equivalent. At least so similar that I think of how to design focus management sufficiently abstract to handle both cases: keyboard focus: usually, one associates with keyboard focus the active application on the desktop (or part of it). This means, that some global shared resource (like the menu bar in Mac) should reflect this. How would I do this: * you ask a component to request focus * the controller sends a request for focus to the focus manager (module) with a 'Focus' object encapsulating the desired effects with respect to shared resources so the focus manager can call Focus::install or something to let the Focus set the context as appropriate * either this operation returns a flag to indicate the success of the operation or the focus manager calls the controller back with Controller::enterFocus() or something * Controller can now set the focus flag in it's telltale (subject) so observers get notified and can reflect visually the focus (think of button frames with a black outline when in focus) I hope this all looks not too complicated. I think it's the minimal interaction needed to have sufficient flexibility for the focus manager to implement it's policy and for decoupling of subject/view. Second example: mouse pointer. usually one has the possibility to install a pointer image (Raster) on a per controller basis. How would we implement this ? * when the controller receives it's first mouse event, it means the mouse has just entered the controller * the controller requests mouse focus from the focus manager using a 'Focus' object * when the focus manager installs this Focus, the latter sets the current pointer image * ...continues as above... Well, I think you realize how remarcably similar both interactions look. Is this an inherent similarity ? Does it make sense to reflect it in terms of an abstract approach to Focus management ? What should 'Focus' look like to make the above possible ? First, Controllers don't need a Focus. They could simply use the Focus object of the parent Controller. Indeed, since our scene graph is very fine grained, Controllers are as well. So it's highly probable that a Controller will take the parent's Focus what means that there is no resource installed (we will see how Focus Management can be implemented so that these cases are 'optimized out'. As Focus now corresponds to an input device (every input device has a current focus to be dispatched to the correct Controller), we need something like input device ID which can be used to identify Focus types. Probably this ID should be borrowed from the Event namespace where we need this ID too to correctly associate the Event. Any thoughts along these lines ? Regards, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Sat Jun 26 22:00:52 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:35 2005 Subject: Microsoft fonts In-Reply-To: References: Message-ID: <19990626180052X.graydon@pobox.com> just distribute berlin with a shell script: #!/bin/sh echo echo "Would you like do download the Gratis Microsoft Truetype Fonts" echo -n "(Courier New, Arial, and Times New Roman), implicitly agreeing to the EULA? " read ANS case $ANS in y|Y) echo "downloading fonts"; wget http://fonts.from.microsoft ;; n|N) echo "ok, get your own fonts then!";; esac -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Sat Jun 26 22:39:06 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:36 2005 Subject: Microsoft fonts In-Reply-To: References: <19990626180052X.graydon@pobox.com> Message-ID: <3775568A.8C96E979@wserv.com> Graydon Hoare wrote: > > just distribute berlin with a shell script: > > #!/bin/sh > echo echo "Would you like do download the Gratis Microsoft Truetype Fonts" > echo -n "(Courier New, Arial, and Times New Roman), implicitly agreeing to >the EULA? " > read ANS > case $ANS in > y|Y) echo "downloading fonts"; wget http://fonts.from.microsoft ;; > n|N) echo "ok, get your own fonts then!";; > esac That's one way to do it. I was thinking though, if I were to take a screenshot of the various letters in the fonts as rendered by freetype and then evolved my own font by rendering it in memory, comparing it against the screenshot and having it either live or revert and used that font file, would I own it or would Microsoft? The basic idea is pretty simple: 1. Take a screenshot of a letter rendered at 10-15 sizes using Freetype 2. Start with a very basic font file, a single dot. 3. Slightly modify the font file in some random way 4. Render the modified font and take screenshots of it at the same 10-15 sizes 5. Compare the two screenshots of the original and yours and determine if the font file is better or worse than it was before the mutation. If better, go to step 3, if worse, revert to last known version and go to step 3. And before anyone asks, yes, I do sometimes overthink ways to solve a problem :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Sat Jun 26 23:29:50 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:36 2005 Subject: Microsoft fonts In-Reply-To: <3775568A.8C96E979@wserv.com> References: <3775568A.8C96E979@wserv.com> Message-ID: <19990626192950E.graydon@pobox.com> > That's one way to do it. I was thinking though, if I were to take a >screenshot > of the various letters in the fonts as rendered by freetype and then >evolved my > own font by rendering it in memory, comparing it against the screenshot and > having it either live or revert and used that font file, would I own it or >would > Microsoft? doesn't matter, the quality would suck. you wouldn't be able to print with it, it wouldn't be scalable, it'd have no hinting, and its kerning would be wrong. i.e. it'd be like most freeware fonts :) -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From lar at ruby.cs.byu.edu Sun Jun 27 01:44:48 1999 From: lar at ruby.cs.byu.edu (Laramie Leavitt) Date: Fri Feb 25 22:23:36 2005 Subject: Focus and stuff Message-ID: I was personally wondering about the case where there are 2 instances of a device that we commonly use only one of (today). For example, suppose that the user has 2 monitors and two keyboards (and two mice) and starts berlin to use each monitor. How would the design allow for this scenario? I see the following as possible. 1. User starts two instances of Berlin, and (using a script) explicitly states which device each uses. 2. User starts two instances of Berlin, and (using a script) Berlin automatically determines which device each uses. 3. User starts one instance of Berlin, where both mice are free to move to either display device, and either keyboard can be used as the primary input device. (the user may have to use a script to set up the multiple monitors for the server.) I like the third option, but would like to be able to assign a keyboard to a particlar application. I also like the first option, and think both situations should be designed for. Additionally, each device that provides identical input should have some unique identifier, for the case that a user assigns one of the two keyboards to a particluar device, and uses the other as a roaming keyboard, for example. The design should also be able to use newer input devices. Someone mentioned a 3D glove, why not some 3D pressure sensitive input device (like a wacom tablet, but in 3 dimensions. Maybe something for modeling, imagine a computer sensitive ball of clay..) just a few thoughts. Laramie -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From brent at earthlink.net Sun Jun 27 06:36:52 1999 From: brent at earthlink.net (Brent A. Fulgham) Date: Fri Feb 25 22:23:36 2005 Subject: GGI-Mesa Problems? Message-ID: Has anyone else experienced problems using the GGI-Mesa packages under Debian? I am getting segfaults even when just compiling the mesa sample programs. This is very likely my fault, but I'd like help isolating the cause. Can anyone verify a working system, library level? Thanks, -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Sun Jun 27 21:06:42 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <199906260127.VAA06666@dirk.holoweb.net> References: <199906260127.VAA06666@dirk.holoweb.net> Message-ID: <99062723150300.00854@alcatraz168> On Sat, 26 Jun 1999, Laurie Harper wrote: > Graydon Hoare speakificated the following: > I think our ship might have come in -- IBM releases unicode utility > library under (what looks like, correct me if I'm wrong) a compatible > license. > > http://www.alphaworks.ibm.com/tech/icu/ I hate to bring this license stuff up again... I spoke with the guys from IBM and Debian at saturday at the "linuxtag" here in Kaiserslautern. They both told me that the IBM public License is NOT compatible with the GPL. The debian guys were not even sure that the IPL is free enough for them (although the people I talked to said they didn't know exactly wether the IPL was examined yet). So IMHO we need to come up with our own unicode stuff or find a GPLd unicode lib. The other option we have is changing the berlin license to LGPL. Then we could use the IBM unicode classes. But we can not incorporate the unicode stuff into Prague. Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Mon Jun 28 00:11:40 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <99062723150300.00854@alcatraz168> References: <99062723150300.00854@alcatraz168> <199906260127.VAA06666@dirk.holoweb.net> Message-ID: <3776BDBC.7BC4384@wserv.com> Tobias Hunger wrote: > > I spoke with the guys from IBM and Debian at saturday at the "linuxtag" >here in > Kaiserslautern. They both told me that the IBM public License is NOT >compatible > with the GPL. The debian guys were not even sure that the IPL is free enough > for them (although the people I talked to said they didn't know exactly >wether > the IPL was examined yet). > > So IMHO we need to come up with our own unicode stuff or find a GPLd unicode > lib. > > The other option we have is changing the berlin license to LGPL. Then we >could > use the IBM unicode classes. But we can not incorporate the unicode stuff >into > Prague. Berlin is already under LGPL, the recent arguments were to convert it to GPL. There are very few licenses which are compatible with GPL. BSD, X's artistic license, and LGPL are the only ones I can think of. It is unfortunate that the infectious clause of the GPL wasn't worded more carefully. If RMS would have just insisted that any new code derived from anything based on the GPL would need to be Open Source instead of saying it needed to be GPL, we wouldn't be in this mess. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From alain at mbz.org Mon Jun 28 05:14:54 1999 From: alain at mbz.org (Alain Toussaint) Date: Fri Feb 25 22:23:36 2005 Subject: i'll be moving soon Message-ID: <377704CE.AD617027@mbz.org> Hello Lister's, well,i just wanted to say that i'm moving soon,on the 30 of this month, i'll live with my new Girlfriend and her mother,i predict that in the second week of july at most,i'll be back on the internet,in the meantime,good luck and congratulation with the various advance in berlin. Alain Toussaint -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Mon Jun 28 06:52:49 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <3776BDBC.7BC4384@wserv.com> References: <3776BDBC.7BC4384@wserv.com> Message-ID: <19990628025249E.graydon@pobox.com> > It is unfortunate that the infectious clause of the GPL wasn't worded more > carefully. If RMS would have just insisted that any new code derived from > anything based on the GPL would need to be Open Source instead of saying it > needed to be GPL, we wouldn't be in this mess. You know, there's nothing intrinsically binding us to an LGPL/GPL dichotomy. We're not "in a mess". Anyone who's contributed code to berlin is a copyright owner. When we release, we _choose_ how to release. This means we can choose any sort of license we please, including this one here: This whole product is released as a GPL program, since GPL rules the universe from high atop mount olympus, except we add in the following exceptions to get some nifty features residing in libraries controlled by corporations with laywer problems: 1. You are allowed to link against IBM's unicode lib 2. You are allowed to link against Mozilla's libNSPR 3. You are allowed to link against QT 4. You are allowed to link against Rsaref and for good measure, 5. You are allowed to charge only enough money to recover the costs when you throw cool parties to demo berlin This will not buy it the ability to link with wholly-GPL libraries (say, readline) but it'll assuage any fears people have about some goofball from marketing linking with highly bogus items like a binary-only patented font rasterizer, releasing it to critical acclaim, and marketing it so hard that everyone forgets there's an all-free berlin available. Of course, this sort of behaviour makes us feel all high and mighty, introduces lots of opportunity for future disagreement and bitter private email, and produces yet _another_ obnovious three-letter "public license" which people actually have to read and will invariably make annoying scuffling noises with their feet over while humming and hawing and implying that we're "not good enough to use a real license". I still sorta feel that we'd just be better off with warsaw-as-GPL, everything-else-as-LGPL, and let the marketing bastard duke it out with us at a pub after a developers' conference. On a latter note: does it actually _mean_ anything to release warsaw as GPL vs. LGPL? How do you link with interface definitions? They don't really "compile" in the conventional 1:1 relationship people are used to. If we were to release warsaw "as LGPL", can anyone visualize some terrible future scenario in which somehow our best intrests aren't being looked out for? I don't quite see it.. -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From Esailor9 at southtech.net Mon Jun 28 08:54:09 1999 From: Esailor9 at southtech.net (Evil Sailor 9) Date: Fri Feb 25 22:23:36 2005 Subject: comments from a berlin admirer Message-ID: <37773831.61B76136@southtech.net> I've been perusing the mailing-list archive (nice setup, by the way) for a few days now and I wanted to say two things. First of all, I haven't seen how berlin will acknowledge sound. I *assume* that it will just be another widget that someone eventually hacks up that plugs into berlin/prague and takes over /dev/dsp in the manner of the ESD daemon (in case you dont know, it takes input from other sound programs so you can have multiple sounds at the same time) but I wanted to ask anyways... May be a stupid question, after all, but due to my inexperience with things like this, I can't really tell :-) The other thing was a suggestion: have the TODO list in the CVS maybe? This might not be anything resembling a good idea, but it might be easier for maintainers to add notes about their projects. It could serve to be a left-to-do for each kit/api along with features that could help their kit/api out. I can't figure out CVS, but as far as I can tell, there isnt something like this in any of the source tarballs from the berlin site at the moment. I had e-mailed graydon asking about something mentioned on the TODO list on the website, but it appears they were done ages ago. A little perl script could snag the CVS TODO file and post it to the webpage. I keep hearing you mentioning wanting more developers... A TODO list *could* help. Not to mention people like me telling everyone about "this great new windowing system that some people are developing.. it'll replace X one day..." and they all ahh and ohhh. :-) Oh yeah, have any of you looked at http://www.oreality.com/ yet by any chance? ----.---- .--- .----- ... .. - . evil sailor 9 j.a.p.h -- rogue geek for hire http://www.bionode.com/technoshamen ----.---- .--- .----- ... .. - . -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Mon Jun 28 13:31:16 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <3776BDBC.7BC4384@wserv.com> References: <3776BDBC.7BC4384@wserv.com> Message-ID: <199906281331.JAA18546@hendrix.cs.rit.edu> And lo, the chronicles report that Jordan Mendelson spake thusly unto the masses: > > It is unfortunate that the infectious clause of the GPL wasn't worded more > carefully. If RMS would have just insisted that any new code derived from > anything based on the GPL would need to be Open Source instead of saying it > needed to be GPL, we wouldn't be in this mess. > Why is this unfortunate? If he did what you said above, two problems would exist: one, there is no official definition of Open Source, since the service mark application was dropped and it is clear it will never be registered (and of course, he could say "follows the Debian Free Software Definition" but that was not around before the GPL); second, this would render the GPL completely useless for what it was devised for. If I can take a GPL'd product and "derive" a strikingly similar product (add a few lines of code) and distribute that under a BSD-like license, then I have effectively castrated the copyleft, which was RMS's sole purpose for writing the GPL. I would hate to see Berlin bogged down in license wars as other projects like GGI and Wine are, from time to time. GPL and LGPL themselves are not intrinsically good or bad. They are two (similar) licenses among many open and closed source licenses. I find that typically the critics of the GPL are missing it's true point, and that was not only to distribute free software, but to give authors the power to keep their free software free, to make sure that no proprietary derivatives can be made from their efforts, and to do so in a standard and universal way. If an author or group of authors such as the Berlin Consortium do not wish to utilize this protection and would instead like to work under an X or BSD-like license, then that is their choice. Don't slam the licenses though, and if you want to slam RMS, you can find much better things to get him for ;-) -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Mon Jun 28 13:46:06 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <3776BDBC.7BC4384@wserv.com> References: <99062723150300.00854@alcatraz168> <199906260127.VAA06666@dirk.holoweb.net> <3776BDBC.7BC4384@wserv.com> Message-ID: <37777C9D.527D7462@magellan.umontreal.ca> Jordan Mendelson wrote: > It is unfortunate that the infectious clause of the GPL wasn't worded more > carefully. If RMS would have just insisted that any new code derived from > anything based on the GPL would need to be Open Source instead of saying it > needed to be GPL, we wouldn't be in this mess. I'm sure GPL was worded *very* carefully and conscious. On the contrary, what does 'Open Source' mean, after all. It's a buzzword which is now very much 'en vogue' but has it a clear definition like 'free software' as used and propagated by FSF. So, no, I think we would be in a mess if the wording were '...has to be Open Source'. Requiring GPL for derivates might be not convenient for a couple of people (or even a lot) but its definitely very clear if one sticks to the definition. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Mon Jun 28 13:49:18 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <19990628025249E.graydon@pobox.com> References: <19990628025249E.graydon@pobox.com> <3776BDBC.7BC4384@wserv.com> Message-ID: <37777D5E.241B6B0E@magellan.umontreal.ca> Graydon Hoare wrote: > On a latter note: does it actually _mean_ anything to release warsaw > as GPL vs. LGPL? How do you link with interface definitions? They > don't really "compile" in the conventional 1:1 relationship people are > used to. If we were to release warsaw "as LGPL", can anyone visualize > some terrible future scenario in which somehow our best intrests > aren't being looked out for? I don't quite see it.. I'm discussing this very topic with RMS these days. How does (L)GPL apply in the context of protocol based (weak) linking like CORBA. I'll let you know if I have some news... Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Mon Jun 28 14:26:18 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <199906231918.PAA15913@delysid.gnu.org> References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <199906272257.QAA26241@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> Message-ID: <3777860A.34B4800B@magellan.umontreal.ca> Richard Stallman wrote: > > I now remember having heard about the Berlin project before. From > what I could gather, it seemed that a fundamental design goal was to > make it more convenient to dynamically select non-free drivers for the > display hardware. No. We use libGGI underneath. I have very little information about how they interact with hardware/drivers. If ever selecting non-free drivers was an issue, then in the GGI project. > If that is indeed the goal, I think it is a fundamentally misguided > goal. It would encourage people to use non-free drivers while hardly > even thinking about what they are doing. That is exactly the opposite > of what we need to do. Right now, a person who installs a non-free X > server is at least likely realize that that is a step away from > freedom. I agree. > Do you think I have misunderstood something about this? Berlin is not really dealing with drivers. The hardware abstraction is done in a lower level. We use another abstraction for drawing: a DrawingKit encapsulates the functionality to draw the scene graph. One DrawingKit does so using openGL to draw to the screen, another uses PostScript to get a printed dump of what you see on the screen etc. > Anyway, on to other issues: > > Ok, the Berlin Project is aiming at a new display server which includes > the functionality of X > > Would this be a replacement for the X server, then? Or would it work > with the X server? In this message, I will assume it replaces the X > server. > > . That is, relying on libGGI/Mesa as the graphic > 'driver', we are building a protocol (CORBA based) > > Would this protocol replace the X protocol? If so, what would be done > about all the many programs that have been written to link with Xlib > and Xt? Would there be modified versions of Xlib and Xt to speak the > new protocol? That is indeed an important issue. Since there is at least one X server using GGI we hope to be able to merge it into Berlin to let both type of programs coexist. Yet our design is so radically different that at this point I think there is not much use of designing in 'X compatibility mode'. I agree that we will have to address this whole point. It will be strategically very important. > Below, I will assume that this protocol would replace the X protocol. > > The idea is really to make the server very modular, i.e. to have > modules for the different tasks (we call them kits) such as TextKit, > FigureKit, LayoutKit, ImageKit etc. which are plugged in only when > clients request it. > > >From just a list of names, I can't guess what sorts of jobs > these kits would do. Could you give me some more explanation? > > If there is a fixed set of available kits, why not have them linked > together? They won't have to get swapped in to real memory if they > are not needed. What advantage is there in making this dynamic? I > don't see it. Hmm, you might want to use the server on a low level machine and run a client working in (extended) text mode like vi or something. Why use the display server at all, you might ask. Our TextKit is designed to handle international fonts/unicode so if arabic or japanese people want to edit text, they will be able to do it. So the server will be extremely scalable and extensible. You might even install in your setup just the kits you need. The second reason is interface/implementation separation. From the CORBA definition everyone knows what a WidgetKit is supposed to do, but how it does that is completely hidden. So we could have different WidgetKits installed which are loaded depending on style settings etc. Same for all the other kits. TextKit might be parametrized in terms of local settings (a TextKit for arabic, one for latin fonts, one for kanji...) And you load only the ones you need (your application needs.) Here is a little summary about what the kits do: LayoutKit: defines layout managers of all sorts (hbox, grid, overlay etc.) WidgetKit: defines all sorts of widgets ImageKit: knows how to read/write various image formats and load them into the internal format (which happens to be PNG) FigureKit: graphic primitives for structured graphics (lines, polygons, splines, images etc.) TextKit: text management, glyphs, layout of text (all abstract to support international text) ... > The question we had was how a license such as GPL reflects these > different layers of possible relationship or interface/implementation > reuse. How could we protect the protocol(s) from being 'extended' > the way Microsoft interprets that term apparently. > > I am not sure what you mean by "extended" in scare quotes, > so I don't understand the question. > > When a program is free software, people are always free to > make modified and extended versions of it. So Microsoft > would be free to extend this protocol. There is no way you > can stop them, or anyone, from doing so. > > What you could perhaps do is to use the GPL to require > extended versions *of you software* to be free. Then if > Microsoft did make an extended version, and they based it on > your software rather than writing a completely new version, > they would have to release the source for it. Thus, their > changes would be available to you and the community. They could > not make secret extensions. That's exactly the point I tried to get at. I don't want to prevent the evolution of the project at all. But I want to make sure that no-one introduces hidden incompatibilities. So I want to make sure the protocol is really transparent to the whole community. My point is that you can always add new protocols (interfaces) and these can be written in any license (they are not linked against the rest, at least not in the traditional terms of the word link (may be we should distinguish strong and weak links much as in mathematics these terms are used (strong/weak convergence, norm etc.) > However, the use of CORBA for communication alters the effect > of the GPL, as you guessed it might. Exactly. That's what I was aiming at. > Basically, if you publish a module with a clearly defined > CORBA interface, it would be hard to argue a program > which invokes that module is an extension of your module. > I think it would be considered a separate program. > > That means that even if your module is released under the GPL, > non-free programs could invoke it with CORBA. > > Is that a good thing? Not necessarily. > > It seems to me that non-free applications ought to be able > to do their display with Berlin. Non-free apps can be linked > with Xlib now, and I think that strategically it would be a mistake > to try to forbid the same kind of usage for Berlin. Ok, so GPL for the protocols and LGPL for the libraries ? > However, extensions and drivers for the server are another matter > entirely. It would be a mistake to permit non-free extensions and > drivers. So I think we should look for a way to prohibit them. That > is to say, we should look for a design which is such that the > consequence of using the GPL would be to prohibit such non-free > extensions and drivers. Agree entierly and as I said above, this is not really an issue in the Berlin project. The parts which are from Berlin's point of view the drivers (GGI, Mesa, omniORB) are all free and we don't plan to change that. Thank's a lot, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Mon Jun 28 14:43:07 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:36 2005 Subject: Various Updates: Bugzilla, Install Paths, READMEs, Debs, Etc In-Reply-To: <37749DD6.E65A9107@wserv.com> References: <37749DD6.E65A9107@wserv.com> Message-ID: <377789FB.508775F0@magellan.umontreal.ca> Jordan Mendelson wrote: > > Alright, I've updated Bugzilla system to have components listed, so now you >can > report problems with your favorite components. > > I've updated the toplevel README.FIRST file and included a fairly complete >way > to upgrade a Debian Slink or previous Debian distribution to Potato w/ >packages > you need to install, it may or not be accurate, it would be nice if someone > checked :) > > With the introduction of 0.0.2, I propose we do use the following directory > structure (which is as close to FSSTND as possible, I consider Berlin to be >an > entire different environment just like X and needs it's own directory on >/usr): [...] Knowing that this topic already get lots of attraction (heated debate) I'd like to propose that we postpone this issue. Since we have nothing to install (it's all about development) there is no point to have a 'make install' target at all I think. I'm not sure how the Debian policy treats this kind of stuff but I think we have other things to do right now than worrying about how we integrate Berlin into the standard file system. By the way, same goes for fonts. Since this release doesn't include a working TextKit, why worrying other developers/visitors with suggestions like downloading TT fonts from Microsoft ? I guess this would upset people more than we would like and I already hear stupid questions like 'do I need to install Windows to be able to run Berlin ?'. > Now from what I understand, Aaron is doing the deb's right? There are a few > things which probably should be done, set the libraries back to > libfoo.major.minor.patch and probably build with libtool, add install rules >to > the makefiles and we might as well import the entire debian/rule|control >files > in. May be Aaron could give us a little lesson about the Debian rules. What is a package required to have/can to be distributable with Debian ? I don't really like the idea to use the libtool. Is this really necessary ? We require the system to be able to handle dynamic linking anyway, so what is libtool good for, then ? > Fonts, Graydon mentioned that textkit is in the works. I was browsing >freetype > and playing around with the library and realized we really don't have any >of the > basic fonts. Microsoft actually released a few Truetype fonts for free > distribution, but I'm really not sure what license they are under. Really we > just need Arial/Helvitica, Times New Roman and Courier New initially. If >someone > can find regular, bold and italic versions in a good license, we should >import > them in. See above. Final question: whom to contact ? How should we announce a new version ? I'd propose to mail to * linux and X related newsgroups (may be asking RMS for announcing via gnu.announce) * mailing list such as Fresco (eventually GNOME, KDE to get nice flame wars in :) * freshmeat/slashdot Regards, Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Mon Jun 28 17:12:24 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:36 2005 Subject: Unistring & Unicode? In-Reply-To: <37777D5E.241B6B0E@magellan.umontreal.ca> References: <37777D5E.241B6B0E@magellan.umontreal.ca> Message-ID: <19990628131224B.graydon@pobox.com> > I'm discussing this very topic with RMS these days. How does (L)GPL > apply in the context of protocol based (weak) linking like CORBA. > I'll let you know if I have some news... It's funny, I spent some of last summer talking to him about this and he wasn't really aware of what corba was at that point or how it could be defined legally, but I _bet_ after a year of heavy corbafication in gnome and KDE that this discussion has finally worked its way into a feasable, decidable state.. -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Mon Jun 28 23:19:44 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:36 2005 Subject: Various Updates: Bugzilla, Install Paths, READMEs, Debs, Etc Message-ID: <21D757CECBD2D211AD5D00105A2974A7392F12@EXCHANGE> > > May be Aaron could give us a little lesson about the Debian > rules. What is > a package required to have/can to be distributable with Debian ? The best source of info on Debian is the various Debian packaging and developer guides at http://www.debian.org (see the developer's corner). In a nutshell, anything licensed as GPL/LGPL/Artistic/BSD/X and a few others are considered "Free" and may be released by Debian in the "main" distribution. Non-free indicates items that have licensing or redistribution restrictions that do not allow it to be freely used. Obviously, things like Netscape go here. However, our very own OmniORB (which is a quite-free product) must go in non-free because it has license restrictions that prevent a user from breaking compatibility with CORBA. So, not everything in "non-free" is proprietary closed stuff. Contrib holds everything in-between. There are no requirements as far as tools used to build the packages, etc. Obviously it must be built using the version of the C libraries, libstdc++, etc., available under Debian. There are some requirements about where things must go IF they are going into the /usr or / file heirarchy. We could always wimp out and just put things in /opt :) > I don't really like the idea to use the libtool. Is this > really necessary ? The other concern I have about libtool is that the documentation on its website (see http://www.gnu.org) indicates that the author does not consider it safe to use for C++ yet. Perhaps this is out of date, but it certainly surprised me! > Final question: > > whom to contact ? How should we announce a new version ? I'd > propose to mail to > > * linux and X related newsgroups (may be asking RMS for > announcing via gnu.announce) > * mailing list such as Fresco (eventually GNOME, KDE to get > nice flame wars in :) > * freshmeat/slashdot > Those look good to me.... -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Mon Jun 28 23:26:26 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:36 2005 Subject: Bad E-mail Address. Bad. Bad Bad. Message-ID: <21D757CECBD2D211AD5D00105A2974A7392F1A@EXCHANGE> In case the lot of you haven't noticed, I apparently can't find my backside with both hands and have sent mail from home using a malformed return address. Note: This applies to Graydon and Stefan, and possibly anyone commenting on my OpenGL problems. If you have mail to me sitting on your system with unexplained "unable to deliver" errors, and the like, it is because my MTA was popping my local user name into my return mail header. Please replace: brent@earthlink.net with: bafulgham@earthlink.net. This will resolve any such problems. For my part, all mail will now go through Emacs, so I will have properly formed return address headers come hell or high water. Apologies for any inconvenience. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mental at kludge.org Tue Jun 29 00:30:40 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:23:36 2005 Subject: comments from a berlin admirer In-Reply-To: <37773831.61B76136@southtech.net> References: <37773831.61B76136@southtech.net> Message-ID: On Mon, 28 Jun 1999, Evil Sailor 9 wrote: > I've been perusing the mailing-list archive (nice setup, by the way) for > a few days now and I wanted to say two things. First of all, I haven't > seen how berlin will acknowledge sound. I *assume* that it will just be > another widget that someone eventually hacks up that plugs into > berlin/prague and takes over /dev/dsp in the manner of the ESD daemon > (in case you dont know, it takes input from other sound programs so you > can have multiple sounds at the same time) but I wanted to ask > anyways... May be a stupid question, after all, but due to my > inexperience with things like this, I can't really tell :-) Hmm... I proposed a (skeletal) design for an audio system that was more or less a realtime block-and-wire-dataflow signal processing deal, that as much as possible threw around tokens with transformation lists instead of copying/processing data chunks directly (i.e. actual signal processing is deferred until the last possible moment so more optimization decisions can be made). We knocked the idea back and forth a little, and then I went off to the GGI folks with the idea, and it kind of languished since then. You might be able to find my posts on the matter in the archives, but it was some time ago now (a year? more than a year?). I'm not sure how far back the archives go... Berlin certainly wasn't mature enough at the time to really pursue it then anyway; I dunno if it is yet now or not. -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From rms at gnu.org Tue Jun 29 03:22:29 1999 From: rms at gnu.org (Richard Stallman) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <3777860A.34B4800B@magellan.umontreal.ca> References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> Message-ID: <199906290322.VAA28604@wijiji.santafe.edu> That is indeed an important issue. Since there is at least one X server using GGI we hope to be able to merge it into Berlin to let both type of programs coexist. Yet our design is so radically different that at this point I think there is not much use of designing in 'X compatibility mode'. I agree that we will have to address this whole point. It will be strategically very important. Berlin MUST coexist with X, or I think few people would run it. I wouldn't. GNU programs normally display using X, and it would take very strong arguments to convince me to tell all the GNU maintainers "Convert your programs to use Berlin instead of X." Many other programs also display using X, and you can't expect them all to be changed. I think very few people would run Berlin if it means that those programs stop running. Our TextKit is designed to handle international fonts/unicode so if arabic or japanese people want to edit text, they will be able to do it. Alas, this is rather vague; I don't understand it at all. People display Arabic and Japanese using X already. > It seems to me that non-free applications ought to be able > to do their display with Berlin. Non-free apps can be linked > with Xlib now, and I think that strategically it would be a mistake > to try to forbid the same kind of usage for Berlin. Ok, so GPL for the protocols and LGPL for the libraries ? I don't know whether I agree, because I am not sure what this means. A protocol is a mathematical abstraction--it doesn't have a copyright, so it can't have a license. Only a *program* can have a license. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 29 03:46:32 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <199906231918.PAA15913@delysid.gnu.org> References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <199906290322.VAA28604@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> Message-ID: <37784198.F1370C3C@magellan.umontreal.ca> Richard Stallman wrote: > Ok, so GPL for the protocols and LGPL for the libraries ? > > I don't know whether I agree, because I am not sure what this means. > A protocol is a mathematical abstraction--it doesn't have a copyright, > so it can't have a license. Only a *program* can have a license. I wish you were right. However, aren't algorithms patented in the US ? (I'm not in the US but the programs will be distributed there too). What is the difference between an algorithm (see for example GIF) and a protocol (at least legaly) ? Isn't a protocol a definition of an algorithm ? (in case of IDL headers it's even something in between an algorithm and a program since it consists of code which is transformed eventually into a program in terms of translators and compilers. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jwb at cp.net Tue Jun 29 03:54:01 1999 From: jwb at cp.net (Jeffrey W. Baker) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <199906231918.PAA15913@delysid.gnu.org> References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <199906290322.VAA28604@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> Message-ID: <37784359.A13DC0B6@cp.net> Richard Stallman wrote: > > That is indeed an important issue. Since there is at least one X server > using GGI we hope to be able to merge it into Berlin to let both type > of programs coexist. Yet our design is so radically different that at > this point I think there is not much use of designing in 'X >compatibility > mode'. I agree that we will have to address this whole point. It will be > strategically very important. > > Berlin MUST coexist with X, or I think few people would run it. I > wouldn't. > > GNU programs normally display using X, and it would take very strong > arguments to convince me to tell all the GNU maintainers "Convert your > programs to use Berlin instead of X." Many other programs also > display using X, and you can't expect them all to be changed. > > I think very few people would run Berlin if it means that those > programs stop running. I wholeheartedly disagree. Berlin will (or won't) stand on its own merits. The burden of X compatibility would be a cumbersome graft onto the face of a very beautiful and innovative design. Backward compatibility does not make sense across two systems with very different architectures. I also do not accept that X is important to the every day functionality of most computers. A lot of very useful software has been written using the [Less|Mo]tif, GTK and QT packages. These programs should not and would not be aware if they were being displayed on a Win32 or MacOS machine, if the toolkit had been ported. Porting the GTK or any of the other toolkits to Berlin would bring much software with it. Finally, X and Berlin can cooperate without having to be compatible. Because Berlin use GGI, and GGI can be displayed in X, a user could run his Berlin applications and his X applications simultaneously on the same X display. In the other direction, the X server can be made to display to a GGI target, so a user could run X applications on the same GGI target as his Berlin applications. But any more than this frame-buffer-level cooperation would be difficult and silly. > Our TextKit is designed to > handle international fonts/unicode so if arabic or japanese people > want to edit text, they will be able to do it. > > Alas, this is rather vague; I don't understand it at all. People > display Arabic and Japanese using X already. > > > It seems to me that non-free applications ought to be able > > to do their display with Berlin. Non-free apps can be linked > > with Xlib now, and I think that strategically it would be a mistake > > to try to forbid the same kind of usage for Berlin. > > Ok, so GPL for the protocols and LGPL for the libraries ? > > I don't know whether I agree, because I am not sure what this means. > A protocol is a mathematical abstraction--it doesn't have a copyright, > so it can't have a license. Only a *program* can have a license. Yes I agree with RMS here. Publish the protocol and if people want to use it for whatever reason then they can. The wonderful thing about open protocols is they allow people to use your system in ways that would not occur to you. Cheers, Jeffrey -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Tue Jun 29 05:12:51 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <199906290322.VAA28604@wijiji.santafe.edu> References: <199906290322.VAA28604@wijiji.santafe.edu> Message-ID: <19990629011251K.graydon@pobox.com> I hope you don't take offense to my replying, I don't know how private a conversation this is (it's being forwarded to our list :) but I thought I'd comment on a couple technical items, as I'm not really too good with legal implications. > Berlin MUST coexist with X, or I think few people would run it. I > wouldn't. coexistence and complete interoperability are different things. pine and MH coexist, but since their mail box models are so different they are not interoperable. installing berlin does not mean uninstalling X, nor does it mean uninstalling or even ceasing to use X programs. we develop berlin in X, using a wrapper which runs berlin in an X visual. Some day we will have a wrapper which puts X in a berlin visual, and then a wrapper which puts individual X visuals in individual berlin visuals (window : window interoperability). then we will gradually build bridges down to the popular X widget toolkits such that they too can interoperate. This has always been the plan, but as I'm sure you understand the person-power to accomplish it is not readily available "near the beginning" of such a large project. So we had to make a decision: given that it is technically possible, should we "dilute" our technology to make bridging easier (say by making X protocol the default, making the drawing model work in pixel-units, making the font format the PCF format, etc.) or should we attempt to "enter new territory" and make an experimental server which has all the features we want, and hope that enthusiasm for those features is high enough to encourage people to write wrappers and bridges to save themselves the hassle of switching between X and Berlin consoles? Obviously we chose the latter. If you want an enhanced X server, berlin is not it. It's not completely novel code, much of it has a long history of R&D in the C++ community, it just happens to be the program we wanted to write. > > Our TextKit is designed to > handle international fonts/unicode so if arabic or japanese people > want to edit text, they will be able to do it. > > Alas, this is rather vague; I don't understand it at all. People > display Arabic and Japanese using X already. they do, but with decidedly suboptimal features. Even english, an amazingly rectangular-character-oriented language, is not well supported by the X font and text rendering model. the fact that all X users are used to it is sad, because there is a lot better typography available, not just to those willing to use "poorly licensed" proprietary work. X simply has _bad_ typographic technology. The problems are many: * X text is non-antialiased, and has no support for subpixel spacing. * X has no way of accessing font metrics, which means that you cannot tell how large a glyph is supposed to be without rendering it to pixel units and measuring it. aside from being silly, this is a problem if the font is small because the font hinting mechanism will have kicked in on a 72DPI monitor and the metrics will be different than those the font will use when printing at the same size on a 600DPI printer. This makes getting the number of glyphs that fit on a line of text right ("what you see is what you get" layout) almost impossible without bypassing the X text system. * X text does not support ligatures. you can fake real ligatures by having a bunch of ligature "quasi-glyphs" in the font, and if the application or toolkit happens to know the index numbers of these glyphs it might be able to get by (for instance, the 4 forms of arabit are widely known enough that it is plausible). In any event it makes it impossible for a clever font vendor to add features to the font (such as opentype layout tables) without at least writing a font server, possibly having to interact with all the toolkit authors. * X text does not support kerning pairs. This is the feature which adjusts the inter-glyph spacing between a capital T and a lowercase e such that the e "tucks under" the lip of the T. It's used in most fonts. * X text is strongly connected to the Character = Glyph assumption, which has proven a problem in international text processing. If you consider the script Devenagri, used to write over 25 languages, the issue becomes clear: as you enter syllables, the glyphs change appearance dramatically from one composite to the next. The classical X response to this is the same as the response to Chinese: write a special input server which converts sequences of codes in the source language to correct "character" codes in the target language, and send those codes to the X font server. This approach is almost passable in chinese since the glyphs, once formed, can not interactively be "decomposed" again. if they are interactively deleted, they are deleted as a whole. In Devenagri, it is realistic to place a cursor in the middle of a word partly filled with composite glyphs and press the backspace key. This alters the context of the surrounding glyphs, and their forms must change. In order to do this in X, the client library must maintain a special bidirectional mapping between character codes which came from the Devenagri server and glyphs in the X server, and when there is a change the client library must back up to a word boundary, erase all the glyphs on the visual and re-render them via the Devenagri server. This is a lot of supporting machinery for a supposedly international text model. We are hoping to express APIs which address most of these issues in our display protocol, and permit font developers to make good use of them. Good text makes a lot of difference, visually. -graydon -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From anoq at HardcoreProcessing.com Tue Jun 29 10:20:18 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:23:36 2005 Subject: Flick, IDL and omniORB... In-Reply-To: <199906251332.OAA24973@pineapple.cam-orl.co.uk> References: <199906251332.OAA24973@pineapple.cam-orl.co.uk> Message-ID: <37789DE2.7F217874@HardcoreProcessing.com> Duncan Grisby wrote: > Work is currently underway on a new IDL compiler, although it's likely > to be quite a while before it's done. There would be very little to > gain by creating a Flick back-end for omniORB, since Flick's main > selling point is that it produces "highly optimised" stubs. omniORB > already does almost all [1] of its optimisations, as well as a few > more. > ... One of my friends (firefly@diku.dk) is investigating Flick. According to his research there should be more advantages to using Flick than just performance: It has a very modular architecture, allows for different IDL-languages (OSF, OMG etc.), allows for different message encoding formats and easier interoperability between multiple ORBs. Using Flick should minimize the effort needed to maintain all these features... So maybe it would still be a good choice for omniORB? Cheers -- http://www.HardcoreProcessing.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From dgrisby at uk.research.att.com Tue Jun 29 13:00:31 1999 From: dgrisby at uk.research.att.com (Duncan Grisby) Date: Fri Feb 25 22:23:36 2005 Subject: Flick, IDL and omniORB... In-Reply-To: <37789DE2.7F217874@HardcoreProcessing.com> References: <37789DE2.7F217874@HardcoreProcessing.com> Message-ID: <199906291300.OAA00980@pineapple.cam-orl.co.uk> On Tuesday 29 June, ANOQ of the Sun wrote: > One of my friends (firefly@diku.dk) is investigating Flick. > According to his research there should be more advantages > to using Flick than just performance: > > It has a very modular architecture, allows for different > IDL-languages (OSF, OMG etc.), allows for different > message encoding formats and easier interoperability > between multiple ORBs. Using Flick should minimize > the effort needed to maintain all these features... I don't quite understand why these things are good for a CORBA ORB. They certainly make good research, but CORBA has a single IDL (which is an ISO standard), and a single required message encoding format. I don't know what you mean by `easier interoperability' -- interoperability is the whole point of the CORBA standard. Are you suggesting that all ORBs should use Flick? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Tue Jun 29 13:48:38 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application In-Reply-To: <19990629011251K.graydon@pobox.com> References: <19990629011251K.graydon@pobox.com> Message-ID: <199906291348.JAA19287@hendrix.cs.rit.edu> And lo, the chronicles report that Graydon Hoare spake thusly unto the masses: > > I hope you don't take offense to my replying, I don't know how private > a conversation this is (it's being forwarded to our list :) but I > thought I'd comment on a couple technical items, as I'm not really too > good with legal implications. > > > Berlin MUST coexist with X, or I think few people would run it. I > > wouldn't. > > coexistence and complete interoperability are different things. pine > and MH coexist, but since their mail box models are so different they > are not interoperable. installing berlin does not mean uninstalling X, > nor does it mean uninstalling or even ceasing to use X programs. we > develop berlin in X, using a wrapper which runs berlin in an X > visual. Some day we will have a wrapper which puts X in a berlin > visual, and then a wrapper which puts individual X visuals in > individual berlin visuals (window : window interoperability). then we > will gradually build bridges down to the popular X widget toolkits > such that they too can interoperate. This has always been the plan, > but as I'm sure you understand the person-power to accomplish it is > not readily available "near the beginning" of such a large project. So > we had to make a decision: given that it is technically possible, > should we "dilute" our technology to make bridging easier (say by > making X protocol the default, making the drawing model work in > pixel-units, making the font format the PCF format, etc.) or should we > attempt to "enter new territory" and make an experimental server which > has all the features we want, and hope that enthusiasm for those > features is high enough to encourage people to write wrappers and > bridges to save themselves the hassle of switching between X and > Berlin consoles? Obviously we chose the latter. I agree. However I also agree that if Berlin releases without being able to display an xterm and a netscape window, it will fail (at least, it will fail in the sense that hardly anyone will use it as their primary windowing system; it may be relegated to a GGI->X window on a few folks machines). At this point, I don't think Berlin developers should worry about X. Once Berlin itself is functional and stabilizing, I think it is definately worth "grafting" X on somehow, if only by providing a Berlin target for GGI and having X servers in windows. I would think of it as the leap from Windows 3.1 to Windows NT; many 3.1 apps may work in NT, but not nearly as well as native NT apps. X on Berlin would provide the transitional buffer to allow folks to use their favorite X apps until a suitable Berlin-based replacement is available. > If you want an > enhanced X server, berlin is not it. It's not completely novel code, > much of it has a long history of R&D in the C++ community, it just > happens to be the program we wanted to write. And I think it is a good idea. Other organizations (XFree, TOG) can work on trying to extend X's life. Berlin should be something diffferent. In the end, users can judge if it is worth keeping with the tried and true but out of date X or take the risk of jumping to something completely new. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Tue Jun 29 13:52:11 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:36 2005 Subject: comments from a berlin admirer In-Reply-To: References: Message-ID: <199906291352.JAA19316@hendrix.cs.rit.edu> It seems to me that Berlin should take a higher-level approach to sound, just as it has to video. Berlin depends on GGI for video (and presumably is extensible enough to depend on another driver set if needs be), so why not define an abstraction layer for third-party sound drivers such as ALSA, OSS or even ESD? And lo, the chronicles report that MenTaLguY spake thusly unto the masses: > > On Mon, 28 Jun 1999, Evil Sailor 9 wrote: > > > I've been perusing the mailing-list archive (nice setup, by the way) for > > a few days now and I wanted to say two things. First of all, I haven't > > seen how berlin will acknowledge sound. I *assume* that it will just be > > another widget that someone eventually hacks up that plugs into > > berlin/prague and takes over /dev/dsp in the manner of the ESD daemon > > (in case you dont know, it takes input from other sound programs so you > > can have multiple sounds at the same time) but I wanted to ask > > anyways... May be a stupid question, after all, but due to my > > inexperience with things like this, I can't really tell :-) > > Hmm... I proposed a (skeletal) design for an audio system that was more or > less a realtime block-and-wire-dataflow signal processing deal, that as much > as possible threw around tokens with transformation lists instead of > copying/processing data chunks directly (i.e. actual signal processing is > deferred until the last possible moment so more optimization decisions can > be made). We knocked the idea back and forth a little, and then I went off > to the GGI folks with the idea, and it kind of languished since then. > > You might be able to find my posts on the matter in the archives, but it was > some time ago now (a year? more than a year?). I'm not sure how far back > the archives go... Berlin certainly wasn't mature enough at the time to > really pursue it then anyway; I dunno if it is yet now or not. > > -=MenTaLguY=- > > ----------------------------------------- > mental@kludge.org > ----------------------------------------- > FOR COMMENT CHANNELS ONLY > > > -- > To UNSUBSCRIBE, email to design-request@berlin-consortium.org > with a subject of "unsubscribe". Trouble? Contact >listmaster@berlin-consortium.org > -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Tue Jun 29 14:01:50 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:36 2005 Subject: Flick, IDL and omniORB... Message-ID: <199906291401.KAA19360@hendrix.cs.rit.edu> And lo, the chronicles report that ANOQ of the Sun spake thusly unto the masses: > > Duncan Grisby wrote: > > Work is currently underway on a new IDL compiler, although it's likely > > to be quite a while before it's done. There would be very little to > > gain by creating a Flick back-end for omniORB, since Flick's main > > selling point is that it produces "highly optimised" stubs. omniORB > > already does almost all [1] of its optimisations, as well as a few > > more. > > ... > I don't know anything about Flick. But if you're looking for a new IDL compiler, what about ORBit? I know it doesn't have C++ binding at this time (at least I don't think it does), but it'd probably be easier to add C++ support to ORBit than to write a completely new ORB/IDL compiler. I don't know how ORBit compares to omniORB in terms of performance, but ORBit is supposed to be rather fast and lightweight, and seems to be maturing rather well (and rather quickly). Ideally, IMO, Berlin would be completely ORB-neutral and the user (or package builder) could determine the best ORB for the job, assuming the ORB they choose meets the requirements of Berlin (C++ bindings, whatever latest whiz-bang features like DII which might be used, etc) at build time. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From anoq at HardcoreProcessing.com Tue Jun 29 15:23:21 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:23:36 2005 Subject: Flick, IDL and omniORB... In-Reply-To: <199906291300.OAA00980@pineapple.cam-orl.co.uk> References: <199906291300.OAA00980@pineapple.cam-orl.co.uk> Message-ID: <3778E4E9.7CD508@HardcoreProcessing.com> Duncan Grisby wrote: > I don't quite understand why these things are good for a CORBA ORB. > They certainly make good research, but CORBA has a single IDL (which > is an ISO standard), and a single required message encoding format. I > don't know what you mean by `easier interoperability' -- > interoperability is the whole point of the CORBA standard. Are you > suggesting that all ORBs should use Flick? OK - easier interoperability between COM/DCOM/ActiveX/DCE/CORBA etc. then :) Also, communication between certain types of programming languages might benefit from a different encoding format in places where interoperability is not needed (in-process method invocations?). And finally I believe that supporting other programming languages than just C/C++ might be easier with Flick. I don't know if all ORBs should use Flick though, since competition is always a good thing... :) Anyways - it was just a comment/suggestion... Cheers -- http://www.HardcoreProcessing.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Tue Jun 29 16:03:24 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:36 2005 Subject: (L)GPL and its application Message-ID: <21D757CECBD2D211AD5D00105A2974A7397B7A@EXCHANGE> > I agree. However I also agree that if Berlin releases without > being able > to display an xterm and a netscape window, it will fail (at > least, it will > fail in the sense that hardly anyone will use it as their > primary windowing > system; it may be relegated to a GGI->X window on a few folks > machines). I think in the short term our only concern should be creating a decent text widget that can act like a standard Xterm. Once we have this, we can make use of a huge amount of software written for text mode. This includes Emacs, various mail readers, etc., etc. Many X apps are written as wrappers around an underlying engine (the so-called client-server architecture) which should be relatively easy to re-implement as true Berlin apps. Of course, using Berlin's messaging and other features will likely require complete re-writes of many apps. My point is that we can harness much of the Free Software communities products without necessarily implementing an X compatibility layer. This can come later. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Tue Jun 29 16:08:26 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:37 2005 Subject: Flick, IDL and omniORB... Message-ID: <21D757CECBD2D211AD5D00105A2974A7397B83@EXCHANGE> > > I don't know anything about Flick. But if you're looking for a new IDL > compiler, what about ORBit? I know it doesn't have C++ > binding at this time > (at least I don't think it does), but it'd probably be easier > to add C++ > support to ORBit than to write a completely new ORB/IDL > compiler. I don't > know how ORBit compares to omniORB in terms of performance, > but ORBit is > supposed to be rather fast and lightweight, and seems to be > maturing rather > well (and rather quickly). > OmniORB has the best performance of any ORB we've evaluated. Frankly, there are not many problems with the functionality of the IDL compiler we already have with OmniORB. Duncan alludes to some messy internals (which we thankfully don't have to deal with), but my only complaint with the system was over admittedly esoteric licensing issues. > Ideally, IMO, Berlin would be completely ORB-neutral and the user (or > package builder) could determine the best ORB for the job, > assuming the > ORB they choose meets the requirements of Berlin (C++ > bindings, whatever > latest whiz-bang features like DII which might be used, etc) > at build time. > By definition the system is already ORB-neutral. Berlin running with OmniORB will be compatible with objects bound to other ORBs on other machines (or the same machine) written in the same or different languages.... Of course, we have to configure our build to work with the specific output produced by our IDL compiler (in terms of what kinds of files are created, their names for including in our own source code, the specific libraries to use, etc.) -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Tue Jun 29 18:27:15 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <37749DD6.E65A9107@wserv.com> References: <37749DD6.E65A9107@wserv.com> Message-ID: <99062920352800.04430@alcatraz168> Hello! I was asked today why berlin will use a registry and, to be frank, I couldn't answer this question. So why are we using a registry? It can't be grepped, you need special programs to view it, and that it allows for faster access is (at least in normal programs) not so essential since you read the configuration just once anyway. >From what I see in the Windows registry it is even more caotic then a bunch >of files in /etc (but that could be my own ignorance, I hardly ever use windows). And files are much easier to delete then registry keys. So what are the advantages of a registry? Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 18:58:02 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs Message-ID: <3779173A.A703877D@wserv.com> Alright, I couldn't get in touch with Aaron (no one ever emails me back any more), so I decided just to use my debhelper rules and commit them to CVS. You can download them directly from: http://jordy.wserv.com/berlin/debian Or you can rebuild them yourself by doing: # apt-get debhelper # mv berlin-tree berlin-0.0.2 # cd berlin-0.0.2 # make -f debian/rules binary These are not ready for upload to Debian, the descriptions and sections are not complete, but it will do the following: 1. Add /usr/Berlin/lib to /etc/ld.so.conf and remove it automatically 2. Add /usr/doc/Berlin with some docs 3. Add /usr/Berlin/lib with all the libs 4. Add /usr/Berlin/bin with the binary tests 5. Add /usr/Berlin/include with the headers 6. Add /usr/Berlin/include/idl with the IDL source The packages are split into three peices, berlin, berlin-dev and berlin-doc. There are several issues still: 1. Documentation gets gziped funny :) 2. WARSAW environmental variable is not set anywhere 3. Dependancies don't include the libggi-target-* stuff, should put in a Suggest: 4. The libs are named Libx.so instead of Libx.so.major.minor.patch. 5. I didn't add any manual pages (manuals should probably go /usr/Berlin/man and edit manpath.conf 6. There are no menus to add to GNOME like the old package did. 7. No automatic increments of build number yet (stays at -1) 8. Section & Priority are probably wrong and it should go into the expermental tree. Now off to play with textkit. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Tue Jun 29 19:02:54 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <99062920352800.04430@alcatraz168> References: <99062920352800.04430@alcatraz168> Message-ID: <199906291902.PAA19847@hendrix.cs.rit.edu> Well, I'm not a Berlin developer but I definately think the registry is a good idea as long as it is not abused or mangled like the Windows registry concept (which gives the word "registry" a bad reputation). Hacking up text config files is such a pain in the ass, and doing so programmatically is even more a pain, since each program will have its own syntax and format. I hope that the registry developers put alot of thought into how to make the registry extensible enough to handle almost any conceivable configuration data but do so in a way that can be arbitrarily accessed by other programs via CORBA. That way, ideally, I could modify my window manager settings in a convienient graphical front-end with as minimal knowledge of my specific window manager as possible. Anyways, don't think of the registry as a replacement for all config files. Think of it more as a replacement for the under-used and wonderfully inadequate X Resources Database. Also, a virtual filesystem, either for the kernel or for a file manager (I imagine Moscow will include a file manager with at least as much functionality as the oh-so-cool Midnight Commander), which allows the user to navigate the registry as if it were a filesystem would be really nice (but not a priority, I would think). And lo, the chronicles report that Tobias Hunger spake thusly unto the masses: > > Hello! > > I was asked today why berlin will use a registry and, to be frank, I >couldn't > answer this question. So why are we using a registry? It can't be grepped, >you > need special programs to view it, and that it allows for faster access is >(at > least in normal programs) not so essential since you read the configuration >just > once anyway. > > >From what I see in the Windows registry it is even more caotic then a >bunch of > files in /etc (but that could be my own ignorance, I hardly ever use >windows). > And files are much easier to delete then registry keys. > > So what are the advantages of a registry? > > Regards, > Tobias > > -- > > ---------------------------------------------------------------- > Tobias Hunger "Who is General Failure and > hunger@rhrk.uni-kl.de why is he reading my Disc?" > ---------------------------------------------------------------- > > > -- > To UNSUBSCRIBE, email to design-request@berlin-consortium.org > with a subject of "unsubscribe". Trouble? Contact >listmaster@berlin-consortium.org > -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From lar at ruby.cs.byu.edu Tue Jun 29 19:05:49 1999 From: lar at ruby.cs.byu.edu (Laramie Leavitt) Date: Fri Feb 25 22:23:37 2005 Subject: Registry Message-ID: I think that the registry should be basically an API, and if someone does not like the Berlin implementation, they would be free to rewrite it to use whichever mechanism that they desired, whether that be a plain jane filesystem, or some more complex SQL database backend, it would be possible to link it to Berlin. Laramie -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From icy_manipulator at mindless.com Tue Jun 29 19:14:48 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... Message-ID: <199906291914.PAA19988@hendrix.cs.rit.edu> One more opnion on the registry: I don't think it should be contained in 1 or 2 big binary (or otherwise) files like Microsoft does. I think it should be distributed as much as possible so that if, for instance, my Netscape registry settings got corrupted, the whole registry wouldn't barf. Of course, it'll probably have to be distributed somewhat between system and user, (even Microsoft does that), but if it could be as broken down as possible (without going nuts) that would be, IMO, a good thing. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 19:14:24 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <99062920352800.04430@alcatraz168> References: <37749DD6.E65A9107@wserv.com> <99062920352800.04430@alcatraz168> Message-ID: <37791B10.B7FF598B@wserv.com> Tobias Hunger wrote: > > Hello! > > I was asked today why berlin will use a registry and, to be frank, I >couldn't > answer this question. So why are we using a registry? It can't be grepped, >you > need special programs to view it, and that it allows for faster access is >(at > least in normal programs) not so essential since you read the configuration >just > once anyway. I seriously need to update the FAQ to answer this as so many people ask it. #1) Text files can not store binary data which the Registry will hold. (Text will be encoded in Unicode which is not easily edited with your average text editor anyway). #2) The Registrar will handle tens of thousands of keys in some places even hundreds of thousands (network wide registrar). Parsing a 15 meg text file is not something I'd like to do. #3) Filesystem access to do the registrar as a filesystem (ie actually use files instead of building a filesystem into a database) is far too slow at this point to be usable. ReiserFS would almost do it to be honest, but it's not standard, not supported by anything but Linux and is still under development. #4) Registrar is meant to handle persistant information which means it will be constantly changing. This means you'd either have to put the entire contents of a text database in memory or you'd have to reparse the text file every single time someone wants to make a request. #5) Keys require special security privilages, user/group ownership, permission bits, etc. This would increase a text database's size by several times. #6) You can export the database as text (XML) and edit it and then reimport it back into the Registrar (or when we get an XML engine you will be able to reimport it, right now it's export only, sorry :) > >From what I see in the Windows registry it is even more caotic then a >bunch of > files in /etc (but that could be my own ignorance, I hardly ever use >windows). > And files are much easier to delete then registry keys. People really need to remember that for all intents and purposes, filesystems are databases. All I did was put a filesystem into a file, rip out the logical -> physical translation algs and replace them with my own. Windows was a poor implementation of a good idea. AIX for example uses a configuration database that is extremely stable. As far as I know, MacOS X Server does as well (it reexports the /etc files from a database in an early version I used). Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 19:30:57 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Registry In-Reply-To: References: Message-ID: <37791EF1.F7047793@wserv.com> Laramie Leavitt wrote: > > I think that the registry should be basically an API, and if someone > does not like the Berlin implementation, they would be free to rewrite > it to use whichever mechanism that they desired, whether that be a > plain jane filesystem, or some more complex SQL database backend, it > would be possible to link it to Berlin. That's exactly what it is. Actually on my TODO list is to rip out the backend which was horribly done and put in a abstract layer to add different backends (like SQL or ReiserFS). For all intents and purposes, the registrar is just one big API that passes commands from and two a database and enforces security (or will whenever we get a SAM :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 29 19:38:03 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <199906291902.PAA19847@hendrix.cs.rit.edu> References: <199906291902.PAA19847@hendrix.cs.rit.edu> Message-ID: <3779209B.19EDAB54@magellan.umontreal.ca> Aaron Gaudio wrote: > > Well, I'm not a Berlin developer but I definately think the registry is > a good idea as long as it is not abused or mangled like the Windows registry > concept (which gives the word "registry" a bad reputation). > > Hacking up text config files is such a pain in the ass, and doing so > programmatically is even more a pain, since each program will have its > own syntax and format. I hope that the registry developers put alot of >thought > into how to make the registry extensible enough to handle almost any >conceivable > configuration data but do so in a way that can be arbitrarily accessed by > other programs via CORBA. That way, ideally, I could modify my window > manager settings in a convienient graphical front-end with as minimal >knowledge > of my specific window manager as possible. > > Anyways, don't think of the registry as a replacement for all config files. > Think of it more as a replacement for the under-used and wonderfully > inadequate X Resources Database. Full agreement. > Also, a virtual filesystem, either for the kernel or for a file manager > (I imagine Moscow will include a file manager with at least as much > functionality as the oh-so-cool Midnight Commander), which allows the user > to navigate the registry as if it were a filesystem would be really nice > (but not a priority, I would think). I think there are much better approaches to data base management than file systems as such. Anyway, whatever the *form* will be of our registry, it would indeed be good to learn two things from X: * a standardized approach for styling (where to store styles, what grammar to use) * a way to inspect the data base and modify it interactively (and online) ironically, even though X *has* protocols for both, neither is used very well. Every program has its own grammar now (see for example all the window manager configurations and the rediculous approaches to 'unify' them like with 'AnotherLevel' etc.) and it is impossible to configure things by means of a *standardized* GUI component, even though the EditRes protocol is very well suited for it. We have to investigate why this didn't work and what we have to avoid to let our style engine not die the same death X resource management does. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From lar at ruby.cs.byu.edu Tue Jun 29 19:32:41 1999 From: lar at ruby.cs.byu.edu (Laramie Leavitt) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... Message-ID: For checking purposes, maybe something like Something like a RangedData x..y? or a UniqueString? It would also be nice to have a journaled registry, i.e. somthing which logs the changes so that they can be fully undone. checkpoints as well. (maybe everytime a change is made and the program successfully runs after that.) Laramie -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 29 19:41:23 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:37 2005 Subject: Registry In-Reply-To: References: Message-ID: <37792163.BFE1E4AF@magellan.umontreal.ca> Laramie Leavitt wrote: > > I think that the registry should be basically an API, and if someone > does not like the Berlin implementation, they would be free to rewrite > it to use whichever mechanism that they desired, whether that be a > plain jane filesystem, or some more complex SQL database backend, it > would be possible to link it to Berlin. I don't agree. I think the Registry is just concerned about the persistent storage of styles in whatever form is suitable. The interface of the scene graph and the rest of berlin to styles should be completely different since the storage isn't (can't be) important to the scene graph given the fast access we need to styles values. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From hunger at rhrk.uni-kl.de Tue Jun 29 19:29:17 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <37791B10.B7FF598B@wserv.com> References: <37791B10.B7FF598B@wserv.com> Message-ID: <99062921483500.04471@alcatraz168> On Tue, 29 Jun 1999, Jordan wrote: Glad to hear the expert on this matter! > I seriously need to update the FAQ to answer this as so many people ask it. > > #1) Text files can not store binary data which the Registry will hold. (Text > will be encoded in Unicode which is not easily edited with your average text > editor anyway). What kind of binary data will be stored there? What kind of data will be stored there at all? > > #2) The Registrar will handle tens of thousands of keys in some places even > hundreds of thousands (network wide registrar). Parsing a 15 meg text file >is > not something I'd like to do. I'd hate to parse ANY 15MB file! Why won't we put it into a bunch of smaller files? My inetd has its file, all the other subsystems have theres, why do they need to get to the informations of the other programs? And you get the permissions for free. > #4) Registrar is meant to handle persistant information which means it will >be > constantly changing. This means you'd either have to put the entire >contents of > a text database in memory or you'd have to reparse the text file every >single > time someone wants to make a request. > So the registrar is some kind of temporal storage space? Why has it to be saved at all then (besides the size)? > #6) You can export the database as text (XML) and edit it and then reimport >it > back into the Registrar (or when we get an XML engine you will be able to > reimport it, right now it's export only, sorry :) > Will there be a textmode tool for that? > People really need to remember that for all intents and purposes, >filesystems > are databases. All I did was put a filesystem into a file, rip out the >logical > -> physical translation algs and replace them with my own. Windows was a >poor > implementation of a good idea. AIX for example uses a configuration database > that is extremely stable. As far as I know, MacOS X Server does as well (it > reexports the /etc files from a database in an early version I used). > I'm sorry, I only know the poor implementation of M$-windows:-) Regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From seefelds at MAGELLAN.UMontreal.CA Tue Jun 29 19:56:11 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <3779173A.A703877D@wserv.com> References: <3779173A.A703877D@wserv.com> Message-ID: <377924DB.58764A65@magellan.umontreal.ca> Jordan Mendelson wrote: > > Alright, I couldn't get in touch with Aaron (no one ever emails me back any > more), so I decided just to use my debhelper rules and commit them to CVS. >You > can download them directly from: > > http://jordy.wserv.com/berlin/debian > > Or you can rebuild them yourself by doing: > > # apt-get debhelper > # mv berlin-tree berlin-0.0.2 > # cd berlin-0.0.2 > # make -f debian/rules binary > > These are not ready for upload to Debian, the descriptions and sections are >not > complete, but it will do the following: > > 1. Add /usr/Berlin/lib to /etc/ld.so.conf and remove it automatically > 2. Add /usr/doc/Berlin with some docs > 3. Add /usr/Berlin/lib with all the libs > 4. Add /usr/Berlin/bin with the binary tests > 5. Add /usr/Berlin/include with the headers > 6. Add /usr/Berlin/include/idl with the IDL source So what are the reasons to have berlin installed into /usr ? Do we have anything to install anyway ? I'd really prefer to keep stuff in the local directory, i.e. one the developer chooses for both, sources and executables/modules. > The packages are split into three peices, berlin, berlin-dev and berlin-doc. Well, berlin-doc is quite descriptive, but what means the split between berlin and berlin-dev ? What did you put into berlin ? > There are several issues still: > > 1. Documentation gets gziped funny :) > 2. WARSAW environmental variable is not set anywhere Right. A root README (INSTALL) has to say the exact sequencce of actions to get berlin compiled/running: * set LD_LIBRARY_PATH and WARSAW to point to berlin's /lib * make config * make > 3. Dependancies don't include the libggi-target-* stuff, should put in a > Suggest: > 4. The libs are named Libx.so instead of Libx.so.major.minor.patch. Right. Something to add to the individual kit Makefiles. I suggest that the major numbers are synchronized among the sub projects and the minor numbers are individually given. > 5. I didn't add any manual pages (manuals should probably go >/usr/Berlin/man and > edit manpath.conf Once we have working ref manual creation with perceps, we can easily build man pages out of the sgml files. These then correspond to the interface definition for the classes. > 6. There are no menus to add to GNOME like the old package did. What would this be good for ? > 7. No automatic increments of build number yet (stays at -1) > 8. Section & Priority are probably wrong and it should go into the >expermental > tree. Stefan -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 20:24:32 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <377924DB.58764A65@magellan.umontreal.ca> References: <3779173A.A703877D@wserv.com> <377924DB.58764A65@magellan.umontreal.ca> Message-ID: <37792B80.ED7B8A6A@wserv.com> Stefan Seefeld wrote: > > Jordan Mendelson wrote: > So what are the reasons to have berlin installed into /usr ? > Do we have anything to install anyway ? I'd really prefer to keep > stuff in the local directory, i.e. one the developer chooses for > both, sources and executables/modules. /usr/Berlin is appropriate as Berlin is a completely seperate environment from both X and console applications. /usr/bin is for console apps. /usr/X11R6/bin is for X apps, so it was logical to make /usr/Berlin/bin for Berlin apps. I figured we might as well push them into /usr now since we'll have to do it sooner or later. > > The packages are split into three peices, berlin, berlin-dev and >berlin-doc. > > Well, berlin-doc is quite descriptive, but what means the split between > berlin and berlin-dev ? What did you put into berlin ? berlin-dev is headers and IDL sources. I just followed the lead of everyone else for things like mesa and mesa-dev and omniorb and omniorb-dev. Really it should contain non-stripped shared libraries as well, but we don't staticly link Berlin so I threw those into the main berlin deb. > Right. A root README (INSTALL) has to say the exact sequencce of actions > to get berlin compiled/running: > > * set LD_LIBRARY_PATH and WARSAW to point to berlin's /lib > * make config > * make Gotcha, actually LD_LIBRARY_PATH no longer needs to be set as I modified /etc/ld.so.conf :) It actually contains the toplevel README.FIRST file which is sort of like an INSTALL file combined with a README file at this point to compile and run Berlin. The binaries actually only need you to do one thing to make them run and that is to export WARSAW=/usr/Berlin/lib. > > 5. I didn't add any manual pages (manuals should probably go >/usr/Berlin/man and > > edit manpath.conf > > Once we have working ref manual creation with perceps, we can easily build >man > pages out of the sgml files. These then correspond to the interface >definition > for the classes. Gumdrops. > > 6. There are no menus to add to GNOME like the old package did. > > What would this be good for ? I donno, you had them in yours, I thought I'd mention it :) > > 7. No automatic increments of build number yet (stays at -1) > > 8. Section & Priority are probably wrong and it should go into the >expermental > > tree. 9. No source deb yet. (I haven't read that far yet :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 20:15:51 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... In-Reply-To: <99062921483500.04471@alcatraz168> References: <37791B10.B7FF598B@wserv.com> <99062921483500.04471@alcatraz168> Message-ID: <37792977.A9598109@wserv.com> Tobias Hunger wrote: > On Tue, 29 Jun 1999, Jordan wrote: > > #1) Text files can not store binary data which the Registry will hold. >(Text > > will be encoded in Unicode which is not easily edited with your average >text > > editor anyway). > > What kind of binary data will be stored there? What kind of data will be >stored > there at all? Things like custom structs, file type fingerprints, temporary storage for files for machines with no hard drives, copy buffers, etc. > > #2) The Registrar will handle tens of thousands of keys in some places >even > > hundreds of thousands (network wide registrar). Parsing a 15 meg text >file is > > not something I'd like to do. > > I'd hate to parse ANY 15MB file! Why won't we put it into a bunch of smaller > files? My inetd has its file, all the other subsystems have theres, why do >they > need to get to the informations of the other programs? And you get the > permissions for free. I answered this, but maybe you didn't understand :) Currently there is no well supported filesystem to work with very small to very large files efficiently. If you try putting 3k 16 byte files on your hard drive, you will waste about 80% of your disk space and cut the number of inodes you have to use by a large amount. ReiserFS is currently the only filesystem I know of which could deal with it, and there are no ports to anything but Linux as far as I know. But then again, I do plan on making a pluggable backend, so one day you will be able to plug in a filesystem module and store everything in files instead of in a database if you really really want to, although I favor SQL servers more. > > #4) Registrar is meant to handle persistant information which means it >will be > > constantly changing. This means you'd either have to put the entire >contents of > > a text database in memory or you'd have to reparse the text file every >single > > time someone wants to make a request. > > > > So the registrar is some kind of temporal storage space? Why has it to be >saved > at all then (besides the size)? Window positions, current color schemes, last 15 files open in your text editor, current button bar customizations, application preferences, file associations, undo levels in your application, copy buffers, programs IORs, etc. > > #6) You can export the database as text (XML) and edit it and then >reimport it > > back into the Registrar (or when we get an XML engine you will be able to > > reimport it, right now it's export only, sorry :) > > > > Will there be a textmode tool for that? There is already, it's one of the test binaries. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Tue Jun 29 20:44:26 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:23:37 2005 Subject: Registry... Message-ID: <21D757CECBD2D211AD5D00105A2974A739B09D@EXCHANGE> > by means of a *standardized* GUI component, even though the EditRes > protocol is very well suited for it. We have to investigate > why this didn't > work and what we have to avoid to let our style engine not > die the same > death X resource management does. > I think the reason for this disconnect was that people want maximum flexibility and configurability. I believe earlier versions of X did not provide all the features people wanted. So, as these features evolved new constructs were created to meet those needs. Now that more generic methods are available to handle such settings, there are too many entrenched configuration managers built into various products. We need to make sure that our API allows for future additions such that people won't want to "go outside the box", and would rather add new feature descriptions in the existing Registry. -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 29 21:02:13 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <3779173A.A703877D@wserv.com> References: <3779173A.A703877D@wserv.com> Message-ID: <19990629140213.A15081@localhost> On Tue, Jun 29, 1999 at 02:58:02PM -0400, Jordan Mendelson wrote: > > Alright, I couldn't get in touch with Aaron (no one ever emails me back any > more), so I decided just to use my debhelper rules and commit them to CVS. >You > can download them directly from: Wow. Could you maybe wait three days next time instead of reproducing my effort? I did respond. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 29 21:04:28 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:37 2005 Subject: Berlin debs Message-ID: <19990629140428.B15081@localhost> Yes, I have a build script for berlin. I've had one for a *long* time. The only reason I haven't done anything with it, is I can't for the life of me get the thing to run. It's something to do with my local omniorb installation. However, nobody else is having the same problem. As soon as I get it working, or get an official debian developer who can run my script for me and do an NMU, there will be .debs on all of your local mirrors. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Tue Jun 29 21:07:02 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <19990629140213.A15081@localhost> References: <19990629140213.A15081@localhost> <3779173A.A703877D@wserv.com> Message-ID: <19990629140702.C15081@localhost> On Tue, Jun 29, 1999 at 02:02:13PM -0700, Aaron Van Couwenberghe wrote: > On Tue, Jun 29, 1999 at 02:58:02PM -0400, Jordan Mendelson wrote: > > > > Alright, I couldn't get in touch with Aaron (no one ever emails me back >any > > more), so I decided just to use my debhelper rules and commit them to >CVS. You > > can download them directly from: > > Wow. Could you maybe wait three days next time instead of reproducing my > effort? I did respond. let me rephrase. one day. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 21:38:20 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Berlin debs In-Reply-To: <19990629140428.B15081@localhost> References: <19990629140428.B15081@localhost> Message-ID: <37793CCC.5C132649@wserv.com> Aaron Van Couwenberghe wrote: > > Yes, I have a build script for berlin. I've had one for a *long* time. > > The only reason I haven't done anything with it, is I can't for the life of > me get the thing to run. It's something to do with my local omniorb > installation. However, nobody else is having the same problem. Try this: First make sure your hostname is setup correctly: # ping `cat /etc/omniorb.cfg |grep Host |cut -f2 -d" "` Also make sure that it's your machine: # traceroute -n `cat /etc/omniorb.cfg |grep Host |cut -f2 -d" "` should report the start & dest IPs as the same. Then make sure that somehow your /var/log/omninames* files aren't screwed up. # /etc/init.d/omniorb stop # export OMNINAMES_LOGDIR=/var/log # export OMNIORB_USEHOSTNAME=`cat /etc/omniorb.cfg |grep Host |cut -f2 -d" "` # export OMNIORB_CONFIG=/etc/omniorb.cfg # rm /var/log/omninames* # omniNames -start `cat /etc/omniorb.cfg |grep Port |cut -f2 -d" "` # killall -15 omniNames # /etc/init.d/omniorb start Also double check omniNames is bonding to a port correctly: # nestat -a |grep LISTEN |grep `cat /etc/omniorb.cfg |grep Port |cut -f2 -d" "` and make sure there's one listed. Then double check to see you don't have any odd firewall rules: # telnet `cat /etc/omniorb.cfg |grep Host |cut -f2 -d" "` \ `cat /etc/omniorb.cfg |grep Port |cut -f2 -d" "` Type something and hit enter, it should return: GIOP and then close connection. That's everything I can think of that would cause omniORB to break. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From jordy at wserv.com Tue Jun 29 22:35:36 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <19990629140702.C15081@localhost> References: <19990629140702.C15081@localhost> <19990629140213.A15081@localhost> <3779173A.A703877D@wserv.com> Message-ID: <37794A38.B539CEA5@wserv.com> Aaron Van Couwenberghe wrote: > > On Tue, Jun 29, 1999 at 02:02:13PM -0700, Aaron Van Couwenberghe wrote: > > On Tue, Jun 29, 1999 at 02:58:02PM -0400, Jordan Mendelson wrote: > > > > > > Alright, I couldn't get in touch with Aaron (no one ever emails me back >any > > > more), so I decided just to use my debhelper rules and commit them to >CVS. You > > > can download them directly from: > > > > Wow. Could you maybe wait three days next time instead of reproducing my > > effort? I did respond. > > let me rephrase. one day. I admit it. I am an extremely impatient person. :) It was good practice anyway, I read about Debian policies and learned a bit about the hellish nightmare you call packaging. I don't think I've ever seen so many tools which all did the exact same thing before :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mental at kludge.org Tue Jun 29 23:10:07 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:23:37 2005 Subject: (L)GPL and its application In-Reply-To: <37784359.A13DC0B6@cp.net> References: <37784359.A13DC0B6@cp.net> Message-ID: On Mon, 28 Jun 1999, Jeffrey W. Baker wrote: > Finally, X and Berlin can cooperate without having to be compatible. >Because > Berlin use GGI, and GGI can be displayed in X, a user could run his Berlin > applications and his X applications simultaneously on the same X display. >In > the other direction, the X server can be made to display to a GGI target, >so a > user could run X applications on the same GGI target as his Berlin > applications. But any more than this frame-buffer-level cooperation would >be > difficult and silly. The option that would make the most sense to me would be a Berlin-based X server w/ window manager. The window manager would basically just provide an X interface to the normal Berlin WM-ish stuff. (An example of such a product for Windows is Exceed: it can take both the role of an X server and optionally a window manager, too. When it acts as a window manager, it supplies the standard Windows decorations and so forth (it in fact merely wraps Windows' native WM), so the X windows mingle on your desktop with the native apps.) Berlin's design is not so radical that you'd need explicit hooks in its design to implement something like that; it could be implemented as just another application or component. > Yes I agree with RMS here. Publish the protocol and if people want to > use it for whatever reason then they can. The wonderful thing about > open protocols is they allow people to use your system in ways that > would not occur to you. This is true of open interfaces in general. -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From mental at kludge.org Tue Jun 29 23:21:14 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:23:37 2005 Subject: comments from a berlin admirer In-Reply-To: <199906291352.JAA19316@hendrix.cs.rit.edu> References: <199906291352.JAA19316@hendrix.cs.rit.edu> Message-ID: On Tue, 29 Jun 1999, Aaron Gaudio wrote: > It seems to me that Berlin should take a higher-level approach to sound, It is actually a fairly high-level abstraction layer. It abstracts the lower-level sound interfaces in a similar fashion to how GGI3d abstracts the lower-level graphics interfaces (although admittedly my design is much more limited). If you're maybe interested in helping out, I might revisit this stuff again. I started a straight C implementation a long time ago as a proof-of-concept; I'll see if I can dig that up. -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From higgins at probita.com Wed Jun 30 00:10:34 1999 From: higgins at probita.com (higgins@probita.com) Date: Fri Feb 25 22:23:37 2005 Subject: (L)GPL and its application In-Reply-To: References: Message-ID: > On Mon, 28 Jun 1999, Jeffrey W. Baker wrote: > > > Yes I agree with RMS here. Publish the protocol and if people want to > > use it for whatever reason then they can. The wonderful thing about > > open protocols is they allow people to use your system in ways that > > would not occur to you. I'm quite confused about the issues that have been discussed involving licensing with respect to protocols. Does Berlin actually use any protocols other than CORBA? It seems to me that it does not. What I've been doing is mentally replacing the word protocol with interface whenever I see it. When people refer to placing the "protocols" under the GPL, I assume they mean licensing the IDL files under the GPL. This seems like the right approach to me. However, what meaning does the GPL have for such files? Is a CORBA interface licensable? I assume it's quite alright to license the individual .idl files under the GPL, but for them to be useful, you'll have to publish the interface they describe in a more convenient format, like HTML. Then, anyone reading this interface description could easily implement their own clean-room implementation of the .idl files, and then modify them. The question is, would these modifications also be GPL? I suspect the answer is no, but I'm unsure. RMS has said that protocols are not licensable. I assume the same is true for CORBA interfaces. If we assume that the Berlin interfaces cannot be protected by the GPL, then we should consider what possibilities exist for non-free extension. If we are unable to protect our own interface, then I assume anyone developing non-free extensions would also be unable to protect those extensions. I believe the worst they could do would be to not document them, forcing us to determine them empirically (and though I'm no CORBA expert, I assume the effort involved would be trivial). Given this, I don't think we should worry too much about non-free extension to the Berlin interfaces. However, it would be nice to avoid the extra step and just obtain the modified IDL files for extensions directly from the modifier. If it is true that the interface is not licensable and the GPL can't provide this protection, might another mechanism exist to fill this role? Patrick -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From higgins at probita.com Wed Jun 30 01:10:32 1999 From: higgins at probita.com (higgins@probita.com) Date: Fri Feb 25 22:23:37 2005 Subject: Mesa CVS Message-ID: I really can't wait to get hacking on Berlin (looks like a kick-ass project), but I'm having troubles getting all the components together. I'm trying to get everything together at work on RedHat 5.2, but I'll ultimately be coding on SuSE 6.1 at home. I built GGI from CVS cleanly (and am very pleased with the performance of the demos! Great work, GGI crew!). I decided to try Mesa 3.0, but that was incompatible with CVS GGI. I then tried Mesa CVS only to find someone has totally broken the linux-ggi target. The CVS logs point to jtaylor, but we'll avoid name calling at this point. Anyway, what versions of GGI and MesaGGI are compatible, and also compatible with Berlin? I want to try to keep my downloads over my 28.8 modem at home to a minimum. :) How up-to-date is the TODO list on the webserver? I know I saw a mail suggesting that it was pretty old. If so, any suggestions on a good first task to tackle to help learn the system? Patrick -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From vanco at sonic.net Wed Jun 30 01:20:44 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:23:37 2005 Subject: Mesa CVS In-Reply-To: References: Message-ID: <19990629182044.F15111@localhost> On Tue, Jun 29, 1999 at 07:10:32PM -0600, higgins@probita.com wrote: > I really can't wait to get hacking on Berlin (looks like a kick-ass > project), but I'm having troubles getting all the components together. > I'm trying to get everything together at work on RedHat 5.2, but I'll > ultimately be coding on SuSE 6.1 at home. > > I built GGI from CVS cleanly (and am very pleased with the performance of > the demos! Great work, GGI crew!). I decided to try Mesa 3.0, but that > was incompatible with CVS GGI. I then tried Mesa CVS only to find someone > has totally broken the linux-ggi target. The CVS logs point to jtaylor, > but we'll avoid name calling at this point. > > Anyway, what versions of GGI and MesaGGI are compatible, and also > compatible with Berlin? I want to try to keep my downloads over my 28.8 > modem at home to a minimum. :) What you need to do is get the Debian sources. Go to ftp.us.debian.org/debian/dists/unstable/main/source/ and get it from there. The .orig.tar.gz and the .diff.gz are important to you. Unpack the former, and apply the latter to it. From there, you should be able to build. And yes, Jon did break it, but his layout is much better than the old. Once it's in working order, I'll be immensely glad (he fixed the 24bpp displaylib) [A -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From graydon at pobox.com Wed Jun 30 01:23:08 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:23:37 2005 Subject: Debian 0.0.2 .debs In-Reply-To: <37794A38.B539CEA5@wserv.com> References: <37794A38.B539CEA5@wserv.com> Message-ID: <19990629212308A.graydon@pobox.com> > It was good practice anyway, I read about Debian policies and learned a bit > about the hellish nightmare you call packaging. I don't think I've ever >seen so > many tools which all did the exact same thing before :) oh come on, you heared knuth's joke? "what's the definition of unix?" "20 different kinds of regular expression syntax living under the same roof" -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From bfulgham at xpsystems.com Wed Jun 30 04:13:59 1999 From: bfulgham at xpsystems.com (Brent A. Fulgham) Date: Fri Feb 25 22:23:37 2005 Subject: Whining about libpng Message-ID: <14201.39110.915726.464004@hopper> Stefan, A partial solution: It appears that libpng buffers it reading text temporarily so that it can expand the bytes using the zlib decompression routines. This explains why I see it writing to an unfamiliar area of memory. I assume that this also occurs during the write phase, as it must compress my raw bytes before writing. Fine. But why does my array of row pointers come back from the read() method with nothing stored? (Recall that my rows[] array entered the routine pointing to an empty png_byte. It returns in the same state.) So how the heck do I ever get to the data I read? :-( -Brent -- To UNSUBSCRIBE, email to design-request@berlin-consortium.org with a subject of "unsubscribe". Trouble? Contact listmaster@berlin-consortium.org From rms at gnu.org Wed Jun 30 11:25:46 1999 From: rms at gnu.org (Richard Stallman) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application In-Reply-To: <37784359.A13DC0B6@cp.net> (jwb@cp.net) References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906290322.VAA28604@wijiji.santafe.edu> <37784359.A13DC0B6@cp.net> Message-ID: <199906301125.FAA02044@wijiji.santafe.edu> I wholeheartedly disagree. Berlin will (or won't) stand on its own merits. If using Berlin means that many programs written for X just won't run, that in itself is a major demerit, practically speaking. Finally, X and Berlin can cooperate without having to be compatible. Because Berlin use GGI, and GGI can be displayed in X, a user could run his Berlin applications and his X applications simultaneously on the same X display. In the other direction, the X server can be made to display to a GGI target, so a user could run X applications on the same GGI target as his Berlin applications. If one of these methods can solve the practical problem of coexistence between Berlin and X, I urge you most strongly to do it. I think it needs to be possible to have both kinds of windows appearing on the screen together, interacting reasonably with each other when they overlap, and manage them with one common window manager. I do not know whether either of these methods would permit that, but isn't it possible to emulate the X protocol on top of Berlin? From rms at gnu.org Wed Jun 30 11:25:43 1999 From: rms at gnu.org (Richard Stallman) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application In-Reply-To: <37784198.F1370C3C@magellan.umontreal.ca> (message from Stefan Seefeld on Mon, 28 Jun 1999 23:46:32 -0400) References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906290322.VAA28604@wijiji.santafe.edu> <37784198.F1370C3C@magellan.umontreal.ca> Message-ID: <199906301125.FAA02038@wijiji.santafe.edu> I wish you were right. However, aren't algorithms patented in the US ? Algorithms can be covered by patents in the US. However, patents and copyrights are very different. Are you planning to try to get a patent on some aspect of Berlin? What is the difference between an algorithm (see for example GIF) and a protocol (at least legaly) ? An algorithm and a protocol are two different kinds of things, but both could potentially be covered by a patent. Unfortunately, it is most likely to be covered by SOMEONE ELSE's patent. From seefelds at MAGELLAN.UMontreal.CA Wed Jun 30 15:03:21 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906290322.VAA28604@wijiji.santafe.edu> <37784198.F1370C3C@magellan.umontreal.ca> <199906301125.FAA02038@wijiji.santafe.edu> Message-ID: <377A31B9.6EC0A0FF@magellan.umontreal.ca> Richard Stallman wrote: > > I wish you were right. However, aren't algorithms patented in the US ? > > Algorithms can be covered by patents in the US. However, patents and > copyrights are very different. Are you planning to try to get a patent > on some aspect of Berlin? > > What is the difference between an algorithm (see for example GIF) and > a protocol (at least legaly) ? > > An algorithm and a protocol are two different kinds of things, but both > could potentially be covered by a patent. Unfortunately, it is most > likely to be covered by SOMEONE ELSE's patent. That's exactly the point. I think this is even the point about the copyleft in general. We live in a world which is nowadays very much looked at in terms of ownership and property. It's difficult to get over this restricting world view. So using one's property and combining it with copyleft is a way to transcendent and negate the notion of property in itself. I don't want to patent any algorithm or protocol. But I want to make sure that I always have the freedom to use it whatever 'use' means to me. Therefor I have to avoid that anyone else appropriates it. Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From seefelds at MAGELLAN.UMontreal.CA Wed Jun 30 15:16:54 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:26:11 2005 Subject: Mesa CVS References: Message-ID: <377A34E6.90A2BC30@magellan.umontreal.ca> higgins@probita.com wrote: > How up-to-date is the TODO list on the webserver? I know I saw a mail > suggesting that it was pretty old. If so, any suggestions on a good first > task to tackle to help learn the system? Right, the TODO list is a bit outdated. If you look at the people page of the project you will see which sub projects we are working on so you could guess from the names of the kits what they mean (and by browsing the interfaces). Then simply take one and a) ask questions to the mailing list or b) get in contact with one of the guys working on the project you picked. Anyway, you should go to the docs page and read (at least browse) the most imporetant papers since they are the best description of Berlin's design we have so far. Take for example * the Fresco docs * Glyphs: Flyweight Objects for User Interfaces * Unidraw: a Framework for Building Domain Specific Graphical Editors Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From twig at babba.advancenet.net Wed Jun 30 17:45:26 1999 From: twig at babba.advancenet.net (Shaw Terwilliger) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application In-Reply-To: <377A31B9.6EC0A0FF@magellan.umontreal.ca>; from Stefan Seefeld on Wed, Jun 30, 1999 at 03:03:21PM +0000 References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906290322.VAA28604@wijiji.santafe.edu> <37784198.F1370C3C@magellan.umontreal.ca> <199906301125.FAA02038@wijiji.santafe.edu> <377A31B9.6EC0A0FF@magellan.umontreal.ca> Message-ID: <19990630124526.A2628@babba.advancenet.net> On Wed, Jun 30, 1999 at 03:03:21PM +0000, Stefan Seefeld wrote: > Richard Stallman wrote: > > An algorithm and a protocol are two different kinds of things, but both > > could potentially be covered by a patent. Unfortunately, it is most > > likely to be covered by SOMEONE ELSE's patent. > > [...] > > I don't want to patent any algorithm or protocol. But I want to make sure > that I always have the freedom to use it whatever 'use' means to me. Therefor > I have to avoid that anyone else appropriates it. This is somewhat not related to Berlin, but I figure there's probably no better person to answer my question than Richard. Personally, I'm against software patents and most everything they stand for, but I don't see the laws of my country changing (USA) any time soon. I've thrown around the idea of finding a way to beat the system at its own game--like copyleft is to copyright. I considered applying for patents under some legally binding terms that I could never collect royalties or restrict the use of my patented techniques at all, ever. I'm not a lawyer, I know little about the actual patent application process, and I'm not rich. This seems to be much more trouble than it's worth. Patents are expensive and time consuming, and even for the good a project like this might bring, a patent liberation crusade is something no one should ever have to do. The most crippling step in the process is my government itself, notorious for not even understanding its own processes and regulations. My mind wandered to prior art clauses. Is there some established way of "proving" your intellectual work so you have some solid legal ground from which to fight future patent claims? I'm talking mostly software patents here (I'm not happy with patents which cover "real-world" processes, but that's a different argument). Must one "publish" his work? What's meant by "publish?" Does your software have to hit the shelves in a shrink-wrapped box? Do you just need enough witnesses to back you up in court (this one is full of uncertainties)? Would an FTP archive disk from '94 be enough? -- Shaw Terwilliger (twig@advancenet.net) From jordy at wserv.com Wed Jun 30 17:02:59 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application References: <199906231918.PAA15913@delysid.gnu.org> <199906260922.DAA22341@wijiji.santafe.edu> <3774EF89.1954F7A@magellan.umontreal.ca> <199906272257.QAA26241@wijiji.santafe.edu> <3777860A.34B4800B@magellan.umontreal.ca> <199906290322.VAA28604@wijiji.santafe.edu> <37784359.A13DC0B6@cp.net> <199906301125.FAA02044@wijiji.santafe.edu> Message-ID: <377A4DC3.6ADA1522@wserv.com> Richard Stallman wrote: > I think it needs to be possible to have both kinds of windows > appearing on the screen together, interacting reasonably with each > other when they overlap, and manage them with one common window > manager. > > I do not know whether either of these methods would permit that, but > isn't it possible to emulate the X protocol on top of Berlin? Berlin runs ontop of Mesa. Mesa currently can live ontop of GGI or X. Either target will allow you to run Berlin as a window within X. With a little work, the reverse could be done, to run X inside of Berlin. Off the top of my head, I'd say write a Berlin target for GGI and use the GGI X server to display X in a Berlin window. The third option of course is to write a complete X compatibility layer for Berlin. This would require the most work and still not give much better results than simply running X in Berlin. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From icy_manipulator at mindless.com Wed Jun 30 17:38:16 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:26:11 2005 Subject: (L)GPL and its application In-Reply-To: <377A4DC3.6ADA1522@wserv.com> from "Jordan Mendelson" at Jun 30, 99 01:02:59 pm Message-ID: <199906301738.NAA20771@hendrix.cs.rit.edu> And lo, the chronicles report that Jordan Mendelson spake thusly unto the masses: > > Berlin runs ontop of Mesa. Mesa currently can live ontop of GGI or X. Either > target will allow you to run Berlin as a window within X. This relegates Berlin to an X "toy". If Berlin is to be a replacement for X, then we wouldn't want its general use to be from within X. If this is the only way of X and Berlin co-habiting then it is just about the only way Berlin will get used, because there are (at this point) far too many X apps for folks to discard (esp. if you have to work with remote systems which have X but not Berlin). > > With a little work, the reverse could be done, to run X inside of Berlin. Off > the top of my head, I'd say write a Berlin target for GGI and use the GGI X > server to display X in a Berlin window. This is a good short term solution. There are other reasons to have a Berlin target for GGI as well, including running other (non-XGGI) GGI programs from within Berlin. > > The third option of course is to write a complete X compatibility layer for > Berlin. This would require the most work and still not give much better results > than simply running X in Berlin. This is, IMO, the best (and only) long-term solution. It would require alot of work and I would imagine the second option will be the one availible by the time Berlin is at release stage, and this would eventually come out. With the coming XFree86 4.0, the X protocol and the graphical device drivers are supposed to be divided from one another much better than they are, so it may be possible to utilize alot of XFree86 code to handle the X protocol apart from converting it to the CORBA interface of Berlin. In the end, I think most people will want to be able to use their legacy X apps as cleanly as possible; in fact as transparently as possible. I don't think we'd have to worry about the third option encouraging places to keep coding for X instead of Berlin. If Berlin's feature-set is not attractive enough for folks to port/write their apps for it, then they won't, whether XFree is there or not, and the opposite is true as well. I imagine alot of places will keep programming for X just because the rampup will not be justified immediately. Once Berlin gathers momentum, though, I think many developers and software houses will be more comfortable making the switch. Of course, Berlin will need a killer app, whether it be something like Moscow or an office suite (sorry Stallman, I'm not counting emacs ;-) or a game or whatnot. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. From vanco at sonic.net Wed Jun 30 18:12:36 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:26:11 2005 Subject: Omniorb -6 debs In-Reply-To: <21D757CECBD2D211AD5D00105A2974A73A6FAC@EXCHANGE>; from Brent Fulgham on Wed, Jun 30, 1999 at 10:42:37AM -0700 References: <21D757CECBD2D211AD5D00105A2974A73A6FAC@EXCHANGE> Message-ID: <19990630111236.A1230@localhost> On Wed, Jun 30, 1999 at 10:42:37AM -0700, Brent Fulgham wrote: > Aaron, > > I the omniorb-6 debs on Master are current, and built for Potato. I also > have a set > at http://pandora.debian.org/~bfulgham > > -Brent Hey, BTW, everything works now. I haven't the slightest idea what I did. But, thanks for all the tips. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. From seefelds at MAGELLAN.UMontreal.CA Wed Jun 30 18:25:22 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:26:11 2005 Subject: release References: <21D757CECBD2D211AD5D00105A2974A73A6FAC@EXCHANGE> <19990630111236.A1230@localhost> Message-ID: <377A6112.6E6F02CB@magellan.umontreal.ca> Aaron Van Couwenberghe wrote: > Hey, BTW, everything works now. I haven't the slightest idea what I did. Excellent. Let's get berlin out as soon as possible (this week !). Is there agreement about the versioning ? Freshmeat indicates (as of January) that the development version is (was) 0.1.1. So are we releaseing 0.1.1 now ? Anyway, we'll see when reading Graydons announcements :) Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From jordy at wserv.com Wed Jun 30 18:39:08 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package Message-ID: <377A644C.FF5D7574@wserv.com> Graydon brought up ICU a few days ago and I've just had a chance to take a good long look at it and I must say I'm impressed. The package contains date, number, currency, and time localizations along with the Unicode suite. It also seems quite easy to use, as the API is identical to Java's, in fact.. you can use Javasoft's documentation as a reference with very few changes. The data files are small after being compiled (about 4 megs with the locale data as well) I have created a preliminary .deb package for ICU which will allow us to use it within Berlin without having to import it into our source tree. You can download it from: http://jordy.wserv.com/berlin/debian/ It's called, icu_1.2.1-1_i386.deb I've also made the source archives available called icu_1.2.1.orig.tar.gz, icu_1.2.1-1.dsc, and icu_1.2.1-1.diff.gz. I'm not too sure how to submit debian packages to debian yet though :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From jordy at wserv.com Wed Jun 30 18:53:17 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:26:11 2005 Subject: Omniorb -6 debs References: <21D757CECBD2D211AD5D00105A2974A73A6FAC@EXCHANGE> <19990630111236.A1230@localhost> Message-ID: <377A679D.17A2E619@wserv.com> Aaron Van Couwenberghe wrote: > > On Wed, Jun 30, 1999 at 10:42:37AM -0700, Brent Fulgham wrote: > > > > I the omniorb-6 debs on Master are current, and built for Potato. I also > > have a set > > at http://pandora.debian.org/~bfulgham Omniorb-6? Any particular reason for the major skip in version numbers? > Hey, BTW, everything works now. I haven't the slightest idea what I did. > > But, thanks for all the tips. Damn, none of my tips worked? You know how long I spent typing that out? :) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From hunger at rhrk.uni-kl.de Wed Jun 30 18:49:23 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package References: <377A644C.FF5D7574@wserv.com> Message-ID: <99063021170000.15123@alcatraz168> On Wed, 30 Jun 1999, Jordan Mendelson wrote: > Graydon brought up ICU a few days ago and I've just had a chance to take a good > long look at it and I must say I'm impressed. The package contains date, number, > currency, and time localizations along with the Unicode suite. It also seems > quite easy to use, as the API is identical to Java's, in fact.. you can use > Javasoft's documentation as a reference with very few changes. > > The data files are small after being compiled (about 4 megs with the locale data > as well) > > > I have created a preliminary .deb package for ICU which will allow us to use it > within Berlin without having to import it into our source tree. > > You can download it from: > > http://jordy.wserv.com/berlin/debian/ > > It's called, icu_1.2.1-1_i386.deb > > I've also made the source archives available called icu_1.2.1.orig.tar.gz, > icu_1.2.1-1.dsc, and icu_1.2.1-1.diff.gz. > > I'm not too sure how to submit debian packages to debian yet though :) > > > Jordan > It's a cool lib, but it is NOT compatible with the GPL, you can not legally link a GPL-application against ICU. Both debian-guys and and some people at the booth of IBM told that to me at the linuxtag here in Kaiserslautern. So I'm quite coonfident that this information is from good sources :-) Best regards, Tobias -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- From jordy at wserv.com Wed Jun 30 20:04:27 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package References: <377A644C.FF5D7574@wserv.com> <99063021170000.15123@alcatraz168> Message-ID: <377A784B.2BDFECC5@wserv.com> Tobias Hunger wrote: > It's a cool lib, but it is NOT compatible with the GPL, you can not > legally link a GPL-application against ICU. Both debian-guys and and some > people at the booth of IBM told that to me at the linuxtag here in > Kaiserslautern. So I'm quite coonfident that this information is from good > sources :-) We are under LGPL, not GPL so we should have no problem linking to this. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From vanco at sonic.net Wed Jun 30 21:05:59 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:26:11 2005 Subject: Omniorb -6 debs In-Reply-To: <377A679D.17A2E619@wserv.com>; from Jordan Mendelson on Wed, Jun 30, 1999 at 02:53:17PM -0400 References: <21D757CECBD2D211AD5D00105A2974A73A6FAC@EXCHANGE> <19990630111236.A1230@localhost> <377A679D.17A2E619@wserv.com> Message-ID: <19990630140559.B6002@localhost> On Wed, Jun 30, 1999 at 02:53:17PM -0400, Jordan Mendelson wrote: > Aaron Van Couwenberghe wrote: > > > > On Wed, Jun 30, 1999 at 10:42:37AM -0700, Brent Fulgham wrote: > > > > > > I the omniorb-6 debs on Master are current, and built for Potato. I also > > > have a set > > > at http://pandora.debian.org/~bfulgham > > Omniorb-6? Any particular reason for the major skip in version numbers? Brent's been releasing new versions to his homespace at master for some time now. Whenever the original codebase changes, it takes quite some time to push a package through incoming, and if anything serious enough is wrong, the packages will get yanked from main, at which point the whole process starts again... > > > Hey, BTW, everything works now. I haven't the slightest idea what I did. > > > > But, thanks for all the tips. > > Damn, none of my tips worked? You know how long I spent typing that out? :) I tried em all, everything checked out ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. From graydon at pobox.com Wed Jun 30 21:34:17 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:26:11 2005 Subject: release In-Reply-To: Your message of "Wed, 30 Jun 1999 18:25:22 +0000" <377A6112.6E6F02CB@magellan.umontreal.ca> References: <377A6112.6E6F02CB@magellan.umontreal.ca> Message-ID: <19990630173417V.graydon@pobox.com> > Excellent. Let's get berlin out as soon as possible (this week !). > Is there agreement about the versioning ? Freshmeat indicates (as of > January) that the development version is (was) 0.1.1. So are we releaseing > 0.1.1 now ? Anyway, we'll see when reading Graydons announcements :) the version numbering scheme is same as linux: major.minor.patch. The first version I announced I called 0.0.1 because 0.0.0 sounded too depressing. technically this new one should be 1.0.0 because it's a complete rewrite, but people assume "1.x.x" means "working", so I vote for 0.1.0, and we pretend this was just a "minor" change. Visible-functionality wise, it sorta is. No joe-users will be able to tell it changed :) Now that we have (I think) a much more stable, portable, reproducable build & run procedure, I think we can do muchos more point releases on 0.1.x -graydon From hunger at rhrk.uni-kl.de Wed Jun 30 21:51:15 1999 From: hunger at rhrk.uni-kl.de (Tobias Hunger) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package References: <377A644C.FF5D7574@wserv.com> Message-ID: <99063023565300.15874@alcatraz168> On Wed, 30 Jun 1999, Jordan Mendelson wrote: > I have created a preliminary .deb package for ICU which will allow us to use it > within Berlin without having to import it into our source tree. > > You can download it from: > > http://jordy.wserv.com/berlin/debian/ > > It's called, icu_1.2.1-1_i386.deb > > I've also made the source archives available called icu_1.2.1.orig.tar.gz, > icu_1.2.1-1.dsc, and icu_1.2.1-1.diff.gz. > > I'm not too sure how to submit debian packages to debian yet though :) > > > Jordan Yep, you are right. We are under LGPL. All this legalize made me a bit confused... I just installed your icu debs. They work fine, I just wrote a small test program and it worked (as soon as I figured out which header files to include :-) Regards, Tobias PS: Did you notice the talk about the IBM Public License on the debian-legal ML? I read it, but I couldn't figure out what exactly there position on this matter was... -- ---------------------------------------------------------------- Tobias Hunger "Who is General Failure and hunger@rhrk.uni-kl.de why is he reading my Disc?" ---------------------------------------------------------------- From icy_manipulator at mindless.com Wed Jun 30 22:31:57 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package In-Reply-To: <377A784B.2BDFECC5@wserv.com> from "Jordan Mendelson" at Jun 30, 99 04:04:27 pm Message-ID: <199906302231.SAA20960@hendrix.cs.rit.edu> And lo, the chronicles report that Jordan Mendelson spake thusly unto the masses: > > Tobias Hunger wrote: > > > It's a cool lib, but it is NOT compatible with the GPL, you can not > > legally link a GPL-application against ICU. Both debian-guys and and some > > people at the booth of IBM told that to me at the linuxtag here in > > Kaiserslautern. So I'm quite coonfident that this information is from good > > sources :-) > > We are under LGPL, not GPL so we should have no problem linking to this. > > But what will the resultant application be licensed under? If the problem is that the IBM license doesn't allow relicensing, this essentially means that Berlin would be covered by the IBM license if it is viral. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. From vanco at sonic.net Wed Jun 30 22:37:12 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:26:11 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package In-Reply-To: <199906302231.SAA20960@hendrix.cs.rit.edu>; from Aaron Gaudio on Wed, Jun 30, 1999 at 06:31:57PM -0400 References: <377A784B.2BDFECC5@wserv.com> <199906302231.SAA20960@hendrix.cs.rit.edu> Message-ID: <19990630153712.A6093@localhost> On Wed, Jun 30, 1999 at 06:31:57PM -0400, Aaron Gaudio wrote: > > We are under LGPL, not GPL so we should have no problem linking to this. > > > > > > But what will the resultant application be licensed under? If the problem > is that the IBM license doesn't allow relicensing, this essentially means > that Berlin would be covered by the IBM license if it is viral. In which case people couldn't license berlin clients under GPL, which would be a BAD thing. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't. From bfulgham at xpsystems.com Wed Jun 30 22:40:32 1999 From: bfulgham at xpsystems.com (Brent Fulgham) Date: Fri Feb 25 22:26:12 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package Message-ID: <21D757CECBD2D211AD5D00105A2974A73AAD9A@EXCHANGE> > > But what will the resultant application be licensed under? If > the problem > is that the IBM license doesn't allow relicensing, this > essentially means > that Berlin would be covered by the IBM license if it is viral. > > The IBM license poses no danger to Berlin as long as we are LGPL'd, and are only linking to this library. It's the same situation as if I compiled GNU software on my AIX machine at work -- I can link against the system libraries (non-free, proprietary IBM C libraries) without violating LGPL. The only danger is that if we _RELY_ on their software, we could be in trouble if they ever remove their product. We would be forced to reimplement everything we were using from their product. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.spi-inc.org/pipermail/fresco-devel/attachments/19990630/42b30136/attachment.htm From jordy at wserv.com Wed Jun 30 22:45:29 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:26:12 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package References: <377A784B.2BDFECC5@wserv.com> <199906302231.SAA20960@hendrix.cs.rit.edu> <19990630153712.A6093@localhost> Message-ID: <377A9E09.8ED68C02@wserv.com> Aaron Van Couwenberghe wrote: > > On Wed, Jun 30, 1999 at 06:31:57PM -0400, Aaron Gaudio wrote: > > > We are under LGPL, not GPL so we should have no problem linking to this. > > > > > > > > > > But what will the resultant application be licensed under? If the problem > > is that the IBM license doesn't allow relicensing, this essentially means > > that Berlin would be covered by the IBM license if it is viral. > > In which case people couldn't license berlin clients under GPL, which would > be a BAD thing. Yeah, that's the problem. What we should do is use ICU until someone wants to go through and reimplement it as LGPL. The API is already optimial (the one thing Sun did right with Java), so reimplementing and keeping compatibility would basically require porting a peice of one of the other free Java VM's to C++. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From icy_manipulator at mindless.com Wed Jun 30 22:54:32 1999 From: icy_manipulator at mindless.com (Aaron Gaudio) Date: Fri Feb 25 22:26:12 2005 Subject: IBM's Classes for Unicode (ICU) Debian Package In-Reply-To: <21D757CECBD2D211AD5D00105A2974A73AAD9A@EXCHANGE> from "Brent Fulgham" at Jun 30, 99 03:40:32 pm Message-ID: <199906302254.SAA21035@hendrix.cs.rit.edu> But then why is linking against the ICU to create a GPL product not acceptable? As long as the IBM license does not impose any restrictions on applications which link against it, then you should be able to license your application under any license you so choose. Of course, the problem is just what you said: depending on non-free code in a free software project. That's what has kept KDE in the Debian contrib directory. It dilutes the purpose of free software when a component, any component (major or otherwise) of the software is non-free, because the users/hackers no longer have complete latitude with the total product. Using KDE as an example, if I didn't like the way Qt worked in KDE, I couldn't legally do anything about it because KDE was limited in that regard by the Qt license. If I want to change the way Berlin handles Unicode, will I be able to go and edit the source code for the IBM Unicode component or will I have to completely replace it with a free version? Remember, the Dark Side is not stronger, it's just easier, more suductive ;-) Note: I haven't actually read the IBM license so what I said may perfectly be possible and any implied criticisms may be unjustified; but these are the dangers of relying on non-free or "semi"-free (whatever that means) code in free software. Hopefully Berlin can avoid the fiasco KDE had to face. BTW, your mailer is sending your messages in both plain text and HTML, which is really annoying for me using elm and eats up bandwidth. You should try to send only plain text whenever possible. And lo, the chronicles report that Brent Fulgham spake thusly unto the masses: > > > > > But what will the resultant application be licensed under? If > > the problem > > is that the IBM license doesn't allow relicensing, this > > essentially means > > that Berlin would be covered by the IBM license if it is viral. > > > > > > The IBM license poses no danger to Berlin as long as we are LGPL'd, > and are only linking to this library. It's the same situation as > if I compiled GNU software on my AIX machine at work -- I can link > against the system libraries (non-free, proprietary IBM C libraries) > without violating LGPL. > > The only danger is that if we _RELY_ on their software, we could be > in trouble if they ever remove their product. We would be forced > to reimplement everything we were using from their product. > > -Brent > -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "The fool finds ignorance all around him. The wise man finds ignorance within." -------------- Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein. From mental at kludge.org Wed Jun 30 23:07:49 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:26:12 2005 Subject: Interface v.s. Protocol In-Reply-To: Message-ID: On Tue, 29 Jun 1999 higgins@probita.com wrote: > I'm quite confused about the issues that have been discussed involving > licensing with respect to protocols. Does Berlin actually use any > protocols other than CORBA? It seems to me that it does not. What I've > been doing is mentally replacing the word protocol with interface whenever > I see it. When people refer to placing the "protocols" under the GPL, I > assume they mean licensing the IDL files under the GPL. This seems like > the right approach to me. IMO, interface:protocol::vocabulary:syntax -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY From vanco at sonic.net Tue Jun 1 01:09:49 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: IRC In-Reply-To: <3752F3B8.CF58B087@magellan.umontreal.ca>; from Stefan Seefeld on Mon, May 31, 1999 at 08:40:24PM +0000 References: <3752F3B8.CF58B087@magellan.umontreal.ca> Message-ID: <19990531180949.A925@awac.local.net> On Mon, May 31, 1999 at 08:40:24PM +0000, Stefan Seefeld wrote: > hey, > > about two or three weeks ago we tried to schedule an IRC > meeting. Most of you seemed too busy then. Should we try > it again ? Can we manage a meeting, say, sometime in June ? > I suspect it might be helpful if everyone gives some hints > about preferred dates/times so we can set a new date. After June 11, any day, any time is perfectly workable here. Before then, any weekday after 6 PST (13 UTC) or any weekend any time is fine. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Tue Jun 1 01:22:05 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: plugins and strip Message-ID: <19990531182205.A971@awac.local.net> As the runtime dynamic loader for the plugins berlin uses depends on the availability of symbols in the .so's, can they be stripped without breaking them? Just curious... I mean, if there are no symbols in object code, it'd be a minor miracle for ldsym to spit back the right pointer... Thanks! -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Tue Jun 1 01:24:18 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: IRC In-Reply-To: <19990531180949.A925@awac.local.net>; from Aaron Van Couwenberghe on Mon, May 31, 1999 at 06:09:49PM -0700 References: <3752F3B8.CF58B087@magellan.umontreal.ca> <19990531180949.A925@awac.local.net> Message-ID: <19990531182418.A980@awac.local.net> On Mon, May 31, 1999 at 06:09:49PM -0700, Aaron Van Couwenberghe wrote: > On Mon, May 31, 1999 at 08:40:24PM +0000, Stefan Seefeld wrote: > > hey, > > > > about two or three weeks ago we tried to schedule an IRC > > meeting. Most of you seemed too busy then. Should we try > > it again ? Can we manage a meeting, say, sometime in June ? > > I suspect it might be helpful if everyone gives some hints > > about preferred dates/times so we can set a new date. > > After June 11, any day, any time is perfectly workable here. > Before then, any weekday after 6 PST (13 UTC) or any weekend any time is > fine. Oh gosh, leave it to me to butcher the language so well. let me rephrase. After june 11, any day any time. Before then, weekdays after 18:00 PDT (1:00 UTC) or any time any weekend. Thanks for being forgiving ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 01:40:08 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:37 2005 Subject: plugins and strip In-Reply-To: <19990531182205.A971@awac.local.net> Message-ID: On Mon, 31 May 1999, Aaron Van Couwenberghe wrote: > As the runtime dynamic loader for the plugins berlin uses depends on the > availability of symbols in the .so's, can they be stripped without breaking > them? Didn't we discuss this very topic ? Didn't *you* point out that 'strip --strip-unneeded' only strips the symbols of internal use ? Anyway, it's the thing to do. Look at config/plugin.mk. You may well strip using the above option. It conserves all necessary info dlsym() needs to lookup symbols. Regards, Stefan From vanco at sonic.net Tue Jun 1 01:43:47 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: Running the server from today's CVS Message-ID: <19990531184347.A1510@localhost> Ok, I tried to run today's server, and libBerlin still couldn't find TextKit. Looking at the build tree, the Text directory is still commented out of SUBDIRS in src/. I'm sure someone already knew about this. When I tried to uncomment it the other day, I still got the same errors, except the plugin loader passed right over libText without recognizing it as a plugin. Just wanted to make sure this didn't get forgotten about ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Tue Jun 1 01:47:41 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: oops, here's the log Message-ID: <19990531184741.A1519@localhost> Here's the log of the failed run: * logbuf::dump = [0.011037:0:corba] [0/5] hooked up to corba library [0.412587:0:drawing] [1/5] built drawing system [0.414934:0:layout] [2/5] opened root node in scene graph [snip the plugin loader iterating over $WARSAW] [0.468485:0:loader] [3/5] initialized loadable modules [0.469336:0:corba] getRootContext: looking up root corba name context [0.482415:0:corba] [4/5] listening for clients [0.482497:0:corba] [5/5] event distributor constructed, about to enter main loop [snip a gazillion traversals] [11.774:5:loader] GenericFactoryImpl::create_object not doing lifecycle copy for IDL:omg.org/LayoutKit:1.0 [11.7996:5:loader] GenericFactoryImpl::create_object not doing lifecycle copy for IDL:omg.org/FigureKit:1.0 [11.8004:5:loader] GenericFactoryImpl::supports does not support IDL:omg.org/TextKit:1.0 [11.8005:5:loader] GenericFactoryImpl::supports interface listing follows: [11.8005:5:loader] IDL:omg.org/FigureKit:1.0 [11.8005:5:loader] IDL:omg.org/LayoutKit:1.0 [11.8005:5:loader] IDL:omg.org/WidgetKit:1.0 * end of logbuf::dump Whoever fixed up the debug mechanisms, good job ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Tue Jun 1 01:49:59 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: plugins and strip In-Reply-To: ; from Seefeld Stefan on Mon, May 31, 1999 at 09:40:08PM -0400 References: <19990531182205.A971@awac.local.net> Message-ID: <19990531184959.A1061@awac.local.net> On Mon, May 31, 1999 at 09:40:08PM -0400, Seefeld Stefan wrote: > On Mon, 31 May 1999, Aaron Van Couwenberghe wrote: > > > As the runtime dynamic loader for the plugins berlin uses depends on the > > availability of symbols in the .so's, can they be stripped without breaking > > them? > > Didn't we discuss this very topic ? Didn't *you* point out that 'strip > --strip-unneeded' only strips the symbols of internal use ? We were talking about shared libraries, which I had stripped of all symbols more times than I can remember (without any difficulties afterwards). I just don't know how to deal with plugins where we require symbols to be present... > Anyway, it's the thing to do. Look at config/plugin.mk. > You may well strip using the above option. It conserves all necessary info > dlsym() needs to lookup symbols. Ok, thanks! -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 01:50:37 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:37 2005 Subject: Running the server from today's CVS In-Reply-To: <19990531184347.A1510@localhost> Message-ID: On Mon, 31 May 1999, Aaron Van Couwenberghe wrote: > Ok, I tried to run today's server, and libBerlin still couldn't find > TextKit. Looking at the build tree, the Text directory is still commented > out of SUBDIRS in src/. Ah, so you try to run client. Hmm, right, this one doesn't work. > I'm sure someone already knew about this. When I tried to uncomment > it the other day, I still got the same errors, except the plugin loader > passed right over libText without recognizing it as a plugin. > Just wanted to make sure this didn't get forgotten about ;) Yeah. The TextKit is actually worked on. It will be finished for the next release though (won't it, Graydon ;-) What about client1, client2, grid ? Do they work ? (I'm quite proud on them :) Stefan From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 01:53:22 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:37 2005 Subject: oops, here's the log In-Reply-To: <19990531184741.A1519@localhost> Message-ID: On Mon, 31 May 1999, Aaron Van Couwenberghe wrote: > Here's the log of the failed run: > > * logbuf::dump = [...] > [11.8004:5:loader] GenericFactoryImpl::supports does not support > IDL:omg.org/TextKit:1.0 > [11.8005:5:loader] GenericFactoryImpl::supports interface listing > follows: > [11.8005:5:loader] IDL:omg.org/FigureKit:1.0 > [11.8005:5:loader] IDL:omg.org/LayoutKit:1.0 > [11.8005:5:loader] IDL:omg.org/WidgetKit:1.0 > * end of logbuf::dump there you go. TextKit has not been found. That's quite accurate :-) Stefan PS: therefor, please disregard client1 for the next couple of days. From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 01:57:23 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:37 2005 Subject: plugins and strip In-Reply-To: <19990531184959.A1061@awac.local.net> Message-ID: On Mon, 31 May 1999, Aaron Van Couwenberghe wrote: > > Didn't we discuss this very topic ? Didn't *you* point out that 'strip > > --strip-unneeded' only strips the symbols of internal use ? > > We were talking about shared libraries, which I had stripped of all symbols > more times than I can remember (without any difficulties afterwards). I just > don't know how to deal with plugins where we require symbols to be > present... What is the difference ? Both use the same symbol lookup mechanisms. The only difference is the usage (which is not known from inside the lib). You refer to shared libs when your main program contains symbols referring to the lib (so the linker can identify the dependency at compile time) while the symbol for plugin code might only be known at runtime (as in Berlin, when the client explicitely requests it). From the point of view of the library nothing is different. Stefan From vanco at sonic.net Tue Jun 1 03:42:31 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:37 2005 Subject: hey, it works! Message-ID: <19990531204231.B1061@awac.local.net> sheesh, it works. I must say, a great feat, and much cleaner than before. However, it carries the one distinction that it takes the mouse pointer a whole 30 seconds to catch up with me sometimes ;P Anyway, nice job everyone! I'll begin working on .debs immediately. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From graydon at pobox.com Tue Jun 1 11:34:47 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:27:37 2005 Subject: new clients working here! Message-ID: <19990601073447B.graydon@pobox.com> Hey, just wanted to express big, huge embarassing public congradulations to stefan -- the new set of patches seem to mostly "finish" the huge work he's been doing all winter, and finally make the clients work on my machine, and I have to say it's a beautiful sight. the button popping in and out with the telltale change... *sniff* *sniff*. brings a tear to my eye. Our display server rules! I only wish I could have been of a little more help this past few months, as you've been doing so much work. Anyway, I'll try and put in enough hours to polish off a simple layout measurement for the textKit and finish up the GLPencil enough that we can do curves. Plus I think it's getting about time to start profiling, as it looks remarkably stable (well, it needs a general COMM_FAILURE exception handler to be installed to keep it from falling over when the client disconnects, but that's easy). -graydon From anoq at HardcoreProcessing.com Tue Jun 1 14:39:23 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:27:37 2005 Subject: IRC References: <3752F3B8.CF58B087@magellan.umontreal.ca> Message-ID: <3753F09B.766055E5@HardcoreProcessing.com> Stefan Seefeld wrote: > about two or three weeks ago we tried to schedule an IRC > meeting... My exams are not over until 30. of june :( So no matter when you put the meeting - if it's in june - I'll be busy. But still I'll try to make it if I can... Cheers -- http://www.HardcoreProcessing.com From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 18:08:16 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:37 2005 Subject: shared ressources and input devices Message-ID: <37542190.11C443AD@magellan.umontreal.ca> Hey, I'm thinking of how to implement Focus pointer management. It is a somewhat complex topic and I'm somewhat stuck with the 'use cases', i.e. how I actually want the server to behave. Traditionally, input events are separated into focus and positional. While Focus is always granted to some object, pointer events go to the object 'under' the mouse. There are a couple of difficulties: I avoid calling the object receiving the event by a name. This is because I think these advanced features should *not* go into the Graphic interface, blowing it even further. Instead, I'd like to derive an interface (Controller) for this very purpose. There are a couple of features which are common to focus and positional events, so I'm thinking whether it is possible to generalize it. Notably, with every input device/Controller compination goes a certain set of shared resources (the Raster used to graphically represent the device like 'Pointer', menus, menu bars, tool bars etc.) This could be managed by a Focus object. Every Controller may have a Focus instance (or, it inherits from it's parent). When the Focus is activated ('focus is in the Controller'), current menu, current tool bar etc. could all be set to the values from the current Focus instance. This guarantees nice context switching. A singleton FocusManager in the server would manage a stack of active focuses so one a focus is released it can be given back to the last controller which had it before. So since we already had discussions about context sensitive menus etc. I'd like ask you to list some use cases, i.e. what behavior would you like to see so we can work out how this can be implemented. (Note, that this nicely fits with graphica embedding as for example in OpenDoc or OpenParts (the KDE analogon): once Focus is granted to an embedded application, it controls the current active menu bar, tool bar and what not we decide to install for singleton resources.) One last point. I'd like to remember that we have no idea about what input devices we are connected to. So the design should not depend on any particular knowledge about it. (For example, there is no 'mouse', 'keyboard' etc., yet there are pointer and key events, see Event.idl, but we might have arbitrary numbers of pointer and key devices...) Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From jordy at wserv.com Tue Jun 1 20:48:20 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:27:37 2005 Subject: IRC Schedule Message-ID: <37544714.C4E49375@wserv.com> Ok this seems to suit everyone but Anoq, but since he can't do it in June, he can just read logs :) Tuesday June 8th, 00:00 GMT (8:00 pm EDT, 5:00 pm PDT) Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From jordy at wserv.com Tue Jun 1 21:12:27 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule References: <37544714.C4E49375@wserv.com> Message-ID: <37544CBB.CDABD996@wserv.com> Jordan Mendelson wrote: > > Ok this seems to suit everyone but Anoq, but since he can't do it in June, he > can just read logs :) > > Tuesday June 8th, 00:00 GMT (8:00 pm EDT, 5:00 pm PDT) In case this isn't clear, I mean Tuesday June 8th, 00:00 GMT or Monday 8:00 pm EDT / Monday 5:00 pm PDT. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From lar at ruby.cs.byu.edu Tue Jun 1 22:46:37 1999 From: lar at ruby.cs.byu.edu (Laramie Leavitt) Date: Fri Feb 25 22:27:38 2005 Subject: Files that depend on GGI and MESA Message-ID: I was wondering which files in Berlin depend on GGI, and which depend only on Mesa. I am going to attempt to get berlin working with NT. (no NT flames, I do not have access to a Linux machine or I would try that) From seefelds at MAGELLAN.UMontreal.CA Tue Jun 1 23:27:42 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:38 2005 Subject: Files that depend on GGI and MESA In-Reply-To: Message-ID: On Tue, 1 Jun 1999, Laramie Leavitt wrote: > I was wondering which files in Berlin depend on GGI, and which > depend only on Mesa. I am going to attempt to get berlin working > with NT. (no NT flames, I do not have access to a Linux machine > or I would try that) Hmm, there are some other problems, too. libBerlin now uses OS level stuff from Prague like the DLL and Directory classes, others may follow, notably IPC related stuff like ptybuf and the Thread classes, which are all pthread based. Have a look whether you can easily port DLL and Directory to NT since else you would need to patch libBerlin as well. Concerning GGI/Mesa, GGI is only used in initializing the GLDrawingKit. The rest is done by pure openGL calls. Look through all the Drawing/openGL stuff. Currently there are a couple of openGL calls within the ScreenManager, too. However, they shouldn't be there, it has all to be absorbed by the DrawingKit interfaces... Good luck, Stefan From c98ja1 at dmu.ac.uk Wed Jun 2 13:09:46 1999 From: c98ja1 at dmu.ac.uk (Jonas Andersen) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule In-Reply-To: <37544CBB.CDABD996@wserv.com> Message-ID: On Tue, 1 Jun 1999, Jordan Mendelson wrote: > In case this isn't clear, I mean Tuesday June 8th, 00:00 GMT or Monday 8:00 pm > EDT / Monday 5:00 pm PDT. Could we please have this during the weekend? I have a meeting the following day at 9 am UTC and the guy who owns the appartment where I crash still have to go to work in the morning, so weekdays are rather bad. Cheers, Jonas From jordy at wserv.com Wed Jun 2 14:34:03 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule References: Message-ID: <375540DB.A686C702@wserv.com> Jonas Andersen wrote: > On Tue, 1 Jun 1999, Jordan Mendelson wrote: > > > In case this isn't clear, I mean Tuesday June 8th, 00:00 GMT or Monday 8:00 pm > > EDT / Monday 5:00 pm PDT. > > Could we please have this during the weekend? I have a meeting the > following day at 9 am UTC and the guy who owns the appartment where I > crash still have to go to work in the morning, so weekdays are rather bad. Hmm, alright weekends. Sunday 22:00 GMT (6 pm EDT, 3 pm PDT) alright for everyone? What I need is a big schedule where everyone can mark with an X what time they are free... Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From seefelds at MAGELLAN.UMontreal.CA Wed Jun 2 14:51:58 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule References: <375540DB.A686C702@wserv.com> Message-ID: <3755450E.39713BD9@magellan.umontreal.ca> Jordan Mendelson wrote: > Hmm, alright weekends. Sunday 22:00 GMT (6 pm EDT, 3 pm PDT) alright for everyone? Sunday, 13th of June, 22:00 GMT. Fine. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From seefelds at MAGELLAN.UMontreal.CA Wed Jun 2 15:03:06 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:38 2005 Subject: object reference 'deep equality' Message-ID: <375547AA.E7CBD86C@magellan.umontreal.ca> Hey, as I just discovered there is no simple equality test for object references. How then can I ask whether two refs refer to the same object ? A_var a1, a2; B_var b; /*...*/ if (a1 == a2) /*...*/; This clearly doesn't work since there is no overloaded 'operator == (const A_var &, const A_var &)' or anything like that. So the code doesn't do what I want. How can I do this, I can't find this mentioned on any IDL to C++ mapping documentation I have ? Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From dgrisby at uk.research.att.com Wed Jun 2 15:12:10 1999 From: dgrisby at uk.research.att.com (Duncan Grisby) Date: Fri Feb 25 22:27:38 2005 Subject: object reference 'deep equality' In-Reply-To: Your message of "Wed, 02 Jun 1999 15:03:06 -0000." <375547AA.E7CBD86C@magellan.umontreal.ca> Message-ID: <199906021512.QAA25137@pineapple.cam-orl.co.uk> On Wednesday 2 June, Stefan Seefeld wrote: > as I just discovered there is no simple equality test for > object references. How then can I ask whether two refs > refer to the same object ? > > A_var a1, a2; > B_var b; > /*...*/ if (a1->_is_equivalent(a2)) { ... } will almost always work. If _is_equivalent() returns true, the references are definitely to the same object. It's possible to get an incorrect false return by playing silly games with object keys and location forwarding, but it should work in all genuine situations. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From jvh at danmar.dk Wed Jun 2 16:14:16 1999 From: jvh at danmar.dk (jvh Jan Vittrup Hansen) Date: Fri Feb 25 22:27:38 2005 Subject: Cvs Message-ID: Hi! I just checked berlin_0_0_1 out from CVS, as described on your project home-page - but it seems to me that this is NOT the current development branch - am I right? If so what is the current one - or perhaps better yet (since CVS is quite new to me) you could tell me how one lists the possible branches/labels present in the database. Regards, Jan... From c98ja1 at dmu.ac.uk Wed Jun 2 17:33:02 1999 From: c98ja1 at dmu.ac.uk (Jonas Andersen) Date: Fri Feb 25 22:27:38 2005 Subject: BroadcastGL In-Reply-To: <3755450E.39713BD9@magellan.umontreal.ca> Message-ID: I recent article over at www.opengl.org http://www.opengl.org/News/Special/BGL.html Talks about a OpenGL based Broadcast GL used in consumer devices. Not sure what to make of this, mostly just a requirement specification. Take a look, it could prove interesting. Cheers, Jonas -------------------------------------------------------------- Never ask a geek why, just nod your head and slowly back away. -Rob Malda From seefelds at MAGELLAN.UMontreal.CA Wed Jun 2 17:51:08 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:38 2005 Subject: Cvs References: Message-ID: <37556F0C.9ABDC8C@magellan.umontreal.ca> jvh Jan Vittrup Hansen wrote: > > Hi! > > I just checked berlin_0_0_1 out from CVS, as described on your project > home-page - but it seems to me that this is NOT > the current development branch - am I right? If so what is the current one - > or perhaps better yet > (since CVS is quite new to me) you could tell me how one lists the possible > branches/labels present in the database. if you use simply 'cvs checkout' without the tag (as it is described on the Berlin CVS page) you should get the head branch. Good luck ! Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From vanco at sonic.net Thu Jun 3 01:27:47 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule In-Reply-To: <37544714.C4E49375@wserv.com>; from Jordan Mendelson on Tue, Jun 01, 1999 at 04:48:20PM -0400 References: <37544714.C4E49375@wserv.com> Message-ID: <19990602182747.B1091@awac.local.net> On Tue, Jun 01, 1999 at 04:48:20PM -0400, Jordan Mendelson wrote: > > Ok this seems to suit everyone but Anoq, but since he can't do it in June, he > can just read logs :) > > Tuesday June 8th, 00:00 GMT (8:00 pm EDT, 5:00 pm PDT) I'll have to be 45 min late. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Thu Jun 3 01:28:32 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:38 2005 Subject: IRC Schedule In-Reply-To: <375540DB.A686C702@wserv.com>; from Jordan Mendelson on Wed, Jun 02, 1999 at 10:34:03AM -0400 References: <375540DB.A686C702@wserv.com> Message-ID: <19990602182832.C1091@awac.local.net> On Wed, Jun 02, 1999 at 10:34:03AM -0400, Jordan Mendelson wrote: > Jonas Andersen wrote: > > > On Tue, 1 Jun 1999, Jordan Mendelson wrote: > > > > > In case this isn't clear, I mean Tuesday June 8th, 00:00 GMT or Monday 8:00 pm > > > EDT / Monday 5:00 pm PDT. > > > > Could we please have this during the weekend? I have a meeting the > > following day at 9 am UTC and the guy who owns the appartment where I > > crash still have to go to work in the morning, so weekdays are rather bad. > > Hmm, alright weekends. Sunday 22:00 GMT (6 pm EDT, 3 pm PDT) alright for everyone? > What I need is a big schedule where everyone can mark with an X what time they are > free... Yes, this works fine. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Thu Jun 3 01:29:35 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:38 2005 Subject: Files that depend on GGI and MESA In-Reply-To: ; from Laramie Leavitt on Tue, Jun 01, 1999 at 04:46:37PM -0600 References: Message-ID: <19990602182935.D1091@awac.local.net> On Tue, Jun 01, 1999 at 04:46:37PM -0600, Laramie Leavitt wrote: > > I was wondering which files in Berlin depend on GGI, and which > depend only on Mesa. I am going to attempt to get berlin working > with NT. (no NT flames, I do not have access to a Linux machine > or I would try that) Only the server implementation truly depends on GGI, I believe. test/server.cc being the only one built right now. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From vanco at sonic.net Thu Jun 3 01:41:15 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:38 2005 Subject: shared ressources and input devices In-Reply-To: <37542190.11C443AD@magellan.umontreal.ca>; from Stefan Seefeld on Tue, Jun 01, 1999 at 06:08:16PM +0000 References: <37542190.11C443AD@magellan.umontreal.ca> Message-ID: <19990602184115.E1091@awac.local.net> On Tue, Jun 01, 1999 at 06:08:16PM +0000, Stefan Seefeld wrote: > I avoid calling the object receiving the event by a name. This is > because I think these advanced features should *not* go into the > Graphic interface, blowing it even further. Instead, I'd like to > derive an interface (Controller) for this very purpose. And this IMO should be a plugin provided with moscow. Focus should be a state that's provided for in libBerlin, but that's very rudimentary to say the least (just the knowhow to forward events to the node that has focus, and a basic call to give a node focus). Perhaps, for example, you want to be able to switch focus by making keystrokes similar to the win95 paradigm. What if you wanted the window in focus to be zoomed to fit the screen? This is possible, remember. Sometimes moscow will bring the focused window to the top, sometimes only after a click into the window with focus. All this goes to support its being the first component of Moscow ;) And fairly soon is the time that Berlin will begin to benefit from Registrar being integrated in a reasonable way. All of these abstract event types should be bound to some convention in the API for event classification; in turn the way this classification is defined should be loaded from Registrar so someone can plug in their power glove and run Berlin by executing the GII event binding utility for autoprobing for events to bind to common actions. A bit far fetched, but who needs realism. This is berlin ;) -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From seefelds at MAGELLAN.UMontreal.CA Thu Jun 3 02:18:36 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:38 2005 Subject: Moscow, Was: shared ressources and input devices In-Reply-To: <19990602184115.E1091@awac.local.net> Message-ID: On Wed, 2 Jun 1999, Aaron Van Couwenberghe wrote: > On Tue, Jun 01, 1999 at 06:08:16PM +0000, Stefan Seefeld wrote: > > I avoid calling the object receiving the event by a name. This is > > because I think these advanced features should *not* go into the > > Graphic interface, blowing it even further. Instead, I'd like to > > derive an interface (Controller) for this very purpose. > > And this IMO should be a plugin provided with moscow. Focus should be a > state that's provided for in libBerlin, but that's very rudimentary to say > the least (just the knowhow to forward events to the node that has focus, > and a basic call to give a node focus). I completely agree. Focus management is a strategy so we should use the pattern which is called after it, i.e. delegate the algorithm (applied policies for example) out into a configurable unit. What I have in mind, is to give every Controller the possibility to set context information if it receives focus. For example every Controller has an interface like interface Controller { Focus grantFocus(); }; where the returned Focus object contains all the server needs to know to update the context (tools, menus, pointer image etc.). However, the Focus is more like a hint and the server doesn't need to make any promizes about whether all the shared resources requested will really be installed. More like layout: 'tell me what you want and I tell you what you get'. > Perhaps, for example, you want to be able to switch focus by making > keystrokes similar to the win95 paradigm. What if you wanted the window in > focus to be zoomed to fit the screen? This is possible, remember. Sometimes > moscow will bring the focused window to the top, sometimes only after a > click into the window with focus. All this goes to support its being the > first component of Moscow ;) > > And fairly soon is the time that Berlin will begin to benefit from > Registrar being integrated in a reasonable way. All of these abstract event > types should be bound to some convention in the API for event > classification; in turn the way this classification is defined should be > loaded from Registrar so someone can plug in their power glove and run > Berlin by executing the GII event binding utility for autoprobing for events > to bind to common actions. Good point. We should by all means avoid to call input devices by their names (remember the thread ? ;-) However, we should be prepared to handle whatever input devices are connected. This implies abstraction of Focus and similar objects to hold ressources for every device, like sequence but hopefully a bit more statically typed... > A bit far fetched, but who needs realism. This is berlin ;) Indeed. And, while we are at Moscow, I had a look into OpenDoc, KOM and OpenPart (KDE). I think one major step will be the implementation of the CORBA Trading Service. With this, we can register lightweight applications so they can be glued (as 'Parts') together to implement a real document centric desktop. The key design, graphical embedding, is already in place. You only need to put a whole application (the 'Part') as a node into the local scene graph of another application (the 'Document'). Doesn't this look promizing ?! Regards, Stefan From vanco at sonic.net Thu Jun 3 02:36:17 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:38 2005 Subject: Moscow, Was: shared ressources and input devices In-Reply-To: ; from Seefeld Stefan on Wed, Jun 02, 1999 at 10:18:36PM -0400 References: <19990602184115.E1091@awac.local.net> Message-ID: <19990602193617.G1091@awac.local.net> On Wed, Jun 02, 1999 at 10:18:36PM -0400, Seefeld Stefan wrote: > Indeed. And, while we are at Moscow, I had a look into OpenDoc, KOM and > OpenPart (KDE). I think one major step will be the implementation of the > CORBA Trading Service. With this, we can register lightweight applications > so they can be glued (as 'Parts') together to implement a real document > centric desktop. The key design, graphical embedding, is already in place. > You only need to put a whole application (the 'Part') as a node into the > local scene graph of another application (the 'Document'). > > Doesn't this look promizing ?! Definately. I began looking into the possibilities for abstracting data container handles and data chunk streams, and attatching appropriate metadata to both streams and applications so the two can be matched up at runtime, independent of the location of each or the display they're being used from. This was some time ago, so things may have changed. The best way to do this is with trader, but eh, there is no free orb from wich we can rip an implementation and port to omni. Gah. Do we have a corba prodigy about? The cool thing about this, is, if using an embedding/focus API for editors and viewers similar to the one in KOffice, we could arbitrarily embed datatypes within one another and in turn do editing from our terminal without caring what viewer or editor we're using! Magic. But this would be a *really really* hard beast to capture and tame. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From seefelds at MAGELLAN.UMontreal.CA Thu Jun 3 03:03:28 1999 From: seefelds at MAGELLAN.UMontreal.CA (Seefeld Stefan) Date: Fri Feb 25 22:27:38 2005 Subject: Moscow, Was: shared ressources and input devices In-Reply-To: <19990602193617.G1091@awac.local.net> Message-ID: On Wed, 2 Jun 1999, Aaron Van Couwenberghe wrote: > On Wed, Jun 02, 1999 at 10:18:36PM -0400, Seefeld Stefan wrote: > > Indeed. And, while we are at Moscow, I had a look into OpenDoc, KOM and > > OpenPart (KDE). I think one major step will be the implementation of the > > CORBA Trading Service. With this, we can register lightweight applications > > so they can be glued (as 'Parts') together to implement a real document > > centric desktop. The key design, graphical embedding, is already in place. > > You only need to put a whole application (the 'Part') as a node into the > > local scene graph of another application (the 'Document'). > > > > Doesn't this look promizing ?! > > Definately. I began looking into the possibilities for abstracting data > container handles and data chunk streams, and attatching appropriate > metadata to both streams and applications so the two can be matched up at > runtime, independent of the location of each or the display they're being > used from. This was some time ago, so things may have changed. > The best way to do this is with trader, but eh, there is no free orb > from wich we can rip an implementation and port to omni. Gah. Do we have a > corba prodigy about? KDE has a trader implementation. We can use this as long as we have no other. The IDL looks standard conformant. I once read on the omniORB ML that someone proposed to write the Trading service, I've no idea about the current status though. > The cool thing about this, is, if using an embedding/focus API for editors > and viewers similar to the one in KOffice, we could arbitrarily embed > datatypes within one another and in turn do editing from our terminal > without caring what viewer or editor we're using! Magic. Exactly. No need for OS like applications. As much as I like emacs, I'd be happy to change it against a bunch of smaller applets which all happily work together. Similar for Netscape. Welcome back in Unix land, where little tools are glued together to create customized large applications. > But this would be a *really really* hard beast to capture and tame. Well, just a couple of interfaces away :) I'm looking forward to work on them ! Stefan PS: as a little preview, compile and run Fresco's fdraw example program. It's a bit buggy but you get the idea. From mikevdg at xtra.co.nz Thu Jun 3 09:38:19 1999 From: mikevdg at xtra.co.nz (Michael Van der Gulik) Date: Fri Feb 25 22:27:38 2005 Subject: Controllers and Focus In-Reply-To: Message-ID: > What I have in mind, is to give every Controller the possibility to set > context information if it receives focus. For example every Controller > has an interface like > > interface Controller > { > Focus grantFocus(); > }; > > where the returned Focus object contains all the server needs to know > to update the context (tools, menus, pointer image etc.). However, the > Focus is more like a hint and the server doesn't need to make any promizes > about whether all the shared resources requested will really be installed. > More like layout: 'tell me what you want and I tell you what you get'. I didn't quite understand all that.. so.. Correct me: A Controller is an input device on the user's environment (mouse, keyboard, joystick, power glove, eye tracker, voice (?), hands-on-touch-screen...). For each unary controller, there can be one focus. What about multiple focii for a single controller (e.g. putting many fingers on a touch screen?). A 'Focus' object is a pointer to a widget on the screen, be it a pixel, button, floating thingy, window or background, and it is determined by a controller? A widget keeps track of the focuses it has (linked list?) and focuses can arrive and depart, with the widget reacting accordingly? You are saying that the 'Focus' object needs to store all information that widget needs to react? Certainly that would depend on the implementation of that widget, not the focus. - btw, what sort of controllers work with berlin yet? Obviously the mouse is tracking (at a staggaring 2 frames a minute), but what about the keyboard? From seefelds at MAGELLAN.UMontreal.CA Thu Jun 3 13:35:14 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:38 2005 Subject: Controllers and Focus References: Message-ID: <37568492.486C5AAD@magellan.umontreal.ca> Michael Van der Gulik wrote: > > > What I have in mind, is to give every Controller the possibility to set > > context information if it receives focus. For example every Controller > > has an interface like > > > > interface Controller > > { > > Focus grantFocus(); > > }; > > > > where the returned Focus object contains all the server needs to know > > to update the context (tools, menus, pointer image etc.). However, the > > Focus is more like a hint and the server doesn't need to make any promizes > > about whether all the shared resources requested will really be installed. > > More like layout: 'tell me what you want and I tell you what you get'. > > I didn't quite understand all that.. so.. > > Correct me: > > A Controller is an input device on the user's environment (mouse, > keyboard, joystick, power glove, eye tracker, voice (?), > hands-on-touch-screen...). For each unary controller, there can be one > focus. What about multiple focii for a single controller (e.g. putting > many fingers on a touch screen?). The scene graph is defined to be composed out of Graphic objects. They define the interface to handle scene graphs. Now you want to *interact* with it. You want parts of it to receive input events which eventually change the state of a subject. I used the MVC paradigm (Model View Controller) to express this. I refer to the Model as the ensemble of subjects presented by the application. Views are observers attached to the subjects and Controllers are the means to modify the subjects. Clearly, Views and Controllers *are* Graphics in that they are just nodes of the scene graph. > A 'Focus' object is a pointer to a widget on the screen, be it a pixel, > button, floating thingy, window or background, and it is determined by a > controller? A widget keeps track of the focuses it has (linked list?) and > focuses can arrive and depart, with the widget reacting accordingly? traditionally we say that a widget *has* focus if it is the receiver of input events (with respect to a certain input device). I proposed a Focus object which corresponds roughly to the layout related Requisition. Every Controller holds such an object (or at least you can query it from every controller, even if the controller will take the parent's one). Once the FocusManager grants focus to a Controller, it takes the respective Focus object and installs all the shared resources found in there (well, it doesn't need to if there are conflicts but that's the general idea). This is what gives us context switching if you move the focus on to another controller. > You are saying that the 'Focus' object needs to store all information that > widget needs to react? Certainly that would depend on the implementation > of that widget, not the focus. Sure, the controller will be sort of a factory for the Focus in that it installs what shared ressources it wants to. Focus is just the factored out interface for the FocusManager (the server) to access these. > btw, what sort of controllers work with berlin yet? Obviously the mouse is > tracking (at a staggaring 2 frames a minute), but what about the keyboard? Ok, you are referring to input devices here. Hmm, right now, all input events are placed into a PickTraversal. Actually only positional events are treated since only for them a simple approach without focus can work (simply determine what Graphic is placed directly under the pointer and forward the event to it). Once we have focus management we can forward non positional events too. Basically we can handle all input devices GII knows to deal with since we only receive events. Still a word about controllers. Since we are working in a heavily structured graphics world I think Controllers should really be atomic in that they represent the elementary unit of widgets. Indeed, widgets shouldn't exist as full interfaces, rather they are arbitrary subtrees of the scene graph. They promize to act on subjects and they do so in connecting the controllers they are composed of to individual subject methods. For example a horizontal Slider would typically be implemented as follows: HBox / | \ / | \ LC Overlay RC / \ Channel Elevator LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: LC (click): bv->begin(); RC (click): bv->end(); Elevator (drag): bv->set(...); Channel (click): bv->set(...); The above structure is arbitrary. That is, you may want to implement a completely different widget which also controlls a BoundedValue. And, you may want to change one against another. Thats why we can't hard wire it. The 'theming' which is currently quite 'en vogue' among popular widget toolkits like gtk etc. is just a little piece of the cake. If we do it the way I just outlined, we have every freedom to experiment with other widget styles (which can then be loaded from the WidgetKit). Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From jordy at wserv.com Thu Jun 3 16:24:00 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:27:38 2005 Subject: Final IRC Schedule References: <375540DB.A686C702@wserv.com> <19990602182832.C1091@awac.local.net> Message-ID: <3756AC20.55A36F19@wserv.com> Just to clarify there will be a meeting on: Sunday, June 6th at 22:00 GMT, 6 pm EDT, 3 pm PDT. If there is a problem for anyone, say so now. I'll send out one more message an hour or so before the meeting. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From graydon at pobox.com Thu Jun 3 17:29:40 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:27:38 2005 Subject: Final IRC Schedule In-Reply-To: Your message of "Thu, 03 Jun 1999 12:24:00 -0400" <3756AC20.55A36F19@wserv.com> References: <3756AC20.55A36F19@wserv.com> Message-ID: <19990603132940W.graydon@pobox.com> > Sunday, June 6th at 22:00 GMT, 6 pm EDT, 3 pm PDT. > > If there is a problem for anyone, say so now. I'll send out one more message an > hour or so before the meeting. Aigh! that's when my birthday party is scheduled for.. oh for the love of calendaring software! this is rediculous. OK. here's what's gonna happen. I just made an egroup for us, it has a *shared calendar* feature. pretty snappy eh? so everyone go over there and mark off times which are no good for them. step 1: go here http://www.egroups.com/group/berlin-dev/ step 2: join the group step 3: switch to the calendar page step 4: mark off the times which are no-good for you make sure to (a) not mail the group about it, (b) not send reminders. this is just using the calendaring tool for getting everything down on paper (so to speak). The service is a little slow and tends to lock up occasionally for a minute or two, I guess they're having scalability problems. anyway give it a shot and see if that helps us clear things up. stefan and I are both sorta leaning towards the 13th, but lets just get everyone's requirements down on the calendar and see if something presents itself. -graydon From alaint at cgocable.ca Thu Jun 3 17:55:18 1999 From: alaint at cgocable.ca (Alain Toussaint) Date: Fri Feb 25 22:27:38 2005 Subject: Final IRC Schedule References: <3756AC20.55A36F19@wserv.com> <19990603132940W.graydon@pobox.com> Message-ID: <3756C185.AAF5CC27@cgocable.ca> > step 2: join the group > step 3: switch to the calendar page > step 4: mark off the times which are no-good for you done,please check that i hadn't messed up the configuration of the thing (esp the timezone as i tried to set it and wasn't sure if it was for me or the entire group). Alain From alaint at cgocable.ca Thu Jun 3 19:06:59 1999 From: alaint at cgocable.ca (Alain Toussaint) Date: Fri Feb 25 22:27:38 2005 Subject: [Fwd: Re: Final IRC Schedule] Message-ID: <3756D253.C47482A@cgocable.ca> double d'oh...was meant to be sent on the list -------- Original Message -------- Subject: Re: Final IRC Schedule Date: Thu, 03 Jun 1999 15:05:26 -0400 From: Alain Toussaint To: Graydon Hoare References: <3756C185.AAF5CC27@cgocable.ca> <19990603145212M.graydon@pobox.com> > I think you didn't join the group, but instead were editing your > personal calendar. you're not presently in the group, and there's no > extra entries in the group calendar. > > -graydon d'oh....i tried to get access back at the website and lost my way,look like i'll have to dedicace a few hours to it this evening... Alain Toussaint From jordy at wserv.com Thu Jun 3 21:07:53 1999 From: jordy at wserv.com (Jordan Mendelson) Date: Fri Feb 25 22:27:38 2005 Subject: Final IRC Schedule References: <3756AC20.55A36F19@wserv.com> <19990603132940W.graydon@pobox.com> Message-ID: <3756EEA9.D2994EB0@wserv.com> Graydon Hoare wrote: > Aigh! that's when my birthday party is scheduled for.. Well happy birthday. > oh for the love of calendaring software! this is > rediculous. OK. here's what's gonna happen. I just made an egroup for > us, it has a *shared calendar* feature. pretty snappy eh? so everyone > go over there and mark off times which are no good for them. This calender has a really nice feature of being able to schedule recurring events, so those of you in the UK who can only get on the internet at certain times, schedule a recurring event for the time you can't get online. I actually scheduled the time I'm not awake and it looks like it worked just fine, the only problem is the daily view doesn't show the time span of the event, so we'll have to manually figure out when everyone is free. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From mikevdg at xtra.co.nz Fri Jun 4 11:04:15 1999 From: mikevdg at xtra.co.nz (Michael Van der Gulik) Date: Fri Feb 25 22:27:38 2005 Subject: Controllers and Focus In-Reply-To: <37568492.486C5AAD@magellan.umontreal.ca> Message-ID: On Thu, 3 Jun 1999, Stefan Seefeld wrote: > world I think Controllers should really be atomic in that they represent the elementary > unit of widgets. Indeed, widgets shouldn't exist as full interfaces, rather they are > arbitrary subtrees of the scene graph. They promize to act on subjects and they do so > in connecting the controllers they are composed of to individual subject methods. > For example a horizontal Slider would typically be implemented as follows: I'm not fully understanding all those big words. I'll just go read source-code and books now. (don't bother explaining.. I'll get it sometime later tonight). > HBox > / | \ > / | \ > LC Overlay RC > / \ > Channel Elevator > > LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: > > LC (click): bv->begin(); > RC (click): bv->end(); > Elevator (drag): bv->set(...); > Channel (click): bv->set(...); I assume, for example, LC is the controller for the button at one end of the Slider, RC is the controller for the button at the other end (depending if the Slider is horizontal, vertical or something else), Elevator is a controller that gets used, and Channel is that annoying page up / page down thing that happens when you click anywhere else on the Slider. The HBox is a space on the screen? What is the Overlay? I assume this slider would be used in dialogues.. would you inherit a scrollbar from it (or perhaps they have a common parent)? Hmm.. so could you do a quick ascii-art event-flow diagram from the input queue/mechanism/whatever to bv (the BoundedValue of the Slider widget) to show which classes are used.. Also, is BoundedValue related to the Slider by aggregation or association. I'm hoping I sound half-intelligent. In lay-mans terms, is the Bounded Value 'inside' or 'part of' the widget, or is it an external instance created by another object (a factory) in the system? From Massimiliano.Mantione at italtel.it Fri Jun 4 10:54:57 1999 From: Massimiliano.Mantione at italtel.it (Massimiliano Mantione) Date: Fri Feb 25 22:27:38 2005 Subject: Warsaw interfaces? [was: Re: Controllers and Focus] References: <37568492.486C5AAD@magellan.umontreal.ca> Message-ID: <3757B081.3CBA4B40@italtel.it> Stefan Seefeld wrote: > > Still a word about controllers. Since we are working in a heavily structured graphics > world I think Controllers should really be atomic in that they represent the elementary > unit of widgets. Indeed, widgets shouldn't exist as full interfaces, rather they are > arbitrary subtrees of the scene graph. They promize to act on subjects and they do so > in connecting the controllers they are composed of to individual subject methods. > For example a horizontal Slider would typically be implemented as follows: > > HBox > / | \ > / | \ > LC Overlay RC > / \ > Channel Elevator > > LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: > > LC (click): bv->begin(); > RC (click): bv->end(); > Elevator (drag): bv->set(...); > Channel (click): bv->set(...); There is a single point I do not agree with, it is when you say "widgets shouldn't exist as full interfaces". IMHO, they should, and this set of interfaces should be the Warsaw interface. Different Warsaw implementations could provide different widger styles, but I think widgets (to be really interchangeable) should offer precise interfaces. So, I think that at some point in time somebody will in fact write a generic interface for a "horizontal slider". > The above structure is arbitrary. That is, you may want to implement a completely different > widget which also controlls a BoundedValue. And, you may want to change one against another. > Thats why we can't hard wire it. The 'theming' which is currently quite 'en vogue' among > popular widget toolkits like gtk etc. is just a little piece of the cake. If we do it the > way I just outlined, we have every freedom to experiment with other widget styles > (which can then be loaded from the WidgetKit). I agree, this is really a key point. Perhaps the "horizontal slider" Warsaw interface should be exactly a "bounded value" interface. I really agree that a widget and an "active document" are exactly the same thing, both present contents and dispatch events to that content. Widgets are generally "smaller" than documents, they are often reused (in fact they are reusable software components), but I agree that it is better to implement them as a tree of graphics cleverly interconnected rather than hard code their functionality. Anyway, at some level they should provide a particular interface. Perhaps the problem with the current GUI toolkits is that their interfaces are too complex, and too mixed with the particular "visual style" of the toolkit. Instead, if I need an "horizontal slider" it is because I mean the user should "control" a "bounded value", and this is what matters for the logic of my application. I do *NOT* care how the slider looks like, how many different event kinds it can handle or generate... I simply want to give the user a way to control a bounded value! The result of these toughts is that probably the Warsaw interfaces should not be designed as "widget interfaces", but as generic "model interfaces". In a GUI application, the programmer gives the user a way to manipulate a model in a visual way. In this list we often see that "visual" is not the only paradigm to control something, and Berlin should also work with different media types. Probably, we should see "applications" as "model implementations", and user interfaces as "tools to work on models". So, to make things easier, GUI toolkits and "models" should have "compatible" interfaces, so that an application programmer can focus on the model logic first (which is the application core), and then build a GUI simply by saying "the user should control this and that". If the GUI elements (the widgets) have exactly the same interface of the models (but "inverted", so that event sources can be plugged into event listeners), GUI programming gets very easy. Just random toughts, hope this can be useful... Ciao, Massimiliano P.S. Actually, I am still investigating the "event driven" programming paradigm, in contrast with the "imperative" and the "functional" one. For now, it seems to me that handling "parameters" as "events" makes life much easier in designing generic "interconnectable" software components. I am also trying to turn this idea into a sort of very generic programming language, but this work is still in a "high level specification stage" so unfortunately it cannot be useful to Berlin (yet). As widgets will be a "net of interconnected active components", having such a notation could be handy to send widget implementations to a server... I know this sounds confusing, but I hope it makes sense at least to some of you. From seefelds at MAGELLAN.UMontreal.CA Fri Jun 4 12:45:54 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:38 2005 Subject: Controllers and Focus References: Message-ID: <3757CA82.5D22CA5C@magellan.umontreal.ca> Michael Van der Gulik wrote: > > HBox > > / | \ > > / | \ > > LC Overlay RC > > / \ > > Channel Elevator > > > > LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: > > > > LC (click): bv->begin(); > > RC (click): bv->end(); > > Elevator (drag): bv->set(...); > > Channel (click): bv->set(...); > > I assume, for example, LC is the controller for the button at one end of > the Slider, RC is the controller for the button at the other end > (depending if the Slider is horizontal, vertical or something else), > Elevator is a controller that gets used, and Channel is that annoying page > up / page down thing that happens when you click anywhere else on the > Slider. Yep. > The HBox is a space on the screen? What is the Overlay? Overlay is the container of both, the Channel and the Elevator (they are 'overlayed'). It has to adjust the alignment of the elevator as a function of the subject's value (the visual feedback for the current position). > I assume this slider would be used in dialogues.. would you inherit a > scrollbar from it (or perhaps they have a common parent)? I think they have not. Scrollbars act on BoundedRanges, Sliders on BoundedValues (you see the difference in some Scrollbars if they show the 'subrange', something a slider can never do because the subrange is 0. Beside that, you can't inherit a slider since the slider as such is not a class. It is a subtree of the scene graph which is constructed by some factory (such as the WidgetKit). The power of this is that you can come up with a slider whose structure is completely different. All you know is it happens to controll the BoundedValue... > Hmm.. so could you do a quick ascii-art event-flow diagram from the input > queue/mechanism/whatever to bv (the BoundedValue of the Slider widget) to > show which classes are used.. Well, I can't show more than is shown above. The individual controllers of the slider will receive events. On the appropriate events they call the method I wrote down. > Also, is BoundedValue related to the Slider by aggregation or association. > I'm hoping I sound half-intelligent. In lay-mans terms, is the Bounded > Value 'inside' or 'part of' the widget, or is it an external instance > created by another object (a factory) in the system? It's always an external instance. This is necessary since you may want to controll the same subject by different widgets at the same time (same for views, you should be able to observe it from everywhere). So the idea is to instantiate such a subject from the WidgetKit and attach as many controllers and views as you like to it. Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From anoq at HardcoreProcessing.com Fri Jun 4 14:33:59 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:27:38 2005 Subject: Architecture rambling (was: Controllers and Focus) References: Message-ID: <3757E3D7.2058843E@HardcoreProcessing.com> Hello! Pardon me for jumping in - I've not had much time to follow this discussion for a long time, but this is starting to look very much like what I believe to be the ultimate GUI architecture in ML Abstract UI too (which is now being completely redesigned): Michael Van der Gulik wrote: > > HBox > > / | \ > > / | \ > > LC Overlay RC > > / \ > > Channel Elevator > > > > LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: > > > > LC (click): bv->begin(); > > RC (click): bv->end(); > > Elevator (drag): bv->set(...); > > Channel (click): bv->set(...); > > I assume, for example, LC is the controller for the button at one end of > the Slider, RC is the controller for the button at the other end > (depending if the Slider is horizontal, vertical or something else), > Elevator is a controller that gets used, and Channel is that annoying page > up / page down thing that happens when you click anywhere else on the > Slider. What I've got now in ML: I have created a "hierarchially attributed directed hypergraph" which seems ultimate both for a GUI "graph" and for a graph in a 3D-graphics application. It consists of: 1) Nodes (which represents GUI controls) 2) Each node has a hierarchy of attributes 3) Each node also has a list of output connections and a list of reverse connections (i.e. they are connected _from_ an output connection of another node to be able to traverse the graph backwards). 4) Each attribute is really a protocol (an interface) with an associated name (like "color" or "textlines") So nodes (= GUI controls) are controlled by a hierarchy of different protocols (the attributes). --- After reading the above I'm already considering to remove the attributes so that the graph will consist only of: 1) Nodes (which no longer necessarily represents an entire GUI control) 2) Each node now is really a protocol (an interface) with an associated name (like "color" or even "button53" for the general higher level nodes) 3) Each node has a list of output connections and reverse connections as before. This will make it all both more simple but also more flexible / powerful. Now this can also solve your previous discussion about whether GUI controls should exists as complete interfaces: If one node represents the bounded value you talked about, it's children could represent the actual detailed implementation in the current GUI L&F. So the bounded value node might have an interface like: void setMaxBound(int value); int getMaxBound(void); void setMinBound(int value); int getMinBound(void); void setValue(int value); int getValue(void); More "abstract" applications could just use this and be satisfied with it. Other more specific applications could explore the graph further by following the graph to it's children and discover that the control actually consists of (among other things) the 2 buttons at the end. Such an application may decide that one of the buttons has to be red (for whatever reason). Also notice: Many GUI controls are so complex that they will require multiple nodes to control them. I can't help thinking about Lego here: If you make a set of small/simple building blocks which are general enough, it enables you to build virtually anything by combining them. It also looks a little like an abstract syntax- tree of a programming language. The nodes are "functions". The children of a node is it's implementation. Anyway - I hope this rambling is useful. I plan to write up whatever design I may come up with in ML as IDL interfaces. But I'm not doing it until I'm absolutely sure about how things should be... but sometime during or after the summer (hopefully)... Cheers -- http://www.HardcoreProcessing.com From seefelds at MAGELLAN.UMontreal.CA Fri Jun 4 15:24:37 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: Architecture rambling (was: Controllers and Focus) References: <3757E3D7.2058843E@HardcoreProcessing.com> Message-ID: <3757EFB5.1BF5C9E6@magellan.umontreal.ca> ANOQ of the Sun wrote: > I have created a "hierarchially attributed > directed hypergraph" > which seems ultimate both for a GUI "graph" and for > a graph in a 3D-graphics application. Yeah, I think our polymorphic scene graph including views and controllers is an ideal starting point for both GUIs and 3D scenes. In fact, we have unified both into one here. > It consists of: > 1) Nodes (which represents GUI controls) > 2) Each node has a hierarchy of attributes > 3) Each node also has a list of output connections > and a list of reverse connections (i.e. they > are connected _from_ an output connection of > another node to be able to traverse the > graph backwards). > 4) Each attribute is really a protocol (an interface) > with an associated name (like "color" or "textlines") > > So nodes (= GUI controls) are controlled by a hierarchy > of different protocols (the attributes). > > --- > > After reading the above I'm already considering to > remove the attributes so that the graph will consist > only of: > > 1) Nodes (which no longer necessarily represents an > entire GUI control) > 2) Each node now is really a protocol (an interface) > with an associated name (like "color" or even "button53" > for the general higher level nodes) > 3) Each node has a list of output connections and > reverse connections as before. Hmm, I'm not sure what the protocol should be for. In my proposed case you have Controllers manipulating Subjects and Views observing Subjects. This should be sufficient. All the rest of what you probably ment by protocol are semantic interpretations and connections between the subjects. Telltales for example can be constrained. A Menu for example will only allow one item to be selected at a time, so it would best be modeled in terms of Menu::Items being Controllers (which are Telltales, too) which are connected to an ExclusiveConstraint sitting in the Menu itself. Or take the slider example I gave. Just create individual connections between controllers and one or more subjects. The *whole* will then turn out to be a widget of some sort. > This will make it all both more simple but also more > flexible / powerful. Now this can also solve > your previous discussion about whether GUI controls > should exists as complete interfaces: > If one node represents the bounded value you > talked about, it's children could represent > the actual detailed implementation in the > current GUI L&F. So the bounded > value node might have an interface like: > > void setMaxBound(int value); > int getMaxBound(void); > void setMinBound(int value); > int getMinBound(void); > void setValue(int value); > int getValue(void); But why ? What does this interface add ? Remember, you already have the subject itself supporting the above interface. The application shouldn't be concerned about anything but the ensemble of subjects. (It should ask the WidgetKit to link some widget to them though but that's quite fuzzy). On the contratary, I could imagine a client as being two things: * the application which does nothing but expose a set of subjects to the server. * a XML script which is interpreted by the server, telling it to construct a specific interface connecting to the subjects from the client. This boils down to nowadays X applications which ship with app-default files. Now, making the separation of model and controller/view (GUI) really radical, we gain a lot of power. Anyway, that is just one possible way of writing clients for berlin. > More "abstract" applications could just > use this and be satisfied with it. > Other more specific applications > could explore the graph further by > following the graph to it's children > and discover that the control actually > consists of (among other things) the 2 > buttons at the end. Such an application > may decide that one of the buttons > has to be red (for whatever reason). Yep. Part of the app-default equivalent. To be stored persistently in the registrar. > Also notice: Many GUI controls are so > complex that they will require multiple > nodes to control them. Sure (assuming that your 'nodes' correspond to my 'controllers'). In fact, most will. Buttons are really simple. > I can't help thinking about Lego here: > If you make a set of small/simple building > blocks which are general enough, it enables you > to build virtually anything by combining them. Right, that's the idea behind it, all structured graphics. > It also looks a little like an abstract syntax- > tree of a programming language. The nodes are > "functions". The children of a node is it's > implementation. Hmm, not really. nodes are functions in that they are polymorphic. You can place whatever node you want. That's mostly the decorator pattern. You change the behavior of the wrapped node. Some nodes will do that visually (Frames for example put the inner node into a bevel or highlight frame etc.), others change some behavior like the DebugGraphic which reports every traversal passing through it. By the way, these examples are litterally from the 'Design Patterns' book, which uses InterViews/Fresco to illustrate it's point. May be the second edition should consider using Berlin to illustrate some points :-) > Anyway - I hope this rambling is useful. I plan > to write up whatever design I may come up with in > ML as IDL interfaces. But I'm not doing it > until I'm absolutely sure about how things should > be... but sometime during or after the summer > (hopefully)... By the way, are you still working on DOM ? Looking onto the 'Mnemonic Project' (a web browser among others) I find useful functionality as XML parsing and translating into a DOM tree. I think we should consider how to use your DOM stuff inside Berlin shortly, will you be on board ? Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From seefelds at MAGELLAN.UMontreal.CA Fri Jun 4 15:39:58 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: Warsaw interfaces? [was: Re: Controllers and Focus] References: <37568492.486C5AAD@magellan.umontreal.ca> <3757B081.3CBA4B40@italtel.it> Message-ID: <3757F34E.E666FD51@magellan.umontreal.ca> Massimiliano Mantione wrote: > > Stefan Seefeld wrote: > > > > Still a word about controllers. Since we are working in a heavily structured graphics > > world I think Controllers should really be atomic in that they represent the elementary > > unit of widgets. Indeed, widgets shouldn't exist as full interfaces, rather they are > > arbitrary subtrees of the scene graph. They promize to act on subjects and they do so > > in connecting the controllers they are composed of to individual subject methods. > > For example a horizontal Slider would typically be implemented as follows: > > > > HBox > > / | \ > > / | \ > > LC Overlay RC > > / \ > > Channel Elevator > > > > LC, RC, Channel and Elevator are Controllers. They do the following on a BoundedValue bv: > > > > LC (click): bv->begin(); > > RC (click): bv->end(); > > Elevator (drag): bv->set(...); > > Channel (click): bv->set(...); > > There is a single point I do not agree with, it is when you > say "widgets shouldn't exist as full interfaces". > IMHO, they should, and this set of interfaces should be the > Warsaw interface. Different Warsaw implementations could > provide different widger styles, but I think widgets (to be > really interchangeable) should offer precise interfaces. > > So, I think that at some point in time somebody will in fact > write a generic interface for a "horizontal slider". Ok. Forget about the visual presentation of your application for a moment. You only have a value within a given range. Why not simply expose this 'bounded value' *as such* to the interface part ? Why would you want to hard wire anything more than this ? Sliders needn't be horizontal or vertical. May be someone comes up with some spin or something. It has the exact same functionality (to manipulate a BoundedValue). If you restrain your program only to work with horizontal sliders, you'll never be able to see a spin plugged in. > > The above structure is arbitrary. That is, you may want to implement a completely different > > widget which also controlls a BoundedValue. And, you may want to change one against another. > > Thats why we can't hard wire it. The 'theming' which is currently quite 'en vogue' among > > popular widget toolkits like gtk etc. is just a little piece of the cake. If we do it the > > way I just outlined, we have every freedom to experiment with other widget styles > > (which can then be loaded from the WidgetKit). > > I agree, this is really a key point. > Perhaps the "horizontal slider" Warsaw interface should be > exactly a "bounded value" interface. I really agree that a > widget and an "active document" are exactly the same thing, > both present contents and dispatch events to that content. The key point is really the separation of the 'content' and the 'presentation'. In fact that's all about MCV. To separate the notions of subject, view, controller doesn't imply that there can't be an object being a controller and a subject at the same time. I mean, you could well design a Document class which *is* a View *and* a Subject or so. But I won't force anybody to always use these notions in conjunction. (because there is a many to many relationship involved, subjects can be observed by many views, views can observe many subjects, controllers can control many subjects. > Widgets are generally "smaller" than documents, they are > often reused (in fact they are reusable software components), > but I agree that it is better to implement them as a tree of > graphics cleverly interconnected rather than hard code their > functionality. Anyway, at some level they should provide > a particular interface. Perhaps the problem with the current > GUI toolkits is that their interfaces are too complex, and > too mixed with the particular "visual style" of the toolkit. The interfaces are too large in that they don't factor out individual units. See the 'Interface Segregation Principle'. > Instead, if I need an "horizontal slider" it is because I mean > the user should "control" a "bounded value", and this is what > matters for the logic of my application. I do *NOT* care how > the slider looks like, how many different event kinds it can > handle or generate... I simply want to give the user a way to > control a bounded value! Exactly. Then you shouldn't care about the slider's interface but about the BoundedValue's. It's the idea of a factory which takes the subject and builds a widget around it. Traditionally you would take a widget and temporarily *extract* the subject (query the widget's state). > The result of these toughts is that probably the Warsaw > interfaces should not be designed as "widget interfaces", but > as generic "model interfaces". Youp. That's the ensemble of subject's we have. BoundedValue, BoundedRange, Telltale, TextBuffer etc. > In a GUI application, the > programmer gives the user a way to manipulate a model in a > visual way. In this list we often see that "visual" is not > the only paradigm to control something, and Berlin should > also work with different media types. Probably, we should > see "applications" as "model implementations", and user > interfaces as "tools to work on models". So, to make things > easier, GUI toolkits and "models" should have "compatible" > interfaces, so that an application programmer can focus on > the model logic first (which is the application core), and > then build a GUI simply by saying "the user should control > this and that". If the GUI elements (the widgets) have exactly > the same interface of the models (but "inverted", so that > event sources can be plugged into event listeners), GUI > programming gets very easy. > > Just random toughts, hope this can be useful... Yeah, good points ! Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From seefelds at MAGELLAN.UMontreal.CA Fri Jun 4 16:38:15 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: Final IRC Schedule References: <3756AC20.55A36F19@wserv.com> <19990603132940W.graydon@pobox.com> Message-ID: <375800F7.2E65E426@magellan.umontreal.ca> It looks like if we continue in this pace we will schedule the meeting for spring 2000 :( So while the calendar is quietly filling up, may I come back to my earlier proposition that we have the meeting exactly one week later than Jordan proposed, i.e. Sunday, 13th of June, 22:00 GMT Nobody seemed to object to that. If there are any problems, please cry loud. If not, just let's do it. Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From anoq at HardcoreProcessing.com Sat Jun 5 11:11:38 1999 From: anoq at HardcoreProcessing.com (ANOQ of the Sun) Date: Fri Feb 25 22:27:39 2005 Subject: Architecture rambling (was: Controllers and Focus) References: <3757E3D7.2058843E@HardcoreProcessing.com> <3757EFB5.1BF5C9E6@magellan.umontreal.ca> Message-ID: <375905EA.2794CBEB@HardcoreProcessing.com> Stefan Seefeld wrote: > Hmm, I'm not sure what the protocol should be for. In > my proposed case you have Controllers manipulating Subjects > and Views observing Subjects. This should be sufficient. All the rest > of what you probably ment by protocol are semantic interpretations > and connections between the subjects. Telltales for example can be > constrained. A Menu for example will only allow one item to be selected > at a time, so it would best be modeled in terms of Menu::Items being > Controllers (which are Telltales, too) which are connected to an > ExclusiveConstraint sitting in the Menu itself. > > Or take the slider example I gave. Just create individual connections > between controllers and one or more subjects. The *whole* will then > turn out to be a widget of some sort. I guess that's what I get for jumping in like that :) I haven't considered the Model/View/Controller paradigm in this case. But my idea with the hypergraph was that you can replug anything without having to call things M/V or C... I hacked up the first working prototype yesterday and when creating a button, the graph for it looks like this: Nodes: ------ Button: String protocol for modifying it's name in the graph text: String protocol for modifying the button label posX: Integer protocol posY: Integer protocol sizeX: Integer protocol sizeY: Integer protocol create: Construction protocol for when creating the GUI control from the graph Windows native: guess what... (I haven't implemented an action node yet..) Button is connected to all the other nodes through it's named "connection slots" like this: Button.size -> sizeX Button.size -> sizeY Button.position -> posX Button.position -> posY Button.create -> create Button.text -> text Button.native -> Windows native So assuming you want to plug in your model at the button label you just just add event handlers to the text node for getting notifications about changes. Of course you can also use the String protocol for text for just modifying the label... Anyway I hope this makes sense... I'm going to implement this design in full and tell you all about how it works in practice when done :) >By the way, are you still working on DOM ? Looking onto the 'Mnemonic >Project' (a web browser among others) I find useful functionality as >XML parsing and translating into a DOM tree. I think we should consider >how to use your DOM stuff inside Berlin shortly, will you be on board ? I do not have time for it now. I'm desperately in need of money (so I'm writing an app. in ML for which I need the GUI toolkit :) and also there are my exams... but later... I intend to sort of "finish off" DOM into something working (it's almost there..). But I don't think I want to mess with the DTD stuff, except maybe for generating C++ skeletons with CodeTransformer. I'll still try to reach the IRC meething if I can (whenever it's gonna be :) Cheers -- http://www.HardcoreProcessing.com From alexhudek at home.com Sun Jun 6 22:19:37 1999 From: alexhudek at home.com (Alexander K. Hudek) Date: Fri Feb 25 22:27:39 2005 Subject: Kernel Message-ID: <375AF3F9.BC469CE5@home.com> Hey, I've been looking around at all the new technologies emerging in the open OS area. Berlin looks to be one of the most promising of the projects. I was wondering, has anyone thought of gearing berlin towards a HURD kernal rather than a linux kernal? I think it would open up a lot of possibilities as hurd is much more modular/OO. Just a thought. Alex From vanco at sonic.net Sun Jun 6 21:24:05 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:39 2005 Subject: Kernel In-Reply-To: <375AF3F9.BC469CE5@home.com>; from Alexander K. Hudek on Sun, Jun 06, 1999 at 05:19:37PM -0500 References: <375AF3F9.BC469CE5@home.com> Message-ID: <19990606142404.C2526@awac.local.net> On Sun, Jun 06, 1999 at 05:19:37PM -0500, Alexander K. Hudek wrote: > Hey, > > I've been looking around at all the new technologies emerging in the > open OS area. Berlin looks to be one of the most promising of the > projects. I was wondering, has anyone thought of gearing berlin towards > a HURD kernal rather than a linux kernal? I think it would open up a lot > of possibilities as hurd is much more modular/OO. Just a thought. > > Alex Several people leading Debian GNU/Hurd are working exactly for this end. However, Hurd isn't capable right now -- we need KGI. Some time is needed to sort that out... -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From mental at kludge.org Sun Jun 6 23:13:50 1999 From: mental at kludge.org (MenTaLguY) Date: Fri Feb 25 22:27:39 2005 Subject: Kernel In-Reply-To: <19990606142404.C2526@awac.local.net> Message-ID: On Sun, 6 Jun 1999, Aaron Van Couwenberghe wrote: > Several people leading Debian GNU/Hurd are working exactly for this end. > However, Hurd isn't capable right now -- we need KGI. Some time is needed to > sort that out... Well, we don't _need_ KGI, actually. LibGGI is happy on other display architectures too. That being said, from what I've been picking up lately on the GGI mailing list archives (I've given up trying to resubscribe), there seems to be a good deal of interest in KGI on Hurd, or is that what you're making reference to? -=MenTaLguY=- ----------------------------------------- mental@kludge.org ----------------------------------------- FOR COMMENT CHANNELS ONLY From julian at white-tower.demon.co.uk Mon Jun 7 21:02:41 1999 From: julian at white-tower.demon.co.uk (Julian Regel) Date: Fri Feb 25 22:27:39 2005 Subject: Berlin Network Directory Services Message-ID: In July of '98, Jordan suggested that it might be good to implement a directory similar to NDS and Active Directory, possibly built on LDAP. There was a lot of exciting comments and the general reaction was positive. Since then, nothing. Was this idea rejected for some reason? Is it too difficult to implement? Just wondering... Julian +----------------------------------------------+ | Julian Regel: julian@white-tower.demon.co.uk | | http://www.white-tower.demon.co.uk/ | +----------------------------------------------+ From vanco at sonic.net Tue Jun 8 01:09:00 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:39 2005 Subject: Kernel In-Reply-To: ; from MenTaLguY on Sun, Jun 06, 1999 at 07:13:50PM -0400 References: <19990606142404.C2526@awac.local.net> Message-ID: <19990607180900.A9312@awac.local.net> On Sun, Jun 06, 1999 at 07:13:50PM -0400, MenTaLguY wrote: > On Sun, 6 Jun 1999, Aaron Van Couwenberghe wrote: > > > Several people leading Debian GNU/Hurd are working exactly for this end. > > However, Hurd isn't capable right now -- we need KGI. Some time is needed to > > sort that out... > > Well, we don't _need_ KGI, actually. LibGGI is happy on other display > architectures too. That being said, from what I've been picking up lately > on the GGI mailing list archives (I've given up trying to resubscribe), > there seems to be a good deal of interest in KGI on Hurd, or is that what > you're making reference to? Well, actually, we need at least one functional target for libggi to be workable at all. fbdev is pretty much moot, X may or may not come about, and svgalib is fairly far away. All I'm saying is that if KGI is ported, the rest of these would be unneeded, what with the SVGAlib wrapper and XGGI. -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org "...Nothing astonishes men so much as common sense and plain dealing..." -- Ralph Waldo Emerson From seefelds at MAGELLAN.UMontreal.CA Tue Jun 8 20:16:33 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: [fresco] Re: Fresco's status and future References: <375CD381.51B35112@acm.org> <375D55EF.2A82E0F6@magellan.umontreal.ca> <375D8146.BAAC6F7@tu-harburg.de> Message-ID: <375D7A21.A93FEA6E@magellan.umontreal.ca> Thomas Hiller wrote: > > Stefan Seefeld wrote: > > > Another very important part is the TextKit. Why is it designed the way it is ? > > What are your questions about the TextKit ? It was more a general question. I'd like to see in general which considerations led to the current design. For example, the TextKit contains two methods for generating left to right compositions and right to left compositions. Wouldn't it make sense to parametrize the TextKit in terms of 'traits', so that you create a TextKit for, say, standard European text and another one for Arabic text ? Then you wouldn't create a Composer explicitely but let the TextKit care what composer implementation to use. Similar with other text layout related algorithm. It seems to make no sense to me to catch everything by a single TextKit. Separating the different trait dependant algorithms (hyphenation, text layout, etc.) into different TextKits seems a good way to keep it small. (A typical user would only link in one TextKit at a time). Then there is the problem of compensating for incorrect (device dependant) fonts. That is, treating text as device independant glyphs will get you into trouble if you detect that the drawingkit you are going to use to render it doesn't support the exact requisitions as specified by the individual glyphs. This might be no problem as long as you have exactly one DrawingKit (you can simply create the requisitions as a function of existing fonts) but if you establish a layout for, say, X fonts and you want to use a postscript DrawingKit to print your document, what are you doing if the available postscript fonts don't match the X fonts ? As we discussed in Berlin, it is (should be) the job of the Compositor to adjust the layout. Therefor it has to compare the available fonts for both DrawingKits (the screen DK and the printer DK) and try to compensate. > The main design goal was to build a sgml capable TextKit. (This was not reached) > If I would want to write a new TextKit I probably would take an XML parser and write > a renderer for it. Hmm, there should certainly be a mapping so that you can create a scene graph containing text out of an XML stream but since an XML stream could contain anything (almost) you can't simply process it from within a TextKit. But I agree that an XML parser would be nice to have. It would instantiate the different Kits (Text, Widget, Layout, Figure) on demand and build a scene graph with it. We had discussions in the Berlin Project to add such a beast. > Some of the features of the TextKit are described in 'design pattern' by the > gang-of-four. There is a lexi application, which resembles doc from InterViews. Both > application I guess influenced the Fresco TextKit. Yeah, I read the design pattern book (and related material). Where can I find the doc or lexi applications ? Is there any code using the current TextKit capabilities from Fresco ? best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From seefelds at MAGELLAN.UMontreal.CA Fri Jun 11 16:30:46 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: TODO for TODO list Message-ID: <376139B5.F2016C4A@magellan.umontreal.ca> hey (especially Graydon), I think there are a couple of things which could (should) be cleared up at the home page for the release. First of all there are a couple of links which are a bit out of date (Mesa for example), the dependencies need an update too (versions for g++, omniORB, ggi etc. we use). Specifically for the TODO list, I'd propose to make it more structured. Now we have the two categories coding and organizational. I think we can have different coding sections for the different contexts (kits) or even for kits yet to be designed. Some tasks need perl coders, others need people looking from a user's perspective, yet others need to design. There is really a broad range of skills needed. There are plenty of tasks for everyone. For example: documentation ============= modify the 'perceps' tool to our needs: * add support for IDL, namespaces... * write templates to make it output docbook conform text from our *.idl/*.hh files add a build environment for a 'Reference Manual' to the doc subdirectory DrawingKit ========== add support for clipping which allows to * incrementally (stack) narrow the drawing region to confine the region individual graphics have write permission to WidgetKit ========= design a type safe mechanism for the WidgetKit to load user implemented widgets as plugins. DOM === write an XML parser which produces a DOM tree. Consider how to combine this with the current Berlin architecture. Useful references: libwww (W3C), Mnemonic Project, ... Style Manager ============= add styling support to the scene graph. Build a tree of StyleContext objects which is traversed in parallel with the scene graph so that Graphic object can retrieve their styles (as part of the external state) from the Traversal object. Write a Style Manager which builds such a tree and which interfaces to the Registrar for persistant storage. (Should StyleManager and Registrar be combined into the same object ?) Moscow / ApplicationKit ======================= read documentation about openDoc/openParts from different sources (there were a couple of interested links posted at the ML recently) and see how to design basic interfaces for the Moscow layer ('Document', 'Part' etc.) What should the ApplicationKit have as functionality to allow client communication ('embedding') ? Try to figure out where we could get a trading service implementation from (TAO, KOffice etc.) Best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From gray at interlog.com Sun Jun 13 22:35:31 1999 From: gray at interlog.com (Graydon Hoare) Date: Fri Feb 25 22:27:39 2005 Subject: meeting Message-ID: irc.openprojects.net #berlin now. be there or be squishy :) From vanco at sonic.net Mon Jun 14 01:03:16 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:39 2005 Subject: POA? Message-ID: <19990613180316.A450@awac.local.net> I'm not sure I understand all about this, but I'm trying to build a variant of COPE that supports POA. Will berlin (omni 2.1, CORBA 2.0) interoperate with COPE (CORBA 2.2)? -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people: those who can count, and those who can't. From vanco at sonic.net Mon Jun 14 01:23:01 1999 From: vanco at sonic.net (Aaron Van Couwenberghe) Date: Fri Feb 25 22:27:39 2005 Subject: COPE dead; ILU? Message-ID: <19990613182301.B450@awac.local.net> COPE is borked. So, I've moved on to ILU. This looks to be the most actively developed OSS ORB around, with the most bindings on one ORB I've seen yet. Perl bindings are available from a third party, and they appear to be well tested (although not entirely complete). Graydon - have you tried this out? If so was it a dead end? -- ..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org.... Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people: those who can count, and those who can't. From graydon at pobox.com Mon Jun 14 07:54:04 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:27:39 2005 Subject: meeting followup: styles Message-ID: <19990614035404J.graydon@pobox.com> Ok, I'm awake and thinking about styles some more. What I want it a clear, concise plan of attack. none of this wishy-washy crap. this issue has been open way too long, and we're increasingly coding half-baked hacks to get around the absense of both a persistent user preferences database and a way of assigning styles to things. here are the top-level issues: (1) an application needs to be able to look up a persistent, user-specified value by a "key path", which is the classical registrar application. The examples here are: files in the filesystem, URLs, public keys, phone numbers, email addresses, etc. looked up in particular configuration value settings like "font for editing" or "PGP key for work" or whatnot. (2) an application needs to be able to create graphical components "the way the user wants them", which means that the component looks up its stylistic settings based on its position in the scene graph. somehow. (3) some instances of both #1 and #2 benefit from "patterned settings", where the setting is _not_ stored as an absolute key but rather some sort of structured, partly-compiled pattern fragment which may match any number of possible lookup scenarios. (4) some things just need to be set "in place". For instance, it should be possible to inherit "foreground color" from the environment or a style lookup, but it should equally be possible for a client application to say "look you bastards, I want to draw a _red_ line on the screen!". So there should be a way of arriving at a style setting from the scene graph without lookups in the style manager. We're all together thus far? Ok. rundown of how the scene graph currently works: graphics have parents. possibly multiple parents per graphic, as we all know, for the sake of efficiency and general increase in confusion. By traversing the graph, which is acyclic (no node may be its own parent), you "flatten" it into a proper tree, (a tree is a graph where each node has _one_ parent). If you want to visualize this, imagine splitting each child with 2 parents into 2 separate children with identical attributes and an identical set of children. If you repeat this process (even if you're only doing it logically, in your head) splitting the children, then each of their grandchildren, then each of their great grandchildren, you'll see there's an intrinsic (very bushy) tree-structure embedded in a directed acyclic graph (a DAG). So you can think of a DAG just as an optimized tree. A tree with sharing. if this paragraph does not make sense, continue re-reading it until it makes sense. it is totally critical. otherwise you'll be all spooked out with the multiple parents thing and have no way of coping with the implementation of this stuff. Ok, so if the scene graph is a tree, and I think we can rightly say that the actual structure of application defaults can be tree-ish, then what we're looking for is a way of storing patterns for trees and accessing the result of matching a particular node-in-the-tree against those patterns rapidly. The 2 trees in question are a tree of attribute names (for application defautls like email addresses and public keys) and the tree of style settings. Stefan has (rightly) suggested that it would make a whole lot more sense to actually construct a real, live, legitimate tree of "looked up" values in-memory in the display server that a traversal can walk "in parallel" with its traversal of the scene DAG, in order to save hammering on whatever pattern engine or persistence mechanism we have. this tree would only need to be recomputed when the connections change in the scene DAG, which is far less frequent than its complete traversal. so shut up about performance :) it's not an issue until you have profiling data which confirms that it's an issue. The major issue is how to implement such a pattern lookup system. I've read some of the guts of style engines already, and they're not too bad. i'd suggest we start with something very simple, and expand it as we see the need. here's my proposal: each pattern is a sequence of 1 or more "path components", which will be written for ease of comprehension as separated by slashes.. Each path component is either a double-slash, or a pair of two "selectors" the form [class,instance]. Each such selector is either a unistring name or else it is a star. double-slash and star are distinct object types, and are not directly related to the unicode characters * or //, other than by convention (I will write them using asterisks in the examples). i.e. you should, in a pathological case, be able to make a selector called '*' which is not of type star, but which actually stands for that character. why you'd want to do this is beyond me. Anyway, star a wildcard for a single selector, for which any possible value is considered a match. If a selector is not star, then only unicode bit-by-bit equality between the query and the selector is considered a match. double-slash is a short form for any quantity of [star,star] components. that is, it matches to any depth in the query path, with wildcards at any point. Here are some examples of patterns using this rule: pattern: [person,graydon]/[phone-numer,home] => 928-2895 matches: [person,graydon]/[phone-number,home] not: [person,bob]/[phone-number,home] [rabbit,graydon]/[phone-number,home] pattern: [*,graydon]/[phone-number,*] => 928-2895 matches: [person,graydon]/[phone-number,home] [rabbit,graydon]/[phone-number,work] not: [person,dave]/[phone-number,home] pattern: //[button,cancel]/[color,label] => blue matches: [button,cancel]/[color,label] [window,mozilla]/[button,cancel]/[color,label] [app,word]/[window,wizard]/[button,cancel]/[color,label] not: [button,start]/[color,label] pattern: //[button,*]//[color,*] => blue matches: [button,close]/[color,label] [button,open]/[shadow,label]/[color,shadow] [app,mozilla]/[button,open]/[color,label] not: [slider,panner1]/[color,bevel] [button,open[/[color,label]/[localized-name,sweedish] get the idea? hope so. Here's how you store them: in a database, you put all the rules in a single table, call this table "rules". it's for interactive editing, rebuilding, etc. you don't use it at runtime. Once you have the table of rules, you construct an inverted tree. That is, for each rule, you start at its final component (since components will begin with double-slash way more frequently than they end in it, if they _ever_ end in it) and construct a standard linked tree structure on disk, where the entries "star" and "double-slash" are special types of objects which are not mistakable for characters. i.e. make all objects tagged with a type code to begin with. at the end of each tree there is a leaf, which is the value associated with the pattern. Then, when trying to match, take the path you're trying to match and look up the last component. you can seek to an exact match using a nice binary lookup or hashtable. if it does not match, degrade your search to try stars. if there is still no match for the last component using stars, check to see if there's a double-slash at the root branching of your pattern tree. if there is, discard the last component of the path you're matching and start over with the second-last. if you have advanced down the pattern tree, push the last component on a stack and select using the second last component in your query path. The stack exists so you can backtrack. if you ever run out of components in the query path without having arrived at a leaf node, you must pop the stack and try the next-best match at the previous junction. if you pop the last element of the stack, the query failed and there is no value at all. if you ever arrive at a leaf node, the query succeeded and you have your value. all this should only take a couple dozen comparisons, even in a dense case. stars should be ranked below exact matches, obviously. Finally, the issue of how to set exact styles should be pretty clear -- each node in the "parallel style tree" should be updatable by an application. this sort of update should not be persistent, but should last until the node in the style tree is destroyed. It can be accomplished by accompanying a call like "setStyle" with a parent pointer as a parameter, which will disambiguate which parent in the style tree you're talking about. And that's all I have to say about that. it needs doing, and that's imo how it ought to be done. it's a clear subset of the XSL pattern language, but it's small enough that it shouldn't take too long to do it. perhaps not even as long as it took me to write this :) it can be built on top of the current registrar just by altering the node types slighty to introduce double-slash and star, and to tag components, and altering the lookup algorithm. a lot of the stuff remains the same. questions & comments appreciated as always. it's 4am. good night. -graydon From amolbapat at yahoo.com Mon Jun 14 10:49:04 1999 From: amolbapat at yahoo.com (AMOL BAPAT) Date: Fri Feb 25 22:27:39 2005 Subject: Graphics package... Message-ID: <19990614104904.10968.rocketmail@web129.yahoomail.com> Hello, I am Amol Bapat from India. I am trying to build a Graphics package using OpenGL and JAVA. In the package I want to provide facilities like image rendering, light placements, changing background colours etc. I had a few queries regarding the implementation of OpenGL using JAVA. As I want the application to be available on the net I am thinking of JAVA. Is it the best way to do it? What other application development environment can be used. Can the code be portable from Windows to Linux or other OS. And I am going to run the application on Win95 on a pentium 166 MMX with 32MB ram. is it sufficient? Please help me in this matter, Thanking you in anticipation, Amol Bapat. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From seefelds at MAGELLAN.UMontreal.CA Mon Jun 14 13:52:21 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: meeting followup: styles References: <19990614035404J.graydon@pobox.com> Message-ID: <37650915.B6B47565@magellan.umontreal.ca> Graydon Hoare wrote: > here are the top-level issues: > > (1) an application needs to be able to look up a persistent, > user-specified value by a "key path", which is the classical registrar > application. The examples here are: files in the filesystem, URLs, > public keys, phone numbers, email addresses, etc. looked up in > particular configuration value settings like "font for editing" or > "PGP key for work" or whatnot. > > (2) an application needs to be able to create graphical components > "the way the user wants them", which means that the component looks up > its stylistic settings based on its position in the scene > graph. somehow. > > (3) some instances of both #1 and #2 benefit from "patterned > settings", where the setting is _not_ stored as an absolute key but > rather some sort of structured, partly-compiled pattern fragment which > may match any number of possible lookup scenarios. > > (4) some things just need to be set "in place". For instance, it > should be possible to inherit "foreground color" from the environment > or a style lookup, but it should equally be possible for a client > application to say "look you bastards, I want to draw a _red_ line on > the screen!". So there should be a way of arriving at a style setting > from the scene graph without lookups in the style manager. Fine. [scene graph design] > The major issue is how to implement such a pattern lookup system. I've > read some of the guts of style engines already, and they're not too > bad. i'd suggest we start with something very simple, and expand it as > we see the need. here's my proposal: Though I agree we need a StyleManager as soon as possible, I think we should focus on the way the scene graph will interact with it. I.e. issues like pattern matching and priority are a bit less important. For now a single style tree should do. Just to make some point really clear: 1) You may want to set the 'font' style for a group of items (which are frequently grouped in the scene gaph as well). This composite graphic might itself not have any meaningful interpretation of the style you set. SO, all I want to point out, is, that we should really have (logically) a set of styles for each graphic node. Whether it makes sense there or not doesn't matter. The node in question simply takes the styles it can interpret. 2) you can't in general let a graph node ask what styles it has without a traversal. This is because it is really within a DAG, not a tree. You have to flatten the DAG before. Just giving the parent doesn't suffice at all, rather it delegates the ambiguity just one level up. Which of the parent's parents are we looking for ?... It's basically the same story as how to ask 'what is your allocation ?'. Allocations are constructed on the fly (when from the traversal's stack it is clear which instance we mean) or when the node calculates *all* allocations (by means of the Allocation interface). Style lookup should be done somewhat similar. [pattern matching] > Finally, the issue of how to set exact styles should be pretty clear > -- each node in the "parallel style tree" should be updatable by an > application. this sort of update should not be persistent, but should > last until the node in the style tree is destroyed. It can be > accomplished by accompanying a call like "setStyle" with a parent > pointer as a parameter, which will disambiguate which parent in the > style tree you're talking about. If we place the 'setStyle' like method right into the Traversal this works fine. May be we should really consider building a special Traversal ('StyleTraversal') which allows more extensive style editing etc. Sure, all traversals have to care about styles, but may be some special operations could be factored out into this specialized class. I would really start with two new types: * StyleContext: a specifier which defines the position in a tree. may be even an iterator. * Style: basically a name/value pair. We should probably start with a struct containing a string and an Any, though I'd prefer in the long run to statically type the types (at least for standard graphics like text, figures etc.) Now, the implementation could be a tree which's nodes are sets of styles. The tree is traversed in terms of StyleContexts (which look like files in a file system as Graydon pointed out: root/stage/button/bevel) and for each context you can lookup the style in terms of it's name. So, if StyleContext is an iterator, we don't need to export the tree itself via CORBA. StyleManager, StyleContext and Style will suffice. And, just to reiterate, I think that the pattern matching/priority etc. is mostly something the StyleManager has to care about when taking multiple data bases (default, system, user preferences) and tries to merge them. I agree there are some tricky points in there but for now I think what I outlined will suffice. Best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From graydon at pobox.com Mon Jun 14 16:37:18 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:27:39 2005 Subject: meeting followup: styles In-Reply-To: Your message of "Mon, 14 Jun 1999 13:52:21 +0000" <37650915.B6B47565@magellan.umontreal.ca> References: <37650915.B6B47565@magellan.umontreal.ca> Message-ID: <19990614123718E.graydon@pobox.com> > Though I agree we need a StyleManager as soon as possible, I think we > should focus on the way the scene graph will interact with it. I.e. issues > like pattern matching and priority are a bit less important. For now a single > style tree should do. I think you missed the point of my posting. I am not suggesting we abandon the concept of a style tree at all, or that we circumvent it. It is completely acceptable as a way of speeding up the style retrieval process to construct an in-memory tree which represents the cached, "looked up" style values for each uniquely-parented path+node in the scene dag. And yes, there is no way of looking up a dag node using the pattern scheme I outlined, because it's intended for looking up nodes in an unrolled tree. I did actually mention this in the post but I guess it got skimmed. I _agree_ with you on that. I also do not think that that particular issue -- the top-down design motivation of taking tree-like view of the dag, in parallel with the dag, assigning styles from the styleContext tree to traversal contexts via a name/value dictionary-like interface -- is what we're stumbling over. I know you keep saying that we're focusing on "implementation not interface", but the very real fact is that we've been stumbling over implementation. We all know that the interface is "traversal context calls getStyle("color") and gets back the appropriate color for its current path+node", what we've been _lacking_ is a concise, implementable plan for filling in the meaning of the word "appropriate" in the preceeding sentence. I was posting the necessary details for implementing a stored-pattern database and performing lookups on tree nodes. NOT dag nodes. the implicit assumption in my post is that you have _already_ unrolled your dag into a tree, and are now attempting to "decorate" that tree with all the appropriate style settings, in order to implement the dictionary lookup during a style traversal. I was making this posting because every time we bring up the issue in a meeting, we get bogged down in "how can this be done?" and "how can it be efficient" and "that's not how the registrar works" and "I think the X resources model is (cool|messed up)" and related things. I don't think there's any debate over interface. /me realizes he's lapsed into repeating himself and is acting like a grumpy child first thing after waking up, and shuts up now :) From seefelds at MAGELLAN.UMontreal.CA Mon Jun 14 17:48:42 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:39 2005 Subject: meeting followup: styles References: <37650915.B6B47565@magellan.umontreal.ca> <19990614123718E.graydon@pobox.com> Message-ID: <3765407A.9D48F986@magellan.umontreal.ca> Right. I realized even after your first follow up that we are basically in agreement :-) So let me come back to the 'how to resolve' issue. My point was that you have two things: how to fill in the style tree (using patterns etc.) and how to extract values from it. My point was that the first is not so important, by that I mean that more sophisticated pattern handling can be added without disturbing the second part. May be I'm wrong. So to come to the second point, I imagine the tree as (at least logically) a tree of sets. Every node has a set which you can ask for a value in terms of a name. Either it exists then you get back what you were asking or it does not then you get nothing and may stick to your compiled in defaults. Since most of the scene graph will use the same settings and changes will apply to groups of nodes mostly, I think a given style in a given nesting level (StyleContext) will be valid for *all* child nodes as long as it is not overridden. And, as I proposed earlier, overridden might actually mean modified, not redefined. Given my client with the HBox holding three frames which hold rects. You could set a style "Bevel" for the HBox like in Screen/HBox.Bevel 2 and all the children will get "2" when querying for "Bevel". Adding Screen/HBox/Inset.Bevel 4 will make the first child have "4" instead of "2" since the specification overrides the more general "2". Note that A/B/C is just to visualize the StyleContext. It might take whatever format when written down in a persistent DB. Well. This design has actually a couple of problems. X for example distinguishes between class and instance. The above corresponds to the class since I'm saying 'all Insets within all HBoxes within all Screens...' Another way (corresponding to the instance approach) would be to 'enumerate' the children in the tree, so if we are at the HBox level, you have three children and you might assign the 'Bevel 4' style to the first one. It doesn't apply to every Inset but to the 'first child of the HBox'. I think both approaches are quite useful and I like at least the idea of the Xrm. For example having two versions of the same program at two different positions in the scene graph (no, not shared, real copies), I'd like to be able to specify which one I'd like to manipulate *and* I'd like to be able to modify both at once. Regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From graydon at pobox.com Mon Jun 14 18:43:22 1999 From: graydon at pobox.com (Graydon Hoare) Date: Fri Feb 25 22:27:39 2005 Subject: meeting followup: styles In-Reply-To: Your message of "Mon, 14 Jun 1999 17:48:42 +0000" <3765407A.9D48F986@magellan.umontreal.ca> References: <3765407A.9D48F986@magellan.umontreal.ca> Message-ID: <19990614144322K.graydon@pobox.com> > Well. This design has actually a couple of problems. X for example > distinguishes between class and instance. The above corresponds to > the class since I'm saying 'all Insets within all HBoxes within all Screens...' > Another way (corresponding to the instance approach) would be to 'enumerate' > the children in the tree, so if we are at the HBox level, you have three > children and you might assign the 'Bevel 4' style to the first one. It doesn't > apply to every Inset but to the 'first child of the HBox'. Sure. I was being pretty minimal with the featureset I suggested for the pattern language primarily because I wanted something where the algorithm would be simple and we wouldn't spend a lot of time arguing over it. There are all manner of complex patterns you can apply, but I think if you read it the one I'm proposing (paths of class & instance pairs, with wildcards for either and a single depth-ignoring wildcard) is sufficient to get us started. It won't be enough to, say, do XSL off the bat (which supports patterns like ../../@text[position()=last()]/underline meaning any node whose grandparent has a text attribute, and is of last-position in its parent set, and has an underline as a child) but I think limiting the featureset is critical to fast development. we can extend it later. besides, we'll never know which features are most important till we start using it. -graydon From arrow at magenta.com Mon Jun 14 23:12:04 1999 From: arrow at magenta.com (Dave Archer) Date: Fri Feb 25 22:27:40 2005 Subject: Meeting Log (not pretty and long) In-Reply-To: <19990614035404J.graydon@pobox.com> Message-ID: Hi all Here is my log of the meeting. ωνω gray [gray@shell1.interlog.com] has joined #berlin ωνω gray is now known as graydon Yeah, I wrote a C++ wrapper for X11 as part of the OffiX Project and it helped me understand the design of this protocol. allo alloo hehe, hi Graydon, from Hamilton ? seffan cool π graydon/#berlin is logging, but would appreciate it if someone else would as well π graydon/#berlin is in hamilton stefan even in an internet cafe π Arrow suggests we be succinct...I-cafe=$$ per hour so. when were we scheduled to start, 6 or 7? 6 EDT people were confused as always ok, wanna get things on the road? π graydon/#berlin has 6 issues on my list, plus whatever y'all brought along Well, I think at 6 pm but look, neither Aaron, Jonas, Brent... are here right now... heh. yeah. good point. π graydon/#berlin sighs. this is rediculous. maybe we should schedule out meetings in "swatch beats" or something. Hmm, what are those points. may be we can work on a couple of them already. (1) deleting things in the current CVS tree in preparation for release (2) the new eGroup and the new BugZilla (3) Tie Classes (stefan, you'll like this) (4) the general outline of the compositor class (5) registrar (issue-which-will-not-die #1) (6) style contexts (issue-which-will-not-die #2) π graydon/#berlin opens up a window to mail a nag message to the rest of the berlin list about coming to this channel :) ok, 5 and 6 need at least Jordy online, 2 is of general interest, 1 may be too, so let's start with 4. ok, tie classes. 1 sec, composing email. I'd like to add the following points to your list: (7) Prague (8) documentation yes, of course. added.. (9) items of immediate interest (Focus, pty, ...) Though all these are really dependant on more people being online :( π Arrow is logging ok, well tie classes aren't, so I'll mention them now. stefan: do you know what these are? I've got an idea, templates to tie classes together, bridge or so (?) there's an "alternative mapping" in the corba 2.2 spec for interfaces, which does not involve inheritence, but invovles templatized servant classes doing upcalls into the _impl objects. turns out omniorb supports it in 2.7.1, as do a number of other ORBs it reduces compile-time dependency quite a bit, since only the impl.cc file using another interface needs to include the interface decl. impl.hh's would not need to include *any* corba files at all, which would make the amount of cumulative inclusion go wa so, while it might be a lot of work, I'm considering trying to port our tree to use them oh. issue (10): python & other orbs. have a little to report on that. So, GraphicImpl doesn't inherit from Graphic but ties to it ? Yeah, ties actually fit in with the kit notion quite well. instead of making a new, say, boxImpl, you make a new _tie_Graphic, and then BoxImpl itself doesn't inherit from any corba machinery at all. Hmm, have to read a bit about it. Looks interesting though templates might bloat the code quite a lot at this point... the extra parameter (1) in the template is actually boolean, saying the tie should call operator delete on the impl when the tie is released. ownership management. which is nice, because it makes using flyweights easier. we can just make non-owning ties to impls yes. it might make code expand a little.not sure. He, yeah, (11) GC, how to manage ownership of implementations (which is not yet clear, at least, to me) anyway.. I think releasing is important enough at this point to keep tie classes strictly out of CVS until we branch. but I thought I'd mention them. Hmm, I think we have reduced dependancies quite a bit. I'd prefer to stick to these for this release at least. Right. Good to know, we should experiment with it (Will see whether Henning/Vinoski cover this) is that the "advanced C++ programming with corba" book? youp. π Arrow was just about to buy that book...:) π graydon/#berlin wants to get a copy of that. it looks very nice. :)) it's worth the price ! ωνω hunger [hunger@alcatraz168.wohnheim.uni-kl.de] has joined #berlin ωνω hunger is now known as Hunger hey tobias hi there! Hi Tobias, nice to see you here ! hello, stefan. ωνω Alain [pirch@66-107.dr.cgocable.ca] has joined #berlin Hi Tobias hello\ hi alain He, Alain, bon soir ! Hello Alain This is my first irc session, so please be patient with me :-) Hunger--i'll be Graydon (and Stefan & Arrow)--how are you ?? hunger: this is a good place to be learning irc. there's a lot of evil irc users out there and none of them are on this network :) alain: pretty good. I'm in an internet cafe in hamilton. spent the day hiking the bruce trail and eating strawberries. π Alain/#berlin started logging Gray--cool,hope the strawberry where tasty graydon: Toronto eh? Good stuff. :) very. plus I got to spend all weekend with gf, which helps. π graydon/#berlin stares at the clock. this is silly. Ok, Graydon, (1): what should be kept for the next release. all the capital-letter /src directories :) the /doc directory, all capital-letter /includes all that's obvious. how far did you get hoisting libdatatype into prague? It's in there (new implementation). We don't need libdatatype any more. (I discussed this with Andrew) ok, I'm not using libgfont at all, and have the feeling it'll need (mostly) rewriting anyway to use t1lib. so I think it can go for now. I might reintroduce it a couple layers down in /src/Text it doesn't let you access metrics in any good way, which is really the hardest part so I'd say that whole datatype dir can go Fine. What about the unicode stuff ? tricky. that never really got off the ground. I think it really needs to be integrated with the textkit Hmm, I'm even not sure about how much of unicode will go into the stdc++ wstring... like, requesting a buffer with a particular set of characteristic behaviour Yeah, the bidi algorithm looks like something more suitable within the Compositor yeah. you also get things like normalization, where you want a container which normalizes the unistrings it receives from cut/paste and events.. Won't we need unicode below the textkit too? I think we should have a Unicode class within Prague which can be used inside Prague as well. Berlin (TextKit) should use this. and I'm not sure at all how the coalation/sorting stuff is going to work. clients and servers need to see that stuff occasionally, like specifying a username in prague using unicode. yes, I think stefan's suggestion is best but saying "A Unicode Class" and specifying what actually goes in it are 2 very different things. :) Where can I get some docus on converting to and from unicode? I'd like to try to write up a converter if I can. since character data is so prevalent, you probably want to typedef a simple numeric integral type as "unicode" and then write utility classes that go to<->from unicode. wchar_t hunger: gnu "recode" is good, as is "TCS". stefan: no, wchar_t has nothing on conversion. Thanks, graydon. There is a Unicode defined in omniorb by the way. umm....if it help,i can write a sample document in both ascii and unicode for comparison ?? But isn't this ment to *hold* a unicode value ? stefan: yeah, sorta. it's meant to hold "anything wider than ascii", which isn't always clearly unicode. unicode itself isn't even clear on what unicode is, unfortunately, as they've recently started going into 32bit or multi-16-bit chunks. it's bad. we need to decide on certain features to suport. Oh, one more reason to factor the different parts of it yes. the important thing is that everything in berlin should have access to a normalizer. above that, there's some ambiguity for instance, when you compare for equality, some locales have concepts which make equality hard to pin down. and when you coalate, again, hard to specify. it's locale-dependent. but if you have a normalized base form, bit-for-bit, that everyone can get to given a bunch of unicode, then you can always make a stupid coalator and a stupid comparator which just do bit-equality and bit-comparison. you wind up in a sticky situation, like in the current XML draft, they had to decide to make XML tag names case sensitive in order to make it at all plausible to do matching in unicode. because case-insensitivity is highly locale-dependent. I *believe* there's a normalization algorithm on the unicode technical reports page. So, let's put this whole story on the TODO list. We have to use a subset as far as this is not worked out. ωνω Jordy [jordy@24.40.44.141] has joined #berlin (which should be fairly easi) if we had that in prague, say a class "unicodeNormalizer" with a static method "normalize" overloaded to take any possible charset, then the issue would definitely lose some of its urgency. Hi Jordy ! (waiting just for you :) hey jordy. man, i forgot all about this i went food shopping :) good timing dude. I'm paying by the hour here :) Hello Jordy hello jordy Hi! alright, now what exactly was the topic? Ok. (5), (6): registrar and style. or have I just completley missed the entire meeting :) jordy--i'm logging Jordy: we were talking about things which need to show up in prague to facilitate removing the somewhat-underspecified libunicode from the tree I have it from the top...:) oh, just to note, on that topic, alistair leslie did much of libunicode and probably has some code to contribute to any class in prague. Jordy: we're thinking in terms of another release late this month or early next. Well, for now we could just put the very linunicode (-2) into a Unicode class within Prague. Someone has to take on this to elaborate features we need in the future... how done is libunicode? i haven't actually looked into that particular tree I"m mostly concerned that there be a public, available set of static methods which to conversion and normalization. you usually only realize 90% of the way into something that you're going to need a conversion from some existing ascii-centric system. Stefan: can we do styles & registrar last-ish? they have the habit of dragging on for hours :) :) sure. I'd just like to get all the administrivia and what-to-do-next stuff out of the way, so we can be sure it gets done. well ok, Unicode will need to be basically linked to everything... might be good to keep it seperate from everything else Jordy: Prague is linked to everything now :) Prague is the ultimate evil! graydon: good point :) π graydon/#berlin jokes well, we don't want to make Prague a huge monolithic library do we, everything under one roof sort of deal Good point, but wasen't Prague meant to basically be a hardware abstraction? OS abstraction, yeah. No ! It's sort of two parts. OS wrappers and convenience classes everyone will need hmm. true. the logger class is not an "os wrapper" jordy's got a point tho. how gid is prague atm? s/gid/big/ Some other are not, too. Like the IPC classes. π graydon/#berlin smacks self. gf is attacking keyboard. hmmm, not sure... i'd tell you but gnome is having a hissy fit right now byte-count? is it "too large"? I mean, equally, it's annoying to have 20 different libraries, if the functionality of prague is reasonably static. Prague has 300 k right now. that's not bad I do know that it's the 1 component I recompile *least* in berlin.. so I'm not worrying too too much about its "bloat". Exactly. I try to cover most ACE parts too (communication layers etc.) Really Unicode is pretty small, the big part is that damn data file heh. ACE is *HUGE*. it does everything.. ωνω Eugene [eugene@furrypotato.skankybitch.org] has joined #berlin dog dog Nano nano :/ well ok, everything which will be required by every client/server should probably go in one library Ehm. ACE is huge because it is *so* configurable. I use just some subset. There are a couple of really good papers about ACE (ACE Reactors, IPC SAP) eugene and frances are on the same wavelength eh? stefan: oh, I know, I think ACE is really quite sweet. it's jus, well, there's no denying it's enormous. anyway Yes. alright, I think we've covered that topic next? :) ωνω graydon has changed the topic on channel #berlin to: bugzilla and egroup ok, we now have a BTS. bugs.berlin-consortium.org He, thanks a lot for that, Jordy ! jordy's work. if someone wants to redesign the HTML, go right ahead I filed 1 bug in it. it seems to work. file more! I basically just removed the bugzilla logo :) there are bugs ??? ;) Might have a wee look at the HTML then jordy: I think we need to set up some categories. yeah, there aren't any categories either if someone wants to come up with a list of modules to report bugs on, basically bugzilla has two peices, seperate programs to report bugs on, and components of those programs When I had a looksee it bugzilla it looked like a damn nightmare to work on. wasn't too difficult, export a few SQL commands, rework the interface, get 500 perl libraries but it seems to work ok, cept that bug reports link doesn't seem to do anything i take that back, it does do something Speaking of perl - I read you need someone to code some perl - what do you want doing? we also have an "egroup", on www.egroups.com He, Eugene, you like Perl, I think I have something for you ! (later...) mmmkay I wish I knew where that damn TestProduct is coming from which is a really nice forum for posting things you want done, patches you want to have someone look at, documentation fragments, etc. You mean because of it's structuredness ? i like their calender, but i wish it showed when particular things ended I just thought I'd mention those resources. I'll also post links to them on the berlin site so as people can use them who are just getting into berlin. stefan: yes, also because it's not _my_ inbox. I've got my email address all over the berlin website, when in fact there's a whole bunch of people who can integrate patches, submit documentation to CVS, etc. stefan: if you post something to the egroup, everyone with berlin CVS r/w has a chance to do it. stefan: instead of making me the bottleneck, which clearly won't scale. you're right. ...which takes us back to another topic...:) stefan: ? what other topic stefan? >>> Jordy [jordy@24.40.44.141] requested PING 929316484 797651 from #berlin How to do this ssh/cvs thing ! export SSH_RSH=ssh export CVSROOT=:ext:gray@va.debian.org:/cvs/berlin no, I mean how to do it preserving the users identity stefan: you mean in the long run? in the long run we get our own machine and make separate accounts for multiple people, hire a sysadmin, and take over the world of course. oh, i could have sworn there was a way to do that Well, I ment in the medium run then :) like use pserver over ssh ok, that's *another* administrivia todo. I know *someone* on master.debian.org can help us with that if we bribe them enough, but I want to get this meeting over with this weekend. preversions! π graydon/#berlin asks forgiveness. gf is typing oddness. who is gf by the way ? alter ego ? well what happens if we just use :pserver:email:/cvs/berlin after CVS_RSH is set? :) (g)irl(f)riend. oh, from Montreal ? Salut !! Jordy: cvs will not engage the external ssh. stefan: from toronto, but whom I was talking to in montreal, yes. :) Sorry my indescriteness (?) ωνω graydon has changed the topic on channel #berlin to: compositor what's a compositor? :) the golden question it's a layout manager for text essentially ωνω Aaron [aaron@d216.pm13.sonic.net] has joined #berlin alright, i've heard about people having problems laying out text yellow Hi Aaron when did we start? Aaron !!! ji ! which compares the metrics of text rendered under a "canonical" drawingkit vs. the drawingkit which is currently traversing a scene. Something came up yesterday, just got ome 5 mins ago and compensates for the errors introduced by the current drawingkit, either from hinting or from font mismatching. I thought I'd mention that. it's not really done in any appreciable way, but it'll evolve into quite nice adaptive text layout. and it's in the textkit, which is something I've been spending time on. a little, anyway. π graydon/#berlin notes the silence. a dead topic perhaps.. not one of the things I have any experience with :) I still suggest stealing MOzilla's :) Jordy: heh, might happen :) mike shaver of mozilla is in toronto now, apparantly I might be bumping into him sometime soon well there just happen to be a lot of things in Mozilla which would work great with Berlin ωνω graydon has changed the topic on channel #berlin to: Documentation ωνω SignOff alexH: #berlin (alexH has no reason) π graydon/#berlin makes a mental note on other topic: mozilla XUL stefan: you found a new doc tool? sinze mozilla is fairly well covered with CORBA interfaces. Aaron: surprisingly, it is not. 1: comented code ;) my style for commented code is, comment anything that will confuse someone, but dont' comment the basics π graydon/#berlin wonders if stefan is here.. i mean, we don't need to put in a comment every time we define a variable :) He is (sorry) my ag is real bad right now. bear with me, I'll try to not to talk too much the doc tool I found is written in Perl, looks incredibly flexible and is called perceps. I playd with it a bit and it seems really the thing we need. ooookay. well my plan is still thurough docbook. I've been making disgrams in argo, and should continue to do that to make some of the tricky bits clearer. stefan: you got a URL? perceps? stefan: cool. like, makes HTML/SGML? That's the thing I'd like to propose to Eugene. Someone has to adapt it a bit and write template so it outputs (Berlin conformant) docbook docs. http://friga.mer.utexas.edu/mark/perl/perceps/ ωνω alexH [thanks@cr622414-a.etob1.on.wave.home.com] has joined #berlin I think it can output *anything*. You just give it a couple of templates where you define how you want class, interface, method etc. docs to appear and... woah, it makes java applets too? java applets? wow It can use one. I didn't look into this further since I was most interested in docbook like stuff. I can have a wee look. this is pretty cool. ok. yeah. I'm not sure if API-based documentation and "how the thing works" documentation need to be blended in our case. It has a java applet for the class tree. Graydon: no, I'm in favor of a tutorial (completely hand written) and a reference manual (automatically generated) stefan: yeah, I think you're right. Mmkay, seems relatively straight forward. I will bookmark it, and have a looksee when I ger home from work tonight :) stefan: I find myself, when writing the reference docbook, doing a lot of things which ought to be machine-generated (enumerating all the methods in a class with brief descriptions, say) That would really be great since I think this is a good starting point to explain in detail the implementation of certain algorithms. I'd really like to start on that ! ok. cool. well I certainly like what perceps seems to be capable of. π Eugene/#berlin doesnt know anything about docbook - do we have anythink I can take a look at? So write it onto the TODO list. BTW - how up to date are the debs - I will alien them to slp and have a look. I cant get my damn CVS to work. Eugene: ignore current debs. we're releasing new ones. mmmkay ωνω graydon has changed the topic on channel #berlin to: Python & Other ORBs ok, I took the time to make warsaw compile to stubs & skels on fnorb it involves a little fiddling with the C preprocessor and some perling and grepping Python? YEah. I was looking for something to do testing with why are we going into the whole VM deal? :) cheap, fast testing of the display server not Python-in-the-server, just Python-as-a-way-of-running-tests Sorry, what has Python to do with VM ? I mean, if we are going to use any language it might as well be Java, which has built in ORB stef: isn't python interpreted? I think jordy misinterpreted my /topic. I'm talking about testing. graydon: ok, misunderstood but still java would make a more logical choice, since it has a built in ORB and is similar in syntax to C++ Jordy: It is. But is every script considered running on a VM ? I was looking about, and could not get any of the perl ORBs to work quite right stef: yes :) python is good. Jordy: yes, java is my next candidate for testing perl, java, etc all run in VM's Jordy: the problem is that the java2 stuff, including the ORB, is decidedly nonfree and nobody has made a free clone. it's all under sun restrictive license. Jordy: there's a big difference though. but you know that Does any of these ORBs support the security service? graydon: no GPL java2 yet? hmmm Hunger: the security service is underspecified right now CORBA 3.0 will have a much more complete spec I personally find python kinda grody, but I'm not sure if that's just lingering impression from a bad python talk I once attended. Anyway, does anyone _object_ to developing a test framework in python? does anyone feel like doing it, is the real question. Aaron: I know, but some commercial ORBs have it anyway. (Don't ask me how they did it though ;-) perl would be better, but if nothing works nothing works graydon: does python have an ORB? Aaron: I feel like doing it. I'm getting tired of making these one-off test clients which take 5 minutes per compile/link, just to test 1 feature in the server. I'd prefer Python since it is OO. Jordy: yeah, fnorb. it's a little wonky, but seems to work. stefan: perl is OO too. Perl is my preference too. graydon: if the only reason not to go with java is that it's not GPL, I donno if anyone wants to try and get a perl ORB working, I'd like to see that.. I only suggest Java because it's ORB integration is quite nice Jordy: I know, I'd really like to develop some stuff in java for berlin as well. are there any free JAVA orbs? aaron: java has an ORB built in Aaron: yes, there are I know TAO has java bindings but it's not really a JAVA orb Jordy: 1.2 has an ORB built in. 1.1 does not. i could have sworn I saw a 1.2 open source java implementation Jordy: I dunno. It would do for testing. I'd hate to develop a dependency on nonfree stuff tho. Graydon: are you speaking of xset ? Jordy: if you find one, _please_ let me know. I would just like us to bear in mind that Berlin can't end up *depending* on java because of its non-freeness stefan: not in particular. I read its source and it's not as well suited as I'd hoped. oh, kaffe defines part of java 1.2, but it doesn't say anything bout the ORB π graydon/#berlin hmms. ok. worth looking into. Graydon: but they made quite a bit of noise about it... ωνω graydon has changed the topic on channel #berlin to: static build & profile static build? why would we want to do that? :) I mangled the build enough to make it statically link, which is necessary for profiling. Jordy: debugging/profiling Graydon, did you look (compile) into what I've send you ? turns out -pg doesn't work at all across dynamic libraries. stefan: not yet. those 2 clients? I removed some bugs which seem now to make the run a bit faster... really? huh, I didn't know that Jordy: yes. pissed me off. stefan: really? which bugs? i did a quick surf of freshmeat and found JavaORB,not sure if it's usefull though: A free Java implementation of CORBA 2.2 so how big is the whole thing statically linked with all the necessary symbols? π Alain/#berlin continue searching with -g -pg it's 27 megs. sheesh. π Aaron/#berlin has to reboot, brb well, first the 'clear all' in the ScreenManager, then I now use a rectangle from the FigureKit. So we can concentrate on inheren timings, not timing due to ORB... nontrivial. also it seems to crash almost instantly into a traversal. ωνω SignOff Aaron: #berlin (brb) anyway, I'd *like* to get "make profiling" working in the build tree. I'm going to put that on the todo list for anyone who really likes makefiles. 27 megs, my lord I can explain how to do it. it's just a pain in the ass. I think I prepared the Makefiles for profile makes. I never did it though. It shoulod compile not into obj/ but into prf/... ok, well I'll put all the info I discovered during the process on the todo item, and that should get us closer.. well wouldn't we just build the libraries with 'ar' instead of ld and then link using -static? ωνω Aaron [aaron@d216.pm13.sonic.net] has joined #berlin there's some difficulty, since the GenericFactory still has to use plugins , sorta. I'm not sure. possibly the plugin loader should actually have a "static" form as well, since otherwise we'll not be able to profile anything in a plugin. Jordy: right, we would need to compile with -pf, too to include the tags for the profiler to hook on. I guess this makes it that huge. not to mention -g if we want debuggin :) 27 megs may be artificially large, since I did -g -pg and turned off -O but I think those are the right flags if you want to do profiling. and my god it's slow! hahaha Graydon: oh, but couldn't we debug *or* profile one kit at a time ? stefan: yeah, I'm just not sure if -pg works nice without -g turned on. anyway this is taking valuable time. I'm gonna have to get outa here soon, so lets move on. by the way, turning of -O should not make code larger, on the contrary... registrar? ok. registrar & styles. ωνω graydon has changed the topic on channel #berlin to: registrar ωνω graydon has changed the topic on channel #berlin to: registrar and styles thanks :) ok, it's been a while since the last meeting where we had that meltdown over how to integrate styles and registrar entries and after much mulling over I'm still no more convinced how to do it. :( Let me explain my current point: i thought about it for about a week after the meeting and decided that it'd be easier just to do styles somewhere else :) only that (1) they *are* related, (2) they should be possible to do efficiently The scene graph is logically tree. (it might be optimized into a DAG though) Jordy: well, the point I guess imo is that some registrar entries are sorta "pattern-ish" as well true, I could implement some style-like features like regex patterns and what not Jordy: like, "text editor component ID" really happens in multiple contexts but building a full system like what X resource files have might be a little overkill Jordy: yeah. it's not strictly a single-path-to-key feature set. Jordy: heh, X resources would be easy compared to XSL template rules, I suspect. Jordy: but this is inconsequential since none of us have actually taken the time to try it. Jordy: I think the X approach is what we should aim at. At least in functionality. (though I don't see the need for the class/instance separation) graydon: there is one feature that I'm contimplating putting in and that would be array data types so one key multiple data settings, an emum basically but from what I can see with the X resource files Jordy: I keep looking at sleepycat.com's page and thinking we're just asking for corruption in the database, writing our own DB. the major reason for using that style of configuration is just to get a number of keys based on a particular regex, and that I can implement Someone brought up LDAP but I think that isn't right. something like, getKeyRegex("/system/berlin/fonts/*/18/bold/*/arial") or something :) i mean if that's all your asking for, I can do that I could also set keys that way ωνω SignOff Chalky: #berlin (Read error to Chalky[p52-max3.mel.ihug.com.au]: No route to host) He, could we forget about registrar and only talk about what styles should support, first ? π graydon/#berlin is so frustrated with this issue. it seems like it should be easier. setKeyRegex("/system/berlin/fonts/*/18/bold/*/arial", "/usr/share/fonts/arial.ttf"); is that all you want to do? *I* think that berlin would benefit from presenting a generic registrar interface so we can tie in other DBs if we choose later on. Have registrar as a server module, you know. Jordy: tree regexes might be sufficient. I don't know. aaron: it's in the TODO file :) he, we are mixing interface and implementation ! I'd really think of what I want (use cases) before thinking of how we get closer to it !!! aaron: i want to rip out that god aweful database implementation I have in there ;) Stefan: agreed so what does the API need to do. So what do we want the Styles to do ? >>> Eugene [eugene@furrypotato.skankybitch.org] requested PING 929621591 290079 from #berlin stefan: the issue in my mind is that most "key lookups" are really component configuration, which is closely related if not identical to component-styling yeah, give me a set of situations where you'd use styles π Aaron/#berlin pipes down I think, Styles are part of the 'external' state of Graphics. ωνω SignOff alexH: #berlin (gotta go...must learn more about berlin :)) "window font size" "application locale language" well wouldn't a window font size be some sort of default setting? :) "background color" Look at a scene graph. You might want to set colors etc. for all the nodes differently. "bevel width" /system/Berlin/settings/currentstyles/windowfont Graydon: right. are there going to be observers looking realtime at registrar settings? Jordy: right, so what if I want to *set* the preference "*/fontsize" == 12 So, somehow, the StyleManager has to look like a *real* tree (compared to the scene graph which might be a DAG) aaron: yes, complete with the ability to watch keys Jordy: or "mozilla/*/fontsize" = 12 ie should one app be able to change another node's settings graydon: that I can do since it's just a basic regex i mean if all you want is filesystem-style regexes that's easy to implement :) if all you want is the equivilent of: echo "12" > /tmp/*/fontsize So, given that, we have the requirement that StyleContexts are nested (since if you only specify values for the root node they should be valud for the whole graph etc.) Jordy: I think you are still argumenting in terms of implementation ! Jordy: but, as we went over in the last meeting, if you'll recall, it inverts the lookup mechanism of the registrar. the stored key is "*/fontsize", which should match a query for "foo/fontsize" and "bar/fontsize" graydon: exactly that's easy, getKeyRegex() would look at the pattern, match it against other particular keys and then traverse their trees to find a matched key, return that key and any others in a big sequence i could set and get keys using that method, no problem jordy: well, echo "12" > /tmp/*/fontsize is not what I mean. that individually sets existing nodes as having 12 as their font size. I'm saying, store the pattern "*/fontsize", and _regardless_ of what is looked up, if it matches that stored pattern, the ke Let one node of the 'style tree' hold a set of name value pairs which the DAG node can choose from. Either it knows the name than it can use it or it doesn't than it might simply pass it to it's children. graydon: I see what you're saying stefan: provide more details oh, you want to store the pattern itself jordy: yes. oh boy, when you start deal with matching regexes.. jordy: that's the fundamental shift between registrar-as-it-is-now and registrar-as-I'm-proposing Jordy: well, not quite, as any query has a specific real instance node in a real tree. won't that start taking lots of resources to just match simple keys? would it not be more efficient to actually store that info in the individual nodes? yeah aaron Jordy: like, mozilla would not look up "*/fontsize", it would look up "mozilla/fontsize" (since it is mozilla). Graydon, Jordy: I'd *not* put the pattern in the tree. I'd rebuild the tree once the pattern changes. The tree may for now look like the logical scene graph *no sharing). So it might specify a map of names/values for a given node and override/extend this pam for child nodes. it would really start sucking down resources graydon: i get it if mozilla/fontsize exists, use it, if not use */fontsize Aaron: no, it's not going to cost anything particularly heavy. Aaron: except our time in implementing it. The point is that you *can* rebuild the tree (which takes some time) once you change the patterns or the settings. You might merge different trees (default, user etc.) given priority info etc. graydon: if you have regexps that might match any key, you have to compare each possible regexp with the key you're trying to find, and regex engines aren't cheap but i'm thining we could probably do defaults much easier than using regex patterns stefan: yes, of course there's an optimized form. you must store the un-merged rules tho, in order to make it editable. now if you use a fallback mechanism where regex matching doesn't happen every time a key is looked up, then you're fine. so nevermind. why not go the windows route, instead of regex's provide a .default sorta setting One important point is to optimize out nodes which don't modify the given map. But that's an implementation detail which shouldn't affect the design the least possible. Aaron: you're assuming linear match through a set of regexps. that's not how you do it. you do it using tree matching with backoff, like a logic engine. Aaron: trust me it's not that slow. ok no, it's not slow... i can think of a few different ways to implement it, but it will either eat up ram or disk space π graydon/#berlin has to go in a few seconds. Graydon: sure, but these rules are not traversed with every traversal while the current tree is. Stefan: yeah, *then* it could get costly. Stefan: how do you cache it? Stefan: such that each traversal does not recompute styles? Graydon: my understanding of the flyweight pattern is that the style is part of the external state so we have to provide it as part of the context , which means that we have to construct it on the fly... stefan: mm.. ok. perhaps. keep talking. sorry, I have to go. time's up. hmmm (constructing means just traversing the style *tree* in parallel) bye gray Bye gray...I'll email my log...:) Graydon--only way i think as of now of free java on linux is japhar and the java compiler that's part of egcs Bye, graydon. stefan: ah. flash of insight. I see what you mean. the style tree is a cache of the unrolled DAG flyweight state. yes. I totally, totally agree. later folks. ωνω SignOff graydon: #berlin (Leaving) fine, Graydon, bye then see ya Gray Hmm, should we discuss this style thing further ? i'm still having problems visualizing the need :) to be honest I can understand using styles to create a look of applications, like mozilla XUL's Hmm, you see the DAG of graphics we use now ? no stef, I haven't really taken a close look at it π Alain/#berlin possible strong suit may well be documentation You *might* want to set styles for any graphics in the scene graph. Though you certainly won't do it we must be prepared for it. I think it is possible to use an implementation which can take advantage of nodes not adding/modifying styles. Jordy: the scene graph contains graphic nodes. We use the flyweight pattern which means that since we really will use a *lot* of nodes to create a scene, individualk nodes will store as least info as possible and recompute as much as possible when needed. right ωνω Chalky [chalky@p4-max8.mel.ihug.com.au] has joined #Berlin [Chalky] Inconceivable! I see your point...take E themes...Berlin will use some window manage function....so some elements of the scene will have a complimentary style...Right? stefan--is the todo list up to date on the website ?? For example individual nodes don't have any idea of where on the screen they appear. Instead, for each layout depending method the 'allocation' is passed with the traversal object. Alain: not exactly. I just proposed some major changes. ok brb well, individual nodes don't have to care about where they are on the screen , they only need to care about nodes which are lower on the heirarchy Jordan: so it seems natural to pass the style together with the traversal since even though you use the same Graphic somewhere, it's style may differ. hmmm ωνω Aaron has changed the topic on channel #berlin to: Berlin: networked, interoperable display server Jordy: nodes may be shared, which means that a node can have multiple parents ! oh man *and* multiple children. give me an example of a node which has multiple parents? simultaneously i understand multiple children the same letter glyph perhaps ok, so instead of having 90 of those glyphs we have one and we assign them to various nodes Jordy: Imagine some vector graphic, for example a car. It has two tires. Since a tire might be somewhat complex, you create it once and use the *same* for both. Jordy: Think of an application on a teachers system that is simultaniously shown on the computers of students. ok, understood instead of recreaging a 'g' for every application that needs a lower case g, berlin creates one and all apps use that. recreating rather alright, a way to save memory basically :) stefan--don't know if it's unrealistic,but could it be possible that the wm part of berlin be configurable with html and/or xml (kinda like active desktop under doze98) Ok, let's stick to letters. Given the letter 'g'. Once you want it to appear green, once blue. so we have this horrible mesh of nodes can fonts be different ? or is an entirely new glyph needed heh, so we have a node with more than one set of properties Jordy: it's actually not *that* horrible. It only looks so because it is highly optimized. However, for the styles we can't use the same optimization. ok, we want 2 'g's, each in two different applications, both seperate colors Jordy: imagine a HBox which contains twice the letter 'g', position 5 and position 11. Now, how are you going to tell them that the first (pos 5) should draw in green and the second (pos 11) should draw blueish ? stef: secondary tree of properties assigned to each node with information specific to their parent node ie, parent=5 property sheet says green, parent=8 property sheet says blue You would need some style tree which the traversal traverses *in parallel* with the DAG so that the letter 'g' (the corresponding class instance) can query the color from the traversal. hmmm *or* a class for children that holds both a pointer to the Graphic_var and some list of properties. and you want to put that hellish thing in the registrar? :) wouldn't it be better just to keep it in RAM somewhere :) so when a property is requested, the traversal moves up one and looks up that property When the traversal calls graphic->draw(traversal) for the green letter, the node should get 'green' when asking the traversal for traversal->style("Color"). Jordy: what if we made the registrar an asynchronous combination of disk space and memory? ;) well Jordy: wait. the registrar (as the DB engine) is just a means to make the settings persistent. Sure the settings for the actual scene graph should be kept in memory. you'd end up with a very slow deal, the problem is the CORBA interface.. why do network calls for the color green when you can store the color green in with the node itself ie, parent->g->color; Jordy: so have a local mechanism for caching recent data in the server parent2->g->color would go to some other place store a topheavy hash tree in memory Jordy: yeah. Now imagine that for a given nesing level of the scene graph you have a set of name value pairs. s/nesting/nesting/g aaron: even with a caching method, we'd still incur too much latency, better to have it stored with the glyph itself in memory there is no need to do 300 registrar lookups for colors every time you paint a text document :) Jordy: if it is kept with the graphic, we reduce the possibility of sharing it a *lot*. Jordy: then apps have to deal with two different DB APIs. maybe if all settings were kept with the scene graph and the registrar were entirely transparent? There might be some answers from some groupware sources...they have to cach.. Jordy: no ! the tree is in memory. you don't lookup anything from the data base when traversing the scene graph. hmmm where's the free CORBA implementations page?? well i'm just thinking how other GUIs do it.. Jordy: all Berlin sees is the Styles presented by the Traversals. The fact that they are stored in an external DB is part of the implememntation. aaron: linas.org/linux Jordy: I think the X protocol is not that bad for this. you know I seriously need this all drawn out :) i'm just thinking about how you'd want to store properties assigned to each widget, and you are right.. they probably should go in the registrar Jordy: if a user changes a setting, it should apply only to one particular DB (which is merged in based on some priority rules). and if you shove a little mini-registrar which is cache-only on each machine running berlin, it would probably work quite well I'll go to bed now. Will the logfile get posted to the list? π Aaron/#berlin attempts to get COPE working Tobias Yes...:) Jordy: I still think that an XML file per application is the right thing. It's the natural extension of app-defaults files and it is *very* extensible. Finally we could specify the whole GUI in terms of the XML file and only code the 'model' in terms of a programming language. Hunger--yes Tobias: I'm logging too, don't worry ;-) Alain & Arrow: That's great. isnt' XML a definition language? you want something like XSL Jordy: sure. which is the actual style language Bye! ωνω SignOff Hunger: #berlin (using sirc version 2.211+KSIRC/981227-pre0.9) Jordy: AFAIK XSL is the style part of XML yeah, XSL/XML would at least make my life easier, because I can understand how to store those types of style defintions i have a byte mag who explain the entire picture of XML Jordy: the whole point would be how to merge two XSL/XML files (based on what rules) if anyone of you would like to have it,let me know so our XSL files would basically be equivilent to the app-default files of X.... see if you are looking for XSL style things, there is a very clear defintion on how to store XSL in a tree Jordy: to start with, yes. Though I'm not sure where to stop. It really seems *very* powerful. Graydon told me recently that Mozilla's approach is to specify the whole UGI in terms of a XML file, so you would need to interpret the XML file by a parser which builds part of the scene graph... but what about properties which change on the fly? :) Jordy: give an example, please. mmm, let me think :) well say we type the letter 'g' in a text editor and change it's color to red ILU has an alpha perl binding the way mozilla deals with styles is a bit much, they use javascript to define how their interface responds brb,have to do a phone call Jordy: well, forget about this thing for now. Just styles. I think the (logical) tree structure is reasonable. The question is then how to reduce (collaps) it depending on where the set of styles really changes (so effectively you only store the diffs) hmm π Alain/#berlin 's back The tree iterator (cursor) would need to implement the needed intelligence to make the tree look real. Or may be that's just the Traversal's job. how soon does this really need to be implemented? Jordy: Hmm, as soon as possible. Sure, we could use default settings for now but right now we use statically bound styles. This gets a bit awkward when the scene graph gets larger. So our styles define, I want every font to be red, I want every box to have a 2 pixel border, etc... when we create a box... we apply the stylesheet to it and it now says it has a 3 pixel border... Jordy: exactly. what you want me to do is store these settings somewhere in the registrar... and I'm just trying to think about how I can :) π Aaron/#berlin plays with cope there are three perl orbs I mean, I'm not sure if regex's are an optimal way to do it... what you want is; a general default, an application specific default, and a node specific default for every single style-related setting so the question is, when you want to construct a font which the style sheet says should be red... how do you want to query the registrar? :) Jordy: not exactly. I'd like to figure out how to design the interface to styles. Once we come up with a reasonable API, we should think of how to implement styles. Once we found out how, we should think of how to make them persistent. And only the very last point involves the registrar (at least how we now see it). Though one day the Registrar might be identical to the full StyleManager which not only cares about persistance but also about all right, we dont' need the registrar for anything but persistance as far as I can think of, settings which are different from the style sheet like window size Jordy: at least I see a tree the best way to keep styles for a running display server. you want a standard interface for doing this... ok, so LoadStyle() everytime we construct a new node on our scene graph ωνω alexH [thanks@cr622414-a.etob1.on.wave.home.com] has joined #berlin LoadStyle(node)... which would go through and check the registrar to see if there is a persistant setting, then check the registrar to see if there's a default setting, and then check the actual hard coded stylesheet to see if there's a default setting Jordy: you should look how allocations are passed to nodes. There is no way asking for a specific allocation. Allocations are passed along with Traversals. Outside they are simply never needed. The same holds for styles. That's why I think we should bind styles tightly with Traversals. huh, the time on my machine must be way off stefan: hmmm Jordy: the flyweight pattern implies that a node can't ask for it's style, only for the set of it's style*s* stefan: so you want to write out a plan of attack on this one? you seem to have the best grasp on the best way to implement it Jordy: which style applies depends on which 'instance' is currently active, which is only known from inside a traversal (since the traversal gives the context (external state) the node needs to make it unambiguos in the sens of flyweight). Jordy: I don't know. I could try though and correspond with you. Would help me documenting the code, anyway :-) π Aaron/#berlin is away: (Auto-Away after 10 mins) [BX-MsgLog On] ωνω stefan has changed the topic on channel #berlin to: documentation (reference manual) real programmers just read the example programs :) π Jordy/#berlin grins He Eugene, I looked into the perceps file(s). alright, basically we need class defintions It seems absolutely doable. i think a document on the API for internal and external usage would be our basics and example usage of each function What we need is a couple of extensions/adaptions. Namespaces are not in there. IDL is not supported (so we need new key words like interface, module, attribute) Then I'd like to be able to write docs for a method like: attribute Color background; //. the background color of the filler isn't there an IDLdoc or something? This is basically done. That is, for C++ grammar, perceps generates docs like this. Jordy--would you like i do a search for such app (IDLdoc) well perceps might do it :) The templates in which you can specify the concrete appearence of the output is a minor detail. Once the perceps script works for us we can attack that. and someone has to write a document on how to document source :) Jordy: Have a look at perceps ! It looks really powerful ! Quite flexible with respect to output format. Jordy: :) should be straight forward once we agreed on it. Perceps lets you even specify this part ! π Jordy/#berlin looks at perceps perceps was made for C++? Yes. ωνω SignOff alexH: #berlin (Leaving) Though it accepts functions, macros and global variables (urgh) hmmm So it should be relatively easy to adapt it to IDL. well there is an IDL -> html converter out there already I find the reference manual from Fresco (in both, the embedded doc style and the output style) quite impressive ! ORBacus does it I know, but it's commercial :) COPE is dead. I'll try for the ILU perl binding Jordy: html is not exactly what we want. docbook is much better. heh you can convert to *everything* based on docbook. i wish there was just one damn document standard :) Right, I once started documenting using texinfo. It seemed quite standard at that time. Now it's docbook. well, this perceps can output docbook? ωνω SignOff stefan: #berlin (Read error to stefan[rubidium.BIOPHYS.UMontreal.CA]: EOF from client) documentation formats are easy to write parsers for. so it's not really that huge of an issue Jordy: it's more of a template system that interpolates data in source files , so it can export to anything btw, has anyone looked at CorbaScript might be useful instead of Python for quick-testing of framework I'm trying to get a perl orb built. that would be cool. better than python anyway AHAH i found one Aaron: let me know how that goes. kdoc can read IDl and C++ headers and generate documents Jordy: bah ;) i thought DOC++ did too Eugene: sure will π Arrow looks at his watch...3 h aand 40 mins....so far can docbook generate man pages? :) argh, i wish we could get the documentation generator part of orbacus that's another reason I ditched cope, it requires services from orbacus cope? The "ROOT" system from CERN has a nice document generator... i swear there must be 15 different document generators out there true :) that all basically do the exact same thing i mean, this kdoc program was written basically because they couldn't get doc++ to work with their broken headers what kind of reason is that for creating a new program? :) all these new-age GNU make replacements are popping up Well do we wrap up the 'offical" meeting..:) I do have to run.. yeah, i should get going too i'd propose yes I'm heading out then ωνω SignOff Jordy: #berlin (Leaving) π Alain/#berlin stop logging That's it... Dave Archer (Arrow) From seefelds at MAGELLAN.UMontreal.CA Tue Jun 15 02:12:52 1999 From: seefelds at MAGELLAN.UMontreal.CA (Stefan Seefeld) Date: Fri Feb 25 22:27:40 2005 Subject: docs: a reference manual Message-ID: <3765B6A4.D9BC87AE@magellan.umontreal.ca> Hey, just some points about docs since I was disconnected in the middle of the conversation yesterday evening. Sure, there are thousands of doc generators. What I dislike about most is that they are almost entirely focussing on html. What makes perceps so distinctive is that we can specify sets of templates which are used to output the data in a given format. We *can* write templates so that perceps creates nice docbook style output. This should be suitable for almost all imaginable formats (prf, info, man, html etc.) However, if we find some are missing or we don't like the way html is generated from the sgml, simply add another set of templates and let perceps directly create html. Really not a big deal. All which has to be done is patching perceps (which happens to be a perl script) so it understands IDL and namespaces, which is currently not possible) plus some patches to make it understand our macros like 'implements(Graphic)' etc. This is the only work which needs to be done. So whoever feels comfortable with Perl and likes to contribute - I consider this an important step. At least I am waiting for that to write API documentation for all the interfaces/classes I wrote within the