Follow-up Comment #1, bug #21134 (project freeciv):
Are there any special conditions involved, cause it seems I can't reproduce
this behavior ?
___
Reply to this item at:
http://gna.org/bugs/?21134
Follow-up Comment #14, patch #3550 (project freeciv):
Well, technically - patch #3469 comment #37.
___
Reply to this item at:
http://gna.org/patch/?3550
___
Message sent via/by Gna!
Follow-up Comment #12, patch #3550 (project freeciv):
I've missed a thing - what about the second patch (file #16748) ?
___
Reply to this item at:
http://gna.org/patch/?3550
___
Message
Follow-up Comment #5, patch #3560 (project freeciv):
As with any other gtk-setting, gtk-button-images can be set in settings.ini
accompanying gtk.css.
Though I stand by what I wrote in patch #3889 (and a few other places) on this
topic.
___
Follow-up Comment #3, patch #3889 (project freeciv):
One other thing regarding patch #3560:
while there is gtk_button_set_always_show_image, it's only since 3.6 and IMHO
title of the button is descriptive enough in the context anyway if one has a
theme that turns off images on buttons.
As for
Follow-up Comment #2, patch #3889 (project freeciv):
In random order:
- gtk_rc_get_theme_dir is an annoyance: it was a concept change in gtk3, css
themes are read from by default from paths hardcoded on (gtk+) build time
(i.e. ${prefix}/share/themes), so there's no real equivalent for it
-
Follow-up Comment #1, bug #20772 (project freeciv):
I think the rows should be of constant height regardless of whether they
contain any units
First of all, it seems these scrolled windows *can't* be of constant height,
not with GTK_POLICY_AUTOMATIC, unless you want to query the theme for
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 #2, bug #20706 (project freeciv):
Ah, no.
110% is deliberate - not by my design, it's freeciv that reports 110% to
indicate a special condition. I remember stumbling upon this back when I was
writing those patches, but I no longer recall what condition exactly was it.
Follow-up Comment #4, bug #20706 (project freeciv):
Well, it would be much easier if I could remember where I've seen that special
condition (IIRC, 110% was not a real value, but an indicator of a special
status (civil war ?)), nevertheless 110% was already valid before my patch -
the marks just
Follow-up Comment #6, bug #20706 (project freeciv):
open rates dialog and rates setting icons in left panel are no way linked
They never were AFAIK.
Rates dialog checks the values only upon its creation.
Trying to synchronize them would make the code much more complicated for very
little gain.
Follow-up Comment #6, bug #20097 (project freeciv):
Do we expect that to have fixed all issues reported in this ticket?
Well, yes and no.
As I repeated in a few bugs here, the way freeciv is using 'row-activated'
signal was never was never really correct, so I don't see any proper fix for
that
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
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 #6, bug #20565 (project freeciv):
Well, of course it's a reserved name - that's why it was used there.
EXTRA is a valid *prefix* for _DEPENDENCIES variables - see i.e. 'info
automake1.11 Linking'.
___
Reply to this item
Follow-up Comment #4, bug #20565 (project freeciv):
Which version of automake are you using ?
AFAICT, while the construct does look redundant in this particular case, it's
nevertheless valid (that is, it shouldn't trigger an error).
Regarding the fixes: while they look OK, it seems that
Follow-up Comment #2, bug #20534 (project freeciv):
Going deeper into the code, it could hint to a problem with
gdk_pixbuf_composite in canvas_put_sprite, but hard to tell without more
testing.
My guess would be you're hitting following documented case:
When the destination rectangle contains
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 #1, patch #3572 (project freeciv):
Actually, I couldn't really test it either - didn't really know how to force
displaying that bar for longer than a moment it appears during a single player
game.
I don't see anything that would be *obviously* wrong with it though.
However,
Follow-up Comment #1, patch #3561 (project freeciv):
A screenshot please.
I don't see that on trident, cimpletoon nor amplio2.
___
Reply to this item at:
http://gna.org/patch/?3561
___
Follow-up Comment #1, patch #3564 (project freeciv):
Oops. I had that correct on S2_4 - not quite sure why wasn't that
cherry-picked there correctly.
Anyway, it seems to be just a matter of a single line.
(file #16764)
___
Additional
Follow-up Comment #1, patch #3566 (project freeciv):
Are you sure this patch plays a role here ? It shouldn't affect anything but
packing (and nothing in its content suggests it could).
While at the first I seem to have reproduced the problem, I've noticed a
warning in the terminal:
Follow-up Comment #3, patch #3561 (project freeciv):
Ahthis thing.
IIRC, when combined with use grids in citydlg overview page patch, the size
goes back to something reasonable - all that's left is (a gap for) the
scrollbar.
___
Reply
Follow-up Comment #3, patch #3560 (project freeciv):
Well, we could just set this to true in the theme.
Note, that there are other places already affected by this setting - that
screenshot in patch #3561 suggests you didn't notice that.
Follow-up Comment #1, patch #3558 (project freeciv):
Actually, this is a dupe of a part of bug #19900, though this patch might be
more recent.
Also, I need to change this patch a bit - using GtkSettings wasn't needed,
there's a more straightforward way to get the needed PangoFontDescription.
Follow-up Comment #1, patch #3560 (project freeciv):
Actually, that probably means it does work.
The answer may lie in gtk-button-images from GtkSettings.
As it's a standard button now, it follows the theme.
___
Reply to this item at:
Follow-up Comment #7, patch #3550 (project freeciv):
Made a minor thinko in file #16747 - corrected now.
(file #16752)
___
Additional Item Attachment:
File name: 0001-modify-selection-rectangle-drawing.patch Size:2 KB
Follow-up Comment #3, patch #3550 (project freeciv):
In case of update_rect_at_mouse_pos, the problem comes down to a simple thing
- the function signature is 'void update_rect_at_mouse_pos(*void*)'.
The already stated reason comes into play, the same one I was against
Follow-up Comment #5, patch #3550 (project freeciv):
Well, it seems we don't quite understand each other, but OK.
I went with the extreme duplication instead.
You'll see what I mean once I'll attach updated version of both patches.
___
Follow-up Comment #6, patch #3550 (project freeciv):
As noted, I've decided if there's no good way to do it, I'll stick with a
model that sort of works.
I've still merged the active content of update_rect_at_mouse_pos into the
calbacks that used it, but updated the old code in regard of
Follow-up Comment #1, patch #3550 (project freeciv):
Well, TBH, there's one major catch here: while things work as-is both in gtk2
and gtk3 clients, technically they only do that due to luck.
Even back in gtk2 its devs stressed that *all* of the drawing should be done
in 'expose-event' handler.
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 #1, patch #3519 (project freeciv):
This change looks correct - probably it was meant to look like that in the
first place.
___
Reply to this item at:
http://gna.org/patch/?3519
Follow-up Comment #14, bug #20095 (project freeciv):
Well, on S2_4 the patch looks differently, mainly due to tree moves and
freciv-web.
This one is same revision, for S2_4.
Your new error regards readline.
(file #16448)
___
Additional
Follow-up Comment #15, bug #20095 (project freeciv):
The last part of my last comment was a bit silly.
I should have said the new problem is due to the change from patch #3436 and
regards readline.
___
Reply to this item at:
Follow-up Comment #18, bug #20095 (project freeciv):
On an interesting note, each of these patches seems to make those three lua
*_AS_DEPENDENCY vars redundant for their respective trees.
I wonder though: is there any reason (other than not compiling the file twice)
for not simply listing
Follow-up Comment #3, bug #20097 (project freeciv):
@comment #2:
That's exactly what I've meant by I can't reproduce - this works correctly
here, even if the code isn't really correct.
___
Reply to this item at:
Follow-up Comment #6, bug #20095 (project freeciv):
Perhaps a silly question, but does OS X have a *separate* libm ?
(IIRC, that's a valid question for i.e. OpenBSD (or was that just about were
*some* of math functions are ?))
Also, both LUA_AS_DEPENDENCY and LUA_LIBS carry '-lm'.
As for the
Follow-up Comment #7, bug #20095 (project freeciv):
Looking at tolua-5.1/src/bin/Makefile.am again, *unless* I'm missing
something, after changing _LDFLAGS to _LDADD it would seem tolua_DEPENDENCIES
are redundant - see if removing it helps.
Follow-up Comment #10, bug #20095 (project freeciv):
What about what I've wrote in comment #7 ?
After all, the reason dependencies were not computed correctly before was
exactly that those libs were passed via _LDFLAGS instead of _LDADD.
Follow-up Comment #11, bug #20095 (project freeciv):
...also passing '-lm' to libtolua_la_LIBADD (if it's actually needed there and
not for liblua itself) should make it easier to propagate it down the tree.
___
Reply to this item at:
Follow-up Comment #12, bug #20095 (project freeciv):
OK, it's better to write the patch on your own.
This is against trunk r21843.
freeciv-server, freeciv-manual, freeciv-modpack and gtk2/gtk3 clients seems to
build correctly with it.
Please test.
(file #16445)
Follow-up Comment #8, bug #19900 (project freeciv):
I've looked at the patch from comment #7 again and noticed it could be
simplified. At the same time I've decided to split it into two parts - one for
the font and the other for style unrelated to the font.
A word of explanation about
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 #1, bug #20097 (project freeciv):
Take note of patch #3469, thank you.
As for that part about Control key, I can't reproduce, but I'm aware of the
problem; there's no good solution yet - that signal wasn't meant to be used
that way.
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 #3, bug #19846 (project freeciv):
Well, right now I've got the client nearly in pieces (mostly due to gridding -
nearly done now, just restoring the spacing and minor tweaks left), but it
seems my first comment was on the spot - due to the order of signals being
undefined,
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 #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 #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 #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 #1, patch #3478 (project freeciv):
With tongue in cheek, I'd say that's what would happen in the real world,
barring significant height difference.
___
Reply to this item at:
http://gna.org/patch/?3478
Follow-up Comment #2, patch #3478 (project freeciv):
Ah, sorry - should have read the patch first.
You meant this patch should implement this effect.
___
Reply to this item at:
http://gna.org/patch/?3478
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 #2, patch #3472 (project freeciv):
As I already mentioned in patch #3469, as gtk+ 3.4 is the target, grids should
be used instead of tables - in such simple case, there's very little
difference API-wise.
Also, a question: in regard of a different patch/bug (can't find the
Follow-up Comment #1, bug #19882 (project freeciv):
Just a note, so *I* won't forget it - this seems to affect gtk2 client too.
The signal is connected to the changed signal of the combobox - that one can
be emitted not just on interactive changes, but (AFAICT) also if i.e. model
gets changed,
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.
Follow-up Comment #1, bug #2 (project freeciv):
I suspect the only mistake could be relying on some side effect of running in
expose-event.
Attaching something that seems to fix the problem.
The second block is just a minor gtk3 cleanup.
(file #16233)
Follow-up Comment #6, bug #19900 (project freeciv):
...and for a difference, on a topic related note, a minor fix for help label
colors - value taken from old Freeciv.h.
(that line for font in tooltip doesn't seem to work, but the colors do)
(file #16199)
Follow-up Comment #7, bug #19900 (project freeciv):
Alright, it's hard to affect a tooltip, if it's not really a tooltip.
I was looking at the info popups in city dialog - setting them to monospace
makes the formating work again.
(file #16201)
URL:
http://gna.org/patch/?3442
Summary: limit the use of sprite_get_pixbuf
Project: Freeciv
Submitted by: galtgendo
Submitted on: Tue 24 Jul 2012 11:20:30 PM CEST
Category: client-gtk-3.0
Priority: 5 -
67 matches
Mail list logo
