<Skipp_OSX>
maybe we shouldn't be calling MenusBeginning() in BWindow at all... I'm not actually sure of the case that it is useful for. Anyways Tracker is problematic because of loading add-ons, it's still an issue...
<Skipp_OSX>
but by not calling on MenusBeginning and doing via node monitoring instead the issue should be invisible.
<Skipp_OSX>
It's gotta be a locking issue somewhere, probably in BMenu, can't add/remove items too fast from a menu or crash
erysdren has quit [Quit: Konversation terminated!]
<Skipp_OSX>
I'm convinced it's the same underlying bug that plagued us in the wifi list crashing long ago
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<waddlesplash>
Skipp_OSX: but I fixed that one. Nobody seems to have seen it in years
<Skipp_OSX>
well I didn't exactly fix the bug though, just worked around it by not doing the thing that would make it crash, that is quickly adding and removing items. I added the ability to sort the list so that we wouldn't have to add/remove.
<Skipp_OSX>
this is a similar situation, don't do the thing that makes it crash. Although in this case it didn't make a lot of sense to do it on MenusBeginning() anyway
probono98 has joined #haiku
probono98 has quit []
probono98 has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
KapiX has quit [Quit: KapiX]
AlienSoldier has joined #haiku
<Skipp_OSX>
if we can lick the underlying bug I can turn repeated right-click nav menus back on
<Skipp_OSX>
I've tried to but it crashes (still)
xet7 has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
any idea why I'm getting link error after recent BBlockCache error? https://0x0.st/8aEU.txt
<Skipp_OSX>
I tried removing generated/objects dir but the link error persists
<x512[m]>
Skipp_OSX: > maybe we shouldn't be calling MenusBeginning() in BWindow at all...
<x512[m]>
We should not break API behavior compatibility.
<x512[m]>
It worked fine in BeOS.
<Skipp_OSX>
yeah ok I get it but can you explain the comment?
<x512[m]>
Actually Tracker and Deskbar are derived from original BeOS code, so it was already 100% Haiku R1 ready. Bugs are introduced by Haiku.
<Skipp_OSX>
"Pretend that the user opened a menu, to give the subclass a chance to update its menus. This may install new shortcuts, which is why we have to call it here, before trying to find a shortcut for the given key."
<x512[m]>
How did BeOS behaved?
<x512[m]>
I do not think that this logic should be significantly changed.
xet7 has joined #haiku
<Skipp_OSX>
right I understand which is why I'm working around in Tracker but I still would like the explanation for when this does in fact happen.
<skylar[m]>
is there any workaround for that atheroswifi bug
<x512[m]>
If I understand correctly, MenusBeginning() should be not called on key down.
<Skipp_OSX>
but it is, based on the comment explaining why.
<Skipp_OSX>
and I'm afraid I've made the situation worse by allowing shortcuts without command because this gets called even without cmd down now.
<x512[m]>
Again, was is called in BeOS?
<Skipp_OSX>
without a test case I have no way of knowing.
<x512[m]>
Some simple test program can be made for BeOS.
<x512[m]>
For example Alt+V paste to TextSearch are often not working.
<Skipp_OSX>
waiting on approval since you x86'd my TrackerAddOn.h changes
<x512[m]>
TrackerAddOn should be not changed.
<Skipp_OSX>
I think it's related to start edit not return focus
<Skipp_OSX>
not even to add a message constant?
<x512[m]>
It is BeOS protocol implemented by a lot of existing add-ons.
<Skipp_OSX>
a message constant at least one add-on is already using because it's the message we send it?
<Skipp_OSX>
yeah and those add-ons could benefit from having access to that variable name
<Skipp_OSX>
since it's the message Tracker sends to them, they may want to know the message->what to check.
<x512[m]>
Existing software is a set-in-stone and it must work correctly in future OS versions without any modifications. This is what backward compatibility is.
<Skipp_OSX>
Sure but I don't really see how this would break those apps unless they defined that message constant exactly which is unlikely.
<Skipp_OSX>
they would simply have access to a new message constant that they didn't before, and would otherwise work the same. Unless I'm missing something?
<x512[m]>
Why that message is needed? If it is needed then old software can't use it and will be regressed.
<x512[m]>
It should be implemented in a way that new message is not needed.
<Skipp_OSX>
it's used by the add-on when loaded by Tracker to do stuff. it contains a list of refs for the add-on to use and mime-types.
<Skipp_OSX>
the message is already being sent and used by add-ons including notably Zip-O-Matic which was covered in next commit
<x512[m]>
How old add-ons that not aware of this message will work?
<Skipp_OSX>
by looking for refs inside
<x512[m]>
So what is the problem? Why need to add new message?
<Skipp_OSX>
so that add-ons don't respond to refs send to them by not Tracker.
<Skipp_OSX>
or at least have the chance to by checking the constant.
<x512[m]>
Why it shouldn't?
<Skipp_OSX>
unexpected behavior. Zip-O-Matic popped up on me one time while first boot prompt still loaded.
<x512[m]>
It do not happen in BeOS, so it have a different reason.
<Skipp_OSX>
fine it's not needed to fix the bug I'm after, but I thought it would be nice to share the what of the message we're sending to add-ons.
<Skipp_OSX>
allow them to check it, officially
<x512[m]>
Please avoid so send interleaved unrelated patches.
<Skipp_OSX>
well I mean they are related
<Skipp_OSX>
but I guess they could go on their own stack
<x512[m]>
They are not. Hotkeys handling are unrelated to Tracker add-ons.
<Skipp_OSX>
no it's a bug in Tracker that's related to hot key handling involving loading add-ons
<Skipp_OSX>
it is related though MenusBeginning()
<x512[m]>
It is not bug in Tracker if it reveals in all software, including TextSearch.
<Skipp_OSX>
isn't TextSearch part of Tracker?
<x512[m]>
No, it is stand-alone application.
<x512[m]>
GUI frontend over grep.
<Skipp_OSX>
I don't see how anything I've done could make that stop working except maybe something related to shortcuts
<Skipp_OSX>
I guess I'm not really even trying to fix that bug... or only in Tracker
<x512[m]>
Alt+V sometimes do not work in input field.
<x512[m]>
It worked before shortcut patches.
<Skipp_OSX>
yeah but that's a Tracker add-on...
<x512[m]>
It is separate process.
<x512[m]>
You can launch it without Tracker.
<x512[m]>
Tracker add-on only launch process, it can't affect child process shortcuts behavior.
<Skipp_OSX>
I mean how do I reproduce the bug, I have TextSearch up, what triggers paste to stop working?
<x512[m]>
Behavior is chaotic.
<Skipp_OSX>
yes but I think I know why it's happening
<Skipp_OSX>
it's because you do a file rename and the focus is not returned.
<x512[m]>
It do not work even if manually set focus.
<Skipp_OSX>
yeah but I've seen the bug in Tracker and fixed it, I haven't seen in TextSearch
<x512[m]>
It is generic Interface Kit bug, not specific application bug.
<x512[m]>
I have seen it in other applications.
<Skipp_OSX>
hmmm beats me
<x512[m]>
Maybe some uninitialized variable etc..
<Skipp_OSX>
it would have to be something with shortcuts without command key that's the only thing that touches it
<x512[m]>
Yes probably.
mmu_man has quit [Ping timeout: 480 seconds]
<x512[m]>
About Tracker add-on menu. Maybe we can have only one menu and move it between windows on focus change. That will avoid O(N) menu rebuild cost on opened Tracker windows count.
<Skipp_OSX>
is that how BeOS did it? hehe :/
<Skipp_OSX>
no you need one menu per window if we're going to allow them to be in the menu bar as we apparently are.
<Skipp_OSX>
when they're tucked away into a submenu we do share and rebuild the same menu behind the scenes to see the cost.
<Skipp_OSX>
save cost
<x512[m]>
Of course not as important as fixing bugs. Fixing crashes and broken behavior is top priority. Performance in convenience is after that.
<Skipp_OSX>
Well the bug is fixed in Tracker idk about everywhere else that seems like a different bug
<Skipp_OSX>
not fixed but proposed to be fixed anyway
<Skipp_OSX>
if only heap_debug_get_allocation_info would be found by my linker
<Skipp_OSX>
Libsndfile is a C library for reading and writing files containing sampled sound (such as MS Windows WAV and the Apple/SGI AIFF format) through one standard library interface. It is released in source code format under the Gnu Lesser General Public License.
<Skipp_OSX>
ok good to know thank you
Nasina has quit [Remote host closed the connection]
<Begasus[m]>
added libmp3lame and libmpg123 to it, now all tests pass
<Begasus[m]>
weird thing there though, you need to build static librrary to be able to run the tests
<Begasus[m]>
will probably move the tools into a seperate package also
diver has quit [Quit: Leaving.]
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
Nasina has joined #haiku
diver has quit []
diver has joined #haiku
Nasina has quit [Remote host closed the connection]
diver has quit []
erysdren has quit [Quit: Konversation terminated!]