Re: more improvements

[Frederic Muller]

Actually found out part of my answers
Total Rur-ple window size at startup (though no fullscreen is possible
yet) is in 2 places:
in rur_start.py
- line 110: size = (800, 660)
- line 171: self.SetSize((900, 660)) <- this line overrides the former
one which is why we see a resizing at rur-ple start-up

world drawing sizes are in world_creation.py
- line 221: tile_info = (34, 6), <- 34 is the wall length and, 6 the
brick thickness

This way it is easy to add a launch parameter or a screen size detection
to automatically resize the tiles. Only Reeborg doesn't get resized but
it's still very much acceptable (he only walks a little bit on the lower
border of the world).

Still looking for the debugger size definition but I might be able to
find it before anyone gets up yet. :D

Fred

Frederic Muller wrote:
> Hi!
>
> I'd like to improve a few things but I'm not sure how to do it:
>
> 1. startup windows positions in "code and learn":
> - even at normal screen resolution the Reeborg's map has a slider on
> the right
> - we could reduce the debug window at the bottom and make Reeborg's
> world fit in full
>
> => I looked at the code and wasn't sure exactly where that was defined
> (will continue to look though)
>
> 2. Help key in "code and learn":
> - it is currently F5
> - it only works if the active window is Reeborg's world
> - it is not translated (not in PO files neither)
>
> => can we change that to F1, or has F5 a reason to be that could be
> linked with Python way of doing things?
> => I actually only found it because I looked at the code... I wonder
> how many people know about it.
> => does it make sense to work in one of the 2 other logical space of
> that window?
> => I'll try to add it into the PO files but the syntax is a bit
> different than elsewhere (I guess a bit of testing will lead me to the
> right solution).
> => I saw more texts in that world_display.py file which looked like
> comments but that I never saw appear in RUR-PLE. I need to investigate
> more about triggering modes and whether they are translatable. Any
> hint is welcome.
>
> 3. Back to the windows sizes of "code and learn" and more specifically
> trying to fit into 600 pixels high
> - where do I find the debugger size? (same question as in no.1)
> - is there a way to run rur-ple in fullscreen vs windowed? hints welcome
>
> => if fullscreen is doable then hiding the debug window (initial idea
> from André) and putting rur-ple in fullscreen will almost work. We can
> add a -fullscreen command line argument to enable this mode. But then
> we probably need a Quit button...
> Another way would be to reduce the dots and walls spacing (all the
> drawing which do not seem to be bitmaps) by maybe 10% and it would
> fit. I'm still looking where to find this.
>
> Well thanks a lot for any indication you could provide as well as
> answers to more specific questions.
>
> Fred
>

[Frederic Muller]

[Frederic Muller]

Discard the last 4-5 emails from me which have all found answers.. thanks.

Fred

[Andy Judkis]

One thing I wanted to mention is that I frequently find that my students accidentally save empty files over existing files, because they click save when they meant to click open.  Perhaps RUR-PLE could give a warning when about to save an empty file?

Thanks,
Andy

[Andre Roberge]

On Tue, Jan 19, 2010 at 10:13 PM, Andy Judkis <aju...@gmail.com> wrote:

One thing I wanted to mention is that I frequently find that my students accidentally save empty files over existing files, because they click save when they meant to click open.  Perhaps RUR-PLE could give a warning when about to save an empty file?

Or, even better?: give a warning when a file is going to be replaced?
André

 

[Frederic Muller]

Great to get users feedback. I've added the feature in the issue list as
an enhancement.

Andre Roberge wrote:
>
>
> On Tue, Jan 19, 2010 at 10:13 PM, Andy Judkis <aju...@gmail.com
> <mailto:aju...@gmail.com>> wrote:
>
> One thing I wanted to mention is that I frequently find that my
> students accidentally save empty files over existing files,
> because they click save when they meant to click open. Perhaps
> RUR-PLE could give a warning when about to save an empty file?
>
> Or, even better?: give a warning when a file is going to be replaced?

> Andr�

[Peter Maas]

Hi,

I've implemented Issue 33 (warning overwriting an existing file).
Before I check in I'd like to discuss a few details. I noticed that
the Program Open dialog starts in the program directory but the
Program Save dialog in the home directory. Is this intentional? I
think it's a bug.

I also noticed that I cannot start rur-ple from an arbitrary
directory. I'd like to fix this as well so that rur_start.py can be
started from a desktop shortcut without being wrapped in a command
file.

Peter.

[Frederic Muller]

Hi!

I've been a bit busy lately and didn't follow up much.

So yes the current open and save behavior was a temporary fix to the
packaged version which couldn't save files in /opt/rurple due to lack of
rights. Since we wrote a little requirement document for the expected
behavior which goes beyond not overwriting files and can be found here:
http://code.google.com/p/rur-ple/wiki/OpenSaveFilesRequirements

2nd issue would also be nice to have I suppose.

Thanks.

Fred

[Peter Maas]

On 30 Jan., 11:14, Frederic Muller <f...@beijinglug.org> wrote:
> Hi!
>
> I've been a bit busy lately and didn't follow up much.
>
> So yes the current open and save behavior was a temporary fix to the
> packaged version which couldn't save files in /opt/rurple due to lack of
> rights. Since we wrote a little requirement document for the expected
> behavior which goes beyond not overwriting files

Hi,

done and committed: overwrite check for rur files and ability to start
rur-ple from arbitrary directories. I noticed a line "code =
parser.FixLineEnding(code)" in SaveProgramFile. It has no effect since
it is executed after the file has been written. Is it obsolete or
should it be moved right before file.write? SaveWorldFile does not
contain such a statement.

Still to do: overwrite check for world files and implement expected
open/save behaviour according to requirement document.

Peter.

[Frederic Muller]

No idea, I'd say it's obsolete then? cool I'd download a try a bit... :)

[Peter Maas]

On 30 Jan., 11:14, Frederic Muller <f...@beijinglug.org> wrote:

> Since we wrote a little requirement document for the expected
> behavior which goes beyond not overwriting files and can be
> found here:
> http://code.google.com/p/rur-ple/wiki/OpenSaveFilesRequirements

Hi,

I've read the document and have a few remarks and questions.

- What does "source version: no change in the behavior" mean?
That the source version behaves differently from the packaged
version? Wouldn't this complicate the detection logic and increase
the number of test cases without providing additional value for
the user?

- From the packaged version description I deduce the following
detection
logic:

linux:
sys.platform == 'linux2'
home = os.expanduser('~')
userdata = home + '/.config/rurple'

windows (32 and 64):
sys.platform == 'win32'
appdata = os.environ['APPDATA']
userdata = appdata + '/rurple'

Mac OSX:
sys.platform == 'darwin'
posix system -> like linux

os.name == 'posix'
posix system -> like linux

others (including old Mac OS):
probably no user directory.
try '/rurple' or tempfile.gettempdir()+'/rurple'
or os.getcwd()+'/rurple' or give up (let the user
choose a directory when he is about to save.)

- To host these features I would like to use a dedicated
module. My plan is to rename misc.py to settings.py
and do all the user logic there.

Comments are welcome.

Regards, Peter.

---------------------------
Peter Maas, Aachen, Germany
---------------------------

[Frederic Muller]

Peter Maas wrote:
> On 30 Jan., 11:14, Frederic Muller <f...@beijinglug.org> wrote:
>
>> Since we wrote a little requirement document for the expected
>> behavior which goes beyond not overwriting files and can be
>> found here:
>> http://code.google.com/p/rur-ple/wiki/OpenSaveFilesRequirements
>>
>
> Hi,
>
> I've read the document and have a few remarks and questions.
>
> - What does "source version: no change in the behavior" mean?
> That the source version behaves differently from the packaged
> version? Wouldn't this complicate the detection logic and increase
> the number of test cases without providing additional value for
> the user?
>

The idea is that when using the source you can still test things that
will not conflict with installed version, then making development and
testing more complicated. So source version can be run from any
directory and open/save files into that tree.

> - From the packaged version description I deduce the following
> detection
> logic:
>
> linux:
> sys.platform == 'linux2'
> home = os.expanduser('~')
> userdata = home + '/.config/rurple'
>
> windows (32 and 64):
> sys.platform == 'win32'
> appdata = os.environ['APPDATA']
> userdata = appdata + '/rurple'
>
> Mac OSX:
> sys.platform == 'darwin'
> posix system -> like linux
>
> os.name == 'posix'
> posix system -> like linux
>
> others (including old Mac OS):
> probably no user directory.
> try '/rurple' or tempfile.gettempdir()+'/rurple'
> or os.getcwd()+'/rurple' or give up (let the user
> choose a directory when he is about to save.)
>
> - To host these features I would like to use a dedicated
> module. My plan is to rename misc.py to settings.py
> and do all the user logic there.
>

Ok then. As you can see I'm back with email access. Holidays start
tomorrow for me and I will be able to resume my contributions to
rur-ple. Is there anything specific you would like me to work on?

[Peter Maas]

On 12 Feb., 07:56, Frederic Muller <f...@beijinglug.org> wrote:
> The idea is that when using the source you can still test things that
> will not conflict with installed version, then making development and
> testing more complicated. So source version can be run from any
> directory and open/save files into that tree.

Hi,

open/save uses the standard places in HOME, APPDATA etc. now. But this
does not restrict working with the source version. I have just checked
in the changes to implement OpenSaveFilesRequirements. Here is an
overview of the changes:

- New user data handling has been implemented as specified in
http://code.google.com/p/rur-ple/wiki/OpenSaveFilesRequirements.
Exception: Sample files are copied to world/samples and programs/
samples to separate them clearly from user stuff. There is not yet any
write protection because I have yet to figure out how to do this
conveniently.

- misc.py is now conf.py and the only place where configuration data
is stored, loaded, read and written. Configuration data are stored in
ConfigParser format (like Windows ini files). This enables us to place
more properties there in a familiar and easily editable format. I
renamed rurple.lang to user.cfg.

- images.py has turned into an image registry providing images via
getimage() so that it can be imported everywhere without having to
care wether wx.app has been loaded. rur_start.py has only one
__main__ section now. This was not strictly necessary for
OpenSaveFilesRequirements but following your and André's discussion
about unit tests I think that the modules have to become more isolated
to make tests feasible.

- Fixes for starting rur-ple from anywhere.

> Ok then. As you can see I'm back with email access. Holidays start
> tomorrow for me and I will be able to resume my contributions to
> rur-ple. Is there anything specific you would like me to work on?

Since my recent check in has quite a few changes I'd appreciate if you
could test the latest version in your environments. I have tested
under Linux and Windows but chances are that I missed something. My
current strategy is to scan the list of issues to find what to do
next. But some kind of plan / roadmap would certainly be nice. Should
I label my recent check in (r104) with OpenSaveFilesRequirements?

I wonder if we should start a coding style guide in the wiki. I'm not
keen on bureaucracy but some guide lines would probably be helpful to
keep the code readable. PEP 8 is a good start. There are some areas
where I found different uses for the same use cases:

- String borders. In current code there is
roughly a 50/50 usage of single and double
apostrohes. Im undecided here.

- Camel case vs. underscores. My favorite is
(deviating from PEP 8) CamelCase for classes
(starting with upper case), camelCase for
members (starting with lower case) and
CAPITALS_WITH_UNDERSCORES for constants. And
wx stuff should follow wx conventions. But
I'm open for other agreements, of course.

I found some seemingly dead ends in the code base like "toy test" and
the python_files directory. Should we delete them?

As the code starting from r104 should be usable for classroom
situations I had the idea of a zero install rur-ple distribution on a
CD or USB stick with a complete rur-ple and python. A teacher could
insert the medium, run rur-ple directly from it and the pupils could
access it via network while having their own local storage locations:
What do you think of it? And of course I'm wondering what André thinks
of how we are mutilating his baby ;)

[Peter Maas]

Hi,

I have just checked in a few fixes:

- PyDeadCodeError on Shutdown
- Replaced robot speed button by a StaticBitMap
- Language change in lessons after pushing back button.
- Start with language of OS locale (issue 34)
- Add new language without modifying translation.py (issue 29)

For the last fix I expanded the languages dict to hold the complete
ISO639-1 list. The languages actually displayed are determined by
conf.getAvailableLanguages. To make adding languages still easier, I
suggest the following format change:

Put *all* language dependent stuff under rur_locale. To add a new
language a translator should provide:

- Directory named according to ISO639-1, e.g. da for Danish.
- Subdirectory lessons (replacing the old lessons/<lang>)
- A po file named program.po

Adding a new language would then mean adding a single directory. A
translator could simply copy the en directory, name it according to
ISO639-1 and start translating.

Looking forward to your comments.

[Peter Maas]

Hi,

is there anybody out there? ;-) I have just checked in:

- make language choice display the chosen language on startup.
- removed "rur_py." from intra-package imports in rur_py
- removed unused imports
- added beeper sound (issue 19)
- Save on Close starts a yesnocancel dialog: yes - save and exit,
no - exit without save, cancel - do not close

Further suggestions:

- Save on Close for worlds
- visible focus or key control of reeborg independent from focus
so that you don't have to click in the world section
- start with a nice situation instead of an empty page.
This would have an impact on lessons, though.

[Frederic Muller]

Wow.. lots of new stuff. I've been in bed for the last week++ with food
poisoning and just getting better. Do you think all those changes since
early 2010 qualify for making a 1.1 after all and getting the changes out?

Fred

[Frederic Muller]

Hi again,

Was testing the new features and it made me realize that we need to
generate a new pot file.

I find the suggestions an improvement and since we need to update quite
a few language files anyway, that would only mean updating 1-2 lessons
in English and their equivalent translations. I think the added value
benefit the burden of contacting the translators (besides we have a
quite active pool now I believe).

Shall we agree to stop modification after those last improvements then?
What time frame are we looking at?

Thanks.

Fred

[Andre Roberge]

Thanks for the numerous improvements. I am currently on holidays with
very limited internet access. I will follow up on my return, in about
ten days.
André

--
Sent from my mobile device

[Peter Maas]

Hi Fred,

hope you are well again.

On 5 Mrz., 06:40, Frederic Muller <f...@beijinglug.org> wrote:
> Shall we agree to stop modification after those last improvements then?

I have gathered the features and fixes from my notes and the list of
changes. Please correct me if the list is incomplete or some entries
belong to 1.01. It contains only entries which are meaningful for the
users. Those with a "+" are not finished yet.

Features:
- rurple icon on windows
- Linux packaging
- Chinese translation (program + lessons)
- Spanish translation (program + lessons)
- Numerous improvements of English, German and Turkish translations
- windows and mac installers
- Screen size detection, adjusted screen values for XP, 640x480 mode
- wxpython 2.8 compatibility
- overwrite checks for programs and world files
- New user data handling as specified in OpenSaveFilesRequirements.
- Display language choice on startup
- Beeper sound
+ Save on close with yesnocancel
+ nice intro program and world on first start
+ complete packaging

Fixes:
- fix speed slider by give a default length
- issue #8
- issue #27
- issue #23 (world refresh button problem)
- issues 29 + 34
- PyDeadCodeError
- language change after pressing back button
- start rur-ple from arbitrary directory
+ robot key control independent from focus

I think this is enough for 1.1.

Some remarks to complete packaging:

Have the Windows and Mac installers been tested? Do they install a
complete Python with standard library and all tools? Rur-ple is
essentially an IDE and should offer all capabilities of a standard
Python installation.

Recently I ran setup.py in the rur-ple directory on my Ubuntu system
and got a rur_py package under /usr/lib/python2.6/dist-packages which
was unusable mainly because it had no main program and no data. I
think we should support this case as it is the plain vanilla python
install.

> What time frame are we looking at?

I think we could release at end of april.

Last question: do we have an idea who is currently using rur-ple as an
educational tool?

[Andy Judkis]

I use RUR-PLE in my classroom for the first week of our Python exposure. . .  for this semester, that will probably come around in the first few weeks of May.

Thanks,
Andy Judkis

[Peter Maas]

On 13 Mrz., 23:15, Andy Judkis <ajud...@gmail.com> wrote:
> I use RUR-PLE in my classroom for the first week of our Python exposure. .
> .  for this semester, that will probably come around in the first few weeks
> of May.

Hi Andy,

sorry for the late reply. So the count is currently one. I plan to
introduce RUR-PLE to the cs teacher at my son's high school after 1.1
is out. So I hope I will double RUR-PLE's adoption very soon ;-) I
have a few questions. How do you use RUR-PLE? Do you follow the
lessons or have you developped your own approach? Is the stuff easy
for your students or challenging? Is RUR-PLE's visual presentation
helpful or Python as language. Looking forward to hearing from you.

[Andy Judkis]

Hi Peter,

I'm really sorry for the huge delay in responding, I very rarely check gmail.  I just happened to check today.  Please don't interpret my slow response as a lack of enthusiasm, I'd be happy to communicate with you about this -- a much better email address for me is aju...@verizon.net, which I check compulsively.

I basically use RUR-PLE for the first week of programming, as a limited and less abstract environment than the IDLE prompt. I think that RUR-PLE is a great way to start them off -- hard enough to be challenging, but limited enough to be non-threatening.  I think of it as "training wheels" for python.  It's neat because even in such a limited environment, kids get all kinds of unexpected behaviors -- they're surprised to find that it's challenging, but it's still within reach.  I think it's perfect as a way to get started.

I use it to introduce loops, branches, and subroutines -- stuff they'd heard about but hadn't seen.  I don't use the instructional text, I prefer to talk them through the ideas, and let them practice.  I do use many of the exercises up to lesson 22 -- although I've packaged them as a much shorter handout.

I haven't really explored the lessons beyond there, I suspect that there are some good ideas but I just haven't looked.

As a side note, I don't use the repeat() construct, to me that does more harm than good, I just teach them "for count in range()" and then later on when we talk about lists I go back and explain what that's really about.

Thanks,

Andy Judkis

To unsubscribe from this group, send email to rur-ple-discuss+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Frederic Muller]

Dear Peter,

I had to move in April and got a bit distracted since. I'm back looking at RUR-PLE as we're having some deployment at the moment and I have a few questions:
I notice your removed all the code related to supporting lower screen resolution:
http://code.google.com/p/rur-ple/source/diff?spec=svn104&r=104&format=side&path=/trunk/rur_start.py

and apparently support for Python 2.6

This is an issue as we're running on old PCs (800x600) here. Was there a specific reason, or was it just done by accident?

I will need the feature back in so your feedback is appreciated.

Thanks.

Fred
ps: i still need to process this email of yours...

[Frederic Muller]

Hi and best wishes for 2011 for everyone on this list.

I've looked again (and opened my eyes this time - the error message I
got helped as well) and found that some of the code had been re-factored
and moved to a different file. import os was missing which is why the
feature was not working. So no big harm, and dirty eyes on my end.

Following a discussion with Julien I was actually thinking to try to add
a drop down to select resolution and store the last know configuration
in our configuration file.

I also need to complete setup.py for Linux packaging and then we should
have a new release. Apparently January and February seem to be the
months I like to work on Rur-ple :)

I hope everyone is well.

Fred