OODL: Graphics - PNG and fonts
Someone: Alain, I wasn't aware that PNG was a vector format. Are you sure? Alain: No. Someone: Do you know where I can read the specs. Anthony: I think they are on the W3C's page somewhere. Alain: http://www.w3.org/TR/REC-png.html Someone: Since editing will take place in RAM anyway, the format an image will be saved in is not really important from a programmer's point of view. Alain: My ignorance of "real" programming gave me the impression that graphics, particularly stuff that has to be updated in real-time (like in a GUI for example), had an impact on the low-level programming. In the case of Apple, for example, EVERYTHING that is displayed on the screen is drawn with QuickDraw. How wonderful it is to learn that despite the fact that almost everything calls on the graphics, it is sufficiently modular that the graphics have NO impact on the underlying programming. I guess that previous generation of programmers didn't get everything wrong! ;-) Anthony: GraphicsConvert's best PNG encoding can take a couple of minutes. It can be important. Alain: Is this a one-shot deal? Or does this encoding have to happen every time, in real-time? Someone: The trouble is not the code, but changing the font used for buttons is hairy because you'd have to re-arrange all parts on the card. Anthony: Agreed. We'd want a standard font for UI. Alain: Does anyone disagree with this? Someone: I don't see any problem with allowing to select *any* font as the script-editor font. Alain: Hummm.. That's not really where a selection of fonts is particularly interesting. A monospaced font is just fine here. I was suggesting instead that we have a choice of fonts inside the interface ( menus, windows, GUI components, etc ) like we have now with the MacOS. I must admit that I am a little bit bewildered. I thought that this was a gimme. = __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: GCC is GPL so why aren't we?
Michael Fair: Using the GCC underlying architecture will create licensing problems unless we reimplement the whole shebang. Alain: We must avoid licencing problems. What are they in this case? Anthony: The GPL 'virus'. That is, we'd have to use the GPL. Alain: To be considered GPL we would merely have to insist that derivatives of OpenKard will be open source too, correct? It might not be a bad idea considering my MicroSloth Takeover argumentation, and it would also allow us to legitimately use GCC bytecodes. Michael Fair: Reimplementing the whole thing does not sound like an inviting proposition, so I do not balme one bit. Alain: Can we safely use GCC now, then switch later? Anthony: Legally, probably not :( Alain: Unless we make our licence GPL-like for OpenKard and its derivatives. Alain: Although I have written about this often and recently, it bears recalling once more that I do NOT consider software created with the OpenKard authoring system to be derivative works, and thus would NOT be have to be open source (e.g. commercial interest ). If it were otherwise, all documents typed with MicroSoft Word would be the intellectual property of MicroSoft (for example). Alain: The spread of the "GPL-virus" would thus be limited to OpenKard itself and to OpenKard forks that are OpenKard-like (direct competitors). __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: VM and bytecodes as models
Anthony: Or are you proposing an intermediary "OC byte code"? Actually, I might be switching to something like that -- the parser is giving me nightmares as it is now. And it would allow a lot of stuff like that. Micheal Fair: That is exactly what I am proposing and exactly why I am proposing it. :) I think this would take us into a whole new world of possibilities for xTalk languages. Alain: The VM and bytecodes approach (abstraction layer) . I am not sure what it implies technically for the programmers, but it definitely sounds promising from a developer's perspective. = __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Mail archive
Anthony: I'd like to take a moment to applaud Alain's use of the message archive. Most of this was resolved before, and perhaps we should look at that. We exchanged many messages before what to do about licencing, authoring, etc. and it's all in the archive. Alain: I was merely cleaning up my own mailbox. :) Anthony: Someday, someone needs to build that FAQ -- no doubt drawing from a year's worth of effort, all in the archive. Alain: The only messages left in my mailbox now are ones concerning our organizational stuff. My ultimate goal is an empty mailbox! I am finally getting on top of things. For anyone who does not yet have the URL memorized: http://www.mail-archive.com/opencard@metacard.com/ Alain: Thank you for the reminder, Anthony. The mail archive is a wonderful tool when trying to find an old message that has been classified (lost) or trashed. __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Raising some money
Alain: Will these commercial ventures contribute anything to the coffers of the group so that we can become self-financing? Anthony: What expenses would the partnership have? Alain: Let me start with the administrative stuff: 1. Registering the trademark on the name of our software; 2. Registering the trademark on the name of our partnership (perhaps); 3. Registering our partnership agreement; 4. Registering our collective copyright (optional but strongly recommended). Alain: Let's move on now to the technical stuff: The UFP web server is decreasing in value every day. It will eventually have to be replaced. Software had to be upgraded and maintained on a continuous basis. My free Internet priviledges are going to expire soon. I am not crying out for help, nor am I whinning in order to get some sympathy. I am merely pointing out that one should not presume that everything will forever be available at no cost. Anthony: People could always donate, I suppose. Alain: I suppose (for now) that charitable donations will indeed be only our means of financing. I, for one, am committed to seing this project through to the end, and sink some of my own money into it to achieve our goal. But depending entirely on charitable donations is such a precarious route to take. Our lack of funds may inhibit our development, particularly when it comes time to promote our wares to the World! Anthony: Forking can just mean that you think there is a better way to do it. It is not hostile all the time. Alain: Granted. But forking is nonetheless to be avoided when possible. United we stand, divided we fall ... Eric: So, why not use a corporation? Expense - they cost around 300$ filing fee and about $1000 for lawyers fee. Alain: We could raise that much couldn't we? Anthony: Alain, don't be silly. We don't even have a product -- or anything resembling one, and you want to raise money? Alain: What's silly about about raising a couple of thousand dollars? It doesn't have to business-oriented, nor do we necessarily have to have a product in order to raise some money. The HyperCard List pulled it off so that they could place an add to Save HyperCard. Alain: On another tact, I saw the non-profit scheme for our incorporation as the ultimate means of freeing ourselves from liability and, secondarily, as a means of raising money later on. I have been persuaded by this group, however, that incorporation is out and that partnership is the way to go. __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Sale of OpenKard
Alain: That's ok. We are open source. Our wares are not for sale. They are made available to everyone, for free. The sale of OpenKard would indeed require unanimity because it goes against everything this partnership supposedly stands for. Anthony: Umm? I thought we were going to allow people to make sell NuCard CD's, documentation, support, etc? Alain: Yes, we are going to allow people to make sell OpenKard CD's, documentation, support, etc. Alain: Sorry for the ambiguity. I hope I will be clearer this time. Here goes: OpenKard will be available for free to anyone who cares to download it. To avoid this download and/or to benefit from some value-added stuff, a person can choose instead to buy OpenKard from a vendor (RedHat, for example, or yourself if you wish). Alain: What I was writing about in my previous mail is the sale of the OpenKard project/partnership itself. In other words, a buy-out offer from a company that would make our work proprietary. Anthony: ... NuCard ... Alain: Why are you calling our software NuCard? Is that the elected name? Did I miss the post that announced it? __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: GCC is GPL so why aren't we?
Alain: To be considered GPL we would merely have to insist that derivatives of OpenKard will be open source too, correct? Anthony: Standalones would have to be GPL then, too. Alain: I suppose that you (and Scott) are right that standalones would be considered derivative works. Anthony: We've been over this at length. Alain: Yes, I guess that we have. I am sorry to have dredged this up again without first consulting the mail archive. Having done so now, I am not sure that I have fully conveyed the importance of standalones. So I will state them briefly here. In one word, Encapsulation. Do we really expect each and every user of one our stacks to install the complete unabridged version of the Standard Distribution? And consistently maintain it too? As a developer, one can never be sure that they really have the complete set and/or the latest versions of the components, patches, and so on. And suppose they did do all they were supposed to, flawlessly. There is still no guarantee that an improved version of one of our components will not suddenly break an old stack that functionned well with the older non-improved version of the component. Alain: On the other hand, if everything the stack needs to function well is bundled into the stack (standalone), at the source (developer), then all the right parts are present, the user's system doesn't have to be burdened with the entire Standard distribution, he doesn't have anything further to do to complicate his life, everything works now and will continue to work later, despite version changes in OpenKard (unless the OS breaks the program of course). Anthony: ... if we use the GPL as is ... Alain: We could draft our own unique variant of GPL, with the help of Eric. Isn't that what we are doing already? Anthony: In short, if we use the GPL as is, then all standalones must be under the GPL. If we add a clause exempting standalones, all I have to do to make it closed-source is create a standalone. The GPL would work, were it not for these problems. Alain: If this means that, in order to protect ourselves against a MicroSloth takeover by using GPL, we must forego the advantages that standalones would have represented for us, then so be it. Alain: Although I have written about this often and recently, it bears recalling once more that I do NOT consider software created with the OpenKard authoring system to be derivative works, and thus would NOT have to be open source (e.g. commercial interest ). If it were otherwise, all documents typed with MicroSoft Word would be the intellectual property of MicroSoft (for example). Anthony: Your analogy does not hold. MS-Word documents do not contain any portion of MS-Word in them. The contain no intellectual property created by MicroSoft. Alain: Bad example, I guess. How about HyperCard? Or other softwares where the distinction between program and data is blurry. I greatly appreciate the fact that we can create HyperCard standalone programs without any licencing restrictions whatsoever. Its a really big plus. If proprietary Apple can be so generous, why can't we who profess to be open and free be as generous? Anthony: OpenKard standalones, however, contain the entire OpenKard engine -- quite a bit of GPL-covered intellectual property. Alain: So do HyperCard standalones, but your point is well made though. If we want GPL protection, it is likely that we will have to forego standalones. Alain: Besides, given the fact that our engin is not ready yet and, consequently that we will be using MetaCard's engin for the time being, we cannot allow standalones because MetaCard's engin is not open source. Anthony: OpenKard stacks would be fine ... Alain: You are agreeing with me, are you not, that stacks created with the OpenKard authoring tool would not be constrained (infected) by the GPL-licence? Alain: The worse part about not allowing standalones is the fact that we would oblige our users to get, install and maintain the entire Standard Distribution to run their OpenKard stacks, albeit for free. The alternative to standalones that I envision now would be to provide an open source PLAYER of OpenKard stacks. Alain: Does Scott already make available a free player? Would he be willing to provide one? In the negative, we will have to wait for our own to be developed. What will our end-users use to run their OpenKard stacks while our engin/player is not ready? Anthony: ... except perhaps for any icons and resources copied from OpenKard -- but those can be exempted fairly easily and without disasterous consequence. Alain: Good. __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: PrettyPictures attachments and MS
Eric: Oh dear, more pretty pictures... Please look and let me know what you think. Alain: I was NOT able to download the pictures, Eric. The problem is probably due to the fact that I am using a free commercial mail account that sports a Web interface (only). Sometimes it works, sometimes it doesn't. Alain: The ideal thing for me, and for the group too, would have you FTP the stuff to the (centralized) UFP server. That way, everyone who is interested can obtain them, and it doesn't weigh down our E-mail with hefty file attachments (present case excepted, e.g. tiny). Alain: There is also the matter of your file format. Why are you using MS-Word? Could you use something else instead? ( like PDF or HTML, for example ) Alain: Not using MS products is as much a practical decision as it is a political one (for me). Open-Source is to MS what David was to Goliath, except that in this case David is (the collective name of) the Community. __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Free CVS hosting - Libundo
Alain: Anthony posted a message yesterday concerning free open source project hosting. Here's one of the projects that are currently being hosted. This clip seemed particularly interesting to me : Clip: Libundo is a simple, easy-to-use lib which manages recording and playback of undo/redo info for app developers. Alain: Infinite undo/redo would be a wonderful feature for OpenKard. It could also make OpenKard recordable. Clip: It is designed to be simple to plug in to existing apps and require only a min amount of support code be written to support multi-level undo/redo. Libundo handles all the details of determining what has changed after an undoable action is performed, recording that info and saving it for use when an undo is performed. Alain: Why re-invent the wheel? Clip: Libundo is available under the GNU GPL ... Alain: The infectious licencing scheme that we are perhaps leaning towards also. Clip: ... and is not tied to any GUI libraries or application frameworks. Alain: Modular middleware that will allow us to use the GUI libraries and framework that WE chose. Got to like it! Clip: Libundo has a C language interface. Alain: Right up your alley, guys! Clip: Libundo does require the ability to do Unix-style memory mapping. Alain: Is any one or everyone of our programmers familiar with this "Unix-style memory mapping" ? __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Eric's Graphics
Hey everyone! Check out and/or download Eric's OpenKard Graphics : http://ufp.uqam.ca/OpenCard/Graphics/index.html Your list-mommy, Alain __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Top-Down versus Bottom-Up
Anthony: BugTracker is nice, but you should add directions which btn does what, and what info is needed to complete forms, etc. Some btn names are less than self-explanatory. Documentation? Yes, I should add that. Dang it, it's not even beta :) Alain: What a classic programmer dilemna this is. 1. Do I spend most of my time coding intuitively, then document my resulting work later? And, consequently, documentation always lags ... Why wait for the docs to be ready to release the software? 2. Or do I design everything on paper beforehand and maintain this documentation during my development work? Alain: I know the second choice is the textbook answer to this dilemna but, in real life, it is more often the first tactic that is used instead, eh! (myself included) Alain: Furthermore, I am increasingly convinced that the classic Top-Down approach (choice 2), while laudable, is just not realistic. I now favour the Bottom-Up approach, as do (some) researchers in Artificial Intelligence and in Artificial Life (in particular). Broadly speaking, it it the recognition that software systems, despite their underlying binary logico-mathematic formalism, are nonetheless systems that are dynamic, non-linear, etc. And that these complexities are difficult to fit into the old linear ways of building systems. __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: The Future of Interpreter
Anthony: Bison will not be used in the next Interpreter. Instead, I intend to write my own parser-generator tool, which will be done in (yes) HyperCard. Maybe portions in other things, but I doubt it. It will at least have a pretty, HC front-end. Alain: Surely Perl would be a much better choice for a parser-generator tool (e.g. pattern-matching with GREP), particularly for someone like you Anthony who is already familiar with Perl. What is more is that you don't have to forsake your HyperCard interface in the process because HyperTalk and MacPerl interoperate quite well. Anthony: It is named "NuParser" :) Alain: Of course. It will go well with NuCard if that's the name that we elect for OpenKard. Uli: Remember to encapsulate platform-specific code in an own class. That is, a class XMemory for memory management, a MacMemory class for Mac-specific memory management (that can be replaced with another XMemory-derived class e.g. if you want to compile for Windows). This way, unportable code will require few changes. Abstraction is the concept to use. Thanks, autographs later. g Alain: Bravissimo! I like it. It makes me think of the MacOS with its managers and all of that. Anthony: LOL. It'll probably use malloc/free. Alain: Standard ANSI C methods for memory management. A solid choice (probably). Q. Don't you care that it will be slower? A. No. Q. Why? A. Because the parse will be done once, at script save. If it takes 1-2 secs to save a script, big deal. Alain: Good answer! It's not my goal to fragment the xTalk language (at least not yet) Alain: I am not sure who wrote this (Uli or Anthony) but I am intrigued. Sounds like someone (besides myself) is considering a MAJOR rewrite of HyperTalk and lots of changes for HyperCard too. I have been brainstorming this intensively for the last 4 days (though i have been doing this on-and-off for a decade now). One inevitable conclusion is that 100 percent HC-compatibility might be un-advisable, after all. Alain: A wise person once wrote that every act of creation is always preceded by an act of destruction. From the ashes of our dying HyperCard (caterpillar), OpenKard will emerge with renewed vigour (butterfly). The OpenKard stage will be quite different than its previous incarnation -- for the better, I say. Kind of like a Pokemon, I suppose! ;-) __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: OpenKard Web pages
Good evening, y'all! Check out my new Web pages (below). PS: I strongly suggest a large screen at high-resolution for viewing these pages. http://ufp.uqam.ca/OpenCard/index.html http://ufp.uqam.ca/OpenCard/OpenKardNames.html http://ufp.uqam.ca/OpenCard/Qualifications.html http://ufp.uqam.ca/OpenCard/WhatsNew.html http://ufp.uqam.ca/OpenCard/Graphics/index.html That's it until tommorow. z __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: How to write unmaintainable code
Anthony: I suggest we make the following our official style guide: http://mindprod.com/unmain.html OK! Just kidding... Alain: (laughter) Alain: I was indeed fun to read the sarcastic article that tells you how NOT to do it. All kidding aside, we can use this as a counter-example in our guidelines. Thank you for this useful contribution, Anthony! __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Libundo - undo/redo and memmap
Clip: Libundo is a simple, easy-to-use lib which manages recording and playback of undo/redo info for app developers. Alain: Infinite undo/redo would be a wonderful feature for OpenKard. It could also make OpenKard recordable. Uli: I think we can do undo the way SuperCard does it, that is, it's part of our editor (a stack). We'd keep track of the last change in a global, and maybe we'd make it an array of sorts so we can track multiple undo steps. Alain: Whatever way you programmers feel is best is fine by me. Wouldn't it be better to avoid global variables for this recording of user-actions? I think that one or more new functions or properties would be better. get the last userAction get the prev userAction get the next userAction get the first userAction Uli: Undo is really not that complicated. Alain: It depends on the action taken, doesn't it? From a user's perspective, the "undo" menuItem is sometimes disabled (e.g. cannot undo certain actions). For the irreversible actions to be made reversible, the system will have to keep intermediate versions (one for each irreversible action). Please tell me that I am wrong. Uli: And since memmap isn't available on Macs, we can't use libundo anyway. Alain: Is there some fundamental reason why the Mac does NOT do memmap? Why isn't it available on the Mac? Is the Mac the ideal platform for the development of OpenKard? __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Re: OODL: The Future of Interpreter
Anthony: Bison will not be used in the next Interpreter. Instead, I intend to write my own parser-generator tool, which will be done in (yes) HyperCard. Maybe portions in other things, but I doubt it. It will at least have a pretty HC front-end. Alain: Surely Perl would be a much better choice for a parser-generator tool (e.g. pattern-matching with GREP) Anthony: Nope -- not powerful enough, IMO. For writing this parser I'm going to be doing some serious pointer work -- and Perl does not let me do that. Does Perl even have pointers? Alain: Perl doesn't force us to do any low-level memory-management stuff like C does, so I also doubt that Perl has any pointers. They could probably be improvized though. Anthony: Besides, Perl is less portable than plain-ol-C. Alain: Time and time again, Anthony, you have made it abundantly clear that you definitely prefer C over Perl. I understand. C is much more powerful because of its low-levelness but, consequently, its also has a MUCH steeper learning curve. C is not for the faint at heart! Alain: But, more to the point Anthony, you wrote above "I intend to write my own parser-generator tool which will be done in (yes) HyperCard". So I believed that the comparison being made was between HyperTalk and Perl. I like HyperTalk's chunking ability .. always have .. but it still doesn't compare to what you can do with Perl. Alain: Bottom line is that each environment has its own area of specialization, and thus they all have their place at one time or another. Anthony: It's not my goal to fragment the xTalk language (at least not yet) Alain: I am intrigued. Sounds like someone (besides myself) is considering a MAJOR rewrite of HyperTalk and lots of changes for HyperCard too. Anthony: Well, not a major rewrite. Alain: I overstated myself when I said MAJOR rewrite. We want to approximate HyperTalk as it is known and loved today, that's for sure. But there are things that are no longer relevant and some that never were: debug hintBits, debug pureQuicDraw true, debug maxmem, dial, heapSpace, annuity, etc. Furthermore, the scriptEditor's global variables should be properties instead. The HC-managed Applications, Documents and Stacks global variables should be functions instead, and they should be completely managed by the app instead of one or more handlers in the Home Stack script. I could go on ... Anthony: At least not until version 2. Alain: ... but I didn't want to confuse the issue too much by suggesting a million different changes before we have at least a working first version that is quite similar to the HyperTalk we all know and love. Anthony: But some alternatives to the syntax os some commands would be nice. Alain: Indeed! I have PAGES of new syntax, most of which are add-on instead of remove-from or transform-into. In other words, a superset. Hence, they will not make OpenTalk incompatible with HyperTalk (for the most part). Differences could be handled easily at import or compile time. Anthony: All in all, with the bytecodes, you can code in whatever HT language you choose. Alain: That's ...GGRRrreeeaaattTT! (as Tony would say) __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Re: OODL: The Future of Interpreter
Alain: Perl doesn't force us to do any low-level memory-management stuff like C does, so I also doubt that Perl has any pointers. They could probably be improvized though. Anthony: Yes, it could be worked around. But I'd prefer to keep as many hacks out of it as possible. Alain: You're absolutely right. Good principle. Anthony: The regexp support is tempting, but not enough. Besides, if I want regexp, I can always grab a regexp package. Alain: A regexp package for C/C++, correct? If so, then things couldn't be better. Alain: Clearly you definitely prefer C over Perl. Anthony: I prefer perl for a lot of quick prototyping short things which don't require the most speed possible. Alain: How about the rapid-prototyping of new NuTalk syntax? I am/was considering Perl for this. Otherwise, I will either have to learn C/C++, or merely suggest new syntax to our programmers - which they can choose to do or not (of course) - Both are not really satisfactory. Alain: Is it (or will it become) possible with the current arrangement for us non-programmers to prototype new NuTalk syntax? Anthony: When I want to do something longer, or need speed, or need to play with memory, it's either C or C+. Alain: Of course. It makes sense. Anthony: Or sometimes even assembly :) Alain: Showoff! ;-)) Anthony: I don't like playing with the low-level stuff except when it makes it easier, or faster ... Alain: Nothing faster or more efficient than assembly, that's for sure. One can do wonders with a mere 1K, too! Anthony: ...[and I need it faster]. Alain: This need-for-speed, Anthony, is it specific to something that you are doing, or is it just the general principle that faster is always better? Anthony: HyperCard is not actually going to do the parsing. It's going to handle the grammar, and spit out C/C++ to do the parsing. Alain: Could you please clarify the meaning of "handle the grammar". Do you mean by this that the NuTalk sentences are broken down into their generic functional syntactical components (verb, subject, object, etc )? If so, then what do you mean by "parsing"? Alain: But there are things that are no longer relevant and some that never were: debug hintBits, debug pureQuickDraw true, debug maxmem, Anthony: We'll probably keep a lot of 'debug' commands and even add a bunch more -- those commands were never intended for end users; they were intended to help debug HyperCard. We'll need simular commands to debug NuCard. Alain: As long as they are genuinely useful. Also, we could package them separately. After all, they are for programmers only. Why include them in the user-friendly scripting syntax for the rest of us? dial, heapSpace, annuity, etc. Anthony: But why are dial and annuity obsolete? Alain: No one is using or will use HyperCard/NuCard for calculating annuity and compound interest, nor are they using it to automate their phone calls. There are better software packages out there for Statistics and for phone automation. Alain: If we must include them, then include them as separate packages that offer much more than is currently offered in this regard. Lets keep the base syntax of NuTalk focused on the essentials, at least for the first version(s). Alain: The HC-managed Applications, Documents and Stacks global variables should be functions instead, and they should be completely managed by the app instead of one or more handlers in the Home Stack script. I could go on ... Anthony: Why not properties as well? If a stack wants to add to them, why not? Alain: We could do them as properties. But properties are usually reserved for small-sized values. The listing of the paths of all of the Documents, for example, is much too sizable (in my opinion). Furthermore, Documents and such are not PART of HyperCard. They are part of the surrounding environment. Anthony: Also, I think they should completely be managed by the Home stack. Right now, HyperCard performs some magic with them, and you're never quite sure why it works. Alain: I disagree. If something that you would rather not attend to, gets done automatically and without your knowledge, then where is the problem? Anthony: NuCard would perhaps call a function in the Home stack, perhaps called "NuCard:FindStack" to find the stack. That function would be responsible to find it in the search path, and update search paths. Alain: Why doesn't NuCard simply do this automatically and invisibly, without using the Home stack? Anthony: Also, the user could customize the stack search this way. Default behavior in HC is to use the first stack found, but the user could customize NuCard to prompt which stack to use. Alain: set the multiFindDialog to logical Anthony: The user could even customize it to do a full search on the hard disk to find it. Alain: It should do this automatically when the preliminary search in Documents (and such) fails. Or we could provide a another new property: set the searchFileSystem to logical
OODL: undo/redo and open sesame
Anthony or Uli: ... but internally it would still be some sort of global, even if it doesn't pollute the scripter's namespace for globals. Alain: I have no problem with globals that are internal to the OpenKard application. Anthony or Uli: Somehow I don't think the scripters care about our namespace. Alain: They don't care about the internal globals, but I for one believe that the user's globals be reserved for the user's globals. Its a small detail, granted, but we should try to make OpenKard as coherent and as simple as possible. Variables that the user has not declared, some of which should be changed (or else crash), should not be accessible to the user. Anthony or Uli: OTOH we could add UNDO for images and text into OpenKard itself, but this isn't much of a problem. If you can copy and paste, you can implement undo. We can do it more efficiently in OK. Alain: Wonderful. I believe that an infinite undo/redo feature is a major plus for OpenKard. It takes interface forgiveness to new heights! Alain: And it will, besides, force us to integrate a sophisticated backtracking system that could be exploited for some REALLY interesting applications. Recordability and agents come to mind. Anyone in this group ever hear about Apple's technology demo entitled "Open Sesame" ? __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Top-Down versus Bottom-Up
1. Do I spend most of my time coding intuitively, then document my resulting work later? And, consequently, docs always lags ... Why wait for the docs to be ready to release the software? 2. Or do I design everything on paper beforehand and maintain this documentation during my development work? Alain: I know the second choice is the textbook answer to this dilemna but, in real life, it is more often the first tactic that is used instead, eh! (myself included) Anthony: I'd say the first tactic is better. Far better. Alain: In practice, I agree with you Anthony. It's what I have always done, in fact, because I always worked alone and also because my customers were very easy-going about these formalities (because they were paying a mere fraction of what it's worth). But the larger projects are now requiring me to rethink my haphazard methodology (habits). Larger systems are inherently more complex, they often require the collaboration of several people, and thus they require more planning and coordination, which in turn requires some kind of reference that everyone in the project can be guided by (e.g. docs ). Anthony: I find it silly to write TFM before there is software to write it about -- you'll just end up re-writing the manual anyway. Alain: A lot of details do indeed change during the development, testing and revision phases of a project, but they should be in large part implementation DETAILS. The overall architecture and functionality of the system (that the docs establish) should not be dramatically affected by them. Anthony: But, even better is the side-to-side method. Alain: An approach that combines Bottom-Up with Top-Down is probably the best pragmatic strategy (for now), in ComputerSci as well as in Educational design. Alain: The Top-Down approach has always received the Lion's share of developers attention, so we should probably concentrate on the MUCH-less popular Bottom-Up development strategy (equity). Besides, given our present difficulties at arriving at a consensus on features (on anything in fact), it seems natural to use a Bottom-Up approach. Everyone builds the individual parts that he wishes, and we weave all these disparate parts together later on. If this sounds risky, then you understand why the developers of the Top-Down approach nearly always prevail. In fact, they often have no other alternative because the people that finance projects are an insecure lot that insist on forecasting the outcome before they invest their precious capital. But, since we are not looking to be financed, we have the luxury of choosing the Bottom-Up or a combination of the two. On a final note, I would like to point out that my studies in Artificial Intelligence and Communication have persuaded me that the Bottom-Up approach to AI (e.g. A-Life) is the most promising one for achieving this lofty goal. Anthony: Think Differently g. Alain: Evolving artificially-alive intelligent learning agents ... How's that for thinking differently? __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
OODL: Prototyping OpenTalk syntax
Alain: A regexp package for C/C++, correct? If so, then things couldn't be better. Anthony: Except that regexp is slow. I don't really need it -- at least not for what I'm doing now. Alain: the short answer is YES then. Anthony: You won't have to learn much C++. You'll have to learn the syntax for NuParser. You'll have to learn a little C++ to bytescode and possibly assemble the new instructions you add. You'll have to learn NullCPU assembly. To add a new command, you'll have to change the NuParser. Not too hard. Then you'll have to add a little to the translator. Then, if it is not already part of the bytecode, you'll have to add some to the compiler. Alain: Sounds like a lot to me! In any case, you are confirming that I will need to be somewhat proficient with C/C++ to contribute to OpenTalk's syntax. Correct? Anthony: ... but from your HC Syntax webpage, you probably already do. Alain: You're too kind. HyperCard's formal syntax is a cinch compared to what you described above. Add to that all of the software that I will have to buy, learn, etc: language, compiler, MPW, etc. Alain: Is it (or will it become) possible with the current arrangement for us non-programmers to prototype new NuTalk syntax? Anthony: It should be. Alain: The arrangement that you outlined above? Can you provide us with an easier way to prototype new OpenTalk syntax? Templates or ... something ? Anthony: We'll probably keep a lot of 'debug' commands and even add a bunch more ... Alain: Why include them in the user-friendly scripting syntax for the rest of us? Anthony : We don't. That's why they're undocumented. But we leave them in the executable because: a) It's more work taking them out b) Allow a user track down a bug. Alain: Fair enough. Anthony: But why are dial and annuity obsolete? Alain: No one is using or will use HyperCard/NuCard for calculating annuity and compound interest, nor are they using it to automate their phone calls. There are better software packages out there for Statistics and for phone automation. Anthony: And why should one not be able to write such a package with NuCard? NuCard is development tool -- and should be able to do stuff like that. Alain: You are going to need a lot more than a "dial" command to offer a genuine value-added phone solution with NuCard (in my opinion). Alain: If we must include them, then include them as separate packages that offer much more than is currently offered in this regard. Lets keep the base syntax of NuTalk focused on the essentials, at least for the first version(s). Anthony: We're not designing a RISC chip here, Alain. Alain: Simpler means less complexity, less bugs, less work to do (on marginal commands like dial for example), quicker time to market, simpler for the user to learn, better performance, and perhaps some other advantages that don't come to my mind at this time. Anthony: Annuity and dial functions are not that hard, and VERY, VERY, VERY easy compared to plugin extension of the syntax. Alain: Fair enough. Alain: Do you envision that we will eventually have a plugin interface? Or do you recommend that everything be integrated directly into the source code, given that we are open source? Alain: The HC-managed Applications, Documents and Stacks global variables should be functions instead, and they should be completely managed by the app instead of one or more handlers in the Home Stack script. I could go on ... Anthony: Why not properties as well? If a stack wants to add to them, why not? Alain: We could do them as properties. But properties are usually reserved for small-sized values. Anthony: The script property of buttons, fields, cards, backgrounds, and stacks Alain: By convention, the script is a property because each object possesses one. But isn't it just a (brief) reference to a container managed by the Script Editor XCMD? Anthony: The contents of? Alain: Is the content of a field considered a property of that field? Not formally, eh, but I guess that it is in practice. How does HC handle fld-content internally? Anthony: Also, I think they should completely be managed by the Home stack. Right now, HyperCard performs some magic with them, and you're never quite sure why it works. Alain: I disagree. If something that you would rather not attend to, gets done automatically and without your knowledge, then where is the problem? Anthony: It will be done without any effort on your part, by the default home stack. Alain: My Home Stack Script is sacred. So much of my generic stuff belongs there that the 30K limit is never very far. The fact that the application will deprive me of some of this meager space, by including one or more handlers for managing something that should be invisible to the user, is best avoided in my opinion. Anthony: But when you do want to attend to it, I assure you most people don't want to spend all day reading NuCard source code. Alain: How about
OODL: Prototyping OpenTalk syntax - Favorites and doMenu
Anthony: I thought we were talking about search paths, not bookmarks? Uli: Me too. Bookmarks can be implemented easily by hand. Not a feature for OC. Search paths are what's required to find stacks on a certain computer. Alain: Why are you both assuming that i was talking about bookmarks?? I was indeed talking about search paths. Anthony was suggesting that my approach of having OpenKard manage the search paths internally would make the Applications, Documents and Stacks non-accessible to the user for customization. In response, i suggested some new OpenTalk syntax that would allow the user to customize search paths, despite the fact that they are handled internally. This new OpenTalk syntax was inspired from AppleScript's favorites feature, but my spin has nothing to do with MacOS favorites or with Web bookmarks. Domenu relies on the name of the menu item. What about localized versions of OpenCard? Alain: I have scripted HyperTalk in French in my time, so here is how it works: The English menus and menuItems are always available to a script, despite the fact that they may not be present in your French menubar. French menuItems are converted to their English equivalents by HC's Translator Interface BEFORE they are interpreted by HyperCard. Same goes for anything typed into the message box. You activate all of this by setting the language property of HyperCard to the name of a WTRN resource. In my case, the WTRN resource's name was "French" and it mainly contained English--French string substitutions. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Prototyping OpenTalk syntax
Anthony: You can call the built-in functions of HyperCard directly and bypass any user-defined functions by using the word "the" before the function name. Uli: I wasn't aware of that. Alain: Anthony is indeed right-on-the-money. Uli: Well, then we can't use that to call user functions in a more English-like way. Alain: I have been thinking along these lines too. Making OpenTalk more English-like than HyperTalk by liberal-usage of the "the" keyword. The parser would merely have to ignore this keyword when interpreting a script. Alain: We would indeed lose the bypass-the-hierarchy feature of HyperTalk functions called with the "the" keyword. Is it really useful? How frequently is it necessary? Couldn't the scripter merely "send" the message to HyperCard explicitly when the bypass feature is deemed necessary? Or perhaps some syntax like below: the abs [of HyperCard] of numericEpression 1. the abs of numericEpression -- traverses hierarchy 2. the abs of HyperCard of numericEpression -- NOT __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Prototyping OpenTalk syntax
Alain: This new OpenTalk syntax was inspired from AppleScript's favorites feature, but my spin has nothing to do with MacOS favorites or with Web bookmarks. Anthony: The problem is that your syntax will only allow paths ... Alain: What makes you say this ?? Anthony : ... whereas having the home stack handle it (and, btw, your syntax would be part of this) allows searching in any method the user can conceive. Alain: Scripting the search-strategies is indeed a valuable feature, but I am also wondering to what extent the search-mechanism should be externalized and put into the hands of the user, and how much should reside inside the application itself. Alain: How much limited script space (chars) are going to be occupied by this search-feature? How likely is it that users will toy around with such a complex feature? How reliable will their changes be? What if users inadvertently changes (a search and replace all, for example) or deletes these critical handlers? It happened to me when I was a HyperCard newbie, and I wondered for years why this path-feature never seem to work for me as was suggested it would in the many HC-related books that I read. Alain: Could we objectivize handlers? In other words, treat individual handlers inside a script as an instance of the handler-class. Each handler could thus have properties: like dontSearch, dontChange, dontRemove ... for examples. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Documentation and commenting of code
Uli: I don't care whether the docs are written before or after the code, as long as you don't see this as an excuse not to comment your code. Alain: You're absolutely right, Uli. Well-commented code is very important. Uli: If you extensively comment your code, someone else can later write the docs while you keep coding away. If you don't comment, we're all off to a bad start. Add extensive comments, why a check for a variable being NULL is there, why you add or subtract 1 to nudge an image, what part of a graphic is drawn, for what tokens which exception in code handling is. Mark everything one would have to look up, etc. If we do that consequently, we'll have maintainable code, ... Else, we'll have to re-write everything every 6 months... Alain: I wholeheartedly agree. Uli: if the concept is good. Alain: That's what documentation BEFORE would be good for: 1. good design (concept) 2. good planning 3. improved coordination (we are a group after all) __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Prototyping OpenTalk syntax
Alain: This new OpenTalk syntax was inspired from AppleScript's favorites feature, but my spin has nothing to do with MacOS favorites or with Web bookmarks. Anthony: The problem is that your syntax will only allow paths ... Alain: What makes you say this ?? Anthony: Because you're defining a property which stores search paths, correct? Alain: Yes, I am defining a property which stores search paths but does this necessarily exclude other path-like references (like URLs for example) ? The script property is quite liberal with its contents. Alain: How much limited script space (chars) are going to be occupied by this search-feature? Anthony: First off, THERE IS NO 30K LIMIT. There is not a problem with limited script space, period. Alain: Is the limit raised (to 64K like MC, for example) or is there no limit whatsoever? Anthony: Second, these script should be but a few lines, I'd guess. (HANDLER) This would, btw, be the built-in algorithm. Alain: So you agree then that part of the search-paths process should be internal to the application ... Alain: What if users inadvertently changes (a search and replace all, for example) or deletes these critical handlers? Anthony: If the messages reach NuCard, they'd be handled internally. So it won't be catastrophic if you delete them. Alain: ... with internal defaults for the externalized portion of the search-paths process, just in case the user misuses or deletes the Home-stack-handler(s) that manage it. Great! Anthony: And there I go informally proposing syntax again. Alain: What's wrong with that ? Alain: Could we objectivize handlers? In other words, treat individual handlers inside a script as an instance of the handler-class. Each handler could thus have properties: like dontSearch, dontChange, dontRemove ... for examples. Anthony: This would be a major change for HyperCard ... Alain: Yes it would, but it would not make us incompatible because its new functionality (superset). Anthony: ... and would be better discussed on a different thread (translation: let me think about it) Alain: Fair enough. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: OpenTalk syntax - DO and SEND
Anthony: I don't have a problem bypassing the message hierarchy; that can be done easily. Alain: Good. What do you propose? Anthony: I do have a problem with building commands at runtime. Alain: This and the above are two different issues. SEND does not necessarily involve "building cmds at runtime" We thus keep SEND, right? Want to guess how many existing HC stacks become incompatible with OC if we don't support do, send, and run-time variable naming? Alain: LOTS! Anthony: Not too many. Most I've seen don't make use of do. Alain: There was a heated discussion on the pros and cons of HyperCard's DO command on the HC-List. Most contributors to this discussion were insisting that the DO command is one of HyperCard's hottest features. I am among them. Anthony: Most that use send only use it to send a mouseup to a button; quick fix will work there. Alain: I also use SEND a lot. One cannot mix several scripting languages inside the same script, so I put a lot of my AppleScript and MacPerl scripts inside hidden buttons that are remotely-controlled by the stack script. I also use SEND to extend HC's stacksInUse to more than 16 stacks. And I am sure I could think of many other good reasons for DO and SEND if it becomes necessary. Anthony: As for runtime variable naming, hashes can be used instead. A fairly quick fix. Alain: A fairly quick fix for runtime variable naming that doesn't affect the Interpreter. Sounds great. Let's do the same (or a similar trick) to keep DO and SEND in NuTalk/OpenTalk. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: VOTE RESULTS - FreeCard and FreeTalk
Uli: sorry, I was just waiting for people to send in some more votes, but I didn't get any additional ones. There were only 6 votes being sent in :-( Alain: It will have to do for now. Top 10 list: 1. FreeCard 2. HyperRAD Alain: It is nice to see (for me) that my suggested name got second place. Alain: FreeCard is a better choice after all because freedom (lofty) and free-of-cost (concrete) are defining caracteristics of our collaboration. HyperRAD is less appropriate than FreeCard because of the fact that FreeCard will be more than a Rapid Application Development tool. Uli: So I guess FreeCard it'll be. Any objections? Alain: FreeCard it is. Alain: Our scripting language is likely to be FreeTalk. Otherwise, I'd like calling it OpenTalk, but the link between OpenTalk and FreeCard does become a little less obvious than the link between FreeTalk and FreeCard. Alain: What do we name ourselves as a group of persons? As opposed to the name of our software (FreeCard) and the name of our scripting language (FreeTalk). It will simplify the drafting of our licences if we can refer to ourselves as a group with one simple name. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: The DO command
Date: 7 Dec 99 08:42:14 +0100 From: "Jean-Jacques Wagner" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] In response to Dan Gelder (Serf) : Jean-Jacques : But you said you will "not" support the do command in Serf. Alain Farmer : Is that correct, Dan ? Alain Farmer : Does Serf support the DO command ? Alain Farmer : Will Serf support the DO command ? mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Names - FreeCard and FreeScript
Julian Blackhirst : Does our script language have to end in "talk"? So many already do that a beginner could become confused and it makes you think it is associated with speech software. Why not call it "FreeScript", or something else. Anthony : I agree! And it sounds _much_ better, too. Alain : Sure. Why not? FreeScript it is (for now). __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: OODL: GUI
eric-engle : Sorry for my absence, struggling to slay the dragon Thesis... Alain: How do you feel about working on FreeCard's legal issues once again? eric-engle : My understanding is that we the GUI we are developing will be substantially different from that used by MC, and will not be merely cosmetic changes. Alain: That is my understanding too. eric-engle : In MC we have "folders" which present all object attributes. I actually do not have a problem with this approach. Alain: This is an inefficient approach, I am told. FreeCard will be using XBF for file-format stuff. eric-engle : In fact, I find the MC GUI at least adequate. Certainly I think that cosmetic changes are necessary ... Alain : Adequate, but people expect more from software that costs $995. eric-engle : ... beyond that, I must ask what our objectives are. Alain: Good question. eric-engle : I think the MC GUI takes up lots of desk space (six open windows is actually not uncommon: tool palette, scripteditor, object editor, and maybe home and help...) but that will be adressed by changing sizes of the stacks in question. Alain: This is a very frequent complaint leveled at a lot of current softwares that are over-burdened with features/windows. A challenge we will have to face up to as well. eric-engle : A simple 'facelift' of the MC GUI would be an improvement, and can be presented soon (in fact, I am prototyping a version with a 'cream' background, blue textfont, using chicago and monaco...) but before I do the palette (gradient shades of gray create a 'metallic appearance' and will reverse - requiring 32 different icons ... Alain: Notify us when it is ready, Eric. eric-engle : ... in HC just an afternoon, but in MC will take 2 or 3 days). Alain: Clues as to what we need to change to make the GUI easier may be gleaned from the difficulties that are slowing you down when you use MC instead of HC. eric-engle : ...because I'm still a beginner. Alain: Beginners are the best testers because they have to infer what to do and how to do it by reacting to what the GUI provides, instead of counting on experience to fill the gaps. eric-engle : I want some 'feedback' on our Grand Objective: Is it to create a completely different interface. Alain: You could say we have 3 sub-projects. There is the FreeCard application, the FreeCard GUI, and the FreeScript scripting language. MetaCard is a temporary stand-in for the first because MetaCard wants the 2nd. eric-engle : if so, in what respects? I honestly feel some simple cosmetic changes would be sufficient ... Alain: MetaCard is a temporary stand-in. Do not focus merely on that. eric-engle : ... however I am happy to go 'one step beyond' ... Alain: What should the ultimate interface be like ? eric-engle : ... after people tell me where to go Alain: Do not sell yourself short, Eric. Help us imagine what FreeCard will become. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: The DO command - Re Dan Gelder
Alain Farmer : Does Serf support the DO command ? Alain Farmer : Will Serf support the DO command ? Dan Gelder : If all Serf did was copy HyperCard, I would of course need a DO command. But Serf is a new variation of xTalk; I can add arrays, new syntax, etc. Alain : FreeCard will not merely be a HyperCard clone. More like a compatible superset (for the most part). Dan Gelder : OpenCard or Freecard or Nucard or whatever Alain : The name of our application is FreeCard, and the name of our xTalk-variant is FreeScript. Dan Gelder : ... should have DO. Alain : But not merely for compatibility reasons. The DO command is a very powerful feature. Dan Gelder : Serf probably shouldn't. Alain : Why have you chosen to NOT include DO in Serf? Do your reasons include the performance-hit of the DO command? Or because DO would be too difficult to implement? Or because you consider self-modifying code to be naughty programming? Does it have anything to do with the security-restrictions of platforms other than the Mac? __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: The DO command
Julian: if a "Do" or "send" is implemented then we could just implement "do" and not "send" instead of: send mouseup to this card use: do the mouseup of this card Julian: You would have to make the do command slightly improved from HC's "do" command and you wouldn't have to have both do and send. Alain: I like it, despite the fact that it would make FreeScript HyperTalk-incompatible in this regard. Simple is elegant. Less (syntax) is better. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: For the love of DO
- *** the DO command *** -
do "put" theValue "into field" theField
Anthony: What's wrong with: put theValue into field
theField ?!
Alain: OK, it was a bad example.
Anthony: I think the 'do' command has made people fail
to realize what HC syntax allows!
Alain: I am thoroughly familiar with HyperTalk. I have
been using it since day-one that it came out. It has
been my main programming language for 14 years now. I
even created an educational program entirely with HC
that teaches HyperTalk-Scripting to future teachers of
all levels of computing experience.
Alain: Below is a much better illustration of the
power of the DO command. In a nutshell, it allows you
to mix-and-match three (3) different scripting
languages inside the same script: HyperTalk, Perl, and
AppleScript. And, moreover, params can be passed to
these other languages.
on closeField
makeTable fld "TP", fld "DK", fld "DV"
copyCGI "dispatch.cgi"
end closeField
on makeTable(path, key, values)
put "$TP = '" path "'; " return after var
put "$DK = '" key "'; " return after var
put "$DV = '" values "'; " return after var
put readFile("makeTable.pl") return after var
do var as perl
end makeTable
on copyCGI programName
put "HD:Source:" programName into sourcePath
put "HD:Destination:" programName into destinPath
put "tell application" quote "Finder" quote
return after scriptVar
put "set source to (" sourcePath ") as alias"
return after scriptVar
put "set destination to (" destinPath ") as
alias" return after scriptVar
put "duplicate source to destination with replacing"
return after scriptVar
put "end tell" after scriptVar
do scriptVar as appleScript
end copyCGI
Alain: Please note that the lines of the 3rd handler
may wrap themselves if your Email client's window is
small. Copy and paste them into a suitable editor if
you have difficulty reading the handler.
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
OODL: Democracy belongs
I frankly don't see where democracy belongs on this list either. We are not running a society, we're collaborating on a not-for-profit joint creative effort. Alain: So who decides what, when, in what manner, to what end[s] is not [as] important ?? There is no need for secrecy in my estimation...can you explain why you feel the need for it. If the members of this group can't work openly and above- board, I see little chance of success. Alain: I wholeheartedly agree that there is no need for secrecy for most of the issues that we will be voting on. It is a profound conviction of mine that open-ness is next to Godliness when it comes to participation in a group. In politics, un-accountable leaders and/or followers that shroud themselves in secrecy inevitably leads to corruption and/or distrust. Uli: I realize I'm firing cannons at sparrows here. Still, we should prepare for the future. If we set clear rules now that work in any society, we're much more likely to have something that'll work even *if* the FreeCard group gets larger some day. Alain: Hear! Hear! __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: The FreeCard name --- is it available?
Mark: Can someone do a trademark search? I understood that someone (Adrian?) ran all the names through the US Patent Trademark Office's db before we voted. Alain: I thought that it was Anthony DeRobertis that had run our candidate-names thru the DB above. I wouldn't expect a commercial enterprise to name a product with "Free" as the first sylable. Alain: Right, and the name FreeCard was not already taken when we our candidate-names were run thru the DB. (BTW, did those of you who plan to create commercial software with FreeCard take that into consideration?) Alain: No problem whatsoever. Commercial products should not use our name, or even insinuate in any way that this commercial product is endorsed, guaranteed or supported by the FreeCard Group. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Re Uli's recent update
Or do you disagree that voting should be a responsibility of partnership? Alain: For better or for worse, our present voting system is our most efficient means of making decisions and progress. How can anyone of us afford to abstain from voting when our numbers are so small? Six (6) votes in all for the name of our application! Uli: If I was picky, I'd say voting is a right ... Alain: Sure, voting is a right, in principle. But, in practice, if nobody (except the politicians) voted, then our democratic system based on representation would cease to exist, or persist with very little legitimacy. Uli: ... and whoever sees it as a responsibility should move into a dictature for a few years to find out why. But I'm not, and I don't want to start another discussion like that on socialism back then, as it doesn't belong on this list. Alain: I will resist responding to this salvo .. but do not tempt me any further. Uli: So, if there is nobody who wants to object to the name vote (any legal pitfalls?), I won't re-start this vote. Let's get back to work. Alain: You got my vote ! Uli: I hope to soon be in a state to get back to XBF, and I trust Anthony will again do his magic ... Alain: Keep up the good work, guys ! Uli: ... and get interpreter to work, even with "do" added to the feature box. Alain: We certainly hope so, but I am not sure that Anthony is entirely convinced about the relevance and/or advisability of including the DO command in FreeScript. Uli: I'm also happy Eric just announced he'll soon have a partnership agreement. I think we're going again, which is a good sign. Alain: Welcome back, Eric ! Uli: Now, it'd be cool if someone came up with a GUI for FreeCard. Alain: Wasn't Eric working on a cream-colored platinum-like GUI theme? Uli: If you feel better that way, e-mail that stuff to me and I'll take care of the hassles of placing it on the web site so others on the list can examine the designs. Alain: That's the spirit, Uli. Make it easy for everyone to contribute, even those who contributors that are not familiar or capable of FTP-ing their contributions themselves. Uli: Or you can send suggestions what you always liked to the list, or about things that annoy you about HC/MC/SC's user interface. Alain: Another good suggestion, Uli. You're on a roll! E-mail will quite probably always be our principal means of communication, discussion, debate, and all of that. E-mail is the "killer" app of the Web, eh! Alain: I prefer HTML, however, because plain-text mail is rather limited and un-structured compared to the multimedia and structuring possibilities of HTML, with or without CGI programs. I seem to be a lone-wolf in this regard, though, because no one is contributing anything whatsoever to our current Web site, not even comments -- except for the one comment you made about the content of my HyperCard page. Oh well! __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Voting as prerequisite to partnership
Why should people who aren't committed enough to this project to express an opinion receive a partnership? Alain: No. The responsibility of voting and its link to partnership status does not imply that someone who votes one or more times is automatically a partner. Nor does it mean that missing one or a few votes will revoke your partner status once you have attained it. But, given the importance of voting/polling to make decisions and thus to move forward, it is expected that partners should make a sincere effort to vote every time a vote is called. A few asides are understandable, and no we don't necessarily want to know the reason(s) why a particular partner couldn't vote. But a partner who rarely votes is an .. oxymoron ... in my book. I didn't vote because I couldn't care less about it's name. Alain: No harm done. It's our first vote. We are still working out the kinks. One missed vote does not exclude you or anyone else. But, in the future, please try to vote each time, even if the issue being voted on doesn't enthrall you. It is particularly critical at this time, given the fact that we are so few. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: New Feature Requests from HC-List
Uli: Or you can send suggestions what you always liked to the list, or about things that annoy you about HC/MC/SC's user interface. Rob Cozens: I've tried to save a few of those I've seen posted (eg: Judy Perry's list from the HC list). Alain: What a coincidence! I classify all of the messages posted to the HC-List, and among the categories that I have made and maintained, there is one that I have entitled "New Feature Requests". Alain: I will make it available soon. The hitch is that all of the messages are in Netscape Messenger, and there is no convenient export feature. I am going to have to save each message individually, unless someone on this list has any suggestions on how to simplify this export process. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Voting CGI, HC-mac or Linux ?
Alain: I knew you were away for a while, Adrian. Had I been a little less busy, it might have occurred to me to notify you by personal E-mail that a FreeCard vote was in progress. Perhaps we should include in our voting process a personal-notification of all members among the lessons learned with this first vote. Anthony: This would definitely be a nice feature to add to the voting CGI -- whenever a vote is started, a form should be sent to the list members which they just need to fill out and send back. Alain: Yes. We can easily add this mailTo feature to the current HC-based voting CGI. I am referring to the CGI that was used for the Save-HyperCard-Petition. Anthony: This is rather hard without running your own mailserver. Alain: Not necessarily. Having HyperCard 2.4 handle a mailTo URL is a cinch. It would nevertheless be wonderful to have my own mail server again. That damned macjordomo thing never worked .. G ... Anthony: Does anyone have a static IP, reasonable connection, and a Linux box to use for this? If so, I'll make it work. Alain: I have a static IP and a reasonably fast T1 connection, and my partner has been dabbling lately with LinuxPPC, and I have a free slot in my hub for my third Mac. So, what you propose is definitely possible, but I would like you to tell me why I should go to all of that "trouble". __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Forms of new FreeScript syntax
Uli: What is new syntax in your case? e.g. if I wanted to add a command: laugh about value when expression would this be new syntax? Anthony: Yes. But "laugh(value,expression)" is not. Alain: Just like HyperCard. Any new command or function must use the generic form of syntax that is less english-like than native syntax, as illustrated below. commandName param1,param2,paramn functionName (param1,param2,paramn) Alain: Is this the only kind of syntax that you envision people contributing to FreeCard? Alain: It should be noted that AppleScript allows a scripter to create english-like syntax comparable to the native syntax. AppleScript is not limited to the generic syntax illustrated above. Alain: Is it possible to dramatically simplify the process of adding new NATIVE FreeScript syntax to FreeCard? A user-friendly interface to mask all but the really necessary details, crafted with HyperCard or MetaCard say? __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: HTML versus Text
Alain: I prefer HTML, however, because plain-text mail is rather limited and un-structured compared to the multimedia and structuring possibilities of HTML, with or without CGI programs. Uli: Now you're tempting me ... HTML is great for web pages, but if you receive it via e-mail, many people get gibberish, or have to fire up a separate program to view it. Alain: While it would be conceivable to use HTML in our E-mail (because we are a small group), I am sure that this idea will NOT fly. The reasons you gave above are some of the objections. Bandwidth is also a problem. Uli: Also, most stuff can be done as effective by just scattering a few tabs or spaces through text. Alain: Smileys are ok and I love expressing myself in writing, but one must nonetheless admit that text-based exchanges lack many of the communication cues that make multimedia and in-person meeting so much more rich. Humour or sarcasm, for example, are often misinterpreted when the medium of exchange is text-only. Alain: Bottom-line, for me, is that each means of communication has its advantages and its disadvantages. E-mail is great for loosely structured exchanges, on any topic, at any time, in any manner that suits the writer. HTML, on the other hand, is best for info presentation that summarizes our current status, activities, fruits of our labours, etc. (e.g. web site). Add forms and CGI programs to the HTML-mix and you have innumerable ways of sharing structured information. __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
OODL: Pick A Name for our group
RobCozens : OK, I vote for FreeCard Confederation, or FCC. I reconsidered "Federation" because I believe we better meet the definition of "Confederation". Alain: Instead of "vote", you should probably have written "nomination" because we are not even close to being ready to vote on this. Anthony: I _hate_ the FCC. Alain: What have they ever done to you, Anthony? Anthony: Let's not copy their name... Also, it'd create confusion. Alain: I wholeheartedly agree that we should NOT use the name FCC because of the inevitable confusion that would arise. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
OODL: Hard-code dialogs bypassing ?
Rob: How many times have you cursed at an app "Of course I want to delete the ... that's why I selected 'Delete'."? Wouldn't you like a way for someone who knows the app to bypass those kinds of dialogs? I do. Alain: Me too, please. Uli: that could be done using Preferences. Alain: How about dialogs that must appear to the user when he does it manually, but which we don't want to display when this same action is taken by a script? Uli: If you choose "Get Info" on the trash, you can completely turn off that message in the Finder. I don't mind if the option key is used for this purpose in FreeUI, but it must be implemented in FreeScript. It mustn't be hard-coded into FreeCard, agreed? Alain: Why are you insisting so strenuously that it must not be hard-coded? Alain: I suggest some optional syntax and/or some new properties : 1. lock dialogs -- similar to existing "lock error dialogs" 2. set lockDialogs to true -- similar to existing "set lockScreen to true " 3. doMenu menuItem [with/without dialog] [with keys] -- identical to existing HyperTalk syntax _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
OODL: Button under Visual C++/MFC
And what happens if you have two buttons that overlap each other and you click the one that is partially covered? Will it appear to "jump forward" then, like a Macintosh control? Or will it just highlight the parts that are visible, like a button in HyperCard? Alain: Macintosh controls "jump forward" ?? Windows do that - if you click on a window that is not in the foreground, it will jump forward to the foreground and become the active window. But controls?? Good Question. I have investigate the problem, but it seem that only the first option is handled. We obviously need the latter behaviour. No luck ! Alain: The hiliting of parts in HyperCard is the same as the hiliting of Macintosh controls, aren't they?? Did HyperCard stray THAT far from Apple's Human Interface Guidelines?? Also, since we need to send messages when a button is clicked (mouseDown, mouseStillDown, mouseUp), it can be done i Think ! Alain: We will be supporting all of the events that HyperCard 2.x supports, right? In this particular case, we will thus support : mouseDown mouseStillDown mouseUp mouseDoubleClick mouseEnter mouseWithin mouseLeave It'd be best if we could do the tracking of a button in FreeCard-specific code ... Alain: Are you talking about : (a) FreeCard-specific source code, written in C/C++, or (b) FreeCard script language code (FreeScript) ? else whenever we add new messages we have to add the code to dispatch the messages to the current object's script (to "send" a message to it) to *both* the Windows and the Mac code. It'd be best if we could just make the abstraction layer call a function both on Windows and on Mac and then we would have that function do the actual work. Alain: Absolutely! And we have to be able to change a button's style to some custom style whenever its "style" property changes ... Alain: set the style of button to buttonStyle Alain : But the buttonStyle token will have to be defined somewhere, in a structure that detects and/or asks the user for the current/projected platform/context in order to only offer the btnStyles that are supported. But how do you switch custom btnStyles when someone goes from one platform to another? Unless, of course, each mac-btnStyle has a corresponding win-btnStyle and linux-btnStyle. If these corresponding btnStyles are not identical, then FreeCard will look different on every platform. So what's it going to be ? Same look and styles irregardless of platform, or platform-specific enhanced looks/styles that are quite distinct for each platform? ... which is also a lot easier if we can just call an abstraction-layer function and we don't have to add different code depending on which platform we compile for. Alain: Absolutely. Abstraction of implementation details of each platform would undoubtedly be one of the Ten Commandments of programming, if such a thing existed. The only hitch is that universality usually translates into designing for the Lowest-Common-Denominator that is common to all of the targeted platforms. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
OODL: List-mommy on vacation
Merry xMas everyone. Cheers, as Uli would say ! :)) I will be back on December 27, 1999. Alain Farmer _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
OODL: Unanimity, consensus, majorities
Rob: * I wonder if it is really necessary to have a unanimous agreement on every issue? Alain: Not necessarily. Rob: IMNSHO, the need to be unanimous is less than ideal as a standing policy. Alain: I agree. Unanimity is often hard to achieve and it only requires one dissenter to bog down the process. Each participant is, in effect, given the power of veto. Rob: Does anyone know of organizations/partnerships that have this requirement? Alain: I couldn't say off-hand. Mark Rauterkus: I know of a few. One, a local planning forum, operates by a strict *, and it is a crying pitty. It stinks. Alain: We are talking about Unanimity. We are NOT talking about Consensus. Consensus is not a synonym for Unanimity. Not that this is a big threat or anything, but I won't join any organization that needs to operate from its charter by unanimous agreement. That is a serious blunder to progress should it stay. Alain: I agree that unanimity should NOT always be required and that acting otherwise would be fool-hardy. There are some fundamental issues that we MUST all agree upon, however. Fundamentals like : we are open source, we are not a partnership/corporation, the GENERAL framework of our collaboration and of our licencing, and perhaps some other fundamentals that don't come to mind at this time. Alain: In other words, we should be unanimous on the key strategic aspects, but much more accomodating on the tactical details. In essence, we should all agree on where we are going and why, with some basic guidelines for constructively evaluating the means that will be proposed to achieve our goals (e.g. the How ). And trust our good sense for the rest. And isn't it more or less appropriate depending on the number of partners. Alain: Once we have our general framework in place, it is not likely to change much if we do it right. There are few of us now, so now is the best time to deal with these issues. Participants who join later, if and when they do, will do so according to how our group defines itself. While, on the other hand, if we let everything ride without setting down any principles, we are in for ever more trouble as the number of participants increases. Rob: Isn't a simple majority sufficient on minor issues and a 70-80% majority sufficient for major issues? Alain: Define what you mean by "major issue". People don't vote on fundamental inalienable rights and freedoms, and they couldn't even if they wanted to. A democracy cannot vote to become an dictatorship, for example. Yes. Both the majority and super-majority (for stated issues) vote return works for me too. Alain: In most cases, majority will be sufficient to move forward. If someone disagrees on the fundamental stuff, then that person should fork. If one or more persons disagree irreconciably on some less fundamental things, then they could compete to demonstrate (in time) which solution is better. Furthermore, the burden of proof belongs to the dissenter(s). If proof is provided and/or if enough dissention builds up around an issue, then we should probably discuss this issue further. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Temporary FTP server shutdown
I have to make some backups to CD-R, seek out and destroy viruses, defrag my disk, ... scheduled maintenance in a nutshell. So there will be a temporary FTP server shutdown, in 5 minutes from now, for one hour. I will notify the list as soon as the FTP is back online. Alain __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
Re: OODL: Temporary FTP server shutdown
I have to make some backups to CD-R, seek out and destroy viruses, defrag my disk, ... scheduled maintenance in a nutshell. So there will be a temporary FTP server shutdown, in 5 minutes from now, for one hour. Alain: It's going to take me 24 hours after all. What can I say! I will notify the list as soon as the FTP is back online. Alain: I maintain this affirmation though ;-) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
Re: OODL: Temporary FTP server shutdown
Anthony: Alain, it's far more than five hours and its still not back up. Alain: It's going to take me 24 hours after all. What can I say! Anthony: Curious what went wrong. Run out of CD-R's? Alain: The fragmentation of the disk was so severe that it was impossible to defragment the disk with Norton without first removing a whole bunch of stuff. I had hundreds of instances of the HyperCard's infamous inoculation virus polluting a substantial number of my stacks and HC-standalones ... and so on. More like Spring Cleaning than just passing a litle bit of brooming, if you know what I mean. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Unanimity, consensus, majorities
Alain: I agree. Unanimity is often hard to achieve and it only requires one dissenter to bog down the process. Each participant is, in effect, given the power of veto. Anthony: Which is a very good thing when each participant is legally liable for the actions decided on. Alain: We have been over this one many many times. What liability are you referring to, Anthony? We are not a corporation. We are not a partnership. We are a free association of individuals. Any business ventures entered into by one of our members has nothing to do with our association. We sell nothing. Our product is not dangerous and will undoubtedly contain the standard disclaimers of non-responsibility ( software accepted as-is ) ... Alain: Now that the liability issue is out of the way, let's move on to the main gist of my post. In my humble opinion, we need to be unanimous on the fundamentals, and we can settle for majorities of varying degrees for the less fundamental issues. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Unanimity and consensus are not equivalent
Alain: We are talking about Unanimity. We are NOT talking about Consensus. Consensus is not a synonym for Unanimity. Anthony: Alain, let's go to the dictionary. Today's dictionary is: Merriam-Webster's online WWWebster dictionary. Today's definition is: consensus = 1 a : general agreement Alain: GENERAL agreement necessarily implies UNANIMOUS agreement ?? UNANIMITY the consensus of their opinion based on reports... from the border -- John Hersey Alain: Yes, sometimes consensus is ambiguously taken to mean unanimity, just as one of the definitions of the term anarchy means disorder while in fact it was originally a political school of thought. b : the judgment arrived at by MOST of those concerned the consensus was to go ahead Alain: I agree indeed that consensus means "MOST of those concerned". Most is not equivalent to All. 2 : group solidarity in sentiment and belief Alain: Exactly! I particularly like this definition of consensus because it conveys the spirit of what I mean when I use the term consensus. Anthony: So, yes it is a synonym for unamity. Alain: Selective perception, eh! __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Unanimity, consensus, and fundamentals
Mark Rauterkus: Other have stated (I'm in disagreement) Alain: In my humble opinion, we need to be unanimous on the fundamentals, and we can settle for majorities of varying degrees for the less fundamental issues. Mark Rauterkus: Can you detail all the "fundamentals" in full view ... Alain: I certainly hope so. Nothing behind closed doors. Full accountability. Anything that concerns the group should be visible and discussable. Mark Rauterkus: ... in advance? Alain: We started to do so, several months ago. Several debates raged on about the various "political" aspects of our collaboration. These debates were often referred to as "the Constitutional stuff". Mark Rauterkus: I think I would need to see such a tight list ... Alain: The "constitutional" stuff will indeed take time to elaborate, discuss, debate, and revise. I do NOT contend that I have all the answers, nor even a list of all of the questions or issues that will be deemed fundamental. Mark Rauterkus: ...and then throw more thought into the matters. Alain: The "constitutional" stuff is essential. I am glad to see that it is spontaneously re-surfacing after a period of relative sleep. We felt that we needed to progress on the technical front so as the reassure everyone that "real" (hear throat clearing) work is getting done. Mark Rauterkus: Otherwise, no thanks for the STRICT CONSENSUS. Alain: I suspect that you mean "no thanks for the strict UNAMINITY", because a consensus is a general agreement that MOST but not ALL participants agree to. Dissenting views are tolerated and taken into account in the final formulation of the agreement. Mark Rauterkus: We can disagree. Alain: It is healthy that we do. Mark Rauterkus: I can be the odd man out. I sorta expect it. Alain: Non-conformist, eh! Glad to hear it. I consider myself one too. If in doubt about my non-conformity, then consider the solitary uphill battle that I have been waging to clarify the word consensus ! Mark Rauterkus: To get the called for list started, here are some ideas. Things where there might need to be 100% partner agreement: Alain: Good initiative. 1. To close the organization. Alain: Doubtful that we have to enshrine this in our organizational agreement. Those who wish to desist simply leave. As long as there is one or more members that wish to continue, who are we (as desistors) to insist that the organization must be dissolved? 2. To shorten the period of open polls for voting. Alain: Off-hand, this strikes me as little bit un-democratic, but I suppose we could act in this manner if the polling period becomes too long. Endless debate would indeed be counter-productive, especially if we stipulate that a strict unanimity is required, and hence allow ONE dissenter, for example, to hold up the whole process. That's why a majority/consensus is better than unanimity. 3. ??? Alain: A preliminary list to illustrate what I think will probably be considered fundamental : 1. We are open source. 2. We are a free association of individuals. 3. We are not a corporation. 4. We are non-commercial, non-business, non-profit. 5. We are not partners. 6. We do not bear any responsibility for each other. 7. No one is liable for anything. 8. Contributions to FreeCard are irrevocable gifts. 9. ... etc ... (for now) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Fundamentals
Mark Rauterkus: The removal of a partner thing... #1. So, someone wants to quit. ... Does that someone need to get all to agree before the "retirement" can take effect? Alain: Same point that I made. Mark Rauterkus: #2. One should be able to NOT be a partner by one's own choice. No vote needed. Alain: That's a gimme in my book too. Mark Rauterkus: #3. And, perhaps there should be some "suspension" right to being a partner too. Say I have a baby -- and I want to suspend my partnership agreement for 6 months. Then what? Alain: The partner drops out of sight for a while, then returns when he can. I have no problem with that. No need to "suspend" him. Mark Rauterkus: Could it be done? Alain: The main thing, I believe, is that he notifies us of his departure, gives us a ballpark estimate of when he thinks that he will return, and that he accepts the group-decisions taken in his absence. Mark Rauterkus: Going "NO-MAIL" is something that should be okay here, I hope. Alain: Breaking off communication is usually not a very good sign. But I am the first to concede that there are sometimes circumstances or other which could arise that would justify a partner's absence. Missing votes is the only standing issue here. Mark Rauterkus: #4. On the issue of a gross rejection/removal of an existing partner -- tossing him/her out of the rights of partnership -- humm. Alain: If the partner became belligerent, offensive, violent, abusive, destructive, or something unacceptable like that, then I hope we have the good sense to put into place some procedures that will allow us to decide and enforce such a removal if it ever becomes necessary. This unpleasant propect is unlikely though. Mark Rauterkus: There is NO WAY, if I'm given the toss, I'm going to vote for my own removal. The group can't get 100% agreement on tossing a member if that member has a vote. Alain: A fatal flaw of strict unanimity, eh! Nice try. Consensus and majority are less strict than unanimity, however. Besides, unanimity or consensus or majority are not that important in this case. If you piss off members, you will be shunned. It's human nature. Mark Rauterkus: #5. The idea of the group being able to decide to incur contractual debt -- humm. Alain: I have no doubt in my mind whatsoever about this one. No liability or responsibility whatsoever for our non-business free association of individuals. Not now, not later, even if someone were to suggest that we vote to do so. This must be enshrined in our Constitution, for lack of a better term. Mark Rauterkus: I think that would be something that a satellite group, not the main body of this effort, would choose to do. IMHO, I think being debt free should be a main mission of the organization. Alain: I insist. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: re Mark Rauterkus rant
Mark Rauterkus: First off, some attribution to me has been off the mark. Alain: I take rigorous care not to make any mistakes in this regard, but some slips get through from time to time. Mark Rauterkus: I didn't write the Section 11: Voting part. I did just requoted it from the draft on the net. Alain: I was probably attributing the CITATION to you, but it ended up looking like you were the originator. I am fishing though. Mark Rauterkus: Secondly, another point I made had * throughout a word in the requote, when I wrote originally "strict consensus." Alain: I did this deliberately to underline the fact that it was those words in particular which were being responded to, not the whole paragraph. The latter was kept merely to maintain the context, of course. Mark Rauterkus: Helpful tip: Please be a lot more careful out there, okay. Alain: Euh .. thanks for casting your constructive criticism in the third-person, eh! ;-) Mark Rauterkus: Someone wrote: "Mark's attitude stinks". Then went onto to say, among other things, "The council could not ... blurt out ill-considered objections and idiosyncratic prejudices. Just for the record, comments about my attitude stinking are, IMHO, a great example of an ill-considered objection. Alain: Very ill-considered indeed. Lets endeavour to keep all of our deliberations constructive. Personal attacks are unacceptable. Mark Rauterkus: I'm led to guess then that the above attitude assesment must have been a toung-in-cheek quip. Alain: I sincerely hope so. Mark Rauterkus: Here is another matter. The notion of _protecting the interests_ is of little or NO concern here. We have no interests to "protect." We have not assets. We won't. Alain: I wholeheartedly agree. Thus, while the argument that unanimity is required because no one wants to be out-voted into a situation that was not agreed upon at the outset is a valid one, it does not apply in this case because there is absolutely no liability involved. Mark Rauterkus: FACT: We choose to work together on something for the public domain. Alain: Is "public domain" what we finally decided? Were my objections to it addressed, namely the danger of a non-free commercial fork/takeover of FreeCard by the pseudo-company MicroSloth ? Mark Rauterkus: Things that hinder action are fatal. Alain: As a designer, I might respond that constraints are what creation is all about. The guidelines/rules, even when we break them, are nevertheless the focus of any creative work. Alain: As a graduate and researcher in Communication, I have to agree with you wholeheartedly that hindrances to action must be removed when possible. Or, if you are not one of those half-empty-glass types, you could express this as Human Augmentation, as might Douglas Englebart. Mark Rauterkus: I'm voicing "THOUGHTFUL DISSENT" on the matter of 100% agreement needed before action is taken by partners. Alain: Nothing wrong with thoughful dissent, Mark. We value your opinion. We must debate this further. For the record, I am NOT stipulating that we obtain unanimity on each and every decision we will ever make. I am arguing instead that unanimity is required only on the really fundamental issues. Majorities (consensus) of varying degrees on issues that are NOT fundamental will be a MUCH more common occurrence, once the fundamentals are substantially put into place. Mark Rauterkus: (FWIW, I've said here that I'd like to be a partner.) Alain: Well ... you're certainly not a lurker, eh! ;-) Mark Rauterkus: Now what Well, perhaps I'll ponder further. The sachems were required to be of "one mind." How do WE issue that test? I'm telling you now, I'm going to fail that "one-mind test." So, I won't be in. Fine. If the notion here stands in that, "Unanimity becomes a fundamental law," then I'm outta here regardless. Alain: Group-Think has always been abhorrent to me too. I am and always will be a non-conformist, and proud of it. Peer-pressure never had much hold on me. Back in 1984, I had a really great English class in college. It was called "1984" and the teacher was brilliant. His interpretation of George Orwell's masterpiece, and of Aldous Huxley's Brave New World too, were eye-opening in this respect. Mark Rauterkus: PS: Sorry if this message casts a foul odor in your mail box. Alain: No foul smell here. Besides, the inventor never commercialized the virtual-reality-like peripheral that outputs smells. The only prototype of it known to have existed is/was an arcade-like game in the form of a motorcycle simulation with smells for added realism. Can you imagine if they had commericlaized it? Can you turn down the smell on the TV, Harold. You're stinking up the whole house... Sorry, honey, the hero of the story is rummaging through a garbage dump. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Partnership agreement - long mosaic reply
Someone: ... for the partnership it is important, as each one is liable to the other. We can't have 90% of the group decide over 10%. It's too dangerous. Every *partner* needs the right to veto. Alain: Yes, but not on everything. Anthony: Remember, we're all liable for everyone else's actions in the partnership, and I, for one, will not be a part of ANY such agreement where I can have a decision I do not consent to forced upon me. Alain: If a decision/vote is taken that exposes any or all of the FreeCard partners to any liability whatsoever and/or changes the Partnership Agreement, then this decision/vote must be unanimous. -- Anthony: IMO, this does not mean that every piece of code checked in most receive unanimous consent, but rather that agreeing on the person(s) to decide on and check in that code does. Adrian: And to decide on who to delegate duties to, we can still have a majority vote to select one person, but then submit them to the partners for final approval. It would work very much like the Australian and British parliamentary system where a bill must be passed by two houses of parliament. (The american equivalent is congress to president, but with a lot of presidents). I think we can make this work. Alain: A majority would be sufficient for me, in this case. -- Someone: I just don't see how you can reconcile the two statements: either every partner has a veto on everything or some actions can be taken even if a partner objects... which is it? Alain: Your binary formulation almost sounds inevitable but there is a third alternative that comes to my mind upon reading this. There are 2 categories of issues in my view. (1) Fundamental issues that we cannot compromise on, or be out-voted on, and (2) the strategies, tactics, means, day-to-day stuff that we are not likely to always agree on but that leave the general framework intact. Alain: Category-1 issues are fundamental issues like "we are open-source" which should be enshrined in our partnership agreement and then be changeable if and only if the partners unanimously agree. A radical change from free and open to commercial and proprietary, for example, cannot be put to a majority vote. -- Someone: The action would be to delegate the power to certain person(s) who would retain that power under conditions so-and-so (probably 'so long as there is no objection from any partner'), and operate under procedures so-and-so, and unamity would be required on that delegation. Alain: Why is unanimity required in this case? Alain: What are we delegating? Allow a proxy to vote for us in our absence(s)? Where work is concerned, people contribute what they wish, in the manner that suits them. Partners are not bosses. -- Partnership votes shall be conducted via e-mail. Alain: I for one have often suggested that it would be better if we used a Web-based voting form. More structured, easier to set up decisions with complex tradeoffs, etc. In time, perhaps other FreeCarders will wish this too. So lets not put such a tactical detail into our constitutive partnership agreement. To assure authenticity, each partner is to include their date of birth and mother's maiden name as evidence of their identity. Alain: The spoofer probably knows this information too, so this would not be a very reliable authentification procedure. PGP is probably the best we can do without going overboard on this tactical detail. Furthermore, privacy, encryption and authentification should only be required in special cases. Why don't we vote in the open and perhaps even assume that no one will steal our vote. How likely is it that someone will spoof us, given that there is no money involved? In the event a vote is given without such confirming information that vote shall not be deemed as valid. In such case it shall be interpreted that the partner has not voted. However that partner shall be free to rectify their vote, by resubmitting their message with the proper identifying information. Alain: We want to remain as flexible as possible. Uli: Rob, you're mixing up partners and associates. There are partner-level-decisions and associate-level-decisions. Partner-level must be unanimous, while associate-level can be majority. Alain: I substantially agree with this formulation, except to say that partner-level decisions don't necessarily have to be unanimous. Only the really fundamental issues require unanimity. However, given the probable difficulties of evaluating what is fundamental versus what is not, I might have to accept your formulation after all. Uli: If an associate-level decision touches the realm of the partner-level, partners should be able to veto it ... if it includes possibly changing the license, it becomes partner-level. Alain: Agreed. Uli: ... What code is to be used, is usually associate-level... Alain: It depends, I say. High-level design decisions must be adhered to when coding stuff, at least at the API
OODL: What Can UFP Share With FreeCard?
Rob Cozens: Please forgive my ignorance... UFP is on the list of things I'd like to know more about but never found the time to do so, right there next to XOS and Serf. Alain: The UFP is in suspended-animation at this time. Rob Cozens: My understanding is it is an attempt to coordinate and standardize HyperCard scripting efforts so works by different authors can work together. Alain: Create a collection of pre-scripted HyperTalk handlers and stack-based solutions to ease the life of those who are less proficient with HyperTalk/HyperCard than we are. Rapid application development tools for the masses. Rob Cozens: If this is so, it seems to me the FreeCard partnership might be able to draw from work done and lessons learned by UFP. Alain: Members of the UFP are scripters. As a rule, they don't want to re-write HyperCard. They want to create value-added solutions without touching C source code. In my view, they are nonetheless complimentary. FreeCard builds the application, while the UFP provides the pre-scripted handlers and stack-based solutions based on the application. Among other things, we avoid the usual conundrum faced by new software/platforms that initially lack content/software. Rob Cozens: Is there something there for us? Alain: Experienced scripters are one of the best sources for information, suggestions, and so on where scripting is concerned. Current usage trends of the DO command, for example, could be polled from them. Statistical analysis of the collection of handlers could identify oft-coded segments, which could in turn give us clues to desirable syntax improvements. Not to mention that we had many discussions concerning how to manage software versioning in an open collaborative environment, etc. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Alain, the server...
Hmmm... The OpenCard directory is missing on FTP, and there is no web server running... Alain: There is a two-word explanation to this : spring cleaning. What can I say? I didn't expect the NetPresenz prefs to be affected, but they were nonetheless. Its fixed now. Everything works as before. sure you don't want to switch to linux? Alain: It just so happens that I have my third server in the office now. It's a PowerMac 720/120, running MacOS 8.x and/or LinuxPPC. It is not currently plugged into the hub because, I am told, that the Linux installation that took a whole afternoon with several professional on-hand has somehow been corrupted. Don't ask me for the details though. I am not familiar with Linux, nor do I want to be at this time. I am willing, however, to plug it in, for you, and provide you with its IP address. From there, you are COMPLETELY on your own though. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
OODL: Partnership Ideals
Mark: What follows is the start of a new thread with "broad strokes." I'm looking here at the forest, not the trees. I think some general talk is called for now since the open pondering the first draft of the possible agreement. Alain: Yes, let's agree at least on the broad general framework of our collaboration/partnership. Mark: This conversation is still mud in my mind. Alain: This is readily evident to me now because of this muddled post that I am replying to. You stipulate that we don't need unaminity for security-reasons because there is no liability involved, but then you go on to argue that majority-rule is the way to go, even if some remote liability should crop up, "because the decisions are going to be of no financial consequence". Then you go on to say that there should not be any liabilities for partners at the outset and forever more, and that they should form other organizations if they wish to do business. Mark: I'm not able to see the venture being successful, nor being able to change and grow. Alain: What is it EXACTLY that would hinder us so? Mark: There are still a slew of sticking points to the organizational structure. Alain: Agreed. There are many issues that we have to resolve to insure the success of our (ad)venture. Mark: Sorry to be a nay-sayer just now. Alain: Let us not be dissuaded by the spirit of the Holidays from saying what needs to be said .. I say! Mark: But, I do see a solution. I see a way that we can get "out of the woods." I think I'm going to be able to present an alternative approach. Alain: Good initiative. Someone: ... for the partnership it is important, as each one is liable to the other. We can't have 90% of the group decide over 10%. It's too dangerous. Every *partner* needs the right to veto. Mark: Given above logic ... Every partner needs a veto. WHY: To avoid danger. But, if the organization is set-up so as to avoid all dangers, then is a veto needed? Alain: In my view, the key element of your argument is "if the organization is set-up so as to avoid all dangers". I wholeheartedly agree. We must set down the base rules (framework) that we all agree on, and that won't be subject to majority-vote at a later date. Secondly, that unless we are clairvoyant, we will not be able to anticipate the entire set of rules/guidelines that will be optimal for us until the end of time. But we should nonetheless set down some broad principles that will guide our future choices. A majority-vote to engage in some mutual liability later on down the road should be barred from the realm of possibilities or be unanimously agreed to. Alain: If a decision/vote is taken that exposes any or all of the FreeCard partners to any liability whatsoever and/or changes the Partnership Agreement, then this decision/vote must be unanimous. Mark: One can't engage in life with the goal of doing things yet without ever having any liability whatsoever. Alain: Life does indeed present many challenges and risks, but this Web collaboration of people that have never met face-to-face is not necessarily one of those situations where it is wise to risk mutual liability. Mark: That said... we can't be stupid. But, what I see in the above thought is just impossible. Alain: What is impossible about insisting that unanimity be required for a drastic change in the status of our association that would expose us to liability that we had not bargained for when we became a partner, particularly if we are one the out-voted dissenters. Mark: I feel that this endeavor (most of all, being a partner) is NOT for the timid. If all dangers can be eliminated, are partners even needed? Without dangers, how can each partner be liable to the other? Alain: Is there going to be some danger or isn't there? Do we really need to be a partnership, or simply a free association of individuals that share mutual interests and source-code? Mark: Even then, if there is some REMOTE liability to the partners -- I still feel it is okay to have 90% (or even 51%) of the partners decide with votes for the fate of the group. Alain: (1) Let us research the matter further so that we can identify potential sources of liability, and then modify our collaboration agreement to avoid them. Alain: (2) Majority-rule on something as fundamental as un-anticipated mutual liability is dangerous in my opinion. It is probably why Scott cannot allow himself to become a partner of FreeCard. And my situation is not unlike his. I am a technological startup that could blossom into something really big. Anthony: Remember, we're all liable for everyone else's actions in the partnership, and I, for one, will not be a part of ANY such agreement where I can have a decision I do not consent to forced upon me. Alain: Hear! Hear! Mark: I'm okay with majority rule decisions being forced upon me. I'm okay mainly because the decisions are going to be of no financial consequence. Right? Alain: Right. That's how I see it. No
OODL: Partnership Development model...
Your nascent developer community needs to have something runnable and testable to play with. Alain: The rush to code is part of the problem, in my view. It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style ... Alain: Humm .. I have often proceeded in this haphazard kind of way, on projects where I do everything myself, with no outside help. But I am increasingly confronted with the reverse situation these days. All projects of any scale requires a team of talented individuals that must have a design/model/plan to refer to, to make sure that no one's efforts get trampled, and so on. ...but it would be very hard to originate a project in bazaar mode. Linus didn't try it. I didn't either. Alain: Given that we are a collaboration (team), I would like to give the textbook approach to systems design a chance. At least a little bit of the Top-Down approach in order to make sure that we are heading in the right direction ( e.g. heads-up, hindsight, ... ). Might it be one matter to code from the ground up and another to launch and operate an organization? IMHO that mention is about the act of code writing -- and that act is NOT the same as the organizational model. Alain: Indeed! The task-centered programming is quite distinct from the more general organizational issues, which is why the latter tends to make the former a little bit impatient, since the former is more evidently related to the goals of the group of creating its HC clone, and thus tend to ignore or neglect the latter, figuring that these issues will resolve themselves in time, only to have these issues surprise them later ... I do think that it is hard to start from scratch in the coding efforts ... Alain: Paradoxically, programmers tend to view planning and documentation as necessary evils, best left to others, while the "real" action is in the coding. Overcoming difficult programming conundrums with astute coding tricks is .. well .. fun! Alain: So I conclude that it is NOT hard to code from scratch. Quite the contrary. You don't have to plan anything. You don't have any constraints imposed on your coding style and habits. You can pull off some idiosyncratic tricks that no one else will be able to decipher later, perhaps not even yourself, because you don't have to interpret someone else's or your own code when you are starting from scratch. The only hitch is that no one but yourself (for a few months) will understand your code. Consequences: You start over each time without benefiting from the potential re-usability of your previous work. And you can also forget about enlisting people's help. They won't be able to decipher any of it, and it is not likely that it will be adaptable to the group's needs, in particular those needs that the lone-programmer did not (correctly) anticipate. if Eric says it is so. Alain: Eric has given us a big hand with legal stuff, and he is currently working on the graphical aspects of the FreeCard GUI, but what does all of this have to do with programming-from-scratch? But, to our advantage, we've got MetaCard to lean upon, for starters. That benefit is HUGE. Thanks Scott. Alain: Scott's contribution is indeed appreciated but, one must also admit, it is not used much yet. It is more of a model than it is a basis upon which we can build. All of the source code of the GUI will be our own. Work on the FreeCard interpreter is on-going. Plus, we've got some open-source stuff out there too. Perhaps we should have someone do some open- source asset resource investigation and reporting. Alain: I have suggested in the past that we adapt some Perl stuff. Not the Perl scripting stuff but the underlying C-code. We could thus avoid re-inventing a whole bunch of stuff that is already coded. MacPerl's access to the Mac's Toolbox and its full support of Apple's Open Scripting Architecture, for example, come to mind. In our quest for progress one of the big reasons of forming an organization is to have an official-like group. Alain: The main reason that we are forming an organization is so that we can collaborate together, in such a manner that everyone who participates will enjoy the experience and will reap the rewards of the group's collective output. I think we (the original organization) need to exist in ways beyond an email discussion group. We need more than a uniform FTP site. Alain: A Web-based collaboration infrastructure would be nice. Perhaps annual meetings, in person, at a location decided upon by ourselves each year. IMHO, we need some type of ORIGINAL ORGANIZATION that exists. Alain: You are perhaps correct, but it makes me wonder why a formal piece of paper registered with the authorities is so important for the viability of our group. With this group in a viable mode of being, it can both ask for gifts and accept those gifts. People won't "give" nor "contribute" to an email
OODL: Server doesn't recognize .htm
Uli: Alain, could you make the server recognize .htm? They are currently displayed as text files :-( .html works fine. Anthony: Eschew all influences of evil PC 8.3 naming except on things that have to compile over there, that is. Uli: I used my default settings for my web page tool for these pages, and they are ".htm" since the server I'm on doesn't recognize ".html" ... :-( Alain: This is not an either/or proposition. Both extensions will be supported. I believe that it is done. Please notify if the change has not taken effect. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Humour
Alain: This is not an either/or proposition. Both extensions will be supported. I believe that it is done. Please notify if the change has not taken effect. Anthony: Alain, you must of missed the "g" after my comment. I was kidding :) Alain: I am notoriously bad a getting jokes, even in person. Its much worse when the medium is e-mail, because : 1. non-verbal cues are missing ; 2. text-based cues are poor substitutes, which is aggravated by the fact that most of these cues are self-styled, non-standard, idiosyncratic, ... the meaning of the abbreviations "BTW", "AFAIK", and so on are still quite foggy to me. The wink and smile smileys are clear enough, but the other ones look like gibberish. 3. it would be really cool to use HTML-based e-mail, instead of plain text, because it would alleviate much of plain text's expressivity limitations. But I also know that this suggestion will not fly because people still use primitive text-based e-mail clients, and most list servers prohibit it. We might be able to pull it off later, though, when we become server self-sufficient. Alain: Sorry for being so dense when it comes to humour. In my defense, I would like to point out some of the factors that make humorous communication fail: there are cultural differences, the limitations of plain text (above), the lack of familiarity with each other... Alain: So don't make any jokes anymore ... just kidding! :)) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: CLI versus User-Friendly
Adrian: Best way to learn is hands on with Linux. It's really very intuitive, but it follows different logic to MacOS. Anthony: Intuitive isn't quite the right word. Alain: Intuitive!! I doubt that. The whole Mac philosophy is diametrically opposed to any command-line interface because such interfaces are necessarily less intuitive than a point-and-click metaphor of the real-world. Lots of overly-concise commands and arbitrary conventions that have to be learned and remembered. Of course, CLIs are faster because the human operator has to adapt to the demanding-syntax and constructs of machine-driven design, rather than harness some of the computing power to make the computer adapt to our sloppy, error-prone, ambiguous, human ways of accomplishing tasks. So current trends towards Perl, Python, Linux ... while they are promising from a programmer's perspective ... are reactionary and regressive when you look at the big picture. Besides, programmers are human too, so why aren't their tools more user-friendly? For What It Is Worth Alain Farmer __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Programming with CodeWarrior
Good evening fellow freeCarders. What do our programmers think of programming with MetroWerk's CodeWarrior development environment? How does it compare with MPW ? Are there any other development environments that a new Mac programmer should know about ? The reason that prompts me to ask about CodeWarrior is that they offer some free distance-education courses in Macintosh C programming : http://www.codewarrioru.com/Metrowerks/1,6172,1_,00.html Of course their courses require books and software that are related to the CodeWarrior development environment. So I want to know if CodeWarrior is a good investment and/or if something better is available. Salutations, Alain __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Development environment for FreeCard?
Mark: This is a pressing question: What is your take on the choices of development options for this FreeCard gang? Alain: We don't want to constrain our development efforts. Thus, our primary selection-criteria for our development tools should be guided by what is the best option(s) to achieve our goals. I don't want to sound elitist but the price and/or whether it is commercial or open source, while obviously important, are secondary consideration in my view. Open, non-proprietary choices are most definitely preferred, but remain secondary if these development tools are not bundled into FreeCard and are not needed by the FreeCard runtime in order to perform its task(s). This pointer, sent to me, is worthy of investigation: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html Alain: I never imagined that there were that many choices for GUI-toolkits. I am blown away! Mark: My initial hunch is a FREE OPEN source project might be wise to lean heavily on that (Free Open) type of development environment too. Alain: Quite right. If we want college students and others to pick-up some code efforts here -- we might be shooting ourselves in the foot by going to a commercial development suite where there is a high cost. Alain: Not just students, of course, since cost is often a consideration for many developers, albeit to a lesser degree for the latter than for the former. Mark: The commercial options might be the best options out at this moment given where most of us have been in the past years -- but commercial, shrink-wrapped tools might not fit our long-term, global mission well. Alain: Commercial or not, the question I would ask is: What option is the best one(s) from a technical standpoint? __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: Remote Linux Configuration Project
Adrian: How about going to NNTP? Alain: I am not against the idea but, when I suggested something similar several months ago, the suggestion was flatly rejected. Mark: No thanks. NNTP is spam rich, and majordomo isn't nearly as bad. Alain: So I am told. Mark: And NNTP isn't "modern.". If we were to go to a different interface, I'd want to go into something NEW and BETTER. Alain: Sounds like a commendable suggestion. (hint: http://www.forumsamerica.com/Macintosh/) Personally, I love what interaction.in-progress.com can do. I crave a chat with A.I. Alain: The chats that I have visited were OK, I guess, but they usually end up being superficial conversations on mundane subjects. E-mail gives you more time to ponder on what others write, and it allows you enough time and continuity to compose your responses thought-fully. And, of course, there is the synchronous versus asynchronous tradeoff too (e.g. you are temporally constrained with chats) Mark: Furthermore the type of interactions that occur on a mailing list generally don't make it to the news groups. More, "yea, right" and "trite" comments there. Alain: I have heard this about news, too. It is precisely the contrary of what I thought news groups are all about. I thought it was a idea/document publishing environment. Posts that are more like essays and/or with replies that are editorial-like. Scientific exchanges at the international-journals level of discourse. Mark: Email allows for better, in-depth discussions, IMHO. Each has its purpose, but we need to be drilling down for deeper, richer content discussions. Alain: Aleluia! Mark: That alternative server isn't a "production" one -- and I'd hate to take these discussions anywhere that wasn't a rock-solid host for months on end -- and we've got that here now. Alain: Good point. Mark: That server seems to me to be a developmental box. It is great to have those resources for development -- but things get too goofy when doing double duties. Alain: Another good point. Mark: I seen no problem nor worries about bounces, subscriptions, and admins getting ticked off here. Alain: Adrian is indeed the only person that I am aware of that has had such problems with our list. Mark: I think those are inflated assumptions that are NOT real. Alain: Adrian is not a twit, Mark. If he says that he has had such problems, then it is surely true. Mark: The grass isn't greener there, IMHO. Alain: I have written this before but it bears recall that it would be better (ultimately) to be completely self-sufficient. Scott is still with us, now, but will his commitment to hosting our mail waiver when the GUI is completed and we focus our efforts on a free app that will compete with MetaCard for the hearts and minds of all those disenfranchised HyperCard fanatics? You gotta like the fact that Scott/MetaCard is generously helping us, but it is nevertheless somewhat perplexing. Wouldn't you say? Mark: As for the scalable issue -- We have far more capacity on the box and bandwidth this is sitting on. We could expand 1,000 fold and still be safe here. Alain: I am not worried about bandwidth, that's for sure. Mark: I asked MONTHS ago for a new "License" list to be created. But, there wasn't a "demand" by the users for such a service. Alain: Well ... that's not really an accurate picture of why we chose to keep licencing-issues as part of our main (only) mailing list. The principal argument against it, if I recall correctly, was that our group was and probably still is too small for this kind of 'fork' to take place. Mark: To create a new list is sorta easy on the box such as the one we are now being hosted. The system admin could do it in 20 minutes, max. Alain: The difficulty or relative ease of setting up mailing lists, while it has been a royal headache for me, on a Mac, is nonetheless not an issue in this case. Mark: BTW, I'd still like to make more specialized lists here. Alain: Me too, as long as we don't divide ourselves into so many sub-groups that none of them have a sufficient number of participants to keep things alive. Mark: I don't fire up my newsreader, but I ALWAYS get email. Alain: It is an unconstestable fact that E-mail is the most popular application of the Internet. News used to be tremendously popular, but it is waning heavily. Adrian: I think this would be a _big_ improvement. And certainly worth the effort required to move any archives. Alain: Not right away, Adrian. Mark makes some good points when he suggests that we make things bullet-proof on the Linux machine before using it for critical group functions. We will setup some mail lists on the Linux box, that's for sure. The first one will probably be a list dedicated to the subject of the Linux box. Mark: Doubtful. We should improve the FAQs, the scope of the discussions, the numbers of Voters, --- the things that matter. Alain: I agree that we
OODL: Alain apologizes
Mark: I think those are inflated assumptions that are NOT real. Alain: Adrian is not a twit, Mark. If he says that he has had such problems, then it is surely true. Anthony: I think he was refering to me. Alain: The person targeted by Mark's comment is not a twit, irregardless of who was in fact targeted. It seemed to me like he was putting into question the credibility of the person, instead of dealing with the issue(s). Personal attacks are not constructive. As such, my comment does not just target Mark but everyone, including myself. I over-reacted though, and my intervention was less-than-exemplary. I apologize to everyone, and to Mark in particular. Anthony: I said that. Adrian might not be too happy with these mis-attributions. Alain: Two whammies in the same post. Bad post. Sorry about the mis-attributions. My reading of that post was askew in terms of who said what. What threw me was that Anthony was one of the most vocal critics of NNTP several months ago, but seems to be its most vocal proponent this time around. Nothing wrong with that. It just threw me ... and led to my mis-attributions. Alain: I am making a sincere effort though to maintain the historic-context of citations by maintaining those greater-than symbols, in correct numbers, all the while attributing as best I can un-identified chunks to their true originator. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: Whither the Petition now
Is there not now a case for contacting the signatories and informing them that the petition has been presented? Jacque: We don't have their addresses. Alain: Hindsight being 20/20, I will definitely add a "e-mail" field to any future petitions so that: (1) we can contact them later, as above ; (2) make sure that every signatory is one real person ; (3) filter the signatures to remove those that signed several times, keyed on the e-mail which is presumably unique. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Remote Linux Configuration Project = model?
Adrian: I believe we need to look at ways to do this best and experiment with different approaches. For this reason an NNTP server will be set up on the Linux box and a test forum will be set up there. Anthony: Agreed. Alain: Agreed. Anthony: Yeh, well we still wouldn't have to deal with the people who can't manage to unsubscribe from a mailing list, probably because they did not read and/or keep the directions that said how to do so. I guarantee we'll get plenty once we get big. Alain: I am sure that you are correct, Anthony. That's why we will provide them with a Web page that gives them all the directions that they need. If they ask us a question, then we answer back with a clickable URL. Our FAQ could handle this too. And perhaps, given time, we could invent a new way .. some kind of Web-bot that they could interact with directly! Anything is possible ... if and when we "we get big". Anthony: No. NNTP has a major advantage: It can be browsed online. Alain: I don't know about you, Anthony, but I browse my E-mail online (eg. my free Yahoo mail account). If a mailing list gets 1000 messages, I have one choice: download. Alain: Well .. this is not entirely accurate. You could do some (dreaded) mail-filtering. A simple mail-filter mechanism is built into Netscape Communicator. I don't know about Explorer, because I don't use ANY MicroSoft products. But I know for a fact that you can do some sophisticated mail-filtering with scriptable text-based email-clients, like Eudora for example. Anthony: If a newsgroup gets 1000 messages, I can ignore them. Alain: I haven't used news much but what I do recall is that, upon subscribing to any newsgroup, one is inundated with hundreds of messages in one humungous download. I admit, however, that this very well may be because of my lack of familiarity with this means of mediated communication. Adrian: I don't fire up my newsreader, but I ALWAYS get email. Anthony: Hmmm... I do both. Sometimes I even read news more often. Alain: What news feeds/groups are you suscribed to, Anthony? Anything you would like to pass on to this group? What news-client software are you using? [Note: We won't be running a full newsfeed, or even a feed at all. Unless maybe we wanted csm.hypercard] Alain: How about this pie-in-the-sky idea: We eventually do and/or participate-in a newsfeed, but not the mainstream news of course. Just an interesting grouping (community) of related open source groups, say. Anthony: I won't try to convince anyone to go news only until the proof of concept has proven itself :) Ultimately, I don't think I'll need to [convince anyone]. Alain: Nothing convinces more than a good demonstration. Extra points for attitude and perseverance, eh! Anthony: I think we're now running: (...). Alain: This Linux-project is really turning out great. I know what the objective is. I know and understand what is going on. I am kept abreast of developments. So far, we nearly agree on everything. What we don't agree on is not hindering our ability to proceed. Different points are being argumented in a rigorous and objective manner. Alain: A model for FreeCard? I would like to think so. Everything is going fairly well with FreeCard, in my book, although I vaguely fear that some of us don't think that we are proceeding fast enough. I wish that I had had more time to devote to our collaboration. It's one of my New Year's resolutions to dedicate more time to our collaboration. We will see how it will pan out. Close parenthesis. Back to the subject at hand. The main difference between the Linux-project and our FreeCard collaboration is that I have only a very vague idea what is going on with FreeCard. Where is the interpreter at? What is there left to do? If new programmers volunteer to help you, then what will you delegate to them? Same goes for the Block-File-Format too. Anthony: Maybe we'd better ask Alain how much RAM and disk space this machine has. Alain: RAM = 64 MB ; disk = 1 GB when empty Anthony: 17 services off of one box. This should be interesting. Alain: No doubt about it :) Anthony: Any IP yet, Alain? Alain: The 20,000-dollar question, eh! I have spoken with my ISP. They are aware of my need to be connected up. They are sending me the Ethernet cable by internal mail. I should get this cable before this week ends. Hence, we should be up and running (IP) by this friday. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: re what is a rolodex? -- Web-stacks
matteob:... i know this is a stupid question, but...what is a rolodex? 8-) Alain: A rolodex is an office-supply item. More often than not, a rectangular container that holds individual cards, with or without binders ... You know, like those cute metaphoric backgrounds that came with HyperCard. You have tabs sticking out at relevant sections of the rolodex, each tab a little bit more to the right of the previous one, so that you glance at all of the tabs at once, for a bird's-eye-view of all of the stack's cards. Collections of recipes often come in this format, too. Alain: matteob, I have a few free-like days, starting today. Thus, I have time to assist you with your HC-based CGI scripting, if you still wish to do so. Among other things, I have recently scripted a tool that exports everything a stack contains -- including scripts, content and properties -- as an HFS of folders and files that 'mirrors' your stack. The idea being that a CGI program can then use these files in order to generate the corresponding set of web-pages (stack/bkgnds/cards). Each page is composed of layers, one for each HC part. These parts (buttons and fields) can be sized, resized, placed, selected, shown, hidden ... just like the Real Thing. My working hypothesis is that HC userLevels 1, 2, 4 and even 5 are possible on the Web. UserLevel 4 will be the hardest. UserLevel 3 is out of the question for now, but in defense of HTML/CSS/JS, it should be noted that the latter has color, images, QT, and so on that make these interfaces pretty. Do the graphics-editing in another more specialized program, eh! Alain: If anyone else cares to join in, then don't hesitate to write me. Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Dial Command and Mac OS 9
Ivan Gobbo [EMAIL PROTECTED] : Somebody has experienced some dial command problem after upgrade to macOS-9? Alain: You are using HyperTalk's dial command? Pray tell, what do you do with it? Automate your telephone-dialing? The reason I ask is that the FreeCard list recently had a debate on whether the dial command should be honored in our 'HyperCard-clone', for the sake of compatibility with our beloved HyperCard, mainly, since the usefulness of this command is marginal at best -- or so I thought! Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: merryxmas antibody infection
merryxmas antibody written by: The Black Knight Alain: Let me rant, first off, about this immature individual who gets his kicks by calling himself 'The Black Knight', and polluting cyberspace with stupid pranks. Don't you have anything better (eg.constructive) to do with your time? Life is too short. Why add un-necessary difficulties to the existing ones that plague us every day? Anthony: This is, plain and simple, a trojan horse. Whoever posted this stack needs to take care of it. MP0werd: That's the antibody virus, it's not a trojan, it's a virus. Alain: Semantics .. semantics .. either way, we have to get rid of the damned thing. It has infected hundreds of my stacks, on both my servers. I bought Norton AntiVirus a little while back. It readily identifies the merryxmas whatever and purges it 90% of the time. Stacks purge nicely, but HC-standalones don't. The bottom-line is that I am going to have to un-binhex, un-compress, un-zip all of the UFP/FreeCard archives, and run a thorough virus-check. Any item that cannot be purged of its virus will be trashed. My FreeCard backups on CDROM shall be considered tainted from now on. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Dial in FreeCard
Alain: You are using HyperTalk's dial command? Pray tell, what do you do with it? ... Anthony: I think we'd be more into complete serial port control, with a dial command being written in FS using the serial control and the 'play' command. And I think the play command should be written in FS with commands giving better control over audio. Alain: Right on! EXCELLENT suggestions. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: merryxmas antibody
Anthony: I didn't notice anywhere where it sets up code to propagate itself. Did I miss it? Alain: I looked everwhere but found nothing either. I also looked in the resource-fork. No un-usual resources found. It occurs to me now though that perhaps it replaces a bona-fide resource with a bastard-version of this same resource that nonetheless accomplishes its old task too. If you do discover it, please notify me (for curiosity sake). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: FreeCard UI Blind Access
Adrian: When designing the UI, lets try and keep in mind blind users. If we could find a way to make FreeCard easier to use for blind people this could be a useful competitive advantage for FreeCard. Alain: In this regard, it is too bad that we chose against HTML/XML/Web as the GUI. Meta-information and accessibility are some of the primary concerns of these W3C standards. Web-based Brail-clients exist. Adrian: (Not to mention being a good deed). Alain: This is definitely the most laudable part of your idea. Uli: How would we do that? Alain: We could provide a mechanism for including meta-data in our GUI elements, like HTML/XML do. Speech-synthesis is an alternative, but not a very good one because, while the quality of speech-synthesis is getting better, it is still dreadful, i'm afraid. Uli: If you can come up with some cross-platform system that makes it possible to support blind people, that's no problem, but since FreeCard is based on visual elements (buttons, windows, color graphics) I'm not sure how we'd add support for blind people. Alain: You make a good point when you insist that FreeCard 1.x will be based on visual elements. We have to draw the line somewhere, for now, and the approximate equivalent of HyperCard is what we are aiming it in the short-term. And HC has no provisions for the blind. Uli: I'd say we just hope we don't add in anything that makes it more impossible than it already is to add support for disabled people, Alain: I agree, despite the fact that your answer is quite vague. What could we possibly do that would make it impossible for us to adapt FreeCard to the needs of the blind later on? Worse-comes-to-worse, we will do nothing for them. Uli: but we should keep that for version 5.0 or so. It's asking too much to get a working HyperCard clone out there and then also take into account specialties like blind people. Alain: Unfortunately, I have to agree with Uli on this one. Maybe not as far into the future as version 5.x, but quite probably not in our first release. Our web-site, on the other hand, is coded in HTML. So we can accomodate the blind with regard to our collaboration infrastructure, immediately if you wish. Alain: This does not necessarily mean that our web-site has to have a FAT version of HTML (eg. blind and non-blind coded into the same page). We can, instead, have two parallel web-sites. When the person accesses the site, he enters his name and password, which then allows my system to branch and/or dynamically customize the client's output according to the user's profile (prefs). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re:Re: [opencard-digest V1 #233]
Eric, if it's a magnifying glass you need, that's not much of a problem. Alain: I forget what it is called but I once saw and played around with a software gadget that allows you to pass a virtual magnifying-glass over various parts of the screen. But magnification is but ONE of the possible functions of this gadget. I can act as a dynamic filter that let's you focus on particular types of information according to criteria set by you. We'll need something in this direction for the FatBits view anyhow, Alain: Right. so this would be very likely built into the engine, and would mainly involve a bit of multiplication every time a coordinate is passed in. Alain: Sounds good. Shouldn't be much trouble to put this into the HAL. Alain: HAL, the silicon-based being that went berserk in the movie 2001 - A Space Odyssey ? I do not think microsloth is a major worry - because what we produce will necessarily be cheaper. Alain: I have been over this many times but it bears repeating that cost is not the only factor in our competition with MicroSloth. If they were to take our work as the basis for their own, then dramatically improve on it and market it feverishly, then we would be left in the dust, known only to ourselves!!! __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: FreeCard UI Blind Access
Uli: I'm not sure how we'd add support for blind people. Adrian: Um no, I've been misunderstood (my fault for writing the email in a hurry). The key term was (something like) "*keep in mind* blind users". Alain: I am aware of that. No misunderstanding. Adrian: It is not necessary to make the interface speak to the user or anything major like that. Blind users have screen readers that do this for any program. Alain: Right. Adrian: We just need to provide keyboard alternatives wherever possible and make sure that prompts end in a : Alain: That is coherent with HyperCard as we know it today. It has many keyboard alternatives built-in, and many more can be scripted easily (functionKeys, for example). I further suggest that someone eventually create an FC-stack (or something like that) that allows a user to manage and change his keyboard-equivalents. Adrian: When I get the chance I'll find the URL for the slashdot article so you can all read it, Alain: Interesting. Adrian: everything will make much more sense then. :) Alain: You did not fare so badly this time. Adrian: Sorry for throwing the cat amongst the pigeons. Alain: Colorful metaphor. :) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Temporary server shutdown
Our server will be temporarily shutdown today in approximately 30 minutes for approximately 1 hour Reason: My linux server temporarily needs a 'head', the one sitting on the shoulders of my G3. Just long enough so that I can obtain my IP-address and DNS from my ISP. More on this later. Of particular interest to Anthony and Adrian, eh! Alain __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re Temporary server shutdown
Our server will be temporarily shutdown today in approximately 30 minutes for approximately 1 hour Reason: My linux server temporarily needs a 'head', the one sitting on the shoulders of my G3. Just long enough so that I can obtain my IP-address and DNS from my ISP. More on this later. Of particular interest to Anthony and Adrian, eh! Alain Alain: Its ready. Come and get it! __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: Use Download-Manager for summaries
Alain: In my opinion, the ideal place for summarizing where we are at (and such) would be our web-site. Uli: I have a suggestion: If you got my Download-Manager to run on your server Mac, you could set up a folder where summaries would be posted. Then you could put a modified version of the DL manager into your startup items folder (or wherever) that would automatically generate index files listing all these summaries. This way, anyone who feels like posting a summary could just upload it to that folder, and it would automatically be added to the index file. The home page would link to that file and everything's accessible. Alain: OK. Sold. Uli: Of course, we'd still have to write it, but the hurdle to get over would be smaller. Alain: Indeed. Uli: (make sure you have the newest version from my web site) Alain: http://www.weblayout.com/witness --- 'The Witnesses of TeachText are everywhere...' --- HELP SAVE HYPERCARD: --- Sign: http://www.giguere.uqam.ca/petition/hcpetition.html --- Alain: Concerning your signature, Uli, could you please remove the last line that provides a URL for signing the petition. This resource has been permanently removed. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re:Re: FreeCard UI Blind Access
Alain: In this regard, it is too bad that we chose against HTML/XML/Web as the GUI. Meta-info and accessibility are some of the primary concerns of these W3C standards. Web-based Brail-clients exist. Uli: Alain, please do finally throw that XML over board. There is nothing we can do with XML that we can't do with a binary file format. Alain: I am not suggesting that we should change. Please excuse my over-zealous web-centrism. Uli: It's the viewer that displays web pages as Braille. Alain: I am aware of that. Uli: And we can't display a HyperCard stack in a web browser (the way HTML does it). Alain: I was imagining the (eventual) process as similar to embedding Quicktime or Java-Applets into web pages, with the EMBED and/or OBJECT tags. Even better though would be a browser REPLACEMENT (e.g Web-savvy FreeCard stacks). Uli: A HyperCard stack is supposed to look basically the same on every platform, and that means pixel-unit positioning, Alain: In D-HTML, with or without CSS, layers can be sized and positioned with pixel-precision. Uli: ...while HTML is mainly intended to hierarchically structure information, Alain: True, but with a lot of presentation-type stuff added to the mix since the advent of the Internet and, in particular, since the Internet became the mass-public phenomenon that we know of today. CSS is supposed to be the answer to that, separating content-structure from content-presentation, as HTML was supposed to be in the first place. Uli: As for meta-data, that could probably be stored in user properties, which are a de-facto standard in all xTalks except HyperCard, and thus a very likely a good candidate to be in FreeCard in 1.1 or whatever after our 100% HC clone. Alain: Agreed. Uli: Right. Also, many OSs will certainly provide a system-wide technique for improving access for disabled people in time, so let's now draw the line and hope that when we pick up this topic again they'll all have settled down on a standard or at least finalized their proprietary designs so we can support them THEN. Alain: Agreed. Uli: If you find anyone who has time to create a version of our web site that includes special enhancements for the disabled, that's fine. Alain: I will eventually get around to these accessibility considerations, myself. Basically, it is just a few more constraints to take into account while coding the templates of my Web pages. The CGI does all, of the rest after that. Uli: But I think most disabled-enabled browsers are able to translate HTML to Braille Text themselves (after all, it's just a different font, output to a special device, there's no translation of text involved). Alain: Yes, but some of the tricks of the trade tend to make this 'reading' process more arduous. Case in point: using (nested) tables for optimal page-layout. When read back with a braille-reader, each row-column pair (cell) is read out-loud, as if each cell were significant from a semantic point-of-view. Uli: You might want to make sure you have your ALT= Tags on all images, but I hope it won't involve more. Alain: Yes, this is the kind of thing that I had in mind for the short-term. Uli: I really think it's premature to care about these things too much this early in development. Alain: For now and the foreseeable future, I believe that the scope of accessibility-enhancements will be limited to our web-site. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Stacks on the Web
Uli: And we can't display a HyperCard stack in a web browser (the way HTML does it). Alain: I was imagining the (eventual) process as similar to embedding Quicktime or Java-Applets into web pages, with the EMBED and/or OBJECT tags. Even better though would be a browser REPLACEMENT (e.g Web-savvy FreeCard stacks). Uli: the trouble is, plug-ins are like images. Alain: I am not necessarily talking about a plug-in. Uli: They just get a rectangle in the window, and there they are allowed to draw and they're notified of clicks and the user typing keys. Anything that's drawn in there is drawn using OS-specific calls, not using XML or anything. Thus, the browser is actually only providing the window to draw in, anything else is just like with any other application. Alain: I know all of this. It supports well my idea that we could replace current ML-based browsers with a web-savvy FreeCard stack. We could probably achieve much more with FreeCard than is currently possible with ML-based browsers like Netscape and Explorer. Uli: Thus, XML would have absolutely no advantage in this regard. Alain: Unlike myself, you are linking two different arguments together: (1) can we eventually replace current ML-based browsers with a FreeCard alternative ; (2) should the FreeCard GUI be ML-based or binary. Alain: In D-HTML, with or without CSS, layers can be sized and positioned with pixel-precision. Uli: Still, we'd need pages of HTML code to describe what would fit into 16 bytes of binary data. Alain: Good point. Uli: If needed, we could add an exporter to DHTML ... Alain: I believe this to be a good idea. Many HC list members have recently signaled to me their interest in being able to save their HyperCard stacks as web-stacks e.g. a coherent set of web pages and btns that mirrors the structure of the exported stack. Uli: ... but that would miss lots of features and we'd have to translate FreeScript to Java or HTML links and "do" would become impossible, etc. It'd be pretty disadvantageous. Alain: Less than you believe, I venture. Alain: I was thinking of some king of HTTP-based remote procedure calls from FreeCard components embedded in Web pages and/or a FreeCard browser-replacement. HTTP or some other web protocol. Uli: I think it'd be smarter if we just had an "open URL" command like the QuickTime Player has it. Alain: Minimum. MetaCard is already web-savvy. Several web protocols are scriptable from within MetaTalk. Uli: For 2.0 or so. Alain: I agree and always have that version 1.x of FreeCard should aim for HyperCard as we know it now. Uli: To make our file format streamable, we'd need a special web file-format that breaks a stack into several files, where parts of the file are downloaded separately, probably split into separate files (one file per card or so) ... Alain: Sounds simple enough. Does our block-file-format (eventually) permit this? Uli: ... as I'm not sure we can say "download byte 1 to 7 of file x" over the web. Alain: Following up on my Remote-Procedure-Call idea, the HTTP protocol does support this. They call these "stay-alive connections". Uli: It's all possible and within what we allowed for so far, just not at the top of the list for now. Alain: Couldn't (and won't) ask for more than that. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re:Re: Use Download-Manager for summaries
Uli: Oh, I just realized I didn't have support for text files in there yet. I'll upload a new stack shortly. Alain: The archive that I did download un-binhexed itself ok, but silently refuses to un-stuff itself. So I trashed it. Hopefully, this problem will also be fixed in the next version. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: help
Sorry guys for the "help" message; I´m alive and well - no grizzlies around nor any other life- threatening situation :-). Alain: That's a relief! ;-) Actually I just subscribed to the FreeCard mailinglist and wanted to browse the archives. How else do I browse the archives? Alain: Summaries will be provided soon. One of our founding members (Adrian) has taken it upon himself to do the daunting task of summarizing everything for us all. Thanks for your help (and thanks to Uli and Alain for the emergency-room-like quick reply). Alain: 10-4 Rampart. Start an IV with ringers, and transport the patient immediately. Over. (burst of static) :)) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: Eric Engle
Eric: I sent copies of a prototype gui to alain, uli, and mr.DeRobertis. Did you receive them? Alain: Yes. Eric: Did they decompress ok? Alain: Yes. Eric: If you have, can you upload them? (preferably) Or tell me where to upload them? http://ufp.uqam.ca/opencard/Downloads/Eric-GUI.sit.hqx Eric: Am also hoping for comments on them. Alain: The file "Button Ideas.mc" contains one button that I like a lot. The file entitled "buttons_-_navigational_arrows.m" contained a round-rect button and two star-like icons, one with a border, one without. The one with the border is definitely better, unless the bkgnd color of the page is the same color as the bkgnd color of the icon. The file "button ideas 3.mc" is a mystery to me, as were a few other files that only seem to contain a few choppy sentences of a technical nature. I must be missing something. The cursor-like button in the file "more button ideas.mc" is nice though. As far as the gui goes, i can definitely script a new menubar and change the existing dialogs - even the properties box. Alain: I am beginning to understand why MetaCard is getting such a bruising when it comes to its GUI. Eric: Who is interested in the GUI? Anyone? If not, that is cool, i really can handle it (pun intended:) Alain: Despite the fact that it is the scripting that is my favorite feature of HyperCard/FreeCard, it is the quality of our GUI that will make-or-break us. Case in point: MetaCard. Eric: but if people want to work on this let me know. Course if you want to focus on the programming in C and Pascal that's ok. Point is division of labor. Alain: This is the crux of the problem. One person can only do so much. I have much to contribute to the FreeCard GUI and to the FreeCard scripting-language (FreeScript) - eventually - but for now the aspects related to the collaboration are consuming all of my spare time. Eric: Please let me know ... if anyone else wants to do GUI stuff. Alain: I sincerely hope several of our members volunteer to do so. I cannot at this time, but I will endeavour to free up some time to do so in the near future. Regarding partnership - an unincorporated association is a valid option. I'm indifferent. The reasons for forming a partnership are to negotiate with metacard and to have a uniform licensing agreement. That can be worked around however so either form of non-business would work. Alain: That's good to hear. Adrian and me are going to work on the voting/polling system to make it even better than last time, before we call for a vote on the legal form of our association, and on our licencing scheme too. For the latter, I believe that the consensus is a licence that is mainly Public-Domain but with some GPL-like provisions to insure that forks remain open source. Eric: Do let me know about the gui so i can continue working. Alain: Sorry I took so long to respond, Eric. your faithful servant eric engle Alain: And I, yours. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Sanctity of our server
Good evening fellow freecarders. We recently had a problem with a virus that called itself the 'merryxmas inoculation' virus, or something like that. I have scanned the entire disk, including the archives, for any trace of viruses. I am happy to report that none were detected by the latest version of Norton Anti-Virus software. So feel free to download what you wish from the FreeCard download space, with the peace of mind that this is probably relatively safe to do ... for now. I will endeavour to maintain our virus-free status but one can never be 100% sure about this. So it goes without saying that if you partake in the activity of downloading, that you do so at your own risk. And we vigorously encourage those that contribute to FreeCard to be vigilant about these security matters, too. Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Interpreter update - compliance
DeRobertis: Uli and I do note the lack of compliance in compilers, and while it does stop us from fully using certain things, such as templates, it does not stop of from making the rest of the program compliant to the standard -- or as best as possible. We don't use NULL as a place for a quick temp, although on MacOS we could get away with it. We don't depend on the size of a long or a int or a short (or at least try not to). Why? Because we have no guarantee that it will work everywhere; in fact, I can name systems where all of those assumptions will break. Alain: This is interesting information. May we include this information in the FreeCard web-site ? Say in the web-page that is meant to describe the FC interpreter, its current state, and where it is going. DeRobertis: [I know the old interpreter was pretty bad -- the new one will be much better] Alain: No pressure intended, but your above comment begs the question: When do you believe that this much better version will be available for testing? Do you have any idea? A ball-park estimate would be fine. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Collaboration infrastructure
Hello fellow FreeCarders. I have just completed a new version of my web-site generating system for one of my clients. I am basking in the glow of the satisfaction of a job well-done and, well, done. More to the point, this version of the system is completely generic. In other words, it will take me minutes to adapt it to FreeCard and/or to adapt it to the UFP. The only long part, in fact, is the copy/paste of our existing pages into the new system(s). What's more is that I have a day off tomorrow. I could go play outside, but it is dreadfully cold these days in Canada, and I was never much of a winter-sports fanatic, anyhow. So, instead of goofing-off, I will contribute and adapt an instance of my collaboration software to our group. Of course, this is in no way a formal guarantee that it will get done tomorrow. Shit happens! (shrug). Besides, not all winter sports are practiced outside! :) Warm salutations to all, Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: FreeCard Collaboration Infrastructure
The Web-based FreeCard Collaboration Infrastructure is almost ready, folks. :) There are just a few more non-complicated kinks to work out. Adaptation pains, basically. Not new R-and-D by any measure. To wet your appetites, I have taken a snapshot of our "Home Stack" page, and converted it into GIF. Be warned, however, that (this time) you need a large screen and/or a high resolution to avoid scrolling horizontally and vertically. The web-page, on the other hand, scales to the screen-size and screen-resolution rather well. http://ufp.uqam.ca/opencard/FreeCard.gif Highlights (that you cannot necessarily see in the above GIF image) : * HyperCard-like metaphor ; * Dynamic 'menubar' of buttons ; * Two userLevels: registered ot guest ; * Dynamically-generated and personnalized web-pages ; * Auto-recording of all form-elements of any page ; * Auto-logging of all transactions (timed in msecs) ; * A dozen collaboration-sections, so far. I am approximately two-days away from a full bug-free release. A slightly buggy version is likely for tommorrow. Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: FreeCard debugging facilities
Eric: ... but script errors do happen, and it is really nice to be able to watch global variables. Alain: Yes, one of HC's most endearing features is the ease with which one can debug one's scripts. The variable watcher, and the step-by-step debugger too. Eric: hmm, come to think of it i maybe could do a script for a variable watcher stack... but how would we do a message watcher? Alain: Both of these should be external and programmed in low-level code, just as it is now in HyperCard, such that the debugging stuff remains efficient and transparent. Eric: Ideally both would be in xTalk rather than in C ... Alain: We can improve the debugging facilities currently provided by HC's Script-Editor, Variable-Watcher, and Message-Watcher. Among other things, we could add new scriptable properties that allow us to adapt FreeCard's default debugging behaviour to our specific needs, instead of re-inventing the whole thing in FreeScript. Eric: ...because XCMD's are not cross-platform. (incidently cross worlds has some demo xcmd's which are both windows and macos compatible...) Alain: It depends on the XCMD. If your XCMD was made in order to hide/protect your code and/or make repetitive actions faster, then it is likely that these XCMDs will continue to run properly on all platforms. The problem arises when your XCMD capitalizes on platform-specific features. Uli: Eric, this is a tough point. I think we'll certainly add support for message variable watchers implemented using scripts somewhere down the line. Alain: We are aiming at 100%-HyperCard-compatibility in the 1.x versions of FreeCard, correct? If so, then the above should be included as soon as possible. Do you agree? Uli: But it needs to be supported by the engine, e.g. by having it automatically open up a stack and send a message to it resp. send a message to a certain stack if it's open. Alain: In HyperCard, the Script-Editor, the Variable-Watcher, and the Message-Watcher are external resources, coded at the same (low-)level as HyperCard is. What's more, you can substitute these resources with your own variants of these debugging facilities. Isn't this how we should do it too? Uli: Who wants can create some within the constraints of MetaCard's engine for now ... Alain: This exceeds my current knowledge and experience in programming, unfortunately. Uli: ...as we'll certainly try to support as much of their syntax as feasible. Alain: This is news, sort of. I surmised, of course, that we would eventually get around to comparing ourselves to ALL of the other xCards out there, but, to my knowledge, nothing has been posted about this, until now. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re FreeCard Collaboration Infrastructure
Eric: Wow! The graphics for the freeCard site look nice! Alain: Thank you, Eric. Alain: The whole web-site acts like a set of HyperCard stacks. The upper-frame is akin to the 'menubar' (navigation toolbar). The middle-frame (card) contains the contents of the cards. The bottom-frame is akin to the messageBox, but our messageBox is multimedia, eh! Alain: Each page contains the necessary information and handlers to dynamically adjust the appearance and function of each button in the menubar-frame. Pages are generated and personalized, in real-time, according to a user-model of each user. All form-elements of any page are automatically and transparently recorded and revived. This latter functionality will allow us to vote on each card/page/concept, our specific votes revived, side-by-side with a representation of the group's voting on the matter. Eric: Oh, whet is the correct spelling (i think anyway). Alain: Incorrect, Eric. Wet is the correct term. It can used as a verb, as well as an adjective. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Stacks on the Web - plugins and XCMDs
Uli: Besides that, I'd say we don't allow XCMDs (or any other kind of plugin) over the web ... Alain: I avoid these too, but probably for different reasons. Users hate plugins. The download(s). The installation(s). The upgrade(s). Where to put then? When to upgrade them? Identifying the plugin as the culprit of buggy system behaviour, in the first place. Uli: ...and file access commands may only manipulate files in a special folder next to the stack. Alain: Sound a bit like cookies. Client-side file-access limited to a designated location (file/folder) on the client's machine. The main hitch with cookies, for me, is that the user doesn't necessarily always use the same machine. Hence, his cookies don't follow him around. Thus, it is an un-reliable means of maintaining state. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Collaboration Infrastructure READY
Hello fellow freecarders. It has been quiet lately. I hope the announcement below will change that somewhat. The FreeCard Collaboration Infrastructure is (sort of) ready. Try it now: http://giguere.dsc.uqam.ca/freecard/index.html Things I know that need to be done: * All of the pages have to be re-touched ; * Long pages have to be broken down into cards ; * Several navigation buttons to be added ; * Non-discontinuous navigation of everything ; * Integrated voting/consensus-barometer feature ; * etc But all of the above is mainly cosmetic, or nice features to add soon. It essentially works. Enjoy! Alain Farmer mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: Re: Collaboration Infrastructure READY
The FreeCard Collaboration Infrastructure is (sort of) ready. Try it now: http://giguere.dsc.uqam.ca/freecard/index.html Things I know that need to be done: Alain: I must be getting desperate. I am replying to myself! * All of the pages have to be re-touched ; Alain: Much has been done, in this regard, but several hours will still be required to bring it up to scratch. * Long pages have to be broken down into cards ; Alain: I am a strong proponent of the one concept per card/page approach. Modularity is next to godliness, eh! That way we can associate with each modular concept, the following context-sensitive operations: * Vote on very specific concepts/points/ideas * Comments, and form to make a new comment * Meta-data * Help * References * Visual navigation MAP (you are here) * About this card .. * Edit this card .. (web-form) Alain: All of this for each and every card of our web-site. Context-sensitive is key here. * Several navigation buttons to be added ; Alain: Several navigation buttons have been added. They now number 8 in the navigation toolbar in the top-frame. Namely: First, Previous, Next, Last, Contents, Help, Home, and Post. Except for Post and Contents, the rest should be quite familiar to anyone who has used HC. * Non-discontinuous navigation of everything ; Alain: The Contents and Home buttons have substantially improved the situation. * Integrated voting/consensus-barometer feature ; Alain: Every card contains one specific item. You click on the VOTING button, in the bottom-frame, then proceed to vote on this specific item. What's more, our system generates each page in real-time, so it will be easy to display the ever-up-to-date and summarized results of voting on this particular item. And, because each page is also personnalized in real-time, we could also revive each user's voting-state, which he could then compare to the voting-state of the group ; before, during and after the user votes. The user can vote as many times as he wishes, as soon as his opinion of the item changes. Only the user's most-recent vote is kept. * etc Alain: As the Carpenters once sung: "We've only just begun ...". Too many feature-ideas to enumerate here, at this time, but I should probably mention that the bottom-frame will be dependant on the userLevel of the web user: 1. In its current form, the bottom-frame is the rough equivalent of HyperCard's message box (e.g. to display short messages and/or interact with the web-card/web-HC. 2. I am in the process of transforming the bottom-frame into another toolbar, symmetrical with the 8 buttons of the navigation toolbar in the top-frame. The 8 bottom buttons are (provisionally): Map, About, Comments, Voting, Meta-data, Edit, References, Alternatives. Uli: Alain, looks great! Just two things that bothered me: Alain: At least we are a duet now! ;-) Uli: 1) It uses JavaScript. I'm paranoid. Alain: Security-wise, JavaScript is no worse than other languages, it seems to me. The most recent incarnation of JS has been overhauled in terms of security. Which is good, I am sure, but which caused me many headaches this year. Uli: (i.e. I had to turn it on in my browser). Alain: You must be joking, Uli. HTML by itself is VERY static. The static display of a fast-moving multimedia QT movie does NOT make it any less static, either. Client-side interactivity is essential, with or without Dynamic-HTML. The latter dramatically exacerbates the need for JavaScript. Alain: I do not particular like JavaScript either. If you or someone else can pull it off, it would be nice to set the language attribute of the SCRIPT tag to something other than JavaScript, like FreeScript for example. VBscript did it! Uli: Would it be possible to change the navigation to use regular HTML? Alain: I endeavour to be as flexible as possible but, in this case, I cannot compromise at all. While my system is 80% server-side, and the 20% client-side JavaScript that I do use is limited in scope to the fundamentals ... without JavaScript, the whole solution falls apart. Uli: 2) The downloads don't work, they're displayed in the frame. Alain: Fixed. Uli: Also, I don't get anything in the bottom frame. Alain: That frame was intentionally empty. It was meant to be the rough equivalent of HyperCard's message box. Its also great in a drill-and-practice tutorials, for providing feedback to user and/or obtaining snippets of information from him. Uli: Should I also have turned on Java? Alain: Not at all. I never touch the stuff. Uli: 3) We might want to add some color. Alain: It was natural for me to go for the B-and-W color scheme because I am still using B-and-W HyperCard 2.2. It's simpler to prototype with, too. And I am a strong proponent of the sparse use of color, conditionned as I am by Apple's Human Interface Guidelines. Uli: One more suggestion which I'm sure you just accidentally missed: Alain: Accidentally missed ?? I was working with the
OODL: Re:Re: Collaboration Infrastructure READY
Alain: Security-wise, JavaScript is no worse than other languages, it seems to me. The most recent incarnation of JS has been overhauled in terms of security. Which is good, I am sure, but which caused me many headaches this year. Anthony: I've lost count of how many JS security holes there have been last year, from stealing credit card numbers to faking which site you're looking at. Alain: The latest incarnation of JavaScript is much more security-oriented than all of its predecessors. There is tainting and procedure authentification, and all of that. With these features taken into consideration, are you still insecure about JavaScript's secureness? Is JS the WORST language in this regard? Uli: Would it be possible to change the navigation to use regular HTML? Alain: I endeavour to be as flexible as possible but, in this case, I cannot compromise at all. While my system is 80% server-side, and the 20% client-side JavaScript that I do use is limited in scope to the fundamentals ... without JS, the whole solution falls apart. Anthony: What does the JavaScript do? It activates a simple form. Alain: It is more essential than that. The onLoad event of the middle-frame re-adjusts the buttons in the top-frame, produces the default message that is displayed in the bottom-frame, and starts a timer. Hidden form elements maintain the state of the user. Going to any page stops the timer and transparently submits the user's state to the server. As a by-product of the process, the values of the user's form-elements are also sent. We are going to exploit the latter to record members votes. This is basically it, with the exception a few calculations, moving some data around, bypassing the default form-element selection order, in order to guide the data-entry of the student/user, and some other interface niceties that make the web-experience more user-friendly. Anthony: Some reason why clicking the nagigation images can't do that? Alain: That would mean that each image's link would have to be hard-coded with the image tag, and the HTML of the buttons frame would have to be changed every time you change page. That is MUCH slower than dynamically changing them (appearance and destination) with a little bit of JavaScript. Anthony: I've got problems besides just letting unknown parties execute code on my machine. Alain: 1. Am I an unknown party that you don't trust? Alain: 2. JavaScript's scope is pretty much limited to the HTML page that embeds them. Like Java and others, JavaScript cannot read or write to the user's disk. It doesn't have hooks into the user's operating system. Besides a little of tricky spoofing on the web to rip-off credit card numbers and other secure information from unsuspecting people naive enough to consider the Internet secure in the first place, what can JavaScript do that is deleterious to the client's machine? Anthony: 3 of the 4 browsers I use don't support JS. Alain: My official position on this matter is that I only support Netscape and Explorer, the two most widely used browsers throughout the World. My system would probably also work well with other less-known browsers, like Mosaic and such. The browsers that I do NOT support are the primitive ones that don't support frames, tables and/or even graphics. Uli: Also, I don't get anything in the bottom frame. Alain: That frame was intentionally empty. Anthony: Please remove it. It makes it need to scroll on my 13" monitor. Alain: That frame was intentionally left empty because it will eventually serve a purpose. Actually, it will serve several purposes: * A frame to provide pretty, customized feedback to the user, instead of relying on the ugly dialogs provided by JS itself. They are not only ugly, they are very limited and in English, while many of my clients are French. * A rough equivalent of HC's msg box, on the Web. To display messages, like the above, but also to allow the user to use it to submit commands to my server. * Another set of buttons, like the top-frame, with further operations that are context-sensitive (e.g. card-specific) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: What fonts
What fonts are available cross platform? I think that fonts are different for different machines. Thus a button of a certain size might contain text on one machine, but not be big enough on another computer to contain the same text. Alain: I have passed on your interrogations concerning fonts to my graphics-artist. She had provided me with a very short list of multi-platform fonts, e.g. fonts that you can expect to be the same on each platform. A complex subject which brings great wealth to companies like Adobe. Perhaps big font houses can guarantee uniformity of their fonts across platforms. Alain: I have kept myself relatively abreast of the situation where the font issue is concerned. For some time now, they have been talking about embedding fonts into HTML pages. Like images, the fonts will be downloaded dynamically (and cached too?) to the client when the page is rendered. The remaining issue, I believe, is whether the font can be cached or whether it should be systemically flushed once you are done reading your page. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: Time for a 20-ton GPL LART
Alain, there has been a slight miscommunication. Somehow the sides have gotten mixed up. I want the loser who thinks he can undo the GPL by a stupid notice to get the 20-ton LART, not the other guy! Alain: How silly of me. Consequently, now that I know which side is which, the victory of this loser would indeed be dreadful, as you stipulated. It would render GPL totally useless. I'll use names next time to prevent any confusion. Alain: Another variation on the Problem-of-Other-Minds. e.g. You can never really know for sure whether the other person has understood what you wanted him to understand. The back-and-forth exchanges (communication) serve to confirm or disaffirm the inferences of the preceding exchanges. In plain English, if we talk long enough, we can be reasonably sure that we both understand the same thing. As we have done in this case. Nothing wrong with that but, as you suggest above, we can reduce the number of exchanges necessary to achieve our goal, by being as clear and as explicit as possible in each and every exchange. For what it is worth, this is my aim, and I encourage everyone to do likewise. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: What fonts
Alain: I have passed on your interrogations concerning fonts to my graphics-artist. She had provided me with a very short list of multi-platform fonts, e.g. fonts that you can expect to be the same on each platform. Alain: ... but I lost the list. And the situation has perhaps changed since the lost-list was made. (re-reading my own message, I realized that I had not completed my thought). __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
OODL: webSite-generator update
Alain: A version of my FreeCard Web-Site generator is in the process of being dramatically simplified: 1. No frames 2. No JavaScript 3. No dynamic HTML Alain: This new version will thus be simpler, faster, and more secure than its recent predecessor. I am also hoping this one will be far more popular than the last one. As an added precaution, I will only make this new version available when it is near-perfect. So hang tight for now. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: Re: [opencard-digest V1 #267]
Eric: (do _you really want to chase down _every link and change its style? Manually? I do not, though a script could probably be written to do it). Alain: Syntax coloring and such is usually a scripted process, as it should be. Nothing stopping you from doing this manually, but I feel that life is too short for such mundane tasks. That's what computers were originally designed for, eh! Eric: ... the aesthetics are an aspect of the GUI that metaCard expects to get in exchange for its support of this project. Alain: If you are saying that Scott chose to participate in FreeCard for the purpose of improving the GUI and thus improve MetaCard's success in the market-place, then I agree with you. But that is where it stops. We do NOT OWE Scott or MetaCard anything whatsoever, except perhaps our gratitude. The rest is a gamble that we all share in, as individuals with mutual interests working towards a common goal. Eric: Function determines form, but within function paramaters form should be aesthetically pleasing ... MC places function over form which is good, but there is plenty of room within functional parameters for improvement. Alain: I tend to agree with you, Eric, that function precedes and is more important than form. But I have just completed a Masters in Interactive Multimedia surrounded by artistic-types that would argue precisely the contrary, adding that that is why computer stuff is so drab, dweeby, un-artistic, etc. Case in point: MC. Eric: MetaCard's demo is really generous and deserves to be supported. Alain: I have also been pleasantly surprised at how generous and easy-going Scott has been. It is a sincere pleasure to have him aboard on this open-source xCard adventure. Eric: I have developed new menus. They work nicely (amazing what can be done with the DO command). Alain: Aha! The infamous DO command at work. Eric: ...adding submenus (lineSize, polySides)... Alain: Sub-menus would indeed be nice, for stuff like: fontSize, fontFace, lineSize, etc. It groups together related things and makes the interface less cluttered. But please make the sub-menus only one level deep. Eric: However adding submenus (lineSize, polySides) would, i think, require more than 10 lines. Alain: It was my understanding that once we got the organisation and licencing issues worked out, that Scott was going to provide us with a special licence on the full-fledged version of MetaCard (e.g. no 10-line limit) Eric: The new menus ... I would also like to move some menuItems within existing menus ... Alain: This may be a stupid question but here goes. Are you aiming for something quite similar to the current HyperCard interface, or a better-looking variation on MetaCard's current GUI, or are you aiming for something radically different? I have no well-formed opinion on this matter yet, except to say that the latter 2 options might make us stray far away from what HyperCard users will expect from a HyperCard-clone. Alain: ... but I lost the list. Eric: do you have a find function? :) Alain: The list was scribbled on a piece of paper that used to adorn the billboard over my desk. Alain: And the situation has perhaps changed since the lost-list was made. Alain: Besides, my above statement goes much more to the heart of the matter. The old list, even if I still had it, might not be relevant anymore. Alain: (re-reading my own message, I realized that I had not completed my thought). Eric: think first then write? thimk? Alain: I systematically re-read each part of my letters, while I am composing it (in-situo), and afterwards too (globally) once my message is composed. I make sure that I have responded to every item that I wanted to respond to, as evidenced by my infamous habit of chopping up posts and prefixing them with the interlocutor's name. And I also screen out typos and grammatical errors - my own mostly. Alain: But no one is perfect, eh! In my defense, I caught it myself immediately after I committed the omission. ;-) __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: OODL: webSite-generator update
Alain: This new version will thus be simpler, faster, and more secure ... Uli: I can't really tell you how much I thank you for doing this. I liked the old design, really... Alain: It is kind of you to say so. Uli: ... but with the problems Anthony had I guess there'll likely be more people who would have suffered these problems. Alain: It does kind of throw a monkey-wrench into my development plans. For one, it makes me uncertain about which technologies to focus on for the future. I was also hoping to achieve two goals at once by basing my work for us, on R-and-D that I have to do anyways. Uli: I hope it's not too much work for you. Alain: It's not so bad, after all. It took me a day to remove most of the overly-complex stuff. It will take me another free day or so to complete the job. Uli: If you need any utility handlers etc. be sure to get word to the list (maybe even the UFP list), so all of us can help you. Alain: Excellent idea but I will clean up a little bit more before getting down to some handler fine-tuning, so I will take you up on this soon but not right away. Uli: BTW - my offer still stands, if you need an XCMD, tell me and I'll try to write one. This might dramatically speed up things. Alain: This would indeed kick ass. Once all of the handlers are fine-tuned, we'll transform some of them into externals. You will be hearing from me, Uli. :) Alain: We will also see if Elektra can be added to the mix. What licencing scheme is it under? ;-) Uli: I've recently started writing a simple dragdrop XCMD that offers similar features as Serf provides in this regard. Alain: I have no need for it now, but I will undoubtedly find one for it. I like drag-and-drop. There is something really cool about it. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
