|
Glenn Posts: 99
16/01/2016
|
Pondering some updates to my SyMenu installations today, and thinking about the "fully customizable menu" limitations regarding treating all the user entries as a single block, the following ideas came to mind. They are somewhat redundant in nature, in that the overall goal is to allow shared chunks of menu structure. The first has appeal, if it can be implemented, because it might also be a way to intermix blocks of "SyMenu defined" and blocks of "user defined" menu structures, which is not presently possible.
1. It would be nice if there could be multiple blocks of "user defined" menu entries. One block would come from the current directory structure, and not be deletable. Other blocks would be defined by pointing at a separate SyMenu directory structure, and borrowing, or importing, its user defined menu structure. These imported menu structures would always be read-only to this SyMenu instance, but could be added to or deleted from the main menu list as a block. Perhaps due to the different classes, all the "user defined" blocks would have to be contiguous, but perhaps not (which would be more flexible). Perhaps the "import" entry would be new type of SyItem, instead of an additional block in the "SyMenu defined" list.
The goal here would be to have pieces of menu that could be maintained separately, but used together, preferably without adding an extra level of menu nesting, just additional entries obtained from the other SyMenu directory structure.
2. The other idea is an outgrowth of one I suggested recently, which I think is on your todo list... that entries that require Read/Write access simply vanish from the menu structure when the instance discovers it should be READONLY (either with the file flag, or the read-only file system).
This variation would be menu entries that are visible or invisible based on the existence of an environmental or SyMenu variable with a specific substring found in its value at SyMenu initialization time. The default would be for entries to be visible; but the existence of a particular substring in a specified variable would make it invisible, or the default could be for entries to be invisible, but the existence of a particular substring in a specified variable would make it visible. Either way could work. It could even be required to be a SyMenu variable with a specific name, if that simplifies the configuration or implementation.
The value of the variable then would simply be a set of delimiters and substrings, such as ~abc~def~ where the check would be for either ~abc~ or ~def~. Or it could just be a list of characters, where a single character suffices to specify the visibility of the menu entry. Short strings seems easier to keep track of, the "substring existence" check would allow users to choose either of these techniques, or possibly invent other clever schemes. One advantage of allowing the menu creator to specify both variable and substring for a command is that the variable could be something like USERNAME for commands that belong to a single user... if USERNAME is unique enough for the set of users involved.
The goal here would be to have a complete menu structure maintainable as one piece, but eliminate certain menu entries for certain users that don't need them, without having to maintain multiple, nearly-identical menu structures with just one or a few extra commands in some of them.
edited by Glenn on 16/01/2016
|
|
|
link
|
|
Glenn Posts: 99
17/01/2016
|
Another use for the "vanishing" menu entries would be to deal with 32-bit/64-bit differences. I'm aware http://www.ugmfree.it/Forum/messages.aspx?TopicID=345, but it would be possible to simply define two menu entries, both with "PROCESSOR_ARCHITECTURE" as the variable, one with "x86" and one with "AMD64" as the substring, and only the appropriate one would appear.
|
|
|
link
|
|
Glenn Posts: 99
17/01/2016
|
Here's another idea, different than the above: In the Item Manager, it would be nice to have a "make copy" operation when an item is selected. It would make an exact copy of an item, but give it a different name (by adding "Copy of " to the front, or something along that line).
Then similar commands could be created more efficiently.
|
|
|
link
|
|
sl23 Posts: 285
17/01/2016
|
I like the idea of showing correct apps depending whether 64bit or not, but some apps require 32bit. An example would be LMMS. As it requires the use of 32bit dll files (VST's) the 64bit version won't load them. I hope in the future to add MuLab 32/64 too, which also doesn't have a VST bridge.
I suppose exceptions could be made for apps such as these, is it worth the hassle?
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
19/01/2016
|
Hi Glenn. You split your proposals in two because probably your target could be reached in either ways but they are two different requests:
- different blocks of user entries available on the menu structure
- possibility to disabling/hiding portions of user entries.
I would like to do some considerations about the feasibility and opportunity to implement these features.
The first option is hardly feasible. The only real way to do that would be integrating the menu structure with the user items structure (it was an idea of yours I guess). Every other way seems to me not correct. Moreover this implementation will need an incredible effort by my side, and I prefer to dedicate my time to other implementations. I suspect that eventually the real effect of this feature will be confusion. A normal user would be forced to manage his items and the native ones. If I am a normal user I'll ask to myself "why the hell I have to manage the native items since I have problems to manage my items yet".
The second option is nice and organic.
SyMenu already supports the hide item feature. If I extend this feature to the command line, it becomes available in a more extended and flexible way but remains out of sight of our normal users. But my approach to implement that feature would be different than yours.
My proposal: the SyItems don't acquire new properties to drive the visibility. This is an important condition because I don't want to create structure inside the entities for a rare used request. So let's think in a more economic way.
The SyItems are reachable from the command line by their names. If I have a folder called "User 123" I could pass to the command line a command like that -hi "User 123".
I can imagine a further option. If I have a folder called "User 1234" that has to be shown I can add this other flag -sw "User 1234". The -sw (show) flag is priority to the -hi (hide) flag.
What's about name collision? It's up to you. Don't use the same name for different elements :-)
In this scenario it could be even possible to use wildcards. I imagine something like that:
-hi "User*" -sh "User 1234"
Every element starting with the name User will be hided except for User 1234.
I'm not so sure that the command line hide feature should affect every item.
The native item won't be affected at all, you have the new menu structure to modify that. Naturally the Syfolders should be included but I'm not sure that the other SyItem should.
What's your opinion like?
Speaking about the Item copy it is already available: http://www.ugmfree.it/SyMenuManual.aspx#dragAndDropClone
Don't work for the folder elements.
|
|
|
link
|
|
Glenn Posts: 99
22/01/2016
|
@sl23: as I outlined the idea, the "PROCESSOR_ARCHITECTURE" would be a configurable technique to turn on or off particular items. If your version of Windows includes WOW6432 (or whatever it is called), then programs of the opposite bitness could still be invoked, but when programs have both 32 and 64 bit versions, the idea, if implemented, could be configured to hide the one that doesn't match the native architecture, presumably the one that matches would be preferred.
@Gianluca: I suspected that would be your reaction to the "multiple blocks of user entries" idea, but it was just enough different than full integration that I thought there might be a small possibility it might be more practical, and thus worth mentioning. So we will not discuss that further.
The hide/show idea:
Agreed that most users, and most SyItem menu entries would not need the options. And I'm not averse to command line options in general. However, most usages of the option would be tightly coupled to the SyItem, and needing to also change the command line options on a command by command basis would be awkward. Naming the commands in a way to minimize the number of command line options required to turn them on or off would also be awkward, or make the command line long. I see 2-3 "global values" being set, but a dozen or more SyItems wanting to be tweaked based on those global values... the same value turning some SyItems on, and others off.
I note that you have, under Advanced options (for SyProgram only) the 4 boxes for particular environment variables. We had discussed the possibility of changing that to not be specific to those 4 variables, but to allow for a list of (name, value) pairs, allowing a user-specified variable to be set to a user-specified value to be passed to this particular program. We hadn't discussed how many, but some programs would benefit from 5-6 such variables. Often they can be set globally and other programs will ignore them. Mostly it would be when using the same program in multiple ways, that specific settings for particular variables would want to differ. We didn't discuss the UI for that... there isn't a lot of space right there, but maybe a multiple selection list box with a few items showing, scrollable, a button to delete the selected items, and a button to pop up a dialog box where a new name, value pair could be entered and added to the list.
If the above happens, then maybe instead of just (name, value) it could be extended to (usage, name, value) where usage would be one of:
→Set this variable to this value for this run of this program
→Check this variable for this substring to determine the visibility of this command in the menu
One could gain a bit of space, by combining the working directory into the list:
→Use this value for the working directory [which would empty and disable the name box]
→Use this value for the Home drive for folder [I really haven't figured out what this does, or why it is useful, but I'll trust that it is: I looked in the manual and found the section named "SyProgram - Advanced" and didn't find anything about "Home drive for folder", but somehow I missed how to copy items, which is embarrassing.]
The Default values button could be moved up by "Enable Advanced params" checkbox (actually, is there any reason to have the "Enable advanced params" as a checkbox? if everything is blank, what gets enabled?), and would cause the default values to be explicitly filled in, or the overridden values to be removed? And actually, I'm not sure the Default values generated are particularly useful, either. Maybe they are, but they seem specific to the "current managed 4 variables" so without those, maybe this button could go away too.
So Advanced could wind up as just add/delete buttons, and a list of name value pairs. The usages could be specified by special names, following by → whereas environment variable settings would be the environment variable name following by =, and hide/show by name ?, and then the value. For example:
Working Directory → %WORKING DIRECTORY%
Home Drive for folder → G:
APPDATA=.\APPDATA
PROCESSOR_ARCHITECTURE ? x86
SPECIAL-FOR-THIS-PROGRAM=#:\progconfig
For more discrimination between types of values in the list, each type could be displayed in a different color to benefit non-color-blind people, but the plain text with special names and symbols would suffice for everyone.
Well, maybe the above would work for SyProgram... do other SyItems need to be turn on/off? Well, all the others would have room for the options in their UI. SyProgram is the most crowded. The only "usage" that would be relevant to the others would be the hide/show. The only other ones I could imagine wanting to hide/show would be separator and container, but maybe my imagination is limited in this regard. So those two, or all the other items could grow the "Advanced" tab, with the same interface, although most of the options would be irrelevant, and maybe only the one usage type even enabled.
|
|
|
link
|
|
Glenn Posts: 99
22/01/2016
|
Of course, the problem with UI design, is there are so many ways to do it. As soon as I sent the previous comment, I thought of a completely different alternative, not tied to restructuring the SyProgram Advanced options box (although those restructurings have merit on their own, perhaps).
A SyProgram could have a 4th button in the row "Additional Params" "Gesture" "Advanced" called "Visibility". A name and substring could be entered in boxes there, and maybe even a "not" checkbox, to invert the sense of the match. If the variable called name has substring in its value, the item would be visible. If "not" is checked, it would be invisible. Not finding the substring would produce the opposite result.
Then, the other items could all have the same "Visibility" options.
The problem I see with basing the choice on the name, is that the name of a program is not very indicative of whether it has both 16 and 32 bit versions, or whether or not it is an advanced program only appropriate for some users, or whether it is a program that only works in some environments. (these are the three concepts that I see for which this hide/show feature would be useful).
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
23/01/2016
|
I'm trying to reply to your proposals even if they are not so clear for me (maybe it is a language misunderstanding in this case).
Glenn wrote:
the idea could be configured to hide the one that doesn't match the native architecture, presumably the one that matches would be preferred.
The only real utility of this feature is when you hide a x64 program in a x32 platform. In some cases it is necessary to execute x32 programs in the x64 platform. An example: I user my preferred image viewer, Irfanview, to scan images from my printer. My printer driver is compatible with x32 architecture, so if I want to scan something I have to execute Irfanview x32 even if my system is x64. Honestly I think that the usefulness of an implementation that hides or preferably offers certain programs according to the OS architecture is very low.
Hide/show trough command line.
You are right. A too long and complex command line is not viable, above all the items to switch on/off are many.
Advanced parameter.
Well your idea is great and really useful at a UI level too. I can create the dropdown with the most common environment variable, program variables and some special variables.
The dropdown will help you to fill a multiline textbox where you can set and edit your variables by hand too.
I wouldn't push the system to create a specific operator syntax for activate/deactivate the features, but every feature could be represented by a different variable followed by the value. It's a more generic and expandable method.
For example if you want to hide an item you will have the variable SYMENU_SHOW
SYMENU_SHOW=false
In case you want to show or hide an element based on a condition you can use
SYMENU_SHOW=%BIT%==x64
Using the %BIT% variable instead the PROCESSOR_ARCHITECTURE we remain consistent with the variables define for the tooltip and we can use the variable value in the right hand side of our equation.
Naturally all the not SYMENU_ variables will be considered system variables or item variables.
When you want to define the Working directory for example you can create it dynamically with the universal unit identifier (#:\) as you do today
Working directory=#:\SyMenu\ProgramFiles
or dynamically with a custom variable passed from the command line
Working directory=%customPathFromCommandLine%ProgramFiles
All this architecture represents a simple idea started from your thoughts but I'm not so sure to implement it because:
1) I'm not so sure that this viable, consistent and understandable
2) I'm not so sure it is really useful for a lot of users. Your scenario and the implementation you are requesting are very special. I want to use my time to meet the requirements of a many users. So we can continue to speak about this topic but I would like to see a lot of interested about it too otherwise our speculation will remain so.
Glenn wrote:
actually, is there any reason to have the "Enable advanced params" as a checkbox? if everything is blank, what gets enabled?
Simply you can disable the advanced params without any need to empty all the fields and the system preserves your values for a future use.
|
|
|
link
|
|
Glenn Posts: 99
24/01/2016
|
Gianluca wrote:
I'm trying to reply to your proposals even if they are not so clear for me (maybe it is a language misunderstanding in this case).
Sure. We'll keep talking until we understand each other.
Glenn wrote:
the idea could be configured to hide the one that doesn't match the native architecture, presumably the one that matches would be preferred.
Gianluca wrote:
The only real utility of this feature is when you hide a x64 program in a x32 platform. In some cases it is necessary to execute x32 programs in the x64 platform. An example: I user my preferred image viewer, Irfanview, to scan images from my printer. My printer driver is compatible with x32 architecture, so if I want to scan something I have to execute Irfanview x32 even if my system is x64. Honestly I think that the usefulness of an implementation that hides or preferably offers certain programs according to the OS architecture is very low.
In the cases that it is necessary to execute x32 on x64, one wouldn't hide it. In the cases that it is not necessary to execute x32 on x64, one could hide it. http://www.ugmfree.it/Forum/messages.aspx?TopicID=345 is not from me, but demonstrates a different technique for choosing a program based on architecture. That technique doesn't allow for choosing x32 on x64, and indicates I am not alone in thinking there is merit to the idea. Although I'm suggesting a much more general technique, that could easily be used to implement any combination of visibility for x32 or x64 programs on x32 or x64 architectures, whichever combinations want to be displayed (probably only a proper or improper subset of the ones that work, but particularly, avoiding ones that don't work, or aren't necessary for the project.)
Gianluca wrote:
Hide/show trough command line.
You are right. A too long and complex command line is not viable, above all the items to switch on/off are many.
Advanced parameter.
Well your idea is great and really useful at a UI level too. I can create the dropdown with the most common environment variable, program variables and some special variables.
The dropdown will help you to fill a multiline textbox where you can set and edit your variables by hand too.
I wouldn't push the system to create a specific operator syntax for activate/deactivate the features, but every feature could be represented by a different variable followed by the value. It's a more generic and expandable method.
For example if you want to hide an item you will have the variable SYMENU_SHOW
SYMENU_SHOW=false
In case you want to show or hide an element based on a condition you can use
SYMENU_SHOW=%BIT%==x64
Using the %BIT% variable instead the PROCESSOR_ARCHITECTURE we remain consistent with the variables define for the tooltip and we can use the variable value in the right hand side of our equation.
Naturally all the not SYMENU_ variables will be considered system variables or item variables.
When you want to define the Working directory for example you can create it dynamically with the universal unit identifier (#:\) as you do today
Working directory=#:\SyMenu\ProgramFiles
or dynamically with a custom variable passed from the command line
Working directory=%customPathFromCommandLine%ProgramFiles
All this architecture represents a simple idea started from your thoughts but I'm not so sure to implement it because:
1) I'm not so sure that this viable, consistent and understandable
2) I'm not so sure it is really useful for a lot of users. Your scenario and the implementation you are requesting are very special. I want to use my time to meet the requirements of a many users. So we can continue to speak about this topic but I would like to see a lot of interested about it too otherwise our speculation will remain so.
--- general response
I hear you on spending time to meet requirements of many users. I do appreciate the "specials" that you've done for me, already. It seemed like a simple idea, similar to turning off the "Configuration" menu entry for READONLY users. But implementation ideas are more complex, so far. My first idea, reworking Advanced settings in SyProgram items, is a significant rework, but provides other benefits than visibility.... if they are deemed beneficial.
One of the reasons I poked at the Advanced settings in SyProgram items, and the 4 environment variables there, was that those particular 4 don't seem all that useful to set, and others would be; and your manual even admits those 4 aren't even paid attention to by many programs that simply read the registry to get the "real" values, or use various Win32 APIs that read the registry on their behalf to get the "real" values. But there are a fair number of tools (especially programming tools, and especially ports of Unix/Linux programs) that do respond to particular environment variables of their own creation, so changing/expanding that feature seems of quite general utility to me.
The other implementation idea, a new box beside the Advanced box, would be more easily applicable to other SyItem types, and is independent of enhancements to things in the Advanced box, but is also a fair bit of code to implement a small. Anything with a user interface takes a fair bit of code, unfortunately.
Your idea of command line gets unwieldy, at least in the way you proposed it, by matching menu entry text (if I understood it correctly), because groups of things to enable/disable don't necessarily have common text... and in the case of architecture visibility...the 32-bit and 64-bit program menu entries, being mutually exclusive in visibility (for some scenarios) might want to have exactly the same menu text!
It is much easier to find problems with implementation ideas, than to think them up!! But I'll do some more thinking, and maybe something with a much smaller implementation will occur to me.
---- specific responses
I'd agree, I don't think you understand all the ideas I tried to describe, and I don't think I understand all of yours.... that certainly raises the question of "viable, consistent, and understandable" !
In your examples you show an expression syntax. I was attempting to avoid expression evaluation, and just use substring searching with success or failure of the search determining the visibility. So I think I'd simplify your 2nd example to:
BIT ? x64
With the ? marking that as a "visibility" option, instead of = meaning a variable to set... examining the BIT variable and seeing if it contains x64 or not.
So far in my use of SyMenu, I've only found reason to use one value for "Working directory": %WORKING DIRECTORY%. Anything where programs are stored is completely inappropriate for use as a "Working directory", which is where data files should be. Windows gets that backwards. I start SyMenu giving it a "working directory" of the directory where the data is.... and want to pass that to all the programs it starts, as well.
Glenn wrote:
actually, is there any reason to have the "Enable advanced params" as a checkbox? if everything is blank, what gets enabled?
Gianluca wrote:
Simply you can disable the advanced params without any need to empty all the fields and the system preserves your values for a future use.
OK. I guess I couldn't see any value in filling all the fields, and then not using them  But maybe for debugging or something, turning them off without losing them would be useful... Once could make a copy of the SyItem, and empty them out there, for debugging.... So I'm missing the use case for the disable button, but my only reason for questioning it was to save space in rearranging things, to be able to show more environment variable settings.
|
|
|
link
|
|
Glenn Posts: 99
25/01/2016
|
This discussion, whether there are any changes to SyMenu that result or not, has been very profitable to me in understanding the disconnect there is between efficiency and Windows. While not really on-topic for discussion here, I wrote a diatribe about it at http://slashdot.org/firehose.pl?op=view&id=80569101. Some people may have simple projects and use only one file and one program at a time. When it gets more complex than that, Windows gets seriously in the way, and one of your comments (paraphrased) "but that is the Windows default for Start In" and one of mine "So far in my use of SyMenu, I've only found reason to use one value for "Working directory": %WORKING DIRECTORY%." finally made it click for me why Windows is so inefficient to use, which is the topic of the diatribe. And in my search for efficiency, and for a portable menu structure to help with using Dropbox and portable programs effectively, one of the things I found was SyMenu... and yet there are some thing about SyMenu, duly borrowed from "the Windows way of doing things", that I have to consistently work around. But now that I've found "Control" to copy SyItems, that is easier to work around, even if the defaults are too much like "the Windows way of doing things"
Sadly, "the Windows way of doing things" has been ingrained into so many programs, that I doubt they will ever be cured. Yet, it would only take a few tweaks to most program to allow an efficient way of doing things to live side by side with "the Windows way".
1. Launching programs and shortcuts should respect the concept of a "current working directory" as more important than a "Start In" directory. But the way the presently get started by Windows, they only get a hint of "current working directory" if they are launched by clicking on an associated file: the path to that file is the "current working directory". If they get launched from Start menu or desktop shortcuts, they have no clue, and are given a "generic" Environment block and "global" access to the registry, neither of which informs them of the user context.
2. Multiple instances of programs should be common: one for each "current working directory", rather than one per user.
3. When using multiple desktops, the "current working directory" should be tightly bound to it, and passed along to programs, as part of the "current desktop environment", so that there can be one project per desktop.
The key thing is in understanding that "projects" are the efficient form of organization, not "programs". No one ever created their paper filing system for their business by putting all their receipts from Home Depot in one place, and all their receipts from Lowe's in another: instead, the receipts were filed by "project" or "customer" for later reimbursement.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
27/01/2016
|
Glenn wrote:
BIT ? x64
With the ? marking that as a "visibility" option, instead of = meaning a variable to set... examining the BIT variable and seeing if it contains x64 or not.
My doubt in using an operator to impose visibility on an item is that: what does happen when we need to set another property on that item? Shall we define another operator?
For example we could think that in certain machine we want to execute some items in elevated mode.
The operator could be § and the syntax
MACHINENAME § AdminPC
Some items should be shown but disabled when in read only mode
ç READONLY
Some others will be executed twice when you pass true from the command line with the variable %xyz%
£ %xyz%
We will risk to be short of strange operators and to create an obscure system for super experts.
This is the reason for which I prefer to use built-in variable. Our syntax will change in:
SYMENU_RUNADMIN=%ComputerName%==AdminPC
SYMENU_DISABLE=%READONLY%
SYMENU_EXECUTETWICE=%xyz%==true
Well I don't like a lot my proposed syntax but I totally disagree yours, because it is more cryptic than mine. I'm completely opened to other proposals but clearer, consistent, and expandable.
Glenn wrote:
but my only reason for questioning it was to save space in rearranging things
I think that if we pass to the dropdown system almost all the advanced box will be dedicated to a multiline textbox where the environment variables, the built-in variables, and the custom variables are shown. So the space shouldn't be a problem anymore.
This things is starting to tickle my mind
Last thing.
Wow Glenn... I greedily read your slashdot article. Bravo! Everyone working deeply in Windows should read that.
My two cents to the topic now.
If multiple program instances and virtual desktops are not the reply because the Windows behaviour, have you ever thought about program virtualization?
It's a bit like portabilize a programs but a bit different. With program virtualization you create a sandbox where the program executes believing to be in charge of its world and instead it is inside a fishbowl, so the virtualization concept could be extended to allow the creation of simultaneous multiple sandboxes starting from the same executable.
In the past I played with Altiris SVS (now Symantec Workspace virtualization) and VMWare ThinApp but either don't push the concept to an extreme like you are proposing... and it is a shame.
|
|
|
link
|
|
Glenn Posts: 99
01/02/2016
|
Glad you liked my writeup. Anyway, that bit of insight into why I'm always fighting with the Windows way of doing things will help me recognize the issue more quickly, and help you understand my point of view, in trying to make SyMenu do things that Windows doesn't want to do!
The whole "portable program" concept is really somewhat of a reaction to Windows integrating so many million settings into the registry, instead of .ini files... and one can see the need for doing that if one believes that there should be some many million settings to set in the first place, and if they really should apply to *all* programs. And some some of the millions of *Windows* settings should apply to all programs, but settings for individual programs are still better off in .ini files (or something equivalent), methinks.
The registry is also nice in supporting concurrency of updates, which is an issue you've helped me work around with READONLY settings for my use of concurrent copies of SyMenu on Dropbox. But the registry is a total pain in the neck due to the need to "install" programs rather than just run them, and to repeatedly install of every different machine, because the settings are not portable, to be moved from one machine to another... whether via portable media, or shared online media.
I'm still thinking about various possibilities for a user interface for this "visibility" option, in spare moments, but there haven't been many of them this past week.
|
|
|
link
|
|
Glenn Posts: 99
01/02/2016
|
Oh, and regarding sandboxes. Windows implements one sandbox, but it is sort of a sledgehammer.... separate users. And so-called "fast user switching" is a way to get multiple independent desktops. I haven't played with that, mostly I've configured my machines with one user only, but when I mentioned this issue and that possible solution to a friend, he was aghast at the thought of using separate users to separate tasks because of what he claimed were onerous switching times or techniques.
Another sandbox is virtualization, where you can have subsidiary OS running on the same machine. I've played with three of those: the one built in to Windows since Win7Pro but done better in Win8Pro; the Oracle one, and the VMWare one. There is a lot of setup work to get any of those to run successfully, and I didn't try using them on a separate desktop, but they do have their own environment and windows, and so they could potentially be somewhat of a solution, especially if running multiple instances on multiple desktops (if that is allowed). But this would be a sledgehammer too, requiring installing the OS multiple times as well as all the applications of interest, just to get separate "current working directory" for multiple tasks, and makes sharing of file between projects harder too, but the whole point is that sharing between projects _should_ be (somewhat) hard, because it leads to confusion when they are all dumped together.
A single program sandbox (such as in a browser, or an antivirus) wouldn't solve the problem of sharing one "current working directory" context among multiple programs used for a project.
I'm not familiar with the VMWare Thin App concept or the Symantec Virtual Workspace. I'll have to read the marketing blurbs on those when I get some time.
|
|
|
link
|