Re: gEDA-dev: Next gEDA release?

[Ben Jackson <ben-at-NOSPAMben_dot_com>]

On Mon, Dec 10, 2007 at 02:49:32PM -0500, DJ Delorie wrote:
> 
> Can we come up with a list of "must-fix" issues for the gtk hid?  I
> might be able to fix some of them for a release.

That's what I was thinking, but I ran into a lot of issues with just
a little experimenting:

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;

note the duplicate add of the same resource.  Then in the ghid_menu_cb it
ignores resource 0:

      for (vi = 1; vi < node->c; vi++)
        if (resource_type (node->v[vi]) == 10)
          {
#ifdef DEBUG_MENUS
            printf ("    %s\n", node->v[vi].value);
#endif
            hid_parse_actions (node->v[vi].value, NULL);
          }

I ran into this while trying to find the infinite ghid_menu_cb loop.

You see lots of code like this:

  if (in_cb)
    return;
  else
    in_cb = 1;

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.

The problem is that that bandaid is all over in the gtk code and it doesn't
actually work.  There seems to be a case where a callback gets queued by
GTK instead of simply nesting in the call stack (perhaps they did it
explicitly to avoid deep recursion).  When that happens, the GTK HID can
cause itself to loop with callbacks triggering non-nested callbacks.

Other problems I saw (no particular severity order):

	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)

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

	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)

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

	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)

	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.

	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.

	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.

	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.

	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.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/


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