[Keith]

By turning off OpenGL you miss e.g. alpha blending of layers, which has a big impact on image quality. Also you miss out on using the GPU performance to improve rendering through the use of textures, display lists etc. If you can get OpenGL to work on Linux it's definitely worth it; if in doubt try the Windows version to compare OpenGL vs non-OpenGL drawing.

Layer colours for 'system' layers currently aren't saved to a techfile so you can load them later at present. This could easily be fixed; I'll put it in the list for the next release.

The .gladerc file sets bindkey and various options, but is not used for any layer information; that is always saved to a techfile.

[Keith]

Hi Bill,

My experience on Linux has been that Nvidia generally do the best OpenGL drivers, ATI tend to be slightly behind, although that was a while ago.

With Linux you normally do have to install and set up the card vendor's drivers, as the standard distos do not include anything except Mesa software emulation. With Windows, OpenGL usually works well out the box although updating the drivers has occasionally fixed a few strange effects with some cards.

– Keith

[Keith]

Hi Bill,

Few things to try.

1. FC14 may run the rh5 version of glade rather than the rh4 version you appear to be using

2. You might want to try downloading the latest nVidia drivers for the graphics card you're using, and make sure OpenGL can run. As from the logfile, you are using Mesa which is software emulation of OpenGL, and it may be slow and/or buggy.

3. If all else fails you can run glade in non-OpenGL mode by setting the env var

export GLADE_USE_OPENGL=no

I'm a bit puzzled by your comment that when you selected an object it didn't highlight. Have you by any chance changed the background color to white? If so you will need to change the 'select' color which by default is also white…

Implementing a 'nudge' command as you say seems a good idea, I'll look into it.

[Keith]

Can you let me know:

– what OS are you running (Linux, but specifically what version)
– what graphics card you have?

Even better, just send the logfile, or at least the first portion of it.

you can email to the address in the help->about dialog.

Thanks!

Edit: normally to move an object, you select it (left mouse click), then use Edit->Move and click on the starting point for the move, or just the 'm' bindkey if infix mode is on (View Display Options dialog). Then move the cursor and you should see an outline of the object moving. Left click again to define the position you want to move the object to.

If you just want to move the object by say 10um, select the object, set infix mode off (in the View->Display Options form) and use the bindkey OR use Edit->Move menu command. Then when prompted for the starting point, hit F5 and use coords 0 0 as the starting point. Hit F5 again and enter the distance you want to move by.

Hope this helps!

[Keith]

Yes, you've found a bug. If the original cell contained an instance, it would loop endlessly.

The Copy cell message doesn't refer to the new cell because the command opens a dialog prompting for the new cellview details. At present there is also a limitation in that it will only copy to the same library as the existing cell. This should be straightforward to fix.

Fix will be in version 4.1.82.

Edit: there was also a bug in copy cell, which caused polygons to be copied to the wrong layer. This too has been fixed.

[Keith]

I've fixed the problems and 4.1.81 should be available on windows/linux platforms later today.

If running extraction again on the same cellView, please delete the 'extracted' view (use the library browser, right click on the view and select delete). Else the existing extracted view will get written to again and cause incorrect behaviour.

[Keith]

You've found a bug. In fact no-one has ever tried saving a design with connectivity, and looking at the code there are some errors with the way instPins are handled. I'll get a fix in for 4.1.81.

[Keith]

Hi Folks,

I am in the process of moving the build system for Glade on CentOS 4.6 (=RHEL4) to CentOS 5.7 (=RHEL5). The main reason is that the latest Qt libs won't compile under old versions of gcc, and hey, CentOS 4.6 is pretty old.

If you have any objections / problems with this, let me know. In theory running VMware means any Linux flavour *can* be supported, but the effort in doing so makes it unfeasible to choose all but the most popular.

– Keith

[Keith]

Version 4.1.77 fixes a nasty bug that crept in at v4.1.72. The symptoms of this bug were that Glade would crash when opening any layout, *unless* the LSW was already open. As the .gladerc setting file controls whether the LSW is shown on startup, some users did not experience this problem; new users did.

Please update to 4.1.77 asap and discard any versions 4.1.72-76.

[Keith]

I've finally tracked down the source of this problem. It's been fixed in version 4.1.77. FYI, the bug existed from version 4.1.72 thru 4.1.76 and was slightly hard to find as it only occurred if you did not have the LSW open when opening a cellView. It also trashed the call stack, sigh.

[Keith]

This version is a rebuild of 4.1.75 for Windows 32/64 bit following problems several users were having with crashes which alas could not reproduced. However, anecdotal evidence suggests that incompatible Qt libraries were the problem.

The Qt libs have all been recompiled locally rather than using the Qt VS2010 binaries. Also the latest VS2010 SP1 redistributables are included; please make sure you run these as per the README file instructions to update the (necessary) runtime libraries.

[Keith]

I'm guessing that the crash occurs when opening a cellview, rather than during GDS2 import? This could be the recent Qt bug that others have also noticed where Qt is using OpenGL for drawing its widgets e.g a QLabel.

As I can't reproduce this in-house (yet), it would be useful to get more info in order to follow up with the Qt folks. If you have seen this crash, please send the crash report/logfile to support@peardrop.co.uk.

Edit: I've had 3 reports of crashes on Windows 32 and 64 bit platforms with a variety of graphics cards. The crashes all seem to occur in QGLWidget::glDraw(), called by Qt trying to draw widgets and using an OpenGL QPaintDevice (note this has nothing to do with Qt's drawing mode OpenGl/non-OpenGL).

[Keith]

What platform? What OS? Sounds like Windows, but it's working OK here on 3 windows macines running XP and Windows 7 32/64 bit.

Any clues in the logfile?

[Keith]

If your email address is on any of the common spam lists, don't bother even trying to register. If it's not on the spam lists it will be treated with suspicion if it's with an anonymous host e.g. gmail. Genuine members are welcome; spammers are not.

[Keith]

I heard from one member that he was unable to post to the forum. If you experience any problems with it, please let me know so they can be fixed. Thanks.

[Author]

Posts