Re: gripes, etc.

[Ahmad Baitalmal <ahmad bitbuilder com>]

Andrew Sutton wrote:

39B32DD9.59AFD85A@home.com">

i spent the greater portion of the day looking for an application that
would let me do something like rational's modeler (class diagrams, use
cases, etc.). this led me on a long quest of installing around 30
different libraries, applications and api's. finally, i gave up, finding
no application that provided the flexibility i was looking for, and
considered writing one for gnome - mainly because there's lots of
re-usable software out there, but found some basic problems with the
gnome conceptual model (for lack of a better description). this is a
brief list of gripes for gnome...

1. there's no roadmap.

i looked all over gnome.org for some kind of a product roadmap. i picked
up the major categories of development (desktop, office and
development), but there's nothing that seems to tie those together. any
developer can walk thru the product list and pick out back-end,
middleware, and user interface software, but it's confusing and time
consuming.

2. i couldn't find any evidence of a steering commitee.

i found a couple of primary developers - but that doesn't seem to be
quite the same. it left me questioning the future direction of the gnome
component model and the directions that various applications are taking.
for example, what's going to happen when corba 3 comes out. it defines a
component model - a very comprehensive one too - i scanned thru the 500
page spec a while ago.

3. no middle ground documentation

every piece of documentation i read on gnome.org and went from screen
shots with brief capability descriptions to header files and
documentation of function calls. the task of learning gtk and gnome is,
for lack of a better word, a little daunting. especially, after coming
home from a long day of coding for different systems. in short, there's
either too little or too much documentation. somebody needs to draw the
object model for gtk and gnome (since they're so obect oriented). uml or
booch would be perfect. the learning curve for new developers can be
significantly reduced (assuming they can figure out the notation).

4. i still didn't solve my problem

just a gripe in general. i think the linux development community could
definitely benefit from a design tool like rational's modeller. imagine,
making the right decisions early can save you from complete rewrites
later (as technologies change and evolve). so, if there's one in the
works... great!, otherwise... um... anybody want to write one? i have
limited (read none) gnome development experience, but i can definitely
contribute solid ideas.

imagine the possibilities... integrated development envirionment with
design, gui development (glade), code generation, documentation
generation, code editing (wouldn't be much of an ide without it),
requirement tracking, bug tracking, configuration management... just
thinking big :)

comments, questions?

Andrew Sutton
asutton21@home.com


_______________________________________________
gnome-devel-list mailing list
gnome-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Dear Mr. Big Thinker :)
    I've been through the phaze you are in right now about a year ago. I
 got frustrated and longed for the comforts of Win32. Not to mention the
 belittleing you get if you ask "De expoits", ("You mean you don't know how
 to grep? Duh..") :)

As far as development environments, it seems that everyone is VERY happy
 with Emacs, vi, etc... for everything ( even for UML ). I've spent days
 looking for tools I assumed they existed. They must exist, I told my self,
 but usually you are the first ask. 

The developers have done a wonderfull job, but no one (almost) is getting
 paid for doing this and all of it has been built in "after-hours-overtime".
 So if you can't find it, Build It.

I do believe that the most powerful thing that we as developers can provide
 is a full set of development tools. The way I see it, the more time a developer
 spends trying to figure out how to deal with his/her development environment,
 the less time he/she spend in developing something useful.

What ever we come up with should address future problems and not just porting
 solution from Win32. CORBA 3 is a good example. If we want to kick some
 behind, the tools we build should be oriented to take full advantage of
 these new standards. We should not be playing catch up with Win32, we should
 get a leg up.

Well, I guess I know what I'll do next. A roadmap my friend. I'll post it
 up a draft @ BitBuilder.com and let's start poking it and getting some feed
 back in.

Please excuse the spelling :)

-- 
Ahmadster
www.BitBuilder.com