GuideMe (TeaseMe v2.0) - Current Build 0.4.4

[tr0gd0r]

Ah right. Such is the nature of cross platform development!

I've also noticed some issues with forms not working, but it's not terribly urgent (I would image the number of users on Linux to be pretty small!)

[DarkPassenger]

Yes I agree, there can't be that many users on Linux, don't spend to much time on this. As long as it's not crashing I'm happy, I can live with VLC opening in a separate window

[RemiHiyama]

*shrug* If I can't fix it I can't fix it, but I've no intention of not at least giving it a shot.

Especially since I wouldn't be at all surprised if the new window behavior breaks some of the other stuff the video tag is supposed to be able to do.

[bobhill]

Especially since I wouldn't be at all surprised if the new window behavior breaks some of the other stuff the video tag is supposed to be able to do.

Perhaps like this?

Crop.jpg (159.38 KiB) Viewed 3257 times

Edit/Solved: So, this was being caused by me setting the "Compatibility" file property on javaw.exe to a high DPI setting: "System (Enhanced)" in Windows 10. I need to do this to properly scale some applications. I changed the setting to "System", and it solved the issue. Hopefully nobody else has this problem, but if so, that's the problem!

[RemiHiyama]

Perhaps like this?

It's not what I was thinking of, but it's certainly worth looking into as well.

Still, I'll need some more information. What OS are you on, did you have the same issue with 4.4, any vlc related errors in your log files?

[EroticDevelopment]

Hi all, I'm still here just had a bit longer hiatus than planned. I got sick for a few weeks, was travelling to see family around both Thanksgiving and Christmas, had vacation in the middle, and before all of that I got a new desktop and really just finished setting up my development environment again.

This is going to be a long one short novel, but I think it covers most of what I've missed.

I actually got a functioning build environment for this working, and think I understand enough of the coding side of things to start trying to fix some issues and add some features, but I don't really get git, so...

Ugh, I don't know what I'm trying to say. I mean, it's open source and so anyone can fork it at any time, but I don't want to step on any toes, you know?

Not stepping on toes at all, I moved the entire build process to GitHub actions for exactly this reason. Philo did amazing work, and I don't want to minimize that at all, but the build/release process was a bit complicated and hard for newcomers to get it going. The idea here was anyone can fork it and have working builds fully automated.

To add to that, I'm always open to help and pull requests. In fact I personally think having multiple people who know the code and regularly contribute is the best way to make sure the project keeps forward momentum and relies less on a single person.

Not just hasn't posted, according to user statistics he hasn't done anything on the site since August, which is the sort of thing that makes me wonder if maybe he's just moved on.

Yeah, I should do better about actually logging in... Since the forums are public I usually just browse the forums and don't login unless I'm replying or need to access DMs, and I get email notifications for those.

I've got this idea that it'd be much more pleasant to write this:

Code: Select all

addButton({target: "exit", text: "Stop", hotkey: "s"})

than this:

Code: Select all

addButton("exit", "Stop", "", "", "", "", "s")

It's interesting that you mention this format of using JS objects instead of multiple parameters. I had this same idea, and I would love to see this implemented. Since JS doesn't support function overloading it's not easy to have multiple functions with one or two parameters. With passing an object like this is becomes easy and I think it would make for much easier JS development for tease authors.

Remi, huge thanks for the Log4J updates. I had to deal with this across dozens of applications at work and it has been a complete pain in the ass. The update itself it pretty straightforward, but the scope of impact on this one was huge. I have the added benefit of applications that require HIPAA, PCI, and other regulatory requirements that make this even more sensitive. I agree with your assessment on impact here - overall less likely to be exploited in our usage, but it definitely opens up a potential privacy issue and that alone is a reason to get it patched quickly. Apologies I did not get to this sooner, and thank you again for working on this. I've made multiple updates to try to keep vendor libraries up to date, and I'm not aware of any other security vulnerabilities, but it's worth re-iterating what you mentioned here:

Also, keep in mind that GuideMe is not a secure sandbox. I'm not aware of any other code execution vulnerabilities, but a guide can still send data to any web server it wants via ordinary html. Use caution with teases made by people you don't know, and I recommend not entering your real name or other personally identifiable information into GuideMe.

Given the nature of the program it would be very difficult if not impossible to fully protect against malicious teases. As Remi said, it's good to exercise caution when using teases from people you don't know. The nice thing is the teases can be reviewed and I would hope anything malicious would be spotted and removed fairly quickly.

Hmmm. I did some searching for that option and found this issue in vlcj's github: https://github.com/caprica/vlcj/issues/929

And it's fixed... in vlcj-4.4.2 and up.

GuideMe currently uses 3.12.1

That may not be a trivial upgrade.

It's a pretty miserable upgrade, but one I want to do for a number of other reasons in addition to this. It has been on my list to work on as well. I think this update would be made much easier by creating some new classes for the audio and video players that aren't as tied in to the main UI classes.

So I decided to do some searching for vlcj unexpectedly opening new windows, and found some pages saying that happened when there was an issue with a window handle (or window surface, or something like that) being invalid.

There's some weirdness around the window handle and video surface for VLC, so I'm not terribly surprised here. To be honest, this part of the application needs some TLC. I think most of this will resolve itself if we update VLCj, because new versions have different requirements for the window handle and video surface, but we'll see.


Now, for what's next. Remi, if you have other items you're working on, please feel free to create issues as needed, comment on ones you're working on, and open merge requests etc. I'll try to clean up any of these you've resolved as I merge code back up. If you have interest in contributing to the development I'll gladly take the help, and I think it would benefit everyone if we have multiple people working on it.

I'm going to merge most if not all of what Remi has done back into my repo and tag the release(s). At a minimum, I'll tag a newer release that has the Log4J updates. I may need to adjust some version tags slightly. While I like the approach of having a release number and/or alpha build number, the block of code that processes the app version needs some work and only accepts a 3-part version like X.X.X, so it may not properly check app versions. Versions like 0.4.5.1 may not be interpreted as we'd like, and this may need to become 0.4.6. I want to replace this code with an actual Semver library that can read alpha/beta tags properly as well, so if time allows maybe I'll try to get that added and keep your version number.

I think we have a few options here going forward, and I'd really like some other opinions. Should we just drop the leading 0 and move to 4.5.1 etc? I'm inclined to go this route since this is how everyone has been referring to versions and at least to me going to 1.X would just be confusing.

[RemiHiyama]

With passing an object like this is becomes easy and I think it would make for much easier JS development for tease authors.

Yep, that was the idea. I'm not entirely happy with the system I've come up with for handling this; I keep coming up with how I'd do it in Ruby and then having to work around Java not letting you do that are probably awkward. (And, uh, it seems like the Javascript side won't allow something I thought was going to be necessary/desirable either. Whoops.) Still, having to do the obnoxious part -once- in the app so that people writing teases can do it the easy way makes sense.

It's a pretty miserable upgrade, but one I want to do for a number of other reasons in addition to this. It has been on my list to work on as well. I think this update would be made much easier by creating some new classes for the audio and video players that aren't as tied in to the main UI classes.

It wasn't quite as bad as I'd thought, but there were a couple places where I'm not sure I didn't break something, just that everything seems to work fine without them. (It keeps trying to stop the video when you haven't played a video and I don't know why! o.O Admittedly I haven't been focusing on trying to figure it out, it's just annoying.)

Creating new classes would probably be beyond me. I'm not entirely clear on how a lot of the UI parts work in the first place.

I'm going to merge most if not all of what Remi has done back into my repo and tag the release(s).

I'd actually suggest taking out the addRepeatTimer functions (not the backend code for repeats, just the functions); I doubt anyone's using them yet and it seems silly when the new object-based functions are on their way. I just... hadn't realized I'd be doing that when I wrote those, or at least not so soon.

Hopefully the rest is not too indigestible; I got confused more than a few times about how to get git to do things or which things should be entered where.

Versions like 0.4.5.1 may not be interpreted as we'd like, and this may need to become 0.4.6. I want to replace this code with an actual Semver library that can read alpha/beta tags properly as well, so if time allows maybe I'll try to get that added and keep your version number.

It's not like I had actually changed the internal version number either, might as well do whatever makes sense.

After reading about semantic versioning I'd been thinking "maybe we should just declare this 1.0.0 and go on from there", because the version numbering had been really weird. Going to 4.x will probably be easier on everyone though; it's more or less how everyone had been acting already.

[EroticDevelopment]

With passing an object like this is becomes easy and I think it would make for much easier JS development for tease authors.

Yep, that was the idea. I'm not entirely happy with the system I've come up with for handling this; I keep coming up with how I'd do it in Ruby and then having to work around Java not letting you do that are probably awkward. (And, uh, it seems like the Javascript side won't allow something I thought was going to be necessary/desirable either. Whoops.) Still, having to do the obnoxious part -once- in the app so that people writing teases can do it the easy way makes sense.

It's an interesting problem for sure. Part of me wants to move this project to the Kotlin compiler so we could use a mix of Kotlin and Java as needed since Kotlin would make several things easier in GuideMe, but I also don't want to make the app more complex and difficult for new developers so it's a catch-22. Kotlin compiles to Java bytecode just like "normal" java, so end-users wouldn't be able to tell any difference but it would introduce .kt files and a different syntax in places. Does anyone here have experience with Kotlin or any strong preference here? Part of me also thinks with Kotlin becoming the default for Android development it may be easier for anyone with mobile experience to work on. I suppose it could also open the doors to re-using some of the core code in a mobile version, but that would be a long way down the road.

It's a pretty miserable upgrade, but one I want to do for a number of other reasons in addition to this. It has been on my list to work on as well. I think this update would be made much easier by creating some new classes for the audio and video players that aren't as tied in to the main UI classes.

It wasn't quite as bad as I'd thought, but there were a couple places where I'm not sure I didn't break something, just that everything seems to work fine without them. (It keeps trying to stop the video when you haven't played a video and I don't know why! o.O Admittedly I haven't been focusing on trying to figure it out, it's just annoying.)

Creating new classes would probably be beyond me. I'm not entirely clear on how a lot of the UI parts work in the first place.

I have a handful of XML teases just for testing, so I'll do some testing with those and see if anything stands out. The biggest thing I've fought with is people are using this in many creative ways, some of which aren't really documented or fully supported but they work, and I try not to break those usages either. Sometimes this means someone reporting a bug in a tease that used to work, which isn't ideal.

I'm going to merge most if not all of what Remi has done back into my repo and tag the release(s).

I'd actually suggest taking out the addRepeatTimer functions (not the backend code for repeats, just the functions); I doubt anyone's using them yet and it seems silly when the new object-based functions are on their way. I just... hadn't realized I'd be doing that when I wrote those, or at least not so soon.

Hopefully the rest is not too indigestible; I got confused more than a few times about how to get git to do things or which things should be entered where.

Sounds good, I'll remove those function before tagging that release. The rest all looks good so far, the only thing I saw is it looks like one commit was accidentally reverted that likely shouldn't have been. If this happened the same way I've seen it occur at my day-job, my only suggestion would be to watch usages of "git revert", and make sure the hash you provide that command isn't a merge commit unless you really want to revert all commits that were a part of that merge. Usually you just want a single commit under that merge. I've been the person who resolves nasty Git messes at my day-job for multiple years now, and in my opinion you're doing just fine with Git.

Versions like 0.4.5.1 may not be interpreted as we'd like, and this may need to become 0.4.6. I want to replace this code with an actual Semver library that can read alpha/beta tags properly as well, so if time allows maybe I'll try to get that added and keep your version number.

It's not like I had actually changed the internal version number either, might as well do whatever makes sense.

After reading about semantic versioning I'd been thinking "maybe we should just declare this 1.0.0 and go on from there", because the version numbering had been really weird. Going to 4.x will probably be easier on everyone though; it's more or less how everyone had been acting already.

Yeah, unless there are any strong objections I'll probably plan to release your v0.4.5.1 as v4.5.1 and go forward from there without the leading 0. When I introduce a proper Semver library to check Tease version requirements I'll add something to strip the leading "0." if present for backwards compatibility. That would also let us to alpha/beta/rc releases cleanly, and teases could even specify a minimum version of say "4.6.0-rc.1" and it would know how to verify that.

I've been doing a lot of work today to get Remi's changes merged back in, and so far things are going well. I should have some new releases tagged soon.

[RemiHiyama]

Does anyone here have experience with Kotlin or any strong preference here?

I'm not really clear on what it would make easier, but then my knowledge of Kotlin is pretty limited to "I've heard of Kotlin."

(Gotta admit I'm not thrilled by the idea of bringing in another language I've never done anything with, but I could probably adapt if it was worth it for another reason. It's not like it's Rust or something.)

Sometimes this means someone reporting a bug in a tease that used to work, which isn't ideal.

That reminds me, the only one I've personally run into that was broken is Pilgrim Quest. It seems to work just fine if you manually strip the xml stuff off the .js files that isn't needed anymore. I thought about adding some code to let GuideMe handle that for you (it's probably not the only old tease that broke), but I wasn't really sure how best to do so. Didn't really want to do a naive check, and doing something like "try to parse it as xml, if that throws an exception treat it as plain javascript" seems like bad form. Even if it'd probably work.

Sounds good, I'll remove those function before tagging that release. The rest all looks good so far, the only thing I saw is it looks like one commit was accidentally reverted that likely shouldn't have been.

I'm guessing that'd be when I wasn't paying close enough attention and accidentally merged something with master that I meant to merge with develop, and kinda panicked about it.

Hmm, at this point I probably don't need to maintain that distinction anymore.

[tr0gd0r]

It's great to see development progressing again! I've finally gotten back to my e-stim tease, refactored my spaghetti code into something more maintainable.

Anyway as I previously mentioned, forms seem to be broken (on Linux at least, haven't tried the latest couple of builds on Windows). I get a lot of these errors in the console which seem like they might give a clue:

Code: Select all

[main] ERROR org.guideme.guideme.ui.MainShell -  get form fields null
java.lang.NullPointerException: null
	at org.guideme.guideme.ui.MainShell.getFormFields(MainShell.java:2776) [GuideMe.jar:?]
	at org.guideme.guideme.ui.MainShell.runJscript(MainShell.java:2712) [GuideMe.jar:?]
	at org.guideme.guideme.MainLogic.displayPage(MainLogic.java:153) [GuideMe.jar:?]
	at org.guideme.guideme.MainLogic.displayPage(MainLogic.java:105) [GuideMe.jar:?]
	at org.guideme.guideme.ui.MainShell$shellTimer.run(MainShell.java:1831) [GuideMe.jar:?]
	at org.eclipse.swt.widgets.Display.timerProc(Unknown Source) [org.eclipse.swt.gtk.linux.x86_64-4.6.1.jar:?]
	at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) ~[org.eclipse.swt.gtk.linux.x86_64-4.6.1.jar:?]
	at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(Unknown Source) [org.eclipse.swt.gtk.linux.x86_64-4.6.1.jar:?]
	at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source) [org.eclipse.swt.gtk.linux.x86_64-4.6.1.jar:?]
	at org.guideme.guideme.App.main(App.java:125) [GuideMe.jar:?]

Hopefully it's an easy fix! Again thanks to everyone who is/has contributed to GuideMe over the years!

[RemiHiyama]

Windows form fields seem to be fine. It looks like the evaluate function is returning null, and then the actual error takes place when GuideMe tries to split it. Replacing the entire script with a line that just returns an empty string throws the same error, which I don't believe should be the case unless something going wrong with the function no matter what the actual script is. Everything that's coming up on google for evaluate returning null is because people didn't have return lines in their scripts though, which isn't the case here, so I'm not sure what is going on.

[RemiHiyama]

After some searching, I thought replicating the one-time initialization code in this might be the fix for the "Xlib not initialized for threads." error. It does seem to deal with the same thing.

... But if I do that, GuideMe crashes on startup, so something is obviously wrong.

Maybe using a newer version of VLCJ that has this built in, and making CompositeVideoSurface a subclass of AWTVideoSurface would work, but I think that version of VLCJ requires Java 11. Which... I don't know how important it is to stay Java 8 compatible, so I don't know if that's a problem or not.

[EroticDevelopment]

Maybe using a newer version of VLCJ that has this built in, and making CompositeVideoSurface a subclass of AWTVideoSurface would work, but I think that version of VLCJ requires Java 11. Which... I don't know how important it is to stay Java 8 compatible, so I don't know if that's a problem or not.

That's something I've been wondering about too... I added JRE 11 to the unit tests on GitHub a while back, so I know the app works with 11, I just don't know how disruptive it would be to other users. Since GM comes with a JRE, I suppose it would only really impact the Slim / Linux versions and I'm inclined to say the Linux users out there could handle making sure they're running a compatible JRE without issue. I suppose that begs the question, if we're updating the JRE do we jump straight to 17 which is the current LTS version? At a minimum I'd like to get JRE 17 in the unit tests as well so we know if that's even an option. Even if we don't now, we'll have to eventually.

On the topic of JREs, I'm currently pulling from Adopt OpenJDK URLs, and they handed that project off to Adoptium and re-branded, so I'll need to update the GitHub actions and the README to reflect the new URLs and branding.

Edit: I added JRE 17 to the tests, and they're all passing. I haven't actually tested it yet, but that's a good sign.

[RemiHiyama]

That's something I've been wondering about too... I added JRE 11 to the unit tests on GitHub a while back, so I know the app works with 11, I just don't know how disruptive it would be to other users.

You know, I'm not sure. I think I'd subconsciously assumed that we were staying on Java 8 because there were platforms people were using it on that wouldn't support a higher version, but I don't know if that's a realistic concern.

IntelliJ seems to completely lose it if I try changing the language level, but that could just be that I'm not doing it right. (Java, if I haven't made that clear enough, is not my best language.)

[tr0gd0r]

After some searching, I thought replicating the one-time initialization code in this might be the fix for the "Xlib not initialized for threads." error. It does seem to deal with the same thing.

... But if I do that, GuideMe crashes on startup, so something is obviously wrong.

Maybe using a newer version of VLCJ that has this built in, and making CompositeVideoSurface a subclass of AWTVideoSurface would work, but I think that version of VLCJ requires Java 11. Which... I don't know how important it is to stay Java 8 compatible, so I don't know if that's a problem or not.

I've done a little bit of X11 in the past and the call to XInitThreads() needs to be the first call made to Xlib, so if it was crashing then maybe it needs to go earlier in the process, I'm not familiar with how the SWT bindings handle it.


As for the forms, I had a quick poke around and I wonder if it's due to Windows defaulting to IE, whereas Linux uses WebKit. Again, I'm not really familiar with Java or its ecosystem.