Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » [Proposal] The maintainer and the future of TURTLE package
[Proposal] The maintainer and the future of TURTLE package [message #54415] Tue, 14 July 2020 18:55 Go to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hi,

I was wondering if TURTLE is actively maintained. I value this package, and I find it useful for my purposes.

Does it have a maintainer? IF not, I'd be happy to step up to be its maintainer.

My initial plan is to move it to VirtualGUi.

I already have an experimental version of it based it on VirtualGui.

However, VirtualGui seems to define DoPaint and SyncCaret methods, And they are not overrideable. Is there any other way, in which I can ge text cursor (caret) and mouse cursor information to send over the wire protocol?

Best regards,
Oblivion


[Updated on: Tue, 14 July 2020 18:56]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #54469 is a reply to message #54415] Tue, 28 July 2020 17:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Excellent! You should now have write rights in the svn...

Mirek
Re: [Proposal] The maintainer and the future of TURTLE package [message #54476 is a reply to message #54469] Wed, 29 July 2020 11:00 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Thank you!

My question remains though:

 VirtualGui seems to define DoPaint and SyncCaret methods, And they are not overrideable. Is there any other way, in which I can ge text cursor (caret) and mouse cursor information to send over the wire protocol?


This can be worked around by preprocessor commands (for example), but that would be ugly, and an inelegant way to do so.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #54479 is a reply to message #54476] Wed, 29 July 2020 11:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Well, there seems to be SystemCursor bool variable that makes VirtualGui use SetMouseCursor method. I think we can have SystemCaret / SetCaret as well. That would solve the problem, correct?
Re: [Proposal] The maintainer and the future of TURTLE package [message #54490 is a reply to message #54479] Thu, 30 July 2020 20:51 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

Quote:
. I think we can have SystemCaret / SetCaret as well. That would solve the problem, correct?


Yeah, I think this should be the way to send the required caret information.
SetCaret method along with a static SystemCaret boolean would be nice to have.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #54491 is a reply to message #54490] Fri, 31 July 2020 10:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Implemented (not quite tested SetCaret, but should work), I have also replaced SystemCursor with GetOptions method....
Re: [Proposal] The maintainer and the future of TURTLE package [message #54492 is a reply to message #54491] Fri, 31 July 2020 16:05 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
OK, thanks!

Hopefully I'll be able to finish the port to VirtualGui next week.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #54652 is a reply to message #54491] Wed, 26 August 2020 17:12 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

I have ancountered a curious problem while testing the Turtle/VirtualGui port.
(Note: This is tested on a Linux machine with default LANG=UTF-8 encoding. and this problem affects both old and new Turtle packages as the VirtualGui package shares the same clipboard code.)

The problem is GetWString and GetString do not work properly if called on a clipboard text.

TextCtrl derived classes are affected by this, as they use the same mechanism.

Sreenshot with explanation:

index.php?t=getfile&id=6168&private=0

Now, the culprit seems to be the VirtualGui clipboard String/WString conversion code (VirtualGui/Clip.cpp, 64-86):

String GetString(PasteClip& clip)
{
	GuiLock __;
	if(clip.Accept("wtext")) {
		String s = ~clip;
		return WString((const wchar *)~s, wstrlen((const wchar *)~s)).ToString(); / << Adds random chars. Why is this though? It is already a string. For charset conversion?

            //  return ToUtf16(s).ToString();    // Seems to work fine...
            //  return s.ToWString().ToString(); // Seems to work fine...
 
	}
	if(clip.IsAvailable("text"))
		return ~clip;
	return Null;
}

WString GetWString(PasteClip& clip)
{
	GuiLock __;
	if(clip.Accept("wtext")) {
		String s = ~clip;
		return WString((const wchar *)~s, wstrlen((const wchar *)~s)); // Adds random chars...

            //  return ToUtf16(s);    // Seems to work fine...
            //  return s.ToWString(); // Seems to work fine...

	}
	if(clip.IsAvailable("text"))
		return (~clip).ToWString();
	return Null;
}



Best regards,
Oblivion


[Updated on: Wed, 26 August 2020 17:18]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #54653 is a reply to message #54652] Thu, 27 August 2020 10:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
The code is copied from Win32 where there can be some data after double zero terminator. I think problem here is that there is just single-zero terminator...

I guess your fix is fine.

Re: [Proposal] The maintainer and the future of TURTLE package [message #54657 is a reply to message #54653] Fri, 28 August 2020 14:59 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

Thank you for your help and patience.

Before I finalize the Turtle port, I need a clarification on one point:

The original Turtle package uses "all-static" approach.

1) Is it OK to keep the VirtualGui-based Turtle all-static too (It works well...), or should I remove the static stuff and make them instance members?
2) Accordingly, can I instantiate more than one VirtualGui/TurtleGui in the same process. Does U++ properly support this?
if so, this might prove useful for later iterations of the Turtle package.

Best regards,
Oblivion


[Updated on: Fri, 28 August 2020 15:00]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #54658 is a reply to message #54657] Fri, 28 August 2020 15:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Oblivion wrote on Fri, 28 August 2020 14:59
Hello Mirek,

Thank you for your help and patience.

Before I finalize the Turtle port, I need a clarification on one point:

The original Turtle package uses "all-static" approach.

1) Is it OK to keep the VirtualGui-based Turtle all-static too (It works well...), or should I remove the static stuff and make them instance members?
2) Accordingly, can I instantiate more than one VirtualGui/TurtleGui in the same process. Does U++ properly support this?
if so, this might prove useful for later iterations of the Turtle package.

Best regards,
Oblivion


Well, it is still using CtrlCore and CtrlCore has a lot of global variables, so it does not really make sense to bother making Turtle support more than single session per process....
Re: [Proposal] The maintainer and the future of TURTLE package [message #54659 is a reply to message #54658] Fri, 28 August 2020 16:57 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Quote:

Well, it is still using CtrlCore and CtrlCore has a lot of global variables, so it does not really make sense to bother making Turtle support more than single session per process....


OK, thanks for the clarification.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #54681 is a reply to message #54658] Mon, 31 August 2020 21:34 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

The Turtle package is ported to VirtualGui, and it is now in the trunk. This was the first phase. The next is to improve the server.

However, there are some small issues that might need fixing in the U++ Core, before 2020.2.

1) LaunchWebBrowser() is not working with Turtle ATM, as it uses a compile time switch (TURTLE). I could have added support for it but it had to use TURTLE switch and IMO, LaunchWebBrowser should be handled globally for VirtualGui, not just for Turtle. Otther possible/future virtualization software might want to utilize it too. (Making a callback-based version of LaunchWebBrowser for VirtualGui platform, maybe?)

2) Accordingly the TURTLE switches and Turtle specific functionality in the uppsrc seems obsolete now. VIRTUALGUI switches are sufficient. We'll already have feature-parity with the previous version of Turtle package once the LaunchWebBrowser issue is solved.

3) As it happens, I saw a Ctrl::IsEndSession() method defined in CtrlCore (always returns false). I think this method is a better way to check for session termination, at least in VirtualGui/Turtle. So I was wondering if it is possible to define it in VirtualGui/Ctrl, and let it return the status of fbEndSession flag? The reason why I ask is, it can be used to break loops that lie outside the scope of Ctrl::ProcessEvent(), in case of session termination. (i.e. Turtle's SyncClient() method is one of them...)

Best regards,
Oblivion


[Updated on: Mon, 31 August 2020 22:03]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #55935 is a reply to message #54681] Tue, 05 January 2021 11:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
While trying to move Turtle to UppHub, I have noticed it does not work Smile (I will gladly provide you commit rights there as soon as I find out your github username...)

The reason seems to be that after uploading html, we try to establish WebSocket connection over the same port. Unfortunately, at the same time browser tries to fetch favicon, which gets cought by WebSocket and connection is terminated because that is not the correct websocket request.

Have you noticed this issue?

Trying to remedy that by moving websocket communication to another port...

Mirek
Re: [Proposal] The maintainer and the future of TURTLE package [message #55937 is a reply to message #55935] Tue, 05 January 2021 11:39 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

Quote:
While trying to move Turtle to UppHub, I have noticed it does not work Smile (I will gladly provide you commit rights there as soon as I find out your github username...)

The reason seems to be that after uploading html, we try to establish WebSocket connection over the same port. Unfortunately, at the same time browser tries to fetch favicon, which gets cought by WebSocket and connection is terminated because that is not the correct websocket request.

Have you noticed this issue?

Trying to remedy that by moving websocket communication to another port...


Thanks for reporting this. I haven't encountered this issue. I'll look into it tonight but I am already working on a simple login mechanism, and the Turtle server side is going to change soon.
Stil, IMO it would be better to use a randomized port number for websocket in ephemeral port range or > 32K.

Speaking of login: the mainstream browsers do not allow/deprecated unsecure websocket connections unless the host is localhost or explicitly allowd. In any case using unsecure layer is bad practice. And the K.I.S.S way of implementing a login mechanism is to use the secure web socket layer (wss/TLS). (I'll propose the plan next week)

But at the moment WebSocket class seems to allow server side security via its older interface. Is there a way or plan to fix that or can I safely use the older API?


my github username: ismail-yilmaz


Best regards,
Oblivion




[Updated on: Tue, 05 January 2021 12:15]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #55940 is a reply to message #55937] Tue, 05 January 2021 16:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Well, continue here please:

https://github.com/mirek-fidler/Turtle

Mirek
Re: [Proposal] The maintainer and the future of TURTLE package [message #55941 is a reply to message #55940] Tue, 05 January 2021 16:48 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1139
Registered: December 2006
Senior Contributor
Am I missing something?

./umk reference WebWord CLANG -bus
In file included from /home/buildbot/worker/l-upp/build/reference/WebWord/main.cpp:1:
/home/buildbot/worker/l-upp/build/reference/WebWord/WebWord.h:5:10: fatal error: 'Turtle/Turtle.h' file not found
#include <Turtle/Turtle.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #55942 is a reply to message #55941] Tue, 05 January 2021 16:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 05 January 2021 16:48
Am I missing something?

./umk reference WebWord CLANG -bus
In file included from /home/buildbot/worker/l-upp/build/reference/WebWord/main.cpp:1:
/home/buildbot/worker/l-upp/build/reference/WebWord/WebWord.h:5:10: fatal error: 'Turtle/Turtle.h' file not found
#include <Turtle/Turtle.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.


It is not there anymore... Actually, nor is WebWord.

Mirek
Re: [Proposal] The maintainer and the future of TURTLE package [message #55945 is a reply to message #55942] Tue, 05 January 2021 17:56 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

There was also a rudimentary WebHelloWorld example left in the reference section. I have moved it to UppHub/Turtle/Examples directory.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #55946 is a reply to message #55941] Tue, 05 January 2021 18:00 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13040
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 05 January 2021 16:48
Am I missing something?

./umk reference WebWord CLANG -bus
In file included from /home/buildbot/worker/l-upp/build/reference/WebWord/main.cpp:1:
/home/buildbot/worker/l-upp/build/reference/WebWord/WebWord.h:5:10: fatal error: 'Turtle/Turtle.h' file not found
#include <Turtle/Turtle.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.


Speaking of which: It would be great if your automated building infrastructure started scanning UppHub. Do you think it would be possible?
Previous Topic: Want to use CLANG with MSBT64 toolchain
Next Topic: Technology lab vs External resources
Goto Forum:
  


Current Time: Wed Jan 20 05:49:56 CET 2021

Total time taken to generate the page: 0.02172 seconds