IDE for python similar to visual basic

Q

qwe rty

i have been searching for am IDE for python that is similar to Visual
Basic but had no luck.shall you help me please?
 
V

Vivian Wang

i have been searching for am IDE for python that is similar to Visual
Basic but had no luck.shall you help me please?


You can try biform:
http://www.bilive.com/download/Setup_BiForm_V2.1_en.msi.zip

Demo:
http://www.bilive.com/demo/BiForm_EN_demo.htm

More demo:(Chinese version)
http://www.bilive.com/demo/

BiForm is a form designer,one designed form will deploy as a PFF file.
BiReader is a runtime PFF file process engine for end-users.
Setup file above include BiForm and BiReader.

Main features:
*Python as script language,base on QT GUI library
*Visible form designer
*Internal database access framework
*Auto connect database,auto create tables
*Supports SQLite/Mssql2000/Sybase ASE,not need write diffrent script
for diffrent database at most time
*Simple deploy,simple upgrade
*Different forms can share same tables,they will auto cooperation with
other forms at runtime.If you want to deploy a new function , not need
uninstall other forms,deploy the new PFF file is enough .
 
C

Che M

i have been searching for am IDE for python that is similar to Visual
Basic but had no luck.shall you help me please?

Boa Constructor. IDE/visual GUI-builder/sizer support, lots of
other goodies. Not actively maintained, though, and some issues
on Linux, in my experience. But I like it a lot.
 
R

r

i have been searching for am IDE for python that is similar to Visual
Basic but had no luck.shall you help me please?

Hello qwe rty,

I remember my first days with GUI programming and thinking to myself;
how on earth can i write GUI code without a MS style GUI builder? Not
to long after that i was coding up some pretty spectacular GUI's from
nothing more than source code and loving it.

[Warning: the following is only opinion!]
I think a point and click GUI builder (although some may disagree) is
actually detrimental to your programming skills. The ability to
visualize the GUI only from the source code as you read it, is as
important to a programmer as site reading sheet music is to a
musician. And I like to program with the training wheels off.
 
N

Nobody

I think a point and click GUI builder (although some may disagree) is
actually detrimental to your programming skills. The ability to
visualize the GUI only from the source code as you read it, is as
important to a programmer as site reading sheet music is to a
musician. And I like to program with the training wheels off.

The main advantage of a GUI builder is that it helps prevent you from
hard-coding the GUI into the program. You could get the same effect by
coding a UIL/XRC/etc file manually, but a GUI builder tends to force it.

It also allows the GUI to be edited by without requiring any programming
knowledge. This eliminates the need for the GUI designer to be familiar
with the programming language used (or any programming language), and
allows customisation by end users.

Creating a GUI programmatically is almost always the wrong approach. It
tends to be adopted due to a path of least resistance, rather than any
affirmative reason.
 
R

r

Creating a GUI programmatically is almost always the wrong approach. It
tends to be adopted due to a path of least resistance, rather than any
affirmative reason.

so i guess it'e safe to say that you use a GUI builder? :)
 
A

Albert van der Horst

The main advantage of a GUI builder is that it helps prevent you from
hard-coding the GUI into the program. You could get the same effect by
coding a UIL/XRC/etc file manually, but a GUI builder tends to force it.

A GUI builder results in hard coding the GUI. The code only resides
elsewhere.
It also allows the GUI to be edited by without requiring any programming
knowledge. This eliminates the need for the GUI designer to be familiar
with the programming language used (or any programming language), and
allows customisation by end users.

This is the real argument. The code is separated into two modules.
The modules are coded in different languages. All for good reason.
Maybe the configuration file can be changed without
recompiling the c-code. Very nice.
Creating a GUI programmatically is almost always the wrong approach. It
tends to be adopted due to a path of least resistance, rather than any
affirmative reason.

In view of the above this is not quite the correct way to put it.

What I resent is that it leads to a non-professional attitude
of the graphical part. Programming is over, lets now kludge
some screens together. No. The graphics part has to be carefully
designed, carefully tested, and carefully "written", even if it
is using a graphical tool. So, yes please, *do* create a GUI
"programmatically".

Groetjes Albert
 
R

r

A GUI builder results in hard coding the GUI. The code only resides
elsewhere.
+1

and this is why M$ interfaces suck eggs! This whole "let's just slap
together something that works even if kludgy" attitude begets the
horrible UI's of which i speak. Are you saying that programmers have
no ability to design elegant UI's? Or are you saying GUI's are not
*that* important?
What I resent is that it leads to a non-professional attitude
of the graphical part. Programming is over, lets now kludge
some screens together. No. The graphics part has to be carefully
designed, carefully tested, and carefully "written", even if it
is using a graphical tool. So, yes please, *do* create a GUI
"programmatically".

Groetjes Albert

Agreed! You *must* get up-close-and-personal with the GUI code. You
know, in the past i would write the logic first and then fit the GUI
to the code, not any more!. Now I design the GUI first, then write the
code to complement it. Maybe i'm just nuts, but i thought GUI's where
targeted at "non-technical" end users, not the enlightened few?


get_enlightened(http://jjsenlightenments.blogspot.com/)
 
N

Nobody

A GUI builder results in hard coding the GUI. The code only resides
elsewhere.

Data (e.g. a UIL or XRC file) isn't code.

But "hard-coding" is more a question of whether you can realistically
change the data without changing the code. If the code craps out due to
minor changes to the data, there isn't much advantage of having a separate
data file.
In view of the above this is not quite the correct way to put it.

What I resent is that it leads to a non-professional attitude
of the graphical part. Programming is over, lets now kludge
some screens together. No. The graphics part has to be carefully
designed, carefully tested, and carefully "written", even if it
is using a graphical tool. So, yes please, *do* create a GUI
"programmatically".

My view is that the program should provide functionality without
unnecessarily dictating the way in which that functionality is used.
Essentially, it's an issue of "loose coupling".

The interface really should be configurable by the user according to their
needs. The code doesn't need to *know* the position or dimensions of
a widget, or its label or colour or spacing, let alone dictate them.

In most cases, the code shouldn't even get to dictate that specific
widgets even exist. Rather, it should provide actions which can
be bound to buttons, menu items and/or accelerators as the user chooses.
 
N

Nobody

and this is why M$ interfaces suck eggs! This whole "let's just slap
together something that works even if kludgy" attitude begets the
horrible UI's of which i speak. Are you saying that programmers have
no ability to design elegant UI's? Or are you saying GUI's are not
*that* important?

I'm saying that the user understands their workflow and environment better
than the application's programmers. The user should be able to decide
which menu items are shown and where, which buttons are shown and where,
etc. The code doesn't need to know this level of detail, let alone dictate
it.
 
R

r

I'm saying that the user understands their workflow and environment better
than the application's programmers. The user should be able to decide
which menu items are shown and where, which buttons are shown and where,
etc. The code doesn't need to know this level of detail, let alone dictate
it.

I completely disagree with this idea of user "customization" of the
GUI. Sounds more like adolescent accessorizing to me. How is changing
the location of a button, or entry, or whatever, actually going to
make workflow more easier? Sounds like "somebody" failed to get input
from their users at design time. Or "somebody" has the inability to
relate to their end users. However i know some out there like the
"styles" and "skins" crap, which is a different animal altogether than
what you speak of.

Would a mechanic give you a screw driver so you could adjust the fuel/
air ratio yourself? If he did i would never take my car back again!
Just reeks of incompetence!!

Only qualified persons should fix cars, same for software!
 
B

Brendon Wickham

The interface really should be configurable by the user according to their
needs. The code doesn't need to *know* the position or dimensions of
a widget, or its label or colour or spacing, let alone dictate them.

Perhaps...but the user needs a framework in order to understand the
functions they find themselves in charge of once they've initiated a
program. As the designer, the programmer is best placed to provide
that framework, because they know, or they should know, what it is
(something I don't think can be taken for granted). Therefore,
fundamental decisions about the UI should be left to the programmer.
If customisation is possible, all well and good, but it should not be
the main goal of a UI. Usability principles should be.
In most cases, the code shouldn't even get to dictate that specific
widgets even exist. Rather, it should provide actions which can
be bound to buttons, menu items and/or accelerators as the user chooses.

That would be an API.
 
D

David Smith

r said:
I completely disagree with this idea of user "customization" of the
GUI. Sounds more like adolescent accessorizing to me. How is changing
the location of a button, or entry, or whatever, actually going to
make workflow more easier? Sounds like "somebody" failed to get input
from their users at design time. Or "somebody" has the inability to
relate to their end users. However i know some out there like the
"styles" and "skins" crap, which is a different animal altogether than
what you speak of.

Would a mechanic give you a screw driver so you could adjust the fuel/
air ratio yourself? If he did i would never take my car back again!
Just reeks of incompetence!!

Only qualified persons should fix cars, same for software!

Speaking for backyard mechanics everywhere, I sometimes want the
screwdriver. :)

--David
 
K

Kevin Walzer

Hello qwe rty,

I remember my first days with GUI programming and thinking to myself;
how on earth can i write GUI code without a MS style GUI builder? Not
to long after that i was coding up some pretty spectacular GUI's from
nothing more than source code and loving it.

[Warning: the following is only opinion!]
I think a point and click GUI builder (although some may disagree) is
actually detrimental to your programming skills. The ability to
visualize the GUI only from the source code as you read it, is as
important to a programmer as site reading sheet music is to a
musician. And I like to program with the training wheels off.

Whether done in code or with a visual tool, good, effective GUI design
is not easy. However you get there is up to you. In my case (using
Tkinter), I've found that it's faster and better to write the code by
hand. Code in the text editor, the terminal for testing: simple and
easy. Adding another tool to the mix just makes things more complicated.
:) Some may find it's easier to use a GUI builder, and if that's the
case, some good ones have been recommended.

<shameless plug>
In case anyone thinks the words "Tkinter" and "good, effective GUI
design" shouldn't be in the same paragraph, please see
http://www.codebykevin.com/phynchronicity.html...
</shameless plug>
 
N

Nobody

I completely disagree with this idea of user "customization" of the
GUI. Sounds more like adolescent accessorizing to me. How is changing
the location of a button, or entry, or whatever, actually going to
make workflow more easier?

For a start, removing any buttons which the user won't be needing
eliminates the risk of them clicking on them by accident.

Beyond that, there is an advantage to placing buttons (etc) in similar
locations to other applications which the user uses (or was using prior
to migrating).

In some cases, the reduction in mouse motion which can be obtained by
placing specific buttons close together can make significant difference.

Sometimes those buttons aren't all part of the same application (I know of
people who place the Windows taskbar at the top of the screen simply
because it's closer to most applications' toolbar and menubar). If you
have two windows side-by-side, there's a benefit to having the left-hand
window's controls running down its right-hand edge and vice-versa, so both
sets of controls are all in one cluster.

For mouse-centric applications, keyboard shortcuts aren't always
a solution; particularly for left-handed users, as shortcuts are normally
optimised for right-handed users (i.e. common shortcuts use the LHS of the
keyboard, on the assumption that the right hand is on the mouse).
Sounds like "somebody" failed to get input
from their users at design time. Or "somebody" has the inability to
relate to their end users.

You're assuming that there is some "right" answer which is appropriate for
all users. There isn't.
Would a mechanic give you a screw driver so you could adjust the fuel/
air ratio yourself? If he did i would never take my car back again!
Just reeks of incompetence!!

If the manufacturer took your approach, there wouldn't be any screw. Just
a fixed setting for all climates and altitudes, urban and rural, flat
and hilly.
 
A

Albert van der Horst

On Mon, 07 Sep 2009 23:56:17 +0000, Albert van der Horst wrote:


My view is that the program should provide functionality without
unnecessarily dictating the way in which that functionality is used.
Essentially, it's an issue of "loose coupling".

The interface really should be configurable by the user according to their
needs. The code doesn't need to *know* the position or dimensions of
a widget, or its label or colour or spacing, let alone dictate them.

In most cases, the code shouldn't even get to dictate that specific
widgets even exist. Rather, it should provide actions which can
be bound to buttons, menu items and/or accelerators as the user chooses.

I don't necessarily disagree. But how does this work in practice?

I have a totally programmable editor (I do, I'm using it right no.)
I'm able to redefine commands to the point that I have no longer a
command to quit the program, and even have no longer a possibility to
define a new key-combination to quit the program. The hacker who wrote
it would say: "don't do that".
Combined with my habit to switch the Caps lock and control keys
and use the editor full-screen, someone else really gets nowhere.

What if I prefer to have the gaz throttle and the clutch pedal of my
car switched. Is that a good idea?

Bottomline, "let the user choose" must not be an excuse for us,
where we are not able to propose a good choice.

(You may read the subject note-eater on my website.)

Groetjes Albert
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top