Why C/C++? Check out Kiwi, PyGTK and libglade.
on
Glade 2 Tutorial
·
· Score: 1
I was a bit surprised to see the example application was written (of all things) in C. Besides being harder and taking longer to write, it's too hard to change (and going to be flaky since a SEGV is so much easier to hit.)
I've done some work on a framework for PyGTK (0.6 only for the moment, but GTK+2 support is coming) that makes writing an app like this one trivial. In fact, the examples include a temperature converter app (`just like ye ole Mr. Raskin said'). The code is so tiny it can fit in a/. comment:
Well, let's put it in another light. Mozilla is a very large project: much larger than the Linux kernel, by all counts, and it fosters a lot of different kinda of tasks than just "development". There is QA, which does the chores that we ignore or accumulate in most projects, and documenters, and people supporting users on IRC, and standards work. So while you say this is wasted effort, I say it keeps the project going, and helps distill quality from milestone to milestone. There are regressions, sure; the fact remains: this is not a toy project anymore, but a huge one. The largest we've engaged in open source, possibly.
So while your general view is probably correct - yes, we have too much beaurocracy in software development - you shouldn't forget that very large projects tend to be hard to avoid falling apart by themselves. Process isn't _just_ beaurocracy; it just _usually is_.
Let's look at the Linux kernel, for an example of a large project gone bezerk from lack of process. We now have no idea what is going on from release to release beyond ChangeLogs, there are no public CVS repositories to query changes, the review process it completely informal and unguaranteed, and there isn't even a bugtracker for users to query on current status and fixes. That's very bad for us Linux users, IMO. But because the process is highly centralized and hasn't changed for ages, it's stagnated.
The fact that a project has very good developers can postpone problems, as can the amount of goodwill in a project. But sometimes sooner than later a project will have trouble scaling. When yours does, look at mozilla for good ideas.
For now, tough luck. Brazil has a couple of banks with broken Java or DHTML interfaces. IMHO it's the banks that are wrong - they make damn interfaces that are too complicated, and never worry about standards.
Advice: choose a bank with a better policy towards W3C standards.
Slashdot Mirror
I was a bit surprised to see the example application was written (of all things) in C. Besides being harder and taking longer to write, it's too hard to change (and going to be flaky since a SEGV is so much easier to hit.)
/. comment:
:-) Docs and code available under the LGPL: http://www.async.com.br/projects/kiwi/
I've done some work on a framework for PyGTK (0.6 only for the moment, but GTK+2 support is coming) that makes writing an app like this one trivial. In fact, the examples include a temperature converter app (`just like ye ole Mr. Raskin said'). The code is so tiny it can fit in a
from Kiwi import Delegates, FrameWork, mainquit
class Farenheit(Delegates.GladeDelegate):
widgets = ["quitbutton", "temperature",
"celsius", "farenheit" ]
def __init__(self):
Delegates.GladeDelegate.__init__(self,
"faren", delete_handler=mainquit)
def convert_temperature(self, temp):
farenheit = (temp * 9/5.0) + 32
celsius = (temp - 32) * 5/9.0
return farenheit, celsius
def clear_temperature(self):
self.farenheit.set_text("")
self.celsius.set_text("")
def on_quitbutton__clicked(self, *args):
self.view.hide_and_quit()
def after_temperature__changed(self, entry, *args):
temp = entry.get_text().strip() or None
if temp is None:
self.clear_temperature()
else:
farenheit, celsius = self.convert_temperature(float(temp))
self.farenheit.set_text("%.2f" % farenheit)
self.celsius.set_text("%.2f" % celsius)
delegate = Farenheit()
delegate.show_and_loop()
It's Python, of course
I wonder if this is a meta-April Fools dupe, because it's simply ridiculous.
Well, let's put it in another light. Mozilla is a very large project: much larger than the Linux kernel, by all counts, and it fosters a lot of different kinda of tasks than just "development". There is QA, which does the chores that we ignore or accumulate in most projects, and documenters, and people supporting users on IRC, and standards work. So while you say this is wasted effort, I say it keeps the project going, and helps distill quality from milestone to milestone. There are regressions, sure; the fact remains: this is not a toy project anymore, but a huge one. The largest we've engaged in open source, possibly.
So while your general view is probably correct - yes, we have too much beaurocracy in software development - you shouldn't forget that very large projects tend to be hard to avoid falling apart by themselves. Process isn't _just_ beaurocracy; it just _usually is_.
Let's look at the Linux kernel, for an example of a large project gone bezerk from lack of process. We now have no idea what is going on from release to release beyond ChangeLogs, there are no public CVS repositories to query changes, the review process it completely informal and unguaranteed, and there isn't even a bugtracker for users to query on current status and fixes. That's very bad for us Linux users, IMO. But because the process is highly centralized and hasn't changed for ages, it's stagnated.
The fact that a project has very good developers can postpone problems, as can the amount of goodwill in a project. But sometimes sooner than later a project will have trouble scaling. When yours does, look at mozilla for good ideas.
For now, tough luck. Brazil has a couple of banks with broken Java or DHTML interfaces. IMHO it's the banks that are wrong - they make damn interfaces that are too complicated, and never worry about standards. Advice: choose a bank with a better policy towards W3C standards.