Currently in MRT there are 6 buttons for name for inserting placeholders. Instead, one can be changed to a pop-up menu, offering all available placeholders (as plug-in button does)
I made a screenshot to make myself clear. Please note that this is only explanatory screenshot, with placeholders and explanation taken from help file, not necessearily the way it should be, and there is only shown submenus for four tems: current name, counter, date and case.
This way all placeholders are there ready for insertion, without need to go to help file each time a rarely used placeholder is needed. Also will decrease novice user questions about how to rename files like this or like that.
So, what do you think?
suggestion for button improvement in MRT
Moderators: Hacker, petermad, Stefan2, white
-
SanskritFritz
- Power Member
- Posts: 3693
- Joined: 2003-07-24, 09:25 UTC
- Location: Budapest, Hungary
-
StickyNomad
- Power Member
- Posts: 1933
- Joined: 2004-01-10, 00:15 UTC
- Location: Germany
Re: suggestion for button improvement in MRT
Looks good!solid wrote: So, what do you think?
Stitscher
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
I was always saying that MRT Interface is disaster.
I even have a better idea. Tree view on the left with categories of default and user presets (this makes all controls fade away). The treeview can have 2 parts - 1 for addition of basing building elements, the same as your menu and second part that will hold presets witch will on click replace values of all 3 inputs (mask, search and replace).
This is the screenshot. I think this is the way to go.
Colored part of the window is place for splitter ! It is to hide/show tree view.
http://img182.imageshack.us/img182/5072/clipbu9.png
I even have a better idea. Tree view on the left with categories of default and user presets (this makes all controls fade away). The treeview can have 2 parts - 1 for addition of basing building elements, the same as your menu and second part that will hold presets witch will on click replace values of all 3 inputs (mask, search and replace).
This is the screenshot. I think this is the way to go.
Colored part of the window is place for splitter ! It is to hide/show tree view.
http://img182.imageshack.us/img182/5072/clipbu9.png
Habemus majkam!
-
ghisler(Author)
- Site Admin
- Posts: 50386
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
The idea of the buttons is to give beginners a hint on how to use placeholders. Pros type these by hand. 
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
2ghisler(Author)
Well, pros or not pros, what are chances of implementing?
2majkinetor !
That's a totaly new design of MRT. It is nice, but defenitely we need first some fetures implemented before any redesign of UI, like plugins placeholders in the replace box, and possibility to make dirs.
And only adding extra buttons is not that much work as complete redesing IMHO.
Well, pros or not pros, what are chances of implementing?
2majkinetor !
That's a totaly new design of MRT. It is nice, but defenitely we need first some fetures implemented before any redesign of UI, like plugins placeholders in the replace box, and possibility to make dirs.
And only adding extra buttons is not that much work as complete redesing IMHO.
The problem is that as soon as you have "your" dropdown list, there will be no GUI changes anymore for years...
Dropdown lists are for sure better than the state right now but they are counterproductive when selecting more than one placeholder:
1. Press button
2. Select an entry
3. Popup closes.
Again and again and again...
You can see the result of "features first, GUI later" approach when you look at the MRT or the custom column configuration. It can be used, yes, but it's far from being comfortable.
Icfu
Dropdown lists are for sure better than the state right now but they are counterproductive when selecting more than one placeholder:
1. Press button
2. Select an entry
3. Popup closes.
Again and again and again...
You can see the result of "features first, GUI later" approach when you look at the MRT or the custom column configuration. It can be used, yes, but it's far from being comfortable.
Icfu
This account is for sale
-
majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
Its not that hard to change the gui to one I suggested.
Far from that, its probably easier to implement than your facelifts.
One other things, n00bs don't use MRTs. Its cuz of ugly interface and scary buttons with hierogliphs on them. I bet easier interface will attract more n00bs.
And its not pull down menu. Its a tree.
.
The point is, that there is alternative way to improve missing things in TC. I know Ghisler doesn't support "nasty hacks" but who cares, lets do it anyway. Interested people can send me e-mail
Why I prefer AHK for this
I like interpretators. They are slow, but you dont have regular problems like with compilers. That is pure text, it will surely work without depending on other things, anybody can read it, understand it, change it on the fly, and do whatever it wants to the code to fit its weird needs if case requires. Using C to create the same is no good - non programmers will not care, programmers will have hell trying to compile it in other versions of IDEs etc (for example, even the author of DM2 didn't succeded to compile DM2 in VS7 as it was created in VS6 !!!, and that is not acceptable - nobody uses VS6 any more).
AHK is good choice as it is the fastest interpretator I know for now. In C million dllcalls take 4 seconds on tested environment, in AHK 8 secs, in AutoIt 60 in VBScript 44 etc...
AHK is also only 1mb in size so if new version breaks the scrpt the one can always revert to old one and continue to work.
The consequences of AHK MRT will be usability of MRT in entire system (explorer Open/save, anywhere ....)
Far from that, its probably easier to implement than your facelifts.
One other things, n00bs don't use MRTs. Its cuz of ugly interface and scary buttons with hierogliphs on them. I bet easier interface will attract more n00bs.
You are amazing!Sir_Silva wrote:Meaning u want all 6 Buttons in 1 PullDown Menu clearly states u dont have a clue what [N#-#] does....
And its not pull down menu. Its a tree.
That was original idea. IT can be done in AHK as complete replacement for MRT as it now supports more advanced regexp then TC. Connecting TC and AHK can be done using %L. Extracting file names, extensions and reanges from filenames is peace of a cake in AHK. So.... again and again, we just need more coders - I can't do everything myselfIf you implement that like F4 in Opera (show/hide to not waste horizontal space) I would support it.
.The point is, that there is alternative way to improve missing things in TC. I know Ghisler doesn't support "nasty hacks" but who cares, lets do it anyway. Interested people can send me e-mail
Why I prefer AHK for this
I like interpretators. They are slow, but you dont have regular problems like with compilers. That is pure text, it will surely work without depending on other things, anybody can read it, understand it, change it on the fly, and do whatever it wants to the code to fit its weird needs if case requires. Using C to create the same is no good - non programmers will not care, programmers will have hell trying to compile it in other versions of IDEs etc (for example, even the author of DM2 didn't succeded to compile DM2 in VS7 as it was created in VS6 !!!, and that is not acceptable - nobody uses VS6 any more).
AHK is good choice as it is the fastest interpretator I know for now. In C million dllcalls take 4 seconds on tested environment, in AHK 8 secs, in AutoIt 60 in VBScript 44 etc...
AHK is also only 1mb in size so if new version breaks the scrpt the one can always revert to old one and continue to work.
The consequences of AHK MRT will be usability of MRT in entire system (explorer Open/save, anywhere ....)
Habemus majkam!