Menu
▾
▴
pythoncard-devel
|
From: Alex T. <al...@tw...> - 2005-08-24 23:47:07
|
I suspect that this email should perhaps be titled "Thoughts on 1.5" (or maybe even "...on 1.1) .... these changes may not be big enough to require, or justify, a change in major version number. So maybe these aren't being ambitious enough .... (this email only lists 3 out of a long list I have waiting to be thought about and/or written up ...) 1. sizer design / geometry management Yes, you can add sizer code - but it's just so un-PythonCard-like. It feels as bad as writing in wxPython :-) In fact, I think I want two kinds of geometry management: a. something very simple. In the resource editor, select an option that says "resizeable components" and it just does it. Very simple assumptions (all textareas expand in both directions, all textfields in X only, everything else is fixed size and just spreads out ....) - BUT it does imply GetBestSize() on each component, so should handle cross-platform issues for that subset of cases where it works at all. Sometimes it will work, many times it won't - but if you're doing some simple utility with a minimal GUI (2 or 3 preferences, a couple of text input fields, a button or two plus one or two scrollable areas for output), this could get it close enough. b. complex. Resource Editor allows definition of "pseudo-components" for sizers and spacers, multi-component selection to insert/remove components to hierarchical sizers - with maybe a treeCtrl view. 2. more types of windows / panels. We can currently only do single panel windows, and notebooks. Would be good to be able to do say sash or splitter windows as well. Hopefully using some generalization so that you can write the panel code without pre-determining which of those types is to be used. This should be extended to include the default single-panel window - so that you can start off writing a simple app, and then when it grows more complicated, other panels can simply be added without changing all the code done so far. 3. full undo/redo in resourceEditor obvious. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.15/80 - Release Date: 23/08/2005 |
|
From: Alex T. <al...@tw...> - 2005-09-03 22:56:16
Attachments:
simpleSizer.py
|
Alex Tweedly wrote:
>
> 1. sizer design / geometry management
>
> Yes, you can add sizer code - but it's just so un-PythonCard-like. It
> feels as bad as writing in wxPython :-)
>
> In fact, I think I want two kinds of geometry management:
> a. something very simple.
> In the resource editor, select an option that says "resizeable
> components" and it just does it.
> Very simple assumptions (all textareas expand in both directions, all
> textfields in X only, everything else is fixed size and just spreads
> out ....) - BUT it does imply GetBestSize() on each component, so
> should handle cross-platform issues for that subset of cases where it
> works at all.
>
> Sometimes it will work, many times it won't - but if you're doing some
> simple utility with a minimal GUI (2 or 3 preferences, a couple of
> text input fields, a button or two plus one or two scrollable areas
> for output), this could get it close enough.
I've written a simple sizer that (I think) does what I was thinking of.
It's pretty simple-minded, but if you have a simple, straightforward
layout, this will "work" most of the time. It's not always great -
layouts can often look stretched, but it achieves the main purpose of
making fields larger as the window size is increased. It should
(untested) manage simple cross-platform issues (buttons should be larger
on Mac, etc.) - though if that means they overlap, well, they just
overlap. You can lay out the design with a bit of slop in Windows and it
should be OK.
To try it out (please do)
1. the file (simpleSizer.py) is attached - put it in PythonCard directory
2. add from PythonCard import simpleSizer
3. in the background's on_initialize(), add a call
simpleSizer.autoSizer(self)
4. remember you may need to make the app resizeable in the resource editor.
I've tried it out on most of the Samples, as well as on findfiles
(findfiles needed tweaking in the resourceEditor - the released version
is not careful about the layout because the sizer code cleaned the
layout up anyway. simpleSizer doesn't do that, so the layout needs to be
correct in the resource file).
Let me know if it works for you, or if it doesn't tell me how it goes
wrong..
Thanks,
--
Alex Tweedly http://www.tweedly.net
|
|
From: <bra...@om...> - 2005-09-28 18:25:15
|
> Alex Tweedly wrote:
> I've written a simple sizer that (I think) does what I was thinking of.
> It's pretty simple-minded, but if you have a simple, straightforward
> layout, this will "work" most of the time. It's not always great -
> layouts can often look stretched, but it achieves the main purpose of
> making fields larger as the window size is increased.
Oh, wow. Wow, wow, wow. This works great with my app. Mr. Tweedly, I bow
and
scrape at your majestic feet.
I just sat down to resume work on my project after weeks away from it, and
recalled that trying out simpleSizer was on my to-do list. Little did I
realize
how amazingly simple it would be to implement, and how effectively it
would
improve my tabbed interface app.
One of the reasons this is so gratifying is that I kept seeing my boss and
a couple of other end users unconsciously trying to resize the main
window even
when it did not have resizeable enabled and they knew full well the
feature was
not implemented.
To implement simpleSizer in my apps main window (and it's child tabs), all
I
needed to do was make the main window resizeable using Resource Editor,
and add
import simpleSizer
simpleSizer.autoSizer(self)
to two different on_initialize methods -- one for the main window, and one
for the parent class of all the tabs. This caused ALL the tabs and child
tabs
to resize their contents beautifully as the window was resized.
I've only tried this on a couple of the more complex child windows, but so
far so good. The only trouble I ran into was a ZeroDivisionError.
Traceback (most recent call last):
File "/OMS/dev/main/OMS/Mycroft/source/client/simpleSizer.py", line 44,
in RecalcSizes
scaleX = 100 * curWidth / minWidth
ZeroDivisionError: integer division or modulo by zero
It turned out that this error went away after I made sure the child window
that generated was resizeable.
You might notice I stuck simpleSizer.py in one of my own packages rather
than
in PythonCard. It works fine that way. When simpleSizer makes it into
PythonCard CVS, I will change my import statements and get rid of the one
from my client package.
All my testing has so far been on Mac OS 10.4.2, wxPython 2.6, and
PythonCard .82, and on Windows XP with wxPython 2.6 and PythonCard .82.
I vote for simpleSizer to go into PythonCard CVS ASAP. It's not going to
break
anything else because nothing else is dependent on it yet. It's a great,
super-easy way to add sizers to PythonCard. It obviously hasn't been
tested
in every scenario, and it's not perfect, but it's far better than no
sizers at all.
It's also very in keeping with the PythonCard spirit of shallow learning
curve.
And putting it out there at will net us a lot more testers. Why wait for
2.0?
Brad Allen
IT Desktop Support
Omnicom Management Services
Dallas, TX
http://www.omsdal.com
|
|
From: Alex T. <al...@tw...> - 2005-09-29 17:07:37
|
#!/usr/bin/python
"""
Simple sizer for PythonCard
"""
import wx
DEBUG = False
DEBUG1 = False
#----------------------------------------------------------------------
class simpleSizer(wx.PySizer):
def __init__(self, minsize, rows=100, cols=100, border=0):
wx.PySizer.__init__(self)
self.minsize = minsize
self.cols = cols
self.rows = rows
self.border = border
#--------------------------------------------------
def Add(self, item, option=0, flag=0, border=0,
pos=None, size=None,
growX = False, growY = False
):
if DEBUG: print "adding", item.name, pos, size, growX, growY
wx.PySizer.Add(self, item, option, flag, border,
userData=(pos, size, growX, growY))
#--------------------------------------------------
def CalcMin( self ):
x,y = self.minsize
return wx.Size(x, y)
#--------------------------------------------------
def RecalcSizes( self ):
# save current dimensions, etc.
curWidth, curHeight = self.GetSize()
px, py = self.GetPosition()
minWidth, minHeight = self.CalcMin()
if DEBUG: print minWidth, minHeight , curWidth, curHeight
if minWidth == 0 or minHeight == 0: return
scaleX = 100 * curWidth / minWidth
scaleY = 100 * curHeight / minHeight
# iterate children and set dimensions...
for item in self.GetChildren():
pos, size, growX, growY = item.GetUserData()
if DEBUG: print "in recalc", pos, size, growX, growY
cx,cy = pos
sx,sy = size
cx = (cx * scaleX + sx*scaleX/2) / 100
cy = (cy * scaleY + sy*scaleY/2) / 100
if growX:
sx = sx * scaleX / 100
if growY:
sy = sy * scaleY / 100
self.SetItemBounds( item, cx-sx/2, cy-sy/2, sx, sy )
#--------------------------------------------------
def SetItemBounds(self, item, x, y, w, h):
# calculate the item's actual size and position within
# its grid cell
ipt = wx.Point(x, y)
isz = wx.Size(w,h)
if DEBUG: print "in itembounds", x,y,w,h
item.SetDimension(ipt, isz)
#--------------------------------------------------
# AGT fill this list
heightGrowableTypes = ["BitmapCanvas", "CodeEditor", "HtmlWindow", \
"Image", "List", "MultiColumnList",
"Notebook", \
"RadioGroup", "StaticBox", "TextArea", \
"Tree"]
widthGrowableTypes = ["BitmapCanvas", "CheckBox", "Choice", \
"CodeEditor", "ComboBox", "HtmlWindow", \
"Image", "List", "MultiColumnList", \
"Notebook", \
"PasswordField", "RadioGroup", "Spinner", \
"StaticBox", "StaticText", "TextArea", \
"TextField", "Tree"]
growableTypes = ["Gauge", "Slider", "StaticLine"]
def autoSizer(aBg):
winX, winY = aBg.size
# make list of all components, make a RowCol sizer to hold them
complist = []
for compName in aBg.components.iterkeys():
comp = aBg.components[compName]
complist.append( comp )
sizer = simpleSizer(aBg.panel.size, 100,100)
# add the components to the grid
for comp in complist:
tx, ty = comp.position
dx, dy = comp.size
# AGT Must be an easier way to get a component's type ??
compType = comp._resource.__dict__['type']
dx1, dy1 = comp.GetBestSize()
if dx1 > dx: dx = dx1
if dy1 > dy:
# hack to deal with the fact that GetBestSize() comes up with too
# large heights for textareas.
if compType <> "TextArea": dy = dy1
# AGT FUTURE should replace with growable attribute in a component's spec
if "HEIGHT_GROWABLE" in comp.userdata or \
compType in heightGrowableTypes or \
(compType in growableTypes and comp.layout == "vertical"):
compGrowableY = True
else: compGrowableY = False
if "WIDTH_GROWABLE" in comp.userdata or \
compType in widthGrowableTypes or \
(compType in growableTypes and comp.layout == "horizontal"):
compGrowableX = True
else: compGrowableX = False
sizer.Add(comp, pos=(tx,ty), size=(dx,dy), growX = compGrowableX, growY = compGrowableY )
if DEBUG1: print "adding ", comp.name, (tx, ty), (dx, dy), compGrowableX, compGrowableY
sizer.SetSizeHints(aBg)
aBg.panel.SetSizer(sizer)
aBg.panel.SetAutoLayout(1)
aBg.panel.Layout()
#--------------------------------------------------
|
|
From: Andy T. <an...@ha...> - 2005-10-12 09:53:47
|
Alex Tweedly wrote: > bra...@om... wrote: > >> >> I've only tried this on a couple of the more complex child windows, >> but so >> far so good. The only trouble I ran into was a ZeroDivisionError. >> >> Traceback (most recent call last): >> File "/OMS/dev/main/OMS/Mycroft/source/client/simpleSizer.py", line >> 44, in RecalcSizes >> scaleX = 100 * curWidth / minWidth >> ZeroDivisionError: integer division or modulo by zero >> >> It turned out that this error went away after I made sure the child >> window >> that generated was resizeable. >> > I haven't been able to get this to happen (I had tested on > non-resizeable windows). The error happens in ReCalcSizes which is only > called when the window is resized; if the window is marked as > "non-resizeable" then I don't really see why it should be in that > section of code at all. Anything unusual about the window/app this > happened in ? (I checked it again on Mac just in case it was platform > dependent - my earlier testing was Win only - but I don't get an error > there either). > > I've put in a safety check - could you please test this (file attached) > >> I vote for simpleSizer to go into PythonCard CVS ASAP. It's not going >> to break >> anything else because nothing else is dependent on it yet. It's a great, >> super-easy way to add sizers to PythonCard. It obviously hasn't been >> tested >> in every scenario, and it's not perfect, but it's far better than no >> sizers at all. >> It's also very in keeping with the PythonCard spirit of shallow >> learning curve. >> And putting it out there at will net us a lot more testers. Why wait >> for 2.0? > > That sounds reasonable to me. > Anyone object ? Or have other thoughts on adding this to CVS ? > > -- > Alex Tweedly http://www.tweedly.net > > I say go for it. I'm giving a presentation at the Australian open source developer's conference [1] in about six weeks and this will help answer the first question I'll get [2]. As Brad says it doesn't impact or break any other part of the framework, and if it's in CVS I'm more likely to test it. Regards, Andy [1] http://www.osdc.com.au/ [2] Which is always "when will you support sizers" -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ |
|
From: Alex T. <al...@tw...> - 2005-10-13 01:23:49
|
Andy Todd wrote: > I say go for it. I'm giving a presentation at the Australian open > source developer's conference [1] in about six weeks and this will > help answer the first question I'll get [2]. > > As Brad says it doesn't impact or break any other part of the > framework, and if it's in CVS I'm more likely to test it. > Done. As I said before, I've tried most of the samples using it - and it pretty well works for most of them that I'd expect it to work for. I'd be grateful to hear of any other experience with it - good or bad. > > [1] http://www.osdc.com.au/ > [2] Which is always "when will you support sizers" I'd still like to support more complex sizers - but every time I think about adding sizers to resourceEditor, it feels like it's straying too far from "easy to use" and "intuitive layout". So if anyone knows of a UI editor that supports sizers and is easy (or relatively) easy to use, please let me know and I'll take a look at it. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.14/130 - Release Date: 12/10/2005 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X