Pythonic cross-platform GUI desingers à la

Discussion in 'Python' started by Wolfgang Keller, Jun 8, 2012.

  1. > I want a gui designer that writes the gui code for me. I don't want to
    > write gui code. what is the gui designer that is most popular?
    > I tried boa-constructor, and it works, but I am concerned about how
    > dated it seems to be with no updates in over six years.


    Sorry to "hijack" your thread, but since this is a very related
    question...

    What "GUI designer" would come the closest to the way that Cocoa's
    Interface Builder works? I.e. is there any one (cross-platform) that
    allows to actually "connect" the GUI created directly to the code and
    make it available "live" in an IDE?

    This whole cycle of "design GUI"->"generate code"->add own code to
    generated code"->"run application with GUI" has always seemed very
    un-pythonic to me. A dynamic, interpreted language should allow to work
    in a more "lively", "direct" way to build a GUI.

    TIA,

    Sincerely,

    Wolfgang
     
    Wolfgang Keller, Jun 8, 2012
    #1
    1. Advertising

  2. Wolfgang Keller

    CM Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 8, 8:27 am, Wolfgang Keller <> wrote:
    > > I want a gui designer that writes the gui code for me. I don't want to
    > > write gui code. what is the gui designer that is most popular?
    > > I tried boa-constructor, and it works, but I am concerned about how
    > > dated it seems to be with no updates in over six years.

    >
    > Sorry to "hijack" your thread, but since this is a very related
    > question...
    >
    > What "GUI designer" would come the closest to the way that Cocoa's
    > Interface Builder works? I.e. is there any one (cross-platform) that
    > allows to actually "connect" the GUI created directly to the code and
    > make it available "live" in an IDE?
    >
    > This whole cycle of "design GUI"->"generate code"->add own code to
    > generated code"->"run application with GUI" has always seemed very
    > un-pythonic to me. A dynamic, interpreted language should allow to work
    > in a more "lively", "direct" way to build a GUI.
    >
    > TIA,
    >
    > Sincerely,
    >
    > Wolfgang


    I'm curious about your point but I don't really understand it. Could
    you try again without using any scare-quoted words? Maybe given an
    example of creating a small text editor application with a GUI builder/
    IDE in this Pythonic way you are hoping for.
     
    CM, Jun 8, 2012
    #2
    1. Advertising

  3. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    Am 08.06.2012 17:11, schrieb CM:
    > I'm curious about your point but I don't really understand it. Could
    > you try again without using any scare-quoted words? Maybe given an
    > example of creating a small text editor application with a GUI builder/
    > IDE in this Pythonic way you are hoping for.


    Before anyone now writes "Good GUIs are coded by hand":
    I agree, but for many purposes only simple GUIs are required
    and it should be possible to create these without studying manuals
    (on toolkit and GUI editor).
    A typical simple GUI would e.g. be for a measurement / data aquisition
    program, where you just need some buttons and fields.


    I think that something in the style of Visual BASIC (version 6) is required
    for either wxPython or PyQt/PySide (or both).
    In the Visual BASIC editor you can e.g. add a GUI element
    and directly go to the code editor to fill methods (e.g. an OnClick
    method).
    If you have not used VB before, you should just try it. You can create
    GUIs within a few minutes even if you haven't used it before.
    (Sure, the fact that anyone can use it has the side effect that most
    of these GUIs are not good...)

    Also:
    Such an editor should support simple manual layouts without enforcing
    the use of sizers (wx) or layout managers (Qt).
    These add an additional level of complexity which is not required
    for simple GUIs.


    Background:
    I'm using Python in a corporate environment but I'm more or less
    the only one using it. I could propagate Python for wider use as it
    is the best available language for things like hardware control and
    data acquisition, but the lack of an easy-to-use GUI editor is
    the blocking point. I can teach anyone how to create a program for data
    acquisition, but I don't see how more than a few could create a GUI
    without an easy-to-use tool.
    There's still a lot of VB6 code around as there's no replacement and
    this gap could well be filled by Python.


    Regards,

    Dietmar
     
    Dietmar Schwertberger, Jun 9, 2012
    #3
  4. Wolfgang Keller

    CM Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    > I think that something in the style of Visual BASIC (version 6) is required
    > for either wxPython or PyQt/PySide (or both).
    > In the Visual BASIC editor you can e.g. add a GUI element
    > and directly go to the code editor to fill methods (e.g. an OnClick
    > method).


    You can do this for wxPython with Boa Constructor easily. You can
    bind an event handler for a wx.EVT_BUTTON to, e.g., "Button1" with Boa
    and it will add this code for you to the bottom of your code:

    def OnButton1Button(self,evt):
    evt.Skip()

    And you can than go in the code editor to that function and change the
    code to do whatever you want.

    > If you have not used VB before, you should just try it. You can create
    > GUIs within a few minutes even if you haven't used it before.


    Same with Boa.

    > Such an editor should support simple manual layouts without enforcing
    > the use of sizers (wx) or layout managers (Qt).
    > These add an additional level of complexity which is not required
    > for simple GUIs.


    Same with Boa, though it also has good support for sizers which
    generally should be required for anything other than the simplest
    GUIs.

    > data acquisition, but the lack of an easy-to-use GUI editor is
    > the blocking point. I can teach anyone how to create a program for data
    > acquisition, but I don't see how more than a few could create a GUI
    > without an easy-to-use tool.
    > There's still a lot of VB6 code around as there's no replacement and
    > this gap could well be filled by Python.


    In addition to Boa, I get the sense that the other tools mentioned
    here are also good, so is this "blocking point" real?
     
    CM, Jun 9, 2012
    #4
  5. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Sat, Jun 9, 2012 at 11:25 PM, Dietmar Schwertberger
    <> wrote:
    > ... for many purposes only simple GUIs are required
    > and it should be possible to create these without studying manuals
    > (on toolkit and GUI editor).
    > A typical simple GUI would e.g. be for a measurement / data aquisition
    > program, where you just need some buttons and fields.
    >
    >
    > If you have not used VB before, you should just try it. You can create
    > GUIs within a few minutes even if you haven't used it before.
    > (Sure, the fact that anyone can use it has the side effect that most
    >  of these GUIs are not good...)


    There's an assumption in most of the Windows world that everything
    needs a GUI. For a simple data acquisition program, I wouldn't use one
    - I'd have it run in a console. That's something that any programmer
    should be able to create without studying complex manuals; all you
    need to know is the basics of I/O and possibly argument parsing.

    I've used Visual Basic. My first salaried work was on VB. Making it
    easy to throw together a simple GUI doesn't mean a thing when you have
    a large project to write - your business logic and UI design work will
    massively dwarf the effort of actually throwing widgets into a
    hierarchy. So the only time it's going to be an issue is with trivial
    programs; which means there isn't much to be saved. Just make your
    trivial things run in a console, and then either use a GUI builder
    (several have been mentioned) or hand-write your UI code.

    Actually, there's a third option these days. Give it no console and no
    GUI, make it respond to HTTP connections, and use a web browser as
    your UI. :)

    ChrisA
     
    Chris Angelico, Jun 9, 2012
    #5
  6. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    Am 09.06.2012 17:34, schrieb CM:
    > You can do this for wxPython with Boa Constructor easily. You can
    > bind an event handler for a wx.EVT_BUTTON to, e.g., "Button1" with Boa
    > and it will add this code for you to the bottom of your code:
    >
    > def OnButton1Button(self,evt):
    > evt.Skip()
    >
    > And you can than go in the code editor to that function and change the
    > code to do whatever you want.

    Having to go there is already more work than I would expect.
    I would expect to go there e.g. by a double-click.

    This is just a minor point, but many minor points sum up...

    If you take maybe 10 people each with some BASIC or Python knowledge,
    I would bet that you can teach most of them how to write a
    simple GUI program in VB within five minutes, but you'll probably fail
    with Boa. (And even then you would have to re-teach them in a few
    months when they try to write their next program.)


    >> If you have not used VB before, you should just try it. You can create
    >> GUIs within a few minutes even if you haven't used it before.

    >
    > Same with Boa.

    Not for me when I tried Boa.
    The logic / usage concept behind is not exactly straightforward.
    At the time, Boa was suggested to be the perfect choice for previous
    Delphi users. Maybe my problem was that I did never use Delphi.
    (Only Turbo Pascal in the pre-gui era...)


    >> Such an editor should support simple manual layouts without enforcing
    >> the use of sizers (wx) or layout managers (Qt).
    >> These add an additional level of complexity which is not required
    >> for simple GUIs.

    >
    > Same with Boa, though it also has good support for sizers which
    > generally should be required for anything other than the simplest
    > GUIs.

    Yes, at least Boa left the choice to the user.
    Some of the other tools even insist on sizers at places where they are
    not even required with a sizer-based layout.
    (E.g. with wx you usually place a notebook directly on a frame while
    some tools insist on using a sizer first.)


    > In addition to Boa, I get the sense that the other tools mentioned
    > here are also good, so is this "blocking point" real?


    I've tried several:
    wxDesigner, Boa, QtCreator, wxFormBuilder, wxGlade,
    None of these were such that I could propagate it as GUI development
    tool for non-programmers / casual users.
    Sure, some are good for designing the GUI, but at the point where
    the user code is to be added, most people would be lost.
    (I think that was the point that Wolfgang did not like and did describe
    as un-pythonic.)


    Also, another requirement for this purpose would be that the tool
    is under active development. This would e.g. rule out Boa.

    I would not care whether the tool is freeware or commercial.
    Being freeware would make handling easier, though (e.g. deployment to
    all measurement PCs by just running it from a file share is
    easier than local installations and license handling).


    Regards,

    Dietmar
     
    Dietmar Schwertberger, Jun 9, 2012
    #6
  7. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Sun, Jun 10, 2012 at 3:07 AM, Dietmar Schwertberger
    <> wrote:
    > None of these were such that I could propagate it as GUI development
    > tool for non-programmers / casual users.
    > Sure, some are good for designing the GUI, but at the point where
    > the user code is to be added, most people would be lost.


    There was a time when that was a highly advertisable feature - "build
    XYZ applications without writing a single line of code!". I've seen it
    in database front-end builders as well as GUI tools, same thing. But
    those sorts of tools tend not to be what experts want to use. You end
    up having to un-learn the "easy way" before you learn the "hard way"
    that lets you do everything.

    You refer to "non-programmers" and then point out that they would be
    lost trying to add code. That's a natural consequence of not being a
    programmer, and of all languages to help someone bridge that gap and
    start coding, I would say Python is, if not the absolute best,
    certainly up there somewhere. Just as you wouldn't expect a music
    authoring program to let someone publish score without knowing how to
    compose music, you can't expect a GUI tool to relieve you of the need
    to write code.

    WYSIWYG UI designers suffer badly from a need to guess _why_ the human
    did what s/he did. Build your UI manually, and there's no guesswork -
    you explicitly _tell_ the computer what to do and why.

    ChrisA
     
    Chris Angelico, Jun 9, 2012
    #7
  8. Wolfgang Keller

    rusi Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 9, 10:07 pm, Dietmar Schwertberger <>
    wrote:
    > > And you can than go in the code editor to that function and change the
    > > code to do whatever you want.

    >
    > Having to go there is already more work than I would expect.
    > I would expect to go there e.g. by a double-click.
    >
    > This is just a minor point, but many minor points sum up...
    >
    > If you take maybe 10 people each with some BASIC or Python knowledge,
    > I would bet that you can teach most of them how to write a
    > simple GUI program in VB within five minutes, but you'll probably fail
    > with Boa. (And even then you would have to re-teach them in a few
    > months when they try to write their next program.)


    This is worth a read in this context: http://osteele.com/archives/2004/11/ides
     
    rusi, Jun 10, 2012
    #8
  9. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On 10 June 2012 07:16, rusi <> wrote:

    > This is worth a read in this context: http://osteele.com/archives/2004/11/ides


    Interesting! I definitely fall nicely at one extreme of this
    dichotomy. Every time I've tried to use an IDE, it's made me feel
    inadequate and I've quickly retreated to my comfort zone (emacs +
    xterm). I felt inadequate because I felt like the IDE was hindering
    me rather than helping me. All I ask from the program that I use to
    write code is:

    * syntax highlighting
    * sensible auto-indenting
    * as little reliance on the mouse as possible
    * emacs key bindings :)

    This article makes me feel more positive about my inability to feel
    comfortable in an IDE. Thanks for the link!

    --
    Arnaud
     
    Arnaud Delobelle, Jun 10, 2012
    #9
  10. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    Am 10.06.2012 08:16, schrieb rusi:
    > This is worth a read in this context: http://osteele.com/archives/2004/11/ides

    So which language would you suggest to use next? ;-)

    I've read the article. It presents some nice ideas, but probably the
    author has not used Python before.
    Otherwise he would have noticed that the overall productivity does not
    only depend on language and IDE/editor, but on the complete environment
    which in the case of Python includes the ability to use the interpreter
    interactively. For many tasks that's a major productivity boost.
    But that's a point that many people don't see because their current
    language like C# or Java does not have an interpreter and when they
    just look at the syntax, the find "there's not enough improvement to
    switch".

    Also, I'm not sure whether the author counts the libraries as language
    or tool feature. In my opinion the environment and the libraries should
    be listed on their own in such an article. Libraries are developed
    after the language, but usually they are ahead of the other tools/IDEs.


    The author lists many IDE features that I personally don't find too
    important (the refactoring capabilities of a simple text editor are
    fine for me...). But following the link to Laszlo made the reason quite
    clear because his IDE background is from Eclipse not from Python.


    Btw.: I've been using Python for 16 or 17 years now. Only 3 years ago I
    did the switch from Editor to IDE (Wing IDE) and this has brought a
    *significant* boost of productivity (especially the good debugger allows
    you to code in a different way as you can use the interactive
    interpreter at any point in your program).



    But back to my original point, this time in the context of the article:
    If you want to 'sell' a programming language for corporate use, you
    absolutely need the tools. And this includes an easy-to-use GUI editor
    which does not only allow to create the GUI, but also to fill it with
    code.
    Most corporate users are casual users, not full time programmers.



    Regards,

    Dietmar
     
    Dietmar Schwertberger, Jun 10, 2012
    #10
  11. Wolfgang Keller

    Kevin Walzer Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On 6/8/12 8:27 AM, Wolfgang Keller wrote:
    > What "GUI designer" would come the closest to the way that Cocoa's
    > Interface Builder works? I.e. is there any one (cross-platform) that
    > allows to actually "connect" the GUI created directly to the code and
    > make it available "live" in an IDE?


    If you're developing on the Mac, PyObjC allows you to use Interface
    Builder for developing Python apps.

    However, there are those of us who are deeply uncomfortable with IB and
    related tools, such as RealBasic and LiveCode/Runtime Revolution. These
    tools make code organization very hard by reducing the amount of code
    written to the point of the UI working by "magic," and/or by breaking up
    your code into little snippets that you can only view by clicking on the
    widget in the UI tool.

    A related issue is that using a tool such as this makes you heavily
    dependent on that particular tool, and subject to its developers'
    priorities, release schedule, and bugs. The pace of Xcode
    development--with Apple making frequent changes to project formats in a
    backwards-incompatible way--is an example of this.

    One reason I prefer to code UI's by hand is because a) in Tkinter it's
    very easy to do, and b) it allows me to have a much better mental model
    of my code and my app's functionality--I can put everything into as many
    ..py files as I need to, and can edit my code with any text editor.

    I think these issues are a reason that the slick "drag-and-drop" UI
    builders tend to be developed by commercial software shops to support
    their language and/or IDE, but find little traction among open-source
    developers and languages.

    --Kevin

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
     
    Kevin Walzer, Jun 10, 2012
    #11
  12. Wolfgang Keller

    Rick Johnson Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 8, 7:27 am, Wolfgang Keller <> wrote:

    > This whole cycle of "design GUI"->"generate code"->add own code to
    > generated code"->"run application with GUI" has always seemed very
    > un-pythonic to me. A dynamic, interpreted language should allow to work
    > in a more "lively", "direct" way to build a GUI.


    I strongly agree with this statement also.
     
    Rick Johnson, Jun 10, 2012
    #12
  13. Wolfgang Keller

    Rick Johnson Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 9, 8:25 am, Dietmar Schwertberger <>
    wrote:

    > Before anyone now writes "Good GUIs are coded by hand":
    > I agree, but for many purposes only simple GUIs are required
    > and it should be possible to create these without studying manuals
    > (on toolkit and GUI editor).


    It is possible. Try Tkinter for the "get-you-from-a-to-b" solution,
    or, wxPython if you like fog lamps, heated seats, and navigation
    systems.

    > A typical simple GUI would e.g. be for a measurement / data aquisition
    > program, where you just need some buttons and fields.


    Buttons and feilds are just a few short lines of code. Look. You guys
    don't need a visual GUI builder. What you need to do is stop being
    lazy and spend a few hours studing the basics of Tkinter and wxPyhon
    (or whatever else suits your needs). IMO, every single python
    programmer who needs GUI interfaces should know the basics of AT LEAST
    Tkinter without even looking at the docs. I mean, how difficult is:

    import Tkinter as tk
    from Tkconstants import *
    root = tk.Tk()
    root.title('Noob')
    for x in range(10):
    f = tk.Frame(root)
    f.pack(fill=X, expand=YES)
    l = tk.Label(f, text="Field_"+str(x))
    l.pack(side=LEFT, anchor=W)
    e = tk.Entry(f)
    e.pack(side=LEFT, fill=X, expand=YES)
    root.mainloop()
    #
    # Or even better. Use grid!
    #
    root = tk.Tk()
    root.title('Amatuer')
    root.columnconfigure(1, weight=1)
    for x in range(10):
    l = tk.Label(root, text="Field_"+str(x))
    l.grid(row=x, column=0, sticky=W)
    e = tk.Entry(root)
    e.grid(row=x, column=1, sticky=W+E)
    root.mainloop()
    #
    # Or become a pro and create reusable objects!
    #
    class LE(tk.Frame):
    def __init__(self, master, **kw):
    tk.Frame.__init__(self, master)
    self.l = tk.Label(self, **kw)
    self.l.pack(side=LEFT)
    self.e = tk.Entry(self)
    self.e.pack(side=LEFT, fill=X, expand=YES)
    root = tk.Tk()
    root.title('Pro')
    for x in range(10):
    le = LE(root, text="Field_"+str(x))
    le.pack(fill=X, expand=YES)
    root.mainloop()


    >
    > I think that something in the style of Visual BASIC (version 6) is required
    > for either wxPython or PyQt/PySide (or both).
    > In the Visual BASIC editor you can e.g. add a GUI element
    > and directly go to the code editor to fill methods (e.g. an OnClick
    > method).


    With Tkinter you add a GUI element IN THE CODE and then you are
    ALREADY in the code editor! What an amazing concept! No juggling
    editors and windows. No need to mentally switch from one language to
    another. Can you imagine how productive you could be?

    > If you have not used VB before, you should just try it. You can create
    > GUIs within a few minutes even if you haven't used it before.


    Allow me to qualify that very naive generalization: "ANYBODY and point
    and click, very few can actually write code".

    > (Sure, the fact that anyone can use it has the side effect that most
    > of these GUIs are not good...)


    Well i see that you agree. Look. This is fact. GUI's require you to
    write code. You cannot get around this fact. Sure, you can create some
    templates. But in the end, you will have to write in order to link the
    templates together.

    I say. If your GUI kit gives you the feeling that you are writing too
    much boilerplate, well, then, it's time to wrap up some re-usable
    functionality on your own. I have done this myself with Tkinter AND Wx.
    ( although much more so with Tkinter being that is a poorly designed
    GUI)

    > Also:
    > Such an editor should support simple manual layouts without enforcing
    > the use of sizers (wx) or layout managers (Qt).
    > These add an additional level of complexity which is not required
    > for simple GUIs.


    See above code for example of *gasps* simple layouts in REAL code!

    > Background:
    > I'm using Python in a corporate environment but I'm more or less
    > the only one using it. I could propagate Python for wider use as it
    > is the best available language for things like hardware control and
    > data acquisition, but the lack of an easy-to-use GUI editor is
    > the blocking point.


    BS!

    > I can teach anyone how to create a program for data
    > acquisition, but I don't see how more than a few could create a GUI
    > without an easy-to-use tool.


    Like Tkinter?

    > There's still a lot of VB6 code around as there's no replacement and
    > this gap could well be filled by Python.


    Visual Basic sucks. I spend more time re-focusing my mental energy
    than actually getting work done. There is no replacement for pure raw
    code. You visualize GUI's in you mind, and fingers bring that vision
    to life through properly written API's.

    Never invent a new problem for a solution that does not exist.
     
    Rick Johnson, Jun 10, 2012
    #13
  14. Wolfgang Keller

    Rick Johnson Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 10, 2:36 pm, Rick Johnson <> wrote:

    > #
    > # Or become a pro and create reusable objects!
    > #
    > class LE(tk.Frame):
    >     def __init__(self, master, **kw):
    >         tk.Frame.__init__(self, master)
    >         self.l = tk.Label(self, **kw)
    >         self.l.pack(side=LEFT)
    >         self.e = tk.Entry(self)
    >         self.e.pack(side=LEFT, fill=X, expand=YES)
    > root = tk.Tk()
    > root.title('Pro')
    > for x in range(10):
    >     le = LE(root, text="Field_"+str(x))
    >     le.pack(fill=X, expand=YES)
    > root.mainloop()


    PS: The keywords argument should have been passed to the entry widget
    and NOT the label. Yes, occasionally, even pros make subtle mistakes.
     
    Rick Johnson, Jun 10, 2012
    #14
  15. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    Am 10.06.2012 21:36, schrieb Rick Johnson:
    > It is possible. Try Tkinter for the "get-you-from-a-to-b" solution,
    > or, wxPython if you like fog lamps, heated seats, and navigation
    > systems.

    I prefer wx or Qt. The look and feel is one reason.

    But the fact that Tkinter is still the standard GUI toolkit tells a lot
    about the situation...


    > Buttons and feilds are just a few short lines of code. Look. You guys
    > don't need a visual GUI builder. What you need to do is stop being
    > lazy and spend a few hours studing the basics of Tkinter and wxPyhon
    > (or whatever else suits your needs). IMO, every single python
    > programmer who needs GUI interfaces should know the basics of AT LEAST
    > Tkinter without even looking at the docs. I mean, how difficult is:

    [snipped code examples]
    Sure, I know how to code GUIs. But the learning curve is too steep
    for new users wanting to implement simple GUIs.


    > With Tkinter you add a GUI element IN THE CODE and then you are
    > ALREADY in the code editor! What an amazing concept! No juggling
    > editors and windows. No need to mentally switch from one language to
    > another. Can you imagine how productive you could be?

    I thought about preparing some templates for typcial applications, but
    I abandonded this as I don't think that it would work out well.


    >> If you have not used VB before, you should just try it. You can create
    >> GUIs within a few minutes even if you haven't used it before.

    >
    > Allow me to qualify that very naive generalization: "ANYBODY and point
    > and click, very few can actually write code".

    Right. I won't comment on the quality of the most VB code.
    But there are many applications where the quality of the code is not
    the main objective. It just needs to work e.g. to set up the instrument
    and read back data. The know-how and value is not the GUI code, but
    in the instrument setup and data evaluation.

    > I say. If your GUI kit gives you the feeling that you are writing too
    > much boilerplate, well, then, it's time to wrap up some re-usable
    > functionality on your own. I have done this myself with Tkinter AND Wx.
    > ( although much more so with Tkinter being that is a poorly designed
    > GUI)

    Did the same for wx twelve years ago as I did not like e.g. the event
    handling. Most of the time I'm still using my own wrappers.
    Still, once or twice a year I'm writing some small applications where
    I would use a GUI builder if it was available instead of copying old
    code as template.


    >> I can teach anyone how to create a program for data
    >> acquisition, but I don't see how more than a few could create a GUI
    >> without an easy-to-use tool.

    >
    > Like Tkinter?

    Don't like Tkinter, even though the alternatives are not too Pythonic
    either.

    > Visual Basic sucks. I spend more time re-focusing my mental energy
    > than actually getting work done. There is no replacement for pure raw
    > code. You visualize GUI's in you mind, and fingers bring that vision
    > to life through properly written API's.
    >
    > Never invent a new problem for a solution that does not exist.

    Sure, VB language sucks, but still I do not see any other tool that
    would cover the RAD aspect of the VB 6 environment. I would love to
    see Python for this, even though this would have negative side
    effects (e.g. attracting stupid people like PHP seems to).


    Regards,

    Dietmar
     
    Dietmar Schwertberger, Jun 10, 2012
    #15
  16. Wolfgang Keller

    rusi Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On Jun 10, 4:52 pm, Dietmar Schwertberger <>
    wrote:
    > Am 10.06.2012 08:16, schrieb rusi:> This is worth a read in this context:http://osteele.com/archives/2004/11/ides
    >


    >
    > I've read the article. It presents some nice ideas, but probably the
    > author has not used Python before.
    > Otherwise he would have noticed that the overall productivity does not
    > only depend on language and IDE/editor, but on the complete environment
    > which in the case of Python includes the ability to use the interpreter
    > interactively. For many tasks that's a major productivity boost.
    > But that's a point that many people don't see because their current
    > language like C# or Java does not have an interpreter and when they
    > just look at the syntax, the find "there's not enough improvement to
    > switch".


    Full agreement here

    >
    > Also, I'm not sure whether the author counts the libraries as language
    > or tool feature. In my opinion the environment and the libraries should
    > be listed on their own in such an article. Libraries are developed
    > after the language, but usually they are ahead of the other tools/IDEs.


    That was my main point and the reason for referring to that article.
    If I may rephrase your points in OSteele's terminology:

    If python is really a "language maven's" language then it does not do
    very well:
    - its not as object-oriented as Ruby (or other arcana like Eiffel)
    - its not as functional as Haskell
    - its not as integrable as Lua
    - its not as close-to-bare-metal as C
    - etc

    Then why is it up-there among our most popular languages? Because of
    the 'batteries included.'
    And not having a good gui-builder is a battery (cell?) that is
    lacking.
     
    rusi, Jun 11, 2012
    #16
  17. > > What "GUI designer" would come the closest to the way that Cocoa's
    > > Interface Builder works? I.e. is there any one (cross-platform) that
    > > allows to actually "connect" the GUI created directly to the code
    > > and make it available "live" in an IDE?
    > >
    > > This whole cycle of "design GUI"->"generate code"->add own code to
    > > generated code"->"run application with GUI" has always seemed very
    > > un-pythonic to me. A dynamic, interpreted language should allow to
    > > work in a more "lively", "direct" way to build a GUI.

    >
    > I'm curious about your point but I don't really understand it. Could
    > you try again without using any scare-quoted words?


    myidea.explanation.retry()

    Python has this insanely great thing that e.g. Delphi, Java, C#, Visual
    Basic, etc. lack and that's called an interactive commandline
    interpreter, which allows you to build GUIs while exploring/trying out
    the API of a GUI framework step by step. You simply type the code for
    the GUI at the python prompt and your GUI comes directly to life.
    Here's an example by someone else:

    http://pysnippet.blogspot.de/2010/11/getting-interactive-with-pyqt.html

    Now "just" (sorry for those quotes again) imagine a GUI builder that
    generates _and_ _runs_ the code (pyqt, wxpython, pygtk, whatever) for
    the GUI you edit _while_ you do so.

    And now imagine that this GUI builder would be integrated with the IDE
    you use (I use one), so that the GUI code is run in the same
    interpreter instance as the other code of your application. So that you
    can directly interact with your application through the GUI you build
    while you do so.

    The advantage of using a GUI builder over typing the code into the
    interpreter window would be that users who rarely implement a GUI(*)
    would not need to re-dig into the details of the API every time. This is
    especially tedious since those APIs are essentially C++ APIs wrapped
    in Python and thus they are honestly simply §$%&@# to use for a certain
    type of Python user(*). And the lack of Python-specific documentation,
    tutorials etc. doesn't really help. Did I mention yet that just having
    to read C++ example code in documentation makes me spill my last meal
    over keyboard, screen etc.?

    Of course there's PyGUI, but that's unfortunately far from being as
    complete as PyQt or wxPython and unless someone creates something like
    an equivalent of Apache Software Foundation for Python, declares PyGUI
    as the canonical Python GUI framework and funds the work needed to
    complete it... And then you still need a GUI builder for it. *sigh*

    > Maybe given an example of creating a small text editor application
    > with a GUI builder/ IDE in this Pythonic way you are hoping for.


    I'm not into text editors as example applications since I don't
    develop text editors, I rarely even use one. And besides, I don't think
    any typical user(*) of such a GUI builder would ever implement a text
    editor in his whole life.

    Personally, my typical use of such a GUI builder would be for database
    applications. Which make up, according to my experience, for at least
    90% of all custom-built applications in companies. Today, these
    applications have to be made by external, paid developers who have
    typically no clue of the application domain in question. Consequently,
    the applications, no matter how many pages of detailed specifications
    you as the domain expert write, never do what you wanted them to do.
    Although just writing the specification takes more time than it would
    take to implement it myself if only the (GUI) tools and (GUI)
    frameworks(**) for Python would be at the level required to make them
    useful for such "developers" as me(*). And did I mention that the cost
    of external developers (plus the overhead cost for interaction with
    them) makes them prohibitive anyway? And did I mention that the time
    required such external development (plus the overhead time for
    interaction with the external developers) takes doesn't help either?

    * Such as "casual" Python scripting dilettants who are not full-time
    software developers but domain experts who just use Python to help get
    their main work done.

    ** In my case of database applications, something like this:
    http://www.nakedobjects.org/book/
    http://www.nakedobjects.org/downloads/Pawson thesis.pdf

    Sincerely,

    Wolfgang
     
    Wolfgang Keller, Jun 11, 2012
    #17
  18. > > What "GUI designer" would come the closest to the way that Cocoa's
    > > Interface Builder works? I.e. is there any one (cross-platform) that
    > > allows to actually "connect" the GUI created directly to the code
    > > and make it available "live" in an IDE?

    >
    > If you're developing on the Mac, PyObjC allows you to use Interface
    > Builder for developing Python apps.


    I know that. And no, I haven't used Interface Builder yet myself, just
    because I would need those GUIs also to run elsewhere than on my
    private Mac.

    > However, there are those of us who are deeply uncomfortable with IB
    > and related tools, such as RealBasic and LiveCode/Runtime Revolution.


    I haven't used any of these either, just because I don't like those
    languages. Their syntax is ugly, static type declarations are imho
    perfectly redundant for interpreted languages and besides they don't
    offer me an interactive interpreter, which is an absolute must-have for
    my day-to-day use of Python - "office automation", ad-hoc "information
    logistics" etc. (errr, sorry for those quotation marks again... ;-).

    > These tools make code organization very hard by reducing the amount
    > of code written to the point of the UI working by "magic,"


    Any modern GUI framework has quite a lot of "magic" going on
    "behind the curtains" without that the user needs to know or understand
    how it works. And this is the way it _should_ be. As long as it is well
    documented how to use that "magic".

    The current GUI frameworks which are available for Python require way
    too much "glue code" that needs to be written by hand, imho simply
    because they are primitive wrappers around frameworks for C++
    developers who are used to such bulkloads of slave labour. Python as a
    language is way ahead of C++, Java, C# etc. in terms of functionality
    that you can implement per coding effort required , but it simply lacks
    GUI frameworks and corresponding development tools that are equally
    efficient.

    > and/or by breaking up your code into little snippets that you can
    > only view by clicking on the widget in the UI tool.


    I remember reading about RAD IDEs/frameworks out there that managed to
    integrate/seperate their generated code with/from user-written code
    quite well. And which could even use external revision control systems
    etc.. Back in the good old days of software diversity, before MS/Java
    took over the whole world...

    > A related issue is that using a tool such as this makes you heavily
    > dependent on that particular tool, and subject to its developers'
    > priorities, release schedule, and bugs.


    This is true with _any_ language, library, framework or software. Heck,
    it's even true with hardware! If this was such a show-stopper, we would
    still write computer programs like this: 0100011100101010101....
    Well, certainly not me, in that case.

    > The pace of Xcode development--with Apple making frequent changes to
    > project formats in a backwards-incompatible way--is an example of
    > this.


    Wxwidgets/python has a reputation for frequent incompatible API changes,
    too...

    And Apple's "product politics", oh, well, errr, uhm, don't get me into
    that... *sigh*. If only all those third-party applications for MacOS X
    were available on Linux, I would happily forget about Apple's very
    existence.

    > One reason I prefer to code UI's by hand is because a) in Tkinter
    > it's very easy to do,


    Tkinter is imho honestly the very best "argument" if you want to make
    potential new users turn their backs away from Python for good. Just
    show them one GUI implemented with it and, hey, wait, where are you
    running to...

    > I think these issues are a reason that the slick "drag-and-drop" UI
    > builders tend to be developed by commercial software shops to support
    > their language and/or IDE, but find little traction among open-source
    > developers and languages.


    The point is that loads of potential "developers"(*) simply don't
    ever get to use Python due to the very lack of such tools (and
    corresponding frameworks).

    * Domain experts in fact who would need to implement loads of
    software to help them get their work done but can't. And since there's
    no budget for external developers, nothing get's ever done about this.

    Sincerely,

    Wolfgang
     
    Wolfgang Keller, Jun 11, 2012
    #18
  19. Wolfgang Keller

    Kevin Walzer Guest

    Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On 6/11/12 8:01 AM, Wolfgang Keller wrote:
    > Tkinter is imho honestly the very best "argument" if you want to make
    > potential new users turn their backs away from Python for good. Just
    > show them one GUI implemented with it and, hey, wait, where are you
    > running to...


    Yes, Tkinter GUI's are very ugly.

    http://www.codebykevin.com/phynchronicity-running.png

    http://www.codebykevin.com/quickwho-main.png

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
     
    Kevin Walzer, Jun 11, 2012
    #19
  20. Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

    On 11/06/2012 13:47, Kevin Walzer wrote:
    > Yes, Tkinter GUI's are very ugly.
    >
    > http://www.codebykevin.com/phynchronicity-running.png
    >
    > http://www.codebykevin.com/quickwho-main.png
    >


    At last we're getting to the crux of the matter. Provided that the GUI
    is pretty who cares about picking appropriate algorithms for the code,
    or a sensible database design or whatever. And heaven forbid that
    anyone suggest using a command line even if this was the better solution
    for the problem that the user wants solved.

    --
    Cheers.

    Mark Lawrence.
     
    Mark Lawrence, Jun 11, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. demibee
    Replies:
    0
    Views:
    372
    demibee
    Dec 26, 2003
  2. Carl J. Van Arsdall
    Replies:
    4
    Views:
    503
    Bruno Desthuilliers
    Feb 7, 2006
  3. Chris Angelico
    Replies:
    1
    Views:
    219
    Wolfgang Keller
    Jun 14, 2012
  4. Dietmar Schwertberger
    Replies:
    5
    Views:
    309
  5. Dietmar Schwertberger
    Replies:
    5
    Views:
    355
Loading...

Share This Page