Closed rizonesoft closed 6 years ago
That's quite a nice feature.
A few ideas:
well, an rss/atom feed would be pretty nice and the link on the downloadpage of n3 with a small 16x16px Rss icon and "Versions Newsfeed" by changing of the Downloadpage.. and maybe would also very good if the full nummer of the version be posted :) and not only the BuildNo. .. to have a possible for include it in QuiteRss or an other newsreader :)
best regards Blacky
My suggestion: a separate executable (e.g. NP3Admin.exe) as a side-by-side deployment like "minipath.exe" Tasks to operate for this tool:
The reason for my suggestion:
Keep Notepad3 slim and fast: Worth to take a look on: http://www.flos-freeware.ch/doc/notepad2-FAQs.html especially: http://www.flos-freeware.ch/doc/notepad2-FAQs.html#q2
... some of the features, Flo refused, are already implemented (thanx to Notepad2-mod base - blowing up NP2 a little bit ;-)):
2017-10-15 22:40 GMT+02:00 blackcrack notifications@github.com:
well, an rss/atom feed would be pretty nice and the link on the downloadpage of n3 with a small 16x16px Rss icon and "Versions Newsfeed" by chaning of the Downloadpage.. and maby would also very good if the full nummer of the version be posted :) and not only the BuildNo. .. to have a possible for include it in QuiteRss or an other newsreader :)
best regards Blacky
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rizonesoft/Notepad3/issues/125#issuecomment-336739913, or mute the thread https://github.com/notifications/unsubscribe-auth/AIZfzj91LQQC7QLAmQ8fw0Sen5lqhRnjks5ssm2jgaJpZM4P512C .
@RaiKoHoff You're right. π I was also thinking of a GUI for the ini file. I laready created an update notification system for my other software using AutoIt? Implementing a Windows Notepad Replacer and GUI for the ini should not be to hard. Also, what about a theme installer?
NP3Admin should be a seperate installation for advanced users? Development time should be much less if I create it in AutoIt.
... that sounds to be a good plan :+1: Using AutoIt for this will definitely speed up development and is a perfect separation of concerns. Having an separate installation for NP3Admin with auto detection of NP3's installation path makes sense too. I personally use NP3 in a highly flexible and portable package (Dropbox,USB-Stick,Work-PC,Home-PC, Friends-PCs ...) - it will be perfect, if NP3Admin will support this (at least for UpdateChecks, notepad replacement and file name ext. association does not make sense in a portable environment. The idea of configuring (certain aspects of) NP3's .ini-file (especially [Settings2]) is very smart :+1: , clearly also usable in a portable environment. Please keep in mind NP3's possibility of redirecting .ini-file reading (see np3portableapps .ini: section [Notepad3] Notepad3.ini=%NOTEPAD3_PORTABLE_SETTINGS%\Notepad3.ini)
the NP3Admin.exe could be maybe NewversAdmin.exe for extra users maybe directly a own program for notification all Programms, if this want anybody, well should he install this NewversAdmin.exe from the whole programs from @rizonesoft
an addon updater make a file more in the folder of N3 :\
i prefer a rss-feed, because, i read at all ever any morning what i have on my rssreader .. and i don't like a own notify program for any lil program's what i install.. but if anyone want this.. well, should he install..
but i take every mornin' my rss.. and i guess, many Peoples who collecting programs make the same and use the newsreaders .., add the program link if he like it from the homepage and if there a new version ..
best regards blacky
not a bad idea... but as an advanced user/etc, update checks including commit logs are a daily activity for me.. ;) lol :D :D So I update any time I find a new build release or betas out.. except for critical programs like Firefox, no betas except for extensions...
If you do write a separate NP3admin exe I suggest a separate ini file too so the main one does not get cluttered...
So its agreed? no update function. I will start working on Notepad3 Admin in a few weeks. Things are hectic busy in bay day job.
@rizonesoft :
Proposal: Adding a Menu entry: " ?
(Help) -> Check for Updates
", which opens a web-page in the browser with a request:
e.g.: https://www.rizonesoft.com/notepad3/updates.html?version=__current__version__
.
Based on __current__version__
, the website can show "Up to date" or "New Version available" with download link.
What do you think about?
Sounds good. I can work on the website part of it tomorrow and update you on the progress. Thank you for the proposal.
@RaiKoHoff FIY: I've saw the "Check for Updates" in beta build: 3.18.202.865 I'm thinking about a little more elaborated check as for eg: "FreeFileSync" A picture says more than a description: :wink:
@hpwamr : nice idea, I'll put it on the ToDo Backlog :smile:
@RaiKoHoff Because of the way WordPress works, It makes it difficult to efficiently pass URL parameters, but I found a workaround. Please test the following URLs:
https://www.rizonesoft.com/downloads/notepad3/update/?version=3.18.131.861 https://www.rizonesoft.com/downloads/notepad3/update/?version=3.18.131.862 https://www.rizonesoft.com/downloads/notepad3/update/
Let me know what you think. If this solution is not acceptable, I can work on another one.
@rizonesoft : Looks good, at a first glance :+1: It is appreciated to have all the update information on that website. On clicking the "Check for Updates" entry, I am mainly interested in the information "Update available: YES or NO" - so it would be better to have an eye-catcher on the dedicated information (higher/bolder font and/or stronger color - less integrated in text flow, a little bit more
[x] distinct
Just a suggestion :smiley: .
Passing URL parameters into a website, build by framework, is a candidate for security breaches, I can only imagine that this is protected very well with some impediments ... :grimacing:
Despite of this, I have a (minor prioritized) suggestion:
@RaiKoHoff Thank you for suggestions and I will take a look at making the version numbers and etc. more prominent.
I'm using a WordPress plugin called URL Param. It is secure and easy to configure. However there are some limitations for example;
The only conditions I have to work with is:
My explanation is not the best, but you can read about it here: https://wordpress.org/plugins/url-params/
Any suggestions would be appreciated.
I'm glad this feature is being reexamined. Particularly if it has the ability to check both the release and beta channels.
The current solution is that the data gathering and logic occurs at the web server. I'm wondering whether it might be better to do that at the client instead, i.e.:
Benefits:
Drawbacks:
Other Considerations:
Regardless of the method used, it's probably good practice to let users know what data is going to be supplied/gathered as part of this process (e.g. IP address, current Notepad3 version). A place for this might be in the EULA at install time.
@craigo- Agreed. With all my other software, I found that it is much more efficient for the client side to handle the version compare. The Notepad3 installer uses the same method to check for updates. Lets see what everybody else has to say about the idea.
I realise my suggestion would mean adding some form of web fetching capability into Notepad3... (added this to my comment above as a potential drawback).
One question here: does Notepad3 "understand" whether it is a beta version or a released one, or does it internally only store a version number?
One problem with the first approach (if that gets selected in the end), i.βe. the check on server side, seems to be that only the submitted version number could be checked (matches a fixed value or not resp. is empty). In this case maybe a second parameter could be transferred which handles the "client is a beta version" flag and allows further logic for the information shown to the user.
It may still not be possible to differentiate the casesβ¦
but at least an "Attention: you're using a beta version!" could be displayed prominently.
I agree on Benefits and Drawbacks of having a solution where the web communication is on client side.
On the other hand, I like to have a Power-Tool, where I am sure, that it does no communication with the web. It does not matter, that it will do any communications only on user request. I like the knowledge of: "there is no mechanism build in, which would be able to communicate with the web in background" - No I am not security paranoid π¬.
So the solution to delegate the check for updates to the web-browser is good enough - a loose coupling is a good programming paradigm. I hate tools, which start-up taking a long breath to check for updates and ending up, after running in timeout, with a message that says that they are not allowed to communicate π². They have been started to do some hard work for me, not to chew the fat with unknown servers... π.
Notepad3 is quite mature, most people do not need to check for updates, NP3 works perfectly for them. I want to check for updates, if I am missing a feature or if the feature I need is broken (π) or there might be security issues which has been recently solved. Last point does not apply to NP3 - not at least: cause there is no web-communication-component π .
As you can see, I don't like the convenient way of updates for lean and mean power-tools like NP3. An alternate solution would be to start an Installer/Updater (the way like minipath.exe is started) with option /update_check which handles all related stuff (check for updates, display info, download and install/replace(portable) ) ...
As always: this is my personal opinion. πΊ
@engelhro : No, NP3 does not "know" if it is a "Beta" or a regular release version. Everybody can fork or download the source code and build his own version and change the version number as he like. Currently, I am the only one providing beta builds and I try to have a consistent version number. The version number has some restrictions (major.yy.mdd.build):
This can be extended (for beta builds) by what ever you can think of ("Γ" and/or short name of developer ...). This needs only some discipline on building and deploying beta builds, the final release is done by @rizonesoft.
@RaiKoHoff: I'm quite your opinion. NP3 is a feature-rich, but still "lightweight" tool with a limited (that's good here!) focus: editing text. And not much more, especially not tapping into the wide and difficult world of external communication via web, with all its drawbacks, especially potential security problems.
And as you said: any check at start would come at the cost of startup time, even when the check is performed delayed and in the background. Sometimes NP3 is run a few dozens times per day by me, so I think its start should happen as instant as possible, keeping the "quick and straightforward" approach.
Thus I support the idea of conducting an update check only on request and also the loose coupling (i.βe., using a separate tool for this).
@RaiKoHoff @craigo- @engelhro I think I've found a solution. How about using something like this: https://wyday.com/wybuild/ for automatic updated. The only drawback is an extra 500kb being added to the installation. π
@RaiKoHoff Would you like me to also release beta builds and help you out a little? I can create a quick build after each PR.
Your offer is very kind, thank you very much. It is not much work to distribute the beta builds and I prefer to have a PR which is not Beta, so the beta tests should have been done before the PR. Builds after a PR may be called "Release Candidates (RC)", which might be of interest to a broader audience. In the end, I think: having RCs will be a little bit over-engineered for a small tool like NP3.
@rizonesoft : I took a quick view on the "wyBuild/wyUpdater" website. It seems to be a perfect solution for large scale projects, delivering small patches only. It can be used as a "Standalone Updater", triggered by NP3, too. So it seems to be a perfect solution for this task, if you like to spent the invest and time to change the Installer accordingly.
@RaiKoHoff @engelhro @craigo- I uploaded the automatic update test versions to the Beta channel. To run the automatic updater, click on wyUpdate.exe. The one in the build 862 will show there is an update avaialable and the one in build 867 will show you have the latest version.
The only drawbacks I could see is the 500KB added to the folder and there is no way to efficiantly include Beta builds. Unless I start a seperate update chain.
Please test and let me know. Thanks!
I forgot to mention @hpwamr If you can also test automatic updates and give me some suggestions, it would be appriciated.
@rizonesoft : Shall we keep the "https://www.rizonesoft.com/downloads/notepad3/update/?version=" server update check as a fallback in case of (broken?)/missing wyUpdate.exe
to be maintained in MP3's sourcecode ?
My personal opinion is that the update will work ONLY with the "Officially and Stable" version. NP3 Update must be reserved for common users and offer them a stable product. People who want to work with Beta versions, have to manually update them at their own risk !
@hpwamr Agreed. @RaiKoHoff good idea.
Beta version 3.18.206.874 includes the wyUpdate.exe and call via "Check for Updates"
@RaiKoHoff Is it working for you?
I played around a little bit with the updater and it was working so far. I looks quite nice, it is small and fast. π Found one issue: the portable installation don't need elevated rights for update NP3 executable. But this is of minor priority.
@RaiKoHoff , @rizonesoft I've tested with the Beta version 3.18.206.874 (portable). It working for me. I receive the msg '"Latest version already installed" When I'm disconnecting the Internet the msg become: An error occured" Unable to check for updates, the server file fails to load.
Question: how to simulate an update is needed ?
@hpwamr Thanks for testing. The only way to test it is to test build 862 I uploaded to the beta channel.
It seems that wyUpdate.exe does not check the executable for the version number, but its client.wyc for version number. I think this is not optimal π¬ (in case of portable "installation" (copy deployment)).
I put a 3.18.101.774
into 3.18.206.874
directory. This is a 3.18.206.874
with "faked" old version number (3.18.101.774
) plus a client.wyc
which is version 3.18.131.862
.
@rizonesoft : Is there a way to tell wyUpdate.exe
to check the executable instead of his client.wyc
?
A workaround would be, the NP3 creates the correct client.wyc
file before calling wyupdate.exe
,
but that will not work with installed version of NP3, where elevated rights are needed π€
@RaiKoHoff Unfortunately not! A new client.wyc needs to be generated for each release. But I do not see this as an issue. It updates the client.wyc when updating the the latest version. It gives me more control at the end of the day and better security. I'll explain. When creating a new update, I upload the files I would like it to update and only those files are updated. Better version handling this way. Kind of the same way GitHub does it.
Hope what I said makes sense.
Done: build 862 downloaded from the beta channel". Test OK "Beta 862_x64 updated to 867x64 π
Take a look at these update files: https://github.com/rizonesoft/Notepad3/tree/master/Build/Update/Updates You will notice that the system is pretty dynamic.
It starts the version control when you created the first set of updates. Meaning it can update build 862 to any newer version. Or just from 862 to 874, if 874 is the newest. The normal user will not notice that there is a seperate client.wyc file in each distribution.
When I do not include a file in a new update set, it is automatically deleted when updating on the users PC. Take the following situation. We update any other file than Notepad3.exe and would like to roll out an update. With wyUpdate we can do this, but with checking the Notepad3.exe it is almost impossible.
@rizonesoft : OK, as long as the entire "collection of files" (like in GitHub) is consistent, there is no problem. GitHub is smarter, it does not rely on files timestamp but on file content hashes and detects inconsistencies. It has been only a surprise to me, that wyUpdate relies on side-by-side configuration without consistency check. In the end, knowing the possible side-effects, I am fine with it. π
@rizonesoft : Merged PR #346 changed the menu entry ? -> Check for Updates
to ? -> Launch Update Installer
, as this reflects better what is going on. Any other suggestion ?
@RaiKoHoff I'm happy with Launch Update Installer. It reflects the nature of the addon. π
@rizonesoft : Shall we have an additional (separate) menu entry ? -> Check Website for Updates
?
@rizonesoft, @RaiKoHoff "Shall we have an additional (separate) menu entry ? -> Check Website for Updates ?"
It could be a good idea to have 2 entries in ( ? )
of a new menu in ( ? )
with 2 entries. E.g. :
Check Website for Updates ?
(to check for availability of new update)Launch Update Installer ?
(to propose an automatic installation in case of an update is available)Post deleted... (because request against the policy of having no web communications itself) π
@hpwamr Because of the nature of wyUpdate, it is not posible to change the interface. Then, It is my opinion that the wyUpdate 'addon' is not time consuming. No more than any other automatic update function available, but thats just me. Lets hear what @RaiKoHoff has to say about it. π
@rizonesoft , @RaiKoHoff
You're right, I've juste check beta_3.18.209.879
and the check for new version is NOW very fast ! π π
Please, forget my last post !
@hpwamr : If your solution implies that NP3 owns the dialog box, NP3 has to check for updated state itself, which is against the policy of having no web communications itself. If your solution implies to change the user interface of the wyUpdater, this seems not be possible.
If the Updater is started once, I assume wyUpdater is of same speed or faster in checking for available updates as/than NP3 itself.
My suggestion to have an additional menu entry to check the website directly is just for people who wants to avoid starting another executable for this task (assuming that the standard web-browser stays always open during work :grin:).
So I am fine with the current solution, just asking if this second entry is wanted.
Implement a simple update check when Notepad3 starts and optionally a check for updates menu item (on help). Here is the update ini file example I use for other Rizonesoft products.
[Update] LatestBuild=605 UpdateURL=https://www.rizonesoft.com/downloads/notepad3/
When I have some time, I can start working on something like this, but I am sure @RaiKoHoff would be able to get this dome much faster than me.