byuu wrote:
But is it 100% obvious to double-click entries?
In the absence of buttons, yes. With them, no.
byuu wrote:This is why the cheat editor has a toggle button, as well.
This was going to be in my next post. I'd like to see the toggle button change to an "Edit" button. Currently, there is no way to easily edit an entry, you have to delete and add a new entry. If that happens, there is also no reason not to simply make description the sort method by default. Anyone who wanted to customize the order otherwise could add numerical prefixes to their descriptions quite easily because of the edit feature.
byuu wrote:
But is it 100% obvious to double-click entries?
In the absence of buttons, yes. With them, no.
No, the conclusion is that you have to doubleclick them; it's not obvious without some thought.
I generally prefer double clicking, but there is a use for the toggle button if byuu allows multiple entries to be selected at the same time. i.e. via Ctrl + A, Ctrl + left click, Shift + left click, Ctrl + arrow key, and Shift + arrow key.
creaothceann wrote:
No, the conclusion is that you have to doubleclick them; it's not obvious without some thought.
It's obvious because there's nothing else to do that makes sense besides enter (which works as well). What exactly was it that you thought people were going to try first? Voice recognition? Caps lock?
I generally prefer double clicking, but there is a use for the toggle button if byuu allows multiple entries to be selected at the same time.
That would confound entry bar behavior which can only show one selection.
creaothceann wrote:No, the conclusion is that you have to doubleclick them; it's not obvious without some thought.
It's obvious because there's nothing else to do that makes sense besides enter (which works as well). What exactly was it that you thought people were going to try first? Voice recognition? Caps lock?
Verdauga Greeneyes wrote:What's entry bar behavior?
The bar at the bottom in which you enter codes and descriptions. Its behavior will have to change to display an entry's info upon selection, or else you couldn't edit the information. This does not affect the add or delete functions.
creaothceann wrote:Posting on the ZSNES board.
I disagree, and I allow for a fair amount of stupidity. There isn't a chance in hell someone would not try enter or dbl click on selectable entries before going through the trouble of registering on a board. Would only having to click an entry again at any point after selecting it satisfy you?
FitzRoy wrote:The bar at the bottom in which you enter codes and descriptions. Its behavior will have to change to display an entry's info upon selection, or else you couldn't edit the information. This does not affect the add or delete functions.
Hmm.. in that case it would make sense for those options to be grayed out. Either that or for them to effect the 'highlighted' entry (i.e. the entry with the dotted line around it. I'm not sure this exists on Linux though, thinking back to one of byuu's posts)
Or, you know, you could just have a one-time pop-up telling users to dbl click entries to activate them. Even that would be better than permanent buttons taking up space and making people default to a slower method when a faster way is possible. Why on earth does this have to be so difficult? I also put a cohesive argument together for reducing the two-line radio box down to one line, at ZERO cost, and it was completely ignored. I can't keep doing this.
Here's an even better idea if possible, it would wipe out all buttons and not require an informational pop-up for anything but the cheat section. Any time an entry is left or right-clicked, a "right-click menu" comes up with the following options for each section:
Input (On Selection)
-------
Assign
Unassign
Input (On Nothing)
------------
Cheat Codes (On Selection)
-----------------------
Toggle
Edit
Add
Remove
Cheat Codes (On Nothing)
-----------------------
Add
Advanced (On Selection)
-----------------------
Modify
The input boxes would stay, but would be grayed out until one of these actions is made, at which point a cursor will appear in the box. Once a user modifies the value and hits enter, it applies or moves to the second box. This scheme would remove 7 buttons, 1 checkbox, and be faster for users.
I must say a context menu with no other way to visually manipulate data is a bad idea. GIMP tried to run that setup for years and people got extremely confused by it.
Context menu might be a good idea for advanced settings, but I think the current scheme more or less work fine. Why not stop beating this dead horse and let Byuu do as he wishes with it?
If you want to delete a menu item, its possible using RemoveMenu(). I don't know about hiding/unhiding. Why don't you just gray/ungray it out?
Let's say you can control the video driver without a restart one day.
Would you want the point / linear settings to be grayed out, rather than invisible, when in DirectDraw mode? End users usually can't tell why something is grayed out, so it's just an annoyance to them to be visible at all.
Yeah, if it's not possible, I'll just have to keep lists and dynamically rebuild the entire menus whenever hide()/show() is called. Fun.
Re-inserting will be harder and will require you move each menu item down two places.
One possible solution to this problem is to move the point/linear options to the bottom of the menu. This way you will just need to append the items when you want it displayed and will be more easier than moving-inserting.
wertigon wrote:I must say a context menu with no other way to visually manipulate data is a bad idea. GIMP tried to run that setup for years and people got extremely confused by it.
Never used GIMP, doubt it was the same behavior. But you're right, I concede to the crystal ball without trying it.
byuu wrote:End users usually can't tell why something is grayed out, so it's just an annoyance to them to be visible at all.
But they can tell why something is missing entirely?
Random question: can someone explain the difference between the D411, D411A, and D411B lockout chips? Does CIC stand for Circuit Identification Code?
I know they're all NTSC, but different games use different variants and the variant isn't reflected in the PCB serial like the memory address decoders are. So if we're ever going to have a true pcb format, I'd like to know if I should be documenting this for every game I redump.
