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

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

.Net Like Gui Builder for Python?

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

Contents

  .Net Like Gui Builder for Python? Orochi <kartikjagdale11@gmail.com> - 2014-07-25 07:55 -0700
    Re: .Net Like Gui Builder for Python? Orochi <kartikjagdale11@gmail.com> - 2014-07-25 08:19 -0700
    Re: .Net Like Gui Builder for Python? Jerry Hill <malaclypse2@gmail.com> - 2014-07-25 14:11 -0400
    Re: .Net Like Gui Builder for Python? Sturla Molden <sturla.molden@gmail.com> - 2014-07-25 20:04 +0000
    Re: .Net Like Gui Builder for Python? Dietmar Schwertberger <maillist@schwertberger.de> - 2014-07-25 23:23 +0200
    Re: .Net Like Gui Builder for Python? Chris Angelico <rosuav@gmail.com> - 2014-07-26 12:40 +1000
    Re: .Net Like Gui Builder for Python? Michael Torrie <torriem@gmail.com> - 2014-07-25 21:33 -0600
    Re: .Net Like Gui Builder for Python? TP <wingusr@gmail.com> - 2014-07-25 21:13 -0700
    Re: .Net Like Gui Builder for Python? Chris Angelico <rosuav@gmail.com> - 2014-07-26 14:37 +1000
    Re: .Net Like Gui Builder for Python? Martin S <shieldfire@gmail.com> - 2014-07-26 09:19 +0200
    Re: .Net Like Gui Builder for Python? Martin S <shieldfire@gmail.com> - 2014-07-26 09:13 +0200
    Re: .Net Like Gui Builder for Python? Chris Angelico <rosuav@gmail.com> - 2014-07-26 19:05 +1000
    Re: .Net Like Gui Builder for Python? Dietmar Schwertberger <maillist@schwertberger.de> - 2014-07-26 12:14 +0200
    Re: .Net Like Gui Builder for Python? Chris Angelico <rosuav@gmail.com> - 2014-07-26 20:25 +1000
    Re: .Net Like Gui Builder for Python? Martin S <shieldfire@gmail.com> - 2014-07-26 12:33 +0200
    Re: .Net Like Gui Builder for Python? Sturla Molden <sturla.molden@gmail.com> - 2014-07-26 10:51 +0000
      Re: .Net Like Gui Builder for Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-26 13:44 +0000
    Re: .Net Like Gui Builder for Python? Dietmar Schwertberger <maillist@schwertberger.de> - 2014-07-26 13:28 +0200
    Re: .Net Like Gui Builder for Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-07-26 14:40 -0400
      Re: .Net Like Gui Builder for Python? Steve Hayes <hayesstw@telkomsa.net> - 2014-07-27 06:49 +0200
        Re: .Net Like Gui Builder for Python? Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-07-27 10:10 +0200
          Re: .Net Like Gui Builder for Python? Steve Hayes <hayesstw@telkomsa.net> - 2014-07-27 14:24 +0200
            Re: .Net Like Gui Builder for Python? Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-07-27 14:42 +0200
              Re: .Net Like Gui Builder for Python? Steve Hayes <hayesstw@telkomsa.net> - 2014-07-28 04:33 +0200
        Re: .Net Like Gui Builder for Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-07-27 11:30 -0400
        Re: .Net Like Gui Builder for Python? Sturla Molden <sturla.molden@gmail.com> - 2014-07-27 18:32 +0000
        Re: .Net Like Gui Builder for Python? Michael Torrie <torriem@gmail.com> - 2014-07-27 22:26 -0600
        Re: .Net Like Gui Builder for Python? Sturla Molden <sturla.molden@gmail.com> - 2014-07-28 10:14 +0000
    Re: .Net Like Gui Builder for Python? CM <cmpython@gmail.com> - 2014-07-27 10:46 -0700
    Re: .Net Like Gui Builder for Python? Kevin Walzer <kw@codebykevin.com> - 2014-07-27 14:48 -0400
      Re: .Net Like Gui Builder for Python? Sturla Molden <sturla.molden@gmail.com> - 2014-07-28 09:59 +0000

Page 1 of 2  [1] 2  Next page →

#75205 — .Net Like Gui Builder for Python?

Hi,
This Question may sound lame ,but I am searching for .Net Like Gui Builder for Python.
I tried PyQt Designer' and 'Glade', No doubt its great but it created only interface.
I have to code all the things in separate file.
what I was searching for is Visual Studio .Net like Gui builder where you
drag and drop widgets and just double click on the widget to edit code of that widget.All other formalities of creating a function and class for the main window and widget(e.g Button) is already done.

So,Is there any Gui App builder like Visual Studio or having features like Visual Studio for Python.

Thank You!

[toc] | [next] | [standalone]

#75206

Edit:
I did went for IronPythonStudio but its dead now and they are not updating it anymore

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

#75209

On Fri, Jul 25, 2014 at 10:55 AM, Orochi <kartikjagdale11@gmail.com> wrote:
> So,Is there any Gui App builder like Visual Studio or having features like Visual Studio for Python.

I'm not aware of anything with the same level of functionality as
Visual Studio's GUI building tools.  Glade is the closest I've seen,
and as you mentioned, it's not as interactive and integrated into an
IDE as Visual Studio is.

-- 
Jerry

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

#75211

Orochi <kartikjagdale11@gmail.com> wrote:

> I tried PyQt Designer' and 'Glade', No doubt its great but it created only interface.
> I have to code all the things in separate file.

That's what you should do. Keep autogenerated and hand-written code
separate.

Also take a look at wxFormBuilder.


> what I was searching for is Visual Studio .Net like Gui builder where you
> drag and drop widgets and just double click on the widget to edit code of that widget.

Most Python GUI frameworks are based on layout managers. "Drag and drop"
does not work so well then.


Sturla

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

#75213

Am 25.07.2014 16:55, schrieb Orochi:
> So,Is there any Gui App builder like Visual Studio or having features like Visual Studio for Python.
Unfortunately there's nothing like that.
IMHO the lack of such a tool is a major blocking point in many 
(corporate) environments...

 From the GUI builders that I have tried, wxFormBuilder comes next.


Regards,

Dietmar

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

#75223

On Sat, Jul 26, 2014 at 7:23 AM, Dietmar Schwertberger
<maillist@schwertberger.de> wrote:
> Am 25.07.2014 16:55, schrieb Orochi:
>
>> So,Is there any Gui App builder like Visual Studio or having features like
>> Visual Studio for Python.
>
> Unfortunately there's nothing like that.
> IMHO the lack of such a tool is a major blocking point in many (corporate)
> environments...
>
> From the GUI builders that I have tried, wxFormBuilder comes next.

The OP asked for two things, which I'll separate because they're
actually quite different.

1) Drag and drop widgets to create a window
2) Double-click a widget to edit its code (presumably event handler)

I have used a number of GUI toolkits that did provide the first one,
but the second is a lot more restrictive than you might think: it
implies that there's exactly one code block per widget. For simple
projects, you might think "Uhh, yeah, a button has its click event",
but there are plenty of other events to attach to a button, and you
might want to have the same function attached to several buttons
(either because they actually do the same thing, or because they do
very similar things and it's parameterized). The nearest I've seen to
"double-click to edit code" is VX-REXX, which had a right-click menu
with all that widget's events; it didn't cope with having the same
code attached to multiple widgets (for that, you need to manually
attach events), but as that's a lot rarer than having multiple code
blocks attached to one widget (eg a hover event and a click event),
that's acceptable for a convenience feature.

As to dragging and dropping widgets to create a window, though...
that's fine for a pixel-based layout, but it's high time pixel-based
layouts were deprecated. They're vulnerable to way too many variations
(twip-based layouts, like VX-REXX uses, are at least independent of
font size, but still vulnerable to plenty of other issues), and
they're rigid. Cross-platform GUI toolkits are generally based around
rules, rather than exact positions, so you end up with a tree. Think
of HTML and how markup affects layout; you place containers and
containers within containers, and everything is held within its
parent. (Well, okay. With position:relative you can mess that up. And
of course position:absolute and position:fixed basically put a new
top-level window onto the page. But normal object layout is based on
the tree structure.)

Rather than a drag-and-drop builder, then, all you need is a text
editor and a way to quickly run your code. As well as demanding
nothing in terms of development time (believe you me, a good d'n'd
builder would cost quite a few dev hours), this guarantees perfect
accuracy; imagine the hassles if your code ended up producing
something not quite identical to your preview! Take the easy and safe
option, and just write your code and look at it. WYSIWYG editors have
their uses in some places, but more and more I'm seeing them as just
too restrictive. Editing text files is the way to do things.

ChrisA

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

#75227

On 07/25/2014 08:55 AM, Orochi wrote:
> Hi, This Question may sound lame ,but I am searching for .Net Like
> Gui Builder for Python. I tried PyQt Designer' and 'Glade', No doubt
> its great but it created only interface. I have to code all the
> things in separate file. what I was searching for is Visual Studio
> .Net like Gui builder where you drag and drop widgets and just double
> click on the widget to edit code of that widget.All other formalities
> of creating a function and class for the main window and widget(e.g
> Button) is already done.
> 
> So,Is there any Gui App builder like Visual Studio or having features
> like Visual Studio for Python.

You can easily compile Qt Designer .ui files to python code with pyuic.
 But loading the .ui file at runtime is a good idea too, and what I do
for my programs.  It adds a certain amount of flexibility.

https://blog.safaribooksonline.com/2014/01/22/create-basic-gui-using-pyqt/

I do the same thing with Glade. Modern GUI toolkits are moving away from
coding GUIs explicitly, at least on Linux and Mac.  Can't speak for windows.

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

#75229

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

On Fri, Jul 25, 2014 at 7:40 PM, Chris Angelico <rosuav@gmail.com> wrote:

> The OP asked for two things, which I'll separate because they're
> actually quite different.
>
> 1) Drag and drop widgets to create a window
> 2) Double-click a widget to edit its code (presumably event handler)
>
> I have used a number of GUI toolkits that did provide the first one,
> but the second is a lot more restrictive than you might think
>


Not that I disagree with the overall point of just using a text editor
(especially for Python GUIs) but apparently you've never created a C# WPF
app using Visual Studio? WPF fully supports layout controls, is *not*
generally pixel based it's more similar to HTML + CSS (although you do
pixel perfect layout if you try), and still easily does (2). And while I
almost exclusively use the Visual Studio XAML tab view rather than
bothering with the Designer view you can drag & drop if you really want to.
And Microsoft's Expression Blend takes that to a whole 'nother level
supposedly making it easy for "even" graphic designers to create GUIs
without delving too much into raw code wrangling.

One of the nice things about VIsual Studio and WPF (even in the XAML view)
is its Properties window. This lets you select a control and see all the
applicable possible properties and what legal choices you have for setting
them. This is an incredible aid to discovering how to use said controls.

And as far as any limitations of (2) goes, I still like using the Events
view of the Properties window to initially hook up an event handler. This
automatically creates a  "correctly" (or at least consistently) named and
argumented event handler and adds the proper attribute to the XAML. It is
easy enough to then mess around with the generated code if that doesn't
quite suit your needs. Having the list of possible event handlers all in
one place instead of having to look up the doc is invaluable. And being
able to press F1 just about anywhere and have the relevant document open up
is even more so.

As far as I've seen Visual Studio + WPF really is state of the art for GUI
building. I wish more developers were familiar with all its capabilities so
they could know what to whine for in their own programming environment :)

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

#75230

On Sat, Jul 26, 2014 at 2:13 PM, TP <wingusr@gmail.com> wrote:
> Not that I disagree with the overall point of just using a text editor
> (especially for Python GUIs) but apparently you've never created a C# WPF
> app using Visual Studio? WPF fully supports layout controls, is *not*
> generally pixel based it's more similar to HTML + CSS (although you do pixel
> perfect layout if you try), and still easily does (2). And while I almost
> exclusively use the Visual Studio XAML tab view rather than bothering with
> the Designer view you can drag & drop if you really want to. And Microsoft's
> Expression Blend takes that to a whole 'nother level supposedly making it
> easy for "even" graphic designers to create GUIs without delving too much
> into raw code wrangling.

No, I haven't. (I haven't done anything with C#. There's a limit to
how much I have time to learn, and I'd much rather work with something
like Pike than C#.) In the light of this, I'd best separate out my
concerns a little further:

1) GUI layouts that use pixel positioning
2) Drag and drop GUI layout interfaces

The first has all the problems I mentioned, of being tightly bound to
so many things. A twip-based layout solves one of them (font size),
and it's possible to get simple features like "match sizes on all
these widgets" and "align these widgets' left margins" (both of which
I had in VX-REXX) to help; but none of that deals with run-time layout
requirements, which are much MUCH better served by a rule-based
layout.

The second, though, still does have issues. While it'll give you a
good result at the end, it's not nearly as advantageous as the d'n'd
interface for laying out pixel-precise positions. WYSIWYG HTML editors
aren't exactly sweeping the board (in fact, every serious web
developer I know prefers to work with the markup itself), and even
then, they're not so much "drag and drop positioning of stuff" as they
are "word processor that saves as HTML". You may as well skip the
WYSIWYG editor and just work directly with code; the benefit isn't
enough to justify the risks, the biggest of which is that your lovely
layout will look completely ugly on a different platform, theme, font
size, etc.

There is one special case, though. When it comes to *mocking up* an
interface, it is sometimes helpful to have a drag-and-drop system that
allows a non-programmer to put something together - a sketch, if you
like. Imagine taking a sheet of physical paper and an actual physical
pencil, and drawing out a layout; now imagine making that both easier
and clearer by dragging widgets around. At no point do you ever expect
the paper sketch to be perfect, and certainly you don't expect it to
work on all platforms, font sizes, etc; but it's a lot easier than
manually crafting ASCII art, and it's something that a programmer can
look at to decide how to lay things out. It's far from perfect,
though, as it assumes a fundamentally 2D layout; GUI design, even back
in the 90s when I first started, was always a tree of parent-child
relationships. But if you want that sort of thing for your mock-up,
I'm sure it'd be possible to abuse something to do it; I used the Open
Watcom C++ Dialog Editor for the job, a few times. It doesn't even
have to be backed by the same language or toolkit.

We're broadly in agreement, though. Instead of searching for the ideal
GUI window builder (and, by the way, one person's ideal will differ
hugely from another's), just write the code directly. Life's better.

Plus, it plays more nicely with source control. Ever tried to dig
through a git repo to figure out when a change happened to an Open
Office document? Not so useful. But I can 'git blame' a source file
and know for sure that I'm getting meaningful results. LilyPond files
are source code; NoteWorthy Composer files are binary blobs. (I'm not
sure about other music formats, like Sibelius's save file, as I
haven't used them.) I'd much rather work with a format where the disk
changes mirror the conceptual changes. Readable diffs FTW.

ChrisA

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

#75237

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

>From the newbie point of view, VS is the perfect tool to get people coding. All the way back to Visual Basic, Microsoft has consistently pushed the ease of creating applications for Windows as a point of adoption. 

Hence Borland Delphi, and the now abandoned Kylix. Pascal has the Lazarus project, which builds on Delphi - so there is a point in integrating gui building in the RAD. 

/martin 

On 26 Jul 2014, TP <wingusr@gmail.com> wrote:


On Fri, Jul 25, 2014 at 7:40 PM, Chris Angelico <rosuav@gmail.com> wrote:

The OP asked for two things, which I'll separate because they're
actually quite different.

1) Drag and drop widgets to create a window
2) Double-click a widget to edit its code (presumably event handler)

I have used a number of GUI toolkits that did provide the first one,
but the second is a lot more restrictive than you might think



Not that I disagree with the overall point of just using a text editor (especially for Python GUIs) but apparently you've never created a C# WPF app using Visual Studio? WPF fully supports layout controls, is *not* generally pixel based it's more similar to HTML + CSS (although you do pixel perfect layout if you try), and still easily does (2). And while I almost exclusively use the Visual Studio XAML tab view rather than bothering with the Designer view you can drag & drop if you really want to. And Microsoft's Expression Blend takes that to a whole 'nother level supposedly making it easy for "even" graphic designers to create GUIs without delving too much into raw code wrangling.

One of the nice things about VIsual Studio and WPF (even in the XAML view) is its Properties window. This lets you select a control and see all the applicable possible properties and what legal choices you have for setting them. This is an incredible aid to discovering how to use said controls.

And as far as any limitations of (2) goes, I still like using the Events view of the Properties window to initially hook up an event handler. This automatically creates a  "correctly" (or at least consistently) named and argumented event handler and adds the proper attribute to the XAML. It is easy enough to then mess around with the generated code if that doesn't quite suit your needs. Having the list of possible event handlers all in one place instead of having to look up the doc is invaluable. And being able to press F1 just about anywhere and have the relevant document open up is even more so.

As far as I've seen Visual Studio + WPF really is state of the art for GUI building. I wish more developers were familiar with all its capabilities so they could know what to whine for in their own programming environment :)

-- 
https://mail.python.org/mailman/listinfo/python-list


-- Sent with K-@ Mail - the evolution of emailing.

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

#75238

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

>From the newbie point of view, VS is the perfect tool to get people coding. All the way back to Visual Basic, Microsoft has consistently pushed the ease of creating applications for Windows as a point of adoption. 

Hence Borland Delphi, and the now abandoned Kylix. Pascal has the Lazarus project, which builds on Delphi - so there is a point in integrating gui building in the RAD. 

/martin 

On 26 Jul 2014, TP <wingusr@gmail.com> wrote:
>On Fri, Jul 25, 2014 at 7:40 PM, Chris Angelico <rosuav@gmail.com>
>wrote:
>
>> The OP asked for two things, which I'll separate because they're
>> actually quite different.
>>
>> 1) Drag and drop widgets to create a window
>> 2) Double-click a widget to edit its code (presumably event handler)
>>
>> I have used a number of GUI toolkits that did provide the first one,
>> but the second is a lot more restrictive than you might think
>>
>
>
>Not that I disagree with the overall point of just using a text editor
>(especially for Python GUIs) but apparently you've never created a C#
>WPF
>app using Visual Studio? WPF fully supports layout controls, is *not*
>generally pixel based it's more similar to HTML + CSS (although you do
>pixel perfect layout if you try), and still easily does (2). And while
>I
>almost exclusively use the Visual Studio XAML tab view rather than
>bothering with the Designer view you can drag & drop if you really want
>to.
>And Microsoft's Expression Blend takes that to a whole 'nother level
>supposedly making it easy for "even" graphic designers to create GUIs
>without delving too much into raw code wrangling.
>
>One of the nice things about VIsual Studio and WPF (even in the XAML
>view)
>is its Properties window. This lets you select a control and see all
>the
>applicable possible properties and what legal choices you have for
>setting
>them. This is an incredible aid to discovering how to use said
>controls.
>
>And as far as any limitations of (2) goes, I still like using the
>Events
>view of the Properties window to initially hook up an event handler.
>This
>automatically creates a  "correctly" (or at least consistently) named
>and
>argumented event handler and adds the proper attribute to the XAML. It
>is
>easy enough to then mess around with the generated code if that doesn't
>quite suit your needs. Having the list of possible event handlers all
>in
>one place instead of having to look up the doc is invaluable. And being
>able to press F1 just about anywhere and have the relevant document
>open up
>is even more so.
>
>As far as I've seen Visual Studio + WPF really is state of the art for
>GUI
>building. I wish more developers were familiar with all its
>capabilities so
>they could know what to whine for in their own programming environment
>:)
>
>
>------------------------------------------------------------------------
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list

-- Sent with K-@ Mail - the evolution of emailing.

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

#75240

On Sat, Jul 26, 2014 at 5:19 PM, Martin S <shieldfire@gmail.com> wrote:
> From the newbie point of view, VS is the perfect tool to get people coding.
> All the way back to Visual Basic, Microsoft has consistently pushed the ease
> of creating applications for Windows as a point of adoption.

IMO it's an attractive nuisance at best. Make it easy to build
something simple and flawed, and people will build things that aren't
simple but are still flawed. Microsoft has done this to the world a
few times - how many people do you know who use Excel for jobs that
would be better served by a database? (Or by a script, even; CSV
import into one sheet, manual fixups as required, then CSV export from
another sheet that has a bunch of formula cells. I've seen that done.)
GUI builders, especially those with "hey look you don't even need to
write code" event handlers, are often like that. Sure, you can make a
simple "Hello, world" pretty easily. You can go one further and have a
slider and an entry field whose contents are synchronized. But for
building a large and complex application, they tend more to make the
job harder than easier; and for people who've learned on that system
and no other, it's "but this works - what, I have to learn a whole new
system now? That new system sucks".

It's the same with everything. I did my first music transposition and
composing with NoteWorthy Composer. It was alright, it got the job
done. But when I wanted to do anything more complex than the authors
planned for, I was stuck. Just adding additional verses to a hymn tune
(music score at the top of the page, four more verses underneath) was
impossible in NWC, so I ended up actually printing out the score, then
physically putting the sheet of paper back in, and printing the
additional verses from a word processor. With LilyPond, I can do
additional verses easily, because the authors planned for it; but more
importantly, I can also do things they didn't plan for, like putting
lyric line breaks into the MIDI file without disrupting the printed
score. (I had to write a little Scheme code to make that work.)

If it comes to that, in a way, programming is all like that. Imagine
buying a device and being allowed to run only the software that its
makers provide. [1] If they think of lots of things, then great! You
want to do something, and there's an app for that. But generally, a
device is sold to more people than built it, and most likely (I'm
definitely making assumptions here) the collective intelligence and
creativity of the buyers exceeds that of the designers. So a smart
designer will make it possible for the device to do more than he
planned, by making it programmable. Sure, it's a bit harder to use
than just "touch this and stuff happens", but instead of finite,
pre-coded functionality, you have infinite possibilities.

Since we're all here on python-list, I think we all appreciate the
value of being able to do what someone else didn't think of. I'm happy
to have the same power-at-the-cost-of-effort in GUI building, too.

ChrisA

[1] This scenario is purely hypothetical. Any similarity with real
products whose names begin with the mathematician's shorthand for the
square root of -1 is purely coincidental. Anyway, I'm exaggerating for
emphasis. Slightly.

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

#75241

Am 26.07.2014 11:05, schrieb Chris Angelico:
> IMO it's an attractive nuisance at best. Make it easy to build
> something simple and flawed, and people will build things that aren't
> simple but are still flawed. Microsoft has done this to the world a
For most software/tools that's good enough. It's better to have this 
than having
nothing.
Sure, when you have a look at the VB-created programs, most of them are 
flawed,
but still they solve problems.

Currently, Python is ruled out as tool in many situations due to the steep
learning curve when it comes to GUIs, so people use Excel, Labview, Matlab
or whatever (or nothing at all or still VB).

> But for
> building a large and complex application, they tend more to make the
> job harder than easier; and for people who've learned on that system
Most problems that are out there to be adressed require only simple 
applications.

For anything non-trivial I don't see that a GUI-builder, I agree that 
hand-coding
the GUI is the better approach.

But then, we're now in a world where e.g. Qt is moving away from widgets to
QML which makes GUI programming a huge mess (in the same way that PHP
made web-programming a mess).

> and no other, it's "but this works - what, I have to learn a whole new
> system now? That new system sucks".
What is the point of not having tools to ease the entry?
Of course it makes the others, who still learned it, feel cool, but 
other than that?

Regards,

Dietmar

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

#75242

On Sat, Jul 26, 2014 at 8:14 PM, Dietmar Schwertberger
<maillist@schwertberger.de> wrote:
> For most software/tools that's good enough. It's better to have this than
> having
> nothing.
> Sure, when you have a look at the VB-created programs, most of them are
> flawed,
> but still they solve problems.
>
> Currently, Python is ruled out as tool in many situations due to the steep
> learning curve when it comes to GUIs, so people use Excel, Labview, Matlab
> or whatever (or nothing at all or still VB).

That's exactly what I mean by "attractive nuisance". Excel appears to
solve your problem, so you use it, and then as the problem shifts,
your spreadsheet gets more and more complicated, until it appears on
The Daily WTF. Is that really a good thing? I mean, you could have
started with pencil and paper, and that would have been even easier.
The only difference is that you outgrow paper sooner than VB, which
means porting is done on a much smaller "code"-base and is less of a
problem.

ChrisA

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

#75243

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

On 26 Jul 2014 12:16, "Dietmar Schwertberger" <maillist@schwertberger.de>
wrote:
>
> Am 26.07.2014 11:05, schrieb Chris Angelico:
>
>> IMO it's an attractive nuisance at best. Make it easy to build
>> something simple and flawed, and people will build things that aren't
>> simple but are still flawed. Microsoft has done this to the world a
>
> For most software/tools that's good enough. It's better to have this than
having
> nothing.
> Sure, when you have a look at the VB-created programs, most of them are
flawed,
> but still they solve problems.
>

And it gets people coding, adding to existing software and thinking about
how to improve stuff (their own or others) in the future.

Also if you look at any newbie programmer software, it's flawed. But it
wouldn't hurt making it easier creating flawed software. Better than less
software (unless it it's malware)

/martin

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

#75244

Martin S <shieldfire@gmail.com> wrote:

> Also if you look at any newbie programmer software, it's flawed. But it
> wouldn't hurt making it easier creating flawed software. Better than less
> software (unless it it's malware)

Malware is rarely flawed. I wish it were, though.

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

#75248

On Sat, 26 Jul 2014 10:51:31 +0000, Sturla Molden wrote:

> Martin S <shieldfire@gmail.com> wrote:
> 
>> Also if you look at any newbie programmer software, it's flawed. But it
>> wouldn't hurt making it easier creating flawed software. Better than
>> less software (unless it it's malware)
> 
> Malware is rarely flawed. I wish it were, though.

Malware is often buggy. Sometimes so buggy it doesn't even do the job it 
is intended to. Viruses crash. Even the most technologically 
sophisticated virus yet discovered in the wild was buggy: Stuxnet was 
only discovered because of a programming error.

https://en.wikipedia.org/wiki/Stuxnet



-- 
Steven

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

#75245

Am 26.07.2014 12:25, schrieb Chris Angelico:
> The only difference is that you outgrow paper sooner than VB, which
> means porting is done on a much smaller "code"-base and is less of a
> problem.
Most Excel or VB based tools are never replaced. They are the 
replacement and final
implementation of the paper solution already.

The world would be a better one if Python was chosen instead of Excel 
for implementation,
offering a continuous path for improvement, but that won't happen 
without an easy-to-use
GUI builder.
(Even though many problems could be addressed without a GUI, it's still 
what people want.)

Regards,

Dietmar

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

#75252

On Sat, 26 Jul 2014 19:05:21 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>IMO it's an attractive nuisance at best. Make it easy to build
>something simple and flawed, and people will build things that aren't
>simple but are still flawed. Microsoft has done this to the world a
>few times - how many people do you know who use Excel for jobs that
>would be better served by a database? (Or by a script, even; CSV
>import into one sheet, manual fixups as required, then CSV export from
>another sheet that has a bunch of formula cells. I've seen that done.)

	The way they package Office doesn't help... Ignoring the
subscription-based "Office 365" I was at Best Buy a few weeks ago... The
only local-install version of Office (Home&Office I think) had Word, Excel,
and PowerPoint.

	How many /home/ users are creating presentations/slide-shows? Drop
PowerPoint and include Access (which is essentially a GUI builder front-end
for the Jet RDBM engine) and Publisher (seems a home user would do more
with invitations, cards, and maybe reports/brochures)!

	I remember when the forte of spreadsheets was in number crunching of
tabular data -- formulas -- (I used to have the Traveller star ship design
rules embodied in a Multiplan spreadsheet running on TRSDOS-6); not this
"static phone book using <find> to lookup" type stuff so many people do
now.

	I'm going to miss being employed for one reason (well, health insurance
though so far this year I've only used about half my deductible, would be
another).  The M$ Home Use program; which made the full Office Suite 2013
available for around $30 (with DVD).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#75265

On Sat, 26 Jul 2014 14:40:56 -0400, Dennis Lee Bieber <wlfraed@ix.netcom.com>
wrote:

>On Sat, 26 Jul 2014 19:05:21 +1000, Chris Angelico <rosuav@gmail.com>
>declaimed the following:
>
>>IMO it's an attractive nuisance at best. Make it easy to build
>>something simple and flawed, and people will build things that aren't
>>simple but are still flawed. Microsoft has done this to the world a
>>few times - how many people do you know who use Excel for jobs that
>>would be better served by a database? (Or by a script, even; CSV
>>import into one sheet, manual fixups as required, then CSV export from
>>another sheet that has a bunch of formula cells. I've seen that done.)
>
>	The way they package Office doesn't help... Ignoring the
>subscription-based "Office 365" I was at Best Buy a few weeks ago... The
>only local-install version of Office (Home&Office I think) had Word, Excel,
>and PowerPoint.
>
>	How many /home/ users are creating presentations/slide-shows? Drop
>PowerPoint and include Access (which is essentially a GUI builder front-end
>for the Jet RDBM engine) and Publisher (seems a home user would do more
>with invitations, cards, and maybe reports/brochures)!

The one thing that isn't available with LibreOffice is OneNote, which you
don't seem to be able to get separately, and doesn't seem to have any
documentation (ie 3rd party books on it). But there is Evernote. 




-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web