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 1 of 3  [1] 2 3  Next page →

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

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?

[toc] | [next] | [standalone]

#9198

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

Excerpts from Ivan Kljaic's message of Sun Jul 10 18:50:31 -0400 2011:
> 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?

What is RAD? If you're just looking for a GUI builder there's Glade for
gtk, wxGlade for wxWidgets, QtCreator (And something new for their newer
system, don't remember the name), etc.
-- 
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
     -- Abraham Lincoln

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

#9203

On Jul 10, 6:50 pm, 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?

Just because Boa Constructor stopped (or lengthily paused?)
development
doesn't mean it doesn't exist.  It does, and (at least on Windows), it
is, IMO, really good.  So why don't you use it?

Che

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

#9211

On Sun, 2011-07-10 at 15:50 -0700, Ivan Kljaic 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?

I've pondered this myself, for a long time - since I could use RAD to
build very nice applications using Borland's OWL on Windows For
Workgroups.... it is sad.

But Open Source land is simply too fragmented.  There are too many
database bindings [and RAD requires something like an ORM (think
SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list
goes on and on].

Nothing can muster the gravity required to bring a quality RAD tool into
existence.

I also suspect - seeing some of the articles that float across the
FLOSS-o-sphere mentioning "RAD" - that many Open Source developers have
never had the pleasure [yes, it is a pleasure] of using a professional
RAD tool.

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

#9235

On Jul 11, 2:42 am, Adam Tauno Williams <awill...@whitemice.org>
wrote:
>
> But Open Source land is simply too fragmented.  There are too many
> database bindings [and RAD requires something like an ORM (think
> SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list
> goes on and on].
>
> Nothing can muster the gravity required to bring a quality RAD tool into
> existence.

Why "too many" ? Natural selection is a GoodThing.

Python is known as "the language with more web frameworks than
keywords", and this doesn't prevent some of these frameworks to be 1/
pretty good and 2/ becoming de facto standards.

> I also suspect - seeing some of the articles that float across the
> FLOSS-o-sphere mentioning "RAD" - that many Open Source developers have
> never had the pleasure [yes, it is a pleasure] of using a professional
> RAD tool.

This is slightly arrogant. Did you occur to you that quite a few OSS
developers may have at least as much experience as you do with these
kind of tools and just happen to actually prefer the unix way of doing
things ?

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

#9236

"bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> writes:

> On Jul 11, 2:42 am, Adam Tauno Williams <awill...@whitemice.org>
> wrote:
> >
> > But Open Source land is simply too fragmented.  There are too many
> > database bindings [and RAD requires something like an ORM (think
> > SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list
> > goes on and on].
>
> Why "too many" ? Natural selection is a GoodThing.

Natural selection is not a good thing. It is blind and unthinking and
cruel and wasteful and haphazard and purposeless. Those aren't traits to
recommend it, IMO.

(It's also not a bad thing. Natural selection just is.)

Natural selection is not what's happening here. Rather, *artifical*
selection, with people as the agents of selection, have purposes and
wants that guide their selections.

It would be better to say: Competition can be (not an unalloyed “is”) a
Good Thing.

> Python is known as "the language with more web frameworks than
> keywords", and this doesn't prevent some of these frameworks to be 1/
> pretty good and 2/ becoming de facto standards.

Right. People are selecting web frameworks for their fitness to
purposes, but their purposes are many and change over time. So there can
be many such frameworks, of varying popularity, and that's a good thing.

> > I also suspect - seeing some of the articles that float across the
> > FLOSS-o-sphere mentioning "RAD" - that many Open Source developers
> > have never had the pleasure [yes, it is a pleasure] of using a
> > professional RAD tool.
>
> This is slightly arrogant. Did you occur to you that quite a few OSS
> developers may have at least as much experience as you do with these
> kind of tools and just happen to actually prefer the unix way of doing
> things ?

Yes. As someone who has used some of those all-in-one one-size-fits-most
tools, I can testify that their usefulness is severely limited when
compared with the Unix model.

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.

-- 
 \           “Are you pondering what I'm pondering?” “Umm, I think so, |
  `\    Brain, but what if the chicken won't wear the nylons?” —_Pinky |
_o__)                                                   and The Brain_ |
Ben Finney

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

#9238

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.

There is also a deep anxiety of using the keyboard. This means that
command line tools are out of the question (everything needs a GUI).

In the Windows world, even programming should be drag-and-drop with
the mouse. Windows programmers will go to extreme measures to avoid
typing code on their own, as tke keyboard is so scary. The most
extreme case is not Visual Basic but LabView, where even business
logic is drag-and-drop.

A side-effect is that many Windows developers are too dumb to write
code on their own, and rely on pre-coded "components" that can be
dropped on a "form". A common fail-case is multiuser applications,
where the developers do not understand anything about what is going
on, and scalability is non-existent.

Sturla

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

#9241

* 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.

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.

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

Thorsten

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

#9243

On 11 Jul, 16:10, Thorsten Kampe <thors...@thorstenkampe.de> wrote:

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

You are probably aware that Unix and Unix customers have been around
since the 1970s. I would expect the paradigm to be changed by now.


S.M.

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

#9247

* sturlamolden (Mon, 11 Jul 2011 07:21:37 -0700 (PDT))
> On 11 Jul, 16:10, Thorsten Kampe <thors...@thorstenkampe.de> wrote:
> > And as soon as developers start developing for Unix customers (say
> > Komodo, for instance), they start following the "Windows model" - as
> > you call it.
> 
> You are probably aware that Unix and Unix customers have been around
> since the 1970s. I would expect the paradigm to be changed by now.

For the /customers/ on Unix it never was a paradigm. They would have 
laughed in their vendor's face if they had gotten the "here are the 
tools, just make them work together as you like" attitude[1].

Thorsten
[1] at least starting from the beginning of the nineties when commercial 
alternatives to Unix began to emerge

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

#9248

On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden <sturlamolden@yahoo.no> wrote:
> You are probably aware that Unix and Unix customers have been around
> since the 1970s. I would expect the paradigm to be changed by now.
>

The paradigm of small tools that do exactly what they're supposed to,
and can be combined? Nope. There's still a philosophy of services that
fit together like a jigsaw puzzle, rather than expecting each
application to do everything you want it to. A standard Unix command
line might consist of three or more tools, piping from one into
another - grep the Apache log for lines containing the name of a PHP
script, pipe that into awk to pick up just the user name, IP address,
and date (without time), then pipe into uniq (deliberately without
first going through sort) to show who's been using the script lately.
And then piped it through sed to clean up the format a bit. Yep,
that's something I did recently.

Point to note: This is the Unix *philosophy* versus the Windows
*philosophy*, not Unix *programs* versus Windows *programs*. There are
Windows programs that follow the Unix philosophy.

ChrisA

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

#9261

On Jul 11, 7:39 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden <sturlamol...@yahoo.no> wrote:
> > You are probably aware that Unix and Unix customers have been around
> > since the 1970s. I would expect the paradigm to be changed by now.
>
> The paradigm of small tools that do exactly what they're supposed to,
> and can be combined? Nope. There's still a philosophy of services that
> fit together like a jigsaw puzzle, rather than expecting each
> application to do everything you want it to. A standard Unix command
> line might consist of three or more tools, piping from one into
> another - grep the Apache log for lines containing the name of a PHP
> script, pipe that into awk to pick up just the user name, IP address,
> and date (without time), then pipe into uniq (deliberately without
> first going through sort) to show who's been using the script lately.
> And then piped it through sed to clean up the format a bit. Yep,
> that's something I did recently.
>
> Point to note: This is the Unix *philosophy* versus the Windows
> *philosophy*, not Unix *programs* versus Windows *programs*. There are
> Windows programs that follow the Unix philosophy.
>
> ChrisA


The intention of programming is to close the semantic gap.

-------------
It is a fundamental task of software engineering to close the gap
between application specific knowledge and technically doable
formalization. For this purpose domain specific (high-level) knowledge
must be transferred into an algorithm and its parameters (low-level).

(from http://en.wikipedia.org/wiki/Semantic_gap
-------------

A gui-builder reduces the semantic gap by showing a widget when the
programmer things 'widget.'
Banging out hundreds of lines in vi/emacs for the same purpose does a
measurably poorer job.

Note it can reduce but not close.  By choosing fidelity to the gui we
have corresponding less fidelity to the algos and data-structures [And
one may assume that someone even using a gui toolkit wants to do
something with the gui and not just paint the screen]

Still it seems a bit naive to suggest that building a gui by a few
point&clicks is 'windows-model' and banging out hundreds of lines in
vi/emacs is 'unix-model.'  It does disservice to python and to unix.

If a student of mine came and said: Is Python better or Unix? he would
receive a dressing down.
And yet more than one person here seems to think such type-wrong
comparisons are ok.

I find this disturbing...

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

#9267

On Jul 11, 11:33 am, rusi <rustompm...@gmail.com> wrote:

> A gui-builder reduces the semantic gap by showing a widget when the
> programmer things 'widget.'
> Banging out hundreds of lines in vi/emacs for the same purpose does a
> measurably poorer job.

It is very rare to need to "bang out" hundreds of lines of code to
replace a mouse click interface. If properly designed a good API can
compete with a GUI. In far less time than it takes me to scroll down a
list of widgets, pick the appropriate one, drag it across the screen,
tinker with it's absolute position, and set some attributes,  i could
have typed Widget(parent, **kw).geometry(blah, blah) and been done.

> Note it can reduce but not close.  By choosing fidelity to the gui we
> have corresponding less fidelity to the algos and data-structures [And
> one may assume that someone even using a gui toolkit wants to do
> something with the gui and not just paint the screen]

Exactly. For this very reason i have always refused to used any "point-
and-click" GUI builders. I prefer to get up-close and personal with my
code bases. Of course i use high levels of API abstraction for most of
the work, however i already know what is happening in the lower levels
if i need to dive down one tier.

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

#9271

On Tue, Jul 12, 2011 at 2:56 AM, rantingrick <rantingrick@gmail.com> wrote:
> It is very rare to need to "bang out" hundreds of lines of code to
> replace a mouse click interface. If properly designed a good API can
> compete with a GUI. In far less time than it takes me to scroll down a
> list of widgets, pick the appropriate one, drag it across the screen,
> tinker with it's absolute position, and set some attributes,  i could
> have typed Widget(parent, **kw).geometry(blah, blah) and been done.
>

Point to ponder: Human beings tend to memorize names better than
images from long lists. Most widgets have names as well as appearances
(although it's arguable that the appearance is more what the widget
_is_, and the name is somewhat arbitrary), although in some cases
there's odd pairings - some toolkits merge Radio Button and Check
Box/Button into a single object, others call them two different
things.

To find the widget you need, you must either scroll a long list and
pick the one you want, or key in - possibly with autocompletion
assistance - the name. Which is easier to memorize? Which is easier to
explain? I'd always rather work with the name. And even with the most
point-and-clicky of interface designers, it's normal to be able to see
the names of the objects you're working with.

The one time where point and click is majorly superior to scripted
design is with pixel positioning of widgets. You can drag things
around until you're artistically happy with them, rather than have to
fiddle with the numbers in code. That's how I learned to code GUIs,
but when I started doing cross-platform work and discovered rule-based
layouts (where you put objects in boxes and lay out the boxes in
order, etc), suddenly life got a LOT easier.

ChrisA

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

#9274

On Jul 11, 1:03 pm, Chris Angelico <ros...@gmail.com> wrote:
>
> The one time where point and click is majorly superior to scripted
> design is with pixel positioning of widgets. You can drag things
> around until you're artistically happy with them, rather than have to
> fiddle with the numbers in code.

This is true mostly for the new user of a GUI library or anyone
unlucky enough to use a poorly designed API(which leads into my next
response)

> That's how I learned to code GUIs,
> but when I started doing cross-platform work and discovered rule-based
> layouts (where you put objects in boxes and lay out the boxes in
> order, etc), suddenly life got a LOT easier.

A bit tangential however still relevant... i had always considered
Tkinter's three geometry managers (pack, place, and grid) to be
perfect. However lately i have been musing on the idea of rewriting
the pack API into something more intuitive like a "linear-box-style"
which then manifests itself in two forms; horizontal and vertical.

Of course you can create horizontal and vertical layouts ALREADY by
passing the side=LEFT or side=RIGHT to the pack geometry manager of
Tkinter widgets (TOP being the default BTW) but that fact isn't always
apparent to the new user as the full set of options are side={TOP|
BOTTOM|LEFT|RIGHT}.

And besides, the current API allows you to pack in all sorts of
ridiculous manners; BOTTOM, then TOP, then LEFT, then TOP, then RIGHT,
then TOP, then LEFT, then RIGHT, THEN GHEE WHIZ! Are you trying to win
the obfuscation award of the year here lad?

As we all know you only need three types of geometry management:
 * Linear (horizontal&vertical)
 * Grid
 * Absolute

Anything else is just multiplicity run a muck, again! And by
propagating such API's we also induce ignorance into our ranks. Before
we EVER consider a Python4000 we really need to clean up this
atrocious stdlib! It's like i tell people: when you keep screwing your
customers over then very soon you'll be out of buisness. Sure you can
make a decent living for a short time but the whole house of cards
comes crumbling down without the core base of repeat customers.

</food for thought>

PS: I noticed that Python.org has a suggestion box now for which
modules we should be concentrating our community efforts. Well like
they say... "imitation is the greatest form of flattery". And i am
quite flattered.

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

#9280

On Tue, Jul 12, 2011 at 4:52 AM, rantingrick <rantingrick@gmail.com> wrote:
> As we all know you only need three types of geometry management:
>  * Linear (horizontal&vertical)
>  * Grid
>  * Absolute
>

I contend that Absolute is unnecessary and potentially dangerous. Grid
and Box (linear) are the most flexible, but there are others that come
in handy too. GTK has quite a few [1] including a scrollable, a
notebook, hor/vert panes (where the user can adjust the size between
the two panes), and so on.

Once again, Ranting Rick is asking for all tools to be destroyed
except his preferred minimal set. I think this strongly suggests that
Rick is, in point of fact, either brain something'd (keeping this
G-rated) or an orangutan, because the ultimate end of his logic is
coding in either Brain-*[2] or Ook [3].

ChrisA

[1] http://developer.gnome.org/gtk3/stable/LayoutContainers.html
[2] http://www.muppetlabs.com/~breadbox/bf/
[3] http://www.dangermouse.net/esoteric/ook.html

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

#9296

Chris Angelico wrote:
> either brain something'd (keeping this
> G-rated) or an orangutan,

There's a certain librarian who might take issue with your
lumping orangutans in with the brain-something'd...

-- 
Greg

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

#9272

Ok. I asked about this questio because I am working with python for
the last 5 years and I am always in touch about signifigact things in
Python. I am pissed of that I make my living by developing
applications at work in Java an C#. 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. If you are going
to say that there are also other libraries with every single one there
is a significant problem that make the development painfull.

About the natural selection... I'll say it with the words of
penn&teller:bullshit
For how many years are this vui library wars going on. How many. Look.
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.
Just imagine what we would have today if the effort of development
would have been used to develop one really good library. We would have
kicked the ass of MS and steve balmer. The average user wants
something simple and not something to program to do something. It
looks that the firs linux os to realize that is successfull. I am
talking about android.

And the python development team is doing nothing to improve the
situatio to solve this dispute that lasts for the last years by
including the worthless Tk library and now upgrading it with Tix.

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. If it would only be maintained and
the libraby updated it would be great. When it comes to other
application, sorry but they are just bad. Their userfriendlyness is
simmilar to most of Ms products, they are "user friendly" but the
problem is that they very wisely chose their friends.

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. Sorry guys but there is not even one
single rad gui tool for python as long as there is no serious
guibuilder.

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

#9277

On Tue, Jul 12, 2011 at 4:28 AM, Ivan Kljaic <ikljaic@gmail.com> wrote:
> For how many years are this vui library wars going on. How many. Look.
> 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.

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. The difference
is that in the open-source world, everything survives and can be seen
as a set of alternatives, whereas in the closed-source world, it's
either different versions of one program (like MS Office), or
competing products (which usually means one of them dies for lack of
money - or is bought out by the other).

What we have is not indecision, it is options. Imagine if you went to
a hardware shop and were offered only one tool: a magnet. Would you
laud them for making a decision and sticking with it? No, you'd wonder
what they have against hammers and screwdrivers. I like to have tools
available to my use, not someone else making my decisions for me.

There's competition in the open source world, too; primarily
competition for developer time, a quite scarce resource. If a toolkit
is not of value to people, it won't get as many dev hours,  so you can
often gauge popularity and usefulness by the VCS checkins.

ChrisA

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

#9278

On Jul 11, 1:28 pm, 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.

Well don't hold your breath friend because i have been ranting for
years about the sad state of GUI libraries (not just in Python but
everywhere). However if somehow "we" (the Python community) could grow
a collective brain and build the three tiered system (that i proposed
on THIS very list!) then we would have something that no one has! Yes,
we would have a future!

 * Layer1: A 3rd party low level GUI library (owned by the python
community) that will be the base from which to build the cake.  A Gui
library that carries the torch of true 21st century GUI's look and
feel, and widgets! (aka: lots of C code here).

 * Layer2: An abstraction of Layer1 (written in 100% python) for the
python std library. (think "PythonGUI")

 * Layer3: A Graphical GUI builder front end for this expansive and
beautiful library (so the kids can play along too).

Yes, i DID mention a Graphical Builder. Even though i'd never use one,
i DO realize the importance of such tools to this community.

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

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

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

csiph-web