Re: gEDA-dev: Next gEDA release?

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

On Mon, 2007-12-10 at 12:25 -0800, Ben Jackson wrote:

> Why are there snippets like this everywhere:
> 
>       ar = resource_create (0);
>       sprintf (av, "ToggleView(%d)", i + 1);
>       resource_add_val (ar, 0, strdup (av), 0);
>       resource_add_val (ar, 0, strdup (av), 0);
>       ar->flags |= FLAG_V;
>       layerview_resources[i] = ar;

The support for configurable menus was only recently added to the GTK
HID, and may still have bugs to iron out, granted.

Having looked at the menu code, I'm confused by it. I think Dan will
have a better chance of fixing this!

> You see lots of code like this:
> 
>   if (in_cb)
>     return;
>   else
>     in_cb = 1;

Hmm... there should be ways to avoid this sort of evil.

> trying to avoid having cb from cb (due to the cb forcing states).  This
> is the problem that is solved in Motif with functions like XmListSelectItem
> taking a final boolean that says whether to invoke callbacks.  I am
> surprised that gtk doesn't have a similar mechanism.

There are probably ways to freeze signal emission, but I've never seen
them required for normal code. This is presumably an issue of the
difference between the user hitting a button / check box, or
pragmatically selecting a the current state.

You can usually hook either a "toggled" or "clicked" type signal, and it
would be useful to check the button's actual state in the handler.

> 	Mousing in and out of the work area causes the display to jump.
> 	I've tried the available patches and none fix it.
>
> 	The window grows several times in normal usage, due to the
> 	status line getting wider (eg when you start drawing a line
> 	and it places an initial mark)

That is a particularly annoying one. The default widget layout can be
altered in the preferences menu, under "General". I changed the defaults
for the CUED build. Not everyone has a wide-screen monitor!

I also did some work on a "packing" widget, which almost worked.. but
did rely on some evil size-allocation stuff. GTK doesn't do height for
width allocation, so I wrote a hack which would try to fake it by
changing a widget's size-request at various points, and seeing what
would fit.

I was starting to use this as a container for packing the main menu bar,
coordinate views, mm/mils button etc.., but I was pointed towards the
alternate layouts.. these removed my immediate need to fix the issue.

> 	All subwindows open up very small (stock Ubuntu desktop setup)

We could do with some default sizes in the code, possibly combined with
a patch like Ivan and I did for gschem, to auto-save dialog positions.

> 	There are log window messages at startup, making it one of those
> 	annoying applications that opens and immediately obscures itself
> 	with a log window (gschem does this too)

This can be turned off in gschem (thank goodness). I'd welcome a patch
for the same in PCB, and perhaps some more friendly defaults to make
that the usual case for both applications.

> 	I think the mouse buttons are wrong.  Of course if people are used
> 	to them, we're kind of doomed.

I mostly copied the scroll-wheel zoom behaviour in gschem from PCB. Soon
after realising every other GTK app does it differently, I changed my
mind.. but the idea of changing it didn't wasn't warmly received. Sadly,
this will lead to more config options - although hopefully I'll be
allowed to set the normal GTK app defaults.

> 	The netlist window flickers when NetlistShow is invoked, even on
> 	the same net.
> 
> 	Using 'tab' to flip the board moves you to a random part of the
> 	other side, not the part you're looking at.
> 
> 	When showing the back side, the vertical scrollback works backwards
> 	(just like it used to in lesstif)

Works for me.. but I do have an extra patch applied to the last release
version. (I posted it to the list before).

> 	The mouseover-hilite color of the layer visibility buttons is the
> 	same as the selected color, so when you click on them, nothing
> 	appears to happen.

Just need to change the prelight style's colour. Not too difficult.

> 	If you tear off the shown layers menu and start turning them all
> 	off, some will fail to turn off on the first click (it 'bounces'
> 	and the layer toggles twice) and when I get to layer 8, I get
> 	an infinite loop as described above.

Gah.. I see it now.

> 	The redraw performance is abysmal in certain cases.  I accidentally
> 	moved a mostly-connected QFP208 with rubberbanding on and non-thin-
> 	drawn and it took 30+ seconds to finish the move before I could
> 	undo and wait another 30+ seconds.  In the lesstif hid this would
> 	have taken a fraction of a second.

Given the GDK calls are a thin wrapper on to XLib, it probably means a
bug in the HID code. I found this old thread:
http://seul.org/pipermail/geda-dev/2006-August/000354.html
Did the patch ever get applied? I realise this patch was for copying
stuff, but are we looking for similar issues?

> 	When you load a board you can be more zoomed out than the hid will
> 	later allow you to if you zoom in and out again.

I'm not sure why, but this also bugs me... I feel "trapped" not being
able to zoom out further, even if I don't "need" to.

> 	Cancelling line drawing doesn't clear the mark (may also be in
> 	lesstif)
> 
> 	I suspect bad things would happen to the layout if you had a lot
> 	of layers.  The notion of showing all layers on the upper left
> 	doesn't scale.  The tools and route sizes should get priority,
> 	for one thing.

Most PCB layout GUIs I've seen put the layer in a drop-down menu (like
Autocad does with its pens). You can right click objects (tracks etc..)
and change their layer from a similar drop-down menu. Similar menus
usually exist for track width.



-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev