>I sent copies of a prototype gui to alain, uli, and mr. DeRobertis. Did you
>recieve them? Did they decompress ok? If you have can you upload them?
>(preferably) Or tell me where to upload them? (if necessary).
Eric,
did you already get an FTP user name and password from Alain so you
can access the server? Ask him to create those for you and then get
yourself an FTP client like Anarchie or Fetch to upload the files.
It's pretty straightforward -- just enter user name, password and
server name (ufp.uqam.ca) and drop a file on the window to upload it.
You can also use netscape, I think the URL would be
ftp:[EMAIL PROTECTED] and then you can drop the file on the
resulting file list window.
>As far as the gui goes, i can definitely script a new menubar and change the
>dialogues existing - even the properties box. Who is interested in the GUI?
>Anyone? If not that is cool, i really can handle it (punintended:)
>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.
I can't work on the UI due to time constraints (though I'd love to),
but what you've done looks neat. I have to say my personal preference
goes to the MacOS 8 bevel buttons' looks, but this gradient thing
looks nice, and the blue highlight is a good use of color. Maybe you
could make the gradient a bit more pale, but that's a matter of
personal taste, not of good or bad.
Re the menus and dialogs -- what you have done with those two menus
looks promising (though I think I'd use a palette instead of a
text-only tool menu). The most important thing is that you arrange
things in an intuitive way. E.g. I always have to search for the
"icon" field in the Object Properties dialog, since it's not in the
"Appearance" tab, even though an icon is part of a button's
appearance.
Also, I consider palettes that are as large as the icon picker to be
a major inconvenience. This is the kind of window I wouldn't mind
being smaller or being a modal dialog window instead of a palette.
I'd say the opposite about user properties. Those should be in a
small, probably resizeable palette instead of a modal dialog. These
are my personal preferences, though. E.g. I often decide to put a
field's text in a user property, or to fetch text fragments from a
number of external files or other stacks and then copy them into a
user property. In that case it's much more convenient if you don't
have to open and close dialog windows every time.
So, the rule of thumb might be: If you find yourself looking for a
feature's location more than once, or if you find yourself cursing
about some window not automatically going away or going away when you
still need it, change it.
It might be a good idea to tell the list about these problems, then
we can help you decide, provide additional feedback etc.
>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.
I have to say I'm not that concerned about the partnership stuff
right now. For me it was mainly related to the MetaCard licensing
issue. I'd consider a licence to place the code under much more
important. My thought would be a simple one that ensures that we can
continue using the sources even if we lose FreeCard due to a mistake
in or the utter lack of the partnership agreement.
I.e. I'd prefer a licence that basically causes the code to become
FreeWare for lifetime. If this required the code to become Public
Domain, we'd just need a draft for a statement that everyone signs
(electronically, if this is legally valid) that says any code, ideas,
graphics, sounds etc. (maybe find a good term that groups all kinds
of contributions) the signee creates become FreeWare and may be used
by anyone and distributed without royalties, and that anything that
isn't supposed to fall under this license would be announced and only
submitted upon confirmation.
If I'm not flamed with all kinds of amendments to this, could you
maybe draft a quick agreement of this sort that legally ensures we
can use what is submitted without fear of royalty fees? Then we could
pick that apart if need be.
This would make it possible for work to really start. We could
require signing this agreement before joining the mailing list, and
we could require mailing list membership (or for one-time
contributions external signing) before anybody is allowed to work on
FreeCard.
With that set up, we could begin working carelessly and
simultaneously design additional infrastructure. I could also begin
posting requests for submissions on newsgroups and in other places,
thus maybe attracting additional programmers. As you know, we're
still pretty low on non-Mac programmers (2 Mac folks, 2 Windows
folks, one of them incapacitated, and that's it).
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
