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

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

Wgy isn't there a good RAD Gui tool fo python

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

Contents

  Wgy isn't there a good RAD Gui tool fo python Ivan Kljaic <ikljaic@gmail.com> - 2011-07-10 15:50 -0700
    Re: Wgy isn't there a good RAD Gui tool fo python Corey Richardson <kb1pkl@aim.com> - 2011-07-10 19:03 -0400
    Re: Wgy isn't there a good RAD Gui tool fo python CM <cmpython@gmail.com> - 2011-07-10 16:49 -0700
    Re: Wgy isn't there a good RAD Gui tool fo python Adam Tauno Williams <awilliam@whitemice.org> - 2011-07-10 20:42 -0400
      Re: Wgy isn't there a good RAD Gui tool fo python "bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> - 2011-07-11 05:09 -0700
        Re: Wgy isn't there a good RAD Gui tool fo python Ben Finney <ben+python@benfinney.id.au> - 2011-07-11 22:39 +1000
          Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 06:44 -0700
            Re: Wgy isn't there a good RAD Gui tool fo python Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-11 16:10 +0200
              Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 07:21 -0700
                Re: Wgy isn't there a good RAD Gui tool fo python Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-11 16:38 +0200
                Re: Wgy isn't there a good RAD Gui tool fo python Chris Angelico <rosuav@gmail.com> - 2011-07-12 00:39 +1000
                  Re: Wgy isn't there a good RAD Gui tool fo python rusi <rustompmody@gmail.com> - 2011-07-11 09:33 -0700
                    Re: Wgy isn't there a good RAD Gui tool fo python rantingrick <rantingrick@gmail.com> - 2011-07-11 09:56 -0700
                      Re: Wgy isn't there a good RAD Gui tool fo python Chris Angelico <rosuav@gmail.com> - 2011-07-12 04:03 +1000
                        Re: Wgy isn't there a good RAD Gui tool fo python rantingrick <rantingrick@gmail.com> - 2011-07-11 11:52 -0700
                          Re: Wgy isn't there a good RAD Gui tool fo python Chris Angelico <rosuav@gmail.com> - 2011-07-12 05:27 +1000
                            Re: Wgy isn't there a good RAD Gui tool fo python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-12 12:40 +1200
                      Re: Wgy isn't there a good RAD Gui tool fo python Ivan Kljaic <ikljaic@gmail.com> - 2011-07-11 11:28 -0700
                        Re: Wgy isn't there a good RAD Gui tool fo python Chris Angelico <rosuav@gmail.com> - 2011-07-12 05:16 +1000
                        Re: Wgy isn't there a good RAD Gui tool fo python rantingrick <rantingrick@gmail.com> - 2011-07-11 12:03 -0700
                        Re: Wgy isn't there a good RAD Gui tool fo python Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-11 14:48 -0500
                        Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 12:58 -0700
                          Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 13:02 -0700
                          Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 13:19 -0700
                        Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 12:37 -0700
                        Re: Wgy isn't there a good RAD Gui tool fo python Kevin Walzer <kw@codebykevin.com> - 2011-07-11 16:35 -0400
                          Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 13:52 -0700
                            Re: Wgy isn't there a good RAD Gui tool fo python CM <cmpython@gmail.com> - 2011-07-12 11:43 -0700
                              Re: Wgy isn't there a good RAD Gui tool fo python rantingrick <rantingrick@gmail.com> - 2011-07-12 14:18 -0700
                                Re: Wgy isn't there a good RAD Gui tool fo python CM <cmpython@gmail.com> - 2011-07-12 17:22 -0700
                                  Re: Wgy isn't there a good RAD Gui tool fo python rusi <rustompmody@gmail.com> - 2011-07-13 07:59 -0700
                        Re: Wgy isn't there a good RAD Gui tool fo python Ben Finney <ben+python@benfinney.id.au> - 2011-07-12 11:10 +1000
              Re: Wgy isn't there a good RAD Gui tool fo python Speedbird <julio@techfuel.net> - 2011-07-11 09:38 -0700
              Re: Wgy isn't there a good RAD Gui tool fo python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-12 20:24 +1000
                Re: Wgy isn't there a good RAD Gui tool fo python Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-12 06:20 -0500
                Re: Wgy isn't there a good RAD Gui tool fo python Chris Angelico <rosuav@gmail.com> - 2011-07-12 22:27 +1000
    Re: Wgy isn't there a good RAD Gui tool fo python Adam Tauno Williams <awilliam@whitemice.org> - 2011-07-10 20:43 -0400
      Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 03:47 -0700
    Re: Wgy isn't there a good RAD Gui tool fo python Anthony Papillion <papillion@gmail.com> - 2011-07-10 19:51 -0500
    Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 03:34 -0700
    Re: Wgy isn't there a good RAD Gui tool fo python Kevin Walzer <kw@codebykevin.com> - 2011-07-11 09:58 -0400
    Re: Wgy isn't there a good RAD Gui tool fo python Stefan Behnel <stefan_ml@behnel.de> - 2011-07-11 19:11 +0200
    Re: Wgy isn't there a good RAD Gui tool fo python "Elias Fotinis" <efotinis@yahoo.com> - 2011-07-11 21:59 +0300
      Re: Why isn't there a good RAD Gui tool for python Billy Mays <noway@nohow.com> - 2011-07-11 15:21 -0400
        Re: Why isn't there a good RAD Gui tool for python Hansmeet Singh <hansmeetschool@gmail.com> - 2011-07-11 20:05 -0800
    Re: Wgy isn't there a good RAD Gui tool fo python Dave Cook <davecook@nowhere.net> - 2011-07-11 23:33 +0000
      Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 18:42 -0700
      Re: Wgy isn't there a good RAD Gui tool fo python sturlamolden <sturlamolden@yahoo.no> - 2011-07-11 18:38 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9281

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.11 02:16 PM, Chris Angelico wrote:
> You think Microsoft makes decisions and sticks with them? Look at 
> Office's last few versions. They can't decide on a file format, an 
> interface, a featureset... everything keeps changing.
Of course they do. They've decided to change things in each major
version to give people a reason to pay for the new version when there's
nothing wrong with the old one (at least nothing that's been fixed in
the new version :P ). Of course, MS is not the only software company
that employs such a strategy...

- -- 
CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOG1ORAAoJEPiOA0Bgp4/LF7oH/Al6RTGIQ2hAKztEiob/oXnz
+eV8HZ0K+OBpd/FtRBkiMTJaQm5LU1jKPdwsf/RhF7UU69FfCQNfhzW5LsdMMQYE
+lh4YwbJ8cXVEkCgdkf2zh7BElJ9/95nYedd64Ev4sG+QECvLFYoeql5mjcO45S9
V+iElE9y4FsPr1E0tC2BhFPQuiRMRIIOjQQ7UKP28dnIOKf6u9QM4UdN4WYKOy+n
jgXRaFtstA3YtbzqmKfVoj9Go8SstF71XnGjSzAQeq4j96IfbvW/PTaPhkvyfB7y
tHG861oW19orvZ1ESJue/lvd/KQ7rRDRn7IjH+fKvKuYlgjM3+Q7hR7hcXi97Wg=
=a5A/
-----END PGP SIGNATURE-----

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

#9282

On 11 Jul, 20:28, Ivan Kljaic <iklj...@gmail.com> wrote:

> To summarize it. It would be very helpfull for python to spread if
> there qould be one single good rad gui builder similar to vs or
> netbeAns but for python. So right now if i need to make a gui app i
> need to work with an applicatio that is dicontinued for the last 5
> years is pretty buggy but is ok.

http://wxformbuilder.org/

Shut up.


> The ony worthly ones mentioning as an gui builder are boa constructor
> fo wx, qtDesigner with the famous licence problems why companies do
> not want to work with it, sharpdevelop for ironpython and netbeans for
> jython.
> Did you notice that 2 of these 4 are not for python? One is out of dTe
> and one has a fucked up licence.


Qt and PySide have LGPL license. QtCreator can be used with Python
(there is a Python uic).

SharpDevelop has an IronPython GUI builder.

Boa Constructor is abandonware, yes.


Is it just me, or did I count to three?

And yes, you forgot:

Visual Studio for IronPython
wxGLADE for wxPython
GLADE for PyGTK
BlackAdder for Python and Qt
SpecTcl for Tkinter

That's eight.

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

#9283

On 11 Jul, 21:58, sturlamolden <sturlamol...@yahoo.no> wrote:

> That's eight.

Sorry, nine ;)

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

#9286

On 11 Jul, 21:58, sturlamolden <sturlamol...@yahoo.no> wrote:

> http://wxformbuilder.org/


This Demo is using C++, it works the same with Python (wxPython code
is generated similarly).

http://zamestnanci.fai.utb.cz/~bliznak/screencast/wxfbtut1/wxFBTut1_controller.swf



Sturla

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

#9284

On 11 Jul, 20:28, Ivan Kljaic <iklj...@gmail.com> wrote:

> The ony worthly ones mentioning as an gui builder are boa constructor
> fo wx, qtDesigner with the famous licence problems why companies do
> not want to work with it, sharpdevelop for ironpython and netbeans for
> jython.

There is wxFormBuilder for wxPython, I suppose you've missed it. Of
three GUI builders for wxPython (wxFormBuilder, wxGLADE, Boa
Constructor), you managed to pick the lesser.

The license for Qt is LGPL, the same as for wxWidgets. Both have LGPL
Python bindings (PySide and wxPython), so why is Qt's license more
scary than wxWidgets?

I have an idea why you think QtCreator cannot be used with Python. If
you had actually used it, you would have noticed that the XML output
file can be compiled by PyQt and PySide.

SharpDevelop for IronPython means you've missed Microsoft Visual
Studio. Bummer.

And I am not going to mention IBM's alternative to NetBeans, as I am
sure you can Google it.

And did you forget abpout GLADE, or do you disregard GTK (PyGTK) as a
toolkit completely?


Regards,
Sturla

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

#9287

On 7/11/11 2:28 PM, Ivan Kljaic wrote:
> Did you notice that 2 of these 4 are not for python? One is out of dTe
> and one has a fucked up licence. Sorry guys but there is not even one
> single rad gui tool for python as long as there is no serious
> guibuilder.

One reason there hasn't been much demand for a GUI builder is that, in 
many cases, it's just as simpler or simpler to code a GUI by hand. 
Certainly with the Tkinter library this is trivial. The only GUI builder 
I've ever used that was arguably superior to hand-coding is Interface 
Builder, on Mac OS X, and it's truly needed there. (The Cocoa frameworks 
don't really lend themselves to hand-coding.) Otherwise I find GUI 
builders inflexible, and more trouble than they are worth.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

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

#9288

On 11 Jul, 22:35, Kevin Walzer <k...@codebykevin.com> wrote:

> One reason there hasn't been much demand for a GUI builder is that, in
> many cases, it's just as simpler or simpler to code a GUI by hand.

Often a GUI builder is used as a bad replacement for sketch-pad and
pencil.

With layout managers (cf. wxWidgets, Qt, Swing, SWT, Tkinter) it is
easier to "sketch and code" than with common MS Windows toolkits (eg.
MFC, .NET Forms, Visual Basic, Delphi) which use absolute positioning
and anchors. Using a GUI builder with layout managers might actually
feel awkward. But with absolute positioning and anchors, there is no
way to avoid a GUI builder. That said, we have good GUI builders for
all the common Python GUI toolkits.

Sometimes a mock-up GUI designer like DesignerVista might help.

Yes, and actually hiring a graphical designer helps too.


Sturla

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

#9336

> > One reason there hasn't been much demand for a GUI builder is that, in
> > many cases, it's just as simpler or simpler to code a GUI by hand.

I use a GUI builder because I'd rather click less than type more. I
just
tried that in Boa Constructor; with ~10 mouse clicks I produced 964
characters of Python code.  Now, sure, depending on how I wrote the
code I could do better than that, but for me, I just find it more
intuitive
and easier to use a GUI to make a GUI.

> Often a GUI builder is used as a bad replacement for sketch-pad and
> pencil.

I would use a sketch-pad and pencil and *then* use the GUI builder.
What's nice about a builder is one can move things around quickly
and see the results in the real application, which one can never
really
see well on a paper sketch.  You could use a mock-up program of
course, but I feel you might as well do it in the builder because when
you're satisfied with it you have a real runnable application instead
of just a picture.

> Using a GUI builder with layout managers might actually
> feel awkward.

It takes some getting used to in Boa, in my experience, but then
it feels intuitive and I really like using sizers with Boa.  It helps
if
you give your sizers descriptive names.

Che

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

#9348

On Jul 12, 1:43 pm, CM <cmpyt...@gmail.com> wrote:
> > > One reason there hasn't been much demand for a GUI builder is that, in
> > > many cases, it's just as simpler or simpler to code a GUI by hand.
>
> I use a GUI builder because I'd rather click less than
> type more. I just tried that in Boa Constructor; with ~10
> mouse clicks I produced 964 characters of Python code.

Remember, it's NOT the length of the code that matters, no, it's the
motion of the "sources" ocean. Did it produce rough seas full of
spaghetti monsters? Or tranquil fjords worth pining over (sadly to
death apparently?)?

 1. Never judge the quality of code simply by it's length. Because if
you do, some folks might suffer from "source envy"!

Also, you MAY have created 964 chars of code with your ten or so
clicks HOWEVER that is just template code. You'll need to set many
attributes for the widgets before they are ready for prime time. Your
"supposed" ten or so click estimate is very naive. It takes MUCH more
to create even a simple GUI, because, we have NOT even discussed logic
yet!

> Now, sure, depending on how I wrote the code I could do
> better than that, but for me, I just find it more
> intuitive and easier to use a GUI to make a GUI.

Personal opinions should always be respected, and as such i respect
yours but later i would outline my GUI design workflow so pay close
attention.

> > Often a GUI builder is used as a bad replacement for
> > sketch-pad and pencil.
>
> I would use a sketch-pad and pencil and *then* use the GUI builder.

But do you really? Your following statements lead me to believe that
you don't.

> What's nice about a builder is one can move things around
> quickly and see the results in the real application, which
> one can never really see well on a paper sketch. 

I prefer to skip any pencil and paper completely myself. I just use my
imagination. UNLESS the GUI is EXTREMELY complicated. For me the
design of a GUI starts in my brain. No pencil, no paper, no three
hours using Auto Cad GUI designer. Next i start creating widgets and
laying them out using geometry managers (in CODE). Finally i run a few
tests, make a few changes, and design phase is over. Time for logic.

---------------------------------------------
My argument against GUI builders is two fold.
---------------------------------------------

 1. GUI builders remove us from the initial "mental design phase" and
temp us to let our inner "click-ity-click" and "drag-ity-drag" child
loose. This inner child likes to play but he hates to plan. Very soon
he has the play room floor (source code) overflowing with toys (code)
arranged in a completely haphazard way. Unlike the child however,
there is no code mommy to spank this bad little boy when he is a
programmer. So he just keeps messing up play room after play room
making a complete fool of himself along the way.

 2. GUI builders remove us from the source code. When you are playing
"clicky-click" with yourself you could be in the trenches fighting the
spaghetti code monster. Instead you are losing mental focus. Remember,
playing with yourself makes you lazy!
----------------------------------------------

What happens is... you get lost "playing" and fail to keep your mental
focus. A programmers metal focus is his most valuable weapon in the
fight against the spaghetti code monster. I am a programmer. I love my
source code more than i love most people in this world. I do not want
to be away from my source. I am jealous of my source! And so too
should you be.

Kevin made the argument earlier that Tkinter (and others) are so easy
to use that they render needing a GUI builder useless -- and he is
correct! But did you know that there are GUI libraries EVEN more
highly abstracted than Tkinter? Oh yes! So your "OMG, this typing and
using my imagination is so difficult" *crap* is really making me
laugh.

That is my argument people. Opinions may vary. Keep watch for the
spaghetti code monster!
Cheers folks.

PS: if you don't like to type, programming IS NOT the best career (or
hobby) choice for you.

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

#9356

On Jul 12, 5:18 pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jul 12, 1:43 pm, CM <cmpyt...@gmail.com> wrote:
>
> > > > One reason there hasn't been much demand for a GUI builder is that, in
> > > > many cases, it's just as simpler or simpler to code a GUI by hand.
>
> > I use a GUI builder because I'd rather click less than
> > type more. I just tried that in Boa Constructor; with ~10
> > mouse clicks I produced 964 characters of Python code.
>
> Remember, it's NOT the length of the code that matters, no, it's the
> motion of the "sources" ocean. Did it produce rough seas full of
> spaghetti monsters? Or tranquil fjords worth pining over (sadly to
> death apparently?)?

In my experience, the GUI builder I use creates reasonable code
that deals with the GUI in a separate portion of the code.  It does
not strike me as spaghetti-ish (though it's not perfect).

> Also, you MAY have created 964 chars of code with your ten or so
> clicks HOWEVER that is just template code. You'll need to set many
> attributes for the widgets before they are ready for prime time. Your
> "supposed" ten or so click estimate is very naive. It takes MUCH more
> to create even a simple GUI, because, we have NOT even discussed logic
> yet!

Sure.  But my point was just that to even get as far as I did (which
was
just a frame and two unspecified widgets) takes 964+ keystrokes, but
only ~10 clicks.  So the pacing of keystrokes:clicks is favorable.
If I built a small functioning GUI application, it  might take 100
clicks
and 9,640 keystrokes (very roughly).  But it is the same point.

> > I would use a sketch-pad and pencil and *then* use the GUI builder.
>
> But do you really? Your following statements lead me to believe that
> you don't.
>
> > What's nice about a builder is one can move things around
> > quickly and see the results in the real application, which
> > one can never really see well on a paper sketch. 

I just meant that though I might start on paper, once it is on
the screen I sometimes will shift things around a bit at that point
to see how it looks.  This is easily done with sizers and a sizer
collection manager and an up/down arrow, so it is worth an
extra minute to just see how it looks.

>  1. GUI builders remove us from the initial "mental design phase" and
> temp us to let our inner "click-ity-click" and "drag-ity-drag" child
> loose. This inner child likes to play but he hates to plan. Very soon
> he has the play room floor (source code) overflowing with toys (code)
> arranged in a completely haphazard way. Unlike the child however,
> there is no code mommy to spank this bad little boy when he is a
> programmer. So he just keeps messing up play room after play room
> making a complete fool of himself along the way.
>
>  2. GUI builders remove us from the source code. When you are playing
> "clicky-click" with yourself you could be in the trenches fighting the
> spaghetti code monster. Instead you are losing mental focus. Remember,
> playing with yourself makes you lazy!

I've certainly heard of others who feel that working with only code
is "cleaner" for them, mentally speaking.  I can understand that.  I
think it just depends on what one is used to.  I don't find the GUI
builder disrupts my ability to plan or keep things orderly.  In fact,
most of my disorder and spaghetti problems have been in the logic
side of the applications, the part which the GUI builder doesn't have
anything to do with.  (That's my own issue to keep working on).

> Kevin made the argument earlier that Tkinter (and others) are so easy
> to use that they render needing a GUI builder useless -- and he is
> correct! But did you know that there are GUI libraries EVEN more
> highly abstracted than Tkinter? Oh yes! So your "OMG, this typing and
> using my imagination is so difficult" *crap* is really making me
> laugh.

My attitude is, if I could speak in English to an AI to tell it what
I'd like
the program to do, I'd do it. Yes, since I can't do that, I inevitably
do
sometimes enjoy puzzling things out, but only because I have to.

> PS: if you don't like to type, programming IS NOT the best career (or
> hobby) choice for you.

I guess it is not so much that I dislike typing, as I dislike having
to
switch from visual mode to code mode, remember the keywords and
such for the widgets, rather than quickly clicking around.  The
keystroke count is really just a proxy for that sort of effort.

CM

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

#9403

On Jul 13, 5:22 am, CM <cmpyt...@gmail.com> wrote:
> On Jul 12, 5:18 pm, rantingrick <rantingr...@gmail.com> wrote:

> > Kevin made the argument earlier that Tkinter (and others) are so easy
> > to use that they render needing a GUI builder useless -- and he is
> > correct! But did you know that there are GUI libraries EVEN more
> > highly abstracted than Tkinter? Oh yes! So your "OMG, this typing and
> > using my imagination is so difficult" *crap* is really making me
> > laugh.
>
> My attitude is, if I could speak in English to an AI to tell it what I'd like the
> program to do, I'd do it. Yes, since I can't do that, I inevitably
> do sometimes enjoy puzzling things out, but only because I have to.
>
> > PS: if you don't like to type, programming IS NOT the best career (or
> > hobby) choice for you.
>
> I guess it is not so much that I dislike typing, as I dislike having
> to
> switch from visual mode to code mode, remember the keywords and
> such for the widgets, rather than quickly clicking around.  The
> keystroke count is really just a proxy for that sort of effort.

Yes. This is what is called the semantic gap.

Say you were a programmer who had to write software for numerical
analysis.
Would you write it in assembly even if, say, you knew assembly very
well?
I contend that most sane programmers would choose an algebraic
language because they understand (formally or intuitively it does not
matter) that minimizing semantic gaps are best for programming.

Writing text that indirectly describes a gui rather than directly
drawing it is analogous to writing assembly that implies an algebraic
operation instead of writing the algebra directly.

As for Kevin's point:
> One reason there hasn't been much demand for a GUI builder is that, in
> many cases, it's just as simpler or simpler to code a GUI by hand.

I am not sure how to interpret that.  If you are saying that most of
today's gui builders are too close to suxware to be worth the time, I
guess its true (and eminently practical)

If on the other hand the claim is that the very idea of gui-builders
is a flawed one I think the jury is still out on that.  And the
history of computer science repeatedly shows that very high level
ideas take decades to enter the mainstream.

Think of garbage collection in 1960 in the esoteric lisp finally
getting mainlined in Java in 1995.

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

#9298

Ivan Kljaic <ikljaic@gmail.com> writes:

> My comPany would switch to python but they complained that there is
> not even one single gui builder or framework that can allow it to make
> a living from it.

That response from your company is a non sequitur. What does “one single
gui builder or framework” have to do with “allow it to make a living
from it”?

Evidently many organisations are making a living with Python, so that
statement is just false.

> For how many years are this vui library wars going on. How many.

Why see it as a war that must have one clear winner? You have options.

> I am a open source supporter but Windows will always kick the ass of
> open source because the open source comunity can not make a decision.

Different people make different decisions. If you want a monolithic
organisation that makes a single decision for everyone, you don't want
software freedom.

> To summarize it. It would be very helpfull for python to spread

Please find a different language to “fix”; Python is spreading quite
successfully.

-- 
 \          “I don't like country music, but I don't mean to denigrate |
  `\          those who do. And for the people who like country music, |
_o__)                        denigrate means ‘put down’.” —Bob Newhart |
Ben Finney

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

#9262

> On Windows, you're a customer and the developer wants to make using his
> application as convenient as possible for you, the customer.
>

So the well-behavioured, good-intentioned windows devs are making sure
the
customer feels pampered and cozy, how nice and dandy.

> On Unix you don't pay and the developer couldn't care less if his
> application works together with application b or how much it takes you
> to actually get this damn thing running.
>

Now, on the other hand, the bad, bearded, grumpy and ugly unix devs
want to make the customer's life miserable, bad boys..

What a load of bull, I am a unix developer and do _care_ for my
customers, being them sysadmins, end users or even windows heads,
and I am sure I am not the only one thinking this way.

The windows "way of doing things" ("user friendly experience", "point
and click", "plug and play") etc is not a bad one at all, it consists
of tools to allow developers who have lesser understanding about
computers
to create applications that will be used by users with also little
understanding
about computers in general, on the other hand, unix/linus/posix devs
develop
applications that can potentially be used more efficiently by people
with great understanding about computers in general.

Both have their user base, and this is IMO the primary reason why
windows
is the dominant OS currently, those with little understanding about
computers and technology in general far outnumber those who do.

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

#9309

Thorsten Kampe wrote:

> * sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT))
>> On 11 Jul, 14:39, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>> > The Unix model is: a collection of general-purpose, customisable
>> > tools, with clear standard interfaces that work together well, and
>> > are easily replaceable without losing the benefit of all the others.
>> 
>> This is opposed to the "Windows model" of a one-click installer for a
>> monolithic application. Many Windows users get extremely frustrated
>> when they have to use more than one tool.
> 
> *sigh* There is no Windows nor Unix "model". There is only you-get-what-
> you-pay-for.
> 
> On Windows, you're a customer and the developer wants to make using his
> application as convenient as possible for you, the customer.

That's an astonishing statement.

Today, I started to update a commercial, proprietary Windows application,
Quickbooks. I didn't actually get around to running the installer
application yet, on account of the installer having trouble if your data is
on a network share. (Apparently the developers of Quickbooks never
considered that when you have multiple users connected to the same database
at once, at least one of them must be accessing it over the network.) But
in preparation for the process, I took note of the information needed to
make QB run. I don't have the list in front of me, but there were something
like 6 or 8 keys needed to make the software work:

Customer account number
Licence key
Upgrade key
Validation code
etc.

(I don't remember the full list. I try not to bring that part of my work
home :)

Or consider the Windows licence key, product activation code, etc. If "as
convenient as possible" was their aim (as opposed to "making a profit from
licencing"), then you wouldn't need all that.

Why on earth should I have to install a "Amazon MP3 Downloader" app to
purchase mp3s? Or the iTunes app? The internet and web browsers excel at
making it easy to download files. Rather than taking advantage of that
convenience, commercial vendors put barriers in the way and try to carve
out little walled gardens. Did they not learn anything from AOL?

Where is the Windows equivalent of yum or apt-get? Why isn't there a central
repository of independent and third party Windows software? It seems clear
to me that it is the major open source communities that aim for
convenience, at the cost of the opportunity to sell licences.

In fairness though, open source developers' idea of "convenient" is not
always the same as mine.


> On Unix you don't pay and the developer couldn't care less if his
> application works together with application b or how much it takes you
> to actually get this damn thing running.

That might have been true, oh, 20 years ago, but today, that's far less of a
rule. Linux distros make interoperability far simpler. Some level of savvy
is needed, but it is remarkable how much Linux software Just Works.

In my experience, two categories of Linux software are generally hard to
deal with: one-man projects (usually stuck on version 0.2b for the last
seven years), and big, popular projects that have been taken over by
developers from the Windows world (I'm looking at you, Firefox). YMMV.


> And as soon as developers start developing for Unix customers (say
> Komodo, for instance), they start following the "Windows model" - as you
> call it.

Surely that's because Komodo started off as a Windows application before
being ported to Unix?



-- 
Steven

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

#9310

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.12 05:24 AM, Steven D'Aprano wrote:
> Rather than taking advantage of that convenience, commercial vendors
> put barriers in the way and try to carve out little walled gardens.
> Did they not learn anything from AOL?
DRM and activation schemes will /always/ make things harder, but that is
the cost of doing business, at least in the minds of commercial software
vendors.

There are actually a lot of good freeware (proprietary, but zero cost)
apps out there. Some even better than open-source alternatives. I avoid
commercial apps, though, since they tend to be far inferior to the
alternatives (inconvenience aside).

> Where is the Windows equivalent of yum or apt-get? Why isn't there a
> central repository of independent and third party Windows software?
If Microsoft made such a repository, how much of the repository would be
high-quality open-source software, and how much would be commercial
shovelware?

Attempts at independent repos have been made, but they all fail because
there's no effort among developers (especially developers of proprietary
software), to package their software this way. These attempts also fail
because they fail to gain support from users (a catch-22 where users
don't bother because there's not much in the repo and there's not much
in the repo because users don't bother).

> It seems clear to me that it is the major open source communities
> that aim for convenience, at the cost of the opportunity to sell
> licences.
The developers of open-source projects often aim to please the user
rather than make money. You'd think pleasing the user and making money
would go hand-in-hand, but history has shown that the latter can be
achieved with little thought of the former.

> That might have been true, oh, 20 years ago, but today, that's far
> less of a rule. Linux distros make interoperability far simpler. Some
> level of savvy is needed, but it is remarkable how much Linux
> software Just Works.
At first, Linux had to learn how to crawl and then walk. Now it's doing
gymnastics. :)

> In my experience, two categories of Linux software are generally hard
> to deal with: one-man projects (usually stuck on version 0.2b for the
> last seven years), and big, popular projects that have been taken
> over by developers from the Windows world (I'm looking at you,
> Firefox). YMMV.
Firefox (and Thunderbird with it) are falling into the same trap that
many fall into when they become popular. This is more prevalent among
commercial apps, but it's not too surprising considering Firefox's
popularity. The trap is making things shiny. That is, using UI designs
(and to a lesser extent adding neat, but generally useless features)
that appeal to the computer-illiterate masses who cling to something
that looks neat, regardless of how useful it ultimately is. AFAICT,
Mozilla's problem isn't that incompetent Windows-centric devs took over,
but rather that Google and MS were stepping up their game with their
respective browsers and is desperately trying not to lose market share.

- -- 
CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOHC4EAAoJEPiOA0Bgp4/Lgm0IAOT+/LQNalPHm5pvt4ilF1yt
RM9fPBSgAF5k9U8jWBuQy/V6QJ/a1Sfkzu8ulZ8TyAYS64quucIqTwMJugdTUmct
KsGbDsyXg0FObMxNiKKFuZblVYOtnULkYtYZOxeE33qy+85X6NMuFUv7ARHaLi/3
1Bdmnsj43hRrzJ1Rwb8x+xbOmiq+fJ7199loPQ+unSu7s37NJoL1e1vFNnsmGz8A
Jg58Q0MbGiwettPdM9ZySYWgTJhiawtEX4SF6YiQqf22e04OyPWyxUfejixnZNoQ
7vbksr9k8PQzuTlG2y3G1pJx6XGrxgOQuEoVjInMGbZW0tx43paJLEWCOcd38FI=
=3FGv
-----END PGP SIGNATURE-----

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

#9312

On Tue, Jul 12, 2011 at 8:24 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Where is the Windows equivalent of yum or apt-get? Why isn't there a central
> repository of independent and third party Windows software? It seems clear
> to me that it is the major open source communities that aim for
> convenience, at the cost of the opportunity to sell licences.
>

The nearest commercial equivalent is probably Apple's iTunes store. It
manages to be the "one place to go" for iphone apps, many of which
cost money. Upside: Developers know where to host their stuff if they
want it to sell. Downside: Developers have to host it there if they
want it to sell - and Apple snag 30% on the way through.

I've not seen a Windows equivalent, but Microsoft could make one if
they wanted to. All they need is for the next version of Windows to
recommend that all software be signed, and make it somewhat awkward to
install unsigned software, and that would be that. It would probably
be the knell of Windows, but it could be done.

ChrisA

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

#9212

>Because RAD tools are for GUI toolkits, not for languages. If you're
>using GTK, Glade works fine. Same with QT and QTDesigner. If you're
>using WPF with IronPython, t

These [Glade, etc...] are *NOT* RAD tools.  They are GUI designers.  A
RAD tool provides a GUI designer that can be bound to a backend
[typically an SQL database].  RAD = GUI + ORM.

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

#9232

On 11 Jul, 02:43, Adam Tauno Williams <awill...@whitemice.org> wrote:
> >Because RAD tools are for GUI toolkits, not for languages. If you're
> >using GTK, Glade works fine. Same with QT and QTDesigner. If you're
> >using WPF with IronPython, t
>
> These [Glade, etc...] are *NOT* RAD tools.  They are GUI designers.  A
> RAD tool provides a GUI designer that can be bound to a backend
> [typically an SQL database].  RAD = GUI + ORM.

The type speciemens for "RAD tools" were Borland Delphi and Microsoft
Visual Basic.

They were not a combination of GUI designer and SQL/ORM backend.

They were a combination of GUI designer, code editor, compiler, and
debugger.


Sturla

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

#9213

As someone who was a Visual Studio user for many years, I felt much
the same way you do when I made the jump to Python on Linux last year.
But then I discovered Glade and am quite satisfied.

Glades UI design paradigm is a little different than that of VS but
it's not so hard that you couldn't learn it in a week. It's very
usable, pretty easy to learn, and doesn't cost you a penny.

If you've not already, I recommend you check out Glade. I think it's
probably what you're looking for.

Anthony

On 7/10/11, Ivan Kljaic <ikljaic@gmail.com> wrote:
> Ok Guys. I know that most of us have been expiriencing the need for a
> nice Gui builder tool for RAD and most of us have been googling for it
> a lot of times. But seriously. Why is the not even one single RAD tool
> for Python. I mean what happened to boa constructor that it stopped
> developing. I simply do not see any reasons why there isn't anything.
> Please help me understand it. Any insights?
> --
> http://mail.python.org/mailman/listinfo/python-list
>


-- 
Anthony Papillion
Advanced Data Concepts
Get real about your software/web development and IT Services
Phone: (918) 919-4624

Does your business need to reduce its phone bill? I can help!
Email me and ask me how!

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

#9233

On 11 Jul, 00:50, Ivan Kljaic <iklj...@gmail.com> wrote:
> Ok Guys. I know that most of us have been expiriencing the need for a
> nice Gui builder tool for RAD and most of us have been googling for it
> a lot of times. But seriously. Why is the not even one single RAD tool
> for Python. I mean what happened to boa constructor that it stopped
> developing. I simply do not see any reasons why there isn't anything.
> Please help me understand it. Any insights?

If you by "RAD tool" mean "GUI builder", I'd recommend wxFormBuilder
for wxPython, QtCreator for PyQt or PySide, and GLADE for PyGTK.

Personally I prefer wxFormBuilder and wxPython, but it's a matter of
taste.

Sturla

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web