|
|
Home » Developing U++ » U++ Developers corner » [Proposal] The maintainer and the future of TURTLE package
|
|
|
|
|
|
|
Re: [Proposal] The maintainer and the future of TURTLE package [message #54652 is a reply to message #54491] |
Wed, 26 August 2020 17:12 |
Oblivion
Messages: 1112 Registered: August 2007
|
Senior 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:
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
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Wed, 26 August 2020 17:18] 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 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Oblivion wrote on Fri, 28 August 2020 14:59Hello 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 #54681 is a reply to message #54658] |
Mon, 31 August 2020 21:34 |
Oblivion
Messages: 1112 Registered: August 2007
|
Senior 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
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Mon, 31 August 2020 22:03] Report message to a moderator
|
|
|
|
Re: [Proposal] The maintainer and the future of TURTLE package [message #55937 is a reply to message #55935] |
Tue, 05 January 2021 11:39 |
Oblivion
Messages: 1112 Registered: August 2007
|
Senior 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
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Tue, 05 January 2021 12:15] Report message to a moderator
|
|
|
|
Re: [Proposal] The maintainer and the future of TURTLE package [message #55941 is a reply to message #55940] |
Tue, 05 January 2021 16:48 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate 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
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Sep 20 22:41:24 CEST 2024
Total time taken to generate the page: 0.03825 seconds
|
|
|