pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Tabv order in dyamic components [Was: Pythoncard-users digest, Vol 1 #938 - 5 msgs]

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

On Apr 4, 2005, at 5:48 AM, Phil Edwards wrote:

> On Sun, 2005-04-03 at 12:04, Alex Tweedly wrote:
>> Is there any way to control the tab order for components created
>> dynamically from the app ?
>>
>
> AFAIK, Alex, it's just down to the order they appear in 
> self.components.
> So if you have:
>
> ['button1', 'button2', 'button3']
>
> and you then do self.components.insert(1, 'button4'), you should end up
> with
>
> ['button1', 'button4', 'button2', 'button3']
>
> then that's your TAB order, reading from left to right.
>

Actually, that won't work. self.components is a WidgetDict object as 
defined in model.py, it is not a simple list, it is a subclass of 
UserDict, so it is basically a glorified dictionary. Furthermore, the 
order of the components on the background is kept in the 'order' key 
and what it should do is have a list of the order the components 
(wxPython controls) were added to the background (wxPython Panel). You 
should never manipulate the order list directly! In order to modify the 
tab order dynamically, you basically have to destroy the controls and 
repopulate the panel which is what the resourceEditor does and it isn't 
particularly pretty, but if you need to do that sort of thing, then 
that's the code to look at. wxPython used to have a bug/feature where 
you could change the tab order simply by hiding and showing the 
controls, but that is long gone.

I don't know why this never came up before, but I bet there is a 
problem if you want to have a component named parent, data, or order, 
so I probably need to test that, then change them to have leading 
underscores or something like that in the future, which also means 
updating the resourceEditor and perhaps some other tools. I'm not sure 
if I'll get to that this week before I leave for the UK or not.

ka

RE: [Pythoncard-users] Python distribution problems

[Schollnick, B. <Ben...@xe...>]

> > Python and Pythoncard/wxPython/insert favourite GUI toolkit here are
> > *never* going to make a huge impact on the Visual Basic=20
> market. IMHO,=20
> > though, that's not a valid reason to stop using them.
>=20
> growing number of VFP/VB users who are unhappy with Microsoft for the=20
> way they've been brushed aside in lieu of the latest Flavor of the=20
> Month. These people are looking to pick up something new to=20
> develop in,=20
> and many of them would prefer not to commit to another=20
> Microsoft tool.=20

Which is sensible....

I have not used or purchased another Microsoft language since they sold
QuickPascal v1.0.  They promised features that did not exist in v1.0 and
I never forgot that lesson.

> Cool tools such as PythonCard help to increase the chance that they=20
> move to Python instead of remaining on the Dark Side.  ;-)

True.

> 	That's why if you're looking to grow your user base,=20
> it's important to=20
> make things as familiar as possible to those folk.=20

Not necessarily.  What we need to supply is something that is overall
better than what they were using.  Yes, it should be a usable and
productive User Interface and Design... =20

But familiar does not necessarily mean better.

Can you give us a few examples? =20

For example, the Windows Registry.  That's familiar to Windows
programmers, but would you suggest that we a need a registry like
component in Python or PythonCard?

I think I can safely say that 90% of Python/PythonCard developers would
say "NO"....

Yes, it's absurd comparison...  But you did not include any examples...
As I mentioned, familiar does not necessarily equal better.  Just
familiar.

> They're leaving=20
> their former comfort zone for something foreign, and the fewer hoops=20
> they have to jump through, the more likely they might stick with your=20
> product, and evangelize it to others.=20

Yes, but it also is a situation where a better product may have a small
learning curve, but is worth the investment.

I think PythonCard needs better documentation, but for 90% of the
situations, the documentation is more than enough....

> So while the things you mention=20
> are not valid reasons for an existing PythonCard developer to *stop*=20
> using the tool, they would be sufficient for a new PythonCard=20
> developer coming from the VB world to never *start*.

The Pythoncard tutorial that I used to evaluate PythonCard was enough to
convince me to use the software.  I would assume that anyone that was
thinking of using it would attempt to use the tutorial and start basing
a decision on that.

I am unclear on what you are suggesting they are basing their decisions
on?  (The quote does not include it)  Presumably on the fact that they
need to instead Python, WxPython, and PythonCard?  Windows programmers
are fully aware of dependencies...  .Net anyone? =20

		- Benjamin

Re: [Pythoncard-users] Python distribution problems

[Ed L. <ed...@le...>]

On Apr 4, 2005, at 8:43 AM, Phil Edwards wrote:

> Python and Pythoncard/wxPython/insert favourite GUI toolkit here are
> *never* going to make a huge impact on the Visual Basic market. IMHO,
> though, that's not a valid reason to stop using them.

	I'm looking at things a bit differently. Coming from the Microsoft 
world (I'm a long-time Visual FoxPro developer), I know that there is a 
growing number of VFP/VB users who are unhappy with Microsoft for the 
way they've been brushed aside in lieu of the latest Flavor of the 
Month. These people are looking to pick up something new to develop in, 
and many of them would prefer not to commit to another Microsoft tool. 
Cool tools such as PythonCard help to increase the chance that they 
move to Python instead of remaining on the Dark Side.  ;-)

	That's why if you're looking to grow your user base, it's important to 
make things as familiar as possible to those folk. They're leaving 
their former comfort zone for something foreign, and the fewer hoops 
they have to jump through, the more likely they might stick with your 
product, and evangelize it to others. So while the things you mention 
are not valid reasons for an existing PythonCard developer to *stop* 
using the tool, they would be sufficient for a new PythonCard developer 
coming from the VB world to never *start*.

      ___/
     /
    __/
   /
  ____/
  Ed Leafe
  http://leafe.com/
  http://dabodev.com/

RE: [Pythoncard-users] time to share your PythonCard gripes and likes

[Schollnick, B. <Ben...@xe...>]

Bruce,

> I would like to see pythoncard more usable for making=20
> education resources and the single biggest difficulty for me=20
> was trying to make a stand alone application from by code=20
> that I could distribute easily to students who are general=20
> psychology students with limited computer skills (not enough=20
> to install and use python in my experience).  Phil Edwards=20
> reportedly has some variety of solution to this as per his posting..

That is not a OpenSource, Python, or PythonCard failing....

If you do not wish your students or "other people" to be forced to
install python and/or WxPython/PythonCard then you need to decide
how to deal with that.

There are two ways that I am aware of to deal with this.  I have used
both with my software and not had any significant problems.

1) McMillian Installer...  Web Site is down, but the software is still
available
	although unsupported on the Windows side per the Author.... =20

2) Py2Exe - Currently supported, not quite as polished as McMillian's
installer
	but is still under development.  The only con is that the
Documentation
	is very sparse.

Both of these packages allow you to bundle up your python software into
a Windows
executable file, with *no* dependencies.....  So your students would not
need
to install any other software.

Combine that with InnoSetup, a free Windows Installer application, and
you can
have your software installed with next to no issues.....

> I think that "Learning Object" can be made easily with=20
> pythoncard but distribution of them in learning object=20
> repositories so other instructors can
> share the wealth is turning out to be a serious problem. =20

I am not quite following you here....

A "Learning Object" is your application???=20

Distributing software can be as difficult as you make it.  Especially on
the
Windows platform, dealing with the registry, etc.

But it seems like you are making this into a larger problem than it is.
Python is extremely portable, even more so with McMillian's Installer or
Py2EXE.

If you wish to try either Installer or Py2EXE feel free to ask if you
need
assistance.

		- Benjamin

Re: [Pythoncard-users] Tabv order in dyamic components [Was: Pythoncard-users digest, Vol 1 #938 - 5 msgs]

[Phil E. <ph...@li...>]

On Sun, 2005-04-03 at 12:04, Alex Tweedly wrote:
> Is there any way to control the tab order for components created 
> dynamically from the app ?
> 

AFAIK, Alex, it's just down to the order they appear in self.components.
So if you have:

['button1', 'button2', 'button3']

and you then do self.components.insert(1, 'button4'), you should end up
with

['button1', 'button4', 'button2', 'button3']

then that's your TAB order, reading from left to right.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] Python distribution problems

[Phil E. <ph...@li...>]

On Mon, 2005-04-04 at 10:00, normanwinn wrote:
> Bruce Landon wrote:
> 
> > I would like to see pythoncard more usable for making education resources
> > and the single biggest difficulty for me was trying to make a stand alone
> > application from by code that I could distribute easily to students who are
> > general psychology students with limited computer skills (not enough to
> > install and use python in my experience).  Phil Edwards reportedly has
> > some variety of solution to this as per his posting..
> > 

Hi Bruce:

I'm not 100% sure what you mean by education resources or "Learning
Object", but it sounds to me like there are more issues here than just
the usability of Python and/or PythonCard. I'd be more than happy to
exchange some e-mails with you off-list about building and distributing
standalone applications if you want. I agree with you that it's a
tedious task, that's what prompted me to start coding a program to make
it easier for me. I'd be interested to hear your opinions on what would
make it easier.

> After an enthusiastic start with PythonCard I am not using it or, for 
> that matter, Python itself. The reasons are similar to those you give. 
> To be fair, this is not a PythonCard problem or even simply a Python 
> problem but a problem of open source software in general. By its nature 
> open source attracts the technically able - notably among the ranks of 
> those that maintain it. It is very difficult to get them to see the need 
> that to you and I is important. You get replies like, "Do A followed by 
> B. If C do D else do E. Then do F, G". This is fine for the pioneers but 
> not for end users.
> 

What else do the end users need? What you've described sounds to me like
exactly the sort of detailed, step by step instructions that are
required for a non-technical PC user.

> This is, IMO, the major existing barrier to the adoption of open source. 
> If Python and PythonCard are really to target the Visual Basic market 
> this problem must be addressed,
> 

Python and Pythoncard/wxPython/insert favourite GUI toolkit here are
*never* going to make a huge impact on the Visual Basic market. IMHO,
though, that's not a valid reason to stop using them. Burt Rutan knows
that he's never going to put NASA or ESA out of business, but he still
went ahead and flew Spaceship 1.

Personally, I still get a buzz from coding stuff using Python on my
Linux machine and watching it work first time when I drop the same code
onto a Windows machine.

-- 

Regards

Phil Edwards
Brighton, UK

RE: [Pythoncard-users] clearing up tab order in resourceEditor

[Schollnick, B. <Ben...@xe...>]

> I'm not particularly thrilled with the idea of making
> a separate dialog specifically for the tab order of
> controls, since it will just be a duplicate of the=20
> functionality already provided.

Then how about adding a DRAG reordering ability to the
current dialog?

It's quite annoying to have to keep clicking "UP", etc....
Actually the most annoying "issue" with the TAB order is that
you need to reference the properties panel, while manipulating=20
it in the options menu....

Why not get rid of the TAB order options from the options menu,
and move those controls to the properties floater?  That makes
more sense from a workflow perspective.

		- Benjamin

[Pythoncard-users] Python distribution problems

[normanwinn <nor...@on...>]

Bruce Landon wrote:

> I would like to see pythoncard more usable for making education resources
> and the single biggest difficulty for me was trying to make a stand alone
> application from by code that I could distribute easily to students who are
> general psychology students with limited computer skills (not enough to
> install and use python in my experience).  Phil Edwards reportedly has
> some variety of solution to this as per his posting..
> 
> I think that "Learning Object" can be made easily with pythoncard but
> distribution of them in learning object repositories so other 
> instructors can
> share the wealth is turning out to be a serious problem.  The only other
> long distance solution is to try to code everything in javascript but that
> is a big step back from what you have done with pythoncard that I will
> press for easy distribution functionality of stand alone programs.

Hello,

I have started another thread with this - though it doesn't belong here.

After an enthusiastic start with PythonCard I am not using it or, for 
that matter, Python itself. The reasons are similar to those you give. 
To be fair, this is not a PythonCard problem or even simply a Python 
problem but a problem of open source software in general. By its nature 
open source attracts the technically able - notably among the ranks of 
those that maintain it. It is very difficult to get them to see the need 
that to you and I is important. You get replies like, "Do A followed by 
B. If C do D else do E. Then do F, G". This is fine for the pioneers but 
not for end users.

This is, IMO, the major existing barrier to the adoption of open source. 
If Python and PythonCard are really to target the Visual Basic market 
this problem must be addressed,

Norman Winn

PS I know this should be on a python list but I can't cope with the mail 
storm one gets from there.




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005

[Pythoncard-users] Time Lapse Photography With PythonCard

[Daryl F. <fly...@sb...>]

A while back I started playing around with time lapse photography.  Using
PythonCard, I was able to pull together several libraries (pyX10 and
VideoCapture) and add a spiffy (by my standards) UI.  You can see the
results at:
http://www.insanitech.com/timelapse/

-Daryl

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Bruce L. <Bru...@do...>]

Kevin,
I would like to see pythoncard more usable for making education resources
and the single biggest difficulty for me was trying to make a stand alone
application from by code that I could distribute easily to students who are
general psychology students with limited computer skills (not enough to
install and use python in my experience).  Phil Edwards reportedly has
some variety of solution to this as per his posting..

I think that "Learning Object" can be made easily with pythoncard but
distribution of them in learning object repositories so other 
instructors can
share the wealth is turning out to be a serious problem.  The only other
long distance solution is to try to code everything in javascript but that
is a big step back from what you have done with pythoncard that I will
press for easy distribution functionality of stand alone programs.

Thanks for all the progress and dedication - truly inspiring
Cheers
Bruce

-- 
Homepage: http://Bruce-Landon.douglas.bc.ca
Landonline: http://landonline.edutools.info
Weblog: http://radio.weblogs.com/0101747/

[Pythoncard-users] Tabv order in dyamic components [Was: Pythoncard-users digest, Vol 1 #938 - 5 msgs]

[Alex T. <al...@tw...>]

Liam Clarke wrote:

>I seriously do recommend a simple cut and paste in the resource file. 
>Saves on keystrokes. :)
>  
>
Is there any way to control the tab order for components created 
dynamically from the app ?

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] RE: Pythoncard-users digest, Vol 1 #938 - 5 msgs

[Liam C. <cy...@gm...>]

I seriously do recommend a simple cut and paste in the resource file. 
Saves on keystrokes. :)


On Apr 3, 2005 9:47 PM, Ade <sk...@bl...> wrote:
> 
> 
> -----Original Message-----
> >Message: 5
> >Date: Fri, 1 Apr 2005 14:21:23 -0800 (PST)
> >From: Kevin Altis <al...@ya...
> >To: pyt...@li...
> >Subject: [Pythoncard-users] clearing up tab order in resourceEditor
> 
> >Since several people have brought this up recently, I
> >just wanted to remind everyone that the tab order is
> >controlled by the order that controls are created on
> >the Background (panel) when the background is created
> >at runtime. This order is shown by the position of the
> >control in the Property Editor in the resourceEditor.
> >Under the Options menu in the resourceEditor, there
> >are menu items to move the components up, down, front,
> >and back. Since this issue comes up periodically, I
> >guess this needs to be made clearer in the
> >resourceEditor or some documentation, and I'm open to
> >suggestions.
> I apologise. I had not used the options to move the component. I have only
> recently changed from 0.80 and used a complex method
> Originally having found it in an old post, you had to bring each component
> to the front in reverse order.
> Having just tried the send backwards / forwards especially using the CTRL
> 1-4 shortcuts, it does the job wonderfully.
> So, sorry again for not updating my way around the interface.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.

[Pythoncard-users] RE: Pythoncard-users digest, Vol 1 #938 - 5 msgs

[Ade <sk...@bl...>]

-----Original Message-----
>Message: 5
>Date: Fri, 1 Apr 2005 14:21:23 -0800 (PST)
>From: Kevin Altis <al...@ya...
>To: pyt...@li...
>Subject: [Pythoncard-users] clearing up tab order in resourceEditor

>Since several people have brought this up recently, I
>just wanted to remind everyone that the tab order is
>controlled by the order that controls are created on
>the Background (panel) when the background is created
>at runtime. This order is shown by the position of the
>control in the Property Editor in the resourceEditor.
>Under the Options menu in the resourceEditor, there
>are menu items to move the components up, down, front,
>and back. Since this issue comes up periodically, I
>guess this needs to be made clearer in the
>resourceEditor or some documentation, and I'm open to
>suggestions.
I apologise. I had not used the options to move the component. I have only
recently changed from 0.80 and used a complex method
Originally having found it in an old post, you had to bring each component
to the front in reverse order.
Having just tried the send backwards / forwards especially using the CTRL
1-4 shortcuts, it does the job wonderfully.
So, sorry again for not updating my way around the interface.

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Alex T. <al...@tw...>]

Kevin Altis wrote:

>Under the Options menu in the resourceEditor, there
>are menu items to move the components up, down, front,
>and back. Since this issue comes up periodically, I
>guess this needs to be made clearer in the
>resourceEditor or some documentation, and I'm open to
>suggestions.
>  
>
Yeah, documentation, yeah ....

Within the Resource Editor itself, I have a few suggestions (one small, 
one medium, two larger).

1.(small)  The menu items have shortcuts (ctrl+1, ctrl+2, etc.) but 
those only work when the main window has focus. I always want to 
re-order the components by clicking on the name in the component list 
box, and then using one of those shortcut - and nothing happens - need 
to click on the main window to give it focus first. (Or, of course, 
click on the actual component in the main window rather than its name - 
but sometimes that's less convenient - e.g. if you have a number of 
invisible components).

2. (medium) It might be good to have buttons within the property window 
for moving the currently selected component (i.e. visible reminders that 
the order is easily changeable - but functionally a duplicate of making 
the shortcuts operate in that window).

3. (larger) It may just be my style - but I have a lot of "Static Text" 
components, which are not focusable, and so don't need to be considered 
in the tab order. It would be handy for me if there was a quick way to 
move them all to the end of the order list, so I could focus on the ones 
I care about.   

4. (larger) The whole mechanism of defining tab order by selecting 
components and moving them back / forward in the order list seems like a 
poor UI (I know it's common and traditional, but it just seems a bit 
weak).  I find this works OK for "fine-tuning" - if I add a new field 
and want to get it in the right place, or if I change my mind about when 
one or two fields should come in the order - but it breaks down when I 
want to change the order completely (usually when I've been building / 
adding / moving components for a while, and finally got to the point of 
thinking about tab order.

I think there might be a couple of other methods which would handle 
these re-organizations better, leaving the "move back / forwards" for 
fine tuning only.

4a. Sort all (focusable ?) components into "reading order" (i.e. 
left-to-right, top-to-bottom) based on either top-left corner or centre 
position.
4b Same thing, but in column reading order (i.e. top--to-bottom, 
left-to-right).

4c. Point-and-click mode.  You use some menu item to enter "tab order 
definition", and then each click on a component (or selection of its 
name in the component list box) adds it to the end of the tab order; 
continue until you're done (either all components have been selected in 
turn, or when you explicitly exit the mode).


I think I'll have a go at 1, 2 and maybe 4a or 4c and see how using them 
feels.

-- 
Alex Tweedly       http://www.tweedly.net




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] Re: Time to share your PythonCard gripes

[Liam C. <cy...@gm...>]

> Tab order, having an actual z-Order property number would solve this nicely.


Just checking, you know that the order in the Resource file determines
the tab order?

i.e. 

{'application':{'type':'Application',
          'name':'Template',
    'backgrounds': [
    {'type':'Background',
          'name':'bgTemplate',
          'title':'Client details',
          'position':(-5, 25),
          'size':(1027, 689),
          'icon':'lux.ico',

        'menubar': {'type':'MenuBar',
         'menus': [
             {'type':'Menu',
             'name':'menuFile',
             'label':'&File',
             'items': [
                  {'type':'MenuItem',
                   'name':'menuFileExit',
                   'label':'E&xit',
                   'command':'exit',
                  },
              ]
             },
         ]
     },
         'components': [

{'type':'Button', 
    'name':'closeButton', 
    'position':(870, 590), 
    'size':(100, -1), 
    'label':'Close', 
    },

{'type':'Button', 
    'name':'saveButton', 
    'position':(740, 590), 
    'size':(100, -1), 
    'label':'Save', 
    },

{'type':'Button', 
    'name':'jobsButton', 
    'position':(530, 310), 
    'label:'Jobs'
    'size':(100, -1), 
    'label':'Save', 
    }, 


closeButton tabs to saveButton which tabs to jobsButton.

I don't know if this is documented anywhere obvious though.

Regards, 


Liam Clarke

-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic  human duty, to take the consequences.'

[Pythoncard-users] clearing up tab order in resourceEditor

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

Since several people have brought this up recently, I
just wanted to remind everyone that the tab order is
controlled by the order that controls are created on
the Background (panel) when the background is created
at runtime. This order is shown by the position of the
control in the Property Editor in the resourceEditor.
Under the Options menu in the resourceEditor, there
are menu items to move the components up, down, front,
and back. Since this issue comes up periodically, I
guess this needs to be made clearer in the
resourceEditor or some documentation, and I'm open to
suggestions.

I'm not particularly thrilled with the idea of making
a separate dialog specifically for the tab order of
controls, since it will just be a duplicate of the
functionality already provided.

I thought that wxPython might have added a separate
tab order mechanism in addition to the Navigate
methods added to the  wxWindow class, but some quick
searches didn't turn up anything, so I'm probably
imagining things.

If for some reason, the component order displayed in
the Property Editor is not accurately reflecting the
tab order, then that's a bug and needs to be fixed, so
let me know of a specific example, if that is the
case.

Thanks,

ka


		
__________________________________ 
Yahoo! Messenger 
Show us what our next emoticon should look like. Join the fun. 
http://www.advision.webevents.yahoo.com/emoticontest

[Pythoncard-users] Re: Time to share your PythonCard gripes

[Ade <sk...@bl...>]

Finding PythonCard was a blessing, it allowed me, when I was starting out
with Python, quick simple access to the most used settings/setup for a lot
of components used in wxPython. It seems to me very, very stable, flexible
and quick.

The interface.

It is good, as it is... very good. It has served well in my learning of
python without needing to expand much beyond it.

Annoyances.
Not being able to select more than one component.
Tab order, having an actual z-Order property number would solve this nicely.

What would be nice.
Double clicking on a component, it would be nice for it to put focus back to
the properties window and have that component selected. Or better yet have a
set up function to have double click do one of a number of quickly wanted
functions. Alternatively, having the whole properties 'thing' appear on a
right click menu?
For my part I have had to start dealing with wxPython to get some of the
components to perform differently, like removing the automatic linefeed at
the end of the text area ( now taken care of in 0.81 of cause ) or the
length of the list from a combo box or having two line button names. It
would be so, so nice to have most of the settings for most of the components
available in the script so they can be 'easily' and transparently modified
within the PythonCard script rather than in the murky depths of wxPython. As
a last resort I ended up modifying the standard component in PythonCard. I
first tried to add the modified component to the components menu but failed
:(. As an alternative a User components menu item where non-standard
components can be added with ease would be a compromise, however this still
requires the wxPython know-how. Might even generate contributions of
reworked components? This sounds like a lot of work though.

However as I said, I have happily used PythonCard for over 2 years.

[Pythoncard-users] workaround for raising child windows in resourceEditor

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

I've come up with a potential solution to raising
child windows when the main window is selected in the
resourceEditor. This is actually a problem for any
PythonCard application with child windows, but seems
to be more of annoyance in the resourceEditor as the
Property Editor window is always being lost behind
other application windows.

You can just drop the following code into
resourceEditor.py and see whether this gives the
behavior you would expect. I would like to get some
feedback before I check it into cvs. If you have
overlapping windows, most likely because you're
working on a small screen, this solution of forcing a
Raise could be very annoying, so I would likely add a
menu item under Options that would allow you to
disable the Raise.

    def on_activate(self, event):
        if not hasattr(self, 'inActivate') or not
self.inActivate:
            self.inActivate = True
            for c in self.GetChildren():
                c.Raise()
            self.Raise()
            self.inActivate = False
        #event.skip()

On a related note, I never added lowercase aliases for
Raise and Lower to the Background class because I
wasn't sure if this would be legal since raise is a
keyword and we need it for raising exceptions. If
someone knows the correct syntax so that we can have a
lowercase alias to Raise I'll add it to the class;
perhaps I could just do a setattr or something?!

raise = wx.Frame.Raise

ka


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

[Pythoncard-users] Delete and Duplicate shortcut changes

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

I changed the shortcut for Delete in the
resourceEditor to Ctrl+D (Command+D on the Mac) and
added a Ctrl+U (Command+U on the Mac) shortcut for
Duplicate. This should avoid any confusion with the
Backspace and Del keys.

ka


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Bo G. <bo...@sy...>]

Phil Edwards wrote:

>2. there's a problem with radiogroup components not displaying properly
>in either the resource editor or the running application
>
>  
>

Speaking of radio groups, any time I have a radio group present, the 
resource editor behaviour for left-right arrow keys is to change the 
default radio group value. It would be less noticable if it only 
happened when the radio group is selected, but that's the behaviour when 
any component is selected, effectively making the left-right arrow keys 
useless in the resource editor whenever there's a radio group present. I 
like to use the arrow keys to move components around in small 
increments, so I find it fairly annoying.

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[<bra...@om...>]

SSBzZWUgeW91ciBwb2ludC4gTWF5YmUgdGhlIGRlbGV0ZSB3aWRnZXQgc2hvcnRjdXQgc2hvdWxk
IGJlIA0KY29tbWFuZC1CYWNrc3BhY2UgKGFuZCBjb21tYW5kLURlbGV0ZSkuIA0KDQoNCnB5dGhv
bmNhcmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IHdyb3RlIG9uIDAzLzMxLzIw
MDUgMDg6NDQ6MTMgDQpQTToNCg0KPiBOaSENCj4gDQo+IEFsdGhvdWdoIEkgZG9u4oCZdCBsaWtl
IHRvIGdyaXBlIGFib3V0IHNtYWxsIHN0dWZmLCB0aGlzIGhhcyBhY3R1YWxseSANCj4gYmVlbiBh
IGNvbnNpc3RlbnQgYWNjaWRlbnQgZm9yIG1lIOKAkyANCj4gSSBoYXZlIHNlbGVjdGVkIGEgY29t
cG9uZW50IChzbyB0aGUgbGl0dGxlIHNxdWFyZXMgYXJlIGFyb3VuZCB0aGUgDQpjb3JuZXJzKS4N
Cj4gSSBnbyB0byBlZGl0IGl0cyBwcm9wZXJ0aWVzIGFuZCBJIGhpdCBkZWxldGUgd2hpbGUgaW4g
YSB0ZXh0IGZpZWxkLg0KPiBJdCBhc2tzIG1lIGlmIEkgd291bGQgbGlrZSB0byBkZWxldGUgdGhl
IGNvbXBvbmVudA0KPiBOb3RlIHRoYXQgaXQgb25seSBoYXBwZW5zIHdoZW4gYSBzcGVjaWZpYyBj
b21wb25lbnQgaXMgc2VsZWN0ZWQuIElmIA0KPiBubyBjb21wb25lbnRzIGFyZSBzZWxlY3RlZCDi
gJhkZWxldGXigJkgd29ya3MgYXMgZXhwZWN0ZWQgaW5zaWRlIHRleHQgDQpmaWVsZHMuIA0KPiAN
Cj4gW21pZ2h0IHRoaXMgYmUgbWFjIHNwZWNpZmljIG9yIGEgZ2VuZXJhbCBidWc/IGFsc28gd29y
a2luZyBvbiBhIG1hY10NCj4gTG92ZSB0aGlzIHByb2dyYW0sIGRldmVsb3BpbmcgYSBwcmV0dHkg
YmlnIGFwcCByaWdodCBub3cgaW4gbm8gdGltZSANCj4gZmxhdC4gVGhlIHJlc291cmNlIGVkaXRv
ciBpcyBncmVhdC4gDQo+IA0KPiBUYWtlIENhcmUsDQo+IEJFUk5pRQ0KPiANCj4gDQo+IA0KPiBJ
IHJlY2VpdmVkIGEgbWVzc2FnZSBmcm9tIGJyYWQuYWxsZW5Ab21zZGFsLmNvbSBhdCBhcHByb3hp
bWF0ZWx5IA0KPiAzLzMxLzA1IDg6MTcgUE0uIEFib3ZlIGlzIG15IHJlcGx5Lg0KDQo+IA0KPiBC
cmFkIEFsbGVuIHdyb3RlIA0KPiAgPiAgICAgICAqIEFiaWxpdHkgdG8gZGVsZXRlIHdpZGdldCBi
eSBwcmVzc2luZyBkZWxldGUga2V5IA0KPiA+ICAgICAgICAgICAgICAobWluZSBkb2Vzbid0IHdv
cmsgdW5kZXIgTWFjIG9yIFdpblhQKSANCj4gDQo+IEknZCBsaWtlIHRvIGFtZW5kIHRoaXM6IHRo
ZSBkZWxldGUga2V5IGFjdHVhbGx5IGRvZXMgd29yayBpbiByZXNvdXJjZSANCmVkaXRvcjsNCj4g
d2hhdCBJIHNob3VsZCBoYXZlIHNhaWQgd2FzIHRoZSBiYWNrc3BhY2Uga2V5LiBBcyBhIE1hYyBn
dXksIEknbSANCj4gbm90IHVzZWQgdG8gdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIGJhY2tz
cGFjZSBrZXkgYW5kIHRoZSBkZWxldGUgDQprZXkuIA0KPiANCj4gVGhlIGJhY2tzcGFjZSBrZXkg
aGFzIG5vIG90aGVyIGZ1bmN0aW9uIGluIHJlc291cmNlIGVkaXRvciwgcmlnaHQ/IA0KPiBJIHZv
dGUgdG8gbGV0IGl0IGRvIHRoZSBzYW1lIHRoaW5nIGFzIHRoZSBkZWxldGUga2V5Lg0KPiANCg0K

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Bernie H. <ber...@ut...>]

Ni!

Although I don=B9t like to gripe about small stuff, this has actually been a
consistent accident for me =AD
I have selected a component (so the little squares are around the corners).
I go to edit its properties and I hit delete while in a text field.
It asks me if I would like to delete the component
Note that it only happens when a specific component is selected. If no
components are selected =8Cdelete=B9 works as expected inside text fields.

[might this be mac specific or a general bug? also working on a mac]
Love this program, developing a pretty big app right now in no time flat.
The resource editor is great.

Take Care,
BERNiE



I received a message from bra...@om... at approximately 3/31/05
8:17 PM. Above is my reply.

>=20
> Brad Allen wrote=20
>>  >       * Ability to delete widget by pressing delete key
>>  >              (mine doesn't work under Mac or WinXP)
>=20
> I'd like to amend this: the delete key actually does work in resource edi=
tor;
> what I should have said was the backspace key. As a Mac guy, I'm
> not used to the distinction between the backspace key and the delete key.
>=20
> The backspace key has no other function in resource editor, right?
> I vote to let it do the same thing as the delete key.

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[<bra...@om...>]

Brad Allen wrote
 >       * Ability to delete widget by pressing delete key 
 >              (mine doesn't work under Mac or WinXP) 

I'd like to amend this: the delete key actually does work in resource 
editor;
what I should have said was the backspace key. As a Mac guy, I'm
not used to the distinction between the backspace key and the delete key.

The backspace key has no other function in resource editor, right?
I vote to let it do the same thing as the delete key.

[Pythoncard-users] Standalone applications

[Phil E. <ph...@li...>]

I did some work almost 12 months ago on documenting the process of
converting a finished PythonCard application to a standalone Windows
binary that could be easily distributed to others. See this page for
details:

http://pythoncard.sourceforge.net/standalone.html

One of the things that came out of this at the time was a need that I
perceived for some sort of project manager application to try to
automate as much of the task as possible. Several people threw some
ideas (and even large chunks of code and finished programs) my way and I
went away to think about it.

Much time has passed....I have finally got round to making some
progress. I think the adjective I'm looking for is 'glacial'... :-)

The program isn't fully finished as yet, but the vast majority of it
works as required. New and existing projects can be opened and edited,
the majority of the build process works with a single mouse click and
ancillary options like a preferences dialog and so forth have been
coded. I've put some screenshots up showing what I've done so far at the
following URL:

http://www.linux2000.com/pm.html

The aim is to get this fully functional ASAP and (if Kevin feels it's a
useful app) contribute the code to the PythonCard project for the
future.

At this stage, any comments/criticism on the user interface would be
gratefully received, either here on the list or privately via e-mail.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Phil E. <ph...@li...>]

On Tue, 2005-03-29 at 23:56, bra...@om... wrote:

> Another thing I like is that PythonCard wraps a lot of wxPython stuff
> that I'm not ready to take on yet, but still allows me to use wxPython
> in small
> ways when I need to. In that respect, I think of PythonCard as
> wxTrainingWheels.

This, in my humble opinion, sums up nicely the greatest strength of
PythonCard in its current form.

> For the 1.0 release, I vote for sticking closely to the .81 release
> but fixing some
> of the Resource Editor glitches. It would be nice to have new features
> but stability

Likewise. The only things which really spring to mind in the current
release are:

1. nailing the window geometry differences between Windows, Linux and
MacOS

2. there's a problem with radiogroup components not displaying properly
in either the resource editor or the running application

3. list components can't be selected in the resource editor

4. button dragging doesn't work in the resource editor

My usual working environment is such that I tend to code/test on both
Linux and Windows at the same time, so 1, 3 and 4 don't bother me too
much - anything which I can't do on Linux I do under Windows instead.
Item 2 could do with being fixed though. Could someone else using Linux
try a radiogroup component in the resource editor and see what happens
with both horizontal and vertical orientation?

-- 

Regards

Phil Edwards
Brighton, UK