gtkwave-users — User questions or comments related to the gtkwave application

Re: [Gtkwave-users] Patch to add new feature: A negative hier_max_level sets the number of hierarchy levels to hide from the left side.

[<by...@nc...>]

Please post this as push request on github. SF is slowly ramping down
and will be for bugfixes only.

Thanks,
-Tony

	-----------------------------------------From: "Vicente Bergas" 
To: gtk...@li...
Cc: 
Sent: Monday August 21 2023 8:57:04AM
Subject: [Gtkwave-users] Patch to add new feature: A negative
hier_max_level sets the number of hierarchy levels to hide from the
left side.

 Hi, the attached patch adds a new feature:
 A negative hier_max_level sets the number of hierarchy levels to hide
 from the left side.

 Regards,
 Vicente.

[Gtkwave-users] Patch to add new feature: A negative hier_max_level sets the number of hierarchy levels to hide from the left side.

[Vicente B. <vi...@gm...>]

Hi, the attached patch adds a new feature:
A negative hier_max_level sets the number of hierarchy levels to hide
from the left side.

Regards,
  Vicente.

Re: [Gtkwave-users] GTKWave "not looking right" on a new install

[Sylvain M. <24...@gm...>]

So all in all, I ended up with the following patch. This restore a
feel I like much better.
Attached here just in case other people also prefer this compact style.
I ended up not bothering with the icons just because I spend enough
time on this already.

Cheers,

     Sylvain

Re: [Gtkwave-users] GTKWave "not looking right" on a new install

[Sylvain M. <24...@gm...>]

Hi,

> Look to see if you grabbed gtkwave3 (gtk1 and 2) vs gtkwave3-gtk3 (gtk2 and 3).  My guess is you grabbed the gtk3 source which goes more toward the gnome style guide for applications.

Yeah, I think on my previous install it was built against GTK2 and
this is now GTK3.
I don't really want to install GTK2 since it's EOL.

> The "giant, useless bar" is because no file is loaded so no menu items will be active and will be ghosted except for menu items to load.

No, I didn't mean the icons, that's the useful part :)  I meant the
top bar / title bar. I have a frame less window manager, I shouldn't
have any client imposed window decoration, that should be left to my
window manager.

But I found out I can undefine WAVE_ALLOW_GTK3_HEADER_BAR to get it
like it should be with a proper menu bar and toolbar.
The toolbar is still way too large, for which I can do :

gtk_toolbar_set_icon_size(GTK_TOOLBAR(tb), GTK_ICON_SIZE_SMALL_TOOLBAR);

which does reduce the icon size to 16x16 but unfortunately still
doesn't really change the toolbar size just because of GTK3 insane
defaults for padding and minimum height.

I'm in the process of fixing that with a bit of GTK3 CSS but still need a

Then finally I'll also need to find a way to include some icons that
are a bit less gray than the default GTK3 set, possibly just go take
the old GTK2 ones and somehow find a way to make gtkwave use those
instead of the system one.

Cheers,

    Sylvain

Re: [Gtkwave-users] GTKWave "not looking right" on a new install

[<by...@nc...>]

Sylvain,

I take it you grabbed a default source tarfile download off the SF
site?

Look to see if you grabbed gtkwave3 (gtk1 and 2) vs gtkwave3-gtk3
(gtk2 and 3). My guess is you grabbed the gtk3 source which goes more
toward the gnome style guide for applications.

The "giant, useless bar" is because no file is loaded so no menu items
will be active and will be ghosted except for menu items to load.

-Tony

	-----------------------------------------From: "Sylvain Munaut" 
To: gtk...@li...
Cc: 
Sent: Sunday July 23 2023 8:50:53AM
Subject: [Gtkwave-users] GTKWave "not looking right" on a new install

 Hi,

 I'm setting up a new laptop and for some reason, gtkwave isn't
looking right.
 See the attached screenshots for what it looks like vs what I expect
 it to look like.

 There is a giant useless bar on top and then the menu items are not
 menu items but a popup menu of one of the icon ... and even the icons
 look wrong.
 It's not good ...

 How do I get it to look like it should be?

 Cheers,

 Sylvain

[Gtkwave-users] GTKWave "not looking right" on a new install

[Sylvain M. <24...@gm...>]

Hi,

I'm setting up a new laptop and for some reason, gtkwave isn't looking right.
See the attached screenshots for what it looks like vs what I expect
it to look like.

There is a giant useless bar on top and then the menu items are not
menu items but a popup menu of one of the icon ... and even the icons
look wrong.
It's not good ...

How do I get it to look like it should be?

Cheers,

     Sylvain

Re: [Gtkwave-users] wayland dependency

[<by...@nc...>]

551:/home/bybell/gtkwave/code/gtkwave3-gtk3> svn commit
Password: 
Sending ChangeLog
Sending src/gtk23compat.h
Sending src/twinwave.c
Transmitting file data ...
Committed revision 1643.

I integrated it slightly modified as the #if with && didn't compile on
my Centos7 system. Thanks for the patch. Checked in as shown above.

-Tony

	-----------------------------------------From: "Fabio Rossi via
Gtkwave-users" 
To: "gtk...@li..."
Cc: "Fabio Rossi"
Sent: Tuesday May 16 2023 5:35:32AM
Subject: [Gtkwave-users] wayland dependency

 Hello,
 I am trying to compile latest gtkwave-3.3.115 against gtk3+ without
wayland support. The configure phase completes without errors but I
get compile time errors due to missing includes related to wayland.

 In file included from debug.h:17,
 from vlist.h:18,
 from analyzer.h:18,
 from symbol.h:20,
 from vcd.h:32,
 from ae2.h:16,
 from globals.h:27,
 from bitvec.c:15:
 gtk23compat.h:12:10: fatal error: gdk/gdkwayland.h: No such file or
directory
 12 | #include 
 | ^~~~~~~~~~~~~~~~~~
 compilation terminated.

 By looking into the code it seems that wayland is not mandatory (a
check against the GDK_WINDOWING_WAYLAND define is used for specific
lines of code but not around the include directives). So I have
created a simple patch which makes possible to build the sources
without errors, at runtime then it seems to work correctly.

 Is the patch correct? Can it be applied upstream?

 Thanks,
 Fabio

[Gtkwave-users] wayland dependency

[Fabio R. <ro...@in...>]

Hello,
I am trying to compile latest gtkwave-3.3.115 against gtk3+ without wayland support. The configure phase completes without errors but I get compile time errors due to missing includes related to wayland.

In file included from debug.h:17,
                 from vlist.h:18,
                 from analyzer.h:18,
                 from symbol.h:20,
                 from vcd.h:32,
                 from ae2.h:16,
                 from globals.h:27,
                 from bitvec.c:15:
gtk23compat.h:12:10: fatal error: gdk/gdkwayland.h: No such file or directory
   12 | #include <gdk/gdkwayland.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

By looking into the code it seems that wayland is not mandatory (a check against the GDK_WINDOWING_WAYLAND define is used for specific lines of code but not around the include directives). So I have created a simple patch which makes possible to build the sources without errors, at runtime then it seems to work correctly.

Is the patch correct? Can it be applied upstream?

Thanks,
Fabio

Re: [Gtkwave-users] Requests: signal name for bound process script, export SVG,

[<by...@nc...>]

Hello Sujay,

It looks like I misread your previous note...font color shouldn't be
hard to do. I read it as new fonts, different font sizes, etc.

I'd say open a bug requesting a feature enhancement request on github,
which is where the current development for future versions is going
on. Right now, I'm too busy to work on gtkwave as my day job is
consuming most of my entire day.

As a side note to everyone, Sourceforge at the point is just for
bugfix maintenance releases. I keep the Sourceforge repo around so I
have a known stable version that I can use at work.

Thanks,
-Tony

	-----------------------------------------From: "Sujay Phadke" 
To: gtk...@li...
Cc: 
Sent: Thursday April 6 2023 12:48:21AM
Subject: Re: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

 Hi Tony,  for #1, I was asking to have signal names visibility in the
"translate filter" process. CMIIW, but what you've stated is for the
"transaction filter" process mechanism. Yes, for the latter, we  do
get a simplified VCD with the signal name. But we don't get that for
the former, which is easier to implement and use. In the former, a
process only sees the raw data of the  associated signal on STDIN,
without the signal name.  
 D0 D1 D2 It'd be advantageous to have the signal_name tag before the
raw data streaming in (maybe with a controlling switch input so it
doesn't break the flow for others?): 
  D0 D1 D2 ..... 
 I did look into the translate filter code (ptranslate.c). I think it
can be done with some modifications to add_filter_callback_2() and
pipeio  
 For #3, I feel the performance is not going to be greatly impacted.
We can already change the color of wave backgrounds with different
colors, dynamically, based on the filters.  I've not noticed any
performance impact with this. Changing the font color would be part of
the same code, but there isn't a way to do it at present. 
 Thanks for your help. I know this is probably not a priority for you.
Maybe I'll get to it sometime when I can understand the code flow
better. 
 best regards, Sujay 

 On Mon, Mar 20, 2023 at 10:46 PM  wrote:
  Hello Sujay,

 I understand what you want to do for #1. I'm telling you that from
gtkwave's perspective, it's a different process, so it's not more
efficient for me, though it might be for you as a developer.

 Note that passing signal names can be done along the "$" directive
mechanism. I had to look at the source to see what it's doing as I
wrote this code back in 2010...

 See save_nodes_to_export_generic() in vcd_saver.c and add whatever
you need. Some information is already there. If you look at existing
input coming from gtkwave, especially lines starting with "$", you'll
see a line like this:

 $comment name val[7:0] $end

 ...I think such a name or something similar would give you what you
need.

 For #3, yes, they're static. If gtkwave was a tool designed for
generating documentation, it could certainly throw new fonts up at
will, but doing so would be very bad for performance for an
interactive tool. 

 -Tony

	----------------------------------------- From: "Sujay Phadke"
 To: gtk...@li...
 Cc:
 Sent: Monday March 20 2023 2:20:05AM
 Subject: Re: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

Hey Tony,  Thanks for the reply. But I don't understand the responses
1 and 3: 
 1. Yes, a new process will be spawned for every signal. However, the
logic of the executable will still remain the same. I want to do
something like: 
 if 'sig_name' == 'signal0':  sys.stdout.write('Nonen') else:
  sys.stdout.write(readline)  
 Unless we pass the metadata for the signal, I don't see how a
separate process will help. Either passing in the signal name/id as
metadata on stdin, alongwith the signal values, or calling the process
with an argument in the TCL script would work. 
 Is there a way to accomplish this? 
 3. I know about those rc variables. However, those are static aren't
they? I want to be able to change the waveform text foreground color
dynamically (per wave phase), just as we do with the background color
(using the ?...? prefix before the value in the translation file).  Is
there a way to do this? 

 On Mon, Mar 20, 2023 at 1:01 PM  wrote:
  Thanks for your comments.

 1) Each signal has a separate process instance / set of stdin/stdout
attached to it for process filter, so even though you'd be able to use
a single script, performance-wise it wouldn't really make too much
difference as multiple processes will be created, anyway.

 2) Unfortunately, I don't have the time for such a thing right now.
PS and Framemaker do generate lists of vectors but I don't know if a
converter exists from those to SVG. Someone else is working on a GTK4
port and I don't know if his changes will address this as I believe he
was planning on collapsing the redundant print.c code into what
signal.c/waveform.c already does.

 3) The rc variables fontname_signals and fontname_waves should allow
changing the fonts. See function do_font_load() in fonts.c.

 Best regards,
 -Tony

	----------------------------------------- From: "Sujay Phadke"
 To: gtk...@li...
 Cc:
 Sent: Sunday March 19 2023 11:52:19PM
 Subject: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

 Hello everyone,  First of all, I must say the GTKWave is an excellent
program. Kudos! 
 I wanted to request the following: 1. Signal name for process filter
script - currently, I have a python script used as a process filter
for various signals. However, I want to parse the input data
differently, based on what signal it is coming from. Example: for
signal0 I may want to convert “-1” to “None”. However, I may
not want to do that for signal1 
 The only want I know of currently is to attach different scripts to
different signals, which is inefficient. Is there a way that the
signal name could also be passed on to the script?  
 2. Please consider having the ability to export the current view as
SVG file. It makes it much more efficient for presenting or pasting
into a webpage.  
 3. Can the font color of the text inside the waves be changed? I can
only change the background color of a waveform using the
“?bgcolor?” prefix before the name. Problem is, some background
colors are useless since the text inside is too light in color. I’m
forced to use only dark backgrounds as a result.  
 Best regards, Sujay   _______________________________________________
 Gtkwave-users mailing list
Gtk...@li...
 [1] [2]https://lists.sourceforge.net/lists/listinfo/gtkwave-users [3]
   _______________________________________________
 Gtkwave-users mailing list
Gtk...@li...
 [4]https://lists.sourceforge.net/lists/listinfo/gtkwave-users [5]
  

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/gtkwave-users
[2] https://lists.sourceforge.net/lists/listinfo/gtkwave-users
[3] https://lists.sourceforge.net/lists/listinfo/gtkwave-users
[4] https://lists.sourceforge.net/lists/listinfo/gtkwave-users
[5] https://lists.sourceforge.net/lists/listinfo/gtkwave-users

Re: [Gtkwave-users] Requests: signal name for bound process script, export SVG,

[Sujay P. <ele...@gm...>]

Hi Tony,
     for #1, I was asking to have signal names visibility in the "translate
filter" process. CMIIW, but what you've stated is for the "transaction
filter" process mechanism. Yes, for the latter, we
do get a simplified VCD with the signal name. But we don't get that for the
former, which is easier to implement and use. In the former,  a process
only sees the raw data of the
associated signal on STDIN, without the signal name.

D0 D1 D2
It'd be advantageous to have the signal_name tag before the raw data
streaming in (maybe with a controlling switch input so it doesn't break the
flow for others?):

<signal_name> D0 D1 D2 .....

I did look into the translate filter code (ptranslate.c). I think it can be
done with some modifications to add_filter_callback_2() and pipeio

For #3, I feel the performance is not going to be greatly impacted. We can
already change the color of wave backgrounds with different colors,
dynamically, based on the filters.
I've not noticed any performance impact with this. Changing the font color
would be part of the same code, but there isn't a way to do it at present.

Thanks for your help. I know this is probably not a priority for you. Maybe
I'll get to it sometime when I can understand the code flow better.

best regards,
Sujay


On Mon, Mar 20, 2023 at 10:46 PM <by...@nc...> wrote:

> Hello Sujay,
>
> I understand what you want to do for #1.  I'm telling you that from
> gtkwave's perspective, it's a different process, so it's not more efficient
> for me, though it might be for you as a developer.
>
> Note that passing signal names can be done along the "$" directive
> mechanism.  I had to look at the source to see what it's doing as I wrote
> this code back in 2010...
>
> See save_nodes_to_export_generic() in vcd_saver.c and add whatever you
> need.  Some information is already there.  If you look at existing input
> coming from gtkwave, especially lines starting with "$", you'll see a line
> like this:
>
> $comment name val[7:0] $end
>
> ...I think such a name or something similar would give you what you need.
>
> For #3, yes, they're static.  If gtkwave was a tool designed for
> generating documentation, it could certainly throw new fonts up at will,
> but doing so would be very bad for performance for an interactive tool.
>
> -Tony
>
>
> -----------------------------------------
> From: "Sujay Phadke"
> To: gtk...@li...
> Cc:
> Sent: Monday March 20 2023 2:20:05AM
> Subject: Re: [Gtkwave-users] Requests: signal name for bound process
> script, export SVG,
>
> Hey Tony,
>    Thanks for the reply. But I don't understand the responses 1 and 3:
>
> 1. Yes, a new process will be spawned for every signal. However, the logic
> of the executable will still remain the same. I want to do something like:
>
> if 'sig_name' == 'signal0':
>      sys.stdout.write('None\n')
> else:
>      sys.stdout.write(readline)
>
> Unless we pass the metadata for the signal, I don't see how a separate
> process will help. Either passing in the signal name/id as metadata on
> stdin, alongwith the signal values, or calling the process with an argument
> in the TCL script would work.
> Is there a way to accomplish this?
>
> 3. I know about those rc variables. However, those are static aren't they?
> I want to be able to change the waveform text foreground color dynamically
> (per wave phase), just as we do with the background color (using the ?...?
> prefix before the value in the translation file).
> Is there a way to do this?
>
>
> On Mon, Mar 20, 2023 at 1:01 PM <by...@nc...> wrote:
>
>> Thanks for your comments.
>>
>> 1) Each signal has a separate process instance / set of stdin/stdout
>> attached to it for process filter, so even though you'd be able to use a
>> single script, performance-wise it wouldn't really make too much difference
>> as multiple processes will be created, anyway.
>>
>> 2) Unfortunately, I don't have the time for such a thing right now.  PS
>> and Framemaker do generate lists of vectors but I don't know if a converter
>> exists from those to SVG.  Someone else is working on a GTK4 port and I
>> don't know if his changes will address this as I believe he was planning on
>> collapsing the redundant print.c code into what signal.c/waveform.c already
>> does.
>>
>> 3) The rc variables fontname_signals and fontname_waves should allow
>> changing the fonts.  See function do_font_load() in fonts.c.
>>
>> Best regards,
>> -Tony
>>
>> -----------------------------------------
>> From: "Sujay Phadke"
>> To: gtk...@li...
>> Cc:
>> Sent: Sunday March 19 2023 11:52:19PM
>> Subject: [Gtkwave-users] Requests: signal name for bound process script,
>> export SVG,
>>
>> Hello everyone,
>>     First of all, I must say the GTKWave is an excellent program. Kudos!
>>
>> I wanted to request the following:
>> 1. Signal name for process filter script - currently, I have a python
>> script used as a process filter for various signals. However, I want to
>> parse the input data differently, based on what signal it is coming from.
>> Example: for signal0 I may want to convert “-1” to “None”. However, I may
>> not want to do that for signal1
>>
>> The only want I know of currently is to attach different scripts to
>> different signals, which is inefficient. Is there a way that the signal
>> name could also be passed on to the script?
>>
>> 2. Please consider having the ability to export the current view as  SVG
>> file. It makes it much more efficient for presenting or pasting into a
>> webpage.
>>
>> 3.  Can the font color of the text inside the waves be changed? I can
>> only change the background color of a waveform using the “?bgcolor?” prefix
>> before the name. Problem is, some background colors are useless since the
>> text inside is too light in color. I’m forced to use only dark backgrounds
>> as a result.
>>
>> Best regards,
>> Sujay
>> _______________________________________________
>> Gtkwave-users mailing list
>> Gtk...@li...
>> <https://lists.sourceforge.net/lists/listinfo/gtkwave-users>
>> https://lists.sourceforge.net/lists/listinfo/gtkwave-users
>>
> _______________________________________________
> Gtkwave-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtkwave-users
>

Re: [Gtkwave-users] Requests: signal name for bound process script, export SVG,

[<by...@nc...>]

Hello Sujay,

I understand what you want to do for #1. I'm telling you that from
gtkwave's perspective, it's a different process, so it's not more
efficient for me, though it might be for you as a developer.

Note that passing signal names can be done along the "$" directive
mechanism. I had to look at the source to see what it's doing as I
wrote this code back in 2010...

See save_nodes_to_export_generic() in vcd_saver.c and add whatever you
need. Some information is already there. If you look at existing input
coming from gtkwave, especially lines starting with "$", you'll see a
line like this:

$comment name val[7:0] $end

...I think such a name or something similar would give you what you
need.

For #3, yes, they're static. If gtkwave was a tool designed for
generating documentation, it could certainly throw new fonts up at
will, but doing so would be very bad for performance for an
interactive tool. 

-Tony

	-----------------------------------------From: "Sujay Phadke" 
To: gtk...@li...
Cc: 
Sent: Monday March 20 2023 2:20:05AM
Subject: Re: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

 Hey Tony,  Thanks for the reply. But I don't understand the responses
1 and 3: 
 1. Yes, a new process will be spawned for every signal. However, the
logic of the executable will still remain the same. I want to do
something like: 
 if 'sig_name' == 'signal0':  sys.stdout.write('Nonen') else:
  sys.stdout.write(readline)  
 Unless we pass the metadata for the signal, I don't see how a
separate process will help. Either passing in the signal name/id as
metadata on stdin, alongwith the signal values, or calling the process
with an argument in the TCL script would work. 
 Is there a way to accomplish this? 
 3. I know about those rc variables. However, those are static aren't
they? I want to be able to change the waveform text foreground color
dynamically (per wave phase), just as we do with the background color
(using the ?...? prefix before the value in the translation file).  Is
there a way to do this? 

 On Mon, Mar 20, 2023 at 1:01 PM  wrote:
  Thanks for your comments.

 1) Each signal has a separate process instance / set of stdin/stdout
attached to it for process filter, so even though you'd be able to use
a single script, performance-wise it wouldn't really make too much
difference as multiple processes will be created, anyway.

 2) Unfortunately, I don't have the time for such a thing right now.
PS and Framemaker do generate lists of vectors but I don't know if a
converter exists from those to SVG. Someone else is working on a GTK4
port and I don't know if his changes will address this as I believe he
was planning on collapsing the redundant print.c code into what
signal.c/waveform.c already does.

 3) The rc variables fontname_signals and fontname_waves should allow
changing the fonts. See function do_font_load() in fonts.c.

 Best regards,
 -Tony

	----------------------------------------- From: "Sujay Phadke"
 To: gtk...@li...
 Cc:
 Sent: Sunday March 19 2023 11:52:19PM
 Subject: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

 Hello everyone,  First of all, I must say the GTKWave is an excellent
program. Kudos! 
 I wanted to request the following: 1. Signal name for process filter
script - currently, I have a python script used as a process filter
for various signals. However, I want to parse the input data
differently, based on what signal it is coming from. Example: for
signal0 I may want to convert “-1” to “None”. However, I may
not want to do that for signal1 
 The only want I know of currently is to attach different scripts to
different signals, which is inefficient. Is there a way that the
signal name could also be passed on to the script?  
 2. Please consider having the ability to export the current view as
SVG file. It makes it much more efficient for presenting or pasting
into a webpage.  
 3. Can the font color of the text inside the waves be changed? I can
only change the background color of a waveform using the
“?bgcolor?” prefix before the name. Problem is, some background
colors are useless since the text inside is too light in color. I’m
forced to use only dark backgrounds as a result.  
 Best regards, Sujay   _______________________________________________
 Gtkwave-users mailing list
Gtk...@li...
 [1]https://lists.sourceforge.net/lists/listinfo/gtkwave-users [2]
  

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/gtkwave-users
[2] https://lists.sourceforge.net/lists/listinfo/gtkwave-users

Re: [Gtkwave-users] Requests: signal name for bound process script, export SVG,

[Sujay P. <ele...@gm...>]

Hey Tony,
   Thanks for the reply. But I don't understand the responses 1 and 3:

1. Yes, a new process will be spawned for every signal. However, the logic
of the executable will still remain the same. I want to do something like:

if 'sig_name' == 'signal0':
     sys.stdout.write('None\n')
else:
     sys.stdout.write(readline)

Unless we pass the metadata for the signal, I don't see how a separate
process will help. Either passing in the signal name/id as metadata on
stdin, alongwith the signal values, or calling the process with an argument
in the TCL script would work.
Is there a way to accomplish this?

3. I know about those rc variables. However, those are static aren't they?
I want to be able to change the waveform text foreground color dynamically
(per wave phase), just as we do with the background color (using the ?...?
prefix before the value in the translation file).
Is there a way to do this?


On Mon, Mar 20, 2023 at 1:01 PM <by...@nc...> wrote:

> Thanks for your comments.
>
> 1) Each signal has a separate process instance / set of stdin/stdout
> attached to it for process filter, so even though you'd be able to use a
> single script, performance-wise it wouldn't really make too much difference
> as multiple processes will be created, anyway.
>
> 2) Unfortunately, I don't have the time for such a thing right now.  PS
> and Framemaker do generate lists of vectors but I don't know if a converter
> exists from those to SVG.  Someone else is working on a GTK4 port and I
> don't know if his changes will address this as I believe he was planning on
> collapsing the redundant print.c code into what signal.c/waveform.c already
> does.
>
> 3) The rc variables fontname_signals and fontname_waves should allow
> changing the fonts.  See function do_font_load() in fonts.c.
>
> Best regards,
> -Tony
>
> -----------------------------------------
> From: "Sujay Phadke"
> To: gtk...@li...
> Cc:
> Sent: Sunday March 19 2023 11:52:19PM
> Subject: [Gtkwave-users] Requests: signal name for bound process script,
> export SVG,
>
> Hello everyone,
>     First of all, I must say the GTKWave is an excellent program. Kudos!
>
> I wanted to request the following:
> 1. Signal name for process filter script - currently, I have a python
> script used as a process filter for various signals. However, I want to
> parse the input data differently, based on what signal it is coming from.
> Example: for signal0 I may want to convert “-1” to “None”. However, I may
> not want to do that for signal1
>
> The only want I know of currently is to attach different scripts to
> different signals, which is inefficient. Is there a way that the signal
> name could also be passed on to the script?
>
> 2. Please consider having the ability to export the current view as  SVG
> file. It makes it much more efficient for presenting or pasting into a
> webpage.
>
> 3.  Can the font color of the text inside the waves be changed? I can only
> change the background color of a waveform using the “?bgcolor?” prefix
> before the name. Problem is, some background colors are useless since the
> text inside is too light in color. I’m forced to use only dark backgrounds
> as a result.
>
> Best regards,
> Sujay
> _______________________________________________
> Gtkwave-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtkwave-users
>

Re: [Gtkwave-users] Requests: signal name for bound process script, export SVG,

[<by...@nc...>]

Thanks for your comments.

1) Each signal has a separate process instance / set of stdin/stdout
attached to it for process filter, so even though you'd be able to use
a single script, performance-wise it wouldn't really make too much
difference as multiple processes will be created, anyway.

2) Unfortunately, I don't have the time for such a thing right now. PS
and Framemaker do generate lists of vectors but I don't know if a
converter exists from those to SVG. Someone else is working on a GTK4
port and I don't know if his changes will address this as I believe he
was planning on collapsing the redundant print.c code into what
signal.c/waveform.c already does.

3) The rc variables fontname_signals and fontname_waves should allow
changing the fonts. See function do_font_load() in fonts.c.

Best regards,
-Tony

	-----------------------------------------From: "Sujay Phadke" 
To: gtk...@li...
Cc: 
Sent: Sunday March 19 2023 11:52:19PM
Subject: [Gtkwave-users] Requests: signal name for bound process
script, export SVG,

 Hello everyone,  First of all, I must say the GTKWave is an excellent
program. Kudos! 
 I wanted to request the following: 1. Signal name for process filter
script - currently, I have a python script used as a process filter
for various signals. However, I want to parse the input data
differently, based on what signal it is coming from. Example: for
signal0 I may want to convert “-1” to “None”. However, I may
not want to do that for signal1 
 The only want I know of currently is to attach different scripts to
different signals, which is inefficient. Is there a way that the
signal name could also be passed on to the script?  
 2. Please consider having the ability to export the current view as
SVG file. It makes it much more efficient for presenting or pasting
into a webpage.  
 3. Can the font color of the text inside the waves be changed? I can
only change the background color of a waveform using the
“?bgcolor?” prefix before the name. Problem is, some background
colors are useless since the text inside is too light in color. I’m
forced to use only dark backgrounds as a result.  
 Best regards, Sujay

[Gtkwave-users] Requests: signal name for bound process script, export SVG,

[Sujay P. <ele...@gm...>]

Hello everyone,
    First of all, I must say the GTKWave is an excellent program. Kudos!

I wanted to request the following:
1. Signal name for process filter script - currently, I have a python
script used as a process filter for various signals. However, I want to
parse the input data differently, based on what signal it is coming from.
Example: for signal0 I may want to convert “-1” to “None”. However, I may
not want to do that for signal1

The only want I know of currently is to attach different scripts to
different signals, which is inefficient. Is there a way that the signal
name could also be passed on to the script?

2. Please consider having the ability to export the current view as  SVG
file. It makes it much more efficient for presenting or pasting into a
webpage.

3.  Can the font color of the text inside the waves be changed? I can only
change the background color of a waveform using the “?bgcolor?” prefix
before the name. Problem is, some background colors are useless since the
text inside is too light in color. I’m forced to use only dark backgrounds
as a result.

Best regards,
Sujay

Re: [Gtkwave-users] GHDL wave file issues

[<by...@nc...>]

Unfortunately, that's a function of how GHW dumps signals. What I'd do
is probably recursively load everything from some hierarchy (right
click in the sst tree pane) and erase whatever signals you don't need.

-Tony

	-----------------------------------------From: "Carl Pedal via
Gtkwave-users" 
To: gtk...@li...
Cc: "Carl Pedal"
Sent: Wednesday October 26 2022 4:24:21PM
Subject: [Gtkwave-users] GHDL wave file issues

 Hi, 
 When using GHDL wave file, some signals appear in the upper tree view
rather than in the lower signal pane as when using VCD format. When
there are many signals it becomes cumbersome to klick each individual
icon in the tree view and then select the signal in the lower signals
pane and then add the signal. Is there a way to get around this? If
FST/VCD supported integers I would stick with that, but for some
reason i can only see LSB (one bit) of any integer in the VHDL code. 

 Thanks in advance.

 /Carl

[Gtkwave-users] GHDL wave file issues

[Carl P. <ped...@ya...>]

Hi,

When using GHDL wave file, some signals appear in the upper tree view rather than in the lower signal pane as when using VCD format. When there are many signals it becomes cumbersome to klick each individual icon in the tree view and then select the signal in the lower signals pane and then add the signal. Is there a way to get around this? If FST/VCD supported integers I would stick with that, but for some reason i can only see LSB (one bit) of any integer in the VHDL code.





Thanks in advance.

/Carl

Re: [Gtkwave-users] OSX launcher script improvement

[Daniel O'C. <da...@do...>]

Hi Tony,

> On 10 Oct 2022, at 05:50, by...@nc... wrote:
> I'd say upload the patch file to github.  That bug reporting system often is easier for this kind of thing.
> 
> https://github.com/gtkwave
> 
> Everything's been moving to github.  SF is around for historical reasons for the super-turbo-stable release branch.

OK thanks, I'll re-do it as a PR.

I didn't realise things had moved to GitHub as most of the links I found pointed at SourceForge (or were dead).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

Re: [Gtkwave-users] OSX launcher script improvement

[<by...@nc...>]

Daniel,

I'd say upload the patch file to github. That bug reporting system
often is easier for this kind of thing.

https://github.com/gtkwave

Everything's been moving to github. SF is around for historical
reasons for the super-turbo-stable release branch.

-Tony

	-----------------------------------------From: "Daniel O'Connor via
Gtkwave-users" 
To: gtk...@li...
Cc: "Daniel O'Connor"
Sent: Saturday October 8 2022 11:31:40PM
Subject: [Gtkwave-users] OSX launcher script improvement

 Hi,
 I am having trouble with gtkwave built from Macports so I downloaded
the prebuilt binary (3.3.107) which does work, however the launcher
has a limitation where it expects CWD to be in the bundle.

 This is a bit limiting as it makes it harder to call from the command
line, however it is easily fixed:
 --- a/contrib/bundle_for_osx/launcher.sh 2022-10-09
13:27:22.000000000 +1030
 +++ b/contrib/bundle_for_osx/launcher.sh 2022-10-09
13:02:47.000000000 +1030
 @@ -10,11 +10,8 @@
 EXEC=exec
 fi

 -name="`basename $0`"
 -tmp="`pwd`/$0"
 -tmp=`dirname "$tmp"`
 -tmp=`dirname "$tmp"`
 -bundle=`dirname "$tmp"`
 +name=$(basename $0)
 +bundle="$(cd `dirname $0`; cd ../..; pwd)"
 bundle_contents="$bundle"/Contents
 bundle_res="$bundle_contents"/Resources
 bundle_lib="$bundle_res"/lib

 (this is a hand edited patch so the filenames might be wrong)

 I was going to file a patch on sf.net but it appears to be disabled
so I am posting it here.

 --
 Daniel O'Connor
 "The nice thing about standards is that there
 are so many of them to choose from."
 -- Andrew Tanenbaum

 _______________________________________________
 Gtkwave-users mailing list
 Gtk...@li...
https://lists.sourceforge.net/lists/listinfo/gtkwave-users
 />

[Gtkwave-users] OSX launcher script improvement

[Daniel O'C. <da...@do...>]

Hi,
I am having trouble with gtkwave built from Macports so I downloaded the prebuilt binary (3.3.107) which does work, however the launcher has a limitation where it expects CWD to be in the bundle.

This is a bit limiting as it makes it harder to call from the command line, however it is easily fixed:
--- a/contrib/bundle_for_osx/launcher.sh        2022-10-09 13:27:22.000000000 +1030
+++ b/contrib/bundle_for_osx/launcher.sh        2022-10-09 13:02:47.000000000 +1030
@@ -10,11 +10,8 @@
     EXEC=exec
 fi

-name="`basename $0`"
-tmp="`pwd`/$0"
-tmp=`dirname "$tmp"`
-tmp=`dirname "$tmp"`
-bundle=`dirname "$tmp"`
+name=$(basename $0)
+bundle="$(cd `dirname $0`; cd ../..; pwd)"
 bundle_contents="$bundle"/Contents
 bundle_res="$bundle_contents"/Resources
 bundle_lib="$bundle_res"/lib

(this is a hand edited patch so the filenames might be wrong)

I was going to file a patch on sf.net but it appears to be disabled so I am posting it here.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

[Gtkwave-users] Marking dumpfile and savefile paths storage in savefile optional

[Wilfried C. <wil...@it...>]

Hello,

First of all thank you for building this tool. I'm learning FPGA arcanes on
my own and this tool is helping me so much!

I like keeping track of the savefile along the RTL in version control (git
in my case).

However, gtkwave stores file paths with are irrelevant between users/repo
clones.
I removed it from the file manually before staging it but it'd be nice to
have an option to prevent gtkwave from storing
paths (or at least only store dumpfile's paths relative to the savefile) so
that it does not show spurious changes in the version control system.

Best regards,
Wilfried.

Re: [Gtkwave-users] Adding bus signals manually to the savefile

[<by...@nc...>]

> You are right. Still the gtkwave GUI does what you describe, doesn't
it?

For some functions, yes. However, a user searching for a single string
versus a save file attempting to load hundreds of signals are
different usage cases.

> Nonetheless I have the impression that the savefiles weren't
designed for manual editing and I should find another workaround like
generating them using a script :(

They can be manually edited, but unfortunately it's a tedious process
in cases where signals are split up into individual bits. 

A long time ago, I did have wild card match and you can see parts of
it in the savefile.c source where the variable wild_active is used in
places, but as sim models became larger, it really wasn't a usable
option anymore.

-Tony

	-----------------------------------------From: "Gökçe Aydos" 
To: gtk...@li...
Cc: 
Sent: Thursday December 23 2021 5:07:35AM
Subject: Re: [Gtkwave-users] Adding bus signals manually to the
savefile

 > No, there's not as you can't hash search on an * character. Going
through signals one at a time is not an option with huge models such
as a full chip with tens of millions of signals.

 You are right. Still the gtkwave GUI does what you describe, doesn't
it?

 Gtkwave shows me the signal as `s[0][0:649]`. Then I can *recurse
 import* this signal. The savefile could implement something similar.

 > Verilog (except for Modelsim occasionally) would dump as 0:639. GHW
treats every bit as its own signal.

 Still gtkwave can generate a bus view from many individual signals
using the flags like `@28`.

 Nonetheless I have the impression that the savefiles weren't designed
for manual editing and I should find another workaround like
generating them using a script :(

 _______________________________________________
 Gtkwave-users mailing list
 Gtk...@li...
https://lists.sourceforge.net/lists/listinfo/gtkwave-users
 />

Re: [Gtkwave-users] Adding bus signals manually to the savefile

[Gökçe A. <gtk...@ay...>]

> No, there's not as you can't hash search on an * character.  Going through signals one at a time is not an option with huge models such as a full chip with tens of millions of signals.

You are right. Still the gtkwave GUI does what you describe, doesn't it?

Gtkwave shows me the signal as `s[0][0:649]`. Then I can *recurse
import* this signal. The savefile could implement something similar.

> Verilog (except for Modelsim occasionally) would dump as 0:639.  GHW treats every bit as its own signal.

Still gtkwave can generate a bus view from many individual signals using the flags like `@28`.

Nonetheless I have the impression that the savefiles weren't designed for manual editing and I should find another workaround like generating them using a script :(

Re: [Gtkwave-users] Adding bus signals manually to the savefile

[Anthony B. <by...@nc...>]

No, there's not as you can't hash search on an * character.  Going through signals one at a time is not an option with huge models such as a full chip with tens of millions of signals.

Verilog (except for Modelsim occasionally) would dump as 0:639.  GHW treats every bit as its own signal.

Given how signals and datatypes are defined in VHDL, I don't know if it's possible for GHDL to dump as vectors like Verilog does.

-Tony

On Dec 22, 2021, 12:53 PM, at 12:53 PM, "Gökçe Aydos" <go...@ay...> wrote:
>I write my savefiles manually, because I distribute the savefiles
>across
>different environments like this:
>
>> [dumpfile] "wave.ghw"
>> top.tb.clk
>> top.tb.rst
>
>Is there a syntax to add a very wide signal like as follows?
>
>> #{wide_signal} top.tb.s[0][0:639]
>
>or
>
>> #{wide_signal} top.tb.s[0][*]
>
>Gtkwave creates a verbose string with all the components of the bus
>like this if I save the savefile.
>
>> ...
>> #{wide_signal} top.tb.s[0][0] top.tb.s[0][1] ... top.tb.s[0][639]
>
>
>_______________________________________________
>Gtkwave-users mailing list
>Gtk...@li...
>https://lists.sourceforge.net/lists/listinfo/gtkwave-users

[Gtkwave-users] Adding bus signals manually to the savefile

[Gökçe A. <go...@ay...>]

I write my savefiles manually, because I distribute the savefiles across
different environments like this:

> [dumpfile] "wave.ghw"
> top.tb.clk
> top.tb.rst

Is there a syntax to add a very wide signal like as follows?

> #{wide_signal} top.tb.s[0][0:639]

or

> #{wide_signal} top.tb.s[0][*]

Gtkwave creates a verbose string with all the components of the bus like this if I save the savefile.

> ...
> #{wide_signal} top.tb.s[0][0] top.tb.s[0][1] ... top.tb.s[0][639]

Re: [Gtkwave-users] Win10, configure --prefix=... FAIL

[<by...@nc...>]

I'll look at this but I don't believe there is anything different in
configure.ac regarding Tcl/Tk for MinGW--at least regarding prefix
usage.

-Tony

	-----------------------------------------From: "Kuang-Chun Cheng" 
To: gtk...@li...
Cc: 
Sent: Tuesday December 21 2021 12:22:37AM
Subject: [Gtkwave-users] Win10, configure --prefix=... FAIL

 Hi,

 For gtkwave-gtk-3.3.111
 if I try to install to other location

 ./configure --prefix=/home/user/mylocal/
 make

 I will get the following error message:

 ...
 checking if structure packing should be enabled... no
 checking if Tcl usage should be disabled... no
 checking for Tcl configuration... found /usr/lib/tclConfig.sh
 checking for existence of /usr/lib/tclConfig.sh... loading
 checking for Tk configuration... configure: error: Can't find Tk
configuration definitions. Use --with-tk to specify a directory
containing tkConfig.sh

 when prefix is used, the internal check will reference to wrong
location:
 /usr/lib/tclConfig.h
 /usr/lib/tkConfig.h

 The following workaround will fix the problem:

 ./configure --prefix=/home/user/mylocal/ 
 --with-tcl=/mingw64/lib 
 --with-tk=/mingw64/lib

 FYI

 Regards
 KC