Best GUI for small-scale accounting app?

[McBooCzech]

Sorry to bother, but I didn't find the final answer to the question
what is the "Best GUI for small-scale accounting app"?

I am the newbie in Python, so I am trying to find some "usable" GUI as
well. But it looks to me there is a lot developers, beta-versions,
tools etc. I have spent a lot of time trying to find which is the
"best" one tool. But now it looks more confusing to me than at the
beginning.

I do not have time to try/test all of them, it is so time-consuming
and confusing specially for total beginner.

IMHO this is the worst think for the Python community: you can find
one Python only with an excellent support. Great!!!! But on the other
hand it is possible to find plenty of GUI tools and for the beginner
(and may be not just for the beginner) it is so hard to choose the
"proper" one!!!!! The field of GUI tools is so fragmented!!!! that I
am close to give it up and start with some commercial product like
Delphi/Kilyx.

BTW you did not discussed Boa, Wingware and BlackAdde (last two are
commercial) here? Are they bad?

Petr

 

[Paul Rubin]

I am the newbie in Python, so I am trying to find some "usable" GUI as
well. But it looks to me there is a lot developers, beta-versions,
tools etc. I have spent a lot of time trying to find which is the
"best" one tool. But now it looks more confusing to me than at the
beginning.

If all you want is "usable", use Tkinter. And if you're a newbie, use
Tkinter. After you've gotten some experience with Tkinter is the time
to start worrying about "best".

 

[JanC]

McBooCzech schreef:

IMHO this is the worst think for the Python community: you can find
one Python only with an excellent support. Great!!!! But on the other
hand it is possible to find plenty of GUI tools and for the beginner
(and may be not just for the beginner) it is so hard to choose the
"proper" one!!!!! The field of GUI tools is so fragmented!!!!

I think the field of GUI frameworks / tools for Python is fragmented
because it's fragmented outside of Python too...

 

[Ed Leafe]

I think the field of GUI frameworks / tools for Python is fragmented
because it's fragmented outside of Python too...

I think that the reason things are fragmented in this field is that
none of the tools are simple enough to learn. They require a great deal
of studying, experimentation, re-coding, Googling, etc., in order to
create your first non-trivial GUI app. Once you've gone through all
that, you'll probably not want to start over again with another tool,
since you'll face a similar ordeal with that tool.

This was one of our motivations in developing Dabo: making a tool that
was easy for any competent Python developer to pick up in a short
period of time. We're using the wxPython toolkit as the underlying UI
toolkit, but wrapping as much of it as we can to make the interface to
the Dabo UI simple. We're also wrapping it to make it independent of
the underlying UI toolkit; ideally, the same code should work for
TkInter, wxPython, Qt, etc. For example, I spent yesterday developing
the menu classes. Here's an example of the wxPython code necessary to
create a menu and add an item to it that calls a particular method when
chosen:

menu = wx.Menu()
itmID = wx.NewId()
itm = wx.MenuItem(menu, itmID, text="Close Window")
self.Bind(EVT_MENU, self.onCloseWindow, itmID)

Here's the equivalent in Dabo:

menu = dabo.ui.dMenu()
itm = menu.append("Close Window", self, self.onCloseWindow)

Note that there is nothing wxPython-ish about the Dabo code. The goal
is to make GUI development as simple as Python development. If we can
reach that goal (and yes, I'm quite aware of the difficulty involved),
it is my belief that there is a good chance that we will reach a
critical mass where enough people are using the tool that it may become
a 'standard'.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[Paul Rubin]

Here's the equivalent in Dabo:

menu = dabo.ui.dMenu()
itm = menu.append("Close Window", self, self.onCloseWindow)

This still seems way too complicated. Why execute a bunch of separate
statements when what you're trying to set up is a single structure?

E.g.:

menu = dabo.ui.Menu(("Close Window, self.onCloseWindow),
("New Window", self.NewWindow),
("Print", self.Print))

 

[Ed Leafe]

This still seems way too complicated. Why execute a bunch of separate
statements when what you're trying to set up is a single structure?

E.g.:

menu = dabo.ui.Menu(("Close Window, self.onCloseWindow),
("New Window", self.NewWindow),
("Print", self.Print))

Obviously, something like that could also be added - do you want to
help develop Dabo? We're always looking for talented people with good
ideas!

I should also mention that there is a class that creates a base
menubar, with the typical menus that nearly all apps use. I needed to
add to an existing menu; hence the call to menu.append().

Since Dabo is now a two-person effort, we develop as we need things. I
am working on the UI Designer, and needed to make menu entries. Up
until now, we've coded them the wx-way, but I wanted to remove that
wxPython dependency, so I took a detour from the UI Designer to create
the menu classes. That's pretty much the pattern: things get written as
they are needed.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[Paul Rubin]

Obviously, something like that could also be added - do you
want to help develop Dabo? We're always looking for talented people
with good ideas!

Only if you want to hire me. I mostly do volunteer development only
on GPL projects. If I'm writing something that can become part of a
commercial Microsoft product, I expect to be paid. But I don't mind
posting snarky comments .

Since Dabo is now a two-person effort, we develop as we need
things. I am working on the UI Designer, and needed to make menu

I hope Dabo can read the xml files Glade generates, so you have a gui
builder that's already deployed.

 

[Ed Leafe]

Only if you want to hire me. I mostly do volunteer development only
on GPL projects. If I'm writing something that can become part of a
commercial Microsoft product, I expect to be paid. But I don't mind
posting snarky comments .

Oh, geez. After months of us getting skewered for releasing Dabo under
GPL, with everyone saying that they wouldn't even *look* at it for fear
of 'infecting' all of their code, we change the license to the MIT
license, and now the complaint is that Microsoft is going to sell the
code!

Ever get that feeling that you can't win? ;-)

I hope Dabo can read the xml files Glade generates, so you have a gui
builder that's already deployed.

That's definitely part of the development plan. But after looking at
Glade and several other designers, our conclusion is that they all lack
something: either flexibility, ease of use, or something else. Sizers
were probably the item that was the most difficult thing to handle
well. The best designer for sizers we found was Qt Designer. We'd like
to make our designer as visually clear as that one.

Also, Dabo is not just a UI toolkit: it's a full 3-tier application
framework. Our major design goal is to integrate the database
connections defined into the UI designer, so that you can drag and drop
fields from the tables in the connection onto the design surface, and
create data-bound controls in one step.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[Paul Rubin]

Oh, geez. After months of us getting skewered for releasing
Dabo under GPL, with everyone saying that they wouldn't even *look* at
it for fear of 'infecting' all of their code, we change the license to
the MIT license, and now the complaint is that Microsoft is going to
sell the code!

Well, those are commercial developers who are afraid of the GPL. If
they want to require people to pay to use the code they release, then
they, just like Microsoft, should also expect to pay the developers of
the components they use. If I were you I would have stood firm on the
GPL, unless they offered you funding.

Ever get that feeling that you can't win? ;-)

I don't see how you lose with the GPL, unless you count missing out on
the exciting opportunity to be an unpaid employee of someone else's
corporation, without even getting back improvements made to your code.

That's definitely part of the development plan. But after
looking at Glade and several other designers, our conclusion is that
they all lack something: either flexibility, ease of use, or something
else. Sizers were probably the item that was the most difficult thing
to handle well. The best designer for sizers we found was Qt
Designer. We'd like to make our designer as visually clear as that one.

I'm not sure what sizers are, but why not just add them to Glade?

Also, Dabo is not just a UI toolkit: it's a full 3-tier
application framework. Our major design goal is to integrate the
database connections defined into the UI designer, so that you can
drag and drop fields from the tables in the connection onto the design
surface, and create data-bound controls in one step.

Ehhh, sounds a little too much like javabeans .

 

[Ed Leafe]

Well, those are commercial developers who are afraid of the GPL.

No, they were several members of the Python community. I disagreed
with their interpretation of the GPL, but the fact remains that it was
a major stumbling block to getting others involved.

I don't see how you lose with the GPL, unless you count missing out on
the exciting opportunity to be an unpaid employee of someone else's
corporation, without even getting back improvements made to your code.

The downside is gaining critical mass for the project. Having several
visible Python folks refuse to even look at what we were doing was not
helping things at all. And I think it the chances of someone else using
my code without payment or anything is a pretty small risk. We still
own copyright, which means that while they can use it, they can't claim
it's theirs.

I'm not sure what sizers are

OIC - then this is not going to be very fruitful.

Ehhh, sounds a little too much like javabeans .

No, it sounds like every other development environment for creating
database applications. I looked a long time for something like this in
Python before undertaking the writing of it myself.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[JanC]

Ed Leafe schreef:

I think that the reason things are fragmented in this field is that
none of the tools are simple enough to learn.

Even on Windows, where several well-known and/or easy to use "Rapid GUI &
Database Development Tools" exist (Delphi, VB, Access, Visual FoxPro,
FileMaker, ...), the framework field is fragmented: Microsoft's Win32, MFC
& WTL, Borland's VCL & CLX, wxWidgets, System.Windows.Forms, several Java
frameworks, ...

But even then, if DaBo ever becomes as easy to use as Delphi/VB for this
type of applications, while remaining cross-platform, that might easily
double the number of Python developers. ;-)

 

[Ed Leafe]

But even then, if DaBo ever becomes as easy to use as Delphi/VB for
this
type of applications, while remaining cross-platform, that might easily
double the number of Python developers. ;-)

Well, there are at least a half-million Visual FoxPro developers who
have been hung out to dry by Microsoft, most of whom would love to
leave the land of proprietary closed solutions for a bit of fresh air.
That's where Paul and I came from, and that was our initial motivation
for deciding to develop Dabo - there wasn't a Python tool out there
that could even begin to approach what we were used to with VFP. If we
could get Dabo to the point where someone familiar with VFP or even VB
could become productive in a short time, well, I'm certain that there
will be lots of new blood in these parts. Our work is being followed
very closely by those communities.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[Luke Skywalker]

That's where Paul and I came from, and that was our initial motivation
for deciding to develop Dabo - there wasn't a Python tool out there
that could even begin to approach what we were used to with VFP.

Interesting discussion. I haven't looked at Dabo yet, but the issues
that must be solved before Python is a valid alternative to
proprietary solutions like Delphi or VB are:

- speed where it matters (ie. no 20s load time)

- good RAD (IDE and GUI designer, on par with Delphi or VB)

- high-quality, varied widgets

- good DB connectors

- reasonable footprint (ie. no 20MB program just for a small
appplication; have mercy on users stuck with P3 and dial-up)

- ease of deployment and maintenance (ie. how easy is it for an
application to launch some updated that will fetch updates from the
web)

If Dabo can do all this, it could be a great solution to all those
people Delphi/VFP/VB users whether to go .Net.

Luke.

 

[Ed Leafe]

Interesting discussion. I haven't looked at Dabo yet, but the issues
that must be solved before Python is a valid alternative to
proprietary solutions like Delphi or VB are:

- speed where it matters (ie. no 20s load time)

Load what? The app, or the data? Users don't care how long the app
takes to start up, since they usually run it all day long. Data
response is a whole 'nother matter, and Dabo is extremely fast in that
regard. After all, a data set is nothing more than lists of lists, and
Python is wicked fast with list handling.

- good RAD (IDE and GUI designer, on par with Delphi or VB)

Still in its infancy in Dabo. Would be nice to have a team working on
it, cos there's only so much a single developer who also has a life can
do.

- high-quality, varied widgets

One of the main reason we picked wxPython as our initial toolkit.
Nearly everything we could want is in there, and they look good on all
platforms.

- good DB connectors

That's not something we control. Dabo is designed to use existing
dbapi-compliant connectors, such as MySQLdb. We currently support
MySQL, PostgreSQL, and Firebird. If anyone has a need to link to
another db, the script to do it is pretty well abstracted.

- reasonable footprint (ie. no 20MB program just for a small
appplication; have mercy on users stuck with P3 and dial-up)

Don't know where we'll come in in this regard. Most database apps
require some sort of runtime engine, and we'll be no different.

- ease of deployment and maintenance (ie. how easy is it for an
application to launch some updated that will fetch updates from the
web)

That seems to me more in the domain of apps created with Dabo, not
Dabo itself. Python already has everything you need to do this, but you
need to create the appropriate scripts for your server and your app.

If Dabo can do all this, it could be a great solution to all those

Of course, we're still pretty early in development; we have 0.3
scheduled to be released in the first week of January. But we do have
our sights set pretty high.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/