fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Stef <st...@ch...>]

Lyle wrote:
> When you referred to it as "remarking", I thought for a moment that
> you 
> were referring to the technique in which the bug disappears as soon as 
> you tell someone else about it ;)
> 

Hah! no, not quite that unlucky, although i do 'fondly' remember
the days of C programming and the ever so fun problem of 'it
works when i remove my comments' ;)

> > One last teeny tiny probably stupid question, which i know
> > breaks OO design but, how would i tie a 'connect' onto a
> > button from another class ? Can you typecast the connect
> > so that it knows its going onto a FXButton in an instance 
> > variable or is there a 'widget controller' which i can 
> > query to get an FXButton 'handle' passed to me?
> 
> If I understand what you're asking, I think I would just second Hugh's 
> recommendation of putting whatever code is necessary in the block to 
> call the desired method on the other button, e.g.
> 
>      button1.connect(SEL_COMMAND) {
>          button2.doSomething
>      }
> 

I understand that this is probably the way that is simpliest
however I also believe that reductionism is 'good'. It is
preferable in my eyes not to have the same code repeated
multiple times in different classes, when it should (in my eyes)
belong in the 'parent' class. 

Imagine this example:

class Funky < FXDialogBox
   def initialize 
      accept=FXButton.new(buttons, "&Accept", nil, self, ID_ACCEPT,
      FRAME_RAISED|FRAME_THICK|LAYOUT_RIGHT|LAYOUT_CENTER_Y)
   end
end

class Mojo < FXMainWindow
    def initialize 
         @lp_dialog=Funky.new(self)
    end
end

now, from inside the Mojo class, how would I go about tying the
connect on the accept to a procedure/method or callback ?


I know it may sound crazy, but if i can do one line such as 
'(FXButton)@lp_dialog.accept.connect(SEL_METHOD... etc)
surely that has to be better than the 20 or 23 or so lines that
I need to do to create my 'Funky' dialog in the other classes ?

Thanks for the pointers (no pun intended) though, most helpful
and glad to see that there is a 'live community' that I can learn
and support. Lack of arrogance also seems to be a 'Fox Community'
strongpoint (unlike certain other Toolkits developers :D

regards and thanks
Stef

Re: [Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Lyle J. <jl...@cf...>]

Stef T wrote:

> Actually, i went back to a tried and tested debugging
> technique called 'remarking' :) Basically, an earlier
> version was working as expected under Win32, so checked
> it out from CVS, compared the differences and one by
> one remarked out the bits and re-ran it.

When you referred to it as "remarking", I thought for a moment that you 
were referring to the technique in which the bug disappears as soon as 
you tell someone else about it ;)

> One last teeny tiny probably stupid question, which i know
> breaks OO design but, how would i tie a 'connect' onto a
> button from another class ? Can you typecast the connect
> so that it knows its going onto a FXButton in an instance 
> variable or is there a 'widget controller' which i can 
> query to get an FXButton 'handle' passed to me?

If I understand what you're asking, I think I would just second Hugh's 
recommendation of putting whatever code is necessary in the block to 
call the desired method on the other button, e.g.

     button1.connect(SEL_COMMAND) {
         button2.doSomething
     }

Lyle

Re: [Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Hugh S. S. E. E. <hg...@dm...>]

On Wed, 10 Dec 2003, Stef T wrote:

> One last teeny tiny probably stupid question, which i know
> breaks OO design but, how would i tie a 'connect' onto a
> button from another class ? Can you typecast the connect
> so that it knows its going onto a FXButton in an instance
> variable or is there a 'widget controller' which i can
> query to get an FXButton 'handle' passed to me ?

Excuse me jumping in.  Though I'm not sure I understand the above...
>
> (i have a single login/password dialog, and depending on
>  where the person 'okays', i want to run a different method
>  in different classes, if you see what i mean :)

...Then just use the block to send appropriate messages to the
desired destination objects.  Or have I really missed something
big? I think encapsulation means being clear about your interfaces,
not complete isolationism...
>
> Sorry for the really 'clumsy' way of doing this :)
> Many thanks and best regards
> Stef
>

        Hugh, who doesn't consider himself fluent in FXRuby matters
        yet.

Re: [Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Stef T <st...@ch...>]

Lyle wrote:
> I don't *see* anything that looks wrong, but it's hard to tell without 
> having all of the code in hand and thus being able to reproduce the 
> problem(s). If you'd like to send the rest of the code (everything 
> needed to run it), I can take a look. [Probably best to send it off-list.]
> 

Actually, i went back to a tried and tested debugging
technique called 'remarking' :) Basically, an earlier
version was working as expected under Win32, so checked
it out from CVS, compared the differences and one by
one remarked out the bits and re-ran it. 

Not the most scientific approach, granted, but i narrowed
it down to the 4 buttons newly added at the bottom. Here
is one of them:

XButton.new(bot2_hform, "Store", nil, self, 0,
FRAME_RAISED|LAYOUT_FILL_X)

for some reason, i was passing in 'self' instead of 'nil'.
Changing that fixed it all up and now the program is layed
out as desired. 

FXRuby is not my usual widget toolkit (i am a glade/gtk
person by nature) so sorry if this is also causing some
confusion with my code :) (of course, for Win32, gtk is
jst awful, whereas Fox works very well :)



One last teeny tiny probably stupid question, which i know
breaks OO design but, how would i tie a 'connect' onto a
button from another class ? Can you typecast the connect
so that it knows its going onto a FXButton in an instance 
variable or is there a 'widget controller' which i can 
query to get an FXButton 'handle' passed to me ?

(i have a single login/password dialog, and depending on
 where the person 'okays', i want to run a different method
 in different classes, if you see what i mean :)

Sorry for the really 'clumsy' way of doing this :)
Many thanks and best regards
Stef

Re: [Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Lyle J. <jl...@cf...>]

Stef T wrote:

> 	well, the subject sort of says it all really.
> Below is my code, and it works flawlessly under linux,
> however, when it runs under Win32, two things happen.
> 
> 	Firstly, the window appears at a size of about
> 20 high by 80 wide. Secondly, the first button (called
> 'Store') doesnt appear at all.
> 
> 	Apart from obviously the logic behind the buttons
> missing, and obviously the 'myFoxCal' logic isnt there,
> but apart from that can anyone tell me what else is 
> 'missing' as it were or what i am doing wrong ?

I don't *see* anything that looks wrong, but it's hard to tell without 
having all of the code in hand and thus being able to reproduce the 
problem(s). If you'd like to send the rest of the code (everything 
needed to run it), I can take a look. [Probably best to send it off-list.]

Re: [Fxruby-users] How to show stuff created at run time (not the easy question)

[Lyle J. <ly...@kn...>]

On Dec 9, 2003, at 7:27 PM, Will Merrell wrote:

> Now, does the @propertyFrame.removeChild(@matrix) call also clean up 
> all of
> the elements contained in @matrix, or do I also need to clear them out?

Yes, removeChild() first unlinks that child widget (@matrix) from its 
parent's list of child widgets, and then it blows the child and all of 
its children away.

> Further, how does Ruby's garbage collection play into this? What gets
> automatically cleaned up, and what do I need to explicityl clean up?

The garbage collector should do the right thing; you shouldn't need to 
explicitly clean up anything in this case.

[Fxruby-users] RE: [Foxgui-users]FOX Community

[Will M. <wi...@co...>]

Sander Jansenwrote:
> www.fifthplanet.net is up again. (although I still have 
> problems with my machine.)

Bless you. 

And thank you for the work you do on this.

	--Will

[Fxruby-users] FOX Community

[Sander J. <sa...@kn...>]

www.fifthplanet.net is up again. (although I still have problems with my 
machine.)

	Sander


-- 
"I've had a wonderful time, but this wasn't it." 
	- Groucho Marx (1895-1977)

[Fxruby-users] Strange Behaviour under Win32 with FXRuby

[Stef T <st...@ch...>]

Hello everyone,
	well, the subject sort of says it all really.
Below is my code, and it works flawlessly under linux,
however, when it runs under Win32, two things happen.

	Firstly, the window appears at a size of about
20 high by 80 wide. Secondly, the first button (called
'Store') doesnt appear at all.

	Apart from obviously the logic behind the buttons
missing, and obviously the 'myFoxCal' logic isnt there,
but apart from that can anyone tell me what else is 
'missing' as it were or what i am doing wrong ?

	thanks
	Stef
(ps also the variable names and class names probably could
    be better, i know ;)

RE: [Fxruby-users] How to show stuff created at run time (not the easy question)

[Will M. <wi...@co...>]

Lyle Johnson wrote:
> Have not tried running your sample code yet,

Don't bother, I did not include the code that calls this.

> but see what happens if you replace the
> calls to resize() with a call to recalc():
>
>	@inspectordlg.recalc

There it is, that works. That is the function that I was looking for, but
with www.fifthplanet.net down I could not find it. Thank you.


> I see another potential problem with the code,
> which is that every call to ObjectInspector#set
> adds a new FXMatrix widget to the dialog box
> (@inspectordlg). Unless I'm just misreading
> things, I suspect that you'll want to first
> remove the old matrix first, i.e.
>
>		# Out with the old...
>		@propertyFrame.removeChild(@matrix)

Yes, I was fairly sure that I had a problem with that, and no you weren't
misreading things. The ObjectInspector#clear method was intended for just
that purpose, but I had not been able to figure out what to put in it. (that
www.fifthplanet.net down thing again.) removeChild is obviously correct.

Now, does the @propertyFrame.removeChild(@matrix) call also clean up all of
the elements contained in @matrix, or do I also need to clear them out?
Further, how does Ruby's garbage collection play into this? What gets
automatically cleaned up, and what do I need to explicityl clean up?


> Hope this helps,
>
> Lyle

Yes it does, and thank you for the timly response.

	--Will

Re: [Fxruby-users] How to show stuff created at run time (not the easy question)

[Lyle J. <ly...@kn...>]

On Dec 9, 2003, at 6:08 PM, Will Merrell wrote:

> One of my questions is how to add gui elements at run time. Now I know 
> all
> about needing to call create and all of that, and if you check out the
> included code below, you'll see that I am doing so. The problem is 
> that when
> I do what I think is proper, the added elemnts do not show up. The 
> weird
> part is that if I resize the dialog, then they suddenly show up working
> fine. In fact if I add two lines to programatically resize it (as 
> shown in
> the code,) then the dialog works exactly as it should. But that seems 
> like a
> really hokie hack job, and I can't believe it is the proper way to do 
> it.
> So, what is?

Have not tried running your sample code yet, but see what happens if 
you replace the calls to resize() with a call to recalc():

	@inspectordlg.recalc

I see another potential problem with the code, which is that every call 
to ObjectInspector#set adds a new FXMatrix widget to the dialog box 
(@inspectordlg). Unless I'm just misreading things, I suspect that 
you'll want to first remove the old matrix first, i.e.

	def set(newobj)
		@targetObject = newobj

		# Out with the old...
		@propertyFrame.removeChild(@matrix)

		# ... and in with the new.
		@matrix = FXMatrix.new(@propertyFrame, ...)

		# ... complete matrix setup ...		
	end

Hope this helps,

Lyle

[Fxruby-users] Disconnecting Foxtails Elements

[Will M. <wi...@co...>]

Hi, This question is mostly for Joel VanderWerf, but if any one else has any
ideas please jump in.

The question is how to cancel the observation of a variable in a Foxtails
element? As you can see in the included code below, (Yes its the same code I
included in my other message today.) I am adding several FTTextFields to
watch some variables in another object.

The object I wish to observe changes from time to time so these fields need
to be added dynamically. So the specific question is: when I stop observing
one object and start observing a new object what do I need to do to clean up
the observations on the old object?

In the Observable library that you wrote there are cancel_when_* methods
that do this job, what are the equivilent methods for Foxtails?

Thanks,
	--Will


==================== begin include =================
#!/usr/bin/env ruby

require 'fox'
require 'fox/responder'
require 'observable'
require 'foxtails'

include Fox
include Observable
include FoxTails

class ObjectInspector
  include Responder

  extend Observable

  def initialize(app, proj)
    @targetObject = nil
    createWindow(app, proj)
  end

  def createWindow(app, proj)
    @app = app
    @project = proj

    @inspectordlg = FXDialogBox.new(app, "Inspector",
      DECOR_BORDER|DECOR_RESIZE|DECOR_TITLE, 0, 0, 150, 300)

    @matrix = FXMatrix.new(@inspectordlg, 2,
      MATRIX_BY_COLUMNS|LAYOUT_FILL_X)

  end

  def clear()
    @matrix.hide
  end

  def set(newobj)
    @targetObject = newobj

    @matrix = FXMatrix.new(@propertyFrame, 2,
      MATRIX_BY_COLUMNS|LAYOUT_FILL_X)

    # First row
    FXLabel.new(@matrix, "Property", nil, LAYOUT_FILL_COLUMN)
    FXLabel.new(@matrix, "Value", nil, LAYOUT_FILL_COLUMN)

    # First row
    FXLabel.new(@matrix, "Type", nil, LAYOUT_FILL_COLUMN)
    FXLabel.new(@matrix, @targetObject.name, nil, LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Left", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :left,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Right", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :right,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Top", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :top,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Bottom", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :bottom,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    @inspectordlg.create
    @inspectordlg.show

#    @inspectordlg.update
#    @inspectordlg.repaint

    @inspectordlg.resize(@inspectordlg.width + 1, @inspectordlg.height)
    @inspectordlg.resize(@inspectordlg.width - 1, @inspectordlg.height)

  end

  # Close the Inspector Windows
  def close
    @inspectordlg.hide
  end

  # Create and show the main window
  def create
    # Create the windows
    @inspectordlg.create
    @inspectordlg.show(PLACEMENT_DEFAULT)
  end
end
===================== end include ==================

[Fxruby-users] How to show stuff created at run time (not the easy question)

[Will M. <wi...@co...>]

Hi, I am using FXRuby to test out some ideas for an app that I am thinking
about writing. FXRuby is proving to be good for quickly trying out ideas to
see what will work well.

One of my questions is how to add gui elements at run time. Now I know all
about needing to call create and all of that, and if you check out the
included code below, you'll see that I am doing so. The problem is that when
I do what I think is proper, the added elemnts do not show up. The weird
part is that if I resize the dialog, then they suddenly show up working
fine. In fact if I add two lines to programatically resize it (as shown in
the code,) then the dialog works exactly as it should. But that seems like a
really hokie hack job, and I can't believe it is the proper way to do it.
So, what is?

PS. I am running this on a windows XP machine using a recent (within the
last month or two) version of the windows Ruby install from Dave and Andy's
site. I have not tried this on any other machine yet.

Any help would be appreciated.

	--Will



==================== begin include =================
#!/usr/bin/env ruby

require 'fox'
require 'fox/responder'
require 'observable'
require 'foxtails'

include Fox
include Observable
include FoxTails

class ObjectInspector
  include Responder

  extend Observable

  def initialize(app, proj)
    @targetObject = nil
    createWindow(app, proj)
  end

  def createWindow(app, proj)
    @app = app
    @project = proj

    @inspectordlg = FXDialogBox.new(app, "Inspector",
      DECOR_BORDER|DECOR_RESIZE|DECOR_TITLE, 0, 0, 150, 300)

    @matrix = FXMatrix.new(@inspectordlg, 2,
      MATRIX_BY_COLUMNS|LAYOUT_FILL_X)

  end

  def clear()
    @matrix.hide
  end

  def set(newobj)
    @targetObject = newobj

    @matrix = FXMatrix.new(@propertyFrame, 2,
      MATRIX_BY_COLUMNS|LAYOUT_FILL_X)

    # First row
    FXLabel.new(@matrix, "Property", nil, LAYOUT_FILL_COLUMN)
    FXLabel.new(@matrix, "Value", nil, LAYOUT_FILL_COLUMN)

    # First row
    FXLabel.new(@matrix, "Type", nil, LAYOUT_FILL_COLUMN)
    FXLabel.new(@matrix, @targetObject.name, nil, LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Left", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :left,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Right", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :right,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Top", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :top,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    FXLabel.new(@matrix, "Bottom", nil, LAYOUT_FILL_COLUMN)
    FTTextField.new(@matrix, 17, @targetObject, :bottom,
      FRAME_SUNKEN|LAYOUT_FILL_COLUMN)

    @inspectordlg.create
    @inspectordlg.show

#    @inspectordlg.update
#    @inspectordlg.repaint

    @inspectordlg.resize(@inspectordlg.width + 1, @inspectordlg.height)
    @inspectordlg.resize(@inspectordlg.width - 1, @inspectordlg.height)

  end

  # Close the Inspector Windows
  def close
    @inspectordlg.hide
  end

  # Create and show the main window
  def create
    # Create the windows
    @inspectordlg.create
    @inspectordlg.show(PLACEMENT_DEFAULT)
  end
end
===================== end include ==================

Re: [Fxruby-users] Segmentation fault when changing the icon for a button

[Bil <bi...@vi...>]

Carsten,

You need to icon.create before you return icon from loadIcon (or at least,=
 before you use button.icon=3D). The reason is that MainWindow.create calls=
 icon.create for "first" icon as it a 'grand-child' of MainWindow at the=
 moment that MainWindow is created. The "second" icon you load up later=
 will need to be 'create'd manually before use. It doesn't matter if you=
 create something too many times (I think it is just ignored), as long as=
 it is done at least once before you attempt to use it.

bil

*********** REPLY SEPARATOR  ***********

On 08/12/2003 at 19:40 Carsten Eckelmann wrote:

>Hi,
>
>I'm banging my head against this problem for days now: I have a button 
>which displays an icon and then when the button is pressed it should 
>display another icon. So the first icon is displayed fine but when I 
>press the button the app chrashes with a segmentation fault. I'm testing 
>this with the 'Pragmatic Installer 1.8.0-10' on Windows 2000.
>
>Here's the code:
>#------------------------------------------
>
>require 'fox'
>include Fox
>class MainWindow < FXMainWindow
>  # load a png image from file
>  def loadIcon(filename)
>    begin
>      icon =3D nil
>      File.open(filename+".png", "rb") { |f|
>        icon =3D FXPNGIcon.new(getApp(), f.read)
>      }
>      icon
>    rescue
>      raise RuntimeError, "Couldn't load icon: #{filename}"
>    end
>  end
>  # initialize the window
>  def initialize(app)
>    super(app, "Test", nil, nil, DECOR_ALL, 0, 0, 0,0, 0, 0)
>    button =3D FXButton.new(self,"")
>    # set the buttons icon to the first image -> works well.
>    button.icon =3D loadIcon("first")
>    # when the button is pressed, change the icon
>    # to the second image -> BOOM!
>    button.connect(SEL_COMMAND) { button.icon =3D loadIcon("second") }
>    end
>  # create the window
>  def create
>    super
>    show(PLACEMENT_SCREEN)
>  end
>end
># create and run the application
>app =3D FXApp.new("Test", "Test")
>MainWindow.new(app)
>app.create
>app.run
>#------------------------------------------
>
>It also doesn't work for FXlabel and FXImageView. What am I doing wrong 
>here?????? Help!
>
>Carsten.
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Fxruby-users mailing list
>Fxr...@li...
>https://lists.sourceforge.net/lists/listinfo/fxruby-users

[Fxruby-users] Segmentation fault when changing the icon for a button

[Carsten E. <ca...@ci...>]

Hi,

I'm banging my head against this problem for days now: I have a button 
which displays an icon and then when the button is pressed it should 
display another icon. So the first icon is displayed fine but when I 
press the button the app chrashes with a segmentation fault. I'm testing 
this with the 'Pragmatic Installer 1.8.0-10' on Windows 2000.

Here's the code:
#------------------------------------------

require 'fox'
include Fox
class MainWindow < FXMainWindow
  # load a png image from file
  def loadIcon(filename)
    begin
      icon = nil
      File.open(filename+".png", "rb") { |f|
        icon = FXPNGIcon.new(getApp(), f.read)
      }
      icon
    rescue
      raise RuntimeError, "Couldn't load icon: #{filename}"
    end
  end
  # initialize the window
  def initialize(app)
    super(app, "Test", nil, nil, DECOR_ALL, 0, 0, 0,0, 0, 0)
    button = FXButton.new(self,"")
    # set the buttons icon to the first image -> works well.
    button.icon = loadIcon("first")
    # when the button is pressed, change the icon
    # to the second image -> BOOM!
    button.connect(SEL_COMMAND) { button.icon = loadIcon("second") }
    end
  # create the window
  def create
    super
    show(PLACEMENT_SCREEN)
  end
end
# create and run the application
app = FXApp.new("Test", "Test")
MainWindow.new(app)
app.create
app.run
#------------------------------------------

It also doesn't work for FXlabel and FXImageView. What am I doing wrong 
here?????? Help!

Carsten.

Re: [Fxruby-users] [ANN] FoxTails 0.2

[Joel V. <vj...@PA...>]

Joel VanderWerf wrote:

> The DRb-based examples don't seem to work on my windows box at work. 
> Maybe 'druby://localhost:9200' doesn't make sense in windows. I'll try 
> using a hostname or ip tomorrow...

That seems to be a local problem with drb. Other drb samples do not work 
on this windows box, but the TCP server example that comes with ruby 
does work.

Re: [Fxruby-users] [ANN] FoxTails 0.2

[Joel V. <vj...@PA...>]

Three cautions:

Make sure you use the latest FXRuby (1.0.27, at least), rather than 
whatever is in the Ruby Windows installer--Lyle recently fixed a bug 
that affected the tree browser examples.

The examples/tree-fancy.rb needs the rbtree extension to work (it's at RAA).

The DRb-based examples don't seem to work on my windows box at work. 
Maybe 'druby://localhost:9200' doesn't make sense in windows. I'll try 
using a hostname or ip tomorrow...

[Fxruby-users] [ANN] FoxTails 0.2

[Joel V. <vj...@PA...>]

Here's the latest FoxTails, version 0.2. Some high points, followed by
low points:

   - Updated to Ruby 1.8.0.

   - An early alpha version of FTTreeBrowser and some "Treelike"
     classes.

   - Several new examples:

     - examples/input-output-windows.rb, in answer to a suggestion by
       Will Merrell to show how to connect observable attrs in different
       windows (hope it helps). It also shows the use of pattern
       matching in "when_var" clauses.

     - examples/chat-server.rb and examples/chat-client.rb show how to
       use Drb+FXRuby+FoxTails to build distributed GUIs. (You need
       Obervable 0.2 for this--see below.)

     - Two interesting looking but slightly broken examples of the tree
       browser, examples/tree.rb and examples/tree-fancy.rb.

   - Still not much documentation (but what there is is in RDoc format,
     so at least it looks good :-).

   - The FTTreeBrowser stuff has some problems--it's really just a
     preview for now.

What is FoxTails?

FoxTails is a set of pure Ruby extensions for FXRuby. The most useful
part of FoxTails is the use of observable attributes to connect GUI
components, as an alternative to directly using Fox's target mechanism.
It helps you separate your Ruby object model from the GUI
representation. It's very easy to use. See the examples.

Some features:

- Deferred targets. By using a code block (in place of the object
   itself) to indicate the target of a widget, there is no need to worry
   about initialization order, which leads to better decoupling.

- In the FoxTails API, the argument lists have the same form as Fox
   argument lists, except that the tgt,sel args are replaced by a
   target, an accessor, and sometimes other args. So it's easy to use
   existing documentation and to convert old programs.

- Works with existing accessors provided by FXRuby (e.g., enabled=,
   etc.) (see examples/scroll.rb).

- Updates happen with no delay! (This is esp. nice for menus, which
   always bothered me in Fox.)

- Values (e.g. in text fields, combo boxes) can be anything, not just
   number or string (see examples/combo.rb).

To get it:

   http://redshift.sourceforge.net/foxtails

You also need:

   http://redshift.sourceforge.net/observable

If you already have observable 0.1, you need to update to 0.2 for the
drb examples to work.

--

Joel VanderWerf
mailto:vj...@us...

[Fxruby-users] New Poll on FOX Community

[Sander J. <sa...@kn...>]

After months of a useless poll (ok.. I was probably drinking that night, when 
I created it), I started a new poll on the FOX Community Wiki site.

For the new poll:
http://www.fifthplanet.net/cgi-bin/wiki.pl?Home

For previous poll results:
http://www.fifthplanet.net/cgi-bin/wiki.pl?Poll_Archive

If you have any suggestions or ideas for next polls, please don't hestitate to 
mail me.

	Sander
-- 
"I've had a wonderful time, but this wasn't it." 
	- Groucho Marx (1895-1977)

Re: [Fxruby-users] controlling a FXComboBox size

[Sander J. <sa...@kn...>]

ie. LAYOUT_FILL_X prevents the resizing when you select from the list.


On Wednesday 03 December 2003 09:15 pm, Sander Jansen wrote:
> In my experience, for FXComboBox I use the LAYOUT_FILL_X style since it may
> resize itself based on the string it is displaying (so unless you have set
> to biggest string it will have to display, it always adjust its size...
> very annoying).
>
> 	Sander
>
>
> On Wednesday 03 December 2003 08:15 pm, Lyle Johnson wrote:
>
> 0> On Dec 3, 2003, at 4:09 PM, Brett S Hallett wrote:
> > > Find attached a few (small :-) example programs that I generated , the
> > > only
> > > one that produces a "correct" combobox is the one (testfox.rb) which
> > > explicitly uses the coordinate AND size parameters, in every other
> > > case I get
> > > a VERY narrow displayed field ( and drop down field).
> > >
> > > I suspect that I am simply not using the correct opts= parameters to
> > > get the
> > > desired effect, which is :
> > >
> > > a) let the user define the width & height of the combobox field
> > > b) let the field fall into its 'natural' position depending upon the
> > > frame
> > >    type declared.
> >
> > When you specify an explicit (a.k.a. fixed) width for the combo-box,
> > there is obviously no question as to which size the layout manager
> > should assign to that combo-box. But if you don't specify a fixed
> > width, the layout manager needs some other way to determine an
> > appropriate default size for it. (This is of course true for any child
> > widget, but today we're talking about combo-boxes ;)
> >
> > For the combo-box (as well as text fields, and some other widgets) the
> > default size depends on the number of columns passed in as an argument
> > to the constructor. In the case of your examples, you're passing in 1
> > as the number of columns, e.g.
> >
> > 	postcode = FXComboBox.new(combo, 1, 10, nil, 0,
> > FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)
> >
> > which causes the combo-box to report a very small default width, since
> > it thinks it only needs to be wide enough to display a string that is
> > one character long. To quickly prove this to yourself, simply change
> > the above line (from testfox1.rb) to read something like:
> >
> > 	postcode = FXComboBox.new(combo, 8, 10, nil, 0,
> > FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)
> >
> > and you should like the result better. Of course, the "right" number of
> > columns is going to depend on the lengths of the items' text, which you
> > don't know in advance. Some people get around this by adjusting the
> > number of columns after all of the items have been added, e.g.
> >
> > 	comboBox = FXComboBox.new(p, 1, ...)
> > 	maxStringLen = 0
> > 	itemStrings.each do |itemString|
> > 		comboBox.appendItem(itemString)
> > 		maxStringLen = [maxStringLen, itemString.length].max
> > 	end
> > 	comboBox.numColumns = maxStringLen
> >
> > > Also note the file "testfox.fxs" which is FOX Script Language I am
> > > developing
> > > to see if this shorthand technique of describing forms is a viable
> > > technique.
> > > Although I've had plenty of experience with DELPHI, et al, I'm not
> > > convinced
> > > that a GUI IDE is necessarly the most efficient method for describing
> > > forms
> > > when the developers Language (Ruby) is using a independent GUI tool.
> > > Delphi
> > > works well because of the very tight intergration of Form/Language.
> >
> > I've never used Delphi itself, but have used Borland C++ Builder which
> > is closely related, and yes, it is very nice. A lot of people are
> > interested in "GUI building" tools for FOX and FXRuby (see for example
> > http://fox-tool.rubyforge.org) and so I'm glad you're investigating
> > this alternative approach.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Fxruby-users mailing list
> > Fxr...@li...
> > https://lists.sourceforge.net/lists/listinfo/fxruby-users

-- 
"I've had a wonderful time, but this wasn't it." 
	- Groucho Marx (1895-1977)

Re: [Fxruby-users] controlling a FXComboBox size

[Sander J. <sa...@kn...>]

In my experience, for FXComboBox I use the LAYOUT_FILL_X style since it may 
resize itself based on the string it is displaying (so unless you have set to 
biggest string it will have to display, it always adjust its size... very 
annoying).

	Sander


On Wednesday 03 December 2003 08:15 pm, Lyle Johnson wrote:
0> On Dec 3, 2003, at 4:09 PM, Brett S Hallett wrote:
> > Find attached a few (small :-) example programs that I generated , the
> > only
> > one that produces a "correct" combobox is the one (testfox.rb) which
> > explicitly uses the coordinate AND size parameters, in every other
> > case I get
> > a VERY narrow displayed field ( and drop down field).
> >
> > I suspect that I am simply not using the correct opts= parameters to
> > get the
> > desired effect, which is :
> >
> > a) let the user define the width & height of the combobox field
> > b) let the field fall into its 'natural' position depending upon the
> > frame
> >    type declared.
>
> When you specify an explicit (a.k.a. fixed) width for the combo-box,
> there is obviously no question as to which size the layout manager
> should assign to that combo-box. But if you don't specify a fixed
> width, the layout manager needs some other way to determine an
> appropriate default size for it. (This is of course true for any child
> widget, but today we're talking about combo-boxes ;)
>
> For the combo-box (as well as text fields, and some other widgets) the
> default size depends on the number of columns passed in as an argument
> to the constructor. In the case of your examples, you're passing in 1
> as the number of columns, e.g.
>
> 	postcode = FXComboBox.new(combo, 1, 10, nil, 0,
> FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)
>
> which causes the combo-box to report a very small default width, since
> it thinks it only needs to be wide enough to display a string that is
> one character long. To quickly prove this to yourself, simply change
> the above line (from testfox1.rb) to read something like:
>
> 	postcode = FXComboBox.new(combo, 8, 10, nil, 0,
> FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)
>
> and you should like the result better. Of course, the "right" number of
> columns is going to depend on the lengths of the items' text, which you
> don't know in advance. Some people get around this by adjusting the
> number of columns after all of the items have been added, e.g.
>
> 	comboBox = FXComboBox.new(p, 1, ...)
> 	maxStringLen = 0
> 	itemStrings.each do |itemString|
> 		comboBox.appendItem(itemString)
> 		maxStringLen = [maxStringLen, itemString.length].max
> 	end
> 	comboBox.numColumns = maxStringLen
>
> > Also note the file "testfox.fxs" which is FOX Script Language I am
> > developing
> > to see if this shorthand technique of describing forms is a viable
> > technique.
> > Although I've had plenty of experience with DELPHI, et al, I'm not
> > convinced
> > that a GUI IDE is necessarly the most efficient method for describing
> > forms
> > when the developers Language (Ruby) is using a independent GUI tool.
> > Delphi
> > works well because of the very tight intergration of Form/Language.
>
> I've never used Delphi itself, but have used Borland C++ Builder which
> is closely related, and yes, it is very nice. A lot of people are
> interested in "GUI building" tools for FOX and FXRuby (see for example
> http://fox-tool.rubyforge.org) and so I'm glad you're investigating
> this alternative approach.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users

-- 
"I've had a wonderful time, but this wasn't it." 
	- Groucho Marx (1895-1977)

Re: [Fxruby-users] controlling a FXComboBox size

[Lyle J. <ly...@kn...>]

On Dec 3, 2003, at 4:09 PM, Brett S Hallett wrote:

> Find attached a few (small :-) example programs that I generated , the 
> only
> one that produces a "correct" combobox is the one (testfox.rb) which
> explicitly uses the coordinate AND size parameters, in every other 
> case I get
> a VERY narrow displayed field ( and drop down field).
>
> I suspect that I am simply not using the correct opts= parameters to 
> get the
> desired effect, which is :
>
> a) let the user define the width & height of the combobox field
> b) let the field fall into its 'natural' position depending upon the 
> frame
>    type declared.

When you specify an explicit (a.k.a. fixed) width for the combo-box, 
there is obviously no question as to which size the layout manager 
should assign to that combo-box. But if you don't specify a fixed 
width, the layout manager needs some other way to determine an 
appropriate default size for it. (This is of course true for any child 
widget, but today we're talking about combo-boxes ;)

For the combo-box (as well as text fields, and some other widgets) the 
default size depends on the number of columns passed in as an argument 
to the constructor. In the case of your examples, you're passing in 1 
as the number of columns, e.g.

	postcode = FXComboBox.new(combo, 1, 10, nil, 0, 
FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)

which causes the combo-box to report a very small default width, since 
it thinks it only needs to be wide enough to display a string that is 
one character long. To quickly prove this to yourself, simply change 
the above line (from testfox1.rb) to read something like:

	postcode = FXComboBox.new(combo, 8, 10, nil, 0, 
FRAME_SUNKEN|FRAME_THICK|COMBOBOX_NORMAL)

and you should like the result better. Of course, the "right" number of 
columns is going to depend on the lengths of the items' text, which you 
don't know in advance. Some people get around this by adjusting the 
number of columns after all of the items have been added, e.g.

	comboBox = FXComboBox.new(p, 1, ...)
	maxStringLen = 0
	itemStrings.each do |itemString|
		comboBox.appendItem(itemString)
		maxStringLen = [maxStringLen, itemString.length].max
	end
	comboBox.numColumns = maxStringLen

> Also note the file "testfox.fxs" which is FOX Script Language I am 
> developing
> to see if this shorthand technique of describing forms is a viable 
> technique.
> Although I've had plenty of experience with DELPHI, et al, I'm not 
> convinced
> that a GUI IDE is necessarly the most efficient method for describing 
> forms
> when the developers Language (Ruby) is using a independent GUI tool. 
> Delphi
> works well because of the very tight intergration of Form/Language.

I've never used Delphi itself, but have used Borland C++ Builder which 
is closely related, and yes, it is very nice. A lot of people are 
interested in "GUI building" tools for FOX and FXRuby (see for example 
http://fox-tool.rubyforge.org) and so I'm glad you're investigating 
this alternative approach.

Re: [Fxruby-users] controlling a FXComboBox size

[Lyle J. <ly...@kn...>]

On Dec 2, 2003, at 5:56 PM, Brett S Hallett wrote:

> I'm writing a small scripting tool for the generation of FXRuby 
> programs, its mostly working OK , however
> I cannot control the positioning and size of combobox fields. (those 
> with a dropdown feature)
>
> I'm trying to avoid LAYOUT_EXPLICIT , so the FORM maybe resized by the 
> user, however it would appear that I can
> create a combobox field if I only use x,y,width,height parameters.

Sorry if I'm being dense, but are you saying that the layout manager is 
ignoring the (non-explicit) layout hint(s) that you're using in the 
combo box's constructor? Can you maybe provide a little example that 
demonstrates the problem?

[Fxruby-users] controlling a FXComboBox size

[Brett S H. <dra...@im...>]

I'm writing a small scripting tool for the generation of FXRuby 
programs, its mostly working OK , however
I cannot control the positioning and size of combobox fields. (those 
with a dropdown feature)

I'm trying to avoid LAYOUT_EXPLICIT , so the FORM maybe resized by the 
user, however it would appear that I can
create a combobox field if I only use x,y,width,height parameters.

Is this so? or am I missing a FOX feature ??

Re: [Fxruby-users] Newbie question about making own drawables

[Joel V. <vj...@PA...>]

Will Merrell wrote:
>>I will soon upload FoxTails 0.2, which is 1.8-friendly
>>and has a tree browser widget. Maybe I'll have some
>>time to document better...
> 
> 
> That will be great, although, at this point its really Observable that I am
> most working with at the moment. Once I get the current stuff working I may
> use Foxtails more.
> 
> BTW any idea when you will release it?

Later today, along with an update of Observable.

You make a good point about having an example with action at a distance. 
I'll put in something like that. Also, to take that to the extreme, I've 
written an example which distributes the observer relationship over a 
DRb connection. (This is why I had to update the Observable package). It 
makes writing distributed GUIs a snap, at least in simple cases.