QLineEdits in a QGroupBox(with the checkBox) on the "Special Options" tab. If the checkBox is checked on "save"-ing the dialogue then the changes are saved into the main QSettings and re-used for future profile loads - :bulb: but there will then need to be a reset button as well to reset to the compiled in defaults that we have currently.
@ SlySven you do not need to recompile Mudlet to get updated Lua code in, we removed that years ago.
You do if the hard-coded paths that are used to load in the LuaCore.lua i.e. in (void) TLuaInterpreter::loadGlobal() and the other run-time modules in the bottom of (void) TLuaInterpreter::initLuaGlobals() are not working on your platform... - this is to make it easier to debug and fix things in those areas.
Hey, Reinos de Leyenda switched over from their MudletRL fork to the official Mudlet: https://www.reinosdeleyenda.es/blog/nueva-version-de-mudletrl
Thanks @SlySven for porting their changes :)
@ SlySven hey how come you undid my windows compiling changes
I'd found they were out of date and some tweaking/explaining was necessary for me to get things to compile; I suppose it would be possible to copy the active lines and re-paste them below as two blocks of commands to paste and run... though as I see that libzip has been updated to 1.4.0 perhaps that bug in 1.3.1 and 1.3.2 has been fixed as I anticipate so it can be just one block.
libzip have retired (as of 2017/12/08) using the autotools build system for libzip as of 1.4.0 and there I was hoping they'd have fixed an issue with using that system on 1.3.1 and 1.3.2 - guess I'll have to see if I can rejig the Windows build instructions to use CMake for that now...
Humm, AppVeyor keeps bugging out - at least for #1539 - the log is ending by saying:
[00:06:58] ==== compiling and installing zziplib ====
[00:06:58] ---- Downloading ----
[00:07:00] ---- Extracting source distribution ----
[00:07:02] ---- changing configure script ----
[00:07:02] ---- Running configure ----
[00:07:41] ---- Running make ----
[00:08:17] ---- Running make install ----
[00:08:25] ==== zziplib compiled and installed ====
[00:08:25] ==== compiling and installing luarocks ====
[00:08:25] ---- Downloading ----
[00:08:26] Exception calling "DownloadFile" with "2" argument(s): "The request was
[00:08:26] aborted: Could not create SSL/TLS secure channel."
[00:08:26] At C:\projects\mudlet\CI\appveyor.install.ps1:75 char:3
[00:08:26] + (New-Object System.Net.WebClient).DownloadFile($url, "$workingBaseD ...
[00:08:26] +~~~~~~~~~~~~~~~
[00:08:26] + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordE
[00:08:26] xception
[00:08:26] + FullyQualifiedErrorId : WebException
[00:08:26]
[00:08:26] Command exited with code 1
[00:08:26] cd C:\src
[00:08:26] bash -c "curl --upload-file ./verbose_output.log https://transfer.sh/verbose_output.log"
[00:08:26] % Total % Received % Xferd Average Speed Time Time Time Current
[00:08:26] Dload Upload Total Spent Left Speed
[00:08:26]
[00:08:27] 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
[00:08:28] 13 699k 0 0 13 98304 0 98304 0:00:07 0:00:01 0:00:06 93980
[00:08:29] 96 699k 0 0 96 672k 0 336k 0:00:02 0:00:02 --:--:-- 328k
[00:08:29] 100 699k 100 44 100 699k 22 349k 0:00:02 0:00:02 --:--:-- 248k
https://transfer.sh/bNZYM/verbose_output.log
development branch - and there should be no difference between how the code would be in the test for the PR (which ran fine on AppVeyor yesterday) and the build now for the updated branch so I think there is an AppVayor system problem although it's status page is not currently showing any issues. :hankey:
Interesting - I have been invited to participate in an academic research project (by a Fabio Thomaz Molinar at Liverpool University, UK) about the effectiveness of Gitter as a team communications tool for F.O.S.S. projects. I was just going to comment about how we have jumped ship to Discord but actually I think there is still a place for Gitter - because the traffic here is much more development orientated and there is (IMHO) good links to Github - although that is not really THAT surprising.
Anyhow - I am not going to put the lights off here just yet...!
QChar to represent them - I think I have the display and selection of text by mouse sorted but I need to do some more checking...
@tiger92665 yes, in version 3.10 (coming soon). You can test it:
https://ci.appveyor.com/api/buildjobs/8fvbti4cdh1hj8fc/artifacts/src%2Fmudlet.zip (windows)
https://transfer.sh/xj4ka/Mudlet-3.9.0-testing-ae3b1e8-linux-x64.AppImage.tar (linux)
https://transfer.sh/kfdqO/Mudlet-3.9.0-testing-ae3b1e8.dmg (macOS)
I thought I already had got the support for GB18030 and GBK (a sucessor to GB2312) MUD Server encoding into Mudlet (in Mudlet/Mudlet#1553 , although there is an issue with the characters that the Unicode organisation says have an ambiguous width (with a recent change they are assumed to be wide by default if the encoding is set to either of those but narrow otherwise - but they can be force to either manually if necessary).
The code to handle selection and highlighting for non ASCII characters by lua scripts or by trigger matching is still being worked on and I am not a 100% certain that it is fully functional.
The GUI is fixed in English at the moment but work had already started to translate it - we are looking for volunteers who are bilingual in English and another language - and we do need some who speak languages of the Mid and Far East parts of the World - if you feel you can contribute I feel sure we would welcome your input...
