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 browser plugin, EnpassUI should never be more than a single click away.

Benefits:

• EnpassCore has no windowed UI, so we could launch it as part of the boot sequence without having to deal with the annoying Enpass window being opened on every boot.
• A UI window should be in in one of the following states: opened, minimized, maximized, or closed. Since EnpassCore is always represented in the tray and EnpassUI is independent of that, there would be absolutely no need for the additional and unusual "minimized but in the tray" state Enpass currently employs. By separating what should be purely a background process from the front-end UI, we can eliminate the need for the quirky "minimize to tray" option and also say goodbye to the bothersome "Click here to restore Enpass" message that is shown every time Enpass is minimized to the tray on Windows 10. In a nutshell, how and when we require the UI for data lookup or data entry should have no affect on whether or not the Enpass service is running in the background.
• Because EnpassCore has no windowed UI, it could be very "lean and mean", thereby not noticeably impacting boot performance (assuming it's implemented as a native C/C++ application).
• For those people who are used to (or like) the way Enpass works now, there is no difference. Users can still add EnpassUI to the boot sequence and have the Enpass Window opened on boot if that is their preference.

Technical thoughts:

• Architecturally, browser plugins and the EnpassUI would just be different clients of the same EnpassCore application.
• In the interest of a shared code base and developer productivity, EnpassCore would ideally be implemented as a C/C++ program that can be compiled on any of the platforms Enpass supports.
• I chose the filenames EnpassCore.exe and EnpassUI.exe only as a way to more clearly communicate their purpose. Nothing more. The filenames are not part of this suggestion. It would probably be best if EnpassUI is named enpass.exe, so that launching enpass.exe would open the windowed UI as it always has. In this way, people who don't know about, care, or want this change wouldn't be impacted by it at all.

Edited November 7, 20169 yr by Unsay

Sounds like a very good idea, I'm truly supporting it. The implementation of course can vary, but the idea of UI and core sounds reasonable. 

Any other feedback on this idea? What do you other users think? Anybody from Enpass want to take a public position?

Edited October 25, 20169 yr by Unsay

Hey @Hemant Kumar

Any chance I can get your take on this?

Hi @Unsay,

Thanks for your suggestion and pretty detailed one. The solution you proposed is very feasible provided we have enough time to do this major refactor. We are planning a major UI/database/sync engine redesign of Enpass next year that will implement many new features that are not feasible with current architecture. I think that will be suitable time for considering your suggestion.

I have enpass as auto start on windows and iirc it always goes quietly right into the tray.

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 "Startup impact" for every application that participates in the startup sequence (see the Task Manager). For some reason that impact isn't measured for Enpass. However, my own measurements show that it's slow as molasses. I'm guessing that's down to Qt, which is a great technology choice for a cross platform UI. However, it is also fat and heavy and therefore has absolutely no business being loaded into memory as part of what should be a small and light background process. It also has no business just sitting around 90% of the time, doing absolutely nothing but wasting my memory.

It could be argued that a single application like Enpass going rogue during the startup sequence is tolerable, but if every application behaved this way we'd soon be back to waiting minutes for our computers to boot, for no other reason than those applications not having been designed properly. An application like Enpass is destined to be included in the startup sequence. It's "startup impact" should be measured and it should be as small as possible. Right now neither is the case.

Lastly, whether I add that background process to the Windows startup sequence manually, or allow Enpass to do so itself via settings, the result should be the same. That it acts differently is unintuitive/funky behavior.

So, I no longer have to deal with the full Enpass window being opened on boot (although the small flashing window isn't exactly pretty). The other aesthetical issues I mentioned remain. More importantly, startup performance is still abysmal and memory usage unjustified. Therefore I'd still very much look forward to Enpass implementing this suggestion.

I know I'm being tough here. I admit that these issues aren't deal breakers. However, it's things like this that make the difference between software that is just good and software that is great. I really want Enpass to be great! ;-)

Edited December 26, 20169 yr by Unsay

On 16.12.2016 at 10:05 PM, Unsay said:

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.

 

I noticed this small flashing window too. Is there a way to hide it?

Edited December 23, 20169 yr by mherold

^ 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.

 

Edited March 14, 20179 yr by Unsay

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* ;-)

Hi @Unsay,

 The refactoring process has been started as per plan with new vault architecture that can support multiple vaults and many requested features that were not possible with older architecture. Side-by-side, we have fixed a lot of pending bugs for upcoming update which is main cause of slow release cycle as of now. 

We have also done a feasibility test for a separate core headless app, but as we use Qt in many places in the core part also, it is still going to load Qt libraries at startup and hence no improvement in startup impact. So, we still continue to use our current model (core and UI in same app). However we are finding ways to reduce startup impact as per Microsoft guidelines https://msdn.microsoft.com/windows/compatibility/startup-apps.

Thanks

19 hours ago, Vinod Kumar said:

We have also done a feasibility test for a separate core headless app, but as we use Qt in many places in the core part also, it is still going to load Qt libraries at startup and hence no improvement in startup impact. So, we still continue to use our current model (core and UI in same app). However we are finding ways to reduce startup impact as per Microsoft guidelines https://msdn.microsoft.com/windows/compatibility/startup-apps.

Thanks

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 useful on every platform, including those that don't use QT (I'm assuming your mobile apps don't use QT and that you use the same OS independent core on every platform). The core would then communicate only with the cross platform event aggregator. That eliminates QT dependencies from the core. In desktop applications, the event aggregator would then propagate those events to the subscribed QT based event handlers. In mobile applications the aggregator would propagate those events to each mobile OSes native event subscribers.

Particularly for a company that builds a single application for so many platforms, it seems like a no-brainer that you'd be very interested in keeping UI dependencies out of the core. Just something to consider...

Good luck!

 

Edited March 15, 20179 yr by Unsay