The Mynydd Factor - Review of Gideon

[Ian Wadham]

Hello Alexander,

And thank you for taking the time to comment on my
review of Gideon.  What you wrote might be summed
up by an American saying and an English one.

    "It's hard to think of draining the swamp when you
      are up to your neck in alligators".

    "If you want a thing done, do it yourself".

Please believe that I understand your position exactly.
I have worked in many roles on many projects, but on
this one I am an end-user.

----- Original Message ----- 
From: "Alexander Dymo" <cloudtemple at mksat.net>
Sent: Sunday, September 28, 2003 10:43 PM


> If you could proof read and improve any of
> QToolTip::add( ....
>
> Tips of the day are outdated. Another area for you to improve...
>
Well, I've been helping Bernd Pol and just sent him a chapter
on how (I think) to use Automake Manager.  I know far too little
to write tips of the day and much too little to feel safe to hop in
and scan or alter your code (sweat ... I might break something).
But I could send you an email with suggested "before and after"
texts for some of the tooltips and WhatsThis messages.  Would
that help?

> > So most of Gideon's buttons are unintelligible, which means you have to
> > hover over them with the mouse and wait for the tooltip to come up, thus
it
> > would be quicker to use menus (preferably popup) or text buttons
>
> Agree, I often use menus by myself ;).
>
Great!  I wrote my chapter that way (sigh of relief ...).  Tip of the day:
In Automake Manager use the right mouse button and popup menus.

> > The next problem is that the two Managers are almost invisible in the
user
> > interface
>
> I don't know how to provide a menu for them. Their actions are too
dependent
> on currently selected objects.  I can only see a top level menu with
> "Automake Manager"
> "Bookmarts"
> "File Selector"
> etc.  entries.  Can you suggest how to call this menu.
>
You're right.  I had not thought this through.  Actually the Automake
Manager
interface is object-oriented in the sense that the original Xerox PARC GUIs
were, i.e. you select an object --- a sub-project, target or file --- then
you
select a function to perform on it (using the right mouse-button to achieve
this effect in Automake Manager).  I think this a more natural way to work
than the usual select a function then select an object to perform it on: so,
in
spite of all the harsh things I said, I'd like to shake the AM designer by
the
hand !  In the real world, I see what needs some work (a low-hanging
tree branch), then I select the tool to do it (a saw).

This approach does not need a drop-down menu (Xerox PARC did not have
one).  I would suggest therefore that Automake Manager (or whatever it is
called finally) should be a line on either the Project or the Build menu,
just
to give it a bit more visibility.

> > In Gideon, some direct edits seem to "take" in Automake Manager and some
do
> > not. Are there rules for this? Does it matter if Automake Manager gets
out
> > of synch with the actual ".am" files? How can we Gideon users be sure?
>
> This should be documented. Automake manager in KDevelop will retain
everything
> you write in Makefile.am when the project is not opened.
> Updates in Makefile.am don't syncronized with KDevelop if the project is
> opened.  Same for QMake.
>
So, if I Close Project, edit Makefile.am manually and Open Project, Automake
Manager re-adjusts its display to correspond to what is in the
Makefile.am's?
Please confirm.  Also, is the same true if you Close KDevelop while a
project is open, edit Makefile.am manually and re-start KDevelop?  Please
confirm.  I'll see that it gets into the KDevelop 3 User Manual.

On another topic, I am never sure whether to go right back through Automake
and friends, Configure and Build Project after playing in Automake Manager,
or whether to do a Distclean or Clean Project first.  Can you explain?  I
think
that should be clarified in the User Manual too.

> #62288 was correctly closed because it is not the problem of KDevelop
> but a problem of your configure.in (.in) or admin/acinclude.m4.in.
>
Those files, whatever they are, are generated for me by Gideon.  If
LIB_KDEGAMES is not in those files, that is a Gideon problem, from
my point of view.  A related problem exists if I mis-type a known
library name as LIB_KDEIU.  Gideon does not validate it.

If the maintainers of the "admin" files are responsible for putting
LIB_KDEGAMES in the files, please re-assign the bug (part of
it, at least) to them.  I do not know who they are or what their
package is called.  All I do know is that kdegames lib is part of the
standard KDE distribution now and should be recognised in Gideon.

> About symbolic names and default installation locations: just write an
> explanation and we will be glad to put it in.
>
Re bugs 62289 and 62291, maybe I will close them.  I did
not know or expect that anyone other than the maintainer could.  Then
maybe I'll write some new bugs and wishlists to clarify and separate
the issues.  Is that what you require?

> Btw, don't expect a solution for your bugs in a short time.
>
I don't.  Though I think Gideon (or the admin files) should
recognise *all* KDE libraries in KDE 3.2 --- and validation
of correct typing of symbols would be good if you can do
it in time.  The other issues are more of a next-version thing.

All the best, Ian W.


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«