gEDA-dev: New autonumber text dialog

[Werner Hoch]

Hi Tomaz,

On Tuesday 31 October 2006 08:56, Tomaz Solc wrote:
> > Ok let's twist your brain ;-):
> > The patch at SF has an error:
> > The sortorder "right to left" sorts the "bottom up" the wrong way.
> > If the x-coordinate is the same the lower symbols are numbered
> > first. Same thing happens with the "bottom up" sort order. If the
> > y-coordinate is the same the right symbols are numbered first
> > instead of the left.
>
> I thought that was intentional (that way "right to left" is exactly
> the opposite of the "left to right" sort).
>
> Also I don't see that as a problem. Usually when numbering nets or
> pins (where I would use reverse sort orders) you only have one row or
> one column.

Think about a matrix of diodes or resistors. I wouldn't like the current 
numbering.

> > BTW. Against witch CVS-branch should it be? And my current patch of
> > the autonumber backend is not in CVS yet. And the patch is not
> > against the current CVS =:-(
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1555067&gr
> >oup_id=161080&atid=818428
>
> Hm. I'm currently using your patch with the main branch (trunk). I
> only had to resolve one conflict by hand.

Great.

> > Some things I don't like of generated dialogs:
> > * dialogs are fixed, you cannot change the dialog within the
> > programm example: lots of key-value pairs in a dynamic generated
> > option dialog.
>
> In that case you can make the static part with Glade and still fill
> in the dynamic part with your code. I think that is still easier than
> making the whole thing by hand.
>
> > * glade limits the dialog creation to it's init state. You have to
> >   create extra functions for populating the dialog with data.
> >   You need an extra function for each dialog.
>
> I don't see that as a problem since the other function (the one that
> sets up the dialog) is already written for you. So again you only
> write on function.
>
> > * and maybe doxygen won't work
> >
> >> A lot of applications use Glade for their GUI today and I think
> >> most of them use either libglade or glade-generated C code without
> >> modifications. After all that is the way Glade was intended to be
> >> used.
> >
> > As stated above. I've not used it that way. Whenever I changed a
> > glade generated dialog, I've used a diff utility to merge the new
> > elements from the glade code into the current C code.
>
> It is usually considered a good practice to keep the GUI code and the
> engine code as separate as possible.

I agree. Partly. If we use generated code then there should be no need 
to change the dialog code itself.

I'll take a look at your patch at SF and let you know what I think about 
it.

Regards
Werner