gschem attribute editor has textentry with small height

[Peter Jacobs]

The attribute editor dialog in gschem 1.6.2.20110115 on Ubuntu 11.10 shows up with its textentry for adding a name=value attribute having too small height. It appears to be only 1 pixel. With some fiddling, it is possible to enter text (but not see it, of course). This problem does not occur on Ubuntu 11.04 with the same revision of gschem so I guess that some behaviour has changed in gtk+.

[Peter Clifton (pcjc2)]

Confirmed - I see this too.

[Peter Clifton (pcjc2)]

Ok, I'm not sure if this is our bug or not, but it appears to be a bad interaction between the GtkTextView widget we use packed inside a GtkScrollWindow widget, with Ubuntu's expanded "overlay scrollbar" feature.

It seems like we don't get a minimum height allocation when the overlay scrollbar is in use, despite the button widget along side our text entry taking up a certain height.

It is true that we don't specify a minimum height for that widget though - and that could well be the underlying problem.

For now, you can work around the issue by starting gschem from the command prompt with:

LIBOVERLAY_SCROLLBAR=0 gschem

[Peter Clifton (pcjc2)]

I'm hesitant to add a fixed minimum-size request in pixels to our code, as that doesn't scale well with different fonts and screen DPIs.

At the very least, we ought to be scaling this based upon the line-height of the font used to render the text, but I'm not immediately sure how to grab that in a non-kludgy way.

In the mean time, we should investigate whether the Ubuntu overlay scrollbar feature is robbing us of a convenient minimum size we ought to be allocated due to the adjacent "Add" button widget.

[Peter Clifton (pcjc2)]

Ok - so we weren't asking for any extra allocated vertical space, nor asking to expand into that which is allocated - presumably because we never allocate any extra size to that part of the dialog, and because the old GtkScrolledWindow implementation always requested enough size to fit the vertical scroll-bar, and that was enough to make things "work" until now.

I think the right fix here is to figure out a text-metric based minimum height for our text widget.

[Peter TB Brett (peter-b)]

I guess changing the flags passed to gtk_table_attach() doesn't help at all?

diff --git a/gschem/src/x_multiattrib.c b/gschem/src/x_multiattrib.c
index ee2a5f9..cd95338 100644
--- a/gschem/src/x_multiattrib.c
+++ b/gschem/src/x_multiattrib.c
@@ -2027,7 +2027,7 @@ static void multiattrib_init(Multiattrib *multiattrib)
   gtk_table_attach (GTK_TABLE (table), label,
       0, 1, 1, 2, 0, 0, 0, 0);
   gtk_table_attach (GTK_TABLE (table), scrolled_win,
- 1, 2, 1, 2, GTK_EXPAND | GTK_FILL, 0, 6, 3);
+ 1, 2, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 6, 3);

   /* - the visible status */
   button = GTK_WIDGET (g_object_new (GTK_TYPE_CHECK_BUTTON,

[Peter Clifton (pcjc2)]

The changed flags aren't a bad idea, but I tried them already - and they don't fix the issue unfortunately.

[Peter TB Brett (peter-b)]

Bumping importance because this affects a lot of people.

[Peter TB Brett (peter-b)]

I've posted a question on StackOverflow to solicit suggestions. ;-)

http://stackoverflow.com/questions/8482505/automatically-sizing-a-gtktextview-in-a-gtkscrolledwindow

[gpleda.org commit robot (gpleda-launchpad-robot)]

A commit was made which affects this bug
git master commit 42182f0ae6b16171329f00f32ff1857d38c1c33e
http://git.gpleda.org/?p=gaf.git;a=commit;h=42182f0ae6b16171329f00f32ff1857d38c1c33e

commit 42182f0ae6b16171329f00f32ff1857d38c1c33e
Author: Peter TB Brett <email address hidden>
Commit: Peter TB Brett <email address hidden>

    gschem: Workaround for zero-height text view bug.

    This is a temporary workaround for a bug on systems using overlay
    scrollbars for GTK+ widgets, where the value editing GtkTextView in
    the multi-attribute editing dialog was appearing with zero height.

    Obviously, setting the height request to a constant size isn't ideal.
    It would be better to set the height request based on the font size,
    so that a certain number of lines are displayed.

    This should be revisited at a later date.

    Affects-bug: lp-876299

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello Peter, is this fixed in 1.8.0 ?

[Peter TB Brett (peter-b)]

Yes (or rather, 1.8.0 contains a work-around).

[Pamir Talazan (pamir-talazan)]

I have this same problem on Ubuntu 12.04

[Launchpad Janitor (janitor)]

This bug was fixed in the package geda-gaf - 1:1.8.1-2

---------------
geda-gaf (1:1.8.1-2) unstable; urgency=low

  * Manually replace directory with symlink in geda.postinst (Closes: #694015)
    Thanks: gregor herrmann <email address hidden>

 -- أحمد المحمودي (Ahmed El-Mahmoudy) <email address hidden> Sun, 20 Jan 2013 22:49:12 +0200

[Matt Rhys-Roberts (mattmoose1969)]

This is still a bug for me; using Ubuntu 12.04 LTS and gschem 1.6.2.20110115 . Can't see any fixes/upgrades in the standard repositories, or am I missing something?

[Felix Ruoff (felixruoff)]

This bug is fixed in the geda-gaf package 1.8.1, which is not in the standard ubuntu-repositories of Ubuntu 12.04 (as you said, the repository-version for Ubuntu 12.04 is 1.6.2).
If you like to use a gschem version without this bug, please donload the latest version (stable) from http://wiki.geda-project.org/geda:download or compile the latest sources from git (see http://wiki.geda-project.org/geda:developer for instructions)

[Ramiro Santiago Leguizamon (leguizars)]

I have installed Ubuntu 12.04 and I have the same problem.

[Tim G (timg11)]

I am new to gEDA, and I see the same issue in gschem.
In the Add Text dialog (Menu / Add / Text) the text entry field is 1 pixel tall.

The Add Attribute dialog from the first post of this thread does not have the problem.

I'm using Ubuntu 16.04 LTS, 64 bit
$ gschem --version
gEDA 1.8.2 (g875406c)

Is this the same issue as before, or a regression? Should I post it as a new bug since it now affects the Add Text dialog?

[Tim G (timg11)]

Screen capture of Add Text dialog issue: https://i.imgur.com/4sbvy5z.png