Not entirely sure, but i get the feeling that it has gotten "worse". That is, i no longer need to mess with the power button to get the asui net window to eat all screen taps.
Do you have a log? The hack actually fixes a really bad bug but goes about it by making the main thread burn the cpu for one cycle until the dbus thread gets scheduled again and grabs the MapNotify. This could've aggravated another bug.
btw, this seems easier to provoke when having the screen black set to say 30 seconds then 2 minutes (my preferred as it rarely gets in the way of reading a longer text).
I just tell it to turn the display off via an ssh command. But I've also let it timeout after 10/30 and only reproduced it that one time when the main loop caught the MapNotify.
The new test/debug build uses a private event loop for the blank window. I'll take a log from the build you have, if you produce one before installing this build.
There was an open wifi network at my sister's house tonight and I found that the test code does not work but figured out how to make it work. So ignore my previous post.
The new test/debug binaries should display the network name in the wifi widget instead of the GUID.
w00t, auouymous!
Latest version works finally. I tried several of the early 2.X builds and they weren't working properly at all (wasn't added to start-up, wouldn't run on manual launch, power menu still came up, etc.)
And confirmed on the latest test-binary displaying the ESSID. Thanks a lot
fix: always display network name instead of GUID (thanks to wklink)
fix: the "ASUI NET" window has its own display connection and event loop so main thread can't steal its map event, keeping the window from closing
fix: update current_time in dbus thread so debug file and hw_query_battery() have correct time
fix: refactored set_string() to avoid threading problems and properly free memory
wifi widget now displays IP address when connected (thanks to jstokes)
added a long press tap marker on fullscreen clock and moved keep-lit icon to other corner
After I first packaged this release it segfaulted when I entered flight mode to disconnect the wifi and happened each time. The test and debug binaries built from the same source would not crash, making it difficult to track down. I did find and fix three bugs that could cause a crash but I doubt any of them were causing the crash I was looking for. The new release hasn't crashed yet so let me know if it crashes for any of you guys.
I'm working on keycode locking support for the next release and will have a setting to disable the secure button to prevent accidental locking for those who don't want it and can't remember their code. I'm thinking it should default to disabled and force those who want to use it to go enable it. What do you guys think?
there is a slight issue when using ppp connections right now. While the text says "connected" and there is a ip address shown, the square stays gray and tapping the wifi button seems to trigger a connection cycle rather then a disconnect.
