On Fri, 19 Aug 2011 20:36:02 +1200, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:Clemens wrote:> In case of tracker thats a bit different. IMHO the problem here is that > tracker is a single process but there should be one BApplication for each> window. Just another reason for that: tracker add-ons can crash the > complete tracker session, that is bad.There are also cons for such a design. Multi-launch would make coordinationof what directories have been opened significantly more complicated. Itwould also waste resources and make currently Tracker-wide caches (like theicon cache and probably also node monitoring) work far less efficiently. People more familiar with Tracker might come up with more issues.Not necessarily more problems (aside from settings being loaded again for each new process), but all this could certainly be solved with proper use of shared memory. However, there is absolutely no point in doing so: putting Tracker windows in separate processes would just be a huge waste of resources (also developer resources) without any gain -- opening a window in Tracker would just use up more resources and would be slower (due to dynamic binding the executable). Future Tracker versions which might use add-ons for their views would take an even higher penalty.
ok does it really slows down the loading noticeable? If that is the case that would really not a acceptable solution, tracker has to popup best a few ms before clicking it ;)
Putting the current add-ons in a separate process is a whole different thing, though, and certainly a good idea, as they don't need access to any Tracker internals and vice versa.
+1As Ingo already pointed, I think the solution would be to also add a save/restore hook to BWindow. The BWindow save state method could return a flag, e.g. B_STATE_SAVED or B_NEED_TO_SAVE_APP_STATE. to indicate if a window is autonomic or not. The default hook would return B_NEED_TO_SAVE_APP_STATE. The default BApplication store hook would call the store hook of all windows. In this way the developer can easily chose where the storing can be done best, in BWindow or in BApplication.
A profile manager could use the BWindow return value to decide if the complete app state has to be saved, e.g. if all windows of a app which are asked to store their state return B_NEED_TO_SAVE_APP_STATE otherwise only the B_STATE_SAVED windows are included to the profile.
A session manager would just call the BApplication store hook.
Regards,
Clemens