Re: Help out with Dia (was Re: Minor dia build error?)

[Cyrille Chepelov <cyrille chepelov org>]

Le Sun, Jun 23, 2002, à 03:58:34PM +0100, Andrew Ferrier a écrit:

> I know this isn't a lot to go on, but could someone suggest a
> part of Dia that could do with some work, and fulfills the
> following (possibly contradictory and unhelpful) objectives:
> 
> 1. Doesn't conflict with anything else anyone is doing for a
> while.
> 
> 2. Is small enough for me to complete fairly rapidly.
> 
> 3. Would be useful but is not critical to the project progress
> (would hate to hold anything up as it will be a learning
> process for me and progress will be patchy --- no pun
> intended).
> 
> 4. Doesn't have too many toolkits/languages I would have to
> learn all at once.


To add to Lars' reply (which is the canonically right reply), I wish to add
a couple things (which ought to be in the Bugzilla too); difficulty * =
easy, *** = medium/advanced, ***** = difficult. OK, I quote the bugzilla a
little.

	* --version command-line option (good to learn the popt API)	
 	* Review all dialog boxes to comply with the GNOME HIG [0] chapter
on application dialog boxes. Can be done one dialog box at a time.
	* #85726 (whoops, just needs merging)
	** Variation on the theme of #85726: load the AUTHORS file to build
the authors[] array (perhaps reformatting the file to make it more suitable
to machine processing).
	** #61644 or a variation thereof; basically, make the connection
points "attract" handles being moved (with a configurable radius), and give
visual feedback when such an attraction is taking place.
	** Rewrite the implementation of
lib/message.c/gtk_message_internal(), so that instead of spitting out one
dialog box per error/warning, it would have only one dialog box with a
scrollbar, filter buttons ("hide warnings" etc.), and would do event
compression (instead of displaying
		foo
		foo
		foo
		foo
it would display
		foo
		(last message was repeated three times)
(like syslog does)) (#56117)

	** clean all objects of the old ad-hoc Defaults code whenever they
have basic StdProp (ie, get/set/describe props methods are here); Hans'
object defaults code now takes care of this in a better and leaner way, and
is persistent to boot (basically, all it takes is removing whatever has the
word "defaults" in an object which looks like objects/FS/flow.c to bring it
closer to something like objects/ER/entity.c)
	*** clean all "StdProp generation 1" objects of their ad-hoc
copy/load/save methods to make them "lean StdProp" (for instance, take 
objects/ER/entity.c and bring it closer to objects/UML/small_package.c; 
making sure the on-disk structure doesn't change in the process)
	**** kill the remaining non-StdPropness (except UML/class.c)
	******* kill the remaining non-StdPropness (UML/class.c)

The best way to proceed afterwards is to attach patches to the bugzilla,
renaming the summary to [PATCH] foooo (not using the keywords -- this is a
bit too awkward to use in practice). For improvements which are not
registered in the Bugzilla, the best thing is to open an enhancement bug,
and attach the patch right away.

Lars and I (and I believe, Hans) receive a message for every transaction
done to the bugzilla (including the never-ending flow of #52836 duplicates...).

	-- Cyrille

-- 
Grumpf.