TypeWriter can accept Observable<KeyNotifications> instead of KeyboardDevice for increased compatibility

vvvv gamma feature
1

I needed TypeWriter, a great tool, but it was designed with Skia in mind. I want to use it with Stride and GlobalKeyboard. But the input to TypeWriter needs a device, a keyboard. I have worked out that I need to remove a node from the input and leave an Observable on the input. Made Vl.CoreLib editable and edited it, works fine. Then the problems start. If I make the library uneditable again, for some reason the library is not recompiled. Such changes also lead to export problems. Both in editable and non-editable mode. Exporting results in an error. I tried to do it with Nuget Overdrive, but that is also impossible because Vl.TypeWriter starts to conflict with itself and does not overdrive anything.

VL.Typewriter.vl (567.3 KB)

So how can I make changes to such a thing so that it can be used and shared with other users, for example?

2

Rather than modifying stuff that comes with Gamma (which imo looks like an anti-pattern anyway), you could either :

3

to work with any type of keyboard, it only needed to be changed in a few places and it worked. I am projecting experience from Beta, when modification “in place” was standard and always practised. But how to deal with this kind of situation now? Is there a strategy for immediate modification?

All of the options offered are very long, complicated and time consuming. Don’t take this the wrong way, but my hands are dropping.

Let’s say this is the part where it’s an option to share code changes — github, wip section, addons. But the problem now is that I can’t apply such a change. Does that mean I can’t change CoreLib at all and in case there is an error there, I need to wait for the changes in the main branch?

Since there is a need to build a standard library, I think the problem is at that level.

UPD: Changed the thread title to make my suggestion

4

I had a similar issue recently, I ended up making a new patch, with a unique name, copied and pasted everything in, including any internal patches, then modifying and using that. The reverting to library thing confused me too!

5

@catweasel Seems like I’m on my way there too
but can’t figure out how to do it properly.
Would be grateful if you could upload your solution.

6

@yar I think you’ve asked a similar question before:

7

@bjoern yep

but VL.TypeWriter is not a nuget, it’s a part of the Standard Library

And there’s a profound difference between editing what’s in the main assembly and what’s in the external modules

In short, editing in this way causes a whole cascade of problems:

  1. the library must be forcibly rebuilt. It is not enough to simply disable ‘editability’.

  2. If the library has been edited and ‘editability’ is off, the changes will not take effect.

  3. If the library has been edited and ‘editable’ is off, export errors will occur.

  4. simply copying VL.TypeWriter as an external module causes a conflict.

could be a workaround, just put it in the nuget overdrive folder:
VL.TypeWriterCustom.zip (117.7 KB)

1 Like
8

I just tried and in principle it works as described in the other thread. But it looks like there is a bug with caching . The--nocache parameter doesn’t seem to work and once a pack is deleted from the cache it doesn’t get “re-cached”. @Elias .
I tried with a 6.2 installation though to not mess up the 6.3 one I am currently working with.

  1. start vvvv with --editable-packages VL.CoreLib
    image
  2. make your changes
  3. quit vvvv
  4. go into the package-cache folder and delete the VL.CoreLib.2024.6 folder
  5. start vvvv again without the parameter
    image
    image1273×873 39.5 KB
2 Likes
9

Here is a modified TypeWriter which can just be referenced and used.
VL.Text.Typewriter.vl (19.0 KB)

1 Like
10

@bjoern thank you very much for the in-depth investigation.

Please also try to export an application with a modified VL.CoreLib

Yeah, really, it confused me the most, I think.

11

The --nocache flag only works for packages not shipped with vvvv itself. For example the ones you installed via nuget or those you load from source.
Those shipped with vvvv itself get compiled on our build server and get some sort of special treatment apparently, bypassing that particular flag.
In any case, you should not modify files in the vvvv install folder or any installed nuget package for that matter. It will give you troubles in the long run, for example when starting the patch on another machine, or updating the package or updating vvvv or when building a new patch, or worse other patches depending on that node might break apart.
Like others pointed out already, make a copy of the patch and give it a new name. Should that copy have red nodes because of dependencies to internal nodes and it’s too much of a hassle to copy those too, you can mark the dependency to for example VL.CoreLib with IsFriend="true" in the .vl file (this needs to be done with a text editor, we don’t offer this in the UI as we don’t want to encourage anyone of doing so. It’s an undocumented feature to get you out of some rare cases like the one you describe).

1 Like
12

@yar
I just updated VL.IO.MouseKeyGlobal to the latest version of SharpHook, while at it I also added the TypeWriter node with Key Notification input, so it now comes with the package (>= v.5.3.5).

3 Likes
13

@bjoern thank you very much! a small thing, but important

In any case, it makes sense to change this in the main repository by adding such a node. Because currently TypeWriter from the standard library is only compatible with Skia