pythoncard-users

[Pythoncard-users] fonts - day one

[Kevin A. <al...@se...>]

If you know anything about fonts, programming issues around fonts,
cross-platform font issues, wxPython font issues, cascading style sheets
(CSS), etc. or just have some opinions on what you want in terms of font
support, please contribute to this thread on the list. Fonts are not a
speciality of mine, so if I end up doing this one alone we're gonna have to
refactor many times ;-)

The time has come to add font support to all the widgets in PythonCard.
Since the prototype is based on wxPython, we're going to be limited by what
can be done with the wxWindows/wxPython library and we're going to be
further limited by what is going to work across platforms. Rowland and I
avoided adding MS Windows-specific features to any of the existing widgets,
and fonts should be handled the same way. This is also the time to start
looking at wrapping wxSTC (Scintilla) for styled text support, though I'm
still unclear on how the wxTE_RICH style for wxTextCtrl relates to wxSTC if
at all.

I encourage everyone to at least read the wxFont overview in the
wxWindows/wxPython documentation, but I'm going to include it at the end of
this message in case you don't know where to look. Other relevant sections
include: Font encoding overview, Unicode support in wxWindows, wxFont class,
wxFontDialog, and just about any other topic in the wxWindows docs with
'Font' in the name.

I don't want to use the wxWindows constants directly for font families, but
will probably use some equivelant mapping initially. I definitely want to
support basic style sheets, so that an app can define a fontStyleSheet and
then set the font for a widget simply by referring to the named
fontStyleSheet. This isn't going to be a full web CSS-like capability, but
we can borrow some of the ideas from CSS.

platform-specific features
In the future, we will probably have a some kind of setting so that if you
wanted to write a PythonCard app that uses platform-specific features the
framework will let you do so, but then make appropriate warnings when the
app is being written and run. So, if there is some feature that is
platform-specific that you want, you can still bring it up and it will get
posted into the feature requests.

ka
---

wxFont overview
Class: wxFont

A font is an object which determines the appearance of text, primarily when
drawing text to a window or device context. A font is determined by the
following parameters (not all of them have to be specified, of course):

Point size  This is the standard way of referring to text size.
Family  Supported families are: wxDEFAULT, wxDECORATIVE, wxROMAN, wxSCRIPT,
wxSWISS, wxMODERN. wxMODERN is a fixed pitch font; the others are either
fixed or variable pitch.
Style  The value can be wxNORMAL, wxSLANT or wxITALIC.
Weight  The value can be wxNORMAL, wxLIGHT or wxBOLD.
Underlining  The value can be TRUE or FALSE.
Face name  An optional string specifying the actual typeface to be used. If
NULL, a default typeface will chosen based on the family.
Encoding  The font encoding (see wxFONTENCODING_XXX constants and the font
overview for more details)


Specifying a family, rather than a specific typeface name, ensures a degree
of portability across platforms because a suitable font will be chosen for
the given font family.

Under Windows, the face name can be one of the installed fonts on the user's
system. Since the choice of fonts differs from system to system, either
choose standard Windows fonts, or if allowing the user to specify a face
name, store the family id with any file that might be transported to a
different Windows machine or other platform.



----------------------------------------------------------------------------
----
Note: There is currently a difference between the appearance of fonts on the
two platforms, if the mapping mode is anything other than wxMM_TEXT. Under
X, font size is always specified in points. Under MS Windows, the unit for
text is points but the text is scaled according to the current mapping mode.
However, user scaling on a device context will also scale fonts under both
environments.

[Pythoncard-users] PythonCard Visual Card Creator

[Ronald D S. <rd...@ea...>]

Unfortunately, just as I am making progress studying the samples code, I am forced to make an unexpected trip overseas again, I will
be out of commission for a week and a half. So, at the risk of being embarassed by my obvious ignorance and naivete, I am going to
summarize some thoughts I am having.

What I most hope for is for someone to code a sort of visual card creator for PythonCard. In other words, a visual card creator
might show a visual palette or window or card, with a group of icons at the top representing the various widgets that Kevin has
already created for PythonCard. It is not necessary nor even desirable to show an infinite number of widgets; rather, only a  small
but representative sample of the widgets, one of each generic kind, sort of a mini sampling of the functionality of PythonCard, to
allow beginnners or neophytes to begin coding real, usable mini-PythonCard gui's right away, from the beginining of their
experience.

I really believe in the concept of "hooking" potential users right up front, allowing them to then evolve or grow into the coding
environment naturally, by trial and error, a little at a time.

In any intellectual creation task, such as  creating a program, the hardest thing of all, by far, is the first step. Most people
never get started, because the first step is just too daunting and scary. But when and if a person completes a first step, no matter
how small, and gets a psychic reward of success, they are hooked, and they may never turn back.

So, a sample card or window, offering a small set of widgets, that can be pointed at and clicked on, and then dragged to the
appropriate spot on the window, offers an inviting introduction to PythonCard. After placing the widget, a right click could bring
up a properties window, or a menu offering the selection of all of the various PythonCard program modules, such as resource files,
resource editors, or the master PythonCard programming environment.

Some of this code to do this may be "borrowable" from elsewhere. What about Boa Constructor? With all of the open source programs
like Boa, to do some sort of visual gui creation, aren't they available for code borrowing? Therr is nothing wrong with code
borrwoing, as I understand it is an honor to have one's code stolen??? Of course, let me hasten to add, that what I have in moind
here must be far simpler than anything Boa offers or does, or else it will miss sthe purpose.

Now it would be nice if someone or some group would step up to the plate and help out on doing this piece of the programming. Kevin
can't do it all by himself;-)))))))

While we're at it, what about a visual metaphor for manipulating the cards in Pythoncard? Couldn't we create a visual "stack" of
Pythoncards, sort of like the old Windows 3.1 Cardfile.exe program, does anyone remember that, that showed a rolodex type stack of
cards for storing addresses, phone numbers and other contact information? A visual stack of Pythoncards could be manipulated easily
and effectively.


I hope someone will step up to the plate and help Kevn on this.  I know that what I am so crudely and clumsily trying to describe
must represent a tremendously difficult and arduous programming task, and so I am very presumptuous to even mention the topic. But
think what a boon to programmers this could be?

I am overwhelmingly impressed and overjoyed with what Kevin and you all have already created. I am humbled by my attempts to learn
by studying the source code for the samples. I believe the programming model already being implented will represent a huge step
forward for Python gui creation.

But a visual metaphor for doing the simplest gui ceation, only, the introductory card creation, would be the coup de grace that
would provide the introductory enticement to lure the multitudes of people, making PythonCard unstoppable, make it what some many of
us have dreamed of. I hope I am not out of line to dream publicly on this list.

Ron Stephens

p.s. I must leave for the airport right now, so I apologize for the sketchy description of what I have in mind. I will be unable to
add to it or answer questions for a week and a half. But maybe that's good. Those of you so much more knowledgeable and capable than
I can probably create something much better than what I am imagining anyway. Suffice it to say, a visual, easy to use
mini-introduction to creating pythoncards would be useful, and would help, even a this early stage in the development of Pythoncard,
to attract users and maybe even contributors. It doesn't need to be fancy, not powerful, nor in any way complete; just an easy way
to get started for users in creating the simplest PythonCard event driven gui applets, if you will.

...sorry for not being able to contribute, but admiring and grateful to all of those who do contribute, Ron Stephens

RE: [Pythoncard-users] PythonCard Visual Card Creator

[Kevin A. <al...@se...>]

Which release are you using? You can check by selecting 'About
PythonCard...' from the 'Debug' menu if you've enabled the Message Watcher,
Property Editor, or Shell when you started a sample. It will display a list
of version numbers such as:

PythonCard version: 0.4.3
wxPython version: 2.3.1
PyCrust version: 0.5.3
Python version: 2.1 (#15, Jun 15 2001, 14:13:47) [MSC 32 bit (Intel)]
Platform: win32

Hopefully, you're using release 0.4.3. If so, have you tried the
resourceEditor sample? You can open up any of the sample .rsrc.py sample
files or just start creating your own layout. Use the Attributes menu item
under the View menu to see the descriptions of the widgets on the current
layout. I've posted a few messages about the resourceEditor and there is a
readme.txt in the directory that is displayed if you select 'About
resourceEditor...' from the 'Help' menu.

Anyway, the other things you are asking for will eventually show up in some
form. Remember that this is a prototype and alpha quality code at that (at
least it is alpha-quality to me). The main purpose of the samples is to
stress the framework and identify the features that need to be added or
fixed.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Ronald
> D Stephens
> Sent: Saturday, August 25, 2001 11:58 AM
> To: pyt...@li...
> Subject: [Pythoncard-users] PythonCard Visual Card Creator
>
>
> Unfortunately, just as I am making progress studying the samples
> code, I am forced to make an unexpected trip overseas again, I will
> be out of commission for a week and a half. So, at the risk of
> being embarassed by my obvious ignorance and naivete, I am going to
> summarize some thoughts I am having.
>
> What I most hope for is for someone to code a sort of visual card
> creator for PythonCard. In other words, a visual card creator
> might show a visual palette or window or card, with a group of
> icons at the top representing the various widgets that Kevin has
> already created for PythonCard. It is not necessary nor even
> desirable to show an infinite number of widgets; rather, only a  small
> but representative sample of the widgets, one of each generic
> kind, sort of a mini sampling of the functionality of PythonCard, to
> allow beginnners or neophytes to begin coding real, usable
> mini-PythonCard gui's right away, from the beginining of their
> experience.
>
> I really believe in the concept of "hooking" potential users
> right up front, allowing them to then evolve or grow into the coding
> environment naturally, by trial and error, a little at a time.
>
> In any intellectual creation task, such as  creating a program,
> the hardest thing of all, by far, is the first step. Most people
> never get started, because the first step is just too daunting
> and scary. But when and if a person completes a first step, no matter
> how small, and gets a psychic reward of success, they are hooked,
> and they may never turn back.
>
> So, a sample card or window, offering a small set of widgets,
> that can be pointed at and clicked on, and then dragged to the
> appropriate spot on the window, offers an inviting introduction
> to PythonCard. After placing the widget, a right click could bring
> up a properties window, or a menu offering the selection of all
> of the various PythonCard program modules, such as resource files,
> resource editors, or the master PythonCard programming environment.
>
> Some of this code to do this may be "borrowable" from elsewhere.
> What about Boa Constructor? With all of the open source programs
> like Boa, to do some sort of visual gui creation, aren't they
> available for code borrowing? Therr is nothing wrong with code
> borrwoing, as I understand it is an honor to have one's code
> stolen??? Of course, let me hasten to add, that what I have in moind
> here must be far simpler than anything Boa offers or does, or
> else it will miss sthe purpose.
>
> Now it would be nice if someone or some group would step up to
> the plate and help out on doing this piece of the programming. Kevin
> can't do it all by himself;-)))))))
>
> While we're at it, what about a visual metaphor for manipulating
> the cards in Pythoncard? Couldn't we create a visual "stack" of
> Pythoncards, sort of like the old Windows 3.1 Cardfile.exe
> program, does anyone remember that, that showed a rolodex type stack of
> cards for storing addresses, phone numbers and other contact
> information? A visual stack of Pythoncards could be manipulated easily
> and effectively.
>
>
> I hope someone will step up to the plate and help Kevn on this.
> I know that what I am so crudely and clumsily trying to describe
> must represent a tremendously difficult and arduous programming
> task, and so I am very presumptuous to even mention the topic. But
> think what a boon to programmers this could be?
>
> I am overwhelmingly impressed and overjoyed with what Kevin and
> you all have already created. I am humbled by my attempts to learn
> by studying the source code for the samples. I believe the
> programming model already being implented will represent a huge step
> forward for Python gui creation.
>
> But a visual metaphor for doing the simplest gui ceation, only,
> the introductory card creation, would be the coup de grace that
> would provide the introductory enticement to lure the multitudes
> of people, making PythonCard unstoppable, make it what some many of
> us have dreamed of. I hope I am not out of line to dream publicly
> on this list.
>
> Ron Stephens
>
> p.s. I must leave for the airport right now, so I apologize for
> the sketchy description of what I have in mind. I will be unable to
> add to it or answer questions for a week and a half. But maybe
> that's good. Those of you so much more knowledgeable and capable than
> I can probably create something much better than what I am
> imagining anyway. Suffice it to say, a visual, easy to use
> mini-introduction to creating pythoncards would be useful, and
> would help, even a this early stage in the development of Pythoncard,
> to attract users and maybe even contributors. It doesn't need to
> be fancy, not powerful, nor in any way complete; just an easy way
> to get started for users in creating the simplest PythonCard
> event driven gui applets, if you will.
>
> ...sorry for not being able to contribute, but admiring and
> grateful to all of those who do contribute, Ron Stephens
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/pythoncard-users
>