Try to set the initial window sizes to be big enough to show the
full welcome line in the message window when the Qt settings
(Preferences on OSX) specify Large font (Huge/Medium/Small/Tiny
seemed ok but I wasn't systematic about checking them).
While at it, I added a long comment about the status window format
and noticed a bug with experience formatting there. Again only
seemed to matter for Large font but the change to fix ignores font
size.
Plus add a couple of Qt "issues", one old and one just discovered.
When wielding a two-handed weapon, Qt's paper doll shows uwep
in the shield slot as well as in the weapon slot to reflect
that it's occupying both hands. Make the shield slot's copy
be a mirror image of the weapon's tile so that it looks less
like wielding two weapons.
Text window search behaved very strangely: at some point after
selecting [Search], entering a search string, having the string
entry popup go away, and having the search performed, but before
the result could be shown, the text window got pushed behind the
main window (map+messages+paperdoll+status). Clicking on the
main window's minimize button hid the main window and gave access
to the text window behind it. That was still functional even
after having been inaccessible; another search could be performed
and/or it could be dismissed. I still don't know what causes
that or how to properly fix it, but using raise() is a workaround
to bring it to the front where it belongs. Unfortunately you can
see it go away and come back so searching for text is distracting.
Allow <return> (when not searching) to dismiss all text windows
including RIP. Accept ctrl+[ as ESC.
Make text window searching be case-insensitive.
Searching wouldn't find a match on the first line of text. Now
it will.
This also includes an attempt to fix github issue #400 (typing a
pickup command while "things that are here" popup text window is
displayed seems to hang the program), but since I can't reproduce
that, I can't tell whether the fix works. The issue description
says that pickup started executing and "things here" couldn't be
dismissed which is different from "things here" being behind the
map waiting for it to be dismissed. The attempted fix is for text
window handling to tell Qt that it wants control of the keyboard,
so nethack shouldn't see any attempted pickup command.
Some enhancements to the widget used to get player input for
getline() and also menu search and text window search.
give caller control of [cancel] and [okay] button names;
give caller a say in how wide the string input box should be
instead of basing that on the length of the prompt string
(needs more work...);
use fixed-width font for displaying the user's input;
clean up the widget layout a little bit.
src/Makefile needs a dependency update for Qt (not included).
A couple of colors used by the Qt hitpointbar didn't look very good.
Switch to lighter green because the named value for that is too dark.
It was using the wrong value for orange; the right one isn't too dark
after all.
Take care of a Qt TODO: when using 'popup_dialog' and entering
a count during a yn#aq question, change the default answer button
from 'n' to 'y' since ending the count with <return> accepts it.
Tweak the Qt character selection widget format a bit. Forcing
the 'logo' string to be taller has resulted in stretching the
window enough to fit all the roles without a scrollbar. (On my
monitor on my OSX system, that is. It won't necessarily be an
improvement for anybody else but shouldn't break anything.)
The TODO item about making it taller so that role list fits is
still there.
For Qt's character selection widget, only allow the [Play] button
to be used when the character name field is non-blank. When that
field is blank, show "(required)" there.
Catch up with SYSCF for checking generic names like "player".
Fix up handling for some conditionally unused variables.
If player got Qt's saved game selection widget at startup but
picked "new game" there, the save file for the last character
in the list of saved games would be clobbered with the new
character's game if a save was performed. It wasn't necessarily
easy to spot because saved game selection shows the character
name from inside the file rather than from the file name, so the
next restore would look normal except for one older character
missing.
Noticed while testing: when you used the character selection
widget (either by picking "new game" in saved game selection or
because there aren't any save files), if you blanked out the
name field or it was already blanked because a generic name like
"player" had been specified, then clicked on "play", the program
would get stuck in a loop somewhere. I didn't try to figure out
where, just changed qt_askname() to revert to original name if
it ended up with a blank one.
This fixes the Qt popup widget for selecting among saved games.
The character name from each applicable save file is shown in a
button and clicking on one of those buttons restores corresponding
file. Previously all the buttons were written on top of each
other so only the final name was visible and the button for the
initial name received the click. The widget also has [quit] and
[new game] buttons.
This fixes restoring an existing save file if no character name
is supplied on the command line in the options. It does not fix
the problem where picking [new game] remembers the file name of
the last saved game in the popup's list and overwrites that file
(after requesting confirmation to do so) if/when you eventually
save. The resulting file will contain the character just saved
but be named for the earlier one. It may not be obvious because
on subsequent restores it will list names from inside the files
rather than deduce those from file names, so the clobbered/
misnamed file will just show up as the former new character.
I'm not sure whether any yn_function() calls include ampersand
in the list of acceptable choices but if any did, the button
for that character would have shown up blank. (Clicking on it
would have successfully produced '&' as player's input though.)
Add support for the 'hitpointbar' to the Qt interface. Rather
than rendering the status title (name+rank or name+monster_species)
using inverse video for leading substring to produce distinct left
and right sides, draw a horizontal bar above that field.
The left portion (current health) is thicker and uses red for <10%
or <5hp, orange for <25% or <10hp, yellow for <50%, green for <75%,
blue for <100%, and black for 100%.
The right portion (missing maximum health) is thinner and runs
from white (paired with red), light gray (paired with orange),
dark gray (with yellow), plain gray (which turns out to be darker
than dark gray, with green), dark blue (with blue), and black (but
black is never shown for injury portion because that's suppressed
when at full health).
Qt already supports a square frame around the hero's map tile that
changes color according to health. Turning the hitpointbar option
Off or On has no effect on that.
When we save gamestate as part of making an insurance snapshot, we will
save message history which will clear toplines but leaving window state
in tack including the need for more.
When fuzzing, we would increment ttyDisplay->inmore but then prematurely
exit more() leaving ttyDisplay->inmore set.
Under various conditions, we can request to remember the topline when
the topline had not yet been acknowledged leaving toplin state in an
inappropriate state.
When the game windows were initialized, the anhk icon for alignment
was centered relative to Lawful/Neutral/Chaotic label but during
the first status update it noticeably shifted left. Non-blank
hunger or encumbrance states could change from centered to left
justified when they were present and the icon was replaced. Oddly,
resetting the 'centered' attribute for the widget wasn't sufficient
to fix this. Running the resize code for that widget did. Another
case of trial and error to make things work the way they ought.
Also, don't highlight a change in alignment or dungeon location as
"got worse" if the internal numeric value went down instead of up;
always highlight as "got better" for those two fields. There ought
to be a third choice for just "changed" but that would have been
more complicated.
Three-way swap: move blindfold to alt-weapon slot, alt-weapon to
quiver slot, and quiver to former blindfold slot. Affects first
and third rows of the 6x3 grid.
Before |After
x H b | b H q
S a w | S a w
G C q | G C x
[x=alt-weapon, H=helmet, b=blindfold, S=shield, a=amulet, w=weapon,
G=gloves, C=cloak, q=quiver; bottom three rows not changed so not
shown.]
New for Qt, moving the mouse over one of the slots in the paperdoll
inventory subset and letting it pause there will use Qt's tool tip
mechanism to give a description of the item under the pointer, if
there is one, or of what the slot would contain when there isn't.
So "e - uncursed leather gloves (being worn)" or "no gloves" when
the pointer is over the glove slot. If you do something with the
keyboard to make the paperdoll change while the mouse is still
hovering, you'll need to move the pointer slightly to have Qt
recheck for tool tip at that spot. It may be feasible to force
an immediate update, but I'm satisfied with how it's working.
Interestingly, you can move pointer and hover while yn_function()
has asked you to pick an inventory item and is waiting for an
answer. Mostly useful for Take-off/Remove or #adjust.
The toolbar contains do-Again, Pick up, Drop, Kick, Throw, Fire,
Eat, and Rest. Insert Search in front of Rest since it's useful
in its own right and some players prefer it even when resting.
Includes a new 12x13 icon; a tiny magnifying glass shown straight
on is something I can manage.
Both the toolbar button for pick up and the action menu entry for
pick up were labeled "Get". That's confusing for an experienced
player who is looking for "Pick up". Rename both of them.
Also, consolidate repetitive code used to set up toolbar buttons.
When qt_yn_function() or qt_more() is asking for a single character
response, typing anything will cause the prompt line in the message
window to stop being highlighted. If they reject what's been typed,
they beep (--More-- doesn't start beeping until second rejection);
change both of them to also rehighlight the prompt line to give a
visual indication that the question/acknowledgement is still being
asked.
Prevent a small inventory menu as the first one shown from forcing
all subsequent ones from being the same short height by forcing it
to have room for at least 15 lines. Temporary hack until someone
figures out why resizing the reused WIN_INVEN isn't working.
Does not affect non-inventory menus which get created on demand and
destroyed when done so don't need to change size to fit different
contents.
Clicking on the status panel runs ^X to show character and status
information without abbreviations. The code needed is identical
to what's now used for clicking on the paper doll inventory panel
except for the command to execute.
Clicking on the paper doll inventory subset window will cause
the '*' command (#seeall) to execute. They convey the same
information (unless multiple leashes or multiple light sources
are in use; seeall lists all of them instead of just the first
of each) but the doll shows the info with a small grid of map
tiles and seeall shows it with an inventory display of worn and
wielded items plus tools in active use.
Ideally it should show information about a specific item as a
"tool tip" when the mouse hovers over one of the doll slots.
I don't know whether I'll ever attempt to tackle that or even
if that's feasible with Qt. Perhaps use right click instead.
Don't allow the user to construct a count value when operating on
a pick-none menu where counts aren't meaningful. Unfortunately
that can still be done on pick-one or pick-any menus which don't
happen to have any entries where a count is applicable.
Allow a count to be optionally started with '#'. Note that if
there is an entry using '#' for the selector letter (probably
inventory that has something in the overflow slot), typing '#'
will select the entry instead of initiating a count.
Flail about a bit trying to get menu size correct--failed on this
front.
Remove a 'TODO' for once. Have the popup that's used to accept the
target string--after clicking on [search] or typing ':' to initiate
menu search+select operation--force keyboard focus to itself. Menu
searching worked without this, but only if you manually clicked on
the search popup prior to typing the target string. Failure to do
so resulted in typed characters being used to select menu entries.
roll parts of pr385 into source tree
This does not take the PR as is.
Unlike the PR, this streamlines and minimizes the integration somewhat:
- use hints/include mechanism instead of creating alternative
Makefile.dat, Makefile.src, Makefile.top, Makefile.utl in sys/lib;
those would have been a maintenance nightmare.
- don't have alternative mkmkfile.sh and setup.sh in sys/lib.
- sys/lib/libnethackmain.c differed from sys/unix/unixmain.c by
very little, so just place a small bit of conditional code at the
top of sys/unix/unixmain.c instead.
- changed the conditional code bits from __EMSCRIPTEN__ to
CROSS_TO_WASM.
- You should be able to build the wasm result by:
cd sys/unix ; sh setup.sh hints/linux.2020 ; cd ../..
make fetch-lua (<-one time)
make WANT_LIBNH all
- You should be able to build LIBNBH by:
cd sys/unix ; sh setup.sh hints/linux.2020 ; cd ../..
make fetch-lua (<-one time)
make CROSS_TO_WASM=1 all
As it is currently coded, winshim.c requires C99.
When 'popup_dialog' is set, the Qt interface uses a popup window
for yn_function() calls and the dialog has a list of buttons, one
per potential choice. It has been handling "yn?" and "ynq?"
questions differently from general request-one-char prompts, using
buttons "Yes", "No, and "Cancel" instead of showing individual
letters. This extends that to "ynaq" and "yn#aq" questions and
labels 'q' reply as "Stop" instead of "Cancel" for those. Also,
when player uses keyboard instead of mouse to answer, allow 'c'
as well as 'q' for cancel ones, 's' as well as 'q' for stop ones.
Prompt Buttons
yn [Yes ][ No ]
ynq [ Yes ][ No ][Cancel]
ynaq [Yes ][ No ][All ][Stop]
yn#aq [Yes ]Count:______[ No ][All ][Stop]
rl [ Left ][Right ] //unchanged; included for completeness
(For contrast, when something specifies "ny" as the acceptable
choices, the buttons will just be [n][y]. Prompts for choosing
from a list of inventory letters can't accidentally match these
special cases as long as they're specified in alphabetical order.)
The failing Travis build issued about 500 lines of diagnostics
when complaining about one line of the source. It compiled ok
for me but I use older versions of Qt library and C++ compiler.
For Qt with 'popup_dialog' On, fix number entry when user types
a digit (or '#') directly onto the dialog instead of clicking
inside the Count box and then typing. Before, that first typed
digit was starting out as selected, so typing the next digit
replaced the selection instead of getting appended to the string
of digits being constructed. Fixed by moving the relevant code
to the KeyPress handler instead of re-executing the dialog.
Also, if a keypress is just a modifier, ignore it. The next
event should be the actual character. Prevents treating <shift>
(and <caps lock>!) as useless dialog responses. Before this,
attempting to type '#' to initiate a count wouldn't work because
the <shift> part of shift+3 ended the dialog. Now '#' works
(and is still optional; starting with a digit suffices).
Support MSGTYPE=stop by having qt_display_nhwindow(WIN_MESSAGE,TRUE)
issue a tty-style --More-- prompt. For popup_dialog Off, the prompt
gets appended to the most recent message; for popup_dialog On, it is
issued via a popup and not displayed in the message window.
It accepts <space>, ^J, ^M, and ^[ (ESC) to dismiss. There's no way
to dismiss it with the mouse (for !popup_dialog) which might need
some fix....
Several adventures along the way. The '^C-in-parent-terminal triggers
infinite loop repeatedly complaining about "event loop already running"'
is now a one-shot complaint. It isn't fixed but the severity of
having it happen is greatly reduced.
Some changes to the YnDialog widget used when popup_dialog is On.
If a button is labelled with a space, it just looks like an
unlabelled button. Switch to "Spc" for space, "Ent" for \n and
"Ret" for \r. (The last two aren't completely logical but I
haven't seen any dialogs that need them and they'll be better
than "^J" and "^M" if there are such.)
For yn#aq dialogs, preload a grayed-out "#" in the count widget.
Just for show; has no tangible effect.
The count widget should return long rather than plain int.
Replace the blank placeholder icon with individual placeholders
for Stone, Slime, Strngl, Deaf, Lev, Fly, and Ride. They're just
40x40 tiles showing solid color (different for each) holding white
block letters spelling the condition. For the first four of those,
the text runs from upper-left to lower-right, for Lev and Fly the
text runs from lower-left towards upper-right, and for Ride it's
horizontal. Not particularly exciting but better than blank. We
still need real artwork to make them be similar to the older
conditions.
Also moves the two petmarks and the pilemark from qt_xpms.h to
qt_map.cpp. The marks and the assorted status icons are all
static arrays, and including that header in two source files
meant that they were all duplicated unless the compiler or linker
was smart enough to discard the unused ones.
For Qt, experience points weren't shown when enabling 'showexp'
option because they were conditional upon '#if EXP_ON_BOTL'. That
got eliminated prior to 3.6.0 so wasn't defined for qt_stat.cpp.
When displayed, show Exp as Level:Xp/Exp instead of as a separate
status field. This has the intentional side-effect of omitting it
when hero is polymorphed and status shows HD instead of Xp.
Label the six characteristics in mixed case instead of all upper
case: Str, Dex, and so forth.
Any key bindings in player's run-time config file will already be
in place by the time the Qt menus are constructed. Those menus
will use the new key assignments rather than the defaults, so not
a bug.
