Re: [Wtr-general] The Plan for Watir
On 5/10/07, Walter Kruse [EMAIL PROTECTED] wrote: I am very keen to have this done, but leeching isn't nice and I can't write C. If there is forward movement on win32guitest, I volunteer to do a document for it, either a user guide, or something in the style of this: http://www.piotrkaluski.com/files/winguitest/docs/winguitest.html As the Official Cheerleader for GuiTest in Ruby: go for it. I think that there is useful stuff there, but Wayne Vucenic and I both lost interest not long after Wayne wrote the code, and I'm not exactly sure how far he got. Someday I'll get back to it, but not anytime soon. I don't remember that there is a lot of C involved. I think it's mostly negotiating the Win32 interfaces. Let me know if you need any privileged access. I'm pretty sure I'm still set up to make that happen. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Thanks for your detailed replies. Comments inline. Christopher Rasch wrote: Well, ultimately, I want to be able to handle any popup that the browser throws up: attach to it, manipulate it, etc. My understanding is that better modal dialog support is one of the new features of Watir 1.5. See here: http://wiki.openqa.org/display/WTR/Watir+1.5+Summary Right. We added support for handling the IE-specific showModalDialog() in Watir 1.5. As Chris said, there is a terminology problem. Technically, any dialog that blocks access to the main page while it is posted is modal. There are many technologies that allow this. 1. Javascript alert() and confirm() 2. The showModalDialog() mentioned above 3. Various security and authentication dialogs 4. File dialogs such as save as. 5. More recently, there are ajax modal dialogs that appear within the page. Watir 1.5 supports the modal_dialog command which supports #2 above. A good argument could be made that it needs to have a more-specific name. And here: Deliver new DLL that allows us to access DOM embedded in modal web dialogs http://jira.openqa.org/browse/WTR-14 WIN32OLE patch for Modal Web Dialog Support http://jira.openqa.org/browse/WTR-2 Both of these tickets relate to improving the existing modal web dialog support (showModalDialog). At this point, I no longer have plans to work on them and no one else has volunteered to work on them. Probably the biggest problem with our current support for showModalDialog is that it only works with Ruby 1.8.2. Fixing this would require that IEDialog.dll be rewritten as an activex component. Provide cleaner interface and more reliable support for modal windows dialogs (i.e. replace winClicker.rb) http://jira.openqa.org/browse/WTR-4 Although this is desirable and many people have talked about helping with this, we've seen few actual contributions. Personally, i have almost always found ways to avoid these dialogs, so I have never had much motivation to fix this myself. Since integration of the various watirs is also part of the roadmap, I expect that some of the better modal dialog support will also be migrated to the other watir flavors. Perhaps I have the wrong impression? The show_modal_dialog support in watir 1.5 is specific to IE. So no. It would be handy to have a better windows library for handling general windows dialogs, and if we had that, then it would also help for firefox -- you could use it there too, although I know that Angrez is focussing on features that would not be platform specific. All of the mechanisms that we currently using in Watir (autoit, winclicker, win32api) are windows specific, so known of them would be migrated to other platforms. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Christopher Rasch wrote: Both of these tickets relate to improving the existing modal web dialog support (showModalDialog). At this point, I no longer have plans to work on them and no one else has volunteered to work on them. Probably the biggest problem with our current support for showModalDialog is that it only works with Ruby 1.8.2. Fixing this would require that IEDialog.dll be rewritten as an activex component. Doesn't WET already handle modal dialogs pretty well? Yes, i believe it does. What would be involved in integrating WET's functionality into Watir? Some programming and testing. And apparently more than any one is willing to do. Provide cleaner interface and more reliable support for modal windows dialogs (i.e. replace winClicker.rb) http://jira.openqa.org/browse/WTR-4 Although this is desirable and many people have talked about helping with this, we've seen few actual contributions. Personally, i have almost always found ways to avoid these dialogs, so I have never had much motivation to fix this myself. I would like to help, but I don't feel competent enough yet to do any good. I'd imagine that others probably feel the same way. Perhaps it would help attract more help if there were some tutorials on the architecture of watir? First of all, this code has nothing to do with the architecture of watir. It is basically standalone and separate. Your suggestion seems to assume that I am trying to attract more help. Actually, I'm mostly inclined to remove this code from Watir or else move to a separate contrib project. I think the best way to attract support would be be make it clear that this is abandoned code. For the record, i do not have a good understanding of this code. I've never worked on it. And i don't use it. But if you are able to convince somebody to write up a tutorial on how this code works (or doesn't) then that would be great. Just don't look at me. At one point (like when i opened the jira ticket) i thought i might eventually get around to cleaning up this code. I no longer think this is likely. The show_modal_dialog support in watir 1.5 is specific to IE. So no. It would be handy to have a better windows library for handling general windows dialogs, and if we had that, then it would also help for firefox -- you could use it there too, although I know that Angrez is focussing on features that would not be platform specific. All of the mechanisms that we currently using in Watir (autoit, winclicker, win32api) are windows specific, so known of them would be migrated to other platforms. Is there a design document for what such a library should have? No i don't believe so. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Id like the winclicker code to disappear and be replaced by a full windows testing library ( How you getting along with that Chris ? ). Enough people seem to want it. Paul - Original Message - From: Bret Pettichord [EMAIL PROTECTED] Date: Wednesday, May 9, 2007 1:40 pm Subject: Re: [Wtr-general] The Plan for Watir Christopher Rasch wrote: Both of these tickets relate to improving the existing modal web dialog support (showModalDialog). At this point, I no longer have plans to work on them and no one else has volunteered to work on them. Probably the biggest problem with our current support for showModalDialog is that it only works with Ruby 1.8.2. Fixing this would require that IEDialog.dll be rewritten as an activex component. Doesn't WET already handle modal dialogs pretty well? Yes, i believe it does. What would be involved in integrating WET's functionality into Watir? Some programming and testing. And apparently more than any one is willing to do. Provide cleaner interface and more reliable support for modal windows dialogs (i.e. replace winClicker.rb) http://jira.openqa.org/browse/WTR-4 Although this is desirable and many people have talked about helping with this, we've seen few actual contributions. Personally, i have almost always found ways to avoid these dialogs, so I have never had much motivation to fix this myself. I would like to help, but I don't feel competent enough yet to do any good. I'd imagine that others probably feel the same way. Perhaps it would help attract more help if there were some tutorials on the architecture of watir? First of all, this code has nothing to do with the architecture of watir. It is basically standalone and separate. Your suggestion seems to assume that I am trying to attract more help. Actually, I'm mostly inclined to remove this code from Watir or else move to a separate contrib project. I think the best way to attract support would be be make it clear that this is abandoned code. For the record, i do not have a good understanding of this code. I've never worked on it. And i don't use it. But if you are able to convince somebody to write up a tutorial on how this code works (or doesn't) then that would be great. Just don't look at me. At one point (like when i opened the jira ticket) i thought i might eventually get around to cleaning up this code. I no longer think this is likely. The show_modal_dialog support in watir 1.5 is specific to IE. So no. It would be handy to have a better windows library for handling general windows dialogs, and if we had that, then it would also help for firefox -- you could use it there too, although I know that Angrez is focussing on features that would not be platform specific. All of the mechanisms that we currently using in Watir (autoit, winclicker, win32api) are windows specific, so known of them would be migrated to other platforms. Is there a design document for what such a library should have? No i don't believe so. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Paul Rogers wrote: Id like the winclicker code to disappear and be replaced by a full windows testing library ( How you getting along with that Chris ? ). Enough people seem to want it. I think a lot of people would like to see that. I certainly would. But last i looked Chris's project hadn't seen a commit in 18 months. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
On 5/9/07, Bret Pettichord [EMAIL PROTECTED] wrote: Paul Rogers wrote: Id like the winclicker code to disappear and be replaced by a full windows testing library ( How you getting along with that Chris ? ). Enough people seem to want it. I think a lot of people would like to see that. I certainly would. But last i looked Chris's project hadn't seen a commit in 18 months. There might still be enough there to work with. This is a port of Perl Win32::GuiTest, btw. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Christopher Rasch wrote: I'm looking forward to ... better support for modal_dialogs on the supported platforms. Nothing is planned in this area. What were you hoping for? Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Since integration of the various watirs is also part of the roadmap, I expect that some of the better modal dialog support will also be migrated to the other watir flavors. Perhaps I have the wrong impression? I think it's a terminology problem: modal dialog is an artifact of IE only. Javascript popup is common to all browsers. There are special problems with IE modal dialogs that are separate from the problems of addressing javascript popups. -C ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
It seems like we need a seperate 'service' that runs next to watir and deals with any type of pop up Psuedo code: # this line tells the other service to expect a # Modal dialog dialog_clicker :expect = 'Windows Modal' , :click = 'ok' @ie.button(:value , 'Show Modal').click # the service now watches for dialogs and clicks them Im not sure how you would work this into actually accessing modal dialogs, maybe dialog_clicker :expect = 'Windows Modal' , :ignore you could also query it: puts dialog_clicker.last_text Paul - Original Message - From: Chris McMahon [EMAIL PROTECTED] Date: Tuesday, May 8, 2007 3:40 pm Subject: Re: [Wtr-general] The Plan for Watir Since integration of the various watirs is also part of the roadmap, I expect that some of the better modal dialog support will also be migrated to the other watir flavors. Perhaps I have the wrong impression? I think it's a terminology problem: modal dialog is an artifact of IE only. Javascript popup is common to all browsers. There are special problems with IE modal dialogs that are separate from the problems of addressing javascript popups. -C ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] The Plan for Watir
I've been doing a lot of thinking and planning for what we need to do with Watir. I've also been fairly quiet. I now have a new job and have been preoccupied by the change in jobs lately: with wrapping up affairs at my old job at DataCert, with a job search, and then with starting at Dovetail, where they had built up a bit of a backlog of work for me which I've finally dug out from. Dovetail has made a big commitment to Watir: to using it to test our software, to supporting enhancements that we will be using, and even to giving me time to attend to the necessary affairs in running an open-source project. In fact, Dovetail intends to ship our testing framework and our tests themselves to our customers. This means that our tests will need to be good: be easy to understand, extend, run and interpret. I am very excited by the opportunity. Watir 1.5 is getting very close to being done. As soon as it looks like we've fixed all the serious compatability bugs with Watir 1.4, we will be posting the 1.5 gem to Rubyforge. This means that it will become the default gem that will be installed when you do a gem install watir. Originally I wanted to wait until we got the documentation for 1.5 updated, but now now i think that can wait for a later point release (say 1.5.3). Charley tells me that many of the questions on the wtr-general list regard problems that would be solved by moving to 1.5, so it really will help to move there. By the way, Charley has also been rather busy lately, partly because people keep hiring his Watir testers away from him. So if you are one of these people, stop it. It only hurts Watir, in the end, by forcing him to spend all his time on his day job. Jeff Fry is threatening to help out with the Rdoc and Zeljko has agreed to take the lead with updating the users guide. Please cooperate with any requests that they make. Many of you have noticed that FireWatir is looking very good. SafariWatir is also looking good. The number one goal that I have for Watir is pull together these different forks of Watir. In my view they should all be part of one library, or perhaps each will be a plug in to a standard library, much as, say the Ruby DBI library supports plug ins for each of the different types of databases. In our case, we'd have separate plug ins for each browser. This means supporting multiple browsers and making Watir work on multiple platforms. The importance and complexity of this goal is part of what is urging me to wrap up Watir 1.5. We are targeting Watir 2.0 to include plugins for each of the main browsers. I also plan to continue working on a Selenium plugin to Watir. This would allow existing Watir tests to run tests using any browser when connecting to a Selenium-enabled server. This, like all the browsers, will be optional; so if Selenium scares you, you will be able to continue to use Watir the old-fashioned way. In preparation for this, Watir 1.6 will begin the restructuring of the existing code base to support plugins and remove the code duplication that currently exists in the different forks. This will require reorganizing the code files, and therefore we will want to merge all patches before this reorg starts. We will also be taking this occassion to make many changes to Watir that we've been considering for some time, but have put off because of concerns about backwards compatibility. We have attempted to make upgrading from 1.4 to 1.5 extremely easy. Upgrading to 1.6 will be more difficult. In particular, we will be converting Watir to use zero-based indexing in 1.6. Another key element to getting Watir 1.5 out is updating our website. We will be publishing a new, detailed, multi-page website aimed at our general user community. This website will be hosted at wtr.rubyforge.org and will include current information about the various releases and how to install them and where the mailing lists are. And we'll be keeping it up to date, as we move forward with this plan. We will continue to use the wiki at OpenQA for the active user community and there will be several links from the general website into the wiki. We have had a lot trouble keeping the various pages on the OpenQA website updated and accurate and will be replacing them with pointers either to the website or to the wiki. I realize that the current arrangement is very confusing and appreciate your patience. The Jira roadmap more or less lays out the next few steps in our plan. We will be updating it shortly to better match up to the plan I lay out here. If you have bugs you want fixed or features you want added, please make sure there is an open Jira ticket for them. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] The Plan for Watir
Good information. You and Charley and maybe some others should put this in blogs so the wider world can find it. On 5/4/07, Bret Pettichord [EMAIL PROTECTED] wrote: I've been doing a lot of thinking and planning for what we need to do with Watir. I've also been fairly quiet. I now have a new job and have been preoccupied by the change in jobs lately: with wrapping up affairs at my old job at DataCert, with a job search, and then with starting at Dovetail, where they had built up a bit of a backlog of work for me which I've finally dug out from. Dovetail has made a big commitment to Watir: to using it to test our software, to supporting enhancements that we will be using, and even to giving me time to attend to the necessary affairs in running an open-source project. In fact, Dovetail intends to ship our testing framework and our tests themselves to our customers. This means that our tests will need to be good: be easy to understand, extend, run and interpret. I am very excited by the opportunity. Watir 1.5 is getting very close to being done. As soon as it looks like we've fixed all the serious compatability bugs with Watir 1.4, we will be posting the 1.5 gem to Rubyforge. This means that it will become the default gem that will be installed when you do a gem install watir. Originally I wanted to wait until we got the documentation for 1.5 updated, but now now i think that can wait for a later point release (say 1.5.3). Charley tells me that many of the questions on the wtr-general list regard problems that would be solved by moving to 1.5, so it really will help to move there. By the way, Charley has also been rather busy lately, partly because people keep hiring his Watir testers away from him. So if you are one of these people, stop it. It only hurts Watir, in the end, by forcing him to spend all his time on his day job. Jeff Fry is threatening to help out with the Rdoc and Zeljko has agreed to take the lead with updating the users guide. Please cooperate with any requests that they make. Many of you have noticed that FireWatir is looking very good. SafariWatir is also looking good. The number one goal that I have for Watir is pull together these different forks of Watir. In my view they should all be part of one library, or perhaps each will be a plug in to a standard library, much as, say the Ruby DBI library supports plug ins for each of the different types of databases. In our case, we'd have separate plug ins for each browser. This means supporting multiple browsers and making Watir work on multiple platforms. The importance and complexity of this goal is part of what is urging me to wrap up Watir 1.5. We are targeting Watir 2.0 to include plugins for each of the main browsers. I also plan to continue working on a Selenium plugin to Watir. This would allow existing Watir tests to run tests using any browser when connecting to a Selenium-enabled server. This, like all the browsers, will be optional; so if Selenium scares you, you will be able to continue to use Watir the old-fashioned way. In preparation for this, Watir 1.6 will begin the restructuring of the existing code base to support plugins and remove the code duplication that currently exists in the different forks. This will require reorganizing the code files, and therefore we will want to merge all patches before this reorg starts. We will also be taking this occassion to make many changes to Watir that we've been considering for some time, but have put off because of concerns about backwards compatibility. We have attempted to make upgrading from 1.4 to 1.5 extremely easy. Upgrading to 1.6 will be more difficult. In particular, we will be converting Watir to use zero-based indexing in 1.6. Another key element to getting Watir 1.5 out is updating our website. We will be publishing a new, detailed, multi-page website aimed at our general user community. This website will be hosted at wtr.rubyforge.org and will include current information about the various releases and how to install them and where the mailing lists are. And we'll be keeping it up to date, as we move forward with this plan. We will continue to use the wiki at OpenQA for the active user community and there will be several links from the general website into the wiki. We have had a lot trouble keeping the various pages on the OpenQA website updated and accurate and will be replacing them with pointers either to the website or to the wiki. I realize that the current arrangement is very confusing and appreciate your patience. The Jira roadmap more or less lays out the next few steps in our plan. We will be updating it shortly to better match up to the plan I lay out here. If you have bugs you want fixed or features you want added, please make sure there is an open Jira ticket for them. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org
