alleg-developers — For coordination between admins/developers, discussion of patches, etc.

[AD] [alleg:bugs] #355 al_show_native_message_box focus on Windows

[ErwinGame <erw...@us...>]

Okay


---

** [bugs:#355] al_show_native_message_box focus on Windows**

**Status:** open
**Group:** 5.1
**Labels:** Windows 
**Created:** Sat Apr 14, 2012 01:22 AM UTC by Peter Wang
**Last Updated:** Tue Oct 09, 2012 04:21 PM UTC
**Owner:** nobody


http://www.allegro.cc/forums/thread/609911/951925#target

We call MessageBoxW to open the message box. When we give the window handle of the display to MessageBoxW, the new window inherits(?) the window proc of the normal Allegro window. For some reason, due to the way the window proc handles the messages, the message box doesn't gain focus when it is created.


---

Sent from sourceforge.net because all...@li... is subscribed to https://sourceforge.net/p/alleg/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alleg/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [AD] Submission: XInput2 patch for linux mouse-movement

[Phelius <pro...@gm...>]

On Thu, Mar 10, 2016 at 7:58 PM, Elias Pschernig <eli...@gm...>
wrote:
>
> I'm confused, you say this patch grabs mouse-movement events in
> XInput2, then you say input + windows + mouse are handled by the
> legacy API - so which one is it for mouse? Or is movement handled by
> XInput2 and buttons with legacy? Would there be any advantage in
> handling more events with XInput2?


With this patch, only Mouse movement will be handled by Xinput2 if
available.
the remaining mouse events: mouse buttons, and wheel events, etc. are all
still handled by the legacy API.
window events (enter, leave, focus, etc.), other input
devices+events(joystick, etc). are all still handled by the legacy API.

According to Xorg docs:
Xinput 2.2 adds multitouch support. Clients can, for example, now
distinguish between a one-finger slide and a two-finger swipe. Multitouch
support adds on to enhancements in previous versions. These included input
device properties to pass additional metadata and configuration information
between devices and clients; also the MultiPointer X (MPX) feature. MPX
allows for multiple X users to share a single X desktop. Each user may have
their own on-screen cursor image and input focus, driven by their own mouse
and keyboard devices.

There's a lot of "#ifdef ALLEGRO_XWINDOWS_WITH_XINPUT2" checks, so
maintaining legacy compatibility was clearly important to someone.
I wanted access to multi-touch and this seemed like the least obtrusive way
to do so.

The joystick interface seems to be a pain point, perhaps Xinput could help
there, I don't know.
My only exposure with X11 is with the touch driver and now this mouse
driver.


I forgot to mention: this patch also fixes a couple other issues:
1)
memory leak with the touch driver:
XFreeEventData() wasn't being called after XGetEventData(). The patch also
moved that logic into xevent.c

2)
Removes the unnecessary calloc() in
xdisplay.c:xdpy_create_display_window() when
setting the event_mask for polling XInput2 events.

Re: [AD] Submission: XInput2 patch for linux mouse-movement

[Elias P. <eli...@gm...>]

On Thu, Mar 10, 2016 at 4:26 PM, Phelius <pro...@gm...> wrote:
> Attached is a patch that enables Xinput2 API for processing mouse-movement.

Thanks!

> No new functionality is implemented.
>
> Notes:
> -I refactored/moved the x11 touch input setup stuff since it also gets used
> for the mouse
> -touchpad events were implemented in Xinput 2.1, but touchscreen events are
> in ver 2.2
>  I simply made 2.2 the minimum requirement. I don't think it's worth it to
> test for both versions
>  and it seems to be what other projects (eg: GTK) are doing.
>
> Important:
> Xorg apparently does not allow using both the legacy API and Xinput2 for the
> same event class.
> So enabling listening for XI_Motion events causes the MotionNotify events to
> stop.
> Hence, this patch _only_ grabs the mouse-movement events in Xinput2 so that
> allegro has access to touchpad events we can add later in the future.
> All other inputs + window + mouse events are all still being handled by the
> legacy API.

I'm confused, you say this patch grabs mouse-movement events in
XInput2, then you say input + windows + mouse are handled by the
legacy API - so which one is it for mouse? Or is movement handled by
XInput2 and buttons with legacy? Would there be any advantage in
handling more events with XInput2?

>
> Testing:
> - allegro5 builds with and without xinput2 support
> - mouse example programs and ALLEGRO_MOUSE_EVENT members all work for legacy
> and XInput2 versions.
> - pointer and mouse-wheel acceleration work for mouse and touchpad
> - hot-plugging USB mouse works and simultaneous use with touchpad works
>
> Everything behaved as expected for me.
>
> Please review and consider for addition.
>

If you haven't done so yet, could you also create a pull request on github?

[AD] Submission: XInput2 patch for linux mouse-movement

[Phelius <pro...@gm...>]

Attached is a patch that enables Xinput2 API for processing mouse-movement.
No new functionality is implemented.

Notes:
-I refactored/moved the x11 touch input setup stuff since it also gets used
for the mouse
-touchpad events were implemented in Xinput 2.1, but touchscreen events are
in ver 2.2
 I simply made 2.2 the minimum requirement. I don't think it's worth it to
test for both versions
 and it seems to be what other projects (eg: GTK) are doing.

Important:
Xorg apparently does not allow using both the legacy API and Xinput2 for
the same event class.
So enabling listening for XI_Motion events causes the MotionNotify events
to stop.
Hence, this patch _only_ grabs the mouse-movement events in Xinput2 so that
allegro has access to touchpad events we can add later in the future.
All other inputs + window + mouse events are all still being handled by the
legacy API.

Testing:
- allegro5 builds with and without xinput2 support
- mouse example programs and ALLEGRO_MOUSE_EVENT members all work for
legacy and XInput2 versions.
- pointer and mouse-wheel acceleration work for mouse and touchpad
- hot-plugging USB mouse works and simultaneous use with touchpad works

Everything behaved as expected for me.

Please review and consider for addition.

Thanks,
Pho75

Re: [AD] Allegro on Gna!

[torhu <tor...@gm...>]

On 09.08.2015 03:33, Peter Wang wrote:
> Hi,
>
> Allegro has been accepted as a project on Gna!

Testing 1 2 3... :)

Re: [AD] Allegro on Gna!

[Peter W. <nov...@gm...>]

On Sat, 15 Aug 2015 13:59:46 -0600, Thomas Fjellstrom <th...@fj...> wrote:
> On Fri 14 Aug 2015 10:26:36 PM SiegeLord wrote:
> > While posting to it a few times, I've noticed that things went into the
> > moderation queue. I'm not sure what
> > all...@li... is doing right now, but I was
> > under the impression that it was not moderated. Could we turn that off
> > for gna as well (if sourceforge is moderated, then nevermind, I must
> > have never noticed it). Just concerned about the workload of
> > whitelisting people by the busy moderator(s).
> 
> Afaik it is/was moderated. I thought elias disabled that at some point, but i 
> could be wrong. For a long time noone was even moderating it...

The gna list was on the default setting so posts by non-members would be
held in a queue.  I had to approve SL's first post but that was it.

I have opened the list to posts by non-members.
If spam turns out to be an issue, we can rethink it.

As for the [AD] list on SourceForge, consider it closed.
Actually it's just hidden from view.  Posts like this should still go
through.  There may be something in the mailman admin area, but I don't
have the password to it.

Peter

Re: [AD] Donation link

[Peter W. <nov...@gm...>]

On Sat, 15 Aug 2015 20:31:32 -0400, Elias Pschernig <el...@ps...> wrote:
> On Fri, Aug 14, 2015 at 11:06 PM, Peter Wang <nov...@gm...> wrote:
> 
> > Hi,
> >
> > Will anything bad happen if I delete the Donate link on the SourceForge
> > page?  I don't want to leave it there when we're moving away.
> >
> >
> It should be removed.

Done.

> I'd still kinda like (someone) to redo the whole
> website - I feel it's time for a new layout plus some stuff should be
> migrated to the wiki, like the DIGMID, Logos or Humor pages - but I guess
> that's not really important right now.

Yeah, most of the web site is just there because it was there in the
past.

Peter

Re: [AD] Donation link

[Elias P. <el...@ps...>]

On Fri, Aug 14, 2015 at 11:06 PM, Peter Wang <nov...@gm...> wrote:

> Hi,
>
> Will anything bad happen if I delete the Donate link on the SourceForge
> page?  I don't want to leave it there when we're moving away.
>
>
It should be removed. I'd still kinda like (someone) to redo the whole
website - I feel it's time for a new layout plus some stuff should be
migrated to the wiki, like the DIGMID, Logos or Humor pages - but I guess
that's not really important right now.

Re: [AD] Allegro on Gna!

[Tobias H. <th...@de...>]

all...@li... is only not moderated for
subscribers, all other mails go into a moderation queue that is never
reviewed I think. I hope it will be different for the new list.

Best,
Tobias

Am 15.08.2015 um 07:26 schrieb SiegeLord:
> While posting to it a few times, I've noticed that things went into the 
> moderation queue. I'm not sure what 
> all...@li... is doing right now, but I was 
> under the impression that it was not moderated. Could we turn that off 
> for gna as well (if sourceforge is moderated, then nevermind, I must 
> have never noticed it). Just concerned about the workload of 
> whitelisting people by the busy moderator(s).
> 
> -SL
> 
> On 08/08/2015 06:33 PM, Peter Wang wrote:
>> Hi,
>>
>> Allegro has been accepted as a project on Gna!
>>
>> https://gna.org/projects/allegro
>>
>> I have created a new mailing list.  Please subscribe if you are interested.
>> Subscriptions from the old mailing list will NOT be automatically
>> transferred to the new list.
>>
>> https://mail.gna.org/listinfo/allegro-developers
>>
>> I intend to shut down the old list in about one week, then transfer the
>> archives.  In the mean time, please cross-post messages to both lists.
>>
>> See you there.
>>
>> Peter
>>
>> P.S. Could a couple of interested parties sign up and request to join
>> the Gna project (or however it is done) so we have multiple admins.
>> Thanks.
>>
>> ------------------------------------------------------------------------------
>>
> 
> ------------------------------------------------------------------------------
> 

Re: [AD] Allegro on Gna!

[SiegeLord <sie...@gm...>]

While posting to it a few times, I've noticed that things went into the 
moderation queue. I'm not sure what 
all...@li... is doing right now, but I was 
under the impression that it was not moderated. Could we turn that off 
for gna as well (if sourceforge is moderated, then nevermind, I must 
have never noticed it). Just concerned about the workload of 
whitelisting people by the busy moderator(s).

-SL

On 08/08/2015 06:33 PM, Peter Wang wrote:
> Hi,
>
> Allegro has been accepted as a project on Gna!
>
> https://gna.org/projects/allegro
>
> I have created a new mailing list.  Please subscribe if you are interested.
> Subscriptions from the old mailing list will NOT be automatically
> transferred to the new list.
>
> https://mail.gna.org/listinfo/allegro-developers
>
> I intend to shut down the old list in about one week, then transfer the
> archives.  In the mean time, please cross-post messages to both lists.
>
> See you there.
>
> Peter
>
> P.S. Could a couple of interested parties sign up and request to join
> the Gna project (or however it is done) so we have multiple admins.
> Thanks.
>
> ------------------------------------------------------------------------------
>

Re: [AD] Gna download area

[SiegeLord <sie...@gm...>]

That's great! Yes, indeed there's quite a few files of... historical 
interest still on SourceForge. I think some of them would appropriately 
be put inside the website perhaps.

-SL

On 08/14/2015 07:51 PM, Peter Wang wrote:
> Hi,
>
> I uploaded our files to Gna:
> http://download.gna.org/allegro/
>
> It would have been a good chance to reorganise things a bit, but I didn't.
> Feel free to, if you like.
>
> Some documentation-related files are still only on SourceForge.  I'm not
> sure where they should go but the download area might be fine for those
> as well.
>
> If you need to upload stuff the instructions are here:
> https://gna.org/cookbook/?func=detailitem&item_id=119
>
> Peter
>
> ------------------------------------------------------------------------------
>

[AD] Donation link

[Peter W. <nov...@gm...>]

Hi,

Will anything bad happen if I delete the Donate link on the SourceForge
page?  I don't want to leave it there when we're moving away.

Peter

[AD] Gna download area

[Peter W. <nov...@gm...>]

Hi,

I uploaded our files to Gna:
http://download.gna.org/allegro/

It would have been a good chance to reorganise things a bit, but I didn't.
Feel free to, if you like.

Some documentation-related files are still only on SourceForge.  I'm not
sure where they should go but the download area might be fine for those
as well.

If you need to upload stuff the instructions are here:
https://gna.org/cookbook/?func=detailitem&item_id=119

Peter

Re: [AD] Transferring bugs to github?

[SiegeLord <sie...@gm...>]

The transfer is now complete. I've adjusted the website bugtracker link 
to point to github as well.

-SL

On 08/09/2015 08:43 PM, SiegeLord wrote:
> It's a very rough lower bound on the number of issues we have, since a
> good few reside in a TODO list on my desktop, and quite a few are in the
> ephemeral threads on allegro.cc. Quite a few of the bugs are for
> Allegro, which we could in principle close, but I'll transfer them as is
> for now.
>
> -SL
>
> On 08/08/2015 11:53 PM, Beoran wrote:
>> The transfer seems fine, but I'm surprised to see that there are so
>> many issues. After we import them we should probably triage them to
>> see which ones we will and won't implement , and perhaps make new
>> issues that describe the actions better.
>>
>> Kind Regards,
>>
>> B.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>

Re: [AD] Transferring bugs to github?

[SiegeLord <sie...@gm...>]

It's a very rough lower bound on the number of issues we have, since a 
good few reside in a TODO list on my desktop, and quite a few are in the 
ephemeral threads on allegro.cc. Quite a few of the bugs are for 
Allegro, which we could in principle close, but I'll transfer them as is 
for now.

-SL

On 08/08/2015 11:53 PM, Beoran wrote:
> The transfer seems fine, but I'm surprised to see that there are so
> many issues. After we import them we should probably triage them to
> see which ones we will and won't implement , and perhaps make new
> issues that describe the actions better.
>
> Kind Regards,
>
> B.
>
>
>
> ------------------------------------------------------------------------------
>

Re: [AD] Deployment

[AJ <ajb...@gm...>]

as a windows user,  i think the InnoSetup script idea is good.
not only does it solve a technical problem, it adds a certain 
professionalism to a deployment that makes it seem more than some 
hobby-game.

"here, have a zip file you unpack, and then install this runtime, and 
run this vcdist thing, then click on one of those exe files to launch 
it...  oh what? it didn't run.. why not? did you read the README?  did 
you follow these 12 steps? ..  you put it in C:/Program Files/  but it 
can't read/write it's own config file... oh yeah.. you have to mess 
about with permissions in the file system too.. ",   this is 
unacceptable these days.





On 9/08/2015 8:44 PM, Peter Hull wrote:
> I've been following the latest speedhack and also reding the recent 
> thread about bundling DLLs/static linking. It seems to me that it's 
> quite tricky to deploy an Allegro game and get it right, especially if 
> the target audience doesn't have allegro at all.
> Has anyone any ideas on how to make it easier. I was thinking of some 
> sort of simple config file, listing the app's name, exe, resources 
> etc. which could be turned into something suitable by a 
> platform-specific processor. For example, on OSX it could work like 
> the 'fixbundle' tool, on Windows maybe generate a WiX or innosetup script.
> What do you think?
> Pete
>

[AD] Deployment

[Peter H. <pet...@gm...>]

I've been following the latest speedhack and also reding the recent thread
about bundling DLLs/static linking. It seems to me that it's quite tricky
to deploy an Allegro game and get it right, especially if the target
audience doesn't have allegro at all.
Has anyone any ideas on how to make it easier. I was thinking of some sort
of simple config file, listing the app's name, exe, resources etc. which
could be turned into something suitable by a platform-specific processor.
For example, on OSX it could work like the 'fixbundle' tool, on Windows
maybe generate a WiX or innosetup script.
What do you think?
Pete

Re: [AD] Allegro on Gna!

[Peter H. <pet...@gm...>]

Au revoir!
Pete

On Sun, 9 Aug 2015 at 08:00 Beoran <be...@gm...> wrote:

> Thanks for setting this up.  I'll get on there also. :)
>
> Kind Regards,
>
> B.
>
>
>
>
> ------------------------------------------------------------------------------
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>

Re: [AD] Allegro on Gna!

[Beoran <be...@gm...>]

Thanks for setting this up.  I'll get on there also. :)

Kind Regards,

B.

Re: [AD] Transferring bugs to github?

[Beoran <be...@gm...>]

The transfer seems fine, but I'm surprised to see that there are so 
many issues. After we import them we should probably triage them to 
see which ones we will and won't implement , and perhaps make new 
issues that describe the actions better.

Kind Regards,

B.

Re: [AD] Transferring bugs to github?

[SiegeLord <sie...@gm...>]

So I explored this further.

Here's a test repository where I have transferred all bugs and feature 
requests from SourceForge:

https://github.com/allebot/sf-test/issues?q=is%3Aopen+is%3Aissue

Some representative issues:

https://github.com/allebot/sf-test/issues/450

https://github.com/allebot/sf-test/issues/359

allebot is a dummy account I intend to use for transfer to the actual 
Allegro repository. The way github works, you cannot make comments on 
behalf of other users, so all the comments are made by allebot. I tried 
to make it clear who was the original author with a little header. This 
is the only part that is impossible to change, but many other format 
things I can probably alter.

Any comments?

-SL

On 08/01/2015 07:18 PM, SiegeLord wrote:
> Should we transfer the bugs from sourceforge to github? I looked into
> it, and it's in principle possible to do in a minimally lossy way. I can
> handle the actual work involved, but am looking for any opinions on
> whether that's something that we should do. I feel like the reason we
> don't get that many bug reports via sourceforge (instead, we basically
> get all of them via allegro.cc) is that its system is a bit of a pain to
> use, and perhaps we'd get more reports using github's slightly better
> system.
>
> -SL

[AD] Allegro on Gna!

[Peter W. <nov...@gm...>]

Hi,

Allegro has been accepted as a project on Gna!

https://gna.org/projects/allegro

I have created a new mailing list.  Please subscribe if you are interested.
Subscriptions from the old mailing list will NOT be automatically
transferred to the new list.

https://mail.gna.org/listinfo/allegro-developers

I intend to shut down the old list in about one week, then transfer the
archives.  In the mean time, please cross-post messages to both lists.

See you there.

Peter

P.S. Could a couple of interested parties sign up and request to join
the Gna project (or however it is done) so we have multiple admins.
Thanks.

Re: [AD] Windows binary suggestion

[Trent G. <tr...@no...>]

To me that sounds perfect, but let's see what others say.

On 15-08-03 08:59 PM, SiegeLord wrote:
> On 08/03/2015 06:01 AM, Trent Gamblin wrote:
>> But I guess in the end the best thing is to build
>> Allegro yourself to meet your needs if you're going to be distributing
>> anything, and use the binaries to get you started...
> I think that no matter what we do, sometimes this will just have to be
> the best way forward.
>
> Anyway, going back to the dlls. In principle, dlls are there so you can
> replace them without distributing the entire game's binary. The more
> dlls you have, the more fine-grained patches you can make. Perhaps,
> however, it is not important to replace the dependency dlls since, with
> few exceptions, Allegro's dependencies are very stable and don't need to
> be replaced? If that's the case, perhaps there's no issue in statically
> linking the dependencies into the dlls (this is definitely possible,
> it's just not currently done). If there's some issue, you'd just replace
> the Allegro dlls. How does that sound?
>
> -SL
>
> ------------------------------------------------------------------------------

Re: [AD] Windows binary suggestion

[SiegeLord <sie...@gm...>]

On 08/03/2015 06:01 AM, Trent Gamblin wrote:
> But I guess in the end the best thing is to build
> Allegro yourself to meet your needs if you're going to be distributing
> anything, and use the binaries to get you started...

I think that no matter what we do, sometimes this will just have to be 
the best way forward.

Anyway, going back to the dlls. In principle, dlls are there so you can 
replace them without distributing the entire game's binary. The more 
dlls you have, the more fine-grained patches you can make. Perhaps, 
however, it is not important to replace the dependency dlls since, with 
few exceptions, Allegro's dependencies are very stable and don't need to 
be replaced? If that's the case, perhaps there's no issue in statically 
linking the dependencies into the dlls (this is definitely possible, 
it's just not currently done). If there's some issue, you'd just replace 
the Allegro dlls. How does that sound?

-SL

Re: [AD] Windows binary suggestion

[Beoran <be...@gm...>]

Maybe an app virtualization tool could help? http://www.cameyo.com/

Kind Regards,

B.