>Alain: Yes. That's exactly what I am aiming for. The
>application should not presume that user-manipulable
>cards and components will be present in a given user's
>Home stack. NO assumptions at all would be ideal. The
>whole idea of HyperCard requiring a stack called
>"Home" in order to run is a mistake that we must fix.
Alain,
sounds sensible, though I suppose to achieve our 100% claim we will have
to support it nonetheless. But you're right, requiring it might not be the
right decision.
>Alain: Odd that Apple never provided a way for people
>like ourselves to add new buttonTasks.
Uli: I think they were mainly intended as a more flexible way to extend
HyperCard in a more MacOS-like way, e.g. to provide a good user interface
for an XCMD (like Movie). That's the reason why there are only programmers'
APIs for this.
>Alain: The
>handlers FTP will be particularly interesting because,
>for example, you could import a Pantechnicon handler
>directly into the scriptEditor as you are scripting.
Uli: That is a nice idea. Readymade web import into the most common dialogs.
>Alain: I have glanced at them, when the occasion
>presented itself, but I will surely examine them all
>when brainstorming the new ScriptEditor. I think that
>AppleScript's editor has nothing to offer us though.
Uli: I kinda liked the freely configurable syntax coloring and the "check
syntax" button. Recording is also a cool option, though I am not quite sure
this would be that easy to do in FreeCard. Adding a recording feature might
slow down the whole application even when it is off. Howver, it is
certainly a 2.0 feature we can keep in the backs of our heads.
>Alain: You could use bold, underline, italic,
>fontFace, fontSize (deprecated). You could also group
>portions of a complex expression such that the groups
>reflect the structure of the syntax.
Uli: That's another aspect I liked about the AS script editor. It uses
Courier for newly entered text, Geneva for syntax-checked text and
different colors and styles for keywords and comments.
>Alain: Sure. Why not? This a collaboration after all.
>:)
Uli: Yeah! Go and get it! :-)
>Alain: I thought that you were alluding to the
>visceral dislike of MetaCard by many HyperCard fans
Uli: Not really. Most of that (at least today) is more people's fear of
new things. I have come to quite enjoy using my copy of MetaCard recently.
Especially its speed and good text-manipulation facilities are a great
time-saver (a "replace" command! Yeah!). The only thing thatspoils it a bit
is the docs. I still haven't figured out how one uses the regexp stuff.
>Alain: Yes. This is non-political technical reasoning
>that underlies this move. It's good design-sense to
>keep the GUI distinct from the engin and the language.
Uli: Yes. But due to the inherent differences between the languages (e.g.
how backgrounds are understood, at what level windows are inserted in the
hierarchy etc.) we *will* eventually have to make some adaptions.
>Alain: My aim with regard to FreeCard is to
>approximate 100% compatibility of HyperCard as we know
>it now. Once this is achieved, I am discharged of my
>responsibility.
Uli: If you wish.
>After that, we will see how things
>play out. I want to continue being responsive to
>FreeCard's needs, but I do have an agenda of my own
>that I wish to achieve in the next six years (or
>more). Anyone wishing to embark on my bus is welcome
>to, and the journey is not mapped out in advance
>(democratic), but I have some definite ideas of what
>sights I would like to see on the way.
Uli: This is why I like a plug-in scheme so much. Everybody can write
stacks that suit their needs and insert them in the UI (SuperCard's
"Utilities" menu is a good start, but I would like to have the whole UI,
except for the most basic items like "Open..." and "Close") consist of
plug-ins. This way, people who create their own power-user tools that they
want to be open so they can modify them while working with them can trash
the menu bar editor and the standalone maker, etc. But good to know we
agree on modularity.
>Alain: For instance ? ;-)
Uli: There is the inherent danger of people making HyperCard a monolithic
giant like M$ Office or Netscape Communicator. What is the use in wrapping
five distinct applications in one application file so I have to start up
the whole web browser and Newsreader shebang when I only want to read my
e-mail? I would much prefer, for instance, to be able to run Netscape
Messenger as a stand-alone application. If people keep adding an FTP stack
to FreeCard that just does what Fetch does, and a web browser stack that
just does what iCab does, it will become a huge distribution of files that
all rely on each other, and new users will be frightened away. However,
with a plug-in scheme, we can make a basic distribution with a set of tools
like HyperCard provides them and make everything else optional plug-ins.
>Alain: In my view, collaboration is in everyone's
>interest because the lone-wolf developer that does an
>entire project without any outside contact, is an
>increasingly rare phenomenon. At the very least, you
>are in collaboration with your customers and/or the
>people who will be using your wares, aren't you?
Uli: After a fashion. However, the customers I have worked with so far
were mainly end-users. Most were happy that they could manage their e-mail
program and just wanted a finished program to do what they want. They
wouldn't have wanted me to give them any other program just to communicate
with me. Remember, some states on this world still use dial-up internet
connections, and there it is most useful to have one command to
automatically up/download everything and then disconnect. If they had to
also start up FC, they'd forget it half of the time or it would cost more
in online time.
Uli: I don't want to get you to drop your ideas, but I just want to
prevent silly things happening like when At Ease was first introduced,
where my computer asked me to select a user every time at startup even
though I had only one configured. Multi-user and collaboration mechanisms
tend to get in the way of single users.
>Alain: I chose to focus my attention on the scripting
>because that is the skill that is the least prevalent
>in the public at large. This lack of scripting ability
>is notably true in Education. As for the multimedia
>aspects that you mention above, they will be included
>in time, but they are not my primary focus right now.
>Among other things, factory-style stereotypical
>graphics are often looked down upon, by developers and
>users alike.
Uli: I am not necessarily talking about Multimedia. Just a library of
useful buttons. There would, e.g. be a "New template button..." menu
command below "New button" that brings up a dialog where you can browse a
list of cool buttons with finished scripts. This might be your average
navigational buttons with visual effects, or a button with a field to
choose or enter a file path etc. And the users should be able to paste in
new buttons into this library.
>For now,
>suffice to say that I want to create a development
>infrastructure that makes its users more
>methodological and increases the quality of their
>development work. And not just the work of an
>individually. Collectively too.
Uli: I suppose this does not mean they *must* work methodical, right?
Because then we might arrive at restrictions like Pascal's way of forcing
you to stick to its structure of arranging a file.
>Alain: I am not talking about installation wizards. I
>am announcing the preliminary draft idea of my
>doctoral research project which involves modeling
>users/learners in order to augment their potential, to
>form effective groups, etc. The basic idea is the
>"adaptive-agent" will adapt to its user on a
>continuous basis. It will spot opportunities to
>educate the user, in-situo, if they are so disposed.
Uli: So, this is like the "learning computer" ideas some companies used to
have a while ago, where the computer notices that for the umpteenth time
you have used copy+clear and it tells you about the "cut" menu item?
>Alain: I understand what you are writing, and I have
>often thought this too, but for any task of moderate
>complexity, you should provide help/assistance.
Uli: AssistanCE, certainly. But AssistanTS in the term how it's currently
used in MacOS, or "Wizards" as you call them are one of the prime examples
of programmers winning over UI designers.
>Alain: Sure. No problem. All you have to do is type
>"toggleGUI" in the message box and/or you can call
>this handler however you wish. The menubar has been
>redefined though, so be careful if you trigger it with
>a menuItem.
Uli: Free_UI_ ... <hint, hint> ;-)
>Alain: No pressure. And sorry for not consulting you
>about this sort-of announcement that your file-format
>will play a role in FreeGUI in the near-future. I knew
>I could count on you though, and, as it turns out, my
>presumption has panned out. So all is well! ;-)
No problem. After all, the file fomats are under the GPL. They are
intended to be used freely.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freecard-general
