Follow-up Comment #141, patch #3469 (project freeciv):
OK, this is the patch fixing the typo.
Should be god for both S2_4 and trunk.
(file #17714)
___
Additional Item Attachment:
File name: 0001-fix-rates-dialog-typo.patch Size:0 KB
Follow-up Comment #142, patch #3469 (project freeciv):
OK, this is the patch fixing the typo.
Ah, we already raised a new ticket (bug #20706), sorry for not mentioning it
here.
___
Reply to this item at:
http://gna.org/patch/?3469
Follow-up Comment #140, patch #3469 (project freeciv):
...and this is why having your own patches rechecked by someone else is a good
thing.
Back in trunk patches, I've made a minor typo, that I've later noticed and
fixed in S2_4 branch, but the fix never made trunk and as such the typo is
still
Update of patch #3469 (project freeciv):
Planned Release: 2.5.0 = 2.4.0,2.5.0
___
Follow-up Comment #139:
No-one screamed...
___
Reply to
Follow-up Comment #92, patch #3469 (project freeciv):
Thanks.
Here's my version of the patch series backported from commits on trunk.
There were a few conflicts, but they were all explicable and easily resolved
(unfortunately I lost my notes on the origins of the conflicts, so you'll have
to take
Additional Item Attachment, patch #3469 (project freeciv):
File name: S2_4-gtk3-grids-etc-patches.mbox Size:340 KB
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent
Follow-up Comment #91, patch #3469 (project freeciv):
This is what I have on my 2.4 branch.
It includes all the patches that got into trunk and a few that didn't.
Obviously, cherry-picking Use g_strdup_printf() or g_strdup()... patch has
muddled the patchset a bit and is probably not really
Follow-up Comment #90, patch #3469 (project freeciv):
To avoid the risk of accidentally introducing changes that didn't go through
Gna, it's probably best to backport from trunk svn.
I plan to do this; I've got a shortlist of changes to backport already. They
don't cherry-pick trivially but I
Follow-up Comment #89, patch #3469 (project freeciv):
Actually, most of my testing was done on 2.4 branch, so I still have my
changes rebased on top of S2_4 branch.
Though I did cherry-pick a few other patches from trunk, including one or two
that I probably didn't need that much, so you'd need
Follow-up Comment #87, patch #3469 (project freeciv):
Months ago, I remember looking at some of the earlier commits to trunk in this
ticket and thinking that they were visible improvements we might well want for
S2_4.
On a brief look now I can't remember what exactly I was thinking of,
Follow-up Comment #88, patch #3469 (project freeciv):
But anyway, in principle, is there a reason not to port the
changes to the Gtk3 client code wholesale to S2_4? It's not like
S2_4 gtk3 has a long history of testing behind it
Note that S2_4 gtk3-client is as much copy of gtk2-client as
Update of patch #3469 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #79, patch #3469 (project freeciv):
53/60 raised as patch #3572, just because I'm yet to test it.
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent
Follow-up Comment #55, patch #3469 (project freeciv):
29/60 raised as patch #3565 as it depends on patch #3561 and cannot be
committed yet. (I want to go though patches in this ticket in order so every
one is certainly handled)
___
Reply
Follow-up Comment #57, patch #3469 (project freeciv):
31/60 raised as patch #3566 for bug found in testing
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
Follow-up Comment #53, patch #3469 (project freeciv):
27/60 raised as patch #3561 for problem found in testing.
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by
Follow-up Comment #41, patch #3469 (project freeciv):
16/60 is duplicate of patch #3348
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
http://gna.org/
Follow-up Comment #44, patch #3469 (project freeciv):
19/60 raised as patch #3558
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
http://gna.org/
Follow-up Comment #45, patch #3469 (project freeciv):
20/60 is duplicate of bug #20095
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
http://gna.org/
Follow-up Comment #47, patch #3469 (project freeciv):
21/60 raised as patch #3560, since it seems not to work.
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by
Follow-up Comment #39, patch #3469 (project freeciv):
I've raised new version of 14/60 as patch #3557
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
Follow-up Comment #37, patch #3469 (project freeciv):
Also 12/60 handled as part of patch #3550.
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
Follow-up Comment #36, patch #3469 (project freeciv):
I've raised 11/60 as patch #3550 for discussion as from quick glance it seems
unacceptable to me.
___
Reply to this item at:
http://gna.org/patch/?3469
Follow-up Comment #28, patch #3469 (project freeciv):
3/60 is being handled as patch #3543
___
Reply to this item at:
http://gna.org/patch/?3469
___
Message sent via/by Gna!
Follow-up Comment #25, patch #3469 (project freeciv):
Usually we've enforced 1 patch/ticket policy to avoid tickets being in some
pseudo state of being partly resolved (some patches committed) and partly not.
With patchset of 60 patches I think we can try different approach here -
forcing you to
Update of patch #3469 (project freeciv):
Status:None = Ready For Test
Assigned to:None = cazfi
Planned Release: = 2.5.0
Follow-up Comment #24, patch #3469 (project freeciv):
When looking at row-selected description, it seems to me it can't be made to
both act as it currently does and coded correctly:
* The row-activated signal is emitted when the method
* gtk_tree_view_row_activated() is called or the user
Follow-up Comment #23, patch #3469 (project freeciv):
This tarball carries complete patchset against r21858 trunk.
There are quite a few patches here, that are already attached to other
bugs/patches here, but there are just too many changes already to show the
current state in any other way.
Follow-up Comment #22, patch #3469 (project freeciv):
I've been a little busy lately, so the progress is a bit slower than I
expected.
On the other hand, as I'm reviewing my own changes, I notice a few places I
can improve them.
I.e., for all those little rants about TOCTOU, I was doing the
Follow-up Comment #21, patch #3469 (project freeciv):
News update: git 1.7.12 was released.
It's with svn 1.7 patch here, so I'm slowly working on separating the changes
I've already made (and tweaking them a little) into a series of git patches.
Unless something significant happens, within a
Follow-up Comment #20, patch #3469 (project freeciv):
Due to previously mentioned reasons, things are a bit stuck right now, but
I've ran a little test today in regard of create_line_at_mouse_pos.
It's already redundant - move_mapcanvas and move_overviewcanvas already cover
it. Though it might
Follow-up Comment #11, patch #3469 (project freeciv):
Well, here's a funny thing: while tinkering with update_rect_at_mouse_pos, I
thought I've made a regression, but gtk2 client seems to have the same
problem.
Holding right mouse button, select an area. Without releasing the button,
scroll with
Follow-up Comment #12, patch #3469 (project freeciv):
I'm tempted to do something really annoying from common client code side of
view - implement update_rect_at_mouse_pos as '{}' and just handle it in
move_mapcanvas.
I still dont understood what you are trying to achieve
Follow-up Comment #13, patch #3469 (project freeciv):
Now, for something bit annoying, for a change: kind of similar test, but in
c case, in gtk3 client leads to not quite correct display till mapcanvas
gets redrawn - I'm not sure if it's related to my changes or not.
But in gtk2 client, it
Follow-up Comment #14, patch #3469 (project freeciv):
@comment 12:
I want to put something like:
{
GdkModifierType state;
gdk_device_get_state(ev-device, ev-window, NULL, state);
if (rbutton_down (state GDK_BUTTON3_MASK)) {
update_selection_rectangle(ev-x, ev-y);
}
}
in
Follow-up Comment #15, patch #3469 (project freeciv):
you asked what does earlier center_tile_mapcanvas() - it center map on unit
when c is pressed, also probably center on some event via message output. I
assume you changed it so of course its your fault, that 'c' make mess now.
Follow-up Comment #16, patch #3469 (project freeciv):
I've made those changes in gtk3 client, not gtk2, where the permanent grab
happens.
(and I didn't exactly ask what does center_tile_mapcanvas do ?, but more
along the lines of is there anything I should know about
update_rect_at_mouse_pos in
Follow-up Comment #17, patch #3469 (project freeciv):
On gtk2 client
- select a unit (I selected )
- center the map on a different tile ( I chosen via messages and it centereed
)
- select an area, don't release the button ( I chosen )
- press c ( nothing happened, unit was still centered )
Follow-up Comment #18, patch #3469 (project freeciv):
sorry I was wrong. Centered was some vent.
It centered on new place but cursor still remained strange. After clicking new
turn everything was ok ( client was almost ok except cursor and I was unable
to select another unit)
Follow-up Comment #19, patch #3469 (project freeciv):
Seems a more detailed description is necessary:
- select a unit
- right click on a tile, that's far enough to make a visible difference but
still being able to see the unit
- press and hold right mouse button, drag to select an area
- without
Follow-up Comment #10, patch #3469 (project freeciv):
I've made not-quite-a-typo in the first version of the second - it worked, but
generated new compiler warnings.
(file #16300)
___
Additional Item Attachment:
File name:
Follow-up Comment #8, patch #3469 (project freeciv):
I'm tempted to do something really annoying from common client code side of
view - implement update_rect_at_mouse_pos as '{}' and just handle it in
move_mapcanvas.
Initial tests look good - that is as I select things with mouse, the rectangle
Follow-up Comment #9, patch #3469 (project freeciv):
I hope that whatever issues there are lately in 'git svn', they'll going to
get reasonably fixed soon, cause that's likely the most simple solution on my
side - I'll simply import svn repo into git then.
Anyway, there has been some progress in
Follow-up Comment #5, patch #3469 (project freeciv):
So, step 2 will regard the simple part of gdk_window_get_pointer
- in chatline .c, one call was doing nothing, the other was connected to a
signal that seems to have been redundant (AFAICT, things work correctly
without handling that signal)
-
Follow-up Comment #6, patch #3469 (project freeciv):
Remember to keep bug fixes and cleanup and feature development separate. First
one should go to S2_4 too, last one only to TRUNK, and middle one usually to
TRUNK only except when being requirement for later bugfix.
Follow-up Comment #3, patch #3469 (project freeciv):
Also, there's a little thing I've missed in the initial port (mainly cause it
was still hybrid then) - except for most gdk_window_get_pointer calls, those
calls can be made far more simple via the content of events they handle.
46 matches
Mail list logo
