Every now and then it rains, and it's the weekend.......
This forum is a bit quiet on weekends...... and so boredom sets in.

I have put this in "tutorials" because it is a fairly simple example of a tcl plugin....... and so it might help understanding of how to use tcl....
There are two plugins that you can use straight away. Either one of them (or both) should be put into any folder that Pd knows the path to.
Open the console in "verbose" mode (bottom right... log: 4-all) to find the folders that Pd is looking in, or would like to find but they are missing at startup. Create a missing one or a new one on your drive if you wish! For a new one you will need to add it to the Pd search paths in "preferences"....
As they (the "-plugin" files) both set the same parameters...... change the Pd window background colour for each day of the week........ if Pd finds both of them then the last one found will be executed last and so its values will be those that are retained.....
If you don't want it to run then just remove it from that folder!
It will run as Pd starts up.......

I have included a tcl colour list so that you can easily change the colours to some that you like.......
This one works with extended in windows, and should work for extended in all OS's.
screen_colour_extended .zip

Open up the foo_bar-plugin.tcl files to see what is inside......!!!
tcl is simple but very very fussy about its format...... the brackets look funny, but if you move them to the next/previous line then you will be sent a lot of red ink............. "Back to School"!!!.......
Here it is for vanilla (windows-yes... others-?)......
screen_colour_vanilla.zip
Please let me know of any success /failure...........
This (with a colour picker) should work for vanilla and extended.........
choose_colour.zip
David.

@Johnny-Mauser
It can be done quite easily with extended as most Pd screen items can be addressed..........

You can send the same messages within the plugin......... it is just that I had only set "canvas_fill"........

However the tcl for vanilla sets a colour for the window background and then a "palette" is calculated for the frame and the contents in an attempt at preserving contrast and "readability".
You can trawl pd\lib\tk8.5\palette.tcl
palette.tcl
for clues...... and if there are fooTheme.tcl files in your release then you will find more clues......
I have not found the equivalent of specific items (like cord_nlet) in vanilla as yet........
David.

Does this plugin let us differentiate the colors of audio v. control inlets and outlets? It's the one major complaint that I have after getting forced back to vanilla: they all look the same.

In extended, there was a canvas tag for signal inlet/outlets, but in vanilla there isn't.

You could overwrite the pdtk_text_new proc to check against a list of signal objects though, and then add a canvas tag.

You can use this to help - https://github.com/Monetus/Ketea-theme-plugin

No, sorry, you wouldn't want to overwrite pdtk_text_new, but probably pdtk_text_editing.

and use the command

$mytoplevel.c itemcget $tag -text 

to get the text you'd compare.

@Monetus @kevinschlei
Could you elaborate a little Monetus...... I have been looking at this but I came to the conclusion that the cord colour would have to be set as the objects are traversed and the window is drawn. I was thinking (never tried before!) of re-compiling vanilla, putting back into g_canvas_c the cord variables ($signal_cord and $msg_cord) that were present in extended.......
But of course a plugin is preferable...
vanilla

static void canvas_drawlines(t_canvas *x)
{
    t_linetraverser t;
    t_outconnect *oc;
    {
        linetraverser_start(&t, x);
        while (oc = linetraverser_next(&t))
            sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags [list l%lx cord]\n",
                    glist_getcanvas(x),
                        t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2, 
                            (outlet_getsymbol(t.tr_outlet) == &s_signal ? 2:1),
                                oc);
    }
}

extended

static void canvas_drawlines(t_canvas *x)
{
    t_linetraverser t;
    t_outconnect *oc;
    int issignal;
    
        linetraverser_start(&t, x);
        while (oc = linetraverser_next(&t))
    {
        issignal = (outlet_getsymbol(t.tr_outlet) == &s_signal ? 1 : 0);
        sys_vgui(".x%lx.c create line %d %d %d %d -width %d -fill %s \
-tags [list l%lx cord]\n",
                 glist_getcanvas(x), t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2, 
                 (issignal ? 2:1), (issignal ? "$signal_cord" : "$msg_cord"),
                 oc);
    }
}

David.

Recompiling vanilla with the appropriate C code would be the best way to go about this, as it would just work and not have to be hacked in on the tcl/tk side.

A lot of the C has tcl baked into it that is somewhat inconvenient, but I wanted to get a better understanding of everything thats going on before I change things. Its going to have to be changed though. By that point I'd like to look into whats going on in purr-data to get some more perspective.. might be good to make some abstraction there.

The way I've been coloring the coords right now though is`

bind PatchWindow <<Editmode>> {+themed::configure_upon_editmode %W}

which binds to the virtual event triggered when changing between edit/run mode and calls this test

if {$::editmode($window) eq 1} {
      themed::configure_for_editmode $tkcanvas
    } else {
      themed::configure_for_runmode $tkcanvas
    }

that consequently triggers this if in editmode (could add a change for run mode)

$tkcanvas itemconfigure {cord || graph || obj} -fill $themed::active_fg

See? It just takes the name of the canvas (which is a somewhat obfuscated string I think might be a memory address substituted in the sys_gui(".x%lx.c ... function) and tells tk that everything tagged with coord, graph, or obj should all be colored the same. Here are the tk docs for more info on the command

it has to change the color of something already drawn. Thats not too much of a problem for coords since the editmode event is triggered all the time. But for things like a graphical array that is being used as an oscilloscope and constantly redrawn, the only sane way is to recompile a fork of vanilla.

What I was telling @kevinschlei was that he could go into the autocomplete plugin I was testing and copy the objects variable, which is just a huge list of all the vanilla objects. If you deleted all the non-tilde objects, you could use introspection to find the text of the obj and make a comparison to the audio objects list and color all their inlets/outlets.

I posted again and said overwrite the pdtk_text_editing proc, but no, that was wrong. It'd probably just be best to bind to editmode or focusin events... But you'd do something like this.

#find all the outlets
set outlet_list [$tkcanvas find withtag outlet]
foreach tag $outlet_list {
    #find the text in the outlet's object
    set text_tag [string range [lindex [$tkcanvas gettags $tag] 0] 0 end-2]
    set text [$tkcanvas itemcget $text_tag]
    #see if its in the audio_objects list
    set text_check [lsearch -exact $audio_objects $text]
    if {$text_check ne -1} {
        #if it is an audio object then color away
        $tkcanvas itemconfigure $tag -fill $anything -outline $also_anything
    }
}

Note that I'm sure there are more efficient ways to go about doing that^

@Monetus Thank you very much @Monetus.... I understand now.......
I will definitely trawl through your code when I get a moment....... and have a go at a new compilation (for windows). It seems it is time to start learning again!
David.

Hi, did anyone find a way to set vanilla gui object's colors, like cords, inlets, etc?

@bamboomusic Maybe.... @seb-harmonik-ar has posted something here.......https://forum.pdpatchrepo.info/topic/10943/a-little-pd-mod
I have not looked into it yet..... as using exclusively windows..... but if he has made changes to some tcl code then......... ?
David.

yes it should work fine on windows if you can compile it.. If you do maybe post a binary
same for linux..

I also opened a pull request here https://github.com/pure-data/pure-data/pull/196 and one of the commits has just the colors added in.. hopefully that will make it into the next release for vanilla

In my pd mod there's a .txt file in the docs: Pure Data/7.stuff that has the available colors (I added some that were not in Pd-Extended yet, like GOP boxes and text highlighting)

edit: I did fix the binary compatibility problem referenced in the Pull Request in this release btw

One note: I have set the outlet height to look ok on OS X but haven't been able to test it on other systems.. hopefully it's ok

@Newk
It's been a while, and then post surgery my brain has recently been rendered somewhat dumb.
Anyway, colours in Vanilla, always good for some fun.
Work in Progress.

It does quite a lot when you switch to edit mode, and the colours stick when you switch back.
Anything added to the patch (or edited) has the standard colours.... but switch out of edit mode and back in and the new colours are there.
I am wondering if that could be useful.......?
So a few new ideas could come out of this..........
Certainly Windows Vanilla 0.49......... vanilla_colours-plugin.tcl
Put it in a Pd known path, and delete it or move it elsewhere to stop the magic.
Please let me know if it works on other systems.
Edit the file to change colours or if you don't like arrows in edit mode.... it's fairly obvious.
Available colours........ tcl colours.txt
Some things not working.
Some weird stuff.
When it is finished I will make a menu item for the console so that colours can be chosen..... maybe.....
David.

@whale-av Hi, I've just tried it by placing the plugin in my externals folder on Win 10 Pd 0,49. When I first open a patch it looks a little disconcerting until I enter edit mode.
Looks really useful though.
Cheers
Balwyn

@Balwyn Might solve that......... vanilla_colours-plugin.tcl
Might not.
It's a shame if it has to be tailored to different systems, but that did seem likely.
You are free to play with the contents and see what you can achieve.
David.