Welcome patches

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderators: Committer, Committer

Message
Author
wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Welcome patches

#1 Post by wrwrwr » Tue Dec 22, 2009 8:21 am

Hello FreeOrion's community!

I've been posting some patches on the tracker for the last couple of days -- so far only fixing some already reported and well described small UI bugs. As I've just begun to delve into the sources any testing and constructive criticism is even more welcome than usually.

User avatar
OndrejR
Space Dragon
Posts: 339
Joined: Thu Oct 02, 2008 11:00 pm
Location: Slovakia

Re: Welcome patches

#2 Post by OndrejR » Tue Dec 22, 2009 9:32 am

Find enjoying programming work on Programming work page.

mZhura
Space Kraken
Posts: 168
Joined: Sun Sep 27, 2009 10:51 am
Location: Moskow, RU

Re: Welcome patches

#3 Post by mZhura » Tue Dec 22, 2009 4:44 pm

i am sorry, but to test anything i need working win32 binary :oops:

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12453
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Welcome patches

#4 Post by Geoff the Medio » Tue Dec 22, 2009 6:36 pm

wrwrwr wrote:Hello FreeOrion's community!

I've been posting some patches on the tracker for the last couple of days -- so far only fixing some already reported and well described small UI bugs. As I've just begun to delve into the sources any testing and constructive criticism is even more welcome than usually.
Thanks for the contributions, but please don't post patches on sourcefoge. Post them on the forums, as otherwise they won't get noticed, and since we'll discuss them on the forums anyway.

wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#5 Post by wrwrwr » Wed Dec 23, 2009 7:57 pm

@OndrejR: What I see is that it has fixing bugs on the first line ;-) But, yes, I've seen that and it remains to be seen if I'll be able to help with some other things.

@mZhura: I don't know about any cross-compiling scripts for FO and setting up a Windows environment is not an option at the moment (my Windows is hardly working itself, burdening it with a task as complex as compiling would surely make it reach some singularity), but thanks for your willingness! (I guess you can always test the current stable build, just check the tracker/forum to see if it's not already fixed before reporting.)

@Geoff: Hmmm, I usually find trackers and such rather useful for bug/patch management, but sure, from my side forum is just as good or even better.



OK, to the point. Here's another small patch, hopefully fixing this: https://sourceforge.net/tracker/?func=d ... tid=544942 .

There are two SidePanels: one for MapWnd and one for ProductionWnd. Both contain InfoPanels that keep track of their expanded/collapsed state using a static object->bool vector (so panels for a single population/resource centre or planet all should be either collapsed or expanded). Toggling production screen switches the side panels by simply showing one and hiding the other, info panels are not updated in any way, so their appearance becomes inconsistent with the statically stored state.

The patch adds a call to SidePanel->Update() when changing visibility of the production window (Update() is a static function that updates both side panels). That is the lightest update path available -- still it does a bit too much, however I'd rather not have anything like "UpdateInfoPanelsCollapsedExpandedState". This update is needed for showing and hiding production.

Some side notes: Why are 2 side panels needed? And, if info panels for an object are all collapsed or not maybe it should really be a single shared panel?


PS: I no longer like the forum that much, as it won't allow me to post neither .diff nor .patch -- insisting on compressing 5 lines of text.
Attachments
collapsible-info-panels-state-inconsistency.diff.tar.bz2
(382 Bytes) Downloaded 65 times

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12453
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Welcome patches

#6 Post by Geoff the Medio » Wed Dec 23, 2009 9:21 pm

I think I've enabled attaching .diff and .patch files... I'm an administrator though, so it might be letting me do things other can't, so could someone check?

If something's only 5 lines though, you could just post it in a forum code tag.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

[The extension diff has been deactivated and can no longer be displayed.]


wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#7 Post by wrwrwr » Wed Dec 23, 2009 9:36 pm

Some compilation warning fixes: gcc (4.3.3) has been complaining about a few unused and uninitialized variables each time, so I've made some corrections to be able to see the actual warnings. A couple can be probably commited, but some are really working around gcc not being able to infer that a variable is initialized -- may not be needed with a different compiler or even with a different version of gcc.

Empire, System, FleetWnd: Prevent some "unused variable" warnings, using some explicit style (like in other parts of the code) rather than removing (I understand this is meant to enhance readability).
Server: Don't use the same (iterator) variable name too many times (causing an ambiguity); should also be easier to read now.
CMakeLists: Add -Wno-deprecated flag only for C++.
CUIDraw, PagedGeometry/*: Be more explicit about initializing variables. [These are the "bad" ones.]

The only left, Ogre::AxisAlignedBox kind, should go away soon, due to these changes: http://ogre.svn.sourceforge.net/viewvc/ ... 28&r2=8787 .

@Geoff: Great, now it works, thank you.
Attachments

[The extension diff has been deactivated and can no longer be displayed.]


User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12453
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Welcome patches

#8 Post by Geoff the Medio » Wed Dec 23, 2009 10:31 pm

You've used a bunch of tabs in your latest diff. These will need to be converted to spaces.

Edit: Also, for the unused variable warnings, you can just remove the variable declarations and avoid adding an extra line. So replace

Code: Select all

if (const UniverseObject* obj = objects.Object(it->second)) {
with just

Code: Select all

if (objects.Object(it->second)) {

wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#9 Post by wrwrwr » Thu Dec 24, 2009 10:41 am

Should I replace all such variables? Personally I would as they don't add too much clarity, but there are quite a few. (Maybe they make the type more clear, but in most cases it's already rather obvious). Anyway lets decide on some style.

I believe the tabs are only in the PagedGeometry stuff that uses them everywhere, If you could, please convert it all yourself (unless you want a patch that changes each and every line that is :-)

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12453
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Welcome patches

#10 Post by Geoff the Medio » Thu Dec 24, 2009 10:58 pm

For the stuff in PagedGeometry, I'd rather not change it at all, since it's not code written by us, and if it's modified, the notice at the top requires that we also modify it to make it clear that it has been modified. Also, the PagedGeometry stuff won't be changing very much, so presumably won't have to recompiled often, so won't be constantly generating the warnings...

I've made a bunch of other changes based on your patch. The changes to System.cpp at line 190 don't seem necessary, as opposed to the similar change at 176 which was an unused variable so could be shortened to not actually store the return value of the Object() call. If having the extra variable is causing warnings, I'll remove it in those cases, but in general it should be fine to declare and assign within an if () and this is done in many places... I think there's any special style change needed, except in cases where a warning is given about such a declared and assigned but then unused variable.

In CUIDrawUtil.cpp you've added a default case to a switch that asserts and then calls a function abort(). I modified that to add a default case that outputs some error text to the log file instead.
wrwrwr wrote:There are two SidePanels: one for MapWnd and one for ProductionWnd. Both contain InfoPanels that keep track of their expanded/collapsed state using a static object->bool vector (so panels for a single population/resource centre or planet all should be either collapsed or expanded).
[...]
Why are 2 side panels needed? And, if info panels for an object are all collapsed or not maybe it should really be a single shared panel?
I discussed this with tzlaine a few years ago, and there was probably a reason at some point, but I don't remember what it is. It'd probably work find just to have a single SidePanel, now, but someone would have to go through and rewrite all the code to work that way, which I don't particularly want to do myself, and which isn't really necessary since things are working now, more or less.

wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#11 Post by wrwrwr » Fri Dec 25, 2009 3:12 pm

PagedGeometry, sure, lets leave that (although I do revert/recompile often). SidePanel x2 -- I feel the same.

Unused variables: I don't mean assigning in an expression :-) But rather wonder should I do some similar code clean up along the way. Example attached (remove unneeded variables, positive conditions, don't add wrong values). Also was considering "const"-ing, correcting case etc., I guess I'll just correct whatever comes in the way -- let me know if I start to overdo that.

CUIDraw: Considering that (if it could at all happen ;-) there is an uninitialized access just after that default statement, are you absolutely sure that this message would be logged before the segmentation fault? Due to the possibility of compiler reordering that's not so obvious to me (although probably yes in this case, but with a bit of luck):

Code: Select all

// File: test.cpp.
#include <iostream>

using namespace std;

int main() {
	int *u;
	cout << "Will we see that?";
	*u = 1;
}

Code: Select all

$ g++ test.cpp -o test
$ ./test
Segmentation fault
If you change cout to cerr or add an endl, you are going to see that message, but hopefully that shows the danger. You might want to consider throw-ing that error in such a low-level case (this is done in similar places already).

OK, that's purely academic, sorry for wasting your time, and of course do as you please :-)
Attachments

[The extension diff has been deactivated and can no longer be displayed.]


wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#12 Post by wrwrwr » Fri Dec 25, 2009 3:29 pm

I've noticed that expand buttons don't fit in InfoPanels if the font is made smaller, here's a fix (makes the population/resource/military panels at least as high as the button).
expand-buttons-with-smaller-font.png
expand-buttons-with-smaller-font.png (2.96 KiB) Viewed 1307 times
Attachments

[The extension diff has been deactivated and can no longer be displayed.]


User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12453
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Welcome patches

#13 Post by Geoff the Medio » Fri Dec 25, 2009 7:21 pm

wrwrwr wrote:PagedGeometry, sure, lets leave that (although I do revert/recompile often).
Unless you recompile everything, including unchanged files, that shouldn't matter, since those files aren't changing much...
Unused variables: I don't mean assigning in an expression :-) But rather wonder should I do some similar code clean up along the way. Example attached (remove unneeded variables, positive conditions, don't add wrong values).
The presence of the unneeded variables don't really hurt anything, and arguably makes the code easier to read since one doesn't need to look up functions like GetHullType to know what they're returning, but I don't really care either way if those are or aren't temporarily stored then discarded after the if checking the return value.

Positive vs. negative conditions doesn't really matter... I don't think it's worth going through just to change that just out of preference for positive. I usually use whichever of positive or negative works, and in these cases I was only outputting error text when the part or hull wasn't found, and was adding the passed-in name in either case, so the negative condition worked best.

Not adding the names of nonexisting parts or hulls to empires is changing how the code works, so isn't really cleanup anymore. When things are working, it shouldn't make a difference, but it might be helpful when debugging to see what part or hull name was actually added to an empire, without needing to have working log output, in case that name was corrupted or somesuch.
Also was considering "const"-ing, correcting case etc., I guess I'll just correct whatever comes in the way -- let me know if I start to overdo that.
These changes are fine. I often get nitpicky when rewriting some code.
CUIDraw: Considering that (if it could at all happen ;-) there is an uninitialized access just after that default statement, are you absolutely sure that this message would be logged before the segmentation fault? Due to the possibility of compiler reordering that's not so obvious to me (although probably yes in this case, but with a bit of luck):
OK, I moved the default case above the SHAPE_RIGHT case, without a break between them, so the default is the same as SHAPE_RIGHT and things should get initialized fine.
wrwrwr wrote:I've noticed that expand buttons don't fit in InfoPanels if the font is made smaller, here's a fix (makes the population/resource/military panels at least as high as the button).
Committed.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Welcome patches

#14 Post by pd » Sat Dec 26, 2009 8:06 am

wrwrwr wrote:I've noticed that expand buttons don't fit in InfoPanels if the font is made smaller, here's a fix (makes the population/resource/military panels at least as high as the button).
Good work. Slightly related to this, would it be possible to not decrease the meter icons below 16x16px(about the size they are when using a font size of 12)?

wrwrwr
Space Floater
Posts: 25
Joined: Thu Dec 17, 2009 5:36 am

Re: Welcome patches

#15 Post by wrwrwr » Sat Dec 26, 2009 3:55 pm

You mean they should scale up, but not down, like this:
meter-icons-8pt.png
meter-icons-8pt.png (9.92 KiB) Viewed 1261 times
meter-icons-12pt.png
meter-icons-12pt.png (11.27 KiB) Viewed 1261 times
meter-icons-16pt.png
meter-icons-16pt.png (16.46 KiB) Viewed 1262 times
?

Post Reply