SyMenu Forum

Gianluca

all messages by user

30/06/2015 Topic: New Executor-Identifier to edit SyMenu-Items Gianluca Administrator	Hi. It 's a good idea but: - I would like to know how many users find it really useful (indeed I find it really useful but I don't want to overcrowd this element) - I'm already thinking on adding a new executor modifier that allows to execute an item in elevate mode (not runas but run as admin). In this way the executor modifier will grow to five elements and adding your proposed one too there will be too many elements to pass all with the CRTL buttons... in my opinion they are already to many today. So it should be useful to rethink the access mode to executor modifier too. If anyone has a good idea let me know.
30/06/2015 Topic: Universal Unit Identifier extension Gianluca Administrator	Well my opinion is that your idea is fantastic but, are you really sure that every need you have shouldn't be accomplished using the relative path notation? For example if you have a program located in F:\AnyFolder\SyMenu\ProgramFiles\prog.exe or in \\netShare\SyMenu\ProgramFiles\prog.exe you can point to the prog.exe easily with the relative path: .\ProgramFiles\prog.exe It's a perfectly portable configuration and works on the network shares too. In the last versions I increased the portability of the WorkingDir and, especially, for the ProgramArgs parameter. Now either support the universal unit identifier and the relative path. So I ask you to make a real example not resolvable with the relative path notation. In case you find one it's probably a bug and I have to fix it. Otherwise I'll surely implement your #~:\ suggestion. edited by Gianluca on 01/07/2015
30/06/2015 Topic: New Executor-Identifier to edit SyMenu-Items Gianluca Administrator	Nice. I could show only the icons instead of icon-texts solution so there will be enough room to show all the modifier at one time. In that way you can choose to activate the modifier cycling on all of them with the CRTL button or you can choose to directly activate one with the CRTL+Number shortcut, or you can click directly on the desired one with the mouse without multiple clicks need. Well let's work on this idea. It seems promising.
30/06/2015 Topic: New Executor-Identifier to edit SyMenu-Items Gianluca Administrator	Smart observation. The compact mode should remain as it is today plus the new shortcuts CTRL+Number. It's compact so there is not room for nothing by definition
30/06/2015 Topic: Universal Unit Identifier extension Gianluca Administrator	Ok I don't know where the problem is but I quickly check some cases and the relative paths work regularly even when SyMenu entirely resides on a network share. Let's do an example with a Jar program. SyMenu reside on a network share, not mapped \\netShare\SyMenu The program executable in my case is a jar program so I have to put as a real executable java that is in the network share too. .\ProgramFiles\JavaRuntimeEnvironment\bin\java.exe Now my two experiments 1) Explicit Working dir Program argument: -jar prog.jar Working directory: .\ProgramFiles\TheJarProgramFolder\ It works 2) Implicit Working dir, explicit path on the program argument -jar .\ProgramFiles\TheJarProgramFolder\prog.jar It works I have never used PSTools but is it possible that if you write your params without the % symbol the relative path starts to work? Parms: /Kpushd ".\Programfiles\PSTools"
01/07/2015 Topic: Universal Unit Identifier extension Gianluca Administrator	I'm happy for the resolution. My idea regarding the different behaviour from SyMenu and Windows Command is this. When you use a relative path such as ".\config" SyMenu, at run time, resolves and replaces it with the corresponding full path for example ".\config" -> \\netshare\SyMenu\ProgramFiles\config I fear that the replace feature removes the double quotes so that your ".\config"&dir that regularly works on a command windows because it is solved as "\\netshare\SyMenu\ProgramFiles\config"&dir in SyMenu becomes \\netshare\SyMenu\ProgramFiles\config&dir which is no more an existing path because, lacking the double quotes, the last folder name is config&dir. Instead your ".\config" &dir with the space separator becomes \\netshare\SyMenu\ProgramFiles\config &dir which works because the first part is an existing path and &dir is a normal parameter. A techical digression. To make everything works, naturally I have to convert the full path again in the DOS 8.3 short format so that a folder with a space inside its name works the same even without the double quotes. For example "Program Files (x86)" become Progra~1. Don't ask me why I have to remove the double quotes... Last observation. Are you sure that you first command, the one without the space ("\config"&dir), is formally correct? I understand that it works the same in the command window but it seems to me very strange that the documentation allows you to write two parameters without at least a space separator. In my opinion it has worked by accident until now.
03/07/2015 Topic: Universal Unit Identifier extension Gianluca Administrator	B.Wettengel wrote: Only a thought: windows can be configured not to use short-names, maybe you have issues then. Oh my God.... I strongly hope that no one disables the short names paths in his system. I not even know that it could be possible. B.Wettengel wrote: @last observation[...] Well your proposal to leave it that way is my favorite :-) I did an experiment with your example and actually the behaviours of the SyMenu command and Windows command are different. SyMenu doesn't respect the /k flag probably because the redirection I do doesn't allow to open a different command. In fact what happens behind the scenes is that SyMenu redirects the command to the original Windows command shell, grabs the output and shows it on its own window. Maybe this redirection is allowed only with a single level of cmd execution. Anyway I thought that for every borderline use of the Windows command, when the SyMenu command item is not suitable for that, you have the chance to use the original Windows command. So I tried to configure a Program item (not a Windows command item), filling the path with "cmd.exe" and the program argument with your command. I don't check the Output command flag so the original Windows command is used. But even in this configuration the behaviour is quite different than the command directly put in the orginal Windows command shell: the pause /k is not observed, the new cmd is not opened. I think that I'll go deep with that configuration (Program item that launches the cmd.exe) and try to solve at least this problem. I don't think that a change with this element will break your scripts in any way because you are using the Windows command items which work in a different way.
23/07/2015 Topic: SPS builder validation fail Gianluca Administrator	Hi David. You are trying to use the US date format but, out there, other formats exist Here in Europe we use several date format and I choosed to use the dd/MM/yyyy so your date should be 23/03/2015. I supposed that the dd/MM/yyyy wasn't so immediate so I put a silver label near the date field as a reminder. If you are creating some custom SPS files remember to deploy them inside the folder [...]SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\_CacheCustom\ and not inside [...]SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\_Cache\ so when you download the official SPS suite they won't be deleted. Let me know if everything works!
03/08/2015 Topic: read-only media Gianluca Administrator	Hi Glenn. Since 3.04 version SyMenu is partially able to check if the device where it is running from is a read only one. I thought there was no need to put this information on the manual because it is a behavior where the user can do nothing. But I should specify at least that when SyMenu detects a read only device a lock icon appears on the contextual menu to indicate why several features are disabled. The next SyMenu version (4.12) will have three great new features: - an improved detection for read only device (now the check is extended to the user authorization settings too) - an improved detection for the elevated status of SyMenu - two new executors modifier The first two features are strictly tied and involve an improvement in the direction you are requesting and in many others: SyMenu on a DVD, SyMenu on a network share, SyMenu on a Dropbox share and so on. The elevation too as a big role in the SyMenu ability to write on a disk. After the next release I would like to invite you and the others that are using SyMenu in these contexts to test it deeply and report to me any strange behavior because, you are perfectly right, SyMenu assumes in a lot of moment to be able to write on its support. But with your help I will catch them all
03/08/2015 Topic: multi-column menus? Gianluca Administrator	I've never noticed this problem because I always hated the too much large menus. My menus are made by few elements, 20 at most, but I will surely study the problem you are submitting to find a solution
03/08/2015 Topic: multi-user SyMenu? Gianluca Administrator	Well I'm not sure if I've understood everything well but the reply is yes. From the next version (4.12) SyMenu switches in read only mode whenever it checks that it has no permission to write new files on its folders or it has no permission to modify its files. If I'm not wrong a Dropbox public share prevents the guests to modify existing files. In this case your configuration will become possible.
04/08/2015 Topic: multi-user SyMenu? Gianluca Administrator	I think that sharing mode 1 is quite impossible to support for SyMenu both because of the DropBox delay and because of SyMenu works as a single user application. I give you a simple example. Working as a single user application means that during the configuration SyMenu works with an in-memory folder structure image until the user saves it on the disk. But when the user saves the new configuration he could overwrite a previous modification already committed by another user. Unfortunately SyMenu is not born with a concurrent scenario in mind. I completely agree with your analysis regarding the sharing mode 2 and 3. With the next version even the sharing mode 2 will become possible.
04/08/2015 Topic: multi-user SyMenu? Gianluca Administrator	Practically you are proposing to put SyMenu in charge to manage the permissions that Windows already manages on its file system. Well I think SyMenu is yet too young to replace Windows with this task too. Do we want to leave Windows in charge to do something or not? Let's concentrate the SyMenu features, and consequentially my efforts, on its core tasks instead. If you use a file system (DB, Win or whatever) that allows you to give the write permission to certain users and only the read only permission to others, you have already a certain degree of flexibility in SyMenu too. Indeed the concurrency problem remains. If your file system isn't able to be so granular in assigning the permission you can change your approach. Just trying to give you a suggestion. Why not duplicate the SyMenu root folder and share the first one with the write enabled users (mode 1) and the second one with the read only ones (mode 2/3)? Naturally to maintain the two folders synchronized you should create a synchronization task, among the first one to the second one. I don't know if Dropbox could have problem with this further method, but you can try to create a symbolic link from the root folder instead of a real copy. In that way you have no need to synchronize the folder too. Well pay attention to the symbolic link because every file deleted on the symbolic folder is deleted on the root too. If you test these configuration I'll be very grateful to you if you can share your experience with us.
04/08/2015 Topic: multi-user SyMenu? Gianluca Administrator	To reply to your legitimate doubt (there is no documentation for this feature) I'm using the first method: I try to intercept all the write operations to avoid them when SyMenu operates in read only mode (ROM). If an error occurs because of a write operation with SyMenu in ROM, means that I have to modify the code to intercept that writing too. No write operation is allowed with SyMenu in ROM. If your need is only to force SyMenu in ROM regardless to the user currently logged, well it's a trivial feature and I can implement it yet in the next version. I can check the existence of one certain file inside the config folder (for example an empty file called READONLY). If SyMenu finds the file it slips in ROM. Why not putting the option into the configuration? Because you can't change it anymore after setting it because SyMenu will always starts in ROM and avoids further configuration. What do you think?
04/08/2015 Topic: multi-user SyMenu? Gianluca Administrator	Your second proposal makes perfectly sense but my point is to implement a workaround yet in the next version and not to give you a promise for the 2018 versions The read only mode based on the flag file is a simple and fast solution and I can implement it in hours so you'll have it for the 4.12. The security is certainly not a SyMenu problem. SyMenu is indefensible by definition because it works with files that are opened, not hidden, not crypted, not protected with password. The only way to create a not modifiable version of SyMenu is to entrust the security to Windows. And we return to one of our current topic.
05/08/2015 Topic: compact and pinned? Alas! Gianluca Administrator	My intention is to create a completely customizable menu. With this approach you can add element wherever you want and whenever you want. With this implementation the full menu and the compact one lose any meaning. But in the meanwhile we have now full and compact options and hereafter we will have expert mode and basic mode too (more or less entries). I can add the pin to the compact menu version too but I can do it only when I put my hand on the new implementation of basic and expert mode and it won't be on so early.
05/08/2015 Topic: manual is deficient in describing relative paths Gianluca Administrator	Hi Glenn. Let me tell you that your contribution to the project in these few days has been huge! I think that you are the first user to go so deep in all the SyMenu features. Thanks! Your post touches a lot of topics and it is a bit difficult for me to reply in a schematic way but I try the same (schematic posts are more useful for readers than conversational ones). Default portable program structure There is no standard in the file and folder structure for portable programs neither for the file and folder structure of installed programs indeed. The manual explains how to download, unzip, and execute SyMenu here http://localhost/UGMFree/SyMenuManual.4.12.aspx#Installation so implicitly it explains how the SyMenu file and folder structure is. Portable program nature A portable program is not a different kind of animal from a not portable program. It is only a more respectful and educated one. The only real difference is that some portable programs need highest privileges to execute but it is true for the not portable programs too. Working directory The working directory (or "Start in") is a particular attribute for Windows shortcuts. When you create a Windows shortcut the assumption is that the WD is the same as the executable directory. In this case it is useless. The attribute utility instead raises when you need to change the current working directory. I post some example for Jar programs where the executable file is java.exe but the working directory is the jar root folder. Another scenario where the WD is useful could be in command items. In all the other cases WD is useless and it is not necessary to specify "%WORKING DIRECTORY%" for every local program. Maybe your experience is different and doesn't fall in the category I mentioned. So please do some examples. Shortcut import When you import a Windows shortcut, it is unwrapped to allow SyMenu to create an item that points to the real program and not to the shortcut. You are right, the unwrapping method loses the original WD. I can add this feature. Manual lacking I will include your four sentences in the manual. You are right, there are a lot of assumptions inside the manual, but I think it is quite normal that a user finds lacking in a manual according with his experience, knowledge, skills...
05/08/2015 Topic: copy SyContainers Gianluca Administrator	No there isn't. You can clone a single item (http://www.ugmfree.it/SyMenuManual.aspx#dragAndDropClone) but not an entire container. edited by Gianluca on 07/11/2015
11/08/2015 Topic: tooltip for SyMenu system tray icon Gianluca Administrator	Hi Gleen. I don't like very much to have a different behavior among the right and left click mouse button. I'm trying to give the SyMenu users a complex program in the easier way as possible. So click with the right button or with the left one has the same effect on purpose. Instead I really, really, really like the idea of the customizable tooltip. To create a customizable feature we need to give some rules first. Your example where the SyMenu folder name or better the SyMenu full path is exposed is one rule but can't be the only one because it could be a very useful on but doesn't cover every needs. We should think about the reason for which you need a new feature and try to make it more general as possible. Let's try with a different idea. How about a free text to customize the tooltip? I should use it to differentiate my several SyMenu installations. For example "SanDisk Extreme installation" (it's my SyMenu on the pen drive), "Saturn installation" (it's my SyMenu on the fixed PC Saturn) and so on. Free text allows us to implement, in a future version, something like environment variables. For example I will able to set my free text with "Installed on %path%" to get the full path for the current SyMenu installation. But we should have other variables, something like %CPU%, %RAM%, %computername%... some are naturally standard environment variables, some others are SyMenu custom environment variables. Well if this feature will be implemented I surely need a list of environment variables to implement from you and the other users :-) In this way the basic user has a free text to fill to simply recognize his SyMenu installation, while the advanced user has an highest degree of customization. What do you think?
11/08/2015 Topic: Download page could mention Windows 10 Gianluca Administrator	Yes I'm testing W10 too in this period and it seems that SyMenu behave well in this system too. SyMenu is a good little pet, no doubt about it I will add the compatibility with W10 along with the next realease. Thanks for your report.