From nochoice at xs4all.nl Wed Aug 10 12:03:29 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Wed Aug 10 11:46:41 2005 Subject: [FR-devel] Collaboration support Message-ID: <42FA2551.1000708@xs4all.nl> Hello everyone, My school has (finally) given me permission to work on FreeRIDE as a school project. Starting september for a period of four to five months I will have three days a week available to work on FreeRIDE. As you can see by looking at the subject I'm going to (try) to implement collaboration support. So before doing alot of research and/or design I'd really like your feedback and or feature-requests to my proposal. FreeRIDE Collaboration First of all, I've thought about implementing a decentralized solution (ie. no server). However I'm fairly certain that, not only it'll be very complex, it will also take far too much work and might even impact security. So I'm proposing a centralized server (program) that will be able to manage multiple collaboration projects. Collab-users would then connect to the server (using SSL) with a username/password. I think it is only logical that all project-files will be stored on an rcs (CVS or subversion). This would include optional chat-transcripts and other necessary files. It would have be possible to download the entire source-tree for a local backup. One possible problem-area is user-management. This will of course greatly depend on your reactions/suggestions. I personally don't think an ACL-solution is needed or necessary. A simple user-role system should suffice. The different roles I've identified as of yet are: administrator, committer, guest. However, is should we keep a user-administration per project or per server and assign users to projects? For storage of the user-administration using yaml files in a secure directory might suffice? (all suggestions welcome) As indicated above I'd like to implement chat-functionality and being able to save chat-transcripts and optionally attach them to source-files. One part functionality I'll most definitely try to implement is allowing (and disallowing!) people to work on the same document at the same time. How I'll go about implementing this I've no idea, but it does have a nice appeal. A feature at the end of my personal wish-list is a diff-presenter showing the original file and the effect of applying a given patch/diff. (Like the one in Eclipse) This can actually be a side-project, it is not essential for collaborating. These are just some ideas I've had for the last month or so, it's in not a complete picture. I hope to be able to find some time next week to create a preliminary analysis and put it up on the Wiki. Well I hope I've made my ideas somewhat clear......I'm very very curious at your reactions. With friendly greetings Jonathan Maasland From roys at mindspring.com Wed Aug 10 13:30:54 2005 From: roys at mindspring.com (Roy Sutton) Date: Wed Aug 10 13:24:59 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FA2551.1000708@xs4all.nl> References: <42FA2551.1000708@xs4all.nl> Message-ID: <42FA39CE.8090407@mindspring.com> Hello Jonathan, I certainly can't speak for the FR team but having used it and begun developing plug-ins for it I do have a few points. FR does not seem to be a stable enough platform for moving forward using it as a collabrative tool. If I were going to focus effort into the product I would try to address the deficiencies in the core product. I believe that one thing you could do that is a natural lead-in to the direction you are going is to implement a project concept. Right now, there is no persistent project concept in FR. There are several other usability issues with the project, though I think some of these are due to FXRuby more than anything else, which is why I have been putting in some effort over at wxRuby. Having said all that, I think everyone on the list would welcome any effort put into FR. FR has been mostly stagnant for a while. Roy Jonathan Maasland wrote: >Hello everyone, > >My school has (finally) given me permission to work on FreeRIDE as a >school project. >Starting september for a period of four to five months I will have three >days a week available to work on FreeRIDE. As you can see by looking at >the subject I'm going to (try) to implement collaboration support. So >before doing alot of research and/or design I'd really like your >feedback and or feature-requests to my proposal. > From nochoice at xs4all.nl Wed Aug 10 15:04:48 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Wed Aug 10 14:48:02 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FA39CE.8090407@mindspring.com> References: <42FA2551.1000708@xs4all.nl> <42FA39CE.8090407@mindspring.com> Message-ID: <42FA4FD0.3020308@xs4all.nl> Hey Roy, Nice to see you here as well :) I totally agree with you. Building project-support will be one of the first things i'll probabely have to do in order to get collaboration-support integrated in FR. I also thought about upgrading FreeRIDE to use wxruby but (as you no doubt know) wxruby is still in 'heavy' development. I don't think it'd be wise start that process until wxruby has at least the first basic Ruby sugar-layer. Unfortunately my school project won't wait for when we get there. Besides, some other developers out there might really really want to do the work ;) The basic functions I had in mind for collab probabely won't take alot of time (mainly cause i'm highly motivated for this project) so any time I would have left at the end (or during the evenings) I'd spend on trying to make further improvements to the FR-core. Thanks Jonathan Roy Sutton wrote: > Hello Jonathan, > > I certainly can't speak for the FR team but having used it and begun > developing plug-ins for it I do have a few points. FR does not seem > to be a stable enough platform for moving forward using it as a > collabrative tool. If I were going to focus effort into the product I > would try to address the deficiencies in the core product. I believe > that one thing you could do that is a natural lead-in to the direction > you are going is to implement a project concept. Right now, there is > no persistent project concept in FR. There are several other > usability issues with the project, though I think some of these are > due to FXRuby more than anything else, which is why I have been > putting in some effort over at wxRuby. > > Having said all that, I think everyone on the list would welcome any > effort put into FR. FR has been mostly stagnant for a while. > > Roy > > Jonathan Maasland wrote: > >> Hello everyone, >> >> My school has (finally) given me permission to work on FreeRIDE as a >> school project. >> Starting september for a period of four to five months I will have three >> days a week available to work on FreeRIDE. As you can see by looking at >> the subject I'm going to (try) to implement collaboration support. So >> before doing alot of research and/or design I'd really like your >> feedback and or feature-requests to my proposal. >> > > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > > From curt at hibbs.com Thu Aug 11 16:38:51 2005 From: curt at hibbs.com (Curt Hibbs) Date: Thu Aug 11 16:32:55 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FA4FD0.3020308@xs4all.nl> References: <42FA2551.1000708@xs4all.nl> <42FA39CE.8090407@mindspring.com> <42FA4FD0.3020308@xs4all.nl> Message-ID: <42FBB75B.9090609@hibbs.com> I think your collaboration ideas are right on. They are all things that have been on the FreeRIDE wish-list since the beginning. It'll be very nice to have someone actually implementing them. Curt Jonathan Maasland wrote: > Hey Roy, > > Nice to see you here as well :) > I totally agree with you. Building project-support will be one of the > first things i'll probabely have to do in order to get > collaboration-support integrated in FR. > > I also thought about upgrading FreeRIDE to use wxruby but (as you no > doubt know) wxruby is still in 'heavy' development. I don't think it'd > be wise start that process until wxruby has at least the first basic > Ruby sugar-layer. Unfortunately my school project won't wait for when we > get there. Besides, some other developers out there might really really > want to do the work ;) > > The basic functions I had in mind for collab probabely won't take alot > of time (mainly cause i'm highly motivated for this project) so any time > I would have left at the end (or during the evenings) I'd spend on > trying to make further improvements to the FR-core. > > Thanks > Jonathan > > Roy Sutton wrote: > > >>Hello Jonathan, >> >>I certainly can't speak for the FR team but having used it and begun >>developing plug-ins for it I do have a few points. FR does not seem >>to be a stable enough platform for moving forward using it as a >>collabrative tool. If I were going to focus effort into the product I >>would try to address the deficiencies in the core product. I believe >>that one thing you could do that is a natural lead-in to the direction >>you are going is to implement a project concept. Right now, there is >>no persistent project concept in FR. There are several other >>usability issues with the project, though I think some of these are >>due to FXRuby more than anything else, which is why I have been >>putting in some effort over at wxRuby. >> >>Having said all that, I think everyone on the list would welcome any >>effort put into FR. FR has been mostly stagnant for a while. >> >>Roy >> >>Jonathan Maasland wrote: >> >> >>>Hello everyone, >>> >>>My school has (finally) given me permission to work on FreeRIDE as a >>>school project. >>>Starting september for a period of four to five months I will have three >>>days a week available to work on FreeRIDE. As you can see by looking at >>>the subject I'm going to (try) to implement collaboration support. So >>>before doing alot of research and/or design I'd really like your >>>feedback and or feature-requests to my proposal. >>> >> >>_______________________________________________ >>Freeride-devel mailing list >>Freeride-devel@rubyforge.org >>http://rubyforge.org/mailman/listinfo/freeride-devel >> >> > > > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > From laurent at moldus.org Fri Aug 12 02:38:19 2005 From: laurent at moldus.org (Laurent Julliard) Date: Fri Aug 12 02:32:22 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FA2551.1000708@xs4all.nl> References: <42FA2551.1000708@xs4all.nl> Message-ID: <42FC43DB.30201@moldus.org> Jonathan Maasland wrote: > Hello everyone, > > My school has (finally) given me permission to work on FreeRIDE as a > school project. > Starting september for a period of four to five months I will have three > days a week available to work on FreeRIDE. As you can see by looking at > the subject I'm going to (try) to implement collaboration support. So > before doing alot of research and/or design I'd really like your > feedback and or feature-requests to my proposal. > > > FreeRIDE Collaboration > > First of all, I've thought about implementing a decentralized solution > (ie. no server). However I'm fairly certain that, not only it'll be very > complex, it will also take far too much work and might even impact > security. So I'm proposing a centralized server (program) that will be > able to manage multiple collaboration projects. Collab-users would then > connect to the server (using SSL) with a username/password. > > I think it is only logical that all project-files will be stored on an > rcs (CVS or subversion). This would include optional chat-transcripts > and other necessary files. It would have be possible to download the > entire source-tree for a local backup. > > One possible problem-area is user-management. This will of course > greatly depend on your reactions/suggestions. I personally don't think > an ACL-solution is needed or necessary. A simple user-role system should > suffice. The different roles I've identified as of yet are: > administrator, committer, guest. However, is should we keep a > user-administration per project or per server and assign users to projects? > > For storage of the user-administration using yaml files in a secure > directory might suffice? (all suggestions welcome) > As others said in this thread FR doesn't have the concept of project right now although there is a embryo for a project plugin in there and I have already posted one or two emails in the ML explaining how I would envisage a full implementation. If I were you I would nto spent too much time on the project/user/role thing. There is nothing really new here plus I believe that it would be good for instance if people could connect to a veersion contreol repo of some sort (e.g. cvs or svn) and see in a FR window new commits listed with an ability to immediately see the diff for instance. > As indicated above I'd like to implement chat-functionality and being > able to save chat-transcripts and optionally attach them to source-files. > > One part functionality I'll most definitely try to implement is allowing > (and disallowing!) people to work on the same document at the same time. > How I'll go about implementing this I've no idea, but it does have a > nice appeal. > This second aspect sounds much more important to me. That is: live communication (IRC channel or Jabber protocol for Jabber4R) and live collaboration (like jointly editing a file or at lest being able to comment a file being developed by others... In my opinion your effort should be in this area as this would be really something new in the programming world > A feature at the end of my personal wish-list is a diff-presenter > showing the original file and the effect of applying a given patch/diff. > (Like the one in Eclipse) This can actually be a side-project, it is not > essential for collaborating. > As you said this is not essential for collaborating. That's the point. Again I don;t think this is very critical and again it is based on the version control part of the work which is not exactly a form of collaboration, at least not live collaboration > These are just some ideas I've had for the last month or so, it's in not > a complete picture. I hope to be able to find some time next week to > create a preliminary analysis and put it up on the Wiki. > > Well I hope I've made my ideas somewhat clear......I'm very very curious > at your reactions. > As other said FR is not rock solid today especially on WIndows. This is mostly due to 2 reasons: - FXRuby/FOX problems on the Win32 platform - I/O Thread problems with Ruby on WIn32 that cause problems with debugging. Other thant that I thin knothing prevent you from writing your project as a FR plugin. Another option is to develop an independent FXRuby/FOX application that we'll later integrate as a FR plugin. THis is what we have done with the RDoc and the IRB plugins. > With friendly greetings > Jonathan Maasland > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > -- Laurent JULLIARD http://www.moldus.org/~laurent From nochoice at xs4all.nl Sun Aug 14 07:05:16 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Sun Aug 14 06:48:00 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FC43DB.30201@moldus.org> References: <42FA2551.1000708@xs4all.nl> <42FC43DB.30201@moldus.org> Message-ID: <42FF256C.4000506@xs4all.nl> Hello Laurent, > As others said in this thread FR doesn't have the concept of project > right now although there is a embryo for a project plugin in there and > I have already posted one or two emails in the ML explaining how I > would envisage a full implementation. After a long search I finally found the following post you made: http://rubyforge.org/pipermail/freeride-devel/2004-October/000147.html which also links to some older posts by you and Rich Kilmer. So to (hopefully) start the discussion on the form of the project-plugin here goes (sorry for the long text): ----------------- First of all I don't think we should force a user to have to create a project. The way FR works now should be enhanced with a new 'mode' the user can choose to use. I'd still like to open a stand-alone Ruby program, make some changes and run it without having to go through a single dialog. Secondly I think we should allow only one open project. Once a project gets closed we should ask the user if he/she wants to close all associated files (a "don't ask again" dialog). Upon closing the project all opened project-files should be saved to the project-properties-file. The new Project-view (or project-explorer) should show the following tree: + Project-name -- + Source director(y|ies) -- + Require paths The source-directories should be expandable to show all files. The source-view should also be included/expandable in the tree. A right-click context menu of the project-name should show the following options: - Add source directory - Add required directory - Show project properties - Run project (default) - more?? The project properties dialog should allow the user to: - Choose the Ruby interpreter to use - Project references (allowing for project dependencies) - Specifying multiple run-targets, allowing full control over the command executed (params etc) - Setting a default run-target Future functions for the project properties: - Manage rcs-settings - Manage collaboration settings - Choose the file-encoding used (when we get Unicode support) ---------------- BTW I took a look at the wiki and just to be on the safe side, I'd like to ask: the entry http://freeride.rubyforge.org/wiki/wiki.pl?ProjectManagementArchitecture (mostly concerning meta-data) isn't relevant for the project-plugin, is it? It all looks very nice and innovative but what the advantages would be to add meta-data is beyond me. Especially looking at the current state of FR. > > This second aspect sounds much more important to me. That is: live > communication (IRC channel or Jabber protocol for Jabber4R) and live > collaboration (like jointly editing a file or at lest being able to > comment a file being developed by others... > > In my opinion your effort should be in this area as this would be > really something new in the programming world Thanks for the pointer on Jabber. I'd already thought about it once but after reading more carefully about Jabber I realized it's a very capable and generic communications protocol. It should be (relatively) easy to use it for both chat-communications and some form of realtime cooperative editing. I am going to do some research on Jabber, writing some simple programs for testing and getting a feel for Jabber. (damn my schedule is over-flowing with research) A server-less collaboration solution is forming in my head, I'd need to think about the implications but using Jabber would definitely make it possible. I'll get back to you all on this specific topic at a later stage. Thanks Jonathan From laurent at moldus.org Sun Aug 14 16:09:56 2005 From: laurent at moldus.org (Laurent Julliard) Date: Sun Aug 14 16:03:44 2005 Subject: [FR-devel] Collaboration support In-Reply-To: <42FF256C.4000506@xs4all.nl> References: <42FA2551.1000708@xs4all.nl> <42FC43DB.30201@moldus.org> <42FF256C.4000506@xs4all.nl> Message-ID: <42FFA514.1060504@moldus.org> Jonathan, The message you found is the one I had in mind. And to make this reply as short as possible, the one thing I can say is: YES! i agree with everything you said in your message. One thing about collaborative editing: I don't think the goal is to allow two people to edit the same file at the same time. My view of it is that one should be able to look at other's file while they are editing them or as they are in the repo and add some comments to it, almost like if you were annotating the file either to ask questions or to suggest how to improve a piece of code. Imagine if peopl could see some Ruby gurus at work and just being able to learn from them live just by looking at how they create code in real time. Plus they could ask some questions live on the code. Of course this would be possible only if the developer agrees to be watched. Laurent Jonathan Maasland wrote: > Hello Laurent, > > >>As others said in this thread FR doesn't have the concept of project >>right now although there is a embryo for a project plugin in there and >>I have already posted one or two emails in the ML explaining how I >>would envisage a full implementation. > > > After a long search I finally found the following post you made: > http://rubyforge.org/pipermail/freeride-devel/2004-October/000147.html > which also links to some older posts by you and Rich Kilmer. > > So to (hopefully) start the discussion on the form of the project-plugin > here goes (sorry for the long text): > ----------------- > First of all I don't think we should force a user to have to create a > project. The way FR works now should be enhanced with a new 'mode' the > user can choose to use. I'd still like to open a stand-alone Ruby > program, make some changes and run it without having to go through a > single dialog. > > Secondly I think we should allow only one open project. Once a project > gets closed we should ask the user if he/she wants to close all > associated files (a "don't ask again" dialog). Upon closing the project > all opened project-files should be saved to the project-properties-file. > > The new Project-view (or project-explorer) should show the following tree: > + Project-name > -- + Source director(y|ies) > -- + Require paths > > The source-directories should be expandable to show all files. The > source-view should also be included/expandable in the tree. > > A right-click context menu of the project-name should show the following > options: > - Add source directory > - Add required directory > - Show project properties > - Run project (default) > - more?? > > The project properties dialog should allow the user to: > - Choose the Ruby interpreter to use > - Project references (allowing for project dependencies) > - Specifying multiple run-targets, allowing full control over the > command executed (params etc) > - Setting a default run-target > > Future functions for the project properties: > - Manage rcs-settings > - Manage collaboration settings > - Choose the file-encoding used (when we get Unicode support) > ---------------- > > BTW > I took a look at the wiki and just to be on the safe side, I'd like to > ask: the entry > http://freeride.rubyforge.org/wiki/wiki.pl?ProjectManagementArchitecture > (mostly concerning meta-data) isn't relevant for the project-plugin, is > it? It all looks very nice and innovative but what the advantages would > be to add meta-data is beyond me. Especially looking at the current > state of FR. > > >>This second aspect sounds much more important to me. That is: live >>communication (IRC channel or Jabber protocol for Jabber4R) and live >>collaboration (like jointly editing a file or at lest being able to >>comment a file being developed by others... >> >>In my opinion your effort should be in this area as this would be >>really something new in the programming world > > > Thanks for the pointer on Jabber. I'd already thought about it once but > after reading more carefully about Jabber I realized it's a very capable > and generic communications protocol. It should be (relatively) easy to > use it for both chat-communications and some form of realtime > cooperative editing. I am going to do some research on Jabber, writing > some simple programs for testing and getting a feel for Jabber. (damn my > schedule is over-flowing with research) > A server-less collaboration solution is forming in my head, I'd need to > think about the implications but using Jabber would definitely make it > possible. > I'll get back to you all on this specific topic at a later stage. > > Thanks > Jonathan > > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > -- Laurent JULLIARD http://www.moldus.org/~laurent From roys at mindspring.com Sat Aug 20 11:07:39 2005 From: roys at mindspring.com (Roy Sutton) Date: Sat Aug 20 11:01:23 2005 Subject: [FR-devel] [Fwd: [fxruby-users] [ANN] FXRuby 1.4.1 Now Available] Message-ID: <4307473B.9040307@mindspring.com> FXRuby 1.4.1 is available. I converted my FreeRIDE project over to it. It runs but there are some very strange things going on with the menus. Just thought I'd give everyone a heads up. Roy -------- Original Message -------- Subject: [fxruby-users] [ANN] FXRuby 1.4.1 Now Available Date: Sat, 20 Aug 2005 09:36:32 -0500 From: Lyle Johnson Reply-To: fxruby-users@rubyforge.org To: fxruby-announce@rubyforge.org, fxruby-users@rubyforge.org All, At long last, FXRuby version 1.4.1 is available for download from this page: http://rubyforge.org/frs/?group_id=300&release_id=2719 Since this is the first release in this series (i.e. compatible with FOX 1.4), it should be considered unstable. Please report any problems either to the mailing list, or even better, log them in the Bug Tracker at RubyForge, here: http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse As usual, the code is provided as a Win32 installer or a binary Gem (both compatible with the latest One-Click Installer for Ruby 1.8.2), as a source gem, and as a source tarball. For instructions on compiling FXRuby from source, please see: http://www.fxruby.org/doc/build.html For a summary of the changes in this release, please see this page: http://www.fxruby.org/doc/changes.html As always, the FXRuby home page is here: http://www.fxruby.org Enjoy, Lyle _______________________________________________ fxruby-users mailing list fxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/fxruby-users From laurent at moldus.org Mon Aug 22 06:45:47 2005 From: laurent at moldus.org (Laurent Julliard) Date: Mon Aug 22 06:39:16 2005 Subject: [FR-devel] [Fwd: [fxruby-users] [ANN] FXRuby 1.4.1 Now Available] In-Reply-To: <4307473B.9040307@mindspring.com> References: <4307473B.9040307@mindspring.com> Message-ID: <4309ACDB.8090807@moldus.org> Roy Sutton wrote: > FXRuby 1.4.1 is available. I converted my FreeRIDE project over to it. > It runs but there are some very strange things going on with the menus. > Just thought I'd give everyone a heads up. > > Roy > Well if it runs with no modification it means that 1.2 and 1.4 are fairly upward compatible. I have to look at the menu. This was one of the most significant changes when we went from fox 1.0 to 1.2 and honestly I have not been impressed by the new 1.2 FXmenu... API. Maybe they have changed it again. Is there a file somewhere summarizing the changes between 1.2 and 1.4? Laurent From roys at mindspring.com Mon Aug 22 13:13:31 2005 From: roys at mindspring.com (Roy Sutton) Date: Mon Aug 22 13:07:28 2005 Subject: [FR-devel] [Fwd: [fxruby-users] [ANN] FXRuby 1.4.1 Now Available] In-Reply-To: <4309ACDB.8090807@moldus.org> References: <4307473B.9040307@mindspring.com> <4309ACDB.8090807@moldus.org> Message-ID: <430A07BB.7030501@mindspring.com> Well, I spoke a bit too soon. I think I see why the menus aren't doing what they're supposed to: Failing to start: rubyide_fox_gui-outputpane Failing to start: rubyide_fox_gui Failing to start: rubyide_tools_fox_source_browser Failing to start: HelloWorld Failing to start: rubyide_tools_fox_script_runner Failing to start: rubyide_tools_fox_file_browser Failing to start: KeyManager Failing to start: rubyide_tools_fox_ri Failing to start: rubyide_tools_fox_irb Failing to start: rubyide_tools_fox_databus_inspector Failing to start: rubyide_tools_fox_configurator Failing to start: rubyide_tools_fox_debugger Failing to start: rubyide_tools_configurator The changelog can be found here: http://www.fxruby.org/doc/changes.html However, you won't see any of the big changes there. I think you'll have to see the Fox 1.2 -> 1.4 changelog. I may look into why those won't start Laurent Julliard wrote: > Roy Sutton wrote: > >> FXRuby 1.4.1 is available. I converted my FreeRIDE project over to >> it. It runs but there are some very strange things going on with the >> menus. Just thought I'd give everyone a heads up. >> >> Roy >> > > Well if it runs with no modification it means that 1.2 and 1.4 are > fairly upward compatible. I have to look at the menu. This was one of > the most significant changes when we went from fox 1.0 to 1.2 and > honestly I have not been impressed by the new 1.2 FXmenu... API. Maybe > they have changed it again. > > Is there a file somewhere summarizing the changes between 1.2 and 1.4? > > Laurent > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > > > From roys at mindspring.com Mon Aug 22 23:47:20 2005 From: roys at mindspring.com (Roy Sutton) Date: Mon Aug 22 23:41:01 2005 Subject: [FR-devel] [Fwd: [fxruby-users] [ANN] FXRuby 1.4.1 Now Available] In-Reply-To: <430A07BB.7030501@mindspring.com> References: <4307473B.9040307@mindspring.com> <4309ACDB.8090807@moldus.org> <430A07BB.7030501@mindspring.com> Message-ID: <430A9C48.9020107@mindspring.com> The problem is that notify() now tries to call a Fox function instead of a function in freebase. Roy Sutton wrote: > Well, > > I spoke a bit too soon. I think I see why the menus aren't doing what > they're supposed to: > > Failing to start: rubyide_fox_gui-outputpane > Failing to start: rubyide_fox_gui > Failing to start: rubyide_tools_fox_source_browser > Failing to start: HelloWorld > Failing to start: rubyide_tools_fox_script_runner > Failing to start: rubyide_tools_fox_file_browser > Failing to start: KeyManager > Failing to start: rubyide_tools_fox_ri > Failing to start: rubyide_tools_fox_irb > Failing to start: rubyide_tools_fox_databus_inspector > Failing to start: rubyide_tools_fox_configurator > Failing to start: rubyide_tools_fox_debugger > Failing to start: rubyide_tools_configurator > > The changelog can be found here: http://www.fxruby.org/doc/changes.html > > However, you won't see any of the big changes there. I think you'll > have to see the Fox 1.2 -> 1.4 changelog. > > I may look into why those won't start > > Laurent Julliard wrote: > >> Roy Sutton wrote: >> >>> FXRuby 1.4.1 is available. I converted my FreeRIDE project over to >>> it. It runs but there are some very strange things going on with >>> the menus. Just thought I'd give everyone a heads up. >>> >>> Roy >>> >> >> Well if it runs with no modification it means that 1.2 and 1.4 are >> fairly upward compatible. I have to look at the menu. This was one of >> the most significant changes when we went from fox 1.0 to 1.2 and >> honestly I have not been impressed by the new 1.2 FXmenu... API. >> Maybe they have changed it again. >> >> Is there a file somewhere summarizing the changes between 1.2 and 1.4? >> >> Laurent >> _______________________________________________ >> Freeride-devel mailing list >> Freeride-devel@rubyforge.org >> http://rubyforge.org/mailman/listinfo/freeride-devel >> >> >> > From nochoice at xs4all.nl Tue Aug 23 15:34:54 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Tue Aug 23 15:17:00 2005 Subject: [FR-devel] CloseAll command Message-ID: <430B7A5E.20405@xs4all.nl> Is there any reason that the CloseAll command isn't in the File menu?? I updated core_commands.rb and component_layout.yaml a bit so that the command-availability works the same for Close as for CloseAll. I also added the command to the menu. Patch is attached. Jonathan --------------- Index: plugins/rubyide_commands/core_commands.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_commands/core_commands.rb,v retrieving revision 1.15 diff -b -u -r1.15 core_commands.rb --- plugins/rubyide_commands/core_commands.rb 3 Mar 2005 00:52:30 -0000 1.15 +++ plugins/rubyide_commands/core_commands.rb 23 Aug 2005 19:10:31 -0000 @@ -109,21 +109,9 @@ editpane.close if editpane end cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') - cmd.manage_availability do |command| - plugin['/system/ui/current'].subscribe do |event, slot| - if slot.name=="EditPane" - case event - when :notify_slot_link - command.availability=true - when :notify_slot_unlink - command.availability=false - end - end - end - end key_mgr.bind("App/File/Close", :ctrl, :W) - cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| + cmd = cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| done = true cmd_slot['/system/ui/components/EditPane'].each_slot do |editpane| if editpane.manager.close(true)=="cancel" @@ -133,6 +121,22 @@ end done end + cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') + + [ "Close", "CloseAll" ].each do |command| + cmd_mgr.command("App/File/"+command).manage_availability do |command| + plugin['/system/ui/current'].subscribe do |event, slot| + if slot.name=="EditPane" + case event + when :notify_slot_link + command.availability = true + when :notify_slot_unlink + command.availability = false + end + end + end + end + end cmd_mgr.add("App/File/SaveAll", "S&ave All", "Save All Files...") do |cmd_slot| done = true Index: plugins/rubyide_gui/component_layout.yaml =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_gui/component_layout.yaml,v retrieving revision 1.4 diff -b -u -r1.4 component_layout.yaml --- plugins/rubyide_gui/component_layout.yaml 15 Jun 2003 15:14:20 -0000 1.4 +++ plugins/rubyide_gui/component_layout.yaml 23 Aug 2005 19:10:34 -0000 @@ -51,10 +51,11 @@ - "1": App/File/New - "2": App/File/Open - "3": App/File/Close - - "4": App/File/Save - - "5": App/File/SaveAs - - "6": SEPARATOR - - "7": App/Exit + - "4": App/File/CloseAll + - "5": App/File/Save + - "6": App/File/SaveAs + - "7": SEPARATOR + - "8": App/Exit - "2": '' "|": - Attributes: '' -------------- next part -------------- Index: plugins/rubyide_commands/core_commands.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_commands/core_commands.rb,v retrieving revision 1.15 diff -b -u -r1.15 core_commands.rb --- plugins/rubyide_commands/core_commands.rb 3 Mar 2005 00:52:30 -0000 1.15 +++ plugins/rubyide_commands/core_commands.rb 23 Aug 2005 19:10:31 -0000 @@ -109,21 +109,9 @@ editpane.close if editpane end cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') - cmd.manage_availability do |command| - plugin['/system/ui/current'].subscribe do |event, slot| - if slot.name=="EditPane" - case event - when :notify_slot_link - command.availability=true - when :notify_slot_unlink - command.availability=false - end - end - end - end key_mgr.bind("App/File/Close", :ctrl, :W) - cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| + cmd = cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| done = true cmd_slot['/system/ui/components/EditPane'].each_slot do |editpane| if editpane.manager.close(true)=="cancel" @@ -133,6 +121,22 @@ end done end + cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') + + [ "Close", "CloseAll" ].each do |command| + cmd_mgr.command("App/File/"+command).manage_availability do |command| + plugin['/system/ui/current'].subscribe do |event, slot| + if slot.name=="EditPane" + case event + when :notify_slot_link + command.availability = true + when :notify_slot_unlink + command.availability = false + end + end + end + end + end cmd_mgr.add("App/File/SaveAll", "S&ave All", "Save All Files...") do |cmd_slot| done = true Index: plugins/rubyide_gui/component_layout.yaml =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_gui/component_layout.yaml,v retrieving revision 1.4 diff -b -u -r1.4 component_layout.yaml --- plugins/rubyide_gui/component_layout.yaml 15 Jun 2003 15:14:20 -0000 1.4 +++ plugins/rubyide_gui/component_layout.yaml 23 Aug 2005 19:10:34 -0000 @@ -51,10 +51,11 @@ - "1": App/File/New - "2": App/File/Open - "3": App/File/Close - - "4": App/File/Save - - "5": App/File/SaveAs - - "6": SEPARATOR - - "7": App/Exit + - "4": App/File/CloseAll + - "5": App/File/Save + - "6": App/File/SaveAs + - "7": SEPARATOR + - "8": App/Exit - "2": '' "|": - Attributes: '' From Laurent.Julliard at xrce.xerox.com Wed Aug 24 08:30:46 2005 From: Laurent.Julliard at xrce.xerox.com (Laurent Julliard) Date: Wed Aug 24 08:24:29 2005 Subject: [FR-devel] CloseAll command In-Reply-To: <430B7A5E.20405@xs4all.nl> References: <430B7A5E.20405@xs4all.nl> Message-ID: <430C6876.1030406@xrce.xerox.com> Jonathan Maasland wrote: > Is there any reason that the CloseAll command isn't in the File menu?? > I updated core_commands.rb and component_layout.yaml a bit so that the > command-availability works the same for Close as for CloseAll. I also > added the command to the menu. > > Patch is attached. > > Jonathan > Thanks for the patch. I just applied it to my own working copy and it works well. I'll commit it when I have access to the CVS repo. Laurent From laurent at moldus.org Thu Aug 25 05:53:45 2005 From: laurent at moldus.org (Laurent Julliard) Date: Thu Aug 25 05:47:14 2005 Subject: [FR-devel] CloseAll command In-Reply-To: <430C6876.1030406@xrce.xerox.com> References: <430B7A5E.20405@xs4all.nl> <430C6876.1030406@xrce.xerox.com> Message-ID: <430D9529.5070507@moldus.org> Laurent Julliard wrote: > Jonathan Maasland wrote: > >> Is there any reason that the CloseAll command isn't in the File menu?? >> I updated core_commands.rb and component_layout.yaml a bit so that the >> command-availability works the same for Close as for CloseAll. I also >> added the command to the menu. >> >> Patch is attached. >> >> Jonathan >> > > Thanks for the patch. I just applied it to my own working copy and it > works well. I'll commit it when I have access to the CVS repo. > > Laurent > Well actually it doesn't work that well. If you do a close all and then try to exit nothing happens. It seems like there has to be at least one edit pane open for the application to close. This is a side effect of th patch. Csan you look into this? Thanks! Laurent From nochoice at xs4all.nl Thu Aug 25 15:25:44 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Thu Aug 25 13:19:22 2005 Subject: [FR-devel] CloseAll command In-Reply-To: <430D9529.5070507@moldus.org> References: <430B7A5E.20405@xs4all.nl> <430C6876.1030406@xrce.xerox.com> <430D9529.5070507@moldus.org> Message-ID: <430E1B38.2000503@xs4all.nl> That was weird indeed.... I added availability behaviour to the CloseAll command. When Exit is invoked it calls project/Close which in turn calls CloseAll. The fix is simple but it still took me twenty minutes to figure out. I attached a completely new patch, the fix I copy-n-pasted below. Thanks for spotting this! Jonathan Laurent Julliard wrote: > > Well actually it doesn't work that well. If you do a close all and > then try to exit nothing happens. It seems like there has to be at > least one edit pane open for the application to close. This is a side > effect of th patch. Csan you look into this? > > Thanks! > > Laurent > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > > Index: plugins/rubyide_project/project.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_project/project.rb,v retrieving revision 1.2 diff -b -u -r1.2 project.rb --- plugins/rubyide_project/project.rb 1 Sep 2003 21:42:11 -0000 1.2 +++ plugins/rubyide_project/project.rb 25 Aug 2005 17:10:07 -0000 @@ -44,7 +44,10 @@ def close @subscription.cancel @subscription = nil - done = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll').invoke + done = true + cmd = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll') + done = cmd.invoke if cmd.available? + if done @plugin['/project/current'].prune else -------------- next part -------------- Index: plugins/rubyide_commands/core_commands.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_commands/core_commands.rb,v retrieving revision 1.15 diff -b -u -r1.15 core_commands.rb --- plugins/rubyide_commands/core_commands.rb 3 Mar 2005 00:52:30 -0000 1.15 +++ plugins/rubyide_commands/core_commands.rb 25 Aug 2005 17:10:06 -0000 @@ -109,21 +109,9 @@ editpane.close if editpane end cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') - cmd.manage_availability do |command| - plugin['/system/ui/current'].subscribe do |event, slot| - if slot.name=="EditPane" - case event - when :notify_slot_link - command.availability=true - when :notify_slot_unlink - command.availability=false - end - end - end - end key_mgr.bind("App/File/Close", :ctrl, :W) - cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| + cmd = cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| done = true cmd_slot['/system/ui/components/EditPane'].each_slot do |editpane| if editpane.manager.close(true)=="cancel" @@ -131,8 +119,25 @@ break end end + plugin['log/debug'] << "returning #{done}" done end + cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') + + [ "Close", "CloseAll" ].each do |command| + cmd_mgr.command("App/File/"+command).manage_availability do |command| + plugin['/system/ui/current'].subscribe do |event, slot| + if slot.name=="EditPane" + case event + when :notify_slot_link + command.availability = true + when :notify_slot_unlink + command.availability = false + end + end + end + end + end cmd_mgr.add("App/File/SaveAll", "S&ave All", "Save All Files...") do |cmd_slot| done = true Index: plugins/rubyide_project/project.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_project/project.rb,v retrieving revision 1.2 diff -b -u -r1.2 project.rb --- plugins/rubyide_project/project.rb 1 Sep 2003 21:42:11 -0000 1.2 +++ plugins/rubyide_project/project.rb 25 Aug 2005 17:10:07 -0000 @@ -44,7 +44,10 @@ def close @subscription.cancel @subscription = nil - done = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll').invoke + done = true + cmd = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll') + done = cmd.invoke if cmd.available? + if done @plugin['/project/current'].prune else Index: plugins/rubyide_gui/component_layout.yaml =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_gui/component_layout.yaml,v retrieving revision 1.4 diff -b -u -r1.4 component_layout.yaml --- plugins/rubyide_gui/component_layout.yaml 15 Jun 2003 15:14:20 -0000 1.4 +++ plugins/rubyide_gui/component_layout.yaml 25 Aug 2005 17:10:07 -0000 @@ -51,10 +51,11 @@ - "1": App/File/New - "2": App/File/Open - "3": App/File/Close - - "4": App/File/Save - - "5": App/File/SaveAs - - "6": SEPARATOR - - "7": App/Exit + - "4": App/File/CloseAll + - "5": App/File/Save + - "6": App/File/SaveAs + - "7": SEPARATOR + - "8": App/Exit - "2": '' "|": - Attributes: '' From nochoice at xs4all.nl Thu Aug 25 16:43:14 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Thu Aug 25 14:36:58 2005 Subject: [FR-devel] CloseAll command In-Reply-To: <430E1B38.2000503@xs4all.nl> References: <430B7A5E.20405@xs4all.nl> <430C6876.1030406@xrce.xerox.com> <430D9529.5070507@moldus.org> <430E1B38.2000503@xs4all.nl> Message-ID: <430E2D62.6030007@xs4all.nl> I forgot to add a accelerator key for the command, how does Ctrl+Shift+w sound? Also, I accidentally left a debug statement in there so please forget the previous patch and use this one.... Thanks Jonathan Jonathan Maasland wrote: >That was weird indeed.... I added availability behaviour to the CloseAll >command. >When Exit is invoked it calls project/Close which in turn calls CloseAll. > >The fix is simple but it still took me twenty minutes to figure out. >I attached a completely new patch, the fix I copy-n-pasted below. > >Thanks for spotting this! > >Jonathan > > >Laurent Julliard wrote: > > > >>Well actually it doesn't work that well. If you do a close all and >>then try to exit nothing happens. It seems like there has to be at >>least one edit pane open for the application to close. This is a side >>effect of th patch. Csan you look into this? >> >>Thanks! >> >>Laurent >>_______________________________________________ >>Freeride-devel mailing list >>Freeride-devel@rubyforge.org >>http://rubyforge.org/mailman/listinfo/freeride-devel >> >> >> >> >Index: plugins/rubyide_project/project.rb >=================================================================== >RCS file: /var/cvs/freeride/freeride/plugins/rubyide_project/project.rb,v >retrieving revision 1.2 >diff -b -u -r1.2 project.rb >--- plugins/rubyide_project/project.rb 1 Sep 2003 21:42:11 -0000 1.2 >+++ plugins/rubyide_project/project.rb 25 Aug 2005 17:10:07 -0000 >@@ -44,7 +44,10 @@ > def close > @subscription.cancel > @subscription = nil >- done = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll').invoke >+ done = true >+ cmd = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll') >+ done = cmd.invoke if cmd.available? >+ > if done > @plugin['/project/current'].prune > else > > > >------------------------------------------------------------------------ > >Index: plugins/rubyide_commands/core_commands.rb >=================================================================== >RCS file: /var/cvs/freeride/freeride/plugins/rubyide_commands/core_commands.rb,v >retrieving revision 1.15 >diff -b -u -r1.15 core_commands.rb >--- plugins/rubyide_commands/core_commands.rb 3 Mar 2005 00:52:30 -0000 1.15 >+++ plugins/rubyide_commands/core_commands.rb 25 Aug 2005 17:10:06 -0000 >@@ -109,21 +109,9 @@ > editpane.close if editpane > end > cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') >- cmd.manage_availability do |command| >- plugin['/system/ui/current'].subscribe do |event, slot| >- if slot.name=="EditPane" >- case event >- when :notify_slot_link >- command.availability=true >- when :notify_slot_unlink >- command.availability=false >- end >- end >- end >- end > key_mgr.bind("App/File/Close", :ctrl, :W) > >- cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| >+ cmd = cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| > done = true > cmd_slot['/system/ui/components/EditPane'].each_slot do |editpane| > if editpane.manager.close(true)=="cancel" >@@ -131,8 +119,25 @@ > break > end > end >+ plugin['log/debug'] << "returning #{done}" > done > end >+ cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') >+ >+ [ "Close", "CloseAll" ].each do |command| >+ cmd_mgr.command("App/File/"+command).manage_availability do |command| >+ plugin['/system/ui/current'].subscribe do |event, slot| >+ if slot.name=="EditPane" >+ case event >+ when :notify_slot_link >+ command.availability = true >+ when :notify_slot_unlink >+ command.availability = false >+ end >+ end >+ end >+ end >+ end > > cmd_mgr.add("App/File/SaveAll", "S&ave All", "Save All Files...") do |cmd_slot| > done = true >Index: plugins/rubyide_project/project.rb >=================================================================== >RCS file: /var/cvs/freeride/freeride/plugins/rubyide_project/project.rb,v >retrieving revision 1.2 >diff -b -u -r1.2 project.rb >--- plugins/rubyide_project/project.rb 1 Sep 2003 21:42:11 -0000 1.2 >+++ plugins/rubyide_project/project.rb 25 Aug 2005 17:10:07 -0000 >@@ -44,7 +44,10 @@ > def close > @subscription.cancel > @subscription = nil >- done = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll').invoke >+ done = true >+ cmd = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll') >+ done = cmd.invoke if cmd.available? >+ > if done > @plugin['/project/current'].prune > else >Index: plugins/rubyide_gui/component_layout.yaml >=================================================================== >RCS file: /var/cvs/freeride/freeride/plugins/rubyide_gui/component_layout.yaml,v >retrieving revision 1.4 >diff -b -u -r1.4 component_layout.yaml >--- plugins/rubyide_gui/component_layout.yaml 15 Jun 2003 15:14:20 -0000 1.4 >+++ plugins/rubyide_gui/component_layout.yaml 25 Aug 2005 17:10:07 -0000 >@@ -51,10 +51,11 @@ > - "1": App/File/New > - "2": App/File/Open > - "3": App/File/Close >- - "4": App/File/Save >- - "5": App/File/SaveAs >- - "6": SEPARATOR >- - "7": App/Exit >+ - "4": App/File/CloseAll >+ - "5": App/File/Save >+ - "6": App/File/SaveAs >+ - "7": SEPARATOR >+ - "8": App/Exit > - "2": '' > "|": > - Attributes: '' > > >------------------------------------------------------------------------ > >_______________________________________________ >Freeride-devel mailing list >Freeride-devel@rubyforge.org >http://rubyforge.org/mailman/listinfo/freeride-devel > > -------------- next part -------------- Index: plugins/rubyide_commands/core_commands.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_commands/core_commands.rb,v retrieving revision 1.15 diff -b -u -r1.15 core_commands.rb --- plugins/rubyide_commands/core_commands.rb 3 Mar 2005 00:52:30 -0000 1.15 +++ plugins/rubyide_commands/core_commands.rb 25 Aug 2005 18:32:01 -0000 @@ -109,21 +109,9 @@ editpane.close if editpane end cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') - cmd.manage_availability do |command| - plugin['/system/ui/current'].subscribe do |event, slot| - if slot.name=="EditPane" - case event - when :notify_slot_link - command.availability=true - when :notify_slot_unlink - command.availability=false - end - end - end - end key_mgr.bind("App/File/Close", :ctrl, :W) - cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| + cmd = cmd_mgr.add("App/File/CloseAll", "C&lose All", "Close All Files...") do |cmd_slot| done = true cmd_slot['/system/ui/components/EditPane'].each_slot do |editpane| if editpane.manager.close(true)=="cancel" @@ -133,6 +121,23 @@ end done end + cmd.availability = plugin['/system/ui/current'].has_child?('EditPane') + key_mgr.bind("App/File/CloseAll", :ctrl, :shift, :W) + + [ "Close", "CloseAll" ].each do |command| + cmd_mgr.command("App/File/"+command).manage_availability do |command| + plugin['/system/ui/current'].subscribe do |event, slot| + if slot.name=="EditPane" + case event + when :notify_slot_link + command.availability = true + when :notify_slot_unlink + command.availability = false + end + end + end + end + end cmd_mgr.add("App/File/SaveAll", "S&ave All", "Save All Files...") do |cmd_slot| done = true Index: plugins/rubyide_project/project.rb =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_project/project.rb,v retrieving revision 1.2 diff -b -u -r1.2 project.rb --- plugins/rubyide_project/project.rb 1 Sep 2003 21:42:11 -0000 1.2 +++ plugins/rubyide_project/project.rb 25 Aug 2005 18:32:02 -0000 @@ -44,7 +44,10 @@ def close @subscription.cancel @subscription = nil - done = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll').invoke + done = true + cmd = @plugin['/system/ui/commands'].manager.command('App/File/CloseAll') + done = cmd.invoke if cmd.available? + if done @plugin['/project/current'].prune else Index: plugins/rubyide_gui/component_layout.yaml =================================================================== RCS file: /var/cvs/freeride/freeride/plugins/rubyide_gui/component_layout.yaml,v retrieving revision 1.4 diff -b -u -r1.4 component_layout.yaml --- plugins/rubyide_gui/component_layout.yaml 15 Jun 2003 15:14:20 -0000 1.4 +++ plugins/rubyide_gui/component_layout.yaml 25 Aug 2005 18:32:03 -0000 @@ -51,10 +51,11 @@ - "1": App/File/New - "2": App/File/Open - "3": App/File/Close - - "4": App/File/Save - - "5": App/File/SaveAs - - "6": SEPARATOR - - "7": App/Exit + - "4": App/File/CloseAll + - "5": App/File/Save + - "6": App/File/SaveAs + - "7": SEPARATOR + - "8": App/Exit - "2": '' "|": - Attributes: '' From nochoice at xs4all.nl Tue Aug 30 21:20:24 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Tue Aug 30 19:13:16 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) Message-ID: <431505D8.7010202@xs4all.nl> ATM I'm tinkering with FreeRide to add support for multiple Ruby-interpreters so you can (at a later stadium) select which Ruby version to use when executing a run target. The run-targets are part of the project-support I'm building. But as I was playing with a new Preference subpanel I noticed something. Each time a subpanel is shown (clicked) there is a call made to get_config_properties. This happens even when the panel has been changed. To see this behaviour (bug?) open the preferences-dialog, open Debugger/Run and input something in path to ruby, then click the unused subpanel and change back to Debugger/Run. The edits made are gone because get_config_properties got called again. The problem lies in rubyide_tools_fox_configurator/fox_configurator.rb on line 237, which I think should be(come): @loaded_configs = [] unless @loaded_configs unless @loaded_configs.include?config_slot.name config_slot.manager.get_config_properties(config_slot) #this was originally line 237 @loaded_configs << config_slot.name end However after looking at the code further I'm really starting to doubt myself. Is it intended that you can only save the main-category you're looking at when you click OK? I'd just like to know before I try fixing things which aren't broken :) Thanks Jonathan From laurent at moldus.org Wed Aug 31 02:54:01 2005 From: laurent at moldus.org (Laurent Julliard) Date: Wed Aug 31 02:47:17 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) In-Reply-To: <431505D8.7010202@xs4all.nl> References: <431505D8.7010202@xs4all.nl> Message-ID: <43155409.1070301@moldus.org> Jonathan Maasland wrote: > ATM I'm tinkering with FreeRide to add support for multiple > Ruby-interpreters so you can (at a later stadium) select which Ruby > version to use when executing a run target. The run-targets are part of > the project-support I'm building. > > But as I was playing with a new Preference subpanel I noticed something. > Each time a subpanel is shown (clicked) there is a call made to > get_config_properties. This happens even when the panel has been changed. > > To see this behaviour (bug?) open the preferences-dialog, open > Debugger/Run and input something in path to ruby, then click the unused > subpanel and change back to Debugger/Run. The edits made are gone > because get_config_properties got called again. > > The problem lies in rubyide_tools_fox_configurator/fox_configurator.rb > on line 237, which I think should be(come): > > @loaded_configs = [] unless @loaded_configs > unless @loaded_configs.include?config_slot.name > config_slot.manager.get_config_properties(config_slot) > #this was originally line 237 > @loaded_configs << config_slot.name > end > > However after looking at the code further I'm really starting to doubt > myself. Is it intended that you can only save the main-category you're > looking at when you click OK? > > I'd just like to know before I try fixing things which aren't broken :) > > Thanks > Jonathan > This is actually the intended behavior. This is why there is both an Apply and OK button. Apply allows you to save the changes you've made in the current panel where as OK is equivalent to Apply and Close the prefrence dialog box. I think what could be done to improve the current system is that if one tries to witch to a different panel that has changes in it that have not been "applied" then a dialog box should appear to inform the user that changes will be lost and whether s/he is ok or not. Laurent From nochoice at xs4all.nl Wed Aug 31 05:52:07 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Wed Aug 31 03:44:55 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) In-Reply-To: <43155409.1070301@moldus.org> References: <431505D8.7010202@xs4all.nl> <43155409.1070301@moldus.org> Message-ID: <43157DC7.3060807@xs4all.nl> So basically that would mean each configurator-panel should provide a ".modified?" method? Also each control would have to be monitored for changes. The first idea I have is to just add "modified=true" at all the places where the controls pick up changes (ie. in blocks or needed methods). Or is there an easier, read more Ruby-ish, way to implement this? It might be that I'm missing an obvious solution because I'm not all that awake... Luckily we don't have that many config-panels atm :) I'm very curious what you think about this proposed solution. Thanks Jonathan Laurent Julliard wrote: > > This is actually the intended behavior. This is why there is both an > Apply and OK button. Apply allows you to save the changes you've made > in the current panel where as OK is equivalent to Apply and Close the > prefrence dialog box. > > I think what could be done to improve the current system is that if > one tries to witch to a different panel that has changes in it that > have not been "applied" then a dialog box should appear to inform the > user that changes will be lost and whether s/he is ok or not. > > Laurent > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > > From laurent at moldus.org Wed Aug 31 06:16:14 2005 From: laurent at moldus.org (Laurent Julliard) Date: Wed Aug 31 06:09:31 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) In-Reply-To: <43157DC7.3060807@xs4all.nl> References: <431505D8.7010202@xs4all.nl> <43155409.1070301@moldus.org> <43157DC7.3060807@xs4all.nl> Message-ID: <4315836E.9080908@moldus.org> Jonathan Maasland wrote: > So basically that would mean each configurator-panel should provide a > ".modified?" method? That's right. Which would consist of getting the properties from the controls and compare them with those in memory. > Also each control would have to be monitored for changes. The first idea > I have is to just add "modified=true" at all the places where the > controls pick up changes (ie. in blocks or needed methods). > That's another option. but this makes a lot of additional FXRuby code to detect any change in teh form. I havent looked into this but might be a way to capture the fact that the panel was modified by conecting the appropriate event handler at the frame i which all controls are embedded. > Or is there an easier, read more Ruby-ish, way to implement this? It > might be that I'm missing an obvious solution because I'm not all that > awake... > > Luckily we don't have that many config-panels atm :) > > > I'm very curious what you think about this proposed solution. > > Thanks > Jonathan > > Laurent Julliard wrote: > > >>This is actually the intended behavior. This is why there is both an >>Apply and OK button. Apply allows you to save the changes you've made >>in the current panel where as OK is equivalent to Apply and Close the >>prefrence dialog box. >> >>I think what could be done to improve the current system is that if >>one tries to witch to a different panel that has changes in it that >>have not been "applied" then a dialog box should appear to inform the >>user that changes will be lost and whether s/he is ok or not. >> >>Laurent >>_______________________________________________ >>Freeride-devel mailing list >>Freeride-devel@rubyforge.org >>http://rubyforge.org/mailman/listinfo/freeride-devel >> >> > > > _______________________________________________ > Freeride-devel mailing list > Freeride-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/freeride-devel > -- Laurent JULLIARD http://www.moldus.org/~laurent From nochoice at xs4all.nl Wed Aug 31 14:55:07 2005 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Wed Aug 31 12:48:06 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) In-Reply-To: <4315836E.9080908@moldus.org> References: <431505D8.7010202@xs4all.nl> <43155409.1070301@moldus.org> <43157DC7.3060807@xs4all.nl> <4315836E.9080908@moldus.org> Message-ID: <4315FD0B.2060705@xs4all.nl> I tried to connect the SEL_COMMAND event to a single block for every child-component. Only to find out, after some time, that Fox only supports one listener. AAArgh! So that solution isn't going to work unless there is some way to 'peek' at the events being sent. That leaves me with the your first suggested solution. I started implementing this and the first prospects are looking good :) A problem I ran into was in the Colors&Font configuration panel. Changing the color of a style causes the setting to be saved directly, when I cancel the prefs-dialog the color changes are still there. Should I attempt to fix this or is this also intended? It isn't very intuitive.... I hope to be able to produce a patch tomorrow Thanks Jonathan Laurent Julliard wrote: > Jonathan Maasland wrote: > >> So basically that would mean each configurator-panel should provide a >> ".modified?" method? > > > That's right. Which would consist of getting the properties from the > controls and compare them with those in memory. > >> Also each control would have to be monitored for changes. The first idea >> I have is to just add "modified=true" at all the places where the >> controls pick up changes (ie. in blocks or needed methods). >> > > That's another option. but this makes a lot of additional FXRuby code > to detect any change in teh form. I havent looked into this but might > be a way to capture the fact that the panel was modified by conecting > the appropriate event handler at the frame i which all controls are > embedded. > > >> Or is there an easier, read more Ruby-ish, way to implement this? It >> might be that I'm missing an obvious solution because I'm not all that >> awake... >> >> Luckily we don't have that many config-panels atm :) >> >> >> I'm very curious what you think about this proposed solution. >> >> Thanks >> Jonathan >> >> Laurent Julliard wrote: >> >> >>> This is actually the intended behavior. This is why there is both an >>> Apply and OK button. Apply allows you to save the changes you've made >>> in the current panel where as OK is equivalent to Apply and Close the >>> prefrence dialog box. >>> >>> I think what could be done to improve the current system is that if >>> one tries to witch to a different panel that has changes in it that >>> have not been "applied" then a dialog box should appear to inform the >>> user that changes will be lost and whether s/he is ok or not. >>> >>> Laurent >>> _______________________________________________ >>> Freeride-devel mailing list >>> Freeride-devel@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/freeride-devel >>> >>> >> >> >> _______________________________________________ >> Freeride-devel mailing list >> Freeride-devel@rubyforge.org >> http://rubyforge.org/mailman/listinfo/freeride-devel >> > > From laurent at moldus.org Wed Aug 31 16:36:58 2005 From: laurent at moldus.org (Laurent Julliard) Date: Wed Aug 31 16:30:15 2005 Subject: [FR-devel] CloseAll command In-Reply-To: <430E1B38.2000503@xs4all.nl> References: <430B7A5E.20405@xs4all.nl> <430C6876.1030406@xrce.xerox.com> <430D9529.5070507@moldus.org> <430E1B38.2000503@xs4all.nl> Message-ID: <431614EA.2030609@moldus.org> Jonathan Maasland wrote: > That was weird indeed.... I added availability behaviour to the CloseAll > command. > When Exit is invoked it calls project/Close which in turn calls CloseAll. > > The fix is simple but it still took me twenty minutes to figure out. > I attached a completely new patch, the fix I copy-n-pasted below. > > Thanks for spotting this! > > Jonathan > > Your patch has been tested succesfully. I have added the suggested crtl-shift-w accelerator and committed the changes to the CVS repo. Thanks for your contribution! Laurent From laurent at moldus.org Wed Aug 31 16:42:06 2005 From: laurent at moldus.org (Laurent Julliard) Date: Wed Aug 31 16:35:20 2005 Subject: [FR-devel] Configurator renderer (prefs dialog) In-Reply-To: <4315FD0B.2060705@xs4all.nl> References: <431505D8.7010202@xs4all.nl> <43155409.1070301@moldus.org> <43157DC7.3060807@xs4all.nl> <4315836E.9080908@moldus.org> <4315FD0B.2060705@xs4all.nl> Message-ID: <4316161E.9090907@moldus.org> Jonathan Maasland wrote: > I tried to connect the SEL_COMMAND event to a single block for every > child-component. Only to find out, after some time, that Fox only > supports one listener. AAArgh! So that solution isn't going to work > unless there is some way to 'peek' at the events being sent. > Well the lesson I learned is: the less you mess up with UI the better. Plus if one day we run FreeRIDE on another GUI toolkit (like wxWdigets for instance) it is much better if the application logic itsefl doesn't depend on the UI > That leaves me with the your first suggested solution. I started > implementing this and the first prospects are looking good :) > Good! :-) > A problem I ran into was in the Colors&Font configuration panel. > Changing the color of a style causes the setting to be saved directly, > when I cancel the prefs-dialog the color changes are still there. Should > I attempt to fix this or is this also intended? It isn't very intuitive.... > it's definitely a bug. Actually it's only the sample code that has the bug. I thought it was propagated to all the editpanes but it isn't. So yes go fix it if you see how that can be done Laurent -- Laurent JULLIARD http://www.moldus.org/~laurent