FoX: removing widgets

[Yuri Leikind]

Hello all,

When I need to delete some widget, I do it like this:

parent_obj.removeChild(obj_to_remove)

and then create and recalc

But, though the object deleted does not belong anywhere in the hierarchy of GUI objects,
it still exists. I have a ObjectSpace.each_object() loop in my program iterating over some
of FXObjects, setting new font and text. Naturally, doing anything to a removed object
causes error "This FXLabel (or FXWindow, or ...) * already released".

So, I have two questions:

1) Is there a way to find out whether the object has already been released?
2) What else must be done to the FoX object that we want to delete, besides
parent_obj.removeChild(obj_to_remove)

 

[Yuri Leikind]

Correct. Calling removeChild() deletes the underlying C++ object. The
Ruby object that was referring to that C++ object is no longer in use,
but it hasn't been garbage-collected yet.


Yes. Accessing a Ruby object whose C++ partner is gone is a no-no.


I don't guess so (it has never come up). If you were to add this request
to the list of FXRuby bugs at SourceForge, I might add a way to find out
this information in a future FXRuby release.


I guess you can try forcing the garbage collector to run immediately
after the call to removeChild(), i.e.

parent.removeChild(child)
GC.start

Perhaps some variable in my application (or in the FXRuby layer...)
still points to the object, and GC.start doesn't help. I'll take a more
thourough look now, as I see now where the problem might be.

You've been very helpful, as usual, thank you.

 

[Tobias Peters]

Perhaps some variable in my application (or in the FXRuby layer...)
still points to the object, and GC.start doesn't help. I'll take a more
thourough look now, as I see now where the problem might be.

Also keep in mind that the garbage collector is conservative. You may
not assume that every unreferenced object is actually destroyed.

Regards,
Tobias

 

[Sascha Doerdelmann]

When I need to delete some widget, I do it like this:

parent_obj.removeChild(obj_to_remove)

and then create and recalc

For me it often works to make the child invisible instead of removing
it. But when I hide a child I might want to change the layout to use
the new space. I did not find the method "layout" which is implemented
in FOX but seems to be missing in fxRuby. I chose to just resize the
app to it's current size which implies a layout change.

Cheers
Sascha

 

[Nicholas Van Weerdenburg]

I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.

However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?

Thanks,
Nick

 

[Gavin Sinclair]

I won't ask which is better, since I've just read some of the colorful

net discussions on that topic.

However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?

I doubt it's possible to determine. You should just conclude that there
is sufficient usage of both to be able to help you with any problems.

If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?

That's a good question, and the answer is no. Both editors are complex in
their own way, and implement a certain philosophy of text editing. It's a
psychological fit with that philosophy that drives usage, not Ruby
bindings to an API. The former is an order of magnitude more significant
than the latter.

I am an expert in both Vim and Ruby, and don't bother to use the Ruby
bindings. They're cool to have (even thought I rarely have them compiled
in), but I've never thought of doing anything that requires them. BTW, I
hate Vim's inbuilt scripting language.

Cheers,
Gavin

 

[Randy Lawrence]

I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.

However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?

Thanks,
Nick

Well, if you decide to go with Vim, then try to keep your fingers off
the cursor keys. It's a royal pain to change that habit but the rewards
are worth it when you can navigate to any part of a screen full of text
with just a few keypresses--all without changing the position of your
hands...

 

[Nicholas Van Weerdenburg]

I'm sort of stuck between the two. I like them both, but figure it's
more productive to stick with one for a stretch. I figured maybe I'd go
with the one that was more attuned with Ruby culture, if there was such
a learning.

I'm on OS/X if that makes any difference.

Thanks,
Nick

 

[Rando Christensen]

I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.

However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?
If so, is this because of VIM's potential to be compiled with Ruby
bindings to it's API?

Rather than looking at it for what it's language bindings are, it's
better to concentrate on the actual core philosophy behind each of the
editors.

The one you decide to use should be whichever editor philosophy fits
your own style better. Especially vim's modal editing against emacs's
more classical style of operation. It depends a lot on how you gather
your own thoughts while programming, and it's really the largest factor
as to which will make you a more efficient programmer in the long run.

The ruby bindings aren't really that important or cool.

 

[Cameron McBride]

Hey Nick,

I'm sort of stuck between the two. I like them both, but figure it's
more productive to stick with one for a stretch. I figured maybe I'd go
with the one that was more attuned with Ruby culture, if there was such
a learning.

nope (not that I'd really know). As was elgantly put by Gavin, they
"implement a certain philosophy of text editing." Pick one
philosophy, and stick to it for a stretch. After that, feel free to
try the other if it suits you.

I'm on OS/X if that makes any difference.

nope. no difference. both are freely available for OS/X.

Cameron

 

[Robert Klemme]

I won't ask which is better, since I've just read some of the colorful
net discussions on that topic.


However, I've been mucking about in each, and am about to pick one to
learn well. I get the impression that this list is about 2 to 1 in VIMs
favour for usage (where either is being used). Is this roughly accurate?

Dunno. I do most Ruby editing with Textpad. (Although, in case you
wanted to know which one I use on Linux, it's emacs.)

Regards

robert

 

[Josh Huber]

Well, if you decide to go with Vim, then try to keep your fingers off
the cursor keys. It's a royal pain to change that habit but the
rewards are worth it when you can navigate to any part of a screen
full of text with just a few keypresses--all without changing the
position of your hands...

Same deal with Emacs. Try and get used to using the cursor
positioning commands versus the pgup/pgdown/arrow-keys -- you'll
end up moving your hands MUCH less. If you go the Emacs route,
you may also want to look into swapping the capslock key with the
control key, since it seems to be much more comfortable. (at
least, it is for me)

 

[Lennon Day-Reynolds]

Can I just say how impressed I am that one of the oldest and most
incindiary questions in the open source world (Vim vs. Emacs) is being
discussed with such civility in this thread?

Now, if we could only reach such an understanding about programming
paradigms, we'd be set...

Lennon

 

[tony summerfelt]

The ruby bindings aren't really that important or cool.

i guess it depends on how and how much you extend the capabilities of
your current editor.

i left the emacs fold ages ago but at the time you were stuck with
elisp if you wanted to extend the editor...

with vim you have your choice between ruby, perl, python (and i
believe lua)

i have vim built with both ruby and perl. i think it's VERY cool to
add an extension to my editor using one of the languages i program
in. i haven't written many ruby functions for vim yet, but i've
written a few perl ones...