pythoncard-users

[Pythoncard-users] Linux Screenshots

[Jeff G. <jgr...@hb...>]

I just finished up the first round of app testing on Linux.  Here are a
few screenshots I grabbed.
 
http://www.people.hbs.edu/jgriffith/pythoncard/

One issue I ran into was the eval() statement had a hard time with the
resource files.  I think this is due to the windows to unix EOL
differences.  The files were unzipped on windows and ftp'd to Linux.  I
figured that would be enough to keep from running into the problem but I
guess it wasn't.

I'll try to provide more screenshots as I dive deeper into
pythoncard-land.

Later
-Jeff Griffith

RE: [Pythoncard-users] Linux Screenshots

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

> From: Jeff Griffith
>
> I just finished up the first round of app testing on Linux.  Here are a
> few screenshots I grabbed.
>
> http://www.people.hbs.edu/jgriffith/pythoncard/

Wow, they don't look so good on Linux. I seem to remember problems like that
with Neil's original screenshots, but I can't seem to find those now. Either
there aren't many Unix users trying PythonCard right now or they must just
expect that kind of ugliness, because nobody has brought it up as a big
issue. No wonder Unix folks always want to use sizers. It also shows that I
really need to preserve any -1 settings for size (width, height). I'll have
to figure out a clever way of doing that in the resourceEditor.

Your worldclock and widget screenshots show that the turning off the text
border isn't working either. The 'edit' button should be transparent. Are
these just not supported in GTK? If GTK support under wxWindows is really
limited, we are probably going to have to have platform-specific options and
appropriate warnings when those options are used in the .rsrc.py file or
code.

You don't need to do more screenshots, let's try and work through the
framework issues so that the current samples look good on Linux, Solaris,
etc. first. I need to do some sizer experiments, maybe next week after fonts
are resolved.

Anyone else with sizer experience or ideas in this area? I still favor
supporting multiple resource layouts identified by platform and default
language setting that would automatically be chosen when the app is started
so a layout could be tuned to Windows, Mac, Solaris, Linux, etc. but we will
still need sizers and anchors.

My major concern with sizers is that they are going to be conceptually
difficult for people to grasp. Alternatively, if what we really want is
something like HTML tables, then lets just go for that if that will solve
the problem. I don't know how you deal with whitespace in general with
sizers, most layouts I've seen look really amateurish because everything is
packed together. That is sort of at the other end of the spectrum from what
your screenshots show, which is that absolute positioning and sizing doesn't
fail gracefully. Anyway, this is a big and hard subject, so we need a lot of
discussion.

> One issue I ran into was the eval() statement had a hard time with the
> resource files.  I think this is due to the windows to unix EOL
> differences.  The files were unzipped on windows and ftp'd to Linux.  I
> figured that would be enough to keep from running into the problem but I
> guess it wasn't.

Did you do an ascii or binary transfer? Unix folks please speak up so we can
address issues with line endings or anything else that I'm missing because
I'm using Windows 2000. I got Unix out of my system a long time ago and
don't plan on going back, so somebody else is gonna have to help here.

ka

Re: [Pythoncard-users] Linux Screenshots

[Neil H. <ne...@sc...>]

Kevin Altis:
> > From: Jeff Griffith
> >
> > I just finished up the first round of app testing on Linux.  Here are a
> > few screenshots I grabbed.
> >
> > http://www.people.hbs.edu/jgriffith/pythoncard/
>
> Wow, they don't look so good on Linux. I seem to remember problems like
that
> with Neil's original screenshots, but I can't seem to find those now.

   I put them back up - don't know why they got deleted:
http://pythoncard.sourceforge.net/snapminimal.png
http://pythoncard.sourceforge.net/snapproof.png
http://pythoncard.sourceforge.net/snapwidgets.png

> Either
> there aren't many Unix users trying PythonCard right now or they must just
> expect that kind of ugliness, because nobody has brought it up as a big
> issue. No wonder Unix folks always want to use sizers. It also shows that
I
> really need to preserve any -1 settings for size (width, height). I'll
have
> to figure out a clever way of doing that in the resourceEditor.

   The sizes of widgets and fonts and the visual appearance depends on which
GTK+ theme you are using. Therefore Jeff's screenshots look a lot different
to mine (he has chosen a theme similar to Motif and I chose one similar to
Windows) and as various parameters, such as font size, change other elements
need resizing. Explicitly setting fonts in your application is frowned upon
because you should be able to choose this in the GTK+ theme control panel
for global effect. Windows has similar features but they are used less often
and for smaller visual changes - few Windows users know how to change the
dialog font which causes many dialogs to display badly.

> Did you do an ascii or binary transfer? Unix folks please speak up so we
can
> address issues with line endings or anything else that I'm missing because
> I'm using Windows 2000. I got Unix out of my system a long time ago and
> don't plan on going back, so somebody else is gonna have to help here.

   Most Python code copes well with the extra \r characters but the resource
files don't so one thing that can be done is to explicitly replace all
'\r\n' with '\n' before evaling on Linux.

   Neil

RE: [Pythoncard-users] Linux Screenshots

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

> From: Neil Hodgson
>
>    The sizes of widgets and fonts and the visual appearance
> depends on which
> GTK+ theme you are using. Therefore Jeff's screenshots look a lot
> different
> to mine (he has chosen a theme similar to Motif and I chose one similar to
> Windows) and as various parameters, such as font size, change
> other elements
> need resizing. Explicitly setting fonts in your application is
> frowned upon
> because you should be able to choose this in the GTK+ theme control panel
> for global effect. Windows has similar features but they are used
> less often
> and for smaller visual changes - few Windows users know how to change the
> dialog font which causes many dialogs to display badly.

I have tried some of the alternate Windows schemes, but I can't remember now
whether wxWindows actually used different default sizes and fonts correctly
all the time. I'll experiment with that more to see what does and doesn't
work in anticipation of doing positioning and sizing that isn't absolute.

So, in the sizer realm are we going to also need to support relative font
sizes as well, so you say something is 100%, 180% ...? Does this map to
wxPython or do we have to manage it ourselves - it looks like the latter
IIRC?

> > Did you do an ascii or binary transfer? Unix folks please speak up so we
> can
> > address issues with line endings or anything else that I'm
> missing because
> > I'm using Windows 2000. I got Unix out of my system a long time ago and
> > don't plan on going back, so somebody else is gonna have to help here.
>
>    Most Python code copes well with the extra \r characters but
> the resource
> files don't so one thing that can be done is to explicitly replace all
> '\r\n' with '\n' before evaling on Linux.

So doesn't the -a option take care of this when the file is unzipped or was
the problem the ftp transfer? If we use distutils will the conversion be
done automatically? I can start automating the conversion to just newlines
before zipping, but that might cause other problems.

ka