[veganglade]

Apparently qmake has its own ideas about setting RPATH. Stackoverflow has some suggestions: http://stackoverflow.com/questions/7506860/qmake-and-passing-origin-to-linker-option-rpath

[veganglade]

I tried the 4.4.26 and 4.4.28 versions of Glade. I think the RPATH value is getting evaluated at the build step instead of being set as a literal string. The literal RPATH should be '$ORIGIN/../lib' (without the quotes). The $ORIGIN is evaluated at run-time by the linker. The RPATH in the binary (obtained using patchelf –print-rpath) is '/../lib'. It seems $ORIGIN is being replace by the empty string by a shell.

[veganglade]

RPATH is similar to LD_LIBRARY_PATH, except it is encoded in the executable itself. I have stopped using LD_LIBRARY_PATH because different programs often require different versions of the same library, which has to be solved using wrapper scripts.

When using GNU binutils, rpath can be set using the linker option "-rpath=<dir>". GCC supports this using the command-line option "gcc -Wl,-rpath,<dir>". I think a value of '$ORIGIN/../lib' for <dir> should do the job. If you are using a cmake or autotools, I guess they probably have some method to set it.

[veganglade]

On RHEL5, I have to change the RPATH of the glade executable for it to work correctly. I use the following comamnd to do that:
patchelf –set-rpath '$ORIGIN/../lib' glade

This looks for linked libraries relative to the glade executable. The default RPATH appears to be hardcoded for the build system. I am posting this in the hope that it will help some one else. Also, it will be nice if this can be included in future builds.

[veganglade]

Works great! Thank you very much.

[veganglade]

Thanks. That's very fast! I wish I could get similar support for our paid software.

I sent you a PM.

Satya

[veganglade]

Hi,

When importing a Laker tech file, I am missing two features, that my current tech file uses:
1. layer mapping file: the format appears to be same as Cadence's. The Cadence tech file import dialog has this option, but the Laker one doesnt.

2. Named pattern uses a display pattern name (Display Group in Laker Parlance). Instead of the attribute list [fill_color fill_stiple line_color line_stipple] , this just uses a name in the tech file. The name is defined in the display file in the tfDisplayGroup section.

Will it be possible to add such a feature?

Thanks,
Satya

e.g.:

techfile might have:
tfLayoutLayerTable {
def { DNWELL drawing 1 DGDNWell yes yes yes }
…
}

display file will have:
tfDisplayGroup {
{ DGDNWell tan blank tan solid }
…
}

[veganglade]

Quote:

If and when the Qt gui toolkit supports Android, it might just be possible.

However, I doubt that is ever going to happen.

I did wonder about having such an application run on iOS so I could use it on an iPad, but (a) the user interface is going to be a problem (b) memory is going to be a problem and (c) getting data in/out is going to be a problem.

Let's stick to what is possible, yes?

Actually, Qt is already available on Android: http://sourceforge.net/p/necessitas/home/necessitas/ and it seems Python as well: https://code.google.com/p/python-for-android/

The correspoding iOS versions are at http://mediator-software.com/ and http://pythonforios.com/

I still think this not the direction to go. But not for technical reasons. It's just because a GDS viewer on a tablet is not very useful.

On the other hand, most best-selling apps on iTunes are useless as well.

Regards,
Satya

[veganglade]

Anything that makes your life easier should be good. The EDA vendors are still stuck on RHEL4, so I am too. Windows version works fine for me. So I will continue using that instead of the RHEL4 version.

[veganglade]

The new glade build appears to be incompatible with RHEL4. Any chance of getting a compatible build?

Thanks,
Satya

[veganglade]

I guess it is a cosmetic feature, only a nice to have. Perhaps it can be put off till enough users find it necessary. I just thought of the feature because the commercial layout editors seem to do it that way. I do not know enough about the design of a layout editor to figure out how they do it or how much complexity it would add.

[veganglade]

May I request a refinement of the label non-rotation. I think it is useful to follow the rotation, but just ignore the mirroring when displaying labels. This way the text can be oriented as needed, but still be easy to read.

[veganglade]

Thank you very much for the lightning fast enhancement. The options work great.

I noticed one minor thing for #1. The text stays in its place when the orientation is set to MX or MY, but the selection box moves away. When the text is in a lower level instance that has MY orientation, the text moves away from its intended location. Please see the test cell in the example library for what I mean.

Edit: Can't upload files.

[veganglade]

Thank you very much for the quick response.

Your statement about #2 is what I meant. When all levels are displayed, often the overlapping labels make the text entirely unreadable. I haven't seen any other layout editor that implements this feature. But then, they don't usually want user feedback even when they are paid for it.

I think fast is better than good looking. The line drawing is certainly good enough for layout purposes. I found an interesting library called OGLFT (http://oglft.sourceforge.net/) that seems to combine OpenGL and Freetype. The site says the texture mapped rendering is fast. Not sure if that would serve this purpose. The library is LGPL, so licensing should not be an issue.

[veganglade]

Thank you very much for the outstanding GDS viewer. Puts all commercial layout tools to shame. I have not tried the editing capabilities so far.

I have some enhancement requests related to labels:

[ol][li]Option to keep label text invariant under mirroring (I am not very good at reading mirrored words)[/li][li]Option to show labels on only one level or all levels. This is because overlapping labels become hard to read.[/li][li]Use real fonts instead of line drawing for label text. Not sure if this feasible or advisable for performance reasons, but would look nicer.
[/li][/ol]

[Author]

Posts