UDC: New

[admin]

Again, all in order to be able to organize things better, and also create appropriated menus to be poped up...

Okay, now a have a little (but, of course, revolutionary ) idea:
- new proprietary "file type" *.xypop
- XYPOP files are to be placed inside XY's app dir.
- they contain commands (caption | command in script syntax)
- one command per line, for example a small two commands file could look like this:

Code: Select all

Append item's modified date | renamebatch *-<myyyymmdd>
Convert to FLV | renameext flv

On startup, XY looks for any XYPOP files. When found they are added to some menu, maybe a new one "Popups". The XYPOP file names are taken as the menu item captions.

Example:
- exists file Copy Commands.xypop
- item "Copy Commands..." is added to the "Popups" menu.
- now when you click (or KS) "Copy Commands..." a menu is popped up containing all the commands that are listed in Copy Commands.xypop

Nice advantages of this idea:
- the app does not get any heavier (only a little bit) or slower even with hundreds of new custom commands
- you can exchange XYPOP files between users like plugin-command-sets!
- there could be a batch option: trigger all commands in a XYPOP file one after the other.

[jacky]

Yes, I'm loving this idea !! This would be exactly what I'm looking for : my own set of commands organized in menus, an option to trigger all commands at once, ... perfect!

And indeed, while UDC have a GUI this feature would not require one since using external text files, which would be very small obviously and the ability to be exchanged as you mention is a great addition too!

Tiny remarks :

- I wouldn't choose "Popups" for the new menu, maybe more "Scripting", "Scripted UDC" or something like that. After all, one could use this feature without ever assigning a KS to popup a menu (Besides, "script" = power, while "popup" = annoying advertisement. In a way.)

- A way to create/edit/delete such files from XY might be nice. Maybe through LM or something... ?

- I would create a subfolder with the same name as the menu, eg. "Scripting", for those files. Would make things easier to deal with I think.

- Yeah I'm loving this idea

[admin]

Yes, I'm loving this idea !! This would be exactly what I'm looking for : my own set of commands organized in menus, an option to trigger all commands at once, ... perfect!

And indeed, while UDC have a GUI this feature would not require one since using external text files, which would be very small obviously and the ability to be exchanged as you mention is a great addition too!

Tiny remarks :

- I wouldn't choose "Popups" for the new menu, maybe more "Scripting", "Scripted UDC" or something like that. After all, one could use this feature without ever assigning a KS to popup a menu (Besides, "script" = power, while "popup" = annoying advertisement. In a way.)

- A way to create/edit/delete such files from XY might be nice. Maybe through LM or something... ?

- I would create a subfolder with the same name as the menu, eg. "Scripting", for those files. Would make things easier to deal with I think.

- Yeah I'm loving this idea

All agreed.

Just to make sure: the commands themselves can not have individual KS since they won't have a fixed place in the main menu.

Main menu caption "Scripts"
One level of menu items:
- Copy Commands... (can have KS)
- Blah Commands... (can have KS)
- etc. Commands... (can have KS)

Clicking "Copy Commands..." will popup a menu at mouse cursor position with your commands (but NO KS).

[serendipity]

WoW!! these are truly revolutionary ideas. can imagine the extensibilty and innumerous possibilities.

[jacky]

Just to make sure: the commands themselves can not have individual KS since they won't have a fixed place in the main menu.

Yeah, I suspected that was your idea, I'm guessing for performance issue.

I think I would be fine with this, and most people should be too. The only reason it could be a little of a downer would be if one command that someone would like to use required such a script, only because it's not available as UDC. That would then mean one KS plus a click/Enter

But AFAIC & can see, it should be all good.

[admin]

Just to make sure: the commands themselves can not have individual KS since they won't have a fixed place in the main menu.

Yeah, I suspected that was your idea, I'm guessing for performance issue.

I think I would be fine with this, and most people should be too. The only reason it could be a little of a downer would be if one command that someone would like to use required such a script, only because it's not available as UDC. That would then mean one KS plus a click/Enter

When I add the "Script" category to UDC you can put that command as well there. The syntax will be identical.

[Linkaday]

What a great firing, jacky, what a great idea, Don - i can only emphasize serendipity's WOW

[admin]

I would create a subfolder with the same name as the menu, eg. "Scripting", for those files. Would make things easier to deal with I think.

Then of course, the files could be *.txt, which would make editing much more comfortable... So let's forget about *.xypop...

[jacky]

When I add the "Script" category to UDC you can put that command as well there. The syntax will be identical.

Oh, well then no need to even think about it

Then of course, the files could be *.txt, which would make editing much more comfortable... So let's forget about *.xypop...

Well, my idea wasn't so much about that part (XY could come with a PFA "xypop>notepad" ; or "xyscript>notepad") but to access the files without having to go there each time, which could be a little annoying.

Even a way to trigger whatever is associated with those files (whatever their extension will be) from XY without having to go there would be nice I think.

Given what we're talking here, even something as simple as holding Ctrl while clicking on the menuitem would trigger the "open" command for that file would be enough, except that there's no ways to create/delete with that...
Although, holding Shift could popup a "Are you sure you want to delete this script file ?", and there could be an item "Create new..." that would ask for a name, then create an empty file by that name & open it.

[jacky]

- Thanks for adding "To Clipboard|Item Base" !

- Just bumping the whole <srcXXX> thing back, in case it got lost with more recent development ("Script" files)

- OT: The new Properties icon on Toolbar could use a context menu I think, listing all of the Panel's tab...

[admin]

Ok, so I have a problem : apparently I do feel like total nonsense makes complete sense in my mind

Code: Select all

    * UDC | New: the following variables refer to the Clone source if 
      there is one given, and not to the currently focused item: 
        <curtitle> 
        <curbase> 
        <curext> 
        <curver> 
        <myyyymmdd> 
      The variable name "cur..." might be confusing here, but the 
      behavior is expected and the logic is clear. If you create a new 
      file that's a clone of a certain other file, it would be total 
      nonsense to name that new file based on the name, date, or version 
      of the currently selected file! 

I do not agree this. I do see how this could be used and why it's cool, I do. But I also believe that on other behaviors to have those variables to relate to the focused&selected item would be expected behavior.

For instance, let's say I download lots of soft and once I tested them and whatnot, I like to create a little text file for each of them with my thoughts on it, maybe the URL where I found it, etc

For this, using a UDC: New with "<curtitle>.txt" for example could be great. But now, imagine I want such a text file to follow a predefined structure, and in order to make my life easier, instead of havig an empty file created I make a template and define it as clone.

Well, that was perfect until this latest change, because now my file is called "template.txt.txt" each and every time, which is nonsense !


So I would say that it would be best to let those variables to relate to the currently focused&selected item, it's simpler & avoid any confusion, and because to have variables relating to the cloned item might be good in another use of that feature, create new variables :
<srctitle>
<srcbase>
<srcext>
<srcver>
<syyyymmdd>

(I used src cause it relates to the source item, but maybe cln for clone(d) might be better...)

Ok, I'm done. I hope you will agree

Finally did it! Just changed the last one to:
<srcmyyyymmdd>