[patch] No more rezooming for viewports (world_view_t)

[knightly]

The attached patch eliminates rezooming of graphics inside the viewports -- viewport graphics will always be of base tile width. Night-view, outlining and player colours are all supported in the viewport as before.

Edit:

A small bug is fixed. Patch updated.

[Dwachs]

good idea!

[z9999+]

Infomation window is too short, and texts will overflow.

[knightly]

@Dwachs

Thank you.


@ Z9999+

Thank you for testing I am already aware of that and will try to fix it. But before that, I want to know whether text messages, which sometimes get too long and overrun the image/viewport or even the message box right margin (please see the attached image), should also be fixed. Thus, may I ask you and others :

   Should we permit variable width message box?
       i.e. message box width = (width of text)+(width of image/viewport)+margins

It seems to me that such overrun of text happens quite frequently. Sometimes it's the responsibility of the translator, but sometimes the translator doesn't have precise control -- e.g. the translated vehicle name is only part of a generated text as in the image. And sometimes there is no way to shorten some text (like vehicle name). Not to mention that, there is no 100% translation and base text (sometimes pretty long itself) gets displayed instead.

Variable width may encourage translators to pay less attention to line width, which is a downside; but IMHO it is better to display with enough width and look tidy than to expect that the translation is 100% perfect, over which the program has no control.

Anyway, I would like to hear your opinions on this issue.

Edit :

@Z9999+

Really sorry. The problem you pointed out above is another problem (not the one I am aware of). I will try to fix it once the above question is settled.

[prissi]

I would aslo think some automatically linebreaking like in gebaeude.cc info() is another option. WOuld be also more small screen friendly.

[knightly]

I would aslo think some automatically linebreaking like in gebaeude.cc info() is another option. WOuld be also more small screen friendly.

Good idea. I will see if I can change the message box to something like that.

BTW, is the patch itself okay? I mean, with respect to fixed scale in viewport. If possible, I would like to create a separate patch to fix the message box problems after the above patch is applied.

[Dwachs]

Maybe you also could fix the world_view_t for pak192 images, iirc there the object in the view window is not centered right in the world-view-t.

[knightly]

Maybe you also could fix the world_view_t for pak192 images, iirc there the object in the view window is not centered right in the world-view-t.

Do you mean buildings? Or moving objects like trucks and trains?

For buildings, alignment looks fine to me. For moving objects, I have adjusted the offset somewhat and it is already better than before. Is there some particular thing that doesn't display well?

[Dwachs]

I do not remember a specific object. I had the impression that the objects are not centered in the viewport.

Here is a screenshot. Houses and attraction are displayed right, but the views in the vehicle and factory info window could be improved.

[knightly]

Are these images captured after applying my patch?

May I know which vehicle is in the upper half of your image? As for the factory info, what particular aspect are your referring to? Do you mean it can't show the full image of the factory?

Edit :

The first viewport in your image should be before applying the patch, as I remember something like this while I was trying to adjust the y-offset for vehicles. Should be one of the trucks.

[Dwachs]

This was before applying the patch. Now its a little bit better. The vehicle is the green CRZ IV P35 Bus.

In general, the view in the vehicle and factory window looks a little bit too small for pak192-scale. Some industries show arbitrary parts of the roof there (stawberry juice plant, dairy). But this is a general complaint not especially targeted at your patch. Maybe you can look at this issue too, while you are at it.

[knightly]

For the vehicle alignment, if I understand correctly, how the artist aligns the object on the 192x192 canvas also contributes to how well it gets displayed in the viewport. (Or have I mistaken?) This patch aligns [1/4 raster from the image bottom] to the middle of viewport -- I think that is the best we can do without looking into the x and y offsets within the vehicle image.

As for the factory info, I understand your concern. I have no problem with increasing its size, but then I don't know what is wanted and what is not. Double the size so that roughly 4x4 tiles could not shown? But then the dialog box will get very large for pak192.Comic.

I have also thought about allowing scaling in viewports, but rezooming requires unpacking the image, resampling, and repacking, which would consume too much processing time if done on the fly repeatedly.

[prissi]

I would rather suggest to implement "additional worlview" windows, which can be opened on request and be either with main scaled or unscaled, so I can watch many locations at the same time. Even normal tools could work there with the new system, as mouse clicks just get the currently selected tool and send a message to it ... But this is getting offtopic, I would like to focus this patch on the unzoomed worl view.

Imho I would suggest to keep size of infowindows like min(64,raster_tilewidth) so its at maximum 192x192 and most of the times less.

[knightly]

Imho I would suggest to keep size of infowindows like min(64,raster_tilewidth) so its at maximum 192x192 and most of the times less.

I think you mean max(64,raster_tilewidth)? No problem, I will go ahead to change all the relevant dialog boxes.

I will also try to fix the message box. Automatic line break should not be a problem, but the text area will be fixed width and will not have something like the blue portion in the attached image.

[knightly]

Here a revised patch against r3033.

All dialog boxes with viewport will scale with the size of the viewport. Message boxes, contrary to what I said above, can also display text right below the image/viewport. I have also tidied up the dialog boxes a bit and fix a couple of minor bugs.

A known issue : in factory info dialog, part of the text may get covered by the viewport for larger tile sizes. The text is in a container and does not wrap around automatically, so we need to think of a way to deal with it.

Hope this patch can finally enter into trunk

Edit :

Forgot to mention that, the viewport for headquarter in the finance dialog remains fixed in size, as there is no room to expand.

[z9999+]

Nice work. Now we can use long text for message window. This should be helpful for players.

I would aslo think some automatically linebreaking like in gebaeude.cc info() is another option. WOuld be also more small screen friendly.

This is very off-topic, but most language don't use this automatically linebreaking feature in building information window, because map edit window doesn't support automatically linebreaking.

[knightly]

Nice work.

Thank you

because map edit window doesn't support automatically linebreaking.

It should not be difficult to adapt the automatic line-breaking text display code and make it into a fixed-width text-area class, if we want to solve this problem too.

[z9999+]

One small thing.
Position of world view is different from older versions.
As a result, there is no margin between text and world view.

I think having some margin like as older versions is better than this patch.

[knightly]

Position of world view is different from older versions.
As a result, there is no margin between text and world view.

Thanks for pointing out Here an updated patch.

[knightly]

Here an updated version against r3047.

The changes are :

1) Fix an existing bug (not caused by my patch) : if you open the info window of a city building, and the city building gets upgraded, the new text may be longer and cause text overflow.

2) Text in builders (factory builder, curiosity builder, etc.) within the lower-right scroll pane will automatically wrap according to the available width.

Since automatically line-wrapping textarea is useful in more than one place, I have made it into a separate class for easy maintenance and reuse. I have added the new source file to the Makefile, but for MSVC, please manually add it to the project file as my project file has changes which shouldn't be committed to the trunk.

[z9999+]

It's very nice.

So, the problem is not these patches but future development plan.

Even if these patches will be in trunk, I can't rewrite translation on SimuTranslator.
Because it is not possible to write 2 different translation for stable branch and for trunk versions.

[knightly]

Thank you very much for your comment, Z9999+

Regarding the translations, let's see if this patch is good enough for incorporation in the stable branch.

[Dwachs]

What an amount of work! Thank you Did not test yet.

Why did you changed something in simfab.cc / simhalt.cc?

What have to be changed with respect to translations? No \n anymore for some texts?

Stable branch or trunk .. dont know. It will be definitely be much additional work to integrate in the stable branch. If it breaks the translations (?) then lets head for trunk inclusion

[knightly]

What an amount of work! Thank you Did not test yet.
Why did you changed something in simfab.cc / simhalt.cc?

Thanks Actually, not much work done on top of the previous version. All those changes in simfab.cc and halt_details.cc are minor textual formatting changes. I have made similar changes in other places too. IMHO Simutrans' interface can be neat and tidy, but sometimes things like margins, linebreaks, tabs and bullet points are not applied consistently. Since this patch fixes some UI problems caused by the viewport, I have tried to fix them too when I see them.

For simhalt.cc, it only fixes the problem as shown in the attached image : the pax statistics combines with the ownership on a single line (not even a space in between), and will always overlap with the viewport. I have added 2 linebreaks to haltestelle_t::info(), that's all. That doesn't solve the whole problem, as the words "no route" may still overlap with the viewport. However, as the pax stat is a single translated object, I can't break it up.

No \n anymore for some texts? ... If it breaks the translations (?) then lets head for trunk inclusion

I think some linebreaks can go, but that is not a must and this patch doesn't break existing translations at all.

It will be definitely be much additional work to integrate in the stable branch.

Does it mean that some code needs to be reworked or added before it fits for inclusion?

[Dwachs]

Does it mean that some code needs to be reworked or added before it fits for inclusion?

No, this was just speculation about inclusion in the stable branch, since the branching off from trunk (where your patch is based on) happened already some time ago. I think it can go in trunk after some testing (ie by myself or prissi).

After testing: nice patch, found no immediate glitches. Please commit

[knightly]

After testing: nice patch, found no immediate glitches. Please commit

Thanks a lot for testing. I don't have write access to SVN yet, though I have sent an email to Christoph requesting it upon Prissi's suggestion (no reply from Christoph at the moment).

Do you mind to commit it for me? Many thanks in advance!

[knightly]

Now incorporated in trunk : r3069