Bug#456125: gfpoken -- Please transition to imlib2

[Bas Wijnen]

Hi,

On Fri, Dec 14, 2007 at 08:15:18AM +0530, Kumar Appaiah wrote:
> On 14/12/2007, Bas Wijnen wrote:
> > It also depends on Gtk+ 1.2.  Some time ago I tried to change the code
> > so it uses Gtk+ 2 instead, but that appeared to be too much effort.  Is
> > Gtk+ 1.2 also scheduled for removal?  If so, it might be better to just
> > drop this package (although I would rather keep it; it's a nice game).
> 
> I must apologize for filing this bug in great haste. I realize that a
> discussion on debian-devel was due, though I just went ahead, and
> realize that it was incorrect to do so in a hurry.

Well, removing dependencies on oldlibs is always a good idea, but not
always easy. :-)

> > I don't think this should be a problem, but if Gtk+ 1.2 will be removed
> > as well, I think it is not worth the effort.  So please let me know
> > about this.
> 
> Of course, GTK+ 1.2 will be removed. But no timeframe has been set for
> it, and it would be grossly incorrect to assume that I am requesting a
> "compy-or-remove" request.

Ok.  In that case, it is probably best to remove the imlib dependency
anyway, assuming it isn't too hard.  Then it may at least be possible to
get rid of that library. :-)

> I have tried my hand at porting some applications from GTK+ 1.2 to 2,
> and know the difficulty involved (in fact, most of the time, my
> efforts were futile).

In this case, the program uses its own implementation of drag and drop,
by tracking button-click and button-release events.  This doesn't work
anymore because Gtk+ 2 sends the button-release event to the original
window, not to the target, so it's not possible to reliably compute on
which position the drop happened.

Moving to the Gtk+ 2 built-in implementation of drag and drop introduces
some extreme delays (of several seconds after picking something up,
before being able to drop it), which is acceptable for most drag and
drop applications, but makes this game very annoying.

If the transition should really happen, it may be best to change the
interface so drag and drop is not used anymore.  Since I also took over
upstream, I can actually just decide to do that. :-)  But I don't really
want to use my time for that at this moment.  If anyone else wants to do
it, patches are welcome. :-)  I was thinking about clicking on an
element to select it (drawing a rectangle around it), and clicking on a
location to place it (either on the board, or in the unplaced list on
the side).

> In such a situation, I think it is best you forget about this bug. Of
> course, I would still request you to keep this wishlist bug open, so
> that we can track it later.

I'll have a look at the imlib transition anyway.  If that's not too
hard, it's worthwhile to do it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20071214/e7a5f00d/attachment.pgp