Greg Ewing wrote:
> Bill Janssen wrote:
>> An editable styled-text widget would be interesting, instead of the
>> simpler editable text widget that already exists.
>
> Yes, that's another thing I have in mind. I need to find out
> what's available on Windows before I get too carried away with
> th
> "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
> What needs to be decided for Py3K is whether to DROP support for
> TK. I am actually mildly in favor of dropping TK support in the
> core if we can make it easy enough to download and install
> separately.
You can't
Oleg Broytmann wrote:
>I am one of those mouse-haters, and I use keyboard as much as possible.
> All platforms allow me to do it with keyboard shortcuts, default buttons
> and tabs over all widgets.
It's reasonable to have some way of controlling
everything with the keyboard, although it seem
Le mercredi 03 mai 2006 à 07:46 +0200, Fredrik Lundh a écrit :
> Antoine Pitrou wrote:
>
> > Including a simplistic GUI library in the stdlib is really *not* helpful
> > to developers, it can even be deceptive.
>
> what makes discussions like these impossible is that everyone is assuming
> that t
Antoine Pitrou wrote:
> Including a simplistic GUI library in the stdlib is really *not* helpful
> to developers, it can even be deceptive.
what makes discussions like these impossible is that everyone is assuming
that their own requirements apply to everyone.
I strongly doubt that the "oh my go
Le mardi 02 mai 2006 à 18:14 -0400, Jim Jewett a écrit :
> They can, by installing wxPython. How long would it take to
> understand wxpython? My gut feel is "longer than it took to
> understand Python", which makes it pretty heavyweight.
Understanding wxPython in itself is not difficult (a tool
On 5/2/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Anyone who is pushing for any GUI toolkit to make it into Py3k ...
> Wandering through all of the widgets ... fully featured GUI toolkit really is.
> ... not everything needs be implemented to the extent it is in wxWidgets or
> wxPython, but
"Stefan Rank" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> There is absolutely no sensible reason at all, for a gui frame to be of
> a fixed size!
> None.
> More precisely: the concept of a maximum size (except screen limits) for
> a frame is asking for user dissatisfaction.
> 'U
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> PyGUI *should* automatically handle tabbing between text fields
> and other controls that you normally type text into. It doesn't
> currently go in for tabbing into buttons and check boxes, which
> has always seemed silly and annoying to me. I mig
Many of these issues have already been discussed -- and solved -- in a
web context, if you look at the w3c.org accessibility documents.
On 5/1/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > You cannot assign a global key shortcut to every command,
> > while you can assign a local hotkey to any m
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > Technically speaking, any toolkit which allows for scrolling and the
> > laying out of controls in a grid would be sufficient to implement this
>
> Although for large grids it could be prohibitively
> inefficient. You really wan
On Wed, May 03, 2006 at 12:33:42AM +1200, Greg Ewing wrote:
> PyGUI *should* automatically handle tabbing between text fields
> and other controls that you normally type text into. It doesn't
> currently go in for tabbing into buttons and check boxes, which
> has always seemed silly and annoying to
Bill> I think a PyGUI mailing list would be a good thing, Skip. And a
Bill> bug-tracker. And a CVS repository.
Bill> I disagree, though, about this discussion being too detailed for
Bill> this list. This is exactly the kind of discussion we need on this
Bill> list -- what a
Fredrik Lundh wrote:
> I don't think PyGUI is good enough for a standard API; it feels way too
> much "MFC era" for my tastes.
Can you elaborate on what MFC-like characterstics
it has that you don't like? I'm open to suggestions
for improvement.
--
Greg
__
Greg Ewing wrote:
>>> I can see the accessibility
>>> argument, but it is basically asking for the ability to drive an
>>> interface designed for use with a pointing device, without using a
>>> pointing device. I'm not sure this is a reasonable constraint.
>>
>> It is. Every GUI toolkit has this,
Bill Janssen wrote:
> > In wxWidgets, the GUI system is able to calculate the minimal size
> > needed by each and any widget, and to prevent the user from resizing the
> > window below the calculated minimal size. =
>
> I'm not sure that this is effectively possible in all cases, but the
> "set_b
on 02.05.2006 11:04 Giovanni Bajo said the following:
> Bill Janssen <[EMAIL PROTECTED]> wrote:
>>> In wxWidgets, the GUI system is able to calculate the minimal size
>>> needed by each and any widget, and to prevent the user from resizing
>>> the window below the calculated minimal size. =
>> I'm
Bill Janssen wrote:
> The Tk canvas widget is a nice one,
I've never been fond of things like the Tkinter canvas that
come with their own data structure. Usually I already have
a data structure of my own, and all I want is a place to
draw it.
> I'm still not quite sure what the PyGUI "canvas" is
Josiah Carlson wrote:
> Technically speaking, any toolkit which allows for scrolling and the
> laying out of controls in a grid would be sufficient to implement this
Although for large grids it could be prohibitively
inefficient. You really want to implement this kind
of thing in a way that doesn
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
>
> > This is, of course, hard, as platforms offer widely differing widget
> > sets. Tough. Nobody said writing a portable GUI layer was going to be
> > easy.
>
> Indeed. I'd say this kind of issue has been the *most*
> difficult
Giovanni Bajo wrote:
> > I can see the accessibility
> > argument, but it is basically asking for the ability to drive an
> > interface designed for use with a pointing device, without using a
> > pointing device. I'm not sure this is a reasonable constraint.
>
> It is. Every GUI toolkit has thi
Paul Moore wrote:
> This is, of course, hard, as platforms offer widely differing widget
> sets. Tough. Nobody said writing a portable GUI layer was going to be
> easy.
Indeed. I'd say this kind of issue has been the *most*
difficult thing about designing and implementing PyGUI
so far. One has to
Bill Janssen <[EMAIL PROTECTED]> wrote:
>> A control which displays and allows to interact with several lines of
>> widgets (e.g. labels, images...).
>> For example a buddy list in an Instant Messaging client.
>
> This seems like part of the application UI to me, not a toolkit issue.
No. The tool
On 5/2/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> A widget toolkit which pre-implements parts of particular applications
> does make it easier to implement those applications, I agree. The
> question in my mind is whether an application can be built even if
> that particular widget is missing.
Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > This seems like part of the application UI to me, not a toolkit issue.
> >
> > Um...no. Most client-side email applications allow you to view email in
> > a particular folder as a 'threaded' and 'non-threaded' view. The
> > 'non-threaded' view would
Skip writes:
> This discussion is interesting, but runs the risk of getting a bit too
> detailed for this list. Maybe the gui-sig should be reactivated (with a
> stated goal of converging on a more Pythonic GUI for Py3k) or a pygui
> mailing list hosted on mail.python.org.
I think a PyGUI mailing
> > This seems like part of the application UI to me, not a toolkit issue.
>
> Um...no. Most client-side email applications allow you to view email in
> a particular folder as a 'threaded' and 'non-threaded' view. The
> 'non-threaded' view would be a list control, if I understand Antoine
> corre
Bill Janssen <[EMAIL PROTECTED]> wrote:
> Antoine, thanks for the explanations.
>
> > A control which displays and allows to interact with several lines of
> > widgets (e.g. labels, images...).
> > For example a buddy list in an Instant Messaging client.
>
> This seems like part of the applicati
Antoine, thanks for the explanations.
> A control which displays and allows to interact with several lines of
> widgets (e.g. labels, images...).
> For example a buddy list in an Instant Messaging client.
This seems like part of the application UI to me, not a toolkit issue.
> You cannot assign
Aahz writes:
> I use Windows, OS X, and Linux. In all cases, I
> strive to maximize my use of the keyboard and minimize my use of pointing
> devices.
Me too.
> I think it is entirely reasonable to expect that a GUI toolkit
> will at least make it straightforward to implement keyboard-based
> com
> since this is the Py3K list, why hurry ?
Because Guido seems to be hurrying. All those pitchforks outside his
office, I suppose.
> (for the record, I'd prefer a conceptual mix of HTML, PyGUI, WinForms,
> and WCK, plus Tkinter's binding model and Canvas. more about this some
> other day.)
Ple
On Mon, May 01, 2006, Bill Janssen wrote:
>Antoine:
>>
>> You cannot assign a
>> global key shortcut to every command, while you can assign a local
>> hotkey to any menu item.
>
> This seems like creeping featurism to me. I can see the accessibility
> argument, but it is basically asking for the
Antoine> As far as I've seen by trying the demos and taking a quick
Antoine> glance at the source, PyGUI also lacks (from the top of my
Antoine> head):
...
Antoine> If making PyGUI into the stdlib is important, a wiki or
Antoine> something could be opened to list the variou
Le lundi 01 mai 2006 à 11:44 -0700, Bill Janssen a écrit :
> > - list controls
>
> Not sure what you mean here.
A control which displays and allows to interact with several lines of
widgets (e.g. labels, images...).
For example a buddy list in an Instant Messaging client.
> > - menu hotkeys (e.g
>Does it support printing? wxPython/wxWidgets support cross-platform
> low-level (pixel by pixel) printing, preview with zoom...
It's currently got the low-level idea of an offscreen Pixmap into
which the app can draw by calling "with_canvas". The Pixmap captures
an image of the drawing, and
Antoine, thanks for looking more closely at this.
> PyGUI also lacks (from the top of my head):
> - list and combo boxes
Yes, in my message yesterday I noted that. I think only
drop-down/pop-up menu support is really necessary for this, and
there's already a menu class that could be mildly alter
> If making PyGUI into the stdlib is important, a wiki or something could
> be opened to list the various issues people have with PyGUI.
Great idea.
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-
On Mon, May 01, 2006 at 07:30:52PM +0200, Antoine Pitrou wrote:
> As far as I've seen by trying the demos and taking a quick glance at the
> source, PyGUI also lacks (from the top of my head):
> - list and combo boxes
> - list controls
> - icons in menus
> - menu hotkeys (e.g. Alt+F to open File me
Le lundi 01 mai 2006 à 09:59 -0700, Bill Janssen a écrit :
> Interesting. I never seem to use tree-views, but I do use graph
> views. I think the standard Python GUI should make it easy to build
> these kinds of things. Right now a graph view is fairly easy to build
> on top of a raw View.
As f
Bill Janssen wrote:
> > But PyGUI is not complete. (Greg is one of the people who says this.) And
> > I belive that it is just not ready to be the "blessed" Python GUI framework.
>
> I'm suggesting a concerted effort to *make* it complete over the rest
> of this year. Or, if that's for some reaso
> But PyGUI is not complete. (Greg is one of the people who says this.) And
> I belive that it is just not ready to be the "blessed" Python GUI framework.
I'm suggesting a concerted effort to *make* it complete over the rest
of this year. Or, if that's for some reason not possible, to pick
some o
> [Bill Janssen proposes we use Greg Ewing's PyGUI as the standard GUI
> framework in Py3K.]
I really like PyGUI. I have dabbled in a number of different GUI frameworks
over the years, and PyGUI is the only one where upon reading the
documentation I immediately thought "that's Pythonic!". (It's us
> So you're really aiming at incorporating a gui-api for Python, so that it can
> be pointed at the backend of choice? Something similar to what the DB-api
> achieves for databases?
Yes, that's essentially what PyGUI already is. It doesn't attempt to
model directly any specific existing toolkit
Bill Janssen wrote:
> 1) I'd add some kind of standard analog value control class,
You're in luck - I've just almost-finished adding a Slider control.
> 2) There needs to be some kind of combobox multiple-value choice
> widget
Yes, there are several more controls like this that I would
li
On 4/30/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I've looked over the PyGUI code a bit more carefully.
>
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for Iro
Bill Janssen wrote:
> I've looked over the PyGUI code a bit more carefully.
>
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for IronPython on .NET and
> Mono). M
I've looked over the PyGUI code a bit more carefully.
It still looks good to me as a Py3K standard portable GUI candidate.
In particular, it doesn't look like it would be hard to port to Java
Swing (for Jython) and Windows.Forms (for IronPython on .NET and
Mono). Might make good summer projects..
47 matches
Mail list logo
