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

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

Everything good about Python except GUI IDE?

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

Contents

  Everything good about Python except GUI IDE? wrong.address.1@gmail.com - 2016-02-27 03:18 -0800
    Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-27 22:36 +1100
    Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-27 04:02 -0800
    Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-27 23:07 +1100
      Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-28 17:34 +1100
        Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-27 23:39 -0800
          Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 19:49 +1100
        Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 19:44 +1100
          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 02:25 -0800
            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 21:34 +1100
              Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 00:08 +1100
                Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:13 -0800
                  Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 00:24 +1100
                    Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:49 -0800
                      Re: Everything good about Python except GUI IDE? Chris Warrick <kwpolska@gmail.com> - 2016-02-28 15:00 +0100
                        Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 06:11 -0800
                          Re: Everything good about Python except GUI IDE? Chris Warrick <kwpolska@gmail.com> - 2016-02-28 15:26 +0100
                            Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 08:50 -0800
                            Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:39 +1100
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 11:54 +1100
                              Re: Everything good about Python except GUI IDE? Ben Finney <ben+python@benfinney.id.au> - 2016-02-29 12:05 +1100
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 12:13 +1100
                              Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 17:39 -0800
                                Re: Lineendings (was Everything good about Python except GUI IDE?) Chris Angelico <rosuav@gmail.com> - 2016-02-29 12:49 +1100
                                  Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 17:55 -0800
                                    Re: Lineendings (was Everything good about Python except GUI IDE?) Chris Angelico <rosuav@gmail.com> - 2016-02-29 13:02 +1100
                                      Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 18:08 -0800
                                        Re: Lineendings (was Everything good about Python except GUI IDE?) Ben Finney <ben+python@benfinney.id.au> - 2016-02-29 13:35 +1100
                                          Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 20:48 -0800
                      Re: Everything good about Python except GUI IDE? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-28 17:09 +0000
                  Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 11:56 -0500
                    Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-03-02 20:44 +1100
          Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-28 23:50 +1100
            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 04:53 +1100
              Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 13:22 +1100
                Re: Everything good about Python except GUI IDE? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-02-29 17:40 +1300
        Re: Everything good about Python except GUI IDE? "Sven R. Kunze" <srkunze@mail.de> - 2016-02-28 13:23 +0100
        Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 12:38 +0000
          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 04:54 -0800
            Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 13:07 +0000
              Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:20 -0800
                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 15:51 +0200
                  Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 06:03 -0800
                    Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 14:29 +0000
                      Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:49 +1100
                        Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-29 11:56 +0000
                      Re: Everything good about Python except GUI IDE? Terry Reedy <tjreedy@udel.edu> - 2016-02-28 19:49 -0500
                    Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 17:08 +0200
                      Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 08:41 -0800
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 23:38 +0200
                      Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 15:47 +1100
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 08:18 +0200
                          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 23:20 -0800
                            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 19:20 +1100
                              Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:37 +0200
                              Re: Everything good about Python except GUI IDE? Grant Edwards <invalid@invalid.invalid> - 2016-02-29 15:43 +0000
                                Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 03:17 +1100
                                  Re: Everything good about Python except GUI IDE? Grant Edwards <invalid@invalid.invalid> - 2016-02-29 18:17 +0000
                                    Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 05:31 +1100
                            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:25 +0200
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 19:33 +1100
                                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:46 +0200
                                Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 03:44 +1100
                                  Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 05:07 +1100
                                    Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 13:22 +1100
                                      Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:05 +1100
                                        Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Chris Angelico <rosuav@gmail.com> - 2016-03-03 04:46 +1100
                                          Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-02 18:29 +0000
                                            Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Chris Angelico <rosuav@gmail.com> - 2016-03-03 07:55 +1100
                                              Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-02 22:01 +0000
                            Re: Everything good about Python except GUI IDE? Terry Reedy <tjreedy@udel.edu> - 2016-02-29 21:33 -0500
                            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 15:31 +1100
                          Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-03-02 20:44 +1100
                            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 13:57 +0200
                  Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:14 +1100
              Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 12:08 -0500
          Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 03:35 +1100
            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-01 20:06 +0200
              Re: Everything good about Python except GUI IDE? wxjmfauth@gmail.com - 2016-03-01 11:30 -0800
                Re: Everything good about Python except GUI IDE? wxjmfauth@gmail.com - 2016-03-01 11:39 -0800
              Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 12:51 +1100
                Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 13:15 +1100
                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 07:41 +0200
                  Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 16:58 +1100
                    Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 10:20 +0200
                      Re: Everything good about Python except GUI IDE? Christian Gollwitzer <auriocus@gmx.de> - 2016-03-02 23:00 +0100
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 00:36 +0200
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 13:38 +0100
          Re: Everything good about Python except GUI IDE? cl@isbd.net - 2016-02-28 12:52 +0000
            Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 14:19 +0100
        Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 12:03 -0500
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 18:41 +0100
    Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-27 13:35 +0000
    Re: Everything good about Python except GUI IDE? MWS <miragewebstudio12@gmail.com> - 2016-02-27 20:05 +0530
    Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-27 15:20 +0100
      Re: Everything good about Python except GUI IDE? wrong.address.1@gmail.com - 2016-02-27 10:13 -0800
        Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 05:29 +1100
        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-27 20:35 +0200
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-27 19:51 +0100
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 00:20 +0100
        Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-28 16:49 +1100
        Re: Everything good about Python except GUI IDE? Sibylle Koczian <nulla.epistola@web.de> - 2016-02-28 11:46 +0100
        Re: Everything good about Python except GUI IDE? Virgil Stokes <vs@it.uu.se> - 2016-02-28 12:26 +0100
        Re: Everything good about Python except GUI IDE? Sibylle Koczian <nulla.epistola@web.de> - 2016-02-28 11:46 +0100
        Re: Everything good about Python except GUI IDE? mm0fmf <none@invalid.com> - 2016-02-28 18:47 +0000
          Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 20:09 +0100
        Re: Everything good about Python except GUI IDE? Michael Torrie <torriem@gmail.com> - 2016-02-28 18:24 -0700
        Re: Everything good about Python except GUI IDE? Mike S <mscir@yahoo.com> - 2016-03-02 23:27 -0800
    Re: Everything good about Python except GUI IDE? Marco Kaulea <marco.kaulea@gmail.com> - 2016-02-27 18:57 +0100
    Re: Everything good about Python except GUI IDE? Anthony Papillion <anthony@cajuntechie.org> - 2016-02-27 13:45 -0600
    Re: Everything good about Python except GUI IDE? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-27 20:52 +0000
    Re: Everything good about Python except GUI IDE? MRAB <python@mrabarnett.plus.com> - 2016-02-27 21:35 +0000
    Re: Everything good about Python except GUI IDE? Mike <termim@gmail.com> - 2016-03-01 19:46 -0800

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#103575 — Everything good about Python except GUI IDE?

I have some VB forms with more than a hundred objects. If I cannot drag and drop text boxes, list boxes, labels, etc., it will be too much work to create that with several lines of code for each object. 

Isn't there any good GUI IDE like Visual Basic? I hope there are some less well known GUI IDEs which I did not come across. Thanks.

[toc] | [next] | [standalone]

#103577

On Sat, 27 Feb 2016 10:18 pm, wrong.address.1@gmail.com wrote:

> I have some VB forms with more than a hundred objects.


https://www.appnovation.com/sites/default/files/attachments/yourproduct.jpg

Your users probably hate you... 

*wink*



-- 
Steven

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

#103580

On Saturday, February 27, 2016 at 4:49:21 PM UTC+5:30, wrong.a...@gmail.com wrote:
> I have some VB forms with more than a hundred objects. If I cannot drag and drop text boxes, list boxes, labels, etc., it will be too much work to create that with several lines of code for each object. 
> 
> Isn't there any good GUI IDE like Visual Basic? I hope there are some less well known GUI IDEs which I did not come across. Thanks.

Good... I do not know [Do not know much of the area]

However there is glade, qtdesigner, wxglade for gtk, qt and wx.

How full-featured/bug-free etc I cannot say.

If you find that they just dont match up to what windows has on offer, I 
wont be surprised :-(

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

#103581

On Sat, Feb 27, 2016 at 10:18 PM,  <wrong.address.1@gmail.com> wrote:
> I have some VB forms with more than a hundred objects. If I cannot drag and drop text boxes, list boxes, labels, etc., it will be too much work to create that with several lines of code for each object.
>
> Isn't there any good GUI IDE like Visual Basic? I hope there are some less well known GUI IDEs which I did not come across. Thanks.

Sounds like the advantage lies with Python here...

Don't make a UI by dragging and dropping that many widgets.

If it takes "several lines of code" for each object, it might be worth
creating a utility function. For example, a database form might
include a good number of fields with associated labels; you could
create a function that creates (in a single line) a label and its
input field. Or create a list and iterate over it, creating all the
widgets as you step through the loop. That's the advantage of code -
you can't easily create reusable 'clumps' with a drag-and-drop
builder, but in code, it's the exact same thing as any other form of
code reuse.

ChrisA

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

#103614

On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:

>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
>> less well known GUI IDEs which I did not come across. Thanks.
> 
> Sounds like the advantage lies with Python here...
> 
> Don't make a UI by dragging and dropping that many widgets.


And later, in another post:

> the best way to build a cross-platform GUI is code, not drag-and-drop.


I think that's out-and-out wrong, and harmful to the developer community. I
think that we're stuck in the equivalent of the pre-WYSIWYG days of word
processing: you can format documents as nicely as you like, but you have to
use a separate mode to see it.

Drag-and-drop GUI builders have the same advantages over code as Python has
over languages with distinct compile/execute steps: rapid development,
prototyping, exploration and discovery. Of course, any decent modern
builder won't limit you to literally drag-and-drop, but will offer
functionality like duplicating elements, aligning them, magnetic guides,
etc.

GUI elements are by definition graphical in nature, and like other graphical
elements, manipulation by hand is superior to command-based manipulation.
Graphical interfaces for manipulating graphics have won the UI war so
effectively that some people have forgotten there ever was a war. Can you
imagine using Photoshop without drag and drop?

And yet programming those graphical interfaces is an exception. There, with
very few exceptions, we still *require* a command interface. Not just a
command interface, but an *off-line* command interface, where you batch up
all your commands then run them at once, as if we were Neanderthals living
in a cave.

An effective and modern GUI builder UI should be programmable without
requiring programming. About thirty years ago Apple came up with the ideal
mix of graphical and programmatic development for its Hypercard product.
You built applications by dragging and dropping widgets on the screen, or
by copying and pasting them from a library of pre-made widgets. 

(By 2016 standards the UI of Hypercard would seem a bit old fashioned and
primitive -- black and white, bitmapped graphics, no magnetic guides
or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder
wouldn't have those limitations.)

Hypercard let you create a place widgets by hand using the mouse, or by
running a one-line command in the "Message Box" (a simple command
interpreter), and for complex tasks, or by writing a script and executing
it. You didn't have to script the *entire* application, just as much or as
little as needed scripting.

Python would be especially well-suited to this, being an interpreter. Why
should I have to batch up all the GUI elements and run them all at once to
see what my application looks like? Why can't I add elements interactively?

I've made a number of attempts to get into GUI development in Python, and
every time I flounder at the lousy state of the art in GUI builder tools.
Yes, the widget set is fantastic. But putting the GUIs together is
primitive beyond words.

Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it
lives on in the guise of LiveCode:

http://livecode.com/


If only I could get the Linux installer to actually, you know, *work*.


-- 
Steven

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

#103615

On Sunday, February 28, 2016 at 12:04:52 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
> 
> >> Isn't there any good GUI IDE like Visual Basic? I hope there are some
> >> less well known GUI IDEs which I did not come across. Thanks.
> > 
> > Sounds like the advantage lies with Python here...
> > 
> > Don't make a UI by dragging and dropping that many widgets.
> 
> 
> And later, in another post:
> 
> > the best way to build a cross-platform GUI is code, not drag-and-drop.
> 
> 
> I think that's out-and-out wrong, and harmful to the developer community. I
> think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> processing: you can format documents as nicely as you like, but you have to
> use a separate mode to see it.
> 
> Drag-and-drop GUI builders have the same advantages over code as Python has
> over languages with distinct compile/execute steps: rapid development,
> prototyping, exploration and discovery. Of course, any decent modern
> builder won't limit you to literally drag-and-drop, but will offer
> functionality like duplicating elements, aligning them, magnetic guides,
> etc.
> 
> GUI elements are by definition graphical in nature, and like other graphical
> elements, manipulation by hand is superior to command-based manipulation.
> Graphical interfaces for manipulating graphics have won the UI war so
> effectively that some people have forgotten there ever was a war. Can you
> imagine using Photoshop without drag and drop?
> 
> And yet programming those graphical interfaces is an exception. There, with
> very few exceptions, we still *require* a command interface. Not just a
> command interface, but an *off-line* command interface, where you batch up
> all your commands then run them at once, as if we were Neanderthals living
> in a cave.
> 
> An effective and modern GUI builder UI should be programmable without
> requiring programming. About thirty years ago Apple came up with the ideal
> mix of graphical and programmatic development for its Hypercard product.
> You built applications by dragging and dropping widgets on the screen, or
> by copying and pasting them from a library of pre-made widgets. 
> 
> (By 2016 standards the UI of Hypercard would seem a bit old fashioned and
> primitive -- black and white, bitmapped graphics, no magnetic guides
> or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder
> wouldn't have those limitations.)
> 
> Hypercard let you create a place widgets by hand using the mouse, or by
> running a one-line command in the "Message Box" (a simple command
> interpreter), and for complex tasks, or by writing a script and executing
> it. You didn't have to script the *entire* application, just as much or as
> little as needed scripting.
> 
> Python would be especially well-suited to this, being an interpreter. Why
> should I have to batch up all the GUI elements and run them all at once to
> see what my application looks like? Why can't I add elements interactively?
> 
> I've made a number of attempts to get into GUI development in Python, and
> every time I flounder at the lousy state of the art in GUI builder tools.
> Yes, the widget set is fantastic. But putting the GUIs together is
> primitive beyond words.
> 
> Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it
> lives on in the guise of LiveCode:
> 
> http://livecode.com/
> 
> 
> If only I could get the Linux installer to actually, you know, *work*.
> 
> 
> -- 
> Steven


A sensible view
And more helpful than pretending that neanderthal == civilized

Chris: Is it easier to work out the best-lookkng colors with a color picker or 
with hacking through a million #rrggbb combos?

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

#103618

On Sun, Feb 28, 2016 at 6:39 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> A sensible view
> And more helpful than pretending that neanderthal == civilized
>
> Chris: Is it easier to work out the best-lookkng colors with a color picker or
> with hacking through a million #rrggbb combos?

Given that "best-looking" is a vague thing that requires a human eye,
the easiest way is to try it, in real-time. Whether you see the
#rrggbb or drag something with the mouse doesn't matter. But this is
an example (single color selection) that is dead simple; whether you
use a picker or explicit RGB, you're still picking up 24 bits of
information that can be comfortably represented in six characters
(seven if you count the hash as part of it). If you mess something up,
you hit Ctrl-Z and go back to the previous color. When it's more
complicated (say, when you're overlaying multiple brushes in multiple
colors), the cost of having a non-textual representation becomes more
serious.

ChrisA

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

#103617

On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
>
>>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
>>> less well known GUI IDEs which I did not come across. Thanks.
>>
>> Sounds like the advantage lies with Python here...
>>
>> Don't make a UI by dragging and dropping that many widgets.
>
>
> And later, in another post:
>
>> the best way to build a cross-platform GUI is code, not drag-and-drop.
>
>
> I think that's out-and-out wrong, and harmful to the developer community. I
> think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> processing: you can format documents as nicely as you like, but you have to
> use a separate mode to see it.
>
> Drag-and-drop GUI builders have the same advantages over code as Python has
> over languages with distinct compile/execute steps: rapid development,
> prototyping, exploration and discovery. Of course, any decent modern
> builder won't limit you to literally drag-and-drop, but will offer
> functionality like duplicating elements, aligning them, magnetic guides,
> etc.

Alright, but how do you go about doing, with a drag-and-drop builder,
all those things we're used to with code - composing new named actions
out of primitives, observing the changes to a program through source
control, unit testing (maybe), and code review? The only way I know of
to build a "function" in a DnD builder is to create a composite widget
(eg "horizontal box containing label and entry field"), which is
extremely useful, but limited - it's like saying that the only way to
reuse code is single-inheritance. How would you create a higher-order
operation in a DnD builder? How would you write something that does
some sort of sweep over a set of widgets and does the same thing to
them?

All these sorts of things are possible... but we're getting right back
to code again. People have tried to create graphical code builders for
decades; they've never been sufficient. Code - textual commands to
manipulate a system - is still the most powerful and flexible way to
do things.

By the way, you'll notice that I said "dragging and dropping **that
many** widgets" (emphasis added). GUI builders can be great for simple
jobs, and a really awesome one can work well for more complex jobs
too, but the asymptotic complexity of using drag and drop is worse
than that of code.

> GUI elements are by definition graphical in nature, and like other graphical
> elements, manipulation by hand is superior to command-based manipulation.
> Graphical interfaces for manipulating graphics have won the UI war so
> effectively that some people have forgotten there ever was a war. Can you
> imagine using Photoshop without drag and drop?

No, I can't. But I also can't imagine git-managing Photoshop files,
and IMO, that is a serious loss. Would you accept a programming
language that forced all files to be edited by a single person?
Collaboration is pretty important these days. How would you review
edits to approve/deny them if you can't see what was edited?

> And yet programming those graphical interfaces is an exception. There, with
> very few exceptions, we still *require* a command interface. Not just a
> command interface, but an *off-line* command interface, where you batch up
> all your commands then run them at once, as if we were Neanderthals living
> in a cave.

I think there's room to improve the textual interface without throwing
it away. Certainly several of the Python toolkits are quite primitive
in their style; everything has to be executed imperatively, with no
room to build a layout declaratively. But thanks to the flexibility of
code, this is a very real possibility. Nobody can usefully *extend*
the VB UI builder except its owner; anybody can write a function that
simplifies one small part of code generation.

Python's existing APIs definitely need some work, but I've used some
other systems that were closer. Imagine something like this:

win = gtk.Window(
    title="Demo Window",
    transient_for=mainwindow,
    child=gtk.labelled(["User name", "Email", "Password", "Confirm",
gtk.okbtn()]),
)

For more complicated work, build up new primitives and keep right on
going. Do it right, and you should be able to have live editing with a
preview window, and *maybe* even some kind of manipulation tool,
although I'm not sure how best to do that.

This doesn't have to be a dichotomy.

ChrisA

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

#103622

On Sunday, February 28, 2016 at 2:15:10 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano wrote:
> > On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
> >
> >>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
> >>> less well known GUI IDEs which I did not come across. Thanks.
> >>
> >> Sounds like the advantage lies with Python here...
> >>
> >> Don't make a UI by dragging and dropping that many widgets.
> >
> >
> > And later, in another post:
> >
> >> the best way to build a cross-platform GUI is code, not drag-and-drop.
> >
> >
> > I think that's out-and-out wrong, and harmful to the developer community. I
> > think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> > processing: you can format documents as nicely as you like, but you have to
> > use a separate mode to see it.
> >
> > Drag-and-drop GUI builders have the same advantages over code as Python has
> > over languages with distinct compile/execute steps: rapid development,
> > prototyping, exploration and discovery. Of course, any decent modern
> > builder won't limit you to literally drag-and-drop, but will offer
> > functionality like duplicating elements, aligning them, magnetic guides,
> > etc.
> 
> Alright, but how do you go about doing, with a drag-and-drop builder,
> all those things we're used to with code - composing new named actions
> out of primitives, observing the changes to a program through source
> control, unit testing (maybe), and code review? The only way I know of
> to build a "function" in a DnD builder is to create a composite widget
> (eg "horizontal box containing label and entry field"), which is
> extremely useful, but limited - it's like saying that the only way to
> reuse code is single-inheritance. How would you create a higher-order
> operation in a DnD builder? How would you write something that does
> some sort of sweep over a set of widgets and does the same thing to
> them?


Alright...
I can handcraft better assembly than gcc generates. Shall I ditch gcc for assembly?
And I can work out more sophisticated memory mgmt and other algos with C than 
with python (vide Steven's recent thread on delimiter-reading),
Shall we prefer C over python?

Moore's law dictates that "penny-wise, pound-foolish" gets multiplied by an
exponential curve and the 'really-wise' puts up with a low(er) level mess for
a higher level good.

Sure the well handcrafted gui code will be smaller, neater, faster, what-have-u
than builder=generated code. So what?
The only reasonable answer is the corollary to Moore's law:
The (differential) cost of programmer-time increases exponentially

> 
> All these sorts of things are possible... but we're getting right back
> to code again. People have tried to create graphical code builders for
> decades; they've never been sufficient. Code - textual commands to
> manipulate a system - is still the most powerful and flexible way to
> do things.
> 
> By the way, you'll notice that I said "dragging and dropping **that
> many** widgets" (emphasis added). GUI builders can be great for simple
> jobs, and a really awesome one can work well for more complex jobs
> too, but the asymptotic complexity of using drag and drop is worse
> than that of code.

Code is always the last resort for arbitrary complexity
Lets keep it the last resort.

If the bottom-line is that python's GUI-builders are so deep into suxland
that they are best avoided in place of hand-written code, thats fine (by me).

Lets please not make a virtue of a lack

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

#103623

On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Code is always the last resort for arbitrary complexity
> Lets keep it the last resort.
>
> If the bottom-line is that python's GUI-builders are so deep into suxland
> that they are best avoided in place of hand-written code, thats fine (by me).
>
> Lets please not make a virtue of a lack

Once someone figures out a way to usefully merge independent changes
(you know, the way source control tools do every single day for code),
maybe I'll consider that. Until then, the last resort is also my first
response.

ChrisA

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

#103634

Chris Angelico <rosuav@gmail.com> wrote:

>On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> Code is always the last resort for arbitrary complexity
>> Lets keep it the last resort.
>>
>> If the bottom-line is that python's GUI-builders are so deep into suxland
>> that they are best avoided in place of hand-written code, thats fine (by me).
>>
>> Lets please not make a virtue of a lack
>
>Once someone figures out a way to usefully merge independent changes
>(you know, the way source control tools do every single day for code),
>maybe I'll consider that. Until then, the last resort is also my first
>response.

Why can't whatever is generated by a GUI form designer be stored in
source control along with all the other project files? The only
restriction would be that everyone who wants to change the UI would
have to use the same form designer.

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

#103635

On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
> Chris Angelico  wrote:
> 
> >On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody wrote:
> >> Code is always the last resort for arbitrary complexity
> >> Lets keep it the last resort.
> >>
> >> If the bottom-line is that python's GUI-builders are so deep into suxland
> >> that they are best avoided in place of hand-written code, thats fine (by me).
> >>
> >> Lets please not make a virtue of a lack
> >
> >Once someone figures out a way to usefully merge independent changes
> >(you know, the way source control tools do every single day for code),
> >maybe I'll consider that. Until then, the last resort is also my first
> >response.
> 
> Why can't whatever is generated by a GUI form designer be stored in
> source control along with all the other project files? The only
> restriction would be that everyone who wants to change the UI would
> have to use the same form designer.

Glade generates XML (last I saw)
XML is text... kinda... but not quite
eg XML is sometimes/somewhere space sensitive, sometimes not
This can generate messy diffs

Best I can see, these are not exactly trivial nor quite impossible to solve problems

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

#103638

Rustom Mody <rustompmody@gmail.com> wrote:

>On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
>> Chris Angelico  wrote:
>> 
>> >On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody wrote:
>> >> Code is always the last resort for arbitrary complexity
>> >> Lets keep it the last resort.
>> >>
>> >> If the bottom-line is that python's GUI-builders are so deep into suxland
>> >> that they are best avoided in place of hand-written code, thats fine (by me).
>> >>
>> >> Lets please not make a virtue of a lack
>> >
>> >Once someone figures out a way to usefully merge independent changes
>> >(you know, the way source control tools do every single day for code),
>> >maybe I'll consider that. Until then, the last resort is also my first
>> >response.
>> 
>> Why can't whatever is generated by a GUI form designer be stored in
>> source control along with all the other project files? The only
>> restriction would be that everyone who wants to change the UI would
>> have to use the same form designer.
>
>Glade generates XML (last I saw)
>XML is text... kinda... but not quite
>eg XML is sometimes/somewhere space sensitive, sometimes not
>This can generate messy diffs

That is also true of Python code but does not preclude effective
source control.
>
>Best I can see, these are not exactly trivial nor quite impossible to solve problems

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

#103639

On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
> Rustom Mody  wrote:
> >Glade generates XML (last I saw)
> >XML is text... kinda... but not quite
> >eg XML is sometimes/somewhere space sensitive, sometimes not
> >This can generate messy diffs
> 
> That is also true of Python code but does not preclude effective
> source control.

Yes as I said its not satisfactory but not impossible to manage

Heck Current state of art VCSes cannot even manage mismatching EOL conventions
cleanly.
And as usual they make a virtue out of the lack: 
"git stores binary data not text"

which means that opening a file created on windows on linux and saving it in 
WITHOUT a SINGLE CHANGE
can give you a 10,000 line diff!!

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

#103641

On 28 February 2016 at 14:49, Rustom Mody <rustompmody@gmail.com> wrote:
> On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
>> Rustom Mody  wrote:
>> >Glade generates XML (last I saw)
>> >XML is text... kinda... but not quite
>> >eg XML is sometimes/somewhere space sensitive, sometimes not
>> >This can generate messy diffs
>>
>> That is also true of Python code but does not preclude effective
>> source control.
>
> Yes as I said its not satisfactory but not impossible to manage
>
> Heck Current state of art VCSes cannot even manage mismatching EOL conventions
> cleanly.
> And as usual they make a virtue out of the lack:
> "git stores binary data not text"
>
> which means that opening a file created on windows on linux and saving it in
> WITHOUT a SINGLE CHANGE
> can give you a 10,000 line diff!!

You clearly haven’t ever done that.

1. git can manage EOL changing if you want to enforce a newline style that way.
2. A good editor can read and write any newline style. It should also
not convert without asking the user.

-- 
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16

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

#103644

On Sunday, February 28, 2016 at 7:30:57 PM UTC+5:30, Chris Warrick wrote:
> On 28 February 2016 at 14:49, Rustom Mody  wrote:
> > On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
> >> Rustom Mody  wrote:
> >> >Glade generates XML (last I saw)
> >> >XML is text... kinda... but not quite
> >> >eg XML is sometimes/somewhere space sensitive, sometimes not
> >> >This can generate messy diffs
> >>
> >> That is also true of Python code but does not preclude effective
> >> source control.
> >
> > Yes as I said its not satisfactory but not impossible to manage
> >
> > Heck Current state of art VCSes cannot even manage mismatching EOL conventions
> > cleanly.
> > And as usual they make a virtue out of the lack:
> > "git stores binary data not text"
> >
> > which means that opening a file created on windows on linux and saving it in
> > WITHOUT a SINGLE CHANGE
> > can give you a 10,000 line diff!!
> 

> 
> 2. A good editor can read and write any newline style. It should also
> not convert without asking the user.

git is a *collaborative* tool and should work when the other party is using
notepad.

> 1. git can manage EOL changing if you want to enforce a newline style that way.
Only out-of-band
You store autocrlf etc in your config not in the repo
[And pray that the other (semi-literate) collaborator does likewise]

> You clearly haven't ever done that.
You specialize in crystal balls?

Here's my report about CRLF issues in CPython
https://mail.python.org/pipermail/python-dev/2015-June/140563.html

Bug report: http://bugs.python.org/issue24507

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

#103645

On 28 February 2016 at 15:11, Rustom Mody <rustompmody@gmail.com> wrote:
> On Sunday, February 28, 2016 at 7:30:57 PM UTC+5:30, Chris Warrick wrote:
>> On 28 February 2016 at 14:49, Rustom Mody  wrote:
>> > On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
>> >> Rustom Mody  wrote:
>> >> >Glade generates XML (last I saw)
>> >> >XML is text... kinda... but not quite
>> >> >eg XML is sometimes/somewhere space sensitive, sometimes not
>> >> >This can generate messy diffs
>> >>
>> >> That is also true of Python code but does not preclude effective
>> >> source control.
>> >
>> > Yes as I said its not satisfactory but not impossible to manage
>> >
>> > Heck Current state of art VCSes cannot even manage mismatching EOL conventions
>> > cleanly.
>> > And as usual they make a virtue out of the lack:
>> > "git stores binary data not text"
>> >
>> > which means that opening a file created on windows on linux and saving it in
>> > WITHOUT a SINGLE CHANGE
>> > can give you a 10,000 line diff!!
>>
>
>>
>> 2. A good editor can read and write any newline style. It should also
>> not convert without asking the user.
>
> git is a *collaborative* tool and should work when the other party is using
> notepad.

What should git do if someone saves, say, Ruby code as a .py file?
Should it rename it? Or should it figure out an equivalent snippet of
Python?

You probably have some rules in your project such as “Code must be
written in Python” or “Use 4-space soft tabs”. Your rulebook should
also include “Use an editor that understands LF line endings”. Notepad
is a joke that you should not tolerate. Problem solved.

(Notepad does not understand LF line endings and replaces them with
boxes. I also don’t think a Notepad user is likely to provide good
contributions, but that’s another thing)

-- 
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16

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

#103649

On Sunday, February 28, 2016 at 7:57:17 PM UTC+5:30, Chris Warrick wrote:
> (Notepad does not understand LF line endings and replaces them with
> boxes. I also don't think a Notepad user is likely to provide good
> contributions, but that's another thing)

You seem to have not worked in a web dev team wherein the frontend guys only know 3 tools

- dreamweaver
- photoshop
- notepad

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

#103665

On Mon, 29 Feb 2016 01:26 am, Chris Warrick wrote:

>> git is a *collaborative* tool and should work when the other party is
>> using notepad.
> 
> What should git do if someone saves, say, Ruby code as a .py file?
> Should it rename it? Or should it figure out an equivalent snippet of
> Python?

Don't be ridiculous. That's completely over the top.

It isn't asking too much for version control systems to *not care* about
line ending changes. Who cares if the file changes from \n to \r \r\n? It
shouldn't matter, or at least, it shouldn't matter much.

> You probably have some rules in your project such as “Code must be
> written in Python” 

In one of my Python projects, I have (as well as various .py files) an R
script and a Gnumeric spreadsheet. In another Python project, I have a
couple of bash scripts. In nearly every one of my repos, I have plain text
files that don't contain Python code. Should the VCS refuse to track them
because they don't contain Python code? Of course not.

If I open a Python file in my editor, accidentally or deliberately change
the content to Ruby code, save and commit, then the VCS obviously should
track the changes because they are actual changes.

But if I open a Python file in my editor, accidentally or deliberately
change the line endings from \n to \r, save and commit, then it is a
weakness and limitation of the current generation of VCSs that they will
treat this as "every line has changed". Or worse, "10,000 lines have
collapsed to a single line containing \r characters".

Changing line endings is neither a structural nor a semantic change to the
content of the file. It's effectively metadata, not data. The Python
interpreter doesn't care which line ending you use. Neither will decent
text editors. If some tools, like git, do, then that's a weakness of git,
not a feature. Changing the permissions on a 10,000 line file doesn't give
you a 10,000 line diff, and neither should changing the line ending.

Your VCS absolutely should track line ending changes. In a perfect world, we
should never care about the line ending, but so long as there are users and
tools that cannot transparently deal with one line ending or another, there
may be times were we do care about line endings, and therefore want to
run "git blame" to find out which idiot changed the line ending of my file
to \r. But that should be treated as a metadata change, not a change to the
content. I know it isn't "really" metadata, it's "actually" content, but
regardless, it should be *treated* as metadata.

Who is the boss here? The user of the tool, or the tool?



-- 
Steven

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

#103668

On Mon, Feb 29, 2016 at 11:39 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> If I open a Python file in my editor, accidentally or deliberately change
> the content to Ruby code, save and commit, then the VCS obviously should
> track the changes because they are actual changes.

"Oops, I accidentally pressed Esc-Meta-Alt-R-Q and translated my code
into Ruby. Now what?"

> Changing line endings is neither a structural nor a semantic change to the
> content of the file. It's effectively metadata, not data. The Python
> interpreter doesn't care which line ending you use. Neither will decent
> text editors. If some tools, like git, do, then that's a weakness of git,
> not a feature. Changing the permissions on a 10,000 line file doesn't give
> you a 10,000 line diff, and neither should changing the line ending.
>
> Your VCS absolutely should track line ending changes. In a perfect world, we
> should never care about the line ending, but so long as there are users and
> tools that cannot transparently deal with one line ending or another, there
> may be times were we do care about line endings, and therefore want to
> run "git blame" to find out which idiot changed the line ending of my file
> to \r. But that should be treated as a metadata change, not a change to the
> content. I know it isn't "really" metadata, it's "actually" content, but
> regardless, it should be *treated* as metadata.
>
> Who is the boss here? The user of the tool, or the tool?

This is a tricky question, and there's a slight difference between
perms and line endings in that it's perfectly possible to have mixed
line endings. The normal way to resolve this is to tell git to convert
line endings *for text files* such that source control always uses \n,
and then individual users get to choose whether to check out with \n
or convert to \r\n for their working copies. This destroys any
information that had been represented in mixed line endings - but
that's information that no project I've ever worked with uses.
However, since this is not something that git dares do on its own,
it's not the default action - though the Git Windows installer does
prompt you to pick those options on installation.

Once you tell git to treat line endings the same way ("git config
--global core.autocrlf true", if memory serves me), it's not even
metadata, it's just non-information.

ChrisA

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web