gschem: window redrawing problem related to right side bar

[Richard Rasker]

One of gschem's latest new features, the Object and Text attribute side bar to the right, appears to have triggered a bug related to redrawing the main window's contents.

I can reliably replicate this bug as follows (Linux Mint 17.2 64-bit, KDE, proprietary nVidia graphics drivers):
1. Start gschem; right side bar and bottom tab windows appear, everything works fine.
2. Maximize the main window.

Gschem now appears to be almost completely unresponsive, and switching to a different application/desktop and back results in a blank main window.
The main window is only redrawn when scrolling the mouse wheel, but this doesn't stop the redraw problem.

The way to stop this behaviour is to drag the border between the main viewport and the right side bar to the right until the side bar is completely out of view. After this, everything is back to normal again, even after dragging the border back to make the side bar visible again.

[Edward Hennessy (ehennes)]

I'm unable to reproduce on Ubuntu 14.04 LTS, Gnome, VMWare graphics. I'll create another VM with Linux Mint and KDE.

[Richard Rasker (rasker-a)]

Edward Hennessy schreef op za 15-08-2015 om 19:39 [+0000]:
> I'm unable to reproduce on Ubuntu 14.04 LTS, Gnome, VMWare graphics.
> I'll create another VM with Linux Mint and KDE.

Hello Edward,
In the meantime I tried several versions of the nVidia proprietary
driver, combined with several KDE-specific environment settings(*) to
prevent tearing, but to no avail.
Currently, I use the nVidia driver version 346.82, but the problem also
occurs with nvidia-340.76.

*: Most notably the following:
In /etc/environment:
CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True
(disabled right now, but to no avail)

So summarizing: Linux Mint 17.2 KDE 64-bit + nVidia 346.82:
still this window redraw problem.

If there's any way that I can provide more information, please let me
know. Some time next week, I'll install a new Linux Mint machine, and
I'll do a gEDA test install there to see if I can replicate this on a
pristine machine.

Best regards,

Richard Rasker

[Edward Hennessy (ehennes)]

I'm also unable to reproduce in Linux Mint 17.2, KDE, and VMWare graphics.

What is your screen resolution? I'll try changing to that and re-test.

Also, can you try the following:

1. Start gschem
2. Alter the zoom (in or out)
3. Maximize the main window

It is your procedure to replicate the issue, but with a zoom in the middle. I'm thinking it could be a set of parameters sent to the zoom code that could be contributing.

Ed

[Richard Rasker (rasker-a)]

Edward Hennessy schreef op zo 16-08-2015 om 00:53 [+0000]:
> I'm also unable to reproduce in Linux Mint 17.2, KDE, and VMWare
> graphics.
>
> What is your screen resolution? I'll try changing to that and re-test.

I have a dual-screen setup, with one screen 1680 x 1050, and the other
1280 x 1024.

> Also, can you try the following:
>
> 1. Start gschem
> 2. Alter the zoom (in or out)
> 3. Maximize the main window
>
> It is your procedure to replicate the issue, but with a zoom in the
> middle. I'm thinking it could be a set of parameters sent to the zoom
> code that could be contributing.

Step 2 can be anything, except enlarging (and that includes maximizing)
the main window.
However, I found another way to trigger the bug, yielding a little more
information:

1. Start gschem
2. Enlarge the main window by dragging one of the borders in an outward
direction.

After a few pixels, the border stops moving, the mouse cursor detaches
from the border, and gschem freezes. From a cold start of gschem, this
happens when the main window reaches a width of 1278 pixels or a height
of 985 pixels, although I don't believe that these dimensions have any
particular significance (see below). Attached you find an example of a
gschem window with this width, showing a blank area where an overlapping
window was closed and gschem failed to redraw.

I also notice that this happens only when BOTH the bottom and right
tabbed windows are visible. Even when the main window is much smaller,
the bug is triggered as soon as I start dragging the borders.

As said, I can make gschem snap out of it by scrolling the mouse wheel
in the main viewport, and then drag the right window into invisibility
-- and I find this also works with the bottom window. Then I can restore
both edge widows and work without problems -- until I resize the main
window again, that is.

If there's any way that I can start gschem in some sort of debug or
trace mode to obtain more information, please let me know.

Best regards,

Richard Rasker

[Edward Hennessy (ehennes)]

Thank you for gathering that information. With that new mechanism you found to replicate the bug, I suspect that it isn't in the zoom code.

There is a preprocessor macro, DEBUG, that can be set. However, looking at the information that it provides, it might not be much use here.

If gschem gets in this failure mode, can you move the mouse wheel, but then use the keybindings instead of dragging the sidebar, to restore normal operation? (The keybindings to show and hide the windows were added to the trunk recently.)

Ed

[Richard Rasker (rasker-a)]

Edward Hennessy schreef op di 18-08-2015 om 15:41 [+0000]:
> Thank you for gathering that information. With that new mechanism you
> found to replicate the bug, I suspect that it isn't in the zoom code.
>
> There is a preprocessor macro, DEBUG, that can be set. However, looking
> at the information that it provides, it might not be much use here.
>
> If gschem gets in this failure mode, can you move the mouse wheel, but
> then use the keybindings instead of dragging the sidebar, to restore
> normal operation? (The keybindings to show and hide the windows were
> added to the trunk recently.)

Hello Ed,

I've been trying to compile the latest git version of gEDA/GAF to test
the above, but that fails. Somehow, ./configure can't find guile 2.0
even though it is installed:

        configure: error: you need at least version 2.0.0 of guile

        > which guile
        /usr/bin/guile

        > ls -l /usr/bin/guile
        lrwxrwxrwx 1 root root 23 aug 21 10:39 /usr/bin/guile -> /etc/alternatives/guile

        > ls -l /etc/alternatives/guile
        lrwxrwxrwx 1 root root 18 aug 21 10:39 /etc/alternatives/guile -> /usr/bin/guile-2.0

As I'm not really a compiler guru, I think I'll just wait until the
latest changes pop up in the normal updates. If there's anything new
that I can report, I will do so.
For the time being, I can use gschem, just as long as I'm careful not to
resize the main window too often.

Best regards,

Richard Rasker

[Peter TB Brett (peter-b)]

Hi Richard,

Have you got all of the development packages you need installed?

You may need to install the guile-2.0-dev package.

                            Peter

[Richard Rasker (rasker-a)]

Peter TB Brett schreef op vr 21-08-2015 om 09:13 [+0000]:
> Hi Richard,
>
> Have you got all of the development packages you need installed?
>
> You may need to install the guile-2.0-dev package.
>

Ah, yes, of course .... the development packages ... Damn that modern
Linux, everything works out of the box, the last time I needed to
compile something was a few years ago :-)

Anyway, I got it to compile without errors, but can I test this newly
compiled version without do the 'make install' step?
I can't afford to end up with a broken gschem installation, since I'm
using it on an almost daily basis.

I tried simply executing gschem/src/gschem from within the ~/geda-gaf
directory, but that results in an error message:

        > gschem/src/gschem
        Backtrace:
        In ice-9/boot-9.scm:
         157: 1 [catch #t #<catch-closure 1424400> ...]
        In unknown file:
           ?: 0 [apply-smob/1 #<catch-closure 1424400>]

        ERROR: In procedure apply-smob/1:
        ERROR: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f

I can't find any testing

It's probably once again my clumsiness (not to mention cluelessness)
with regard to software development, but I have no idea how to test-run
a freshly compiled target, or even if that is possible at all.

Anyway, thanks already for the heads-up about development packages,
stupid of me to forget.

Best regards

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

Hi, Richard.

On Fri, Aug 21, 2015 at 10:06:48AM -0000, Richard Rasker wrote:
...
> I tried simply executing gschem/src/gschem from within the ~/geda-gaf
> directory, but that results in an error message:
>
> > gschem/src/gschem
> Backtrace:
> In ice-9/boot-9.scm:
> 157: 1 [catch #t #<catch-closure 1424400> ...]
> In unknown file:
> ?: 0 [apply-smob/1 #<catch-closure 1424400>]
>
> ERROR: In procedure apply-smob/1:
> ERROR: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f

Could you pull the latest git sources and try once again?
I've just pushed a couple of patches. Perhaps, something will change.

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op za 22-08-2015 om 11:19 [+0000]:
> Hi, Richard.
>
> On Fri, Aug 21, 2015 at 10:06:48AM -0000, Richard Rasker wrote:
> ...
> > I tried simply executing gschem/src/gschem from within the ~/geda-gaf
> > directory, but that results in an error message:
> >
> > > gschem/src/gschem
> > Backtrace:
> > In ice-9/boot-9.scm:
> > 157: 1 [catch #t #<catch-closure 1424400> ...]
> > In unknown file:
> > ?: 0 [apply-smob/1 #<catch-closure 1424400>]
> >
> > ERROR: In procedure apply-smob/1:
> > ERROR: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f
>
> Could you pull the latest git sources and try once again?
> I've just pushed a couple of patches. Perhaps, something will change.

Nope, compiling works OK, but the compiled gschem target still crashes
with the exact same error message, albeit with a different number
(215b400 instead of 1424400) -- but I guess that this is a memory
location or some other less relevant identifier.

Best regards,

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

On Sat, Aug 22, 2015 at 12:11:18PM -0000, Richard Rasker wrote:
> Vladimir Zhbanov schreef op za 22-08-2015 om 11:19 [+0000]:
...
> > Could you pull the latest git sources and try once again?
> > I've just pushed a couple of patches. Perhaps, something will change.
>
> Nope, compiling works OK, but the compiled gschem target still crashes
> with the exact same error message, albeit with a different number
> (215b400 instead of 1424400) -- but I guess that this is a memory
> location or some other less relevant identifier.

Try to uninstall the geda packages you have installed. You'll be able
to install them again any time you want using your package manager after
doing 'make uninstall' in the source repository. I've just tried to
install the Debian geda version and got the same result you have after
doing 'gschem/src/gschem'.

I think the problem could be in the way Debian/Ubuntu places its rc
files and/or the place where gschem searches for them. Probably some
setting of the environment variable GEDADATA could help. I didn't try
setting it though.

In your case, you could also try to configure with another prefix, say
'./configure --prefix=/tmp/gEDA' and run /tmp/gEDA/bin/gschem. This
should work.

Cheers,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op za 22-08-2015 om 16:13 [+0000]:
> On Sat, Aug 22, 2015 at 12:11:18PM -0000, Richard Rasker wrote:
> > Vladimir Zhbanov schreef op za 22-08-2015 om 11:19 [+0000]:
> ...
> > > Could you pull the latest git sources and try once again?
> > > I've just pushed a couple of patches. Perhaps, something will change.
> >
> > Nope, compiling works OK, but the compiled gschem target still crashes
> > with the exact same error message, albeit with a different number
> > (215b400 instead of 1424400) -- but I guess that this is a memory
> > location or some other less relevant identifier.
>
> Try to uninstall the geda packages you have installed. You'll be able
> to install them again any time you want using your package manager after
> doing 'make uninstall' in the source repository. I've just tried to
> install the Debian geda version and got the same result you have after
> doing 'gschem/src/gschem'.
>
> I think the problem could be in the way Debian/Ubuntu places its rc
> files and/or the place where gschem searches for them. Probably some
> setting of the environment variable GEDADATA could help. I didn't try
> setting it though.
>
> In your case, you could also try to configure with another prefix, say
> './configure --prefix=/tmp/gEDA' and run /tmp/gEDA/bin/gschem. This
> should work.

Ah, yes, finally, gschem starts as expected, and yes, now I have the V A
and V S key bindings to toggle visibility of the side bar and the status
bar respectively.

However, nothing has changed yet with respect to the original bug (the
freeze/redraw problem), but now I can at least confirm that hiding
either the side bar or the status bar via the menu or the key bindings
temporarily solves the problem, almost in the same way as dragging it
out of view. The only difference is that with one of the two screen
items disabled, I can keep resizing the main window without problems
(just dragging it out of view isn't as effective, because it becomes
visible again as soon as I enlarge the main window). As soon as both
items are visible, the bug crops up again.

Just to make sure, I also disabled all personal settings by temporarily
renaming de .gEDA directory (which contains gschemrc among other
things), but that also doesn't make any difference.

So in summary: only when BOTH the side bar and the status window are
visible does the bug manifest, and then only when resizing the main
window. When either of the two screen elements is hidden in any way, or
when I do not resize the main window, there is no problem.

Next, I also installed gEDA/gschem on a laptop that I just reinstalled
with Linux Mint 17.1, especially for this purpose. Here too, I can
replicate the bug, so it most definitely has nothing to do with the
machine I'm working on -- the laptop has a different hardware
architecture (32-bit instead of 64-bit) and a different graphics
controller (AMD/ATI instead of nVidia).

Then, as a last try, I changed my system locale from Dutch (NL) to US
English, and rebooted once again for good measure -- but to no avail.

So this is really, really weird. I appear to be the only one who can
very consistently replicate this bug, on either one of two com...

[Vladimir Zhbanov (vzhbanov)]

Hi, Richard.

Could you check the same steps in another DE/WM. I just tried running
gschem in XFCE, and it redraws widgets too slowly compared with my
tailing wm dwm.

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op za 22-08-2015 om 21:22 [+0000]:
> Hi, Richard.
>
> Could you check the same steps in another DE/WM. I just tried running
> gschem in XFCE, and it redraws widgets too slowly compared with my
> tailing wm dwm.

I can't seem to install XCFE, but the bug is also manifest in OpenBox,
albeit with a small difference: when resizing the window by dragging,
the actual main window resize is completed (in KDE, once the mouse
cursor detaches from the main window, the size doesn't change any
more).
However, the rest of the behaviour stays the same: gschem still freezes
its redraw of the main window until a mouse wheel zoom action takes
place (which only results in one redraw, but doesn't resolve the actual
problem) or one of the side/bottom window elements is hidden (which
resolves the problem until both are shown again and the window is
resized).

Best regards,

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

Hi, Richard.

Could you please check the following two things:

1) Open gschem in a terminal (say, xterm or some other) and check, if any
errors/messages are written when such a situation happens.
2) Make sure the issue is related to right sidebar. Just checkout, say,
1.9.1-20140308, and recompile.

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Hello Vladimir,

Vladimir Zhbanov schreef op zo 13-09-2015 om 19:26 [+0000]:
> Hi, Richard.
>
> Could you please check the following two things:
>
> 1) Open gschem in a terminal (say, xterm or some other) and check, if any
> errors/messages are written when such a situation happens.

When starting gschem from a terminal and triggering the bug, I don't get
any error messages anywhere. I monitored tail -f for
/var/log/syslog
/var/log/Xorg.log.0
~/.xsession-errors

I also restored the non-proprietary driver xserver-xorg-video-nouveau
instead of nvidia-346.82-0ubuntu0.2 and rebooted, but that didn't change
anything. So I think it is safe to conclude that it is not a graphics
driver issue.

However, I did see something out of the ordinary with good old top:
When starting gschem with both the status bar and the side bar visible,
but with simply a blank title block, both gschem itself and Xorg gobble
up a HUGE amount of CPU -- each process takes 60% of a CPU core, so
gschem takes a whopping 30% of my 4-core Intel Core i5-3350P 3.10GHz
CPU. And this without doing anything at all. (Memory usage is completely
normal.)

As soon as I close either the status bar (V S) OR the sidebar (V A), CPU
usage returns to normal (i.e. a fraction of a percent).

Then there's a weird thing: when I close and then restore the sidebar
(2 x V A, without doing anything else in between), the CPU load shoots
up again.
However, when I close and restore the status bar (2 x V S), the CPU load
does NOT go back up right away, but it does go up again after I drag the
main window around by its title bar above a certain speed (very slow
dragging does not cause high CPU usage). I think this too points in the
direction of some sort of (critical race?) issue when redrawing the main
window. Then again, if no-one else is experiencing this bug, there may
of course be an issue with my graphics card (nVidia GeForce GT 640),
although I can't see anything wrong in the log files.

Please note that all this is happening before triggering the 'main
window resize bug'; during all this, the window redraw bug is not yet
triggered, and gschem stays responsive, albeit somewhat sluggish during
the high CPU load condition.

AFTER triggering the main window redraw bug, the situation is different:
CPU load is low, but now the main window is only redrawn after clicking
and rolling the mouse wheel in the main viewport, as described in my
first bug report. As already explained, this behaviour can be stopped by
temporarily closing either the sidebar or the status bar.

So summarizing the observed behaviour in a short list; note that these
are the only actions performed, and in this order (I did not do anything
in gschem itself except showing and hiding the sidebar and status bar,
using the shortcut keys exclusively):

Action CPU load Redraw bug
----------------------------------------------------------
1. start gschem High No
2. sidebar off Low No
3. sidebar on High No
4. status bar off Low No
5. status bar on Low No
6. drag main window (slow) Low No
7. drag main window (fast) High No

8. resize main window Low Yes
9. click/scroll main viewport Low Yes (still)
9. sidebar...

[Richard Rasker (rasker-a)]

Hello Vladimir,

I just noticed yet more strange behaviour related to gschem's status bar
and sidebar problems:

1. Click on a .sch file to open it in gschem.
[gschem opens the file with the sidebar and the status bar visible]
2. Choose File -> Print
3. Select 'Print to File', PDF format
4. Adjust the default name to reflect the project's name(*)
5. Click Print.

And ... nothing happens. No PDF file appears.

6. Close either the sidebar or the status bar; or trigger the window
redraw bug, and click/scroll in the main viewport.
7. The PDF file now appears after all.

Perhaps this gives some more clues.

*: It would be nice if the 'Print to file' name reflected the .sch name
already, instead of the generic Print name -- but OK, that's a minor
annoyance.

Best regards,

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

On Sun, Sep 13, 2015 at 11:35:16PM -0000, Richard Rasker wrote:
> Hello Vladimir,
>
> I just noticed yet more strange behaviour related to gschem's status bar
> and sidebar problems:
>
> 1. Click on a .sch file to open it in gschem.
> [gschem opens the file with the sidebar and the status bar visible]
> 2. Choose File -> Print
> 3. Select 'Print to File', PDF format
> 4. Adjust the default name to reflect the project's name(*)
> 5. Click Print.
>
> And ... nothing happens. No PDF file appears.
>
> 6. Close either the sidebar or the status bar; or trigger the window
> redraw bug, and click/scroll in the main viewport.
> 7. The PDF file now appears after all.
Where does it appear then?

(All this behaviour is very strange and looks like some problems with
gtk+ redrawing in your environment. Perhaps, some events are lost for
some reason.)

Could you provide us with your config.log?

>
> Perhaps this gives some more clues.
>
> *: It would be nice if the 'Print to file' name reflected the .sch name
> already, instead of the generic Print name -- but OK, that's a minor
> annoyance.
Please open another bug for this.

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op ma 14-09-2015 om 08:50 [+0000]:
> On Sun, Sep 13, 2015 at 11:35:16PM -0000, Richard Rasker wrote:
> > Hello Vladimir,
> >
> > I just noticed yet more strange behaviour related to gschem's status bar
> > and sidebar problems:
> >
> > 1. Click on a .sch file to open it in gschem.
> > [gschem opens the file with the sidebar and the status bar visible]
> > 2. Choose File -> Print
> > 3. Select 'Print to File', PDF format
> > 4. Adjust the default name to reflect the project's name(*)
> > 5. Click Print.
> >
> > And ... nothing happens. No PDF file appears.
> >
> > 6. Close either the sidebar or the status bar; or trigger the window
> > redraw bug, and click/scroll in the main viewport.
> > 7. The PDF file now appears after all.

> Where does it appear then?

It appears where one would expect it: in the folder specified in the
Print dialog.

> (All this behaviour is very strange and looks like some problems with
> gtk+ redrawing in your environment. Perhaps, some events are lost for
> some reason.)
>
> Could you provide us with your config.log?

See attached file. Interestingly, I see some 'unknown' system parameters
as well 'fatal error' messages in there, yet ./configure and make do not
throw any error messages. But that is as far as my knowledge goes. I
hope that this log file is more informative to you.

The strange thing that I already mentioned previously is that I can
reproduce all this behaviour on a completely different machine: an
elderly laptop, with a completely different graphics system, and 32-bits
instead of 64-bits.
The only thing being the same is the Mint 17 Linux distribution, so
perhaps there's something amiss there in the X Server system, maybe the
bit dealing with the actual hardware (since the bug could not be
reproduced in a VM).

> > Perhaps this gives some more clues.
> >
> > *: It would be nice if the 'Print to file' name reflected the .sch name
> > already, instead of the generic Print name -- but OK, that's a minor
> > annoyance.
> Please open another bug for this.

OK, will do, although it's not a big deal.

Anyway, thank you and all those other developers for all your time and
hard work providing the world with great software! I think this can't be
said often enough -- notwithstanding the occasional bug, I'm a very
happy user of this stuff, every single day!

Best regards,

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

Hi Richard.
Could you please try to configure with the option '--without-libstroke' and recompile?

As concerns PDF appearance, could you check in some terminal program if it exists or not?

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op do 01-10-2015 om 13:47 [+0000]:
> Hi Richard.
> Could you please try to configure with the option '--without-libstroke' and recompile?

Apologies for the delay, I was busy. OK, configured with
'--without-libstroke', recompiled & installed, and found the
executable /usr/local/bin/gschem. However, when I try launching it, it
immediately crashes with the following output:

        ~ > gschem
        Backtrace:
        In ice-9/boot-9.scm:
         157: 1 [catch #t #<catch-closure 958400> ...]
        In unknown file:
           ?: 0 [apply-smob/1 #<catch-closure 958400>]

        ERROR: In procedure apply-smob/1:
        ERROR: In procedure scm_to_utf8_stringn: Wrong type argument in
        position 1 (expecting string): #f

Nothing I can understand here.

When I start the version ~/geda-gaf/gschem/src/gschem (so in the local
git tree), gschem does actually start, but nothing seems to have
changed. It still exhibits the same weird bugs.

> As concerns PDF appearance, could you check in some terminal program if
> it exists or not?

Checked again with a 'watch ls' command in a terminal, but as long as
BOTH the status window and the sidebar are opened, no PDF is written.

As soon as I close one of the two secondary windows, the PDF file
immediately appears.

But don't go through too much trouble. It's perfectly workable, just as
long as I close the status bar right after starting gschem.

Best regards,

Richard Rasker

[Vladimir Zhbanov (vzhbanov)]

Hi Richard,
Have you actually installed gschem before running? That is, have
you done 'sudo make install && sudo ldconfig' after 'make'? (See
bug #1492599). In the case if you don't want to clutter your
working installation just use the '--prefix' option.

Thanks,
  Vladimir

[Richard Rasker (rasker-a)]

Vladimir Zhbanov schreef op wo 07-10-2015 om 11:56 [+0000]:
> Hi Richard,
> Have you actually installed gschem before running? That is, have
> you done 'sudo make install && sudo ldconfig' after 'make'? (See
> bug #1492599). In the case if you don't want to clutter your
> working installation just use the '--prefix' option.

I did 'make install', but not 'ldconfig' -- that last one is new for me.
But shouldn't the compiled executable in de geda-gaf/gschem/src behave
exactly like a fully installed version? Because that executable did
start properly, without the guile error messages.

Here goes once more:

        ~> git pull -> OK
        ~> sudo apt-get remove geda-gschem -> OK
        ~> ./configure --prefix=/tmp/gEDA --without-libstroke
        ...
        configure: error: python headers not found
        configure: error: ./configure failed for xorn

Interesting, I can't remember having seen this one before. But OK:

        ~> sudo apt-get install python2.7-dev
        ~> ./configure --prefix=/tmp/gEDA --without-libstroke -> OK now
        ~> make -> OK
        ~> sudo make install -> OK
        ~> sudo ldconfig -> OK
        ~> /tmp/gEDA/bin/gschem -> gschem starts without error messages

But no, nothing has changed. There is still the window
resizing/redrawing bug, the extreme CPU usage, and the weird PDF export
behaviour. And as usual, all these issues go away by closing either the
status window, the sidebar, or both.

But tonight, I get a chance to install yet another machine with Mint 17.
I'll select the English language from the onset, and see what that
brings. If gschem doesn't misbehave there, I'll do a full machine
reinstall with Dutch, and try again. I'll let you know how this works
out.

Best regards,

Richard Rasker

[Richard Rasker (rasker-a)]

> But tonight, I get a chance to install yet another machine with Mint 17.

And here are the results: I installed a completely different machine (an
old 64-bit AMD Athlon 3200+) with Mint 17.2 KDE, in the default language
(US English) -- and yes, after adding the mehanik gEDA ppa and
installing geda-gschem I found that gschem exhibited the same bugs once
again.

So it would appear that the problem lies in the combination of Linux
Mint KDE with gschem. From what I experience, anyone should be able to
reproduce the bug by installing Linux Mint KDE + geda-gschem on an
arbitrary machine in an arbitrary language.
Maybe installing Linux Mint with another desktop manager (DM) than KDE
may solve the problem, but installing the KDE version and then switching
to another DM doesn't work.
As soon as I have yet another machine at my disposal and some time to
try out a different DM as a 'pristine install', I will report back.

Best regards,

Richard Rasker

[Edward Hennessy (ehennes)]

> On Oct 7, 2015, at 4:24 PM, Richard Rasker <email address hidden> wrote:
>
> So it would appear that the problem lies in the combination of Linux
> Mint KDE with gschem. From what I experience, anyone should be able to
> reproduce the bug by installing Linux Mint KDE + geda-gschem on an
> arbitrary machine in an arbitrary language.
> Maybe installing Linux Mint with another desktop manager (DM) than KDE
> may solve the problem, but installing the KDE version and then switching
> to another DM doesn't work.
> As soon as I have yet another machine at my disposal and some time to
> try out a different DM as a 'pristine install', I will report back.

I could not reproduce this issue with gschem on Linux Mint 17.2 with KDE inside a VMWare Fusion 7.1.2 virtual machine.

Perhaps the best way to proceed is for me to find some dedicated hardware and get Linux Mint up and running.

Ed

[Dominique Michel (dominique-michel-vtxnet)]

Hi,

I have the same issue on a gentoo ~amd64 system with a duo cores AMD E-450 APU and a Radeon HD 6320 display card. My desktop is fvwm with fvwm-crystal. This issue did appear when the sidebar was introduced and with both the gtk+ and the motif GUIs. The display size is 1600x900. The kernel is 4.16.18-rt12, but I get this issue with older rt kernels as well than with the gentoo-sources.

To resume, If I disable the sidebar, all is OK until it appear again when I want to edit some attribute.

When it is enabled, the display is slower, and as soon I maximize the window and click on a topic on the menu bar, the menu take 30 seconds to draw. If I navigate from a menu bar topic to another, the display is not correctly refreshed. The old menu is still here with the new one in the front.

When this append, If I navigate to another desktop page and back, gschem window is blank gray. But I also can get that blank window when no menu is open. After that, if I use a keyboard shortcut to resize gschem to its original size, it's display eventually get back to a normal state, but not always, and it is still slow.

[dmn (graahnul.grom)]

Hi Richard!
If you still have this issue with gschem on your system,
it would be very nice if you try lepton-schematic from the Lepton EDA suite [1]: does it behave the same? I cannot reproduce the bug with either geda-gaf and lepton.
BTW, there is an option you can set in geda.conf configuration file [2] to disable docking widgets:

[schematic.gui]
use-docks=false

[1] https://github.com/lepton-eda/lepton-eda
[2] https://github.com/lepton-eda/lepton-eda/wiki/Configuration-Settings

regards,
Dmitry

[Richard Rasker (rasker-a)]

Hello Dmitry,

Yes, the issue still persists, and hitting V-S to hide the bottom bar is
still the very first thing I do after starting gschem.

Unfortunately, I'm a bit behind with my work, so I can't build and test
the new Lepton suite right now. I'll do that as soon as I have some
spare time on my hands.

And oh, can I set this option use-docks=false in a current gschem
configuration file? Or is this only supported in Lepton?

Anyway, thanks for your message and all your work, and sorry that I
haven't got the time to test things right now.

Best regards,

Richard Rasker

Op 02-12-18 om 21:37 schreef dmn:
> Hi Richard!
> If you still have this issue with gschem on your system,
> it would be very nice if you try lepton-schematic from the Lepton EDA suite [1]: does it behave the same? I cannot reproduce the bug with either geda-gaf and lepton.
> BTW, there is an option you can set in geda.conf configuration file [2] to disable docking widgets:
>
> [schematic.gui]
> use-docks=false
>
>
> [1] https://github.com/lepton-eda/lepton-eda
> [2] https://github.com/lepton-eda/lepton-eda/wiki/Configuration-Settings
>
> regards,
> Dmitry

[dmn (graahnul.grom)]

Richard, thank you for the reply and your intention to help!
Lepton EDA can now be installed alongside geda-gaf (binary files and data directories are renamed).

"use-docks" option is available only in Lepton (it was added one and a half year ago [1]).

To start gschem with bottom dock hidden you can use the following command:

$ gschem -c '(view-status)'

To hide both docks:

$ gschem -c '(view-status) (view-sidebar)'

(-c option specifies Scheme expression to execute at startup).

[1] https://github.com/lepton-eda/lepton-eda/pull/135

Dmitry

[Dominique Michel (dominique-michel-vtxnet)]

A little update. I just try lepton-eda from its git repository. With it and the side dock open, it is slow the first time I click on a component, the menu is a little bit messy during that time (it does not refresh) but it work. After that, the speed is quite decent, everything work normally and I can do whatever I want without problem.

[Dominique Michel (dominique-michel-vtxnet)]

The fix with added feature implemented into lepton is here:
https://github.com/lepton-eda/lepton-eda/pull/135