fxruby-users — General-purpose discussion list for FXRuby

[Fxruby-users] [Q] FXComboBox can't get focus

[Laurent J. <la...@mo...>]

In one of my dialog box I have a FXComboBox which I would like to 
receive focus when I open the dialog box. However doing a setFocus on 
the combobox widget has no effect and the text field in the combobox 
doesn't display the text cursor. I have to type TAB or click the text 
field with the mouse to focus.

I am using FOX 1.0.46/FXRuby 1.0.23 but I suspect this is a bug in the 
FXComboBox widget.

Any workaround?

Thanks!

Laurent

[Fxruby-users] Re: [Foxgui-users][Q] addInput events eating all cpu

[Laurent J. <la...@mo...>]

jeroen wrote:

> What I would suggest is to FORCIBLY paint when data is received. Instead
> of just update(), do update() followed by repaint() which will immediately
> perform all extant repaint rectangles.  
> 
> Try that and see how it goes.  The throughput will be lower [because your
> immediately painting], but the user will see a less jerky display.
> 

I did what you said and also reduce the size of the buffer read at 
once  from the remote process. By doing so I managed to get a smoother 
text flow and scrolling in my FXText widget.

Thanks!

Laurent

[Fxruby-users] [Q] addInput events eating all cpu

[Laurent J. <Lau...@xr...>]

Here's the problem I am having in FreeRIDE (FOX 1.0): I use an 
addInput to listen to a file descriptor which happens to be the STDOUT 
of a remote process. I use INPUT_READ on this channel to capture the 
incoming text and display it in a FXText object.

The problem I have is when the remote process generate output at full 
speed, I can't get the FXText object to refresh and draw the line of 
text in a continuous way instead of displaying almost everything in 
one go when the remote process finally stop.

Is there a way to solve this problem? Like giving some cycles to the 
"normal" update events that will refresh the FXText widget.

Any idea is welcome

Here is the piece of code that I use for monitoring the file descriptor:

     def attach_stdout(fh)
       getApp().addInput(fh, INPUT_READ|INPUT_EXCEPT) do |sender, sel, 
ptr|
         case SELTYPE(sel)
         when SEL_IO_READ
           begin
             text = fh.sysread(100000)
             print_stdout(text)   # print the text in the FXText widget
           rescue EOFError
             detach_stdout(fh)
           end
         when SEL_IO_EXCEPT
           puts 'onPipeExcept'
         end
       end
     end

Laurent

[Fxruby-users] [Q] Focus on Combobox?

[Laurent J. <Lau...@xr...>]

I have a problem with a dialog box on the FreeRIDE project. Our 
search/replace dailog box uses FXComboBox for the string to find and 
replace and I could not find a way to set the Focus on the search 
comboBox when the dialog box opens up.

The setFocus on a combo box seems to have no effect. I would expect 
the cursor to appear in the text field but it doesn't. Looking at the 
FOX source code it looks like there is no setFocus method implemented 
in FXComboBox and I think it should.

Using FXRuby 1.0.23 and FOX 1.0.40

Laurent

[Fxruby-users] [HELP] Please transfer your "fxruby-users" mailing list subscription

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

Hi,

If you're seeing this message it's because you are one of the 80 or so 
people still subscribed to the "fxruby-users" mailing list for the 
FXRuby project hosted at SourceForge.net.

The FXRuby project, along with the "fxruby-users" mailing list, has 
recently moved to its new home at RubyForge. If you would like to 
continue to receive e-mails posted to the active project's mailing 
list, you need to do two things. First, please visit this page:

	http://rubyforge.org/mailman/listinfo/fxruby-users

and fill out the form to subscribe yourself to the new mailing list. 
Shortly after you submit this form, you should receive an e-mail asking 
you to confirm your subscription. After you complete that confirmation, 
you should receive a second e-mail welcoming you to the new list.

After you've successfully subscribed to the new list, please take a 
moment to visit this page:

	http://lists.sourceforge.net/lists/listinfo/fxruby-users

and unsubscribe yourself from the old mailing list. It's a little 
non-obvious how to do this; you need to type your subscribed e-mail 
address into the text field at the bottom of this web page and click 
the "Edit Options" button. That will take you to a different page where 
you can actually unsubscribe from the list. If you need help, or if 
this is just too much trouble, let me know and I can unsubscribe you 
myself.

Finally, if you are no longer interested in being subscribed to this 
list at all, please do still visit the latter link (at 
lists.sourceforge.net) and unsubscribe yourself from that list, or ask 
me to do this for you. I am trying to get a feel for when I can 
completely turn that list "off."

Thanks in advance for your help,

Lyle

[Fxruby-users] strange DND behavior

[Peter S. <pet...@gm...>]

Hi,

I'm again playing around with drag and drop....
If I start the attached prog and drag a text/plain type item directly to 
the app everything is alright. But if I don't drop the item but drag it 
over another app and back again the drop is not accepted. Strange.

Is this some feature I stumbled upon or a bug in my X-server?

Thanks in advance


-- 
Peter Schrammel

[Fxruby-users] [ANN] Mailing List Changes

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

Dear List Subscriber,

The FXRuby project is in the process of moving from SourceForge.net to
RubyForge. One consequence of this move is that this mailing list (the
fxruby-users mailing list) will also be hosted by RubyForge.

In order to ensure that all active list readers get moved to the new list,
I'm asking you to do two things:

 1. Subscribe to the new mailing list by visiting this page:

        http://rubyforge.org/mailman/listinfo/fxruby-users

 2. Once you've received the automated confirmation of your
    subscription to that list, unsubscribe from this list by
    visiting this list:

        http://lists.sourceforge.net/lists/listinfo/fxruby-users

Obviously, there's a chance that some messages will get lost in the shuffle
over the next week or so while people move to the new list. The quicker that
we can get everyone moved over to the new list, the better. If in doubt,
keep an eye on the mailing list archives at both sites.

I am intentionally handling things this way instead of just changing your
subscription without your permission; I don't always like it when that
happens to me. ;) If however you would *prefer* to have me handle the switch
for you, please send me a private e-mail and I'll be glad to take care of
it. Also of course let me know if you run into any other snags.

Thanks in advance for your cooperation,

Lyle

[Fxruby-users] [ANN] FXRuby 1.2a2 Now Available

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

All,

The 2nd alpha release of FXRuby 1.2 is now available for download from here:

    http://rubyforge.org/frs/?group_id=300&release_id=628

The files are:

 * fxruby-1.2.1.gem: a "source" gem
 * fxruby-1.2.1-mswin32.gem: a "binary" gem for Win32, compatible with
   the Ruby 1.8.1 installer for Windows.
 * FXRuby-1.2.1.tar.gz: the standard source tarball.

Changes for this release are documented here:

    http://www.fxruby.org/1.2/doc/changes.html

As you can see, I'm in the process of moving the project from
SourceForge.net to RubyForge. I will make a separate announcement about this.

Lyle

[Fxruby-users] [ANN] We're Moving!

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

All,

I am pleased to announce that thanks to the help of Tom Copeland and Rich
Kilmer (as well as the encouragement of Curt Hibbs and others) FXRuby has
finally begun its move to a new home at RubyForge.

The following project components have already moved:

 * All of the web pages should be in place at http://fxruby.rubyforge.org.
   As soon as the DNS changes propagate in the next day or so, the
   http://www.fxruby.org should also point to that address.
   Note that some of the web pages still refer to SourceForge.net
   addreses, but this should be corrected shortly.

 * The latest file releases (versions 1.0.29 and 1.2.1) are moved.

The following project components have not yet moved, but should within a
week's time:

 * The CVS repository.
 * The previous bug list and feature requests list.

The new mailing lists for fxruby-users and fxruby-announce are also in place
at RubyForge; I'll post a separate message about that.

Thanks, and let me know of any problems,

Lyle

[Fxruby-users] Re: Moving to RubyForge (was: Update: FXRuby 1.2a2 Status)

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

On Jul 14, 2004, at 10:24 AM, Curt Hibbs wrote:

> You should really "bite the bullet" and move to RubyForge. These kind 
> of
> problems seem all-too-common on SourceForge.

You are correct that there are a number of flaws with SourceForge.net, 
and believe me that I'm very tempted to move the project to RubyForge. 
There are at least two potential problems with the current set of 
services provided by RubyForge. And I say "potential" because they may 
not really be problems, but they are things about which I am unclear.

One concern is that SourceForge.net provides what they call "VHOST 
services" that allow the SourceForge.net web server to "answer" for my 
fxruby.org domain name. That is, when you visit:

	http://www.fxruby.org

you're viewing paged hosted on their web servers. I would want this to 
work on RubyForge as well, and it may be that this is no big deal to 
get working (I have filed a support request about this). But I 
definitely don't want that URL (http://www.fxruby.org) to "break" as a 
result of the move.

Another thing which bothers me, but which is not necessarily a problem, 
is the lack of shell account support at RubyForge. I can probably work 
around this, but there are numerous times when it has come in handy for 
my SourceForge.net project(s).

[Fxruby-users] RE: [Fxruby-announce] Update: FXRuby 1.2a2 Status

[Curt H. <cu...@hi...>]

Lyle Johnson wrote:
>
> All,
>
> I've been trying to officially release FXRuby 1.2a2 for the last few
> days but have been unsuccessful due to problems at SourceForge's File
> Release System. These problems are not affecting FXRuby only; there are
> a number of open support requests from other projects concerning this
> issue, and so I expect that it will be resolved in due course.
>
> In the meantime: hang loose.

You should really "bite the bullet" and move to RubyForge. These kind of
problems seem all-too-common on SourgeForge.

Curt

[Fxruby-users] Update: FXRuby 1.2a2 Status

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I've been trying to officially release FXRuby 1.2a2 for the last few 
days but have been unsuccessful due to problems at SourceForge's File 
Release System. These problems are not affecting FXRuby only; there are 
a number of open support requests from other projects concerning this 
issue, and so I expect that it will be resolved in due course.

In the meantime: hang loose.

Thanks,

Lyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA9IjyFXV/hD6oMd0RApEEAJ4uQEv4dtoE1yJZM2QzHgj8Wkoj4ACfR6xw
jv8KF8B4rBefMa8vyQ0xs4Y=
=n5Xl
-----END PGP SIGNATURE-----

Re: [Fxruby-users] glviewer.rb sample program error...

[Jeff K. <tl...@co...>]

Thank you both for your quick responses. I just joined the list today and 
already I've pawned off a problem to someone else! Ain't this internet thingy 
grand?

--jeff

On Sunday 11 July 2004 13:59, Lyle Johnson wrote:
> Jeff & Richard,
>
> For some reason Jeff's original message never made it to my mailbox;
> I've only just seen Richard's *reply* to Jeff's message.
>
> But Jeff's problem (the undefined "include" method, coming out of
> glgroup.rb) is a known problem that will be fixed for the 1.2a2
> release. Which is coming any second now. ;)
>
> Lyle

Re: [Fxruby-users] [Q] Alternatives to the source RubyGem format?

[Gilles F. <gil...@fr...>]

ly...@kn... a =E9crit :
> All,
>=20
> In a separate post, Yuri asked: "Do you plan to provide gems as the onl=
y
> source package format? I think rubygems is a terrific thing, but I also
> suppose there must be a choice."
>=20
> Despite the fact that it still has some rough edges, I really like the =
idea
> of RubyGems and want to do what I can to encourage its adoption in the =
Ruby
> community. But as I've previously stated, the choice to use RubyGems as=
 the
> distribution format for FXRuby 1.2 is a sort of experiment while we're =
still
> in the "alpha" release stage.
>=20
> So my question is, based on your experiences so far, what do you see as=
 the
> disadvantages of sticking with "source" RubyGems as the distribution me=
thod,
> as opposed to the previously available source tarballs? I'm absolutely =
fine
> with offering alternative distributions if we have a compelling reason =
to do
> so. On the other hand, I want to avoid confusion in terms of multiple s=
ets
> of instructions about the different ways to build and install the code,
> depending on which distribution you've downloaded.
>=20
> Let me repeat: this is *not* a done deal. I sincerely want to know what=
 you
> guys are thinking about this.
>=20
> Thanks in advance for your comments,
>=20
> Lyle

The only question I have is related to existing Linux distribution=20
packaging systems.
For instance, Debian. Say I installed Ruby and RubyGems using apt-get,=20
and FXRuby isn't packaged yet. I can see three way of installing FXRuby:
1- As root, using RubyGems - Not the "Debian way"
2- As a user using RubyGems - Is it possible to install FXRuby this way=20
in user space ?
3- Using FXRuby sources + checkinstall to build a rough debian package.

My prefered solution for now is the last one.

Cheers,
_gilles.

Re: [Fxruby-users] glviewer.rb sample program error...

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

Jeff & Richard,

For some reason Jeff's original message never made it to my mailbox; 
I've only just seen Richard's *reply* to Jeff's message.

But Jeff's problem (the undefined "include" method, coming out of 
glgroup.rb) is a known problem that will be fixed for the 1.2a2 
release. Which is coming any second now. ;)

Lyle

Re: [Fxruby-users] RE: [Q] Alternatives to the source RubyGem format?

[RLMuller <RLMuller@Comcast.net>]

Hi Jeff,

Having reread the error messages you got,  I think my suggestion of changing
the working directory was useless.  Sorry for wasting your time.  I don't
run Linux on any of my systems currently and never new it well enough anyway
to by able to make any useful suggestion.

Regards,
Richard


----- Original Message ----- 
From: "Jeff Koppe" <tl...@co...>
To: <fxr...@li...>
Sent: Sunday, July 11, 2004 8:10 AM
Subject: [Fxruby-users] RE: [Q] Alternatives to the source RubyGem format?


> Having just installed Ruby on Linux for the first time I must confess
> that I was a bit disconcerted that I had to install rubygems before I
> could install FXRuby. As I remembered installing it on Windows a year
> or so ago installing FXRuby was pretty darn simple.
>
> However, once I got my head around what rubygems was doing I found it
> petty convenient. I particularly value the uninstall ability of
> rubygems since I had to try several times to get it right due to my
> non-standard installation preferences (aka Linux ignorance) of the
> Fox libraries. I've always found Linux installations to be obscure.
> And if you do any serious Linux work you're familiar with the
> terminal so that's not a hinderance. So, I see a real advantage to
> using Rubygems on Linux installations. In addition, I see real
> advantages to having a consistent installation routine across all
> platforms. Perhaps the gem files can be cross bred with *.rbw to ease
> the burden on our Windows brothers?
>
> --jeff
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 7/9/2004

Re: [Fxruby-users] glviewer.rb sample program error...

[RLMuller <RLMuller@Comcast.net>]

Hi Jeff,

Here's what I did on my Windows2000 machine:

10:15 C:\>I:
10:16 I:\>cd "I:\Program Files\Ruby\samples\FXRuby"
10:16 I:\Program Files\Ruby\samples\FXRuby>ruby glviewer.rbw
(Window opened with plenty of widgets.  I clicked the "close" X)
10:17 I:\Program Files\Ruby\samples\FXRuby>

I think the critical difference between what I did and what you did is I
made the samples directory the current directory before executing ruby.

HTH,
Richard

----- Original Message ----- 
From: "Jeff Koppe" <tl...@co...>
To: <fxr...@li...>
Sent: Sunday, July 11, 2004 8:25 AM
Subject: [Fxruby-users] glviewer.rb sample program error...


> Well I've got all my installation issues taken care of (I think). All the
> sample programs I've tried work fine, except the one I want to build
> on--naturally!
>
> Though I don't think this is an installation issue. Any help would be
> appreciated.
>
> --jeff
>
> jkoppe@linux:~/downloads/ruby/sample_programs> ruby glviewer.rb
> Xlib:  extension "XFree86-DRI" missing on display ":0.0".
> /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/glgroup.rb:67:in
> `bounds': undefined method `include' for #<Fox::FXRangef:0x410a5f7c>
> (NoMethodError)
>         from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
> glgroup.rb:67:in `each'
>         from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
> glgroup.rb:67:in `bounds'
>         from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
> glgroup.rb:67:in `bounds'
>         from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
> glgroup.rb:67:in `each'
>         from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
> glgroup.rb:67:in `bounds'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:509:in `create'
>         from glviewer.rb:576:in `create'
>         from glviewer.rb:576
> jkoppe@linux:~/downloads/ruby/sample_programs>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 7/9/2004

[Fxruby-users] glviewer.rb sample program error...

[Jeff K. <tl...@co...>]

Well I've got all my installation issues taken care of (I think). All the 
sample programs I've tried work fine, except the one I want to build 
on--naturally!

Though I don't think this is an installation issue. Any help would be 
appreciated.

--jeff

jkoppe@linux:~/downloads/ruby/sample_programs> ruby glviewer.rb
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
/usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/glgroup.rb:67:in 
`bounds': undefined method `include' for #<Fox::FXRangef:0x410a5f7c> 
(NoMethodError)
        from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
glgroup.rb:67:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
glgroup.rb:67:in `bounds'
        from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
glgroup.rb:67:in `bounds'
        from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
glgroup.rb:67:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.2.0/lib/fox/
glgroup.rb:67:in `bounds'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:509:in `create'
        from glviewer.rb:576:in `create'
        from glviewer.rb:576
jkoppe@linux:~/downloads/ruby/sample_programs>

[Fxruby-users] RE: [Q] Alternatives to the source RubyGem format?

[Jeff K. <tl...@co...>]

Having just installed Ruby on Linux for the first time I must confess
that I was a bit disconcerted that I had to install rubygems before I
could install FXRuby. As I remembered installing it on Windows a year
or so ago installing FXRuby was pretty darn simple. 

However, once I got my head around what rubygems was doing I found it
petty convenient. I particularly value the uninstall ability of
rubygems since I had to try several times to get it right due to my
non-standard installation preferences (aka Linux ignorance) of the
Fox libraries. I've always found Linux installations to be obscure.
And if you do any serious Linux work you're familiar with the
terminal so that's not a hinderance. So, I see a real advantage to
using Rubygems on Linux installations. In addition, I see real
advantages to having a consistent installation routine across all
platforms. Perhaps the gem files can be cross bred with *.rbw to ease
the burden on our Windows brothers?

--jeff

RE: [Fxruby-users] [Q] Alternatives to the source RubyGem format?

[Oliver S. <ol...@mo...>]

> I'm guessing that the RubyGems developers' argument would be that they
> intentionally don't give you a choice for the installation directory. That
> is, Gems are always installed in a standard location in the Ruby directory
> structure so that you don't have to *care* where they were
> installed. I can
> see a parallel with how I use RPMs under Linux; I rarely list
> their contents
> to see what files are going where, I just install the RPM and
> know that it's
> going to be installed in the "right place."

I don't really need to know where the library files go, but the Windows
installer gives me some text telling me where example files and help files
are.  With the gem, I might not even think to look for any example files,
given that they are kind of buried in the c:\ruby directory.  Admittedly,
installing to another directory is not all that useful for a library, but be
prepared for users complaining that they have two ruby versions installed.
:)

> by "installing third party
> programs", are you referring to the requirement of first
> installing RubyGems
> itself? That is certainly a drawback for now, but at the last Ruby
> conference Matz expressed a strong interest in getting this into the
> official Ruby code base as soon as it's mature. I doubt that will
> be in time
> for the pending 1.8.2 release, but I wouldn't be surprised to see
> it make it
> in there by the end of the year.

Yeah, a few of my problems would be made easier just by rubygems being the
standard way of doing things.

> Now that you've brought it
> up, I'm wondering how hard it would be to in fact "wrap" a binary gem as a
> Win32 installer-like executable (and create an uninstaller for it
> as well).
> If done right one could still retain the advantages of RubyGems
> in terms of
> packaging and versioning, but lose the unfriendliness of the command-line
> interface.

I had considered this possibility as well.  Wrapping a gem in NSIS would
make me happy, and would also give the developer an option of installing
start menu folders, desktop icons, quick launch icons, registry keys and the
rest.  It would make me even happier if there was an automatic option to
reformat Linux text files in DOS format.  One of my pet peeves is
downloading some ruby source and seeing a 'README' file formatted with Linux
line endings.  Windows users can't double-click on a file with no extension,
and furthermore notepad won't display it correctly.  Not that FXRuby suffers
from that problem. :)

Oliver

RE: [Fxruby-users] [Q] Alternatives to the source RubyGem format?

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

On Fri, 9 Jul 2004 12:00:43 -0700, "Oliver Smith" <ol...@mo...>
wrote :

> I just tried installing FXRuby 1.2 on Windows, and thought I would play
> devil's advocate. :)

Someone's got to! ;)

> I just don't see how this is anything but a step backwards on Windows.  Who
> would want to go from double-clicking to typing obscure commands in a DOS
> box?

Yes, this is an excellent point. Of course, we could try to turn this into a
positive suggestion (feature request) for the RubyGems developers; but
that's a side point.

> ... Plus there is no obvious option for choosing an install
> directory and the output of the installer did not even tell me where it put
> the FXRuby 1.2 files.  With the old .exe installer I see a helpful screen
> telling me where the files will go, and an easy option to change the
> destination directory.

I'm guessing that the RubyGems developers' argument would be that they
intentionally don't give you a choice for the installation directory. That
is, Gems are always installed in a standard location in the Ruby directory
structure so that you don't have to *care* where they were installed. I can
see a parallel with how I use RPMs under Linux; I rarely list their contents
to see what files are going where, I just install the RPM and know that it's
going to be installed in the "right place."

> Plus, no DOS box, no installing third party
> programs, no reading help files, no outdated zip files and an obvious way to
> uninstall the program.

I think I follow you on most of these. But by "installing third party
programs", are you referring to the requirement of first installing RubyGems
itself? That is certainly a drawback for now, but at the last Ruby
conference Matz expressed a strong interest in getting this into the
official Ruby code base as soon as it's mature. I doubt that will be in time
for the pending 1.8.2 release, but I wouldn't be surprised to see it make it
in there by the end of the year.

> Of course Lyle, in reality I'm grateful for the work you're doing so
> whichever way you want to do it is the right way.  I'm just taking the
> grouchy consistency-advocate's view. :)

Thanks, but please don't apologize. I think you raise some excellent points
and these are some things I hadn't considered. Now that you've brought it
up, I'm wondering how hard it would be to in fact "wrap" a binary gem as a
Win32 installer-like executable (and create an uninstaller for it as well).
If done right one could still retain the advantages of RubyGems in terms of
packaging and versioning, but lose the unfriendliness of the command-line
interface.

RE: [Fxruby-users] [Q] Alternatives to the source RubyGem format?

[Oliver S. <ol...@mo...>]

I just tried installing FXRuby 1.2 on Windows, and thought I would play
devil's advocate. :)

I just don't see how this is anything but a step backwards on Windows.  Who
would want to go from double-clicking to typing obscure commands in a DOS
box?  I can't think of a single thing Windows users gain from rubygems in
this case.  Plus there is no obvious option for choosing an install
directory and the output of the installer did not even tell me where it put
the FXRuby 1.2 files.  With the old .exe installer I see a helpful screen
telling me where the files will go, and an easy option to change the
destination directory.  Plus, no DOS box, no installing third party
programs, no reading help files, no outdated zip files and an obvious way to
uninstall the program.

Of course Lyle, in reality I'm grateful for the work you're doing so
whichever way you want to do it is the right way.  I'm just taking the
grouchy consistency-advocate's view. :)

Oliver

> -----Original Message-----
> From: fxr...@li...
> [mailto:fxr...@li...]On Behalf Of
> ly...@kn...
> Sent: Friday, July 09, 2004 8:51 AM
> To: fxr...@li...
> Cc: y.l...@sa...
> Subject: [Fxruby-users] [Q] Alternatives to the source RubyGem format?
>
>
> All,
>
> In a separate post, Yuri asked: "Do you plan to provide gems as the only
> source package format? I think rubygems is a terrific thing, but I also
> suppose there must be a choice."
>
> Despite the fact that it still has some rough edges, I really
> like the idea
> of RubyGems and want to do what I can to encourage its adoption
> in the Ruby
> community. But as I've previously stated, the choice to use
> RubyGems as the
> distribution format for FXRuby 1.2 is a sort of experiment while
> we're still
> in the "alpha" release stage.
>
> So my question is, based on your experiences so far, what do you
> see as the
> disadvantages of sticking with "source" RubyGems as the
> distribution method,
> as opposed to the previously available source tarballs? I'm
> absolutely fine
> with offering alternative distributions if we have a compelling
> reason to do
> so. On the other hand, I want to avoid confusion in terms of multiple sets
> of instructions about the different ways to build and install the code,
> depending on which distribution you've downloaded.
>
> Let me repeat: this is *not* a done deal. I sincerely want to
> know what you
> guys are thinking about this.
>
> Thanks in advance for your comments,
>
> Lyle
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
>

[Fxruby-users] [Q] Alternatives to the source RubyGem format?

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

All,

In a separate post, Yuri asked: "Do you plan to provide gems as the only
source package format? I think rubygems is a terrific thing, but I also
suppose there must be a choice."

Despite the fact that it still has some rough edges, I really like the idea
of RubyGems and want to do what I can to encourage its adoption in the Ruby
community. But as I've previously stated, the choice to use RubyGems as the
distribution format for FXRuby 1.2 is a sort of experiment while we're still
in the "alpha" release stage.

So my question is, based on your experiences so far, what do you see as the
disadvantages of sticking with "source" RubyGems as the distribution method,
as opposed to the previously available source tarballs? I'm absolutely fine
with offering alternative distributions if we have a compelling reason to do
so. On the other hand, I want to avoid confusion in terms of multiple sets
of instructions about the different ways to build and install the code,
depending on which distribution you've downloaded.

Let me repeat: this is *not* a done deal. I sincerely want to know what you
guys are thinking about this.

Thanks in advance for your comments,

Lyle

Re: [Fxruby-users] some FXRuby 1.2 stuff

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

On Fri, 9 Jul 2004 18:14:23 +0300, Yuri Leikind
<y.l...@sa...> wrote :

> 1) aliases.rb has a couple of aliases related to so-called leading rows and 
>     columns in the FXTable class:

<snip>

>     Looks like there are no more leading rows/columns, and there are no 
>     setLeadingRows/getLeadingRows/etc methods. And I personally don't need
>     them now as tables are created with ready FXHeaders now.

You're right, those aliases are now obsolete. Will add this to the bug list.

> 2) Before 1.2.x FXRuby  I used to 
> 
> 	require "fox"
> 	require "fox/colors"
> 
>     Now that FXRuby is packed as a Ruby gem I do this
> 
>        require_gem "fxruby"
> 
>     where fxruby is not the so file, but a package name. So how am I
supposed to
>    require the "fox/colors" file now in an elegant way, via require_gem?

As a side effect of the require_gem statement, Ruby's load path is modified
so that it can "see" FXRuby's library path. So you should be able to require
those auxiliary files (like fox/colors.rb) as before, i.e.

    require_gem 'fxruby'
    require 'fox/colors'

> 3) Do you plan to provide gems as the only source package format? I think
>    rubygems is a terrific thing, but I also suppose there must be a choice.

Let me start a new thread of discussion for this one, because it is an
important question that I don't want to get buried...

[Fxruby-users] some FXRuby 1.2 stuff

[Yuri L. <y.l...@sa...>]

Hello Lyle and all, 


I'be been implementing support of FXRuby 1.2 in my little GUI tool, and I have a 
couple of  questions :


1) aliases.rb has a couple of aliases related to so-called leading rows and 
    columns in the FXTable class:

    def leadingRows=(*args); setLeadingRows(*args); end
    def leadingRows(*args); getLeadingRows(*args); end
    def leadingColumns=(*args); setLeadingColumns(*args); end
    def leadingColumns(*args); getLeadingColumns(*args); end

    Looks like there are no more leading rows/columns, and there are no 
    setLeadingRows/getLeadingRows/etc methods. And I personally don't need
    them now as tables are created with ready FXHeaders now

2) Before 1.2.x FXRuby  I used to 

	require "fox"
	require "fox/colors"

    Now that FXRuby is packed as a Ruby gem I do this

       require_gem "fxruby"

    where fxruby is not the so file, but a package name. So how am I supposed to
   require the "fox/colors" file now in an elegant way, via require_gem?


3) Do you plan to provide gems as the only source package format? I think
    rubygems is a terrific thing, but I also suppose there must be a choice.


-- 
Best regards,
Yuri Leikind