Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53994 > unrolled thread

Python GUI?

Back to article view | Back to comp.lang.python

Contents

  Python GUI? eamonnrea@gmail.com - 2013-09-11 13:55 -0700
    Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-11 23:05 -0600
      Re: Python GUI? eamonnrea@gmail.com - 2013-09-12 09:03 -0700
        Re: Python GUI? Robert Kern <robert.kern@gmail.com> - 2013-09-12 17:23 +0100
          Re: Python GUI? Dave Cook <davecook@nowhere.net> - 2013-09-12 18:50 +0000
            Re: Python GUI? Dave Cook <davecook@nowhere.net> - 2013-09-12 21:36 +0000
        Re: Python GUI? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-12 09:51 -0700
          Re: Python GUI? rusi <rustompmody@gmail.com> - 2013-09-17 07:55 -0700
            Re: Python GUI? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-17 09:19 -0700
              Re: Python GUI? rusi <rustompmody@gmail.com> - 2013-09-17 09:51 -0700
                Re: Python GUI? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-17 10:57 -0700
            Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-18 14:10 -0600
        Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-12 21:02 -0600
          Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 11:23 -0700
            Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-13 22:03 -0600
              Re: Python GUI? Wolfgang Keller <feliphil@gmx.net> - 2013-09-14 19:15 +0200
                Re: Python GUI? Dave Cook <davecook@nowhere.net> - 2013-09-15 22:13 +0000
        Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-12 21:18 -0600
      Re: Python GUI? Dave Cook <davecook@nowhere.net> - 2013-09-12 18:35 +0000
    Re: Python GUI? Jerry Hill <malaclypse2@gmail.com> - 2013-09-12 13:09 -0400
    Re: Python GUI? Ian Foote <ian@feete.org> - 2013-09-12 21:17 +0100
    Re: Python GUI? Peter <peter.milliken@gmail.com> - 2013-09-12 20:39 -0700
      Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-12 22:15 -0600
    Re: Python GUI? CM <cmpython@gmail.com> - 2013-09-12 22:14 -0700
    Re: Python GUI? Kevin Walzer <kw@codebykevin.com> - 2013-09-13 09:27 -0400
      Re: Python GUI? Terry Reedy <tjreedy@udel.edu> - 2013-09-13 15:47 -0400
    Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 10:31 -0700
      Re: Python GUI? John Gordon <gordon@panix.com> - 2013-09-13 18:39 +0000
        Re: Python GUI? Joe Junior <joe.fbs.junior@gmail.com> - 2013-09-13 15:49 -0300
          Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 12:37 -0700
            Re: Python GUI? Joe Junior <joe.fbs.junior@gmail.com> - 2013-09-13 16:50 -0300
              Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 13:40 -0700
            Re: Python GUI? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-14 00:21 +0000
              Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 17:38 -0700
                Re: Python GUI? Ben Finney <ben+python@benfinney.id.au> - 2013-09-14 11:23 +1000
                  Re: Python GUI? eamonnrea@gmail.com - 2013-09-14 04:54 -0700
                    Re: Python GUI? Chris Angelico <rosuav@gmail.com> - 2013-09-14 22:07 +1000
            Re: Python GUI? Dave Angel <davea@davea.name> - 2013-09-14 02:05 +0000
          Re: Python GUI? Neil Cerutti <neilc@norwich.edu> - 2013-09-13 19:56 +0000
            Re: Python GUI? eamonnrea@gmail.com - 2013-09-13 13:40 -0700
      Re: Python GUI? llanitedave <llanitedave@veawb.coop> - 2013-09-18 19:47 -0700
    Re: Python GUI? petmertens@gmail.com - 2013-09-13 10:51 -0700
    Re: Python GUI? Metallicow <metaliobovinus@gmail.com> - 2013-09-20 11:34 -0700
      Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-20 13:49 -0600
        Re: Python GUI? Metallicow <metaliobovinus@gmail.com> - 2013-09-20 12:58 -0700
          Re: Python GUI? Michael Torrie <torriem@gmail.com> - 2013-09-20 16:49 -0600
      Re: Python GUI? Robert Kern <robert.kern@gmail.com> - 2013-09-21 00:34 +0100

Page 1 of 3  [1] 2 3  Next page →

#53994 — Python GUI?

There are a few known GUI toolkits out there, and the main ones from what I can tell are:

Tkinter -- Simple to use, but limited
PyQT -- You have a GUI designer, so I'm not going to count that
PyGTK -- Gnome officially back this I think
wxPython -- Very nice, very professional, approved by Python creator, but alas hard to get started with

So, what are your personal preferences and why? Why use X over Y?

I, personally, really like wxPython, but I also really like Tkinter. I've messed with PyGTK, but I'd choose wxPython over it.

Have you got anything to say on what one I should be using(excluding PyQT because it has a D&D designer >:( )? Is Tkinter really dead? Should I stick with wxPython?

It's might be similar to the "What language to use" argument, or the "What background to code on" argument(I prefer darker backgrounds xD Please don't argue about this though!), in the sense that there is *no* answer, just preference.

Also, with wxPython, it has kind of a "flow" layout like JFrame, whereas it will adjust it's layout to look like a native Mac App, Windows app or Linux App, correct? It'll look almost identical, right? Not that it matters, I'm just curious! :D

Thanks!

[toc] | [next] | [standalone]

#54032

On 09/11/2013 02:55 PM, eamonnrea@gmail.com wrote:
> PyQT -- You have a GUI designer, so I'm not going to count that

What do you mean?  Gtk has a GUI designer too.  what of it?

> I, personally, really like wxPython, but I also really like Tkinter.
> I've messed with PyGTK, but I'd choose wxPython over it.

Not me.  wxWidgets' event model is way too MFC-esque for me.  Does it
still use event numbers that you define?  Shudder.

Gtk and Qt's method of signals and slots is by far the most powerful and
flexible.

> Have you got anything to say on what one I should be using(excluding
> PyQT because it has a D&D designer >:( )? Is Tkinter really dead?
> Should I stick with wxPython?

I still don't understand why you are excluding Qt.  All modern toolkits
are heading towards imperative GUI design.  With Gtk I use Glade and
GtkBuilder.  My GUI is in a nice XML file that gets loaded and
manipulated by my python class.  It's extremely clean.  And in the case
of compiled programming, you don't have to recompile just to tweak
something like a layout.

At the moment if someone were to come in from scratch and ask what GUI
toolkit to use, I would answer Qt with PySide.  It's the most
cross-platform of all the toolkits, and it's one of the most mature.
Gtk is also good, but Windows and Mac support is always lagging behind
X11, and it's not as good at fitting into the native look and feel.

> Also, with wxPython, it has kind of a "flow" layout like JFrame,
> whereas it will adjust it's layout to look like a native Mac App,
> Windows app or Linux App, correct? It'll look almost identical,
> right? Not that it matters, I'm just curious! :D

Possibly.  I know Qt and Gtk both can flip the button orders, etc to
look more native.  And all good toolkits give you layout managers so you
never have to resort to fixed layouts.  Qt's layout system is very
different than Gtk's, but once you get the feel of it (use the Qt
Designer program!), it makes a lot of sense.

[toc] | [prev] | [next] | [standalone]

#54061

On Thursday, September 12, 2013 6:05:14 AM UTC+1, Michael Torrie wrote:
> On 09/11/2013 02:55 PM, eamonnrea@gmail.com wrote:
> 
> > PyQT -- You have a GUI designer, so I'm not going to count that
> 
> 
> 
> What do you mean?  Gtk has a GUI designer too.  what of it?
> 
> 
> 
> > I, personally, really like wxPython, but I also really like Tkinter.
> 
> > I've messed with PyGTK, but I'd choose wxPython over it.
> 
> 
> 
> Not me.  wxWidgets' event model is way too MFC-esque for me.  Does it
> 
> still use event numbers that you define?  Shudder.
> 
> 
> 
> Gtk and Qt's method of signals and slots is by far the most powerful and
> 
> flexible.
> 
> 
> 
> > Have you got anything to say on what one I should be using(excluding
> 
> > PyQT because it has a D&D designer >:( )? Is Tkinter really dead?
> 
> > Should I stick with wxPython?
> 
> 
> 
> I still don't understand why you are excluding Qt.  All modern toolkits
> 
> are heading towards imperative GUI design.  With Gtk I use Glade and
> 
> GtkBuilder.  My GUI is in a nice XML file that gets loaded and
> 
> manipulated by my python class.  It's extremely clean.  And in the case
> 
> of compiled programming, you don't have to recompile just to tweak
> 
> something like a layout.
> 
> 
> 
> At the moment if someone were to come in from scratch and ask what GUI
> 
> toolkit to use, I would answer Qt with PySide.  It's the most
> 
> cross-platform of all the toolkits, and it's one of the most mature.
> 
> Gtk is also good, but Windows and Mac support is always lagging behind
> 
> X11, and it's not as good at fitting into the native look and feel.
> 
> 
> 
> > Also, with wxPython, it has kind of a "flow" layout like JFrame,
> 
> > whereas it will adjust it's layout to look like a native Mac App,
> 
> > Windows app or Linux App, correct? It'll look almost identical,
> 
> > right? Not that it matters, I'm just curious! :D
> 
> 
> 
> Possibly.  I know Qt and Gtk both can flip the button orders, etc to
> 
> look more native.  And all good toolkits give you layout managers so you
> 
> never have to resort to fixed layouts.  Qt's layout system is very
> 
> different than Gtk's, but once you get the feel of it (use the Qt
> 
> Designer program!), it makes a lot of sense.

I didn't realise GTK has a GUI designer too :(

I don't like it when you can D&D to position things. I don't understand why someone wouldn't want to write the positioning code, and have fun with the debugging. That's the best part about writing a program, in my opinion. I'm against D&D with programming, and I'm not sure why.

[toc] | [prev] | [next] | [standalone]

#54064

On 2013-09-12 17:03, eamonnrea@gmail.com wrote:
> On Thursday, September 12, 2013 6:05:14 AM UTC+1, Michael Torrie wrote:
>> On 09/11/2013 02:55 PM, eamonnrea@gmail.com wrote:

>> Possibly.  I know Qt and Gtk both can flip the button orders, etc to
>> look more native.  And all good toolkits give you layout managers so you
>> never have to resort to fixed layouts.  Qt's layout system is very
>> different than Gtk's, but once you get the feel of it (use the Qt
>> Designer program!), it makes a lot of sense.
>
> I didn't realise GTK has a GUI designer too :(
>
> I don't like it when you can D&D to position things. I don't understand why someone wouldn't want to write the positioning code, and have fun with the debugging. That's the best part about writing a program, in my opinion. I'm against D&D with programming, and I'm not sure why.

There is nothing forcing you to use the GUI designers if you don't want to.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#54079

On 2013-09-12, Robert Kern <robert.kern@gmail.com> wrote:

> There is nothing forcing you to use the GUI designers if you don't want to.

There's also a markup language available, enaml:

http://docs.enthought.com/enaml/

Dave Cook

[toc] | [prev] | [next] | [standalone]

#54085

On 2013-09-12, Dave Cook <davecook@nowhere.net> wrote:
> There's also a markup language available, enaml:
>
> http://docs.enthought.com/enaml/

I should have mentioned that it's *Python*-based markup, not an XML
horrorshow.

http://pyvideo.org/video/1231/enaml-a-framework-for-building-declarative-user

Dave Cook

[toc] | [prev] | [next] | [standalone]

#54065

[Multipart message — attachments visible in raw view] — view raw

On Sep 12, 2013 9:06 AM, <eamonnrea@gmail.com> wrote:
>
> On Thursday, September 12, 2013 6:05:14 AM UTC+1, Michael Torrie wrote:
> > On 09/11/2013 02:55 PM, eamonnrea@gmail.com wrote:
> >
> > > PyQT -- You have a GUI designer, so I'm not going to count that
> >
> > What do you mean?  Gtk has a GUI designer too.  what of it
> >
> > > I, personally, really like wxPython, but I also really like Tkinter.
> >
> > > I've messed with PyGTK, but I'd choose wxPython over it.
> >
> > Not me.  wxWidgets' event model is way too MFC-esque for me.  Does it
> >
> > still use event numbers that you define?  Shudder.
> >
> > Gtk and Qt's method of signals and slots is by far the most powerful and
> > flexible.
> >
> > > Have you got anything to say on what one I should be using(excluding
> >
> > > PyQT because it has a D&D designer >:( )? Is Tkinter really dead?
> >
> > > Should I stick with wxPython?
> > I still don't understand why you are excluding Qt.  All modern toolkits
> >
> > are heading towards imperative GUI design.  With Gtk I use Glade and
> >
> > GtkBuilder.  My GUI is in a nice XML file that gets loaded and
> >
> > manipulated by my python class.  It's extremely clean.  And in the case
> >
> > of compiled programming, you don't have to recompile just to tweak
> >
> > something like a layout.
> > At the moment if someone were to come in from scratch and ask what GUI
> > toolkit to use, I would answer Qt with PySide.  It's the most
> > cross-platform of all the toolkits, and it's one of the most mature.
> >
> > Gtk is also good, but Windows and Mac support is always lagging behind
> >
> > X11, and it's not as good at fitting into the native look and feel.
>
> > > Also, with wxPython, it has kind of a "flow" layout like JFrame,
> >
> > > whereas it will adjust it's layout to look like a native Mac App,
> >
> > > Windows app or Linux App, correct? It'll look almost identical,
> >
> > > right? Not that it matters, I'm just curious! :D
> >
> >
> >
> > Possibly.  I know Qt and Gtk both can flip the button orders, etc to
> >
> > look more native.  And all good toolkits give you layout managers so you
> >
> > never have to resort to fixed layouts.  Qt's layout system is very
> >
> > different than Gtk's, but once you get the feel of it (use the Qt
> >
> > Designer program!), it makes a lot of sense.
>
> I didn't realise GTK has a GUI designer too :(
>
> I don't like it when you can D&D to position things. I don't understand
why someone wouldn't want to write the positioning code, and have fun with
the debugging. That's the best part about writing a program, in my opinion.
I'm against D&D with programming, and I'm not sure why.
> --
>

There are gui designers for wx as well. Doesn't mean you ever have to use
any of them (although I wouldn't want to write windows forms code by hand).
I do find it generally nicer to work with the markup formats (xrc for wx,
xaml for wpf, and so on) rather than trying to describe a gui in a
programming language.

The main difference between wx and qt is that qt looks native on every
platform while wx *is* native on every platform (it uses native controls
wherever possible). This means that wx integrates into the OS better, but
your also more likely to need OS-specific tweaks in wx, at least from my
experience from a few years ago.

[toc] | [prev] | [next] | [standalone]

#54308

On Thursday, September 12, 2013 10:21:49 PM UTC+5:30, Benjamin Kaplan wrote:

> The main difference between wx and qt is that qt looks native on every platform 
> while wx *is* native on every platform (it uses native controls wherever 
> possible). This means that wx integrates into the OS better, but your also more 
> likely to need OS-specific tweaks in wx, at least from my experience from a few 
> years ago.

For someone who is GUI-challenged, can you please expand on that a bit?

[toc] | [prev] | [next] | [standalone]

#54321

On Tue, Sep 17, 2013 at 7:55 AM, rusi <rustompmody@gmail.com> wrote:
> On Thursday, September 12, 2013 10:21:49 PM UTC+5:30, Benjamin Kaplan wrote:
>
>> The main difference between wx and qt is that qt looks native on every platform
>> while wx *is* native on every platform (it uses native controls wherever
>> possible). This means that wx integrates into the OS better, but your also more
>> likely to need OS-specific tweaks in wx, at least from my experience from a few
>> years ago.
>
> For someone who is GUI-challenged, can you please expand on that a bit?
> --

Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
Win32 on Windows). Other programs that want to hook into yours, such
as screen readers, are familiar with the platform's native GUI
elements- it knows what a Win32 combo box is, and it knows how to read
the text inside it.

The other way to make a GUI is to take a blank canvas and draw on it
yourself. This is more flexible and provides a more consistent
experience across platforms, but unless you specifically go out of
your way to provide hooks for other programs to jump in, all they see
is a bunch of pixels on the screen. In addition, drawing your own
stuff won't necessarily give you the "normal for the operating system"
behavior on other things, like tab behavior. It's possible for
non-native GUI environments to mimic this behavior (and QT does a
pretty good job of this), but there's always going to be little things
that seem a bit off.

The situation is a bit more complicated because QT is the native
toolkit on KDE, so in that environment, QT will be more "correct" than
wx, which would be using GTK if present and plain X11 if it isn't.

[toc] | [prev] | [next] | [standalone]

#54323

On Tuesday, September 17, 2013 9:49:28 PM UTC+5:30, Benjamin Kaplan wrote:
> On Tue, Sep 17, 2013 at 7:55 AM, rusi  wrote:
> 
> > On Thursday, September 12, 2013 10:21:49 PM UTC+5:30, Benjamin Kaplan wrote:
> 
> >
> >> The main difference between wx and qt is that qt looks native on every platform
> >> while wx *is* native on every platform (it uses native controls wherever
> >> possible). This means that wx integrates into the OS better, but your also more
> >> likely to need OS-specific tweaks in wx, at least from my experience from a few
> >> years ago.
> >
> > For someone who is GUI-challenged, can you please expand on that a bit?
> > --
> 
> Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
> Win32 on Windows). Other programs that want to hook into yours, such
> as screen readers, are familiar with the platform's native GUI
> elements- it knows what a Win32 combo box is, and it knows how to read
> the text inside it.
> 
> 
> The other way to make a GUI is to take a blank canvas and draw on it
> yourself. This is more flexible and provides a more consistent
> experience across platforms, but unless you specifically go out of
> your way to provide hooks for other programs to jump in, all they see
> is a bunch of pixels on the screen. In addition, drawing your own
> stuff won't necessarily give you the "normal for the operating system"
> behavior on other things, like tab behavior. It's possible for
> non-native GUI environments to mimic this behavior (and QT does a
> pretty good job of this), but there's always going to be little things
> that seem a bit off.

Thanks for the explanation. However I am not able to square it up:

You seem to be saying that QT draws on a blank canvas rather than calling out to the OS library.
You also seem to be saying that QT (for the most part) Does the Right Thing for each platform.

[toc] | [prev] | [next] | [standalone]

#54325

On Tue, Sep 17, 2013 at 9:51 AM, rusi <rustompmody@gmail.com> wrote:
> On Tuesday, September 17, 2013 9:49:28 PM UTC+5:30, Benjamin Kaplan wrote:
>> On Tue, Sep 17, 2013 at 7:55 AM, rusi  wrote:
>>
>> > On Thursday, September 12, 2013 10:21:49 PM UTC+5:30, Benjamin Kaplan wrote:
>>
>> >
>> >> The main difference between wx and qt is that qt looks native on every platform
>> >> while wx *is* native on every platform (it uses native controls wherever
>> >> possible). This means that wx integrates into the OS better, but your also more
>> >> likely to need OS-specific tweaks in wx, at least from my experience from a few
>> >> years ago.
>> >
>> > For someone who is GUI-challenged, can you please expand on that a bit?
>> > --
>>
>> Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
>> Win32 on Windows). Other programs that want to hook into yours, such
>> as screen readers, are familiar with the platform's native GUI
>> elements- it knows what a Win32 combo box is, and it knows how to read
>> the text inside it.
>>
>>
>> The other way to make a GUI is to take a blank canvas and draw on it
>> yourself. This is more flexible and provides a more consistent
>> experience across platforms, but unless you specifically go out of
>> your way to provide hooks for other programs to jump in, all they see
>> is a bunch of pixels on the screen. In addition, drawing your own
>> stuff won't necessarily give you the "normal for the operating system"
>> behavior on other things, like tab behavior. It's possible for
>> non-native GUI environments to mimic this behavior (and QT does a
>> pretty good job of this), but there's always going to be little things
>> that seem a bit off.
>
> Thanks for the explanation. However I am not able to square it up:
>
> You seem to be saying that QT draws on a blank canvas rather than calling out to the OS library.
> You also seem to be saying that QT (for the most part) Does the Right Thing for each platform.
> --

Right. The QT developers have been working for years to get their
controls to quack like the native ones, even though they aren't
native. They started from controls that looked and worked the same on
all platforms and have been trying to get them to play nicely with the
environment they're running in. wx has been working from the opposite
direction- they started with wrapping the native API and have been
working on getting their API to make programs come out the same even
when using different underlying toolkits. When I used wx about 5 years
ago, some of the layout got messed up when we first ran the program
(developed on Linux/GTK+)  on a Mac because of some differences
between how Carbon and GTK+ draw their controls.

[toc] | [prev] | [next] | [standalone]

#54400

On 09/17/2013 10:19 AM, Benjamin Kaplan wrote:
> Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
> Win32 on Windows). Other programs that want to hook into yours, such
> as screen readers, are familiar with the platform's native GUI
> elements- it knows what a Win32 combo box is, and it knows how to read
> the text inside it.
> 
> The other way to make a GUI is to take a blank canvas and draw on it
> yourself. This is more flexible and provides a more consistent
> experience across platforms, but unless you specifically go out of
> your way to provide hooks for other programs to jump in, all they see
> is a bunch of pixels on the screen. In addition, drawing your own
> stuff won't necessarily give you the "normal for the operating system"
> behavior on other things, like tab behavior. It's possible for
> non-native GUI environments to mimic this behavior (and QT does a
> pretty good job of this), but there's always going to be little things
> that seem a bit off.
> 
> The situation is a bit more complicated because QT is the native
> toolkit on KDE, so in that environment, QT will be more "correct" than
> wx, which would be using GTK if present and plain X11 if it isn't.

I don't think the distinction you're drawing is really all that
important.  Almost all platforms now have accessibility APIs which are a
way better way to go than relying than trying to scrape the information
by peaking into GUI structures that could change.

And on Windows, while the Win32 widget stuff you speak of is a lowest
common denominator, few modern apps use it directly anymore.  MS Office
set the the example early on by creating a new widget set for every
release (using the blank canvas method you describe!).  .Net apps using
winforms use yet another widget set.  They all now use the theming API
to draw their widgets (just like Qt does on Windows), but do their own
even processing, etc.

And it turns out that wxWidget's use of the old win32 widgets means that
some widgets just look plain old and out of place on a new Windows 7 or
8 machine, though MS has tried to make the older widgets work better
with the new theming api:

http://wiki.wxwidgets.org/WxFAQ#Why_does_my_app_take_a_Windows-95-like_look_on_Windows_.3F

My point is, the former method isn't actually the best way to go in the
long run.  The second turns out to work out better, once things like
accessibility frameworks and theming apis are in place.  Perhaps in the
future MS Windows will just provide a drawing method and a theming api.

[toc] | [prev] | [next] | [standalone]

#54095

On 09/12/2013 10:03 AM, eamonnrea@gmail.com wrote:
> I didn't realise GTK has a GUI designer too :(
> 
> I don't like it when you can D&D to position things. I don't
> understand why someone wouldn't want to write the positioning code,
> and have fun with the debugging. That's the best part about writing a
> program, in my opinion. I'm against D&D with programming, and I'm not
> sure why.

Oh, I understand now.  You mean you dislike the old fixed-position,
pixel-based layouts that visual studio used to use, right?   Well, rest
easy, because both Gtk and Qt use layout managers (packing managers)
instead.  Much more flexible, and can automatically resize as a window
sizes, and deal with things like dpi changes.

And in both cases you don't have to use the imperative tools.  You can
still hand-code your GUI in code in Gtk, Qt, or any other gui system.

In any event I think you should give both Glade-3 and Qt Designer a
serious look.  I think your hate of gui designers is about 10 years out
of date now, even if you still prefer not to use them.

[toc] | [prev] | [next] | [standalone]

#54126

On Friday, September 13, 2013 4:02:42 AM UTC+1, Michael Torrie wrote:
> On 09/12/2013 10:03 AM, eamonnrea@gmail.com wrote:
>I think your hate of gui designers is about 10 years out of date now, 
> even if you still prefer not to use them.

So, you are recommending not to code as much? :'( That is what depresses me. These "tools" depress me!

I don't understand why people don't want to code. It's time consuming: But that's the point!!! It *should* be time consuming. It *should* take time to make programs. Speed isn't the main thing, fun is. And these "tools" are taking the fun away.

[toc] | [prev] | [next] | [standalone]

#54152

On 09/13/2013 12:23 PM, eamonnrea@gmail.com wrote:
> On Friday, September 13, 2013 4:02:42 AM UTC+1, Michael Torrie
> wrote:
>> On 09/12/2013 10:03 AM, eamonnrea@gmail.com wrote: I think your
>> hate of gui designers is about 10 years out of date now, even if
>> you still prefer not to use them.
> 
> So, you are recommending not to code as much? :'( That is what
> depresses me. These "tools" depress me!

And some people think that automatic transmissions are depressing.  To
each his own.

> I don't understand why people don't want to code. It's time
> consuming: But that's the point!!! It *should* be time consuming. It
> *should* take time to make programs. Speed isn't the main thing, fun
> is. And these "tools" are taking the fun away.

And nothing in Gtk, Qt, Tk, wx, or any other modern toolkit prevents you
from declaratively creating your GUI.  And for small programs there's
nothing wrong with coding the gui by hand (and in fact I recommend it).

As complexity rises, though, I'd rather just code the creative parts of
things, and not busy-code, which is what gui code becomes.  Much of it
is boiler-plate, cut and pasted, etc.

[toc] | [prev] | [next] | [standalone]

#54169

> As complexity rises, though, I'd rather just code the creative parts
> of things, and not busy-code, which is what gui code becomes.  Much
> of it is boiler-plate, cut and pasted, etc.

If much of the code for a GUI is boiler-plate, busy-code etc. than I
would suggest that the framework is not really as efficient as it
should be.

In fact that's one of the issues I still have with Python: The language
in general is very efficient, allows to do a lot with very little code.
But all GUI frameworks that I had a look at seem to be not "pythonic"
at all in this regard. Except for PyGUI maybe, but that's far from being
as extensive as wxPython or PyQt. So for GUI applications, Python
doesn't seem to have any advantage over #§$%&! like C++ etc. concerning
code efficiency.

X-( 

Sincerely,

Wolfgang

[toc] | [prev] | [next] | [standalone]

#54193

On 2013-09-14, Wolfgang Keller <feliphil@gmx.net> wrote:

> If much of the code for a GUI is boiler-plate, busy-code etc. than I
> would suggest that the framework is not really as efficient as it
> should be.

There are very few Python GUI frameworks as such.  They are almost all
just toolkits, not frameworks in the sense of, say, Django.

Enthought has some interesting GUI framework projects which I haven't
tried:

http://code.enthought.com/projects/

Dabo would be another example.

Dave Cook

[toc] | [prev] | [next] | [standalone]

#54096

On 09/12/2013 09:02 PM, Michael Torrie wrote:
> In any event I think you should give both Glade-3 and Qt Designer a
> serious look.  I think your hate of gui designers is about 10 years out
> of date now, even if you still prefer not to use them.

This is a bit old but still how Qt works:

http://thelins.se/learnqt/2009/05/qt-layouts-the-basics/

[toc] | [prev] | [next] | [standalone]

#54076

On 2013-09-12, Michael Torrie <torriem@gmail.com> wrote:
> Not me.  wxWidgets' event model is way too MFC-esque for me.  Does it
> still use event numbers that you define?  Shudder.

You don't have to define IDs explicitly.  That's been the case for a
long time.

> Gtk and Qt's method of signals and slots is by far the most powerful and
> flexible.

wxPython's event manager adds some flexibility.

Dave Cook

[toc] | [prev] | [next] | [standalone]

#54067

On Wed, Sep 11, 2013 at 4:55 PM,  <eamonnrea@gmail.com> wrote:
> Have you got anything to say on what one I should be using(excluding PyQT because it has a D&D designer >:( )? Is Tkinter really dead? Should I stick with wxPython?

If that's a reason for excluding a GUI toolkit, you're in trouble.
Drag and drop layout tools exist for all of your proposed systems.

-- 
Jerry

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web