Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: release of the Postfish (Read 33511 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

release of the Postfish

Reply #25 –
Quote
I guess that's the story of my life:  things that work for most never work for moi ;)

Here is the exact behaviour I get.  I move my mouse over a slider and it turns light blue.  When I click on the slider, it goes dark.  But the moment I drag it, it lights up to light blue again.

I think it's time to upgrade to 2.4.1 (might as well since I downloaded the source).  Things can only get better (or I hope so anyway). ;)

Eh, not so odd for a brand new app that's only seen a few machines. 

Also, that verifies that the mouse button events are not disappearing.  Thanks for the clarification.  I'll grab 2.4.0 and see what's up.

BTW is the 2.4.0 from a package or built from source?

Monty

release of the Postfish

Reply #26 –
QuantomKnot:  I just ran Postfish against a source build of Gtk 2.4.0 here and everything worked properly.

Did the 2.4.1 upgrade fix anything for you?  Does a debug build show any odd warnings or errors?  Are there perhaps more than one mismatched install of gtk on your box?

"Hmm"

Monty

release of the Postfish

Reply #27 –
QuantumKnot:

Having traced through the multibar event handling code, the only likely way the slider dragging could be malfunctioning is if GTK is calling the wrong event callback.

If you're interested in running this in a debugger to see what's going on (I'd be interested to know), build postfish with:

make clean ; make debug

then run it in GDB, interrupt execution with C-c C-c, and then set breakpoints for the following functions:

multibar.c:multibar_focus
multibar.c:button_release
multibar.c:multibar_leave
multibar.c:multibar_motion
multibar.c:unfocus

then, continue execution and try to drag a slider.  The button_press callback isn't breakpointed (because we know it's working), so the first callback that fires *should* be multibar_motion.  My guess is the one that fires is one of the others and that likely indicates a problem with linking against GTK; the callbacks are ending up at the wrong addresses.  If the wrong one *does* fire, does the motion callback get called eventually?

Are any other Mandrake users having the same problem?  There's a good liklihood this is just due to a weird mis-build (either of Postfish or Gtk2 itself) against the wrong headers.  It wouldn't show up in other Gtk apps unless the app in question is implementing custom widget classes.

This is just an initial direction to get the debugging ball rolling.  Or... you could give me a shell with X forwarding :-)

Monty

release of the Postfish

Reply #28 –
I updated to 2.4.1 and still no success.  But I found out the problem.  I changed to Gnome (2.6) and the sliders work perfectly!!  But they don't work in KDE, which is what I use normally.  gtk 2.4.0 came packaged with Fedora Core 2.

But I'll give the debugging a try (in KDE) and let you know how it goes.

EDIT:  I run it through gdb and set the breakpoints.  The instant my mouse enters the window, the breakpoint at multibar_motion.  When I keep continuing, it keeps triggering on the same function.  After a few goes, it goes to the breakpoint at multibar_leave.  Now if I remove these two breakpoints and try to click on the slider, the slider doesn't drag.  Once I release the mouse click, the breakpoint at button_release triggers.

I guess there is something wrong with using gtk apps in KDE.  Can anyone running Postfish in KDE confirm this problem with sliders not dragging?

release of the Postfish

Reply #29 –
Quote
I updated to 2.4.1 and still no success.  But I found out the problem.  I changed to Gnome (2.6) and the sliders work perfectly!!  But they don't work in KDE, which is what I use normally.  gtk 2.4.0 came packaged with Fedora Core 2.

But I'll give the debugging a try (in KDE) and let you know how it goes.

EDIT:  I run it through gdb and set the breakpoints.  The instant my mouse enters the window, the breakpoint at multibar_motion.  When I keep continuing, it keeps triggering on the same function.  After a few goes, it goes to the breakpoint at multibar_leave.  Now if I remove these two breakpoints and try to click on the slider, the slider doesn't drag.  Once I release the mouse click, the breakpoint at button_release triggers.

I guess there is something wrong with using gtk apps in KDE.  Can anyone running Postfish in KDE confirm this problem with sliders not dragging?

QuantunKnot:

Interesting and thanks for narrowing it down further.  So, if you run all the above breakpoints except multibar_motion, what is the order of triggering?  You mention that 'multibar_leave' triggers at some point while you are still in the multibar button?  Does the multibar_leave trigger during the drag attempt? 

Perhaps KDE's windowmanager is delivering mouse attempts in a radically different order/behavior from the others.

Monty

release of the Postfish

Reply #30 –
Quote
QuantunKnot:

Interesting and thanks for narrowing it down further.  So, if you run all the above breakpoints except multibar_motion, what is the order of triggering?  You mention that 'multibar_leave' triggers at some point while you are still in the multibar button?  Does the multibar_leave trigger during the drag attempt? 

Perhaps KDE's windowmanager is delivering mouse attempts in a radically different order/behavior from the others.

Monty

Yes, I removed the breakpoint at multibar_motion because it kept triggering and I couldn't even move my mouse into the Postfish window without it triggering, let alone trying to drag a slider.  After a few cont's, multibar_leave triggers.  Once I remove the one for multibar_motion,  the multibar_leave keeps triggering.  Once I remove that breakpoint, then nothing triggers anymore and I can try clicking on some things in Postfish.  I can click on any button or checkbox and nothing triggers a breakpoint.  When I click on the slider and hold down the mouse, nothing triggers.  I drag it but it doesn't work (and nothing triggers as well).  At the instant I release my mouse button, the breakpoint at button_release triggers.

hmm....Hope this helps.   

I'll try this process in GNOME as well to see what is supposed to happen.  Regarding KDE, I run quite a few gtk programs and they seem to function ok in KDE.

EDIT:  In GNOME, multibar_leave and multibar_motion do most of the triggering.  Removing those, when I click and drag a slider, it drags and nothing triggers.  Once I release my mouse, button_release triggers.  When I continue, then unfocus triggers.

release of the Postfish

Reply #31 –
OK, I was able to reproduce the behavior myself.  The problem is a click-to-focus WM that doesn't use a strict event ordering.  This is perfectly legal behavior, I just hadn't seen it yet, and it broke the code.

Bug is mine, a patch is coming.

Monty

release of the Postfish

Reply #33 –
I tried to compile, I got this error back again.

Code: [Select]
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/svntest/postfish'
make: *** [all] Error 2
Exit 2


EDIT:  Anyway, I took the windowbutton.c from my previous Postfish and it compiles now  And now the sliders work in KDE!!  *does happy dance*

Thanks Monty.

release of the Postfish

Reply #34 –
Quote
I tried to compile, I got this error back again.

Code: [Select]
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/svntest/postfish'
make: *** [all] Error 2
Exit 2


EDIT:  Anyway, I took the windowbutton.c from my previous Postfish and it compiles now :)  And now the sliders work in KDE!!  *does happy dance*

Thanks Monty. :)

Ha, oops!  I had actually checked that the two dev machines were up to date w.r.t SVN, but I guess I missed.

Also, I found a two more cosmetic bugs, so that too will go into SVN when Mofish is back tomorrow (I forgot today was a holiday; the colo isn't staffed on holidays)

Monty

release of the Postfish

Reply #35 –
Here is something new I found out.  It seems when you quit by pressing the close button on the Postfish window, it spits out these errors:

Code: [Select]
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `Multibar'

(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkToggleButton'

(postfish:18904): Gtk-CRITICAL **: file gtktogglebutton.c: line 326 (gtk_toggle_button_get_active): assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed

(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkEntry'

(postfish:18904): Gtk-CRITICAL **: file gtkentry.c: line 3699 (gtk_entry_get_text): assertion `GTK_IS_ENTRY (entry)' failed

Trapped signal 11; saving state and exiting!
This signal almost certainly indicates a bug in the Postfish;
If this version of Postfish is newer than a few months old,
please email a detailed report of the crash along with
processor type, OS version, FFTW3 version, and as much
information as possible about what caused the crash.  The best
possible report will outline the exact steps needed to
reproduce the error, ensuring that we at Xiph can fix the
bug as quickly as possible.

-- monty@xiph.org, Postfish revision 6781 2004-05-29 11:53:59Z


(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `Multibar'

(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkToggleButton'

(postfish:18904): Gtk-CRITICAL **: file gtktogglebutton.c: line 326 (gtk_toggle_button_get_active): assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed

(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkEntry'

(postfish:18904): Gtk-CRITICAL **: file gtkentry.c: line 3699 (gtk_entry_get_text): assertion `GTK_IS_ENTRY (entry)' failed
Segmentation fault
Exit 139


It doesn't do this when you press the 'Quit' button.

release of the Postfish

Reply #36 –
I have a couple of questions: Does it exist a link for a stable windows compile,
and have this "postfish" tool, any to do with Sascha Eversmeier at http://www.digitalfishphones.com. There is similarity in both effects and GUI style,
(endorphin), beside the name "the fish fillets". This postfish "plugin" sounds like it will be the greatest audio tool this year, and it`s still june.

release of the Postfish

Reply #37 –
Quote
I have a couple of questions: Does it exist a link for a stable windows compile,
and have this "postfish" tool, any to do with Sascha Eversmeier at http://www.digitalfishphones.com. There is similarity in both effects and GUI style,
(endorphin), beside the name "the fish fillets". This postfish "plugin" sounds like it will be the greatest audio tool this year, and it`s still june.

There is no Postfish for Windows yet.  It's a Linux application for the time being.

As for 'DigitalFishPhones', this seems to be a complete coincidence (I had not known about it before; the logos are very cute).  The applications do not appear to be very similar, although they're both audio filters.  I'm not sure why you think the GUIs are similar :-)

(Another odd coincidence; Sascha Eversmeier and I are the same age as well.  How very strange!)

In any case, the spinning fish now used by Xiph.Org has been a personal logo for about twelve years (and I used an earlier version of the fish since high-school).  My computer naming scheme is fish-related and xiph.org itself is named after a fish.  I don't actually have any real fish.

The Postfish tool actually began about two and a half years ago and was always named 'Postfish'.  'Post' meaning 'after' (it's for processing audio after recording llive performances) and 'fish' meaning 'fish'. (1)

I hope that clarifies things.

Monty

(1) based on a joke formula pioneered by Dave Barry

release of the Postfish

Reply #38 –
Even more edits!

The bug was actually, in the end, an out-of-order shutdown.
I can't save out UI state if the UI has already disappeared :-)

Patched tarball at http://www.mit.edu/afs/athena/user/x/i/xip...es-20040601.tgz

That work for ya?

Monty
[hooray for finding all the predicted UI interconnect bugs!]

release of the Postfish

Reply #39 –
Quote
Even more edits!

The bug was actually, in the end, an out-of-order shutdown.
I can't save out UI state if the UI has already disappeared :-)

Patched tarball at http://www.mit.edu/afs/athena/user/x/i/xip...es-20040601.tgz

That work for ya?

Monty
[hooray for finding all the predicted UI interconnect bugs!]

Great job.  Now the interface seems to be pretty much bug-free.  Will keep my eyes out as I keep playing with it.

You can go back to OggFile now or else you might get a lot of shouting 

release of the Postfish

Reply #40 –
Quote
Great job.  Now the interface seems to be pretty much bug-free.  Will keep my eyes out as I keep playing with it.

You can go back to OggFile now or else you might get a lot of shouting  :lol: ;)

Heh, I've been working on Oggfile, these have been five minute fixes once you told me the bug was there with enough details :-)

I need to add a patch to prevent the Bessel filters in the companders from denormalizing, then I'll stick it all in SVN.

Monty