Jump to content
Enpass Discussion Forum

Unsay

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Unsay

  1. A similar error has already been reported (here), but this is a defferent problem. Tested on Android 8.0. After selecting OneDrive from the "Sync With" drop down menu, Enpass briefly shows an "Authenticating" pop-up, Firefox is automatically opened and directed the the Microsoft website, and then Enpass shows this error message: The sync with OneDrive was canceled by the user. I can only click "OK". The "Sync With" drop down is reverted to "None". This worked fine in 5.x FYI: My device is rooted and the default browser is Firefox. Chrome is not installed on my
  2. On Linux, Enpass configuration information is saved to: /home/<user>/Documents/Enpass This is very "Windowsy". In keeping with the spirit of Linux, it should be saved to: /home/<user>/.enpass
  3. This is the problem! You should be working smarter, not necessarily harder ;-) Place all editions of Enpass for Windows on a single code base, with a swappable UI (QT, UWP, or a headless version without a UI which is what would be used 95% of the time when Enpass acts as the back-end for a browser extension)! If you did that you could: release non-UI features for all editions of Enpass for Windows simultaneously, including FF57 support. Require only two editions of Enpass (legacy QT edition for Windows 7/8.x/ and Enpass Portable and an UWP edition for Windows 10), making
  4. Yes, I completely agree. I've been complaining about the root cause of this problem too, for over a year now. Every version of Enpass for Windows suffers from it, e.g. the portable version also isn't compatible with FF57, so people who need the combination of portability and FF57 are out of luck too. Need FF57 and Edge... out of luck. Need Windows Hello and any browser plugin at all... out of luck. All of these editions of Enpass for Windows should theoretically be generated from a single, consolidated and shared code base. That would ensure that all non-UI features (like browser plugins,
  5. All of the questions asked in this thread, and much of the confusion, could be avoided if people would just read! Anyone saying "Help! I'm using the current/latest version of Enpass on Windows and the Firefox 57 plugin doesn't work" needs to stop and inform themselves first! There are multiple editions of Enpass on Windows, all of which have different version numbers. All of them are the current/latest version of Enpass, for their edition. Only one edition is compatible with Firefox 57. Three of them work with Firefox 56 and earlier. Only one of them works with Edge. Frankly, I think
  6. @bunnyhero @tojtojka As Gajender mentioned in the OP, you must have: "the latest Enpass v5.6 for Windows, Linux or Mac (Website version)". The version you are using is v5.6.2 (Microsoft Store version). That will not work. There are currently four different versions of Enpass for Windows: 1. Win32 version for Windows 7/8/8.1/10 [Website] 2. Win32 version for Windows 7/8/8.1/10 PORTABLE [Website] 3. Win32 version for Windows 10 [Store] (the only version that supports the MS Edge WebExtension) 4. UWP version for Windows 10 [Store] (the only version that supports UWP feat
  7. Hi @Anshu kumar It's frustrating because it's so entirely unnecessary. It just makes absolutely no sense for both "standard" and "portable" versions of Enpass to exist. The "standard" version for Windows PC reached 5.6. weeks ago. There is no reason that shouldn't automatically yield the "portable" version for Windows PC as well (or visa versa). For Windows, the state of the WebExtension for Firefox on other platforms is simply irrelevant. For each platform, both the "standard" and "portable" versions really should be one and a same, with the only difference being a slightly differen
  8. Seriously, what are you guys thinking? For any well designed piece of software, there is no reason to separate the standard from the portable version. There is no reason for these two distributions to not be the exact same thing. *sigh* Everyone else can do it, why can't you? People using the portable version also use Firefox... now at version 57... which is incompatible. This has been fixed in the standard version 5.6, but the portable version continues to frustratingly lag behind. It remains incompatible. Any chance you'll get around to updating the portable version from 5..5.
  9. Woot! Just tried out Portable 5.5.5 and this has finally been fixed. Thank you! Now we just need to find out why keeping the non-portable version makes sense (hint: it doesn't): ;-)
  10. I just tried out the portable version again. It still uses the nag-dialog which unnecessarily asks us to specify the path to the wallet file every time it is launched. :-( If the most recently used relative path from enpass.exe to the wallet file is still valid, why not skip the nag-dialog entirely and just provide a way to explicitly open it if required? Why not consolidate on using just the portable version and getting rid of the non-portable version entirely?
  11. Or, rather than going only half way, solve the problem entirely. Just update Enpass in the background automatically without requiring any user interaction whatsoever. Allow users to disable automatic updates in the settings, which would prompt users to update, but don't make that the default.
  12. Well, in any case, thanks for the update. Much appreciated Vinod ! I'm glad you're considering your software's startup impact. Thank you. However, I think it's safe to assume that your software architecture is borked if you have UI dependencies in the lowest/core levels of the application. I suspect that's likely due to events that must be received and handled in the UI layer. If so, then you shouldn't be using QT for that, but rather your own event aggregator (see the Prism framework for a C# code example or any other observer or publisher/subscriber pattern). That would be use
  13. Hey @Vinod Kumar It's been four months, so I'm popping in to check up on this. Do you have any more information on that major refactor you said you had planned for this year, and whether or not, as part of that endeavor, you will split Enpass into a small, efficient, headless (without any dependency on QT) background task and a front-end application? I've noticed the rate of updates being applied to the Windows desktop application has slowed (which I'm almost thankful for), and thought a larger refactoring task may be the cause *hopeful* ;-)
  14. ^ rather than just hiding the Window, it would be better to just not have it exist at all. Even if it is hidden, we'd still be paying for its existence in terms of an additional 10MB of memory being wasted and it slowing down boot times.
  15. Another benefit of having only the portable version, would be that you could dump the installer (less maintenance, fewer things that can go wrong).
  16. Hey My1. Thanks! As I typically do, I had attempted to manually add Enpass to the Windows startup sequence, in which case the full UI is opened (ugly). Thanks to you I've since noticed the "Autorun on system startup" option. When that is checked, at least on my PC, a small Enpass Window briefly flashes on screen during startup and then disappears quietly (for once) into the tray (still ugly). Yes, that's workable, but it remains unpolished. Still, whatever is included in the startup sequence should be small, lightweight and fast! That's why Windows attempts to measure the "Start
  17. @Anshu kumar Hey Anshu, any ETA on this? Do you folks agree that there is no need for the normal desktop version if the portable version behaves as discussed above?
  18. I just also wanted to chime in and say I love the portable version of Enpass, and throw my support behind the same request everyone else here is voicing: By default use a standard path to the wallet that is relative to enpass.exe, and if the wallet file exists, don't show the configuration dialog at all. If you do this, the portable version of Enpass is the only version anybody needs. The normal non-portable desktop version might as well be retired.
  19. I'd like to know what you, Jespreet, expects the benefits of this to be. A lot of people misunderstand "open source" to mean free, which is of course wrong. Open source software can be free, but it doesn't have to be. One isn't related to the other. More importantly, asking people to give away their hard work for nothing is a bit brash. On the other hand, open sourcing Enpass can make a lot of sense if the idea is to allow anyone who has the technical skills to audit the software, thereby giving Enpass' security related claims a "community approved" stamp. Besides actually making Enpass m
  20. Any other feedback on this idea? What do you other users think? Anybody from Enpass want to take a public position?
  21. Of the few icons you suggested Dylan, I'd find two useful, yet I have a whole host of other icons I'd also find useful. Ultimately, no matter how many icons the developers add, there will always be some that are missing. At least for websites, this is not the right approach. It can't ever work well for everyone. Websites already have their own icons that enpass could access and reuse however. They are called favicons, and they are displayed in front of the URL in pretty much every browser's address bar. That's what enpass should be using. It's a mystery to me that they aren't already usin
  22. Enpass on desktops should be split into two separate programs: EnpassCore.exe: This executable file constitutes the core Enpass service that browser plugins communicate with. It should have no window-based-UI whatsoever. This is also what users (and/or the installer) would add to the boot sequence. On boot, adding an icon to the tray (on Windows) or the menu bar (on OSX) would be the only clue it is running. EnpassUI.exe: This executable file constitutes the windowed UI. If EnpassCore isn't running, launching the EnpassUI would automatically launch EnpassCore as well. From any brow
×
×
  • Create New...