RE: Moving the MC IDE forward
> I once considered writing a Rev plugin called GhostCard, which > would emulate > the UI of the dead HyperCard: > > When activated, the Rev IDE is suspended and replaced with a > black-and-white > UI that emulates the Hypercard expoerience. You could only work with one > image, only select one object at a time, no options for tab controls etc. > > It would also have a Preferences stack with a User Level feature: > values go > from 1 to 5 plus a special value for "Infinity". If you set the > User Level > to Infinity the Ghostcard UI goes away and Rev comes back. > > ;) > Now that would be an amusing waste of time ;-) As Buzz Lightyear would say 'To infinity and beyond!' Monte > -- > Richard Gaskin > Fourth World Media Corporation > Developer of WebMerge 2.2: Publish any database on any site > ___ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 AIM: FourthWorldInc > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Ben Rubinstein wrote: > Maybe that is the way forward for those who will want to continue to upgrade > to new engines etc, benefit from the additional libraries, but use their own > or the "classic" MetaCard UI. It might even be possible to formalise this > in a future version of Rev - eg have preferences to switch off the Rev UI at > startup, and to open some other UI at the same time. (Actually the latter > may hardly be needed; I have a little toolbar which supplements the Rev UI, > which is implemented as a Rev "plugin", and set to open at startup and glue > itself to the end of the Rev menubar. When the Rev UI is suspended, my bit > stays in place.) I once considered writing a Rev plugin called GhostCard, which would emulate the UI of the dead HyperCard: When activated, the Rev IDE is suspended and replaced with a black-and-white UI that emulates the Hypercard expoerience. You could only work with one image, only select one object at a time, no options for tab controls etc. It would also have a Preferences stack with a User Level feature: values go from 1 to 5 plus a special value for "Infinity". If you set the User Level to Infinity the Ghostcard UI goes away and Rev comes back. ;) -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Not that I'm here to speak for RunRev or anything (and for all I know those folks may know of a reason why this suggestion is a very bad idea); but if you're interested in things like the database support, but find the interface too rcih/in your face, have you tried the "Suspend Development Tools" option under the "Development" menu? Interesting, I missed this menu item. It's encouraging only because it proves Kevin can easily provide a *minimalist* authoring environment that MC users are accustomed to. I'd have thought this might mean you get all the advantages of Rev in terms of extended libraries - but effectively get rid of all their UI (except for one tiny pallete with a "Restore" button on, which you minimise). I'd guess you could then just open the MetaCard UI instead (but of course I could be wrong). I think it was meant to hide the Rev tools while you tested your stack. It otherwise does not appear to do much in *suspended* mode. Maybe that is the way forward for those who will want to continue to upgrade to new engines etc, benefit from the additional libraries, but use their own or the "classic" MetaCard UI. It might even be possible to formalise this in a future version of Rev - eg have preferences to switch off the Rev UI at startup, and to open some other UI at the same time. (Actually the latter may hardly be needed; I have a little toolbar which supplements the Rev UI, which is implemented as a Rev "plugin", and set to open at startup and glue itself to the end of the Rev menubar. When the Rev UI is suspended, my bit stays in place.) Agreed. Seems trivial to make an MC IDE as a *plugin* which is built and supported by MC users and use the *Suspend* type feature to switch between the two. Seems easier to do this than to support two independent IDEs. I'd be interested to hear from anyone who gives this a go. Or RunRev's opinions if in fact they think it's a Very Bad Idea. Same here. Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Sincerely, Simon ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
on 7/21/03 3:10 PM, Simon lord wrote > Maybe Kevin will add a pref dialog that allows us to decide what > palettes and menus we want to see in our work environment. That would > help considerably and I don't see it as being that difficult to provide. [...snip...] > On Monday, July 21, 2003, at 09:10 AM, Robert Brenstein wrote: [...snip...] >> Well, I for one have just renewed MC licence, so I am "stuck" so do >> speak with MC for another year. Not that I despair. I am happy with >> MC, and I see no need for fork out a few hundred bucks to switch to >> Rev any time soon. I am among those for whom Rev's interface is too >> rich and gets in my way. Not that I'm here to speak for RunRev or anything (and for all I know those folks may know of a reason why this suggestion is a very bad idea); but if you're interested in things like the database support, but find the interface too rcih/in your face, have you tried the "Suspend Development Tools" option under the "Development" menu? I'd have thought this might mean you get all the advantages of Rev in terms of extended libraries - but effectively get rid of all their UI (except for one tiny pallete with a "Restore" button on, which you minimise). I'd guess you could then just open the MetaCard UI instead (but of course I could be wrong). Maybe that is the way forward for those who will want to continue to upgrade to new engines etc, benefit from the additional libraries, but use their own or the "classic" MetaCard UI. It might even be possible to formalise this in a future version of Rev - eg have preferences to switch off the Rev UI at startup, and to open some other UI at the same time. (Actually the latter may hardly be needed; I have a little toolbar which supplements the Rev UI, which is implemented as a Rev "plugin", and set to open at startup and glue itself to the end of the Rev menubar. When the Rev UI is suspended, my bit stays in place.) I'd be interested to hear from anyone who gives this a go. Or RunRev's opinions if in fact they think it's a Very Bad Idea. Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Agreed. I tried to give Rev an honest chance this weekend and got totally frustrated with all the palettes. I was genuinely happy to see support for MySQL and other items I need but the interface simply turned me off and I had to use MC in the end. It's not that I didn't understand the palette options and offerings, it's just that I don't want/need to know about these things while developing. It's *too* helpful, kinda like a car salesman. Maybe Kevin will add a pref dialog that allows us to decide what palettes and menus we want to see in our work environment. That would help considerably and I don't see it as being that difficult to provide. On Monday, July 21, 2003, at 09:10 AM, Robert Brenstein wrote: On Friday, July 11, 2003, at 11:42 AM, Richard Gaskin wrote: So putting it just as bluntly, that there is a perception of MC's value is reason enough. If that perception changes over time the MC engine will whither away naturally. There should be no need to force change, and doing so would not have the liberating feeling of a choice. I'm not proposing forcing anyone to switch. That's not even what I'm asking about. I'm specifically curious why people would expend significant effort updating/enhancing the MC environment. If all we're talking about is maintaining compatibility with new engines, then that's a minimal task and I don't see any reason not to. Well, I for one have just renewed MC licence, so I am "stuck" so do speak with MC for another year. Not that I despair. I am happy with MC, and I see no need for fork out a few hundred bucks to switch to Rev any time soon. I am among those for whom Rev's interface is too rich and gets in my way. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Sincerely, Simon ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Friday, July 11, 2003, at 11:42 AM, Richard Gaskin wrote: So putting it just as bluntly, that there is a perception of MC's value is reason enough. If that perception changes over time the MC engine will whither away naturally. There should be no need to force change, and doing so would not have the liberating feeling of a choice. I'm not proposing forcing anyone to switch. That's not even what I'm asking about. I'm specifically curious why people would expend significant effort updating/enhancing the MC environment. If all we're talking about is maintaining compatibility with new engines, then that's a minimal task and I don't see any reason not to. Well, I for one have just renewed MC licence, so I am "stuck" so do speak with MC for another year. Not that I despair. I am happy with MC, and I see no need for fork out a few hundred bucks to switch to Rev any time soon. I am among those for whom Rev's interface is too rich and gets in my way. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
I have a library of custom handlers that I load at startup in both MC and Rev. One of my handlers reports the mainstacks that are currently loaded in memory. When I run this handler in MC, there are at most only a couple of stacks from the IDE listed, but in Rev, it is difficult to find my own stacks among the dozens that Rev maintains. When I get around to it, I will customize my handler to remove all the "rev" stacks before displaying the results, but at that moment the extra info was intrusive. I can't remove these stacks from Rev (nor do I want to) because they are necessary to its functioning. A somewhat parallel example is the number of custom messages that are constantly being sent in the background by Rev. I know I can view a modified list of pending messages from within the message box, but since MC sends no custom messages in the background at all, MC's IDE translates to the user as "cleaner." And again, these custom messages can't be removed from the program. ... -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com This may not be critical for many applications but it may for some. I wonder, for example, how those extra messages flying behind affect using Rev as a cgi on a web server? Similarly, how the timing issues are affected for, for example, psychology experiments that measure reaction times? I gather than some of these msgs continue to fly in standalones as well. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Sat, 2003-07-12 at 20:04, J. Landman Gay wrote: > On 7/12/03 10:02 AM, Geoff Canyon wrote: > -- snip -- > > For those who prefer MC's simplicity, I don't see any harm in continuing > to assure it is compatible with the most current Rev engine. People will > still have to purchase Revolution to get full access to long scripts, so > RR won't lose any money by allowing folks a choice of IDEs. They have > already said they won't support alternate IDEs, so it won't cost them > anything. And i wants to add that, because, some RR/MC apps needs to be build to run with no GUI at all (backgrounder or console-mode apps and demons), we needs to have a lightweight UI available to code, debug and maintain this kind of apps, for a best usage of the memory and the processor by the hosting servers. -- Bien cordialement, Pierre Sahores Serveurs d'applications & bases ACID SQL Penser et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On 7/12/03 10:02 AM, Geoff Canyon wrote: Then I don't understand all the talk of customizing MC. If it's near perfect (for those who like simplicity) the way it is, let it stay that way. It won't take a team effort to keep it compatible with any foreseeable changes to the engine. I don't recall much talk about altering the MC IDE. What I did see was a desire by long-time users to retain the simplicity and straight-forward nature of what is available right now. I suspect that a bit of embellishment will inevitably occur, but in general I think the goal is simply to retain the compatibility of the relatively static interface that MC has had all these years. For those who prefer MC's simplicity, I don't see any harm in continuing to assure it is compatible with the most current Rev engine. People will still have to purchase Revolution to get full access to long scripts, so RR won't lose any money by allowing folks a choice of IDEs. They have already said they won't support alternate IDEs, so it won't cost them anything. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Friday, July 11, 2003, at 11:42 AM, Richard Gaskin wrote: So putting it just as bluntly, that there is a perception of MC's value is reason enough. If that perception changes over time the MC engine will whither away naturally. There should be no need to force change, and doing so would not have the liberating feeling of a choice. I'm not proposing forcing anyone to switch. That's not even what I'm asking about. I'm specifically curious why people would expend significant effort updating/enhancing the MC environment. If all we're talking about is maintaining compatibility with new engines, then that's a minimal task and I don't see any reason not to. regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Friday, July 11, 2003, at 10:32 AM, J. Landman Gay wrote: These are very minor examples, none of which are crucial or insurmountable. I can customize my way out of the first two of them easily. But the lean IDE in MC has its appeal -- precisely because I *don't* have to customize it. It just stays out of my way. I think it is this kind of thing that causes experienced MC users to accuse Revolution of "bloat". It is also this feeling of steamlined useability that caused HyperCard people to accuse MetaCard of "bloat" as well. ;) Hypercard's huge advantage is the way its own IDE remains completely out of sight until you need it. Then I don't understand all the talk of customizing MC. If it's near perfect (for those who like simplicity) the way it is, let it stay that way. It won't take a team effort to keep it compatible with any foreseeable changes to the engine. The most likely answer to your question is that, given human nature, people don't easily change their habits. For myself, I find I use Revolution far more from the message box than from within its many palettes. It's just how I'm used to doing things, and it is much faster because I type fast and I don't have to wait for interface elements to load. The good news for MC users who are moving to Rev is that it works just fine that way. That's what troubles me: that people will remain with MC, and spend effort on adding features into it that already exist in Revolution, out of human nature. Wouldn't it be easier to address the issues you see in Revolution, and get the rest of what Rev offers (and will be updated to offer) for free, rather than having to re-implement the wheel in MC? Finally, everyone (who prefers MC) seems bothered by the palettes in Revolution. Wouldn't it be possible to simply not open/use those palettes? regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On 7/11/03 1:01 PM, Shari wrote: This brings up a question. I remember when I initially tested Rev vs. MC, Rev required a LOT more memory. Now if I have a project, and compile it in Rev, and MC, will it require more memory in Rev? The extra RAM is mostly for the IDE. Once your stacks become standalones, they shouldn't require any more memory than they did in MC. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Geoff Canyon wrote: > In short, (putting it bluntly) why would anyone want to spend effort > maintaining/updating MetaCard's development environment when the > Revolution environment is also customizable? Very different levels of customizability. For example the Rev license expressly forbids modification of the Distribution Builder, but modifying MC's has let me make a simple automated system that works exactly as I want it to. When it comes to customizability, nothing is more open than Open Source. So maybe a better question might be to ask "Why not?" There is a perception among many here that the MC IDE is useful. Let it be. It costs RunRev nothing to have three (Rev, MC, FreeGUI) or a million IDEs; they all require a licence key to get past the script limits. As Scott used to say, "Let a thousand flowers bloom." There are many benefits to the multi-IDE world we find ourselves in, for everyone involved: - Just as Linux has multiple window managers, the MC engine is powerful enough to drive an unlimited number of IDEs. Let people choose the one they feel most comfortable with. - Since RunRev only provides support for their own IDE, they stand to save money on support costs to the degree that folks use non-Rev-supported IDEs. - Open IDEs allow a level of design experimentation that benefits the entire community, but benefits Rev most of all. The alternative for Rev would be extensive user testing on multiple prototypes, which would be costly and likely yield less useful data than field-tested implementations. All IDEs have the opportunity to learn from one another, and as the owner of the technology Rev is the only one that can borrow from the others; they get free R&D. ;) So putting it just as bluntly, that there is a perception of MC's value is reason enough. If that perception changes over time the MC engine will whither away naturally. There should be no need to force change, and doing so would not have the liberating feeling of a choice. The current plan as announced seems to wisely take these factors into account, taking nothing from anyone and only adding new opportunities for all. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
But for those who have been using MC for a long time, the extra palettes, libraries, and interface elements can get in the way. Someone mentioned speed, and that's a consideration too; it does take somewhat longer for Rev's palettes to load and display their data -- noticeably more time than the equivalent MC palettes. I can think of two examples of how Rev slows my work, both of which I ran up against yesterday, and which caused me to simply switch my working environment from Rev to MC for that session. This brings up a question. I remember when I initially tested Rev vs. MC, Rev required a LOT more memory. Now if I have a project, and compile it in Rev, and MC, will it require more memory in Rev? I would assume so, as all the MC stacks I currently embed in my standalones, would now have to be Rev stacks if compiled in Rev. My new project takes awhile to load in MC. Presumably for the 2000 objects on one card (and nope, this won't be changed, though the public release will not be as bloated, this stack is just for me). I wonder what Rev would do to it? Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On 7/11/03 12:03 AM, Geoff Canyon wrote: Out of curiosity, what is it that the MetaCard development environment has that the Revolution environment doesn't? Or, what is it that MetaCard _doesn't_ have that can't be hidden or > done away with in Revolution? The second statement is more likely on target. I can use either environment in most cases, but there are some times when MC is easier. The thing that MC has that Rev doesn't is, in a nutshell, simplicity. This issue is probably of more consequence to experienced MC users than those who come new to Revolution. For users who are not as familiar with the capabilities of the engine, Rev probably offers the best interface because it is so visual: the user doesn't need to know the entire language and environment to get work done. There are lots of palettes and libraries to help, and a lot of the stack design can be done by simply clicking checkboxes and filling in a few fields. But for those who have been using MC for a long time, the extra palettes, libraries, and interface elements can get in the way. Someone mentioned speed, and that's a consideration too; it does take somewhat longer for Rev's palettes to load and display their data -- noticeably more time than the equivalent MC palettes. I can think of two examples of how Rev slows my work, both of which I ran up against yesterday, and which caused me to simply switch my working environment from Rev to MC for that session. I am porting a 4,000-card, multi-background client stack from HyperCard to Revolution. I wanted to look at a list of all objects on a particular card. It is impossible to see an overview of a stack this large in the Application Overview unless you are willing to go out to lunch and maybe have a couple of drinks while it is loading. I didn't need, or want, to see a list of all the cards -- obviously this is a database -- I just wanted to see the objects on the current card. It was a no-brainer; I opened it in MC where the Control Browser showed me -- instantly, with no delay -- only what I wanted. Rev's IDE, in this case, interfered and slowed me down. I know there are third-party Rev tools to do what I want (including your own control browser) but at that moment I couldn't play with the IDE, I just needed to get the work done. Switching back to MC was easier and a magnitude faster. (The fact that there are several third-party control browser stacks around shows that my experience is common and perhaps should be addressed by Runtime.) I have a library of custom handlers that I load at startup in both MC and Rev. One of my handlers reports the mainstacks that are currently loaded in memory. When I run this handler in MC, there are at most only a couple of stacks from the IDE listed, but in Rev, it is difficult to find my own stacks among the dozens that Rev maintains. When I get around to it, I will customize my handler to remove all the "rev" stacks before displaying the results, but at that moment the extra info was intrusive. I can't remove these stacks from Rev (nor do I want to) because they are necessary to its functioning. A somewhat parallel example is the number of custom messages that are constantly being sent in the background by Rev. I know I can view a modified list of pending messages from within the message box, but since MC sends no custom messages in the background at all, MC's IDE translates to the user as "cleaner." And again, these custom messages can't be removed from the program. These are very minor examples, none of which are crucial or insurmountable. I can customize my way out of the first two of them easily. But the lean IDE in MC has its appeal -- precisely because I *don't* have to customize it. It just stays out of my way. I think it is this kind of thing that causes experienced MC users to accuse Revolution of "bloat". It is also this feeling of steamlined useability that caused HyperCard people to accuse MetaCard of "bloat" as well. ;) Hypercard's huge advantage is the way its own IDE remains completely out of sight until you need it. The most likely answer to your question is that, given human nature, people don't easily change their habits. For myself, I find I use Revolution far more from the message box than from within its many palettes. It's just how I'm used to doing things, and it is much faster because I type fast and I don't have to wait for interface elements to load. The good news for MC users who are moving to Rev is that it works just fine that way. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Taking as a given the fact that the MetaCard development environment is much more static than the Revolution development environment, and therefore has had more of the bugs ironed out of it: Out of curiosity, what is it that the MetaCard development environment has that the Revolution environment doesn't? Or, what is it that MetaCard _doesn't_ have that can't be hidden or done away with in Revolution? Or, what is it that is done so differently in MetaCard than it is in Revolution? In short, (putting it bluntly) why would anyone want to spend effort maintaining/updating MetaCard's development environment when the Revolution environment is also customizable? regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Wed, 2003-07-09 at 22:34, Mark Talluto wrote: > On Wednesday, July 9, 2003, at 01:23 PM, Richard Gaskin wrote: > > > Tereza Snyder wrote: > > > >> on 07.09.03 1:20 PM, Richard Gaskin wrote: > >> > >>> Things we need to decide: > >>> > >>> - Is Yahoo Groups acceptable as a groupware solution for this > >>> project? > >>> With its discussion list, file repository, calendar, and links it > >>> gets my vote, but there may be things I'm overlooking. > >>> > >>> - If so, is it simpler to alter the existing group or create a new > >>> one? > >> > >> > >> It seems like a good solution, and a good group to use. It hasn't had > >> much > >> traffic since the action moved to the MetaCard list at RunRev. > > > > Thanks for the feedback. In the absence of any dissenting opinion I'll > > contact that list admin and run this past him > > > > > > I am just curious to know how many people are planning on staying with > MC and being active in maintaining its IDE? > > > Best regards, > Mark Talluto > http://www.canelasoftware.com > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > Hello Mark, In my developments (backgrounder client-server apps, web's and erp's front-ends, the xtalk coding + engine power makes 90% of my products. I think i will go to use both the MC IDE and the RunRev 2.xx in the future. Bests, Pierre -- Bien cordialement, Pierre Sahores Applications WEB et ERP personnalisés Penser et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Hi MetaCarders, Recently, "Mark Talluto" wrote: I am just curious to know how many people are planning on staying with MC and being active in maintaining its IDE? I can't say how long we'll stay with the MC IDE (can anyone really?), but I can say we're willing to contribute to its development now. I will sign this! :-) And as Richard pointed out, workflow is the keyword. We all got used to the spartanic UI of MC, created nice palettes when we needed them and, to be honest, more than 90% of our daily work will get covered by the functionality MC provides... We all got used to this old "buddy" don't want to say "goodbye" to him ;-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com Regards Klaus Major [EMAIL PROTECTED] www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On 7/9/03 3:34 PM, Mark Talluto wrote: I am just curious to know how many people are planning on staying with MC and being active in maintaining its IDE? Don't know what the future may bring, but I'd like to remain involved with the MC IDE regardless. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Recently, "Richard Gaskin" wrote: > I would be happy to contribute to the maintenance of the IDE going forward, > and would like to see simpler extensibility as a first step (after we get a > list set up to make it happen, of course). Great suggestion! I think Richard won't mind me mentioning the fact that we recently discussed the possibility of modularizing the IDE, separating as many parts out as possible so that folks can create their own flavors of the UI as needed. (Perhaps the current structure of the IDE facilitates this -- I haven't dissected it too deeply.) Many of us have created our own tools and utilities to enhance our work environments: wouldn't it be nice to be able to add our enhancements to the IDE without having to severely dismember it... Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Recently, "Mark Talluto" wrote: > I am just curious to know how many people are planning on staying with > MC and being active in maintaining its IDE? I can't say how long we'll stay with the MC IDE (can anyone really?), but I can say we're willing to contribute to its development now. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Mark Talluto wrote: > I am just curious to know how many people are planning on staying with > MC and being active in maintaining its IDE? That's a good question. I'm well invested in a nice workflow with nifty quick tools I've added, so I'm inclined to keep that workflow in place for the foreseeable future (although I do some work in Rev as well from time to time and enjoy being able to move stacks seamlessly back and forth). I would be happy to contribute to the maintenance of the IDE going forward, and would like to see simpler extensibility as a first step (after we get a list set up to make it happen, of course). -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
On Wednesday, July 9, 2003, at 01:23 PM, Richard Gaskin wrote: Tereza Snyder wrote: on 07.09.03 1:20 PM, Richard Gaskin wrote: Things we need to decide: - Is Yahoo Groups acceptable as a groupware solution for this project? With its discussion list, file repository, calendar, and links it gets my vote, but there may be things I'm overlooking. - If so, is it simpler to alter the existing group or create a new one? It seems like a good solution, and a good group to use. It hasn't had much traffic since the action moved to the MetaCard list at RunRev. Thanks for the feedback. In the absence of any dissenting opinion I'll contact that list admin and run this past him I am just curious to know how many people are planning on staying with MC and being active in maintaining its IDE? Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
Tereza Snyder wrote: > on 07.09.03 1:20 PM, Richard Gaskin wrote: > >> Things we need to decide: >> >> - Is Yahoo Groups acceptable as a groupware solution for this project? >> With its discussion list, file repository, calendar, and links it >> gets my vote, but there may be things I'm overlooking. >> >> - If so, is it simpler to alter the existing group or create a new one? > > > It seems like a good solution, and a good group to use. It hasn't had much > traffic since the action moved to the MetaCard list at RunRev. Thanks for the feedback. In the absence of any dissenting opinion I'll contact that list admin and run this past him -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving the MC IDE forward
on 07.09.03 1:20 PM, Richard Gaskin wrote: > Things we need to decide: > > - Is Yahoo Groups acceptable as a groupware solution for this project? > With its discussion list, file repository, calendar, and links it > gets my vote, but there may be things I'm overlooking. > > - If so, is it simpler to alter the existing group or create a new one? It seems like a good solution, and a good group to use. It hasn't had much traffic since the action moved to the MetaCard list at RunRev. + Tereza Snyder + Senior Software Developer + Attainment Company, Inc. + + 800.327.4269 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
