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
46 matches
Mail list logo
