From Laurent.Julliard at xrce.xerox.com Wed Apr 6 09:01:56 2005 From: Laurent.Julliard at xrce.xerox.com (Laurent Julliard) Date: Wed Apr 6 08:56:38 2005 Subject: [FR-devel] Test Message-ID: <4253DDC4.30903@xrce.xerox.com> Sorry guys, just doing some test. Laurent From laurent at moldus.org Mon Apr 11 15:12:19 2005 From: laurent at moldus.org (Laurent Julliard) Date: Mon Apr 11 15:06:53 2005 Subject: [FR-devel] [ANN] FreeRide 0.9.4 - The Free Ruby IDE Message-ID: <425ACC13.3060305@moldus.org> Version 0.9.4 of FreeRIDE has been released and is available for download! For details and downloads, go to: http://freeride.rubyforge.org/ 0.9.4 introduces two major new features that will make you more productive when you write Ruby code: - one is the Ruby Documentation plugin which allows you get instant help on a class or method name whenever yoy hit the F1 button when writing code (Beware it's terribly addicting...). For this to work properly, the Linux and the Windows installer now comes with the full Ruby Documentation generated (ri format) - second is the "code template" plugin. While typing code press CTRL-J and you'll see a list of code templates that you can insert by selecting their short name. These templates cannot be customized for now but it will come... However we believe there is already a reasonable list of code templates that you can choose from in 0.9.4 0.9.4 also comes with a number of bug fixes. See the ChangeLog file for details. Also note that the experimental refactoring plugin has been deactivated as this was not working very well and the RRB appears to be no longer maintained. Have fun! And, as always, feedback and contributions are welcome. NOTE: If you experience troubles (e.g. crashes) at startup time, delete your FreeRIDE configuration directory in $HOME/.freeride for Linux users or %USERPROFILE%\freeride on Windows to restart from a fresh setting. === FreeRIDE Overview === FreeRIDE aims to be a full-featured, first-class IDE on a par with those available for other languages, with all the best-of-breed features that you would expect in a high-end IDE. Some of FreeRIDE's features include: * Multi-file editing * Syntax highlighting * Auto-indenting * Code Folding * Code Templates * Source navigation by module, class, method, etc. * Integrated Ruby Documentation * Integrated debugging * Written in Ruby for easy extension Some planned features include: * Full internationalization * High-end refactoring support * Remote pair programming In its current state, FreeRIDE cannot yet be called a real IDE although it is already being used by many Ruby developers. What is does have is a stable infrastructure with all the working plumbing needed for the hordes of anxious Ruby developers that want to create plugins to extend the functionality of FreeRIDE. The FreeRIDE team will be working on such FreeRIDE plugins that we will individually release to incrementally improve the FreeRIDE system. Periodically we will rollup these added plugins into new releases of FreeRIDE. Even if you have not officially joined the FreeRIDE team you can still create plugins for you own use, share them with others, or send them to us and we will make them available for download from our project wiki. We may even ask for your permission to include them in the FreeRIDE core distribution. ** IMPORTANT NOTE ** Any help you can provide in testing FreeRIDE, qualifying bugs and (why not) fixing them is really what we need most, especially on Windows where FreeRIDE seems to be less robust than on Linux. Laurent Julliard Curt Hibbs -- Laurent JULLIARD http://www.moldus.org/~laurent From g.glueck at gmx.net Fri Apr 15 18:45:28 2005 From: g.glueck at gmx.net (=?iso-8859-1?q?G=FCnter_Gl=FCck?=) Date: Fri Apr 15 18:39:21 2005 Subject: [FR-devel] remove the plugin-menu-item when a plugin is stopped In-Reply-To: <425ACC13.3060305@moldus.org> References: <425ACC13.3060305@moldus.org> Message-ID: <200504160045.28987.g.glueck@gmx.net> hi, sorry for beeing so silent in the past time. now i'm view at the plugin-manager plugin i started to develop in the past. this plugin should make it possible to start and stop plugins on demand over the plugin-manager-panel. so i search for the right method to remove a menu-item from the tools-menu. sorry if this is a silly question :-) g?nter From curt at hibbs.com Sat Apr 16 00:07:17 2005 From: curt at hibbs.com (Curt Hibbs) Date: Sat Apr 16 00:01:40 2005 Subject: [FR-devel] remove the plugin-menu-item when a plugin is stopped In-Reply-To: <200504160045.28987.g.glueck@gmx.net> References: <425ACC13.3060305@moldus.org> <200504160045.28987.g.glueck@gmx.net> Message-ID: <42608F75.8070306@hibbs.com> G?nter Gl?ck wrote: > hi, > > sorry for beeing so silent in the past time. > > now i'm view at the plugin-manager plugin i started to develop in the past. > > this plugin should make it possible to start and stop plugins on demand over > the plugin-manager-panel. > > so i search for the right method to remove a menu-item from the tools-menu. > > sorry if this is a silly question :-) > > g?nter Well, it looks like there isn't one. If you look at: freeride\plugins\rubyide_gui\menupane.rb its the manager for handling menupanes. Its got an add_command method, but no corresponding remove_command method. Looks like you'll need to add one. Curt From laurent at moldus.org Sat Apr 16 04:42:44 2005 From: laurent at moldus.org (Laurent Julliard) Date: Sat Apr 16 04:37:05 2005 Subject: [FR-devel] Project plugin thoughts - Was : remove the plugin-menu-item when a plugin is stopped In-Reply-To: <200504160045.28987.g.glueck@gmx.net> References: <425ACC13.3060305@moldus.org> <200504160045.28987.g.glueck@gmx.net> Message-ID: <4260D004.6020100@moldus.org> G?nter Gl?ck wrote: > hi, > > sorry for beeing so silent in the past time. > > now i'm view at the plugin-manager plugin i started to develop in the past. > > this plugin should make it possible to start and stop plugins on demand over > the plugin-manager-panel. > > so i search for the right method to remove a menu-item from the tools-menu. > > sorry if this is a silly question :-) > > g?nter > G?nter, Nice to see you again on the FR-devel list. It's good that you are restarting the work on the projet manager and, as a matter of fact I have been giving some thoughts to it (again!) recently. So here is where I am and may be it's time to restart the discussion on the subject between all of us. First thing is to think about what a projet is. The conclusion I came to is that a project in the FreeRIDE sense is nothing else than a collection of properties spread over the various active plugins that define the state of FreeRIDE. An example of this is that A project has a collection of opened files which are properties of the editpane plugin. So then the next question is: are all properties related to a project context? The asnweer is clearly no. There are properties that belong to the plugin itself regardless of the project you are working on. As an example it's very likely that you want the editor behavior to be the same whatever project you work on. So what I was thinking of doing is the following: a) rework the plugins so that their properties are stored either in the 'plugin' slot or the 'project' slot depending on their scope. This is easy to do. b) With this in place the project manager plugin will be responsible for loading, saving and creating projects. Saving a project simply means - the project manager plugin collects all 'project' property slots in all running plugins and store them in the .frp file (the freeride project file) Loading a new project means - the project manager plugin reads the .frp file, and calls each plugin in turn to pass the corresponding project property slot - each plugin must put in place this new project properties and act accordingly. Creating a new projet means - from the project manager plugin, create a project property slot from a template (which can be different depending on the project type e.g. FXRuby application, Console application, Rails application...) - each plugin must put in place this new project properties and act accordingly. So now the question is: what does 'act accordingly' means ? After looking carefylly at the existing code it occured to me that restarting a plugin by calling the stop and then start method was probably not the right thing to do. The main reason is because the start code has a lot to do with bringing the plugin to life and also creating it UI, menu entries.... It seems quite obvious that there is no need to do this again when a new project is loaded. For instance for the editpane plugin, loading a new projet simply means a) closing all the opened files of the current project and b) load all the files of the new project. That's about all. Consequently my suggestion is to add a new class method to the plugins that would be in charge of doing this. We could call the method project_properties=, restart or reload are not really good names because start and load already exist and they do something not related to what we are trying to achieve here. Suggestions are welcome.. (refresh? So, G?nter, while it is an interesting exercise to write the 'plugin manager' plugin, I think it is not necessarily what we need for the project manager. Comments from everybody is welcome. Laurent From g.glueck at gmx.net Sat Apr 16 08:22:21 2005 From: g.glueck at gmx.net (=?iso-8859-1?q?G=FCnter_Gl=FCck?=) Date: Sat Apr 16 08:16:51 2005 Subject: [FR-devel] Project plugin thoughts - Was : remove the plugin-menu-item when a plugin is stopped In-Reply-To: <4260D004.6020100@moldus.org> References: <425ACC13.3060305@moldus.org> <200504160045.28987.g.glueck@gmx.net> <4260D004.6020100@moldus.org> Message-ID: <200504161422.22033.g.glueck@gmx.net> Hi again, > So, G?nter, while it is an interesting exercise to write the 'plugin > manager' plugin, I think it is not necessarily what we need for the > project manager. i think so too, but i started the plugin-manager for some other reason. the only thing that it has to do with the project manager plugin is that we are able to build a plugin-template to create new plugins easier with the project manager. The plugin-manager should then be a tool to make live for plugin developers easier. That's for now. I think its good to resume the discussion of projects in freeride, but i really need a little time to view at the code again. So my contribution should come (hopefully soon) :-) best regards g?nter From laurent at moldus.org Sat Apr 16 12:16:30 2005 From: laurent at moldus.org (Laurent Julliard) Date: Sat Apr 16 12:10:52 2005 Subject: [FR-devel] Win32 testers needed for ripper source code parser Message-ID: <42613A5E.8040000@moldus.org> To all Win users over here! Some of you may have noticed that there are actually two implementation of the source browser plugins in FreeRIDE (the plugin that displayes class/methods hierarchies in a dock). One is called the simple source browser and is based on a quick ruby based analysis of the source file while the other implementation relies on the full featured ruby parser called ripper. I have just reactived the ripper based version of the source browser and I'd like to get feedback from the Win users on whether it works fine. You just have to checkout the latest code from CVS (see http://rubyforge.org/scm/?group_id=31 on how to do that) and start FreeRIDE. Then load all sorts of files (short, long, many classes or methods, etc...) and tell me if the source browser is working fine. Thanks a lot for your help! Laurent -- Laurent JULLIARD http://www.moldus.org/~laurent -------------- next part -------------- --- !ruby/object:FreeBASE::PluginConfiguration name: rubyide_tools_fox_source_browser version: 1.0 autoload: true require_path: rubyide_tools_fox_source_browser/source_browser startup_module: FreeRIDE::FoxRenderer::SourceBrowser properties_path: properties.yaml load_dependencies: rubyide_fox_gui: "*" rubyide_tools_source_parser: "*" start_dependencies: rubyide_fox_gui: "*" rubyide_tools_source_parser: "*" From curt at hibbs.com Sun Apr 17 23:31:46 2005 From: curt at hibbs.com (Curt Hibbs) Date: Sun Apr 17 23:26:06 2005 Subject: [FR-devel] Project plugin thoughts - Was : remove the plugin-menu-item when a plugin is stopped In-Reply-To: <4260D004.6020100@moldus.org> References: <425ACC13.3060305@moldus.org> <200504160045.28987.g.glueck@gmx.net> <4260D004.6020100@moldus.org> Message-ID: <42632A22.60907@hibbs.com> I haven't had time to think through all of this with any depth, but my overall reaction is that this looks pretty good. I don't see any hidden gotchas. Curt Laurent Julliard wrote: > G?nter Gl?ck wrote: > >> hi, >> >> sorry for beeing so silent in the past time. >> >> now i'm view at the plugin-manager plugin i started to develop in the >> past. >> >> this plugin should make it possible to start and stop plugins on >> demand over >> the plugin-manager-panel. >> >> so i search for the right method to remove a menu-item from the >> tools-menu. >> >> sorry if this is a silly question :-) >> >> g?nter >> > > G?nter, > > Nice to see you again on the FR-devel list. It's good that you are > restarting the work on the projet manager and, as a matter of fact I > have been giving some thoughts to it (again!) recently. > > So here is where I am and may be it's time to restart the discussion > on the subject between all of us. > > First thing is to think about what a projet is. The conclusion I came > to is that a project in the FreeRIDE sense is nothing else than a > collection of properties spread over the various active plugins that > define the state of FreeRIDE. An example of this is that A project has > a collection of opened files which are properties of the editpane plugin. > > So then the next question is: are all properties related to a project > context? The asnweer is clearly no. There are properties that belong > to the plugin itself regardless of the project you are working on. As > an example it's very likely that you want the editor behavior to be > the same whatever project you work on. > > So what I was thinking of doing is the following: > > a) rework the plugins so that their properties are stored either in > the 'plugin' slot or the 'project' slot depending on their scope. This > is easy to do. > > b) With this in place the project manager plugin will be responsible > for loading, saving and creating projects. > > Saving a project simply means > - the project manager plugin collects all 'project' property slots > in all running plugins and store them in the .frp file (the freeride > project file) > > Loading a new project means > - the project manager plugin reads the .frp file, and calls each > plugin in turn to pass the corresponding project property slot > > - each plugin must put in place this new project properties and act > accordingly. > > Creating a new projet means > - from the project manager plugin, create a project property slot > from a template (which can be different depending on the project type > e.g. FXRuby application, Console application, Rails application...) > > - each plugin must put in place this new project properties and act > accordingly. > > So now the question is: what does 'act accordingly' means ? After > looking carefylly at the existing code it occured to me that > restarting a plugin by calling the stop and then start method was > probably not the right thing to do. The main reason is because the > start code has a lot to do with bringing the plugin to life and also > creating it UI, menu entries.... > > It seems quite obvious that there is no need to do this again when a > new project is loaded. For instance for the editpane plugin, loading a > new projet simply means a) closing all the opened files of the current > project and b) load all the files of the new project. That's about all. > > Consequently my suggestion is to add a new class method to the plugins > that would be in charge of doing this. We could call the method > project_properties=, restart or reload are not really good names > because start and load already exist and they do something not related > to what we are trying to achieve here. Suggestions are welcome.. > (refresh? > > So, G?nter, while it is an interesting exercise to write the 'plugin > manager' plugin, I think it is not necessarily what we need for the > project manager. > > Comments from everybody is welcome. > > Laurent > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > From gilles.filippini at free.fr Fri Apr 22 15:20:57 2005 From: gilles.filippini at free.fr (Gilles Filippini) Date: Fri Apr 22 15:15:36 2005 Subject: [FR-devel] ANNOUNCE: FXScintilla 1.63 Message-ID: <42694E99.5020906@free.fr> I'm pleased to announce the release of FXScintilla 1.63. FXScintilla is an implementation of the Scintilla source code editing component [1] for the FOX GUI toolkit [2]. Changes since the previous release (1.62): - upgraded to Scintilla-1.63 - Added support for Fox-1.4 FXScintilla homepage: http://www.nongnu.org/fxscintilla/ Downloads: http://savannah.nongnu.org/files/?group=fxscintilla Cheers, _gilles. [1] http://scintilla.org/ [2] http://fox-toolkit.org/