[interface] move position of abilities popup

[white_haired_uncle]

Consider a unit which has too many abilities (or the names are too long) to be displayed on the right hand unit panel in the main gui, and you hover over the last (possibly partially) visible item or the ellipsis.

If the length of the list of all abilites info is relatively short, the popup is positioned at the top of the screen.

If the length of the list is rather log, the popup is positioned with the top at roughly the same y as the abilities list.

This seems rather odd to me, shouldn't the one that's not going to fit be given more space, not less?. It almost seems like maybe there's a '<' where a '>' was intended in there somewhere. I'd try to figure this out for myself, if someone could point me in the right place to start looking.

Thanks

[Pentarctagon]

I don't have an answer for where you could look, though I can say that anything related to why particular UI element gets sized or placed a certain way is a rabbit hole.

[Ravana]

It looks quite bad, but sx has figured out how to make more space for them. Something like menu item to temporarily give more space for sidebar might help.

[white_haired_uncle]

Looks like data/themes/default.cfg [unit_status] might be a place to start

Or src/reports.cpp:

Code: Select all

               
tooltip << _("Ability: ") << "<b>" << display_name << "</b>";
 if(!active[i]) {
             tooltip << "<i>" << _(" (inactive)") << "</i>";
 }

 tooltip << '\n' << description;

 add_text(res, str.str(), tooltip.str(), "ability_" + id + base_name.base_str());

I was wrong about the problem description. It's not just abilities, it also applies to unit type. And when I said the tooltip starts at the top of the screen, I was wrong, that is just how it happened for one unit. Correction:

If the tooltip will fit on the screen (or perhaps in the allocated space, probably more likely), it is positioned such that the bottom is just about the current mouse position.

If the toolitp will not fit on the screen, it is positioned such that the top is just below the current mouse position.

Or perhaps something like,

Code: Select all

if (tooltip.rect.h < mouse.y) then  // height of tooltip is small enough to fit entire tooltip above current mouse position
   tooltip.y=mouse.y - tooltip.rect.h  // place tip so that bottom is at mouse.y
else
  tooltip.y=mouse.y  // place tip so that top is at mouse.y

So it seems my quest is to figure out how tooltips are positioned in general. Or at least for this panel.

But hey, I took a C++ 101 class in college (right around the same year I first saw an inet addr that started with "www"), how hard could this be?

[Ravana]

I added menu item to swap to theme with much more space for abilities and back. https://github.com/ProditorMagnus/Agele ... 7e5ec83826

I also tried to change tooltip width, but did not find how to do that.

[white_haired_uncle]

Looks like I found it. Just moving the tooltip doesn't seem to be enough (at least the way I tried it), now it appears to start well off the top of the screen, so I only get the last portion of the abilities description list ending at current mouse position, but at least I know where it decides if the tooltip should go above or below.

src/tooltips.cpp

Code: Select all

     
     static void show_tooltip(const tooltip& tip)
{
...
       //see if there is enough room to fit it above the tip area
        if(tip.rect.y > rect.h) {
                rect.y = tip.rect.y - rect.h;
        } else {
                rect.y = tip.rect.y + tip.rect.h;
        }

Seems to me this should be expanded.

If fits_above // put above
elsif fits below // put below
elsif fits on screen rect.y=(screen.h - rect.h)/2 // centered on screen
else rect.y=0 // show what you can. Maybe do other stuff like increase rect.w by a little like rect.w=1.1*(rect.h/screen.h)

[gfgtdf]

Makes sense, do you want to open a pr ?

[Ravana]

Until rect.w=1.1*(rect.h/screen.h) part it looks understandable and good improvement.

[white_haired_uncle]

pr?

thanks

Code: Select all

rect.w=1.1*(rect.h/screen.h)

What I'm trying to say there is that if the rectangle doesn't fit because of height, increase the width by approximately the same ratio. So the rectangle has the same area, just different dimensions. rect.h/screen.h is supposed to be the ratio of needed size (height) to available size on the screen. The 1.1 factor is because, I assume, we can't just alter the width in the same proportion as the height is lacking because words might not line up (need a little extra space so words don't wrap).

I tried to see if I could do that, but I can't seem to adjust the width.

[gfgtdf]

pr?

Pull request, https://github.com/wesnoth/wesnoth/pulls

[white_haired_uncle]

Pull request was the only thing I could come up with for pr, but I thought that meant I'd actually be submitting code, which is probably not a good idea. I don't really understand what's going on here, or what implication these could have elsewhere.

thanks

[Ravana]

Overflow to bottom of screen is more acceptable than overflow to side of screen for cases where even full screen is not enough.

[white_haired_uncle]

Code: Select all

        if(tip.rect.y > rect.h) {  // there is enough room to fit it above the tip area
                rect.y = tip.rect.y - rect.h;  // place tooltip above
                rect.x = tip.rect.x - rect.w;
        } else if ((rect.h + tip.rect.y + tip.rect.h) <= area.h) { // there is enough room to fit it below the tip area
                rect.y = tip.rect.y + tip.rect.h;  // place tooltip below
                rect.x = tip.rect.x - rect.w;
        } else if (rect.h < area.h) { // there is enough room on the screen
                rect.y = (area.h - rect.h)/2;  // center tooltip on screen vertically
                rect.x = tip.rect.x - rect.w;
       } else if ((1.1 * rect.w * static_cast<float>(static_cast<float>(rect.h) / area.h)) < (tip.rect.x-rect.w)) { // will fit on screen if we resize  
                rect.w = 1.1 * rect.w * static_cast<float>(static_cast<float>(rect.h) / area.h);  // grow width, shrink height to fit
                rect.x = (area.w-tip.rect.w-rect.w);
                rect.h = area.h;
                rect.y = 0;
        } else {  // tooltip won't fit on screen, just do our best
                rect.x = 0;
                rect.y = 0;
                rect.h = area.h;
                rect.w = area.w;
        }

This is what I came up with. It's close, but the tooltip window doesn't change size. I figured I needed to do something extra to resize the window vs just moving it, as I can move it around all I want but it doesn't get any wider, and got about this far

Code: Select all

???->set_size(rect.w, rect.h);

This actually seems to almost work. Some text in the tip is running off the right side of the screen, while other text remains at the previous width (I want it to readjust to the new tip size). Seems like kind of a hack, but it does resize.

Code: Select all

        font::remove_floating_label(tooltip_handle,0);

        flabel.set_width(rect.w);
        flabel.set_height(rect.h);

        tooltip_handle = font::add_floating_label(flabel);

Unfortunately, I've just found out I'm working off a false premise. I assumed that the initial rect.h was just sized to the amount of data, and that when it was much larger than the screen size the rectangle and its included text were simply running off the bottom of the screen. Playing around with different resolutions, I find that rect.h is never more than a touch larger than the screen height (in 1920x1012, rect.h = 1028, but when I flip down to 1024x768 rect.h=775). I noticed there's a flabel.set_width(text_width), don't know where text_width comes from, I rather hoped I could get away with adding flabel.set_height(text_height) to initially size the rect to the data, but no. [Clue: flabel.set_clip_rect(area); ???]

[gfgtdf]

Pull request was the only thing I could come up with for pr, but I thought that meant I'd actually be submitting code, which is probably not a good idea. I don't really understand what's going on here, or what implication these could have elsewhere.

thanks

Noone is forcing you but i still want to say:

1) From what i see here you are figuring out how the code works just like anyone form the dev team would. True, there are parts of the code where we have people that know it very well where those can do it much easier and people would prefer to have it done "their way" but i'm pretty sure that this is none of them.
2) and prs are reviewed if there is something obviously wrong with it or when someple see something that wouldn't see, people will say that (and reject it until it was changed),
3) also when talking about the wesnoth c++ code you'll get more feedback there than here.
4) And lastly doing a pr will of course increase the chance that this suggested change is actually happening.
5) You can start simple for example by just doing the x position adjustment, and not doing the "hacky" width adjustment.

[white_haired_uncle]

Well, I'm rarely one to turn down good advice, so thanks. I pulled out my old C++ book which has a big note on it that it "Covers Draft ANSI C++", so it shouldn't be too out of date, and I've started working my way through an SDL tutorial. And on a hunch I did some searching on a different approach to finding the required size for the data which turned up something promising:

Code: Select all

int TTF_SizeUTF8(TTF_Font *font, const char *text, int *w, int *h);