Linux Release

[GirkovArpa]

Anyone want to upload a Linux binary to the latest release?

Preferably with the folder locale and the appropriate Sciter library file included.

[papioara]

I have a working one running since yesterday with everything in it, and it has launched fine today after login. So could do it, but please tell me once how to do this.

[GirkovArpa]

Thank you! I believe it's as simple as running cargo build --release and then zipping up target/release/temps-lite.exe along with libsciter-gtk.so and the locale folder.

Then in the release here, click Edit Release, then the button labeled Attach binaries by dropping them here or selecting them. Then Update release.

[papioara]

It is as you say, but we are not quite 'over the hilltop' yet, as we say here - see my post in issue #22

[papioara]

I paste that post here in order to save everybody some clicks:

Unfortunately there are still some flaws which I only noticed at a second glance. The good news: it's up and running, but:

The autostart entry which is created in /.config/autostart has to be edited manually, since it does not work with the command entered there. It says: Exec=/HOME/USER/TEMPS-LITE-FOLDER/./temps-lite-rust. This command launches it, but although the libsciter-gtk.so file and the locale folder are also present, it launches, but does not seem to recognize them. If you modify the command to Exec=cd /HOME/USER/TEMPS-LITE-FOLDER && ./temps-lite-rust, temps-lite-rust works, but I do not know why this makes any difference, because syntaxwise the former version should be fine. I have copied the release folder from the build and placed it in different locations/places on my machine, but what I described above was always the same. I also tried both commands in a Terminal, and the results were also the same.

There are errors on launch with the second command. The first one is an old acquaintance about the rubik font, but the second one may be of interest - I do not know if it is important, because the app is running fine. Here it is:

ERROR:TIS: this://app/lang/load-translations.tis(16) : warning :'async' does not contain any 'await'

And there is the complaint about GLibc already familiar, too

[GirkovArpa]

I can get rid of the "async" and "font" warnings but the "GLibc" warnings would remain until next version of Sciter so I don't suppose it makes a difference to fix them yet.

[papioara]

Very good, but after all these warnings would be invisible anyway if you do not launch temps-lite from the Terminal, and it seems furhtermore that they do not prevent the app from working normally.

[papioara]

Hi,
I have been silent for a while, but now I am back again with a little bit of extra time to help with the project.
I have seen that during my absence there has been some evolution going on - great!
I have cloned the repository again in order to have the most recent version on my machine.
Most features work ok in Linux, but there are some annotations nevertheless:

1. The build process under Linux is not too well documented or explained. I had to tinker a bit, before I got everything right and the build could complete. Would it be a good idea to add some instructions to the Readme? I am willing to do so, if you agree.

2. I have installed the Rubik font on my system in /usr/share/fonts/truetype, where they normally would go for all users, but the error about the missing fonts persist. And there is a new error (I just paste all the errors here):

WARNING:CSS: in @font-face statement, failed to install font at (this://app/rubik.css(4))
WARNING:CSS: in @font-face statement, failed to install font at (this://app/rubik.css(9))
WARNING:CSS: in @font-face statement, failed to install font at (this://app/rubik.css(14))
ERROR:TIS: this://app/lang/load-translations.tis(16) : warning :'async' does not contain any 'await'

3. Autostart: when I tick the checkbox in the settings and click 'Apply', temps-lite creates a starter in the correct folder, but with a command which does not correspond to what I have in my release folder. The line is:

Exec=/home/user/temps-lite/target/release/./temps-lite-rust

I have to edit it manually, so it matches my folder/file structure:

Exec=bash -c 'cd /home/user/temps-lite/target/release && temps-lite'

Having done so and logging out and back in produces the desired result.
But beware: every time you change your mind and remove that checkmark, the autostart entry is removed, and if ever you want to tick the box again, you have to edit the .desktop file again.

4. You ask for uploading a binary of a running and working Linux temps-lite. Stupid question from a non-programmer: Do you mean by binary the release folder with everything necessary in it - the one which emerges after the build process? If you mean this, I can provide one, of course. Otherwise: please explain...

[GirkovArpa]

The build process under Linux is not too well documented or explained. I had to tinker a bit, before I got everything right and the build could complete. Would it be a good idea to add some instructions to the Readme? I am willing to do so, if you agree.

Yes! That would be very appreciated 😍

I have installed the Rubik font on my system in /usr/share/fonts/truetype, where they normally would go for all users, but the error about the missing fonts persist. And there is a new error (I just paste all the errors here):

I have asked the developer of Sciter here how to avoid these warnings, crossing fingers 🤞 and hoping they respond!

I recieved this response while typing this 😁 I just applied these fixes which should get rid of the warnings.

Autostart: when I tick the checkbox in the settings and click 'Apply', temps-lite creates a starter in the correct folder, but with a command which does not correspond to what I have in my release folder.

I believe @4silvertooth wrote the relevant code here:

temps-lite/app/autostart.tis

Lines 23 to 29 in 677a748

	const appPath = URL.toPath(System.home("./temps-lite-rust"));
	const data = String.$([Desktop Entry]
	Type=Application
	Version=1.0
	Name={appName}
	Comment={appName} A simple but smart weather app.
	Exec={appPath}

I am tempted to recommend replacing this:

URL.toPath(System.home("./temps-lite-rust"));

With this:

URL.toPath(System.home());

Which should theoretically (based on this documentation) return something like:

/home/user/temps-lite/target/release/

But I'm confused because you say that it should not begin with /home/user but instead /home/<your account name>? That would seem to imply the documentation is wrong about the function, but maybe I misunderstand.

Also, why do you prefix it with bash -c 'cd? Can't the program be autostarted directly, without using bash?

Forgive me, I am not familiar with Linux 🤔 And honestly, me trying to troubleshoot Linux without a Linux computer is like a blindfolded monkey 🙈 trying to hit a target 🎯 😄

Hopefully, someone else can chime in.

You ask for uploading a binary of a running and working Linux temps-lite. Stupid question from a non-programmer: Do you mean by binary the release folder with everything necessary in it - the one which emerges after the build process? If you mean this, I can provide one, of course.

Not a stupid question 😄 Yes, that is exactly what I was hoping for! It would be great if we could have a Linux release so other Linux users don't have to build it themselves 🚀

[4silvertooth]

I've tested that on Mint Linux, I suppose on different flavours of Linux it might be a bit different to launch the aplication, System.home() should be the exact path where compiled bin is, also my code assumes the binary file name to be temps-lite-rust has that changed to temps-lite after the merge?

Edit: @papioara can you confirm Exec=/home/falter/temps-lite/target/release/./temps-lite working?

[GirkovArpa]

Ah yes, when I copied your code from the rust respository to this one, I did not think to update it to match the current name temps-lite. But still, there remains an unexplained discrepancy between what path it's supposed to return and what @papioara records it as returning. Assuming this is because they did not intend to publish their Linux username, I have taken the liberty to edit their post myself.

[papioara]

Hello everybody,
That's a lot to reply to here, but I will try to be as short as possible:
@4silvertooth : I am on Linux Mint 20, and
/home/falter/temps-lite/target/release/./temps-lite
does work on my machine, yes. I did not test it on the .desktop file in the autostart folder, but ran it without the Exec= in a Terminal, and so it is a safe bet that it will also work when you edit the .desktop file accordingly.
@GirkovArpa : Normally under Linux, you can launch a program by either just typing its name in Terminal or by typing the full path. In the case of temps-lite, the former only works if you are in the folder with the executable, i.e. /release, or, if you issue the command from a different location, you have to split up into two commands: 1. Go to the directory with the executable, and when you are done, (&&) 2. launch temps-lite, which is
cd /home/<yourusername>/temps-lite/target/release && temps-lite
If I evoke it with just the full pathname like /home//temps-lite/target/release/temps-lite, it does start up, but does not recognize the languages strangely, and you cannot choose one in the settings either. I do not understand why it happens in that case and why it does not in the former one. Maybe it has something to do with the shell and not with temps-lite - it is beyond my knowledge at this point.

[papioara]

Ah yes, when I copied your code from the rust respository to this one, I did not think to update it to match the current name temps-lite. But still, there remains an unexplained discrepancy between what path it's supposed to return and what @papioara records it as returning. Assuming this is because they did not intend to publish their Linux username, I have taken the liberty to edit their post myself.

It's what you suspected: Instead of my own user name I inserted a generic name, that's all. Maybe I should have done so in a more explicit way...

[papioara]

Build under Linux:
If I write my instructions: where should they go? Into the Readme or somewhere else? What would you think?

Errors
If I have time these days, I will try and replace the code line in autostart.tis and see what this does and report. I will also clone the repository again, make another build and see if there still are error messages.

Also, why do you prefix it with bash -c 'cd? Can't the program be autostarted directly, without using bash?

It is only "bash -c" - " 'cd" is already a part of the following command in single quotes (cd is "change directory"). It does not open a terminal, but just has bash execute the command in the background. If you omit it in the .desktop file, temps-lite won't start. If you open a Terminal and just type in (assuming you are not in the release folder already)
cd /home/<username>/temps-lite/target/release && temps-lite ,
then, of course, you do not need "bash -c" and the single quotes.

[GirkovArpa]

If I evoke it with just the full pathname like /home//temps-lite/target/release/temps-lite, it does start up, but does not recognize the languages strangely

I believe that's because the executable thinks it's located in whatever folder the command was run from. In this case I imagine it's home (or maybe the folder containing the bash executable), so it's looking for languages in <bash folder>/locale.

I will have to find a way to fix this. Maybe allow a command line parameter to tell it where it's located.

[GirkovArpa]

@papioara I believe I fixed the bug where it was not loading languages when started via bash outside of the executable's own folder.

[papioara]

Hi,
Today I have found the time to test the latest 'state of the art'. There were unexpected results, though, and I have no idea what goes on in the background. I almost start believing in miracles again...
I have begun with a sketch for a build instruction for Linux which I wanted to write first of all, but I have some questions to you, before I can finalize the text:

1. I do not have a link to libsciter-gtk.so and to packfolder, or have I missed something? It would be a good idea to insert them into the text. On my system I have sciter-sdk, so I can always copy them over in case I need them.
2. Is it a bad idea to have two temps-lite folders on your system, although they are in different locations like /home/myusername/temps-lite/ and /home/myusername/Downloads/temps-lite/? I put this question for a special reason, as you will see in a moment.

I cloned the repository and copied over packfolder and libsciter-gtk.so from my already existing temps-lite folder in my home directory with the already executable packfolder (was a bit lazy). Then I built temps-lite, moved /locale to /target/release and libsciter-gtk.so also.
Then I did cd /target/release/ and temps-lite, and it launched. I pasted the API key, and then it worked. So far, so good...

Of course I wanted to test, if your bugfix concerning smooth launches from wherever you are on your system, works. I went to my home directory and launched temps-lite with the full path name like so: /home/myusername/Downloads/temps-lite/target/release/temps-lite. And lo and behold: it launched flawlessly, but not with the New York weather like when launched from within its folder, but with the weather in my place.
I really have no explanation for this behaviour, or do you? Should I have taken a fresh packfolder and libsciter-gtk.so file rather? Do they store information about locations? I have trashed my temps-lite folder from my home directory, but to no avail. It insists on displaying the weather from where I live, although I have not entered the coordinates - it says New York in the settings when launched from within the Downloads folder, but my town when launched with the full path. But where the heck does it get that information from? The other temps-lite folder is in the trash, so the system does not use it, and logging out and back in does not change anything, too.
Last thing: temps-lite still calls itself temps-lite-rust in the autostart entry.

Phew, that was all for tonight, but not boring at least...

[papioara]

Did another test using fresh packfolder and libsciter-gtk.so files, but with the same results as before. Something's tracking me... Scary! And the other temps-lite folder is still in the trash.

[GirkovArpa]

I need some time to respond to the rest of your post, but it seemed appropriate to try to quell your concerns right now:

The last location you entered (and your API key) is saved in a file named database.bin, in the same folder as the executable. I predict that once you locate and delete this file, it will default to New York again.

[4silvertooth]

Last time I checked the database.bin file was at the parent directory of where the executable is.

[papioara]

Thanks for your replies and the information about database.bin. I did some tests, but they raise another question: when called from outside the executable folder with (in my case) ~/Downloads/target/release/temps-lite: can temps-lite draw on another database.bin file somewhere on your system instead? To me it seems to be like that, because, when you launch it like this (database.bin deleted beforehand) and watch what happens in the executable folder, you can see that no new database.bin folder is being created.
Whereas, when you launch it from inside the folder with the executable, and there is no database.bin in it, it immediately creates one.

I scanned my home folder for stray database.bin files and found a single one in my home folder (no idea how it got there) and two others in the Windows version (never used, though) and one in a sciter-notes folder with an additional temps-lite in it. I trashed everything, and now indeed, even if launched from 'somewhere' outside of its executable folder, it is in New York again.
But even if I enter the API key and click 'Apply', it does not create a database.bin file in its executable folder.
But - update to what I described above - it creates one in my home folder instead. That's the one it uses when launched from outside. When fired up from 'inside', it creates a fresh database.bin file and does not know about the API key.
Now we know and can explain the different behaviours, but: is this desirable?

[GirkovArpa]

Thanks for identifying this issue, fixed here! Basically when I corrected the path for the locale folder, I forgot to also correct the path for the database file, to ensure it is always created in the executable's folder, regardless of from where the command prompt was opened which initiated the program.

[GirkovArpa]

@papioara

I do not have a link to libsciter-gtk.so and to packfolder, or have I missed something? It would be a good idea to insert them into the text. On my system I have sciter-sdk, so I can always copy them over in case I need them.

I have linked to a specific version of sciter-sdk here in the readme. The included bin.* folders contain the sciter library and packfolder program, but I agree that direct links for all of them for every OS should be listed.

Is it a bad idea to have two temps-lite folders on your system, although they are in different locations like /home/myusername/temps-lite/ and /home/myusername/Downloads/temps-lite/? I put this question for a special reason, as you will see in a moment.

I imagine this is related to the previously-discussed issue of locale and database pathnames, which hopefully have been resolved. Basically, there should no longer be any issue if for whatever reason one wants to have two or more temps-lite folders on the same computer.

[papioara]

Great, brilliant! I will run a test later this evening and report.

[papioara]

Coming back to a ready-to-run downloadable Linux version without even the need to build it beforehand: would it make sense if I upload a folder with the contents of the release folder? To me it seems that there is everything in it which is needed by temps-lite, or am I wrong? Of course, from time to time, I would have to build a new version when there are changes - not an awful lot of work. This would be something for the more lazy users who do not want to or cannot build it themselves, let alone get an API key from openweather... I know a couple of people who are exactly like that. If it's not ready in one or two clicks, they are not interested any more, although in the Windows and Apple worlds, there are more of them than in the Linux world. Linux users often are more open to tinkering a little and to explore things a little more in-depth. You also are closer to the command line, and it is less fraught with all kinds of prejudice among them.
I am curious what you think about my suggestion...

[GirkovArpa]

I see no problem with including your database.bin file in the release, after changing the location to somewhere random like New York. The worse that could happen is someone abuses the API key and gets your openweathermap account suspended.

would it make sense if I upload a folder with the contents of the release folder?

I am not sure what you mean. To be clear, I am already asking for a .zip folder containing these things to be uploaded to the Releases:

• temps-lite executable
• locale folder
• sciter library file
• database.bin file (after choosing a random location with your API key, and clicking Apply, and closing the program) (optional, for the less technically-inclined users)

[papioara]

Sorry, I was not clear enough...
What I mean is: After cloning the repository, you have a temps-lite folder with everything necessary for building under Linux except for the packfolder file and the libsciter-gtk.so one which you have to add manually.

After running cargo build --release, among other stuff, you have a new folder 'target' with a folder 'release' in it. The latter contains the executable - under Linux it is just called temps-lite without the exe.

As for the API key one could also open another account on openweather under a different email, so I cannot run into trouble if someone should abuse that account.

So I guess, it's pretty much like what you are asking for, or not? Of course that folder does not have to keep the name 'release'l After having tested the latest version, I could upload a .zip of it.

[papioara]

Sorry, my description of the temps-lite folder contents before and after the build are somewhat cursory and incomplete - I just tried to mention the most essential points...

[GirkovArpa]

Well, on my Windows computer the release folder contains almost 100 megabytes of stuff besides the executable. That's why I was confused by this:

would it make sense if I upload a folder with the contents of the release folder?

It sounded like you wanted to upload 100 megabytes? 😄 I am still not sure to be honest, but you sound like you know what you are doing, so all good. Apologies for my lack of understanding.

[papioara]

I have taken a closer look at the release folder and send you a screenshot of its contents after the build. Its size is 49.9 MiB. There are a couple of files and folders which do not seem to be essential for the function, and two folders are empty. I will move out what I guess is unnecessary and see if temps-lite still works and report.

[GirkovArpa]

Ahh, now I understand the source of my confusion. When I build temps-lite, the executable is produced in the release folder, which itself produces database.bin when run:

But everything else is in the top level folder (database.bin is from before the last patch I believe):

Sciter DLL is in my PATH environment variable I think.

[papioara]

Did the test on a copy of the release folder, and it's running (New York, no API key) with just this in it (22.2 MiB in size):

[papioara]

And it also runs when being launched from somewhere else...

Looks like the Windows build process goes off differently. I always have to add packfolder and libsciter-gtk.so manually, before I start the build process. Otherwise there will be complaints about them missing.

[GirkovArpa]

That is my fault. I have both packfolder and sciter.dll in my PATH environment variables so I don't need to copy and paste them into every new sciter project. I should update the readme to reflect that.

Actually, I don't need sciter.dll to build it, only to run it.

[papioara]

I have just cloned the repository again, built temps-lite and tested it. Good news: the bug is gone - you can call it from wherever you want, and it does not drop a database.bin like a bird everywhere. Wonderful!
But you still have to fix the wrong autostart entry. It says until now:

/home/myusername/Downloads/temps-lite/target/release/./temps-lite-rust

It should be, however:

/home/myusername/Downloads/temps-lite/target/release/./temps-lite

Would that be difficult? Otherwise you need to edit the autostart entry manually, which would be annoying, because you might have to do it again, should you uncheck the 'Start at login' box and tick it again.

[4silvertooth]

Should be fixed by the last commit.

[papioara]

I just checked and can confirm... Wonderful! Thank you!

[papioara]

It looks to me now that we have eliminated all the evident bugs which we have noticed - at least I cannot think of one at the moment. Please tell me, if I am wrong.
This raises two questions:
Should I zip up a temps-lite folder with everything necessary (and stripped of the unnecessary stuff) for running temps-lite to Releases as a 'ready-to-run' Linux version?
And would it still make sense to publish build instructions here in the Readme for the ones willing to build temps-lite themselves?

For completeness' sake: when I build temps-lite myself, the build process runs through completely with a usable result, but there is always a warning at the end, and I do not know what it means and if this is of any importance. See the screenshot from the build log in Terminal:

[GirkovArpa]

Should I zip up a temps-lite folder with everything necessary (and stripped of the unnecessary stuff) for running temps-lite to Releases as a 'ready-to-run' Linux version?
And would it still make sense to publish build instructions here in the Readme for the ones willing to build temps-lite themselves?

That sounds perfect, I would appreciate that very much (as I'm sure future Linux users will too!).

The warning isn't important, but removing the underscored line #[macro_use] extern crate sciter; should make it go away without any side-effects.