Comments

• 

  about 7 years ago by shundhammer | Reply

  Implementation Ideas

  The Simplistic Approach: Use a Pop-Up Dialog

  Extend the key event handler in the Qt UI so it catches the special key combination (Ctrl-Shift-Alt-I or whatever), then open a simple Qt pop-up dialog to let the user enter the widget ID and rely on the standard Qt behaviour that [Return] closes that dialog.

  Pro

  • Simple
  • Easy to test
  • It's obvious what's wrong when the process gets stuck during testing - there is still an open pop-up on the screen

  Con

  • The pop-up will easily (and very likely) get in the way of OpenQA's needles (screenshots); OpenQA would have to make sure the pop-up is closed and the screen redrawn to show the original dialog (the dialog under test) so the current screenshot can be compared against the expected "needle".

×
Edit Comment 2688
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
# Implementation Ideas ## The Simplistic Approach: Use a Pop-Up Dialog Extend the key event handler in the Qt UI so it catches the special key combination (Ctrl-Shift-Alt-I or whatever), then open a simple Qt pop-up dialog to let the user enter the widget ID and rely on the standard Qt behaviour that [Return] closes that dialog. ### Pro - Simple - Easy to test - It's obvious what's wrong when the process gets stuck during testing - there is still an open pop-up on the screen ### Con - The pop-up will easily (and very likely) get in the way of OpenQA's needles (screenshots); OpenQA would have to make sure the pop-up is closed and the screen redrawn to show the original dialog (the dialog under test) so the current screenshot can be compared against the expected "needle".
 
×
Reply to shundhammer
Implementation Ideas
The Simplistic Approach: Use a Pop-Up Dialog
Extend the key event handler in the Qt UI so it catches the special key combination (Ctrl-Shift-Alt-I or whatever), then open a simple Qt pop-up dialog to let the user enter the widget ID and rely on the standard Qt behaviour that [Return] closes that dialog.
Pro
• Simple
• Easy to test
• It's obvious what's wrong when the process gets stuck during testing - there is still an open pop-up on the screen
Con
• The pop-up will easily (and very likely) get in the way of OpenQA's needles (screenshots); OpenQA would have to make sure the pop-up is closed and the screen redrawn to show the original dialog (the dialog under test) so the current screenshot can be compared against the expected "needle".
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  The Behind-the-Scenes Approach: Send Widget IDs via a Named Pipe (or Socket)

  This would create a named pipe in, say, /tmp/YaST/widget-ids where the test application (OpenQA) would write the widget ID, and the YaST UI would read from that named pipe in parallel to keyboard and mouse input (Qt does provide this with the QSocketNotifier class).

  Pro

  • No pop-up dialog that might get in the way; the screen (the dialog under test) remains unchanged.

  Con

  • Synchronisation with keyboard input will become a problem; if the test application fills the keyboard buffer very quickly with some widget IDs sent to that named pipe in between. When should the widget IDs be used? There will be race conditions for sure.
  • Security implications: We have to make sure that this named pipe does not open a security hole. It must be writable by root only, and YaST has to check for that and not use it if it is not. Also, it needs to be in a separate directory below /tmp/ because of the sticky bit, and that subdirectory also needs to be accessible only by root. Remember to double-check with the security team.

  TO DO

  • Figure out who creates the directory and the named pipe and when
  • Find a strategy what should happen if there are multiple instances of YaST running; maybe also put a YaST-pid file there and check if that process is still alive? (send a signal #0 to that process)
  • Clean up after YaST / the test ends

×
Edit Comment 2690
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## The Behind-the-Scenes Approach: Send Widget IDs via a Named Pipe (or Socket) This would create a named pipe in, say, `/tmp/YaST/widget-ids` where the test application (OpenQA) would write the widget ID, and the YaST UI would read from that named pipe in parallel to keyboard and mouse input (Qt does provide this with the `QSocketNotifier` class). ## Pro - No pop-up dialog that might get in the way; the screen (the dialog under test) remains unchanged. ## Con - Synchronisation with keyboard input will become a problem; if the test application fills the keyboard buffer very quickly with some widget IDs sent to that named pipe in between. When should the widget IDs be used? There will be race conditions for sure. - Security implications: We have to make sure that this named pipe does not open a security hole. It must be writable by root only, and YaST has to check for that and not use it if it is not. Also, it needs to be in a separate directory below `/tmp/` because of the sticky bit, and that subdirectory also needs to be accessible only by root. Remember to double-check with the security team. ### TO DO - Figure out who creates the directory and the named pipe and when - Find a strategy what should happen if there are multiple instances of YaST running; maybe also put a YaST-pid file there and check if that process is still alive? (send a signal #0 to that process) - Clean up after YaST / the test ends
 
×
Reply to shundhammer
The Behind-the-Scenes Approach: Send Widget IDs via a Named Pipe (or Socket)
This would create a named pipe in, say, /tmp/YaST/widget-ids where the test application (OpenQA) would write the widget ID, and the YaST UI would read from that named pipe in parallel to keyboard and mouse input (Qt does provide this with the QSocketNotifier class).
Pro
• No pop-up dialog that might get in the way; the screen (the dialog under test) remains unchanged.
Con
• Synchronisation with keyboard input will become a problem; if the test application fills the keyboard buffer very quickly with some widget IDs sent to that named pipe in between. When should the widget IDs be used? There will be race conditions for sure.
• Security implications: We have to make sure that this named pipe does not open a security hole. It must be writable by root only, and YaST has to check for that and not use it if it is not. Also, it needs to be in a separate directory below /tmp/ because of the sticky bit, and that subdirectory also needs to be accessible only by root. Remember to double-check with the security team.
TO DO
• Figure out who creates the directory and the named pipe and when
• Find a strategy what should happen if there are multiple instances of YaST running; maybe also put a YaST-pid file there and check if that process is still alive? (send a signal #0 to that process)
• Clean up after YaST / the test ends
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  The Combined Approach: Key Combo and a Named Pipe

  Use the keyboard to tell YaST to read one widget ID from a named pipe: Ctrl-Shift-Alt-I, then write the widget ID to the named pipe followed by a newline.

  Pro

  • Also no pop-up dialog that might get in the way
  • No synchronization problems with keyboard buffer vs. named pipe

  Con

  • More complicated
  • Need clear logging (y2log) to make it possible to debug situations where a test gets stuck somewhere in between: log something like "received Ctrl-Shift-Alt-I; reading /tmp/YaST/ids", and when finished "Read widget ID 'next' from /tmp/YaST/ids".
  • Same security implications as with the named pipe approach

  TO DO

  Same as with the named pipe approach

×
Edit Comment 2692
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## The Combined Approach: Key Combo and a Named Pipe Use the keyboard to tell YaST to read one widget ID from a named pipe: Ctrl-Shift-Alt-I, then write the widget ID to the named pipe followed by a newline. ### Pro - Also no pop-up dialog that might get in the way - No synchronization problems with keyboard buffer vs. named pipe ### Con - More complicated - Need clear logging (y2log) to make it possible to debug situations where a test gets stuck somewhere in between: log something like "received Ctrl-Shift-Alt-I; reading /tmp/YaST/ids", and when finished "Read widget ID 'next' from /tmp/YaST/ids". - Same security implications as with the named pipe approach ### TO DO Same as with the named pipe approach
 
×
Reply to shundhammer
The Combined Approach: Key Combo and a Named Pipe
Use the keyboard to tell YaST to read one widget ID from a named pipe: Ctrl-Shift-Alt-I, then write the widget ID to the named pipe followed by a newline.
Pro
• Also no pop-up dialog that might get in the way
• No synchronization problems with keyboard buffer vs. named pipe
Con
• More complicated
• Need clear logging (y2log) to make it possible to debug situations where a test gets stuck somewhere in between: log something like "received Ctrl-Shift-Alt-I; reading /tmp/YaST/ids", and when finished "Read widget ID 'next' from /tmp/YaST/ids".
• Same security implications as with the named pipe approach
TO DO
Same as with the named pipe approach
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  Needed Tools in the Ecosystem

  • The YDialogSpy needs to be extended to always show a widget's ID, preferably as the first item under its properties (even though it's not strictly speaking a property).
  • Maybe add another special key combination that pops up a dialog showing only the widgets with IDs (i.e. not the complete widget tree, not all the layouts and spacings and alignment widgets) along with their "debug labels"

×
Edit Comment 2694
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
# Needed Tools in the Ecosystem - The YDialogSpy needs to be extended to always show a widget's ID, preferably as the first item under its properties (even though it's not strictly speaking a property). - Maybe add another special key combination that pops up a dialog showing only the widgets with IDs (i.e. not the complete widget tree, not all the layouts and spacings and alignment widgets) along with their "debug labels"
 
×
Reply to shundhammer
Needed Tools in the Ecosystem
• The YDialogSpy needs to be extended to always show a widget's ID, preferably as the first item under its properties (even though it's not strictly speaking a property).
• Maybe add another special key combination that pops up a dialog showing only the widgets with IDs (i.e. not the complete widget tree, not all the layouts and spacings and alignment widgets) along with their "debug labels"
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by lslezak | Reply

  Interesting idea, but it solves only half of the usual openQA issue. One problem is sending the input, the other problem is checking the output (the UI state). I have proposed another solution (REST API) here. It additionally solves the other problem.

  Moreover I already have a working proof of concept with HTTP + JSON (read-only so far, just dumps the current dialog in JSON response).

×
Edit Comment 2706
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Interesting idea, but it solves only half of the usual openQA issue. One problem is sending the input, the other problem is checking the output (the UI state). I have proposed another solution (REST API) [here](https://hackweek.suse.com/16/projects/controlling-and-testing-the-yast-ui-remotely-for-integration-tests-openqa). It additionally solves the other problem. Moreover I already have a working proof of concept with HTTP + JSON (read-only so far, just dumps the current dialog in JSON response).
 
×
Reply to lslezak
Interesting idea, but it solves only half of the usual openQA issue. One problem is sending the input, the other problem is checking the output (the UI state). I have proposed another solution (REST API) here. It additionally solves the other problem.
Moreover I already have a working proof of concept with HTTP + JSON (read-only so far, just dumps the current dialog in JSON response).
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  @lslezak: I discussed several approaches with people from our QA team in the past, and they seem to be very reluctant to use things that they consider too intrusive; very much like "don't fratzernize with the enemy" (the application under test). I can understand those reservations, yet I also see the benefits of checking widget content on the logical level rather than just comparing pixels in screenshots. Both have their pros and cons.

  The approach in this project might be considerably easier for them to accept since it's not that far away from what they already do: Send key events and then compare screenshots. Only this time it's no longer just plain and dumb key events, they come with some semantics: The widget ID, not just a keyboard shortcut that can (and does) change for lots of reasons.

  IMHO we can easily and we should do both: Giving QA the feature to send widget IDs and keep using their current way of testing with screenshots, and in parallel offer deeper introspection with checking actual internal widget state. Both have their merits, depending on what exactly a test wants to achieve.

×
Edit Comment 2720
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
[@lslezak](/users/lslezak): I discussed several approaches with people from our QA team in the past, and they seem to be very reluctant to use things that they consider too intrusive; very much like "don't fratzernize with the enemy" (the application under test). I can understand those reservations, yet I also see the benefits of checking widget content on the logical level rather than just comparing pixels in screenshots. Both have their pros and cons. The approach in this project might be considerably easier for them to accept since it's not that far away from what they already do: Send key events and then compare screenshots. Only this time it's no longer just plain and dumb key events, they come with some semantics: The widget ID, not just a keyboard shortcut that can (and does) change for lots of reasons. IMHO we can easily and we should do both: Giving QA the feature to send widget IDs and keep using their current way of testing with screenshots, and in parallel offer deeper introspection with checking actual internal widget state. Both have their merits, depending on what exactly a test wants to achieve.
 
×
Reply to shundhammer
@lslezak: I discussed several approaches with people from our QA team in the past, and they seem to be very reluctant to use things that they consider too intrusive; very much like "don't fratzernize with the enemy" (the application under test). I can understand those reservations, yet I also see the benefits of checking widget content on the logical level rather than just comparing pixels in screenshots. Both have their pros and cons.
The approach in this project might be considerably easier for them to accept since it's not that far away from what they already do: Send key events and then compare screenshots. Only this time it's no longer just plain and dumb key events, they come with some semantics: The widget ID, not just a keyboard shortcut that can (and does) change for lots of reasons.
IMHO we can easily and we should do both: Giving QA the feature to send widget IDs and keep using their current way of testing with screenshots, and in parallel offer deeper introspection with checking actual internal widget state. Both have their merits, depending on what exactly a test wants to achieve.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  Seel also the reladed project here.

×
Edit Comment 2722
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Seel also the reladed project [here](https://hackweek.suse.com/16/projects/controlling-and-testing-the-yast-ui-remotely-for-integration-tests-openqa).
 
×
Reply to shundhammer
Seel also the reladed project here.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by lslezak | Reply

  I see, this project is simpler so it might be easier to accept and integrate it into the current openQA. We can implement both and see how it evolves later...

×
Edit Comment 2724
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
I see, this project is simpler so it might be easier to accept and integrate it into the current openQA. We can implement both and see how it evolves later...
 
×
Reply to lslezak
I see, this project is simpler so it might be easier to accept and integrate it into the current openQA. We can implement both and see how it evolves later...
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by okurz | Reply

  I think a special keyboard shortcut + widget id is a nice approach for a potentially problematic button so I am looking forward to the results of this hackweek project. I doubt we want to use it in all occasions though as it will be slower (more keypresses to send) and less obvious but it could be more robust of course.

  Regarding "don't fratzernize with the enemy" I would rather phrase it differently: Test as the user does. What we do with openQA is using exactly the interface that the user has available and will most likely use. That is for example shortcuts where it makes sense, e.g. I assume everybody can agree that "alt-n" for the next button is something that should be expected to work. In other cases we can click on buttons identified by "needle matching" where multiple needles can be created and it's easier to maintain then changing screenshots by versions/products/distributions. We can also do send_key_until_needlematch, e.g. "press tab until you reach ", where "" is also identified by needles. Pressing a shortcut is just the fastest way because it is just one specific key press rather than comparing screen and then clicking or hitting keys multiple times until the right button is reached. I think all examples where we had this problem of changing hotkeys so far were mainly because of the following problems: Test writers do not know that YaST has this (awesome) hotkey conflict resolver. So we just need shundhammer to help us understand how it's working and he is doing a great job in doing so already :)

×
Edit Comment 2742
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
I think a special keyboard shortcut + widget id is a nice approach for a potentially problematic button so I am looking forward to the results of this hackweek project. I doubt we want to use it in all occasions though as it will be slower (more keypresses to send) and less obvious but it could be more robust of course. Regarding "don't fratzernize with the enemy" I would rather phrase it differently: Test as the user does. What we do with openQA is using exactly the interface that the user has available and will most likely use. That is for example shortcuts where it makes sense, e.g. I assume everybody can agree that "alt-n" for the next button is something that should be expected to work. In other cases we can click on buttons identified by "needle matching" where multiple needles can be created and it's easier to maintain then changing screenshots by versions/products/distributions. We can also do `send_key_until_needlematch`, e.g. "press tab until you reach <button>", where "<button>" is also identified by needles. Pressing a shortcut is just the fastest way because it is just one specific key press rather than comparing screen and then clicking or hitting keys multiple times until the right button is reached. I think all examples where we had this problem of changing hotkeys so far were mainly because of the following problems: Test writers do not know that YaST has this (awesome) hotkey conflict resolver. So we just need shundhammer to help us understand how it's working and he is doing a great job in doing so already :)
 
×
Reply to okurz
I think a special keyboard shortcut + widget id is a nice approach for a potentially problematic button so I am looking forward to the results of this hackweek project. I doubt we want to use it in all occasions though as it will be slower (more keypresses to send) and less obvious but it could be more robust of course.
Regarding "don't fratzernize with the enemy" I would rather phrase it differently: Test as the user does. What we do with openQA is using exactly the interface that the user has available and will most likely use. That is for example shortcuts where it makes sense, e.g. I assume everybody can agree that "alt-n" for the next button is something that should be expected to work. In other cases we can click on buttons identified by "needle matching" where multiple needles can be created and it's easier to maintain then changing screenshots by versions/products/distributions. We can also do send_key_until_needlematch, e.g. "press tab until you reach ", where "" is also identified by needles. Pressing a shortcut is just the fastest way because it is just one specific key press rather than comparing screen and then clicking or hitting keys multiple times until the right button is reached. I think all examples where we had this problem of changing hotkeys so far were mainly because of the following problems: Test writers do not know that YaST has this (awesome) hotkey conflict resolver. So we just need shundhammer to help us understand how it's working and he is doing a great job in doing so already :)
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by coolo | Reply

  I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation.

  What can work is a special spy for special cases - to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.

×
Edit Comment 2834
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation. What can work is a special spy for special cases - <hotkey> to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.
 
×
Reply to coolo
I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation.
What can work is a special spy for special cases - to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by coolo | Reply

  I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation.

  What can work is a special spy for special cases - to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.

  • 

    about 7 years ago by shundhammer | Reply

    Coolo, good point; I hadn't thought about that.

    That would leaves us with an alternative approach I had considered, but I wanted to keep it simple: Use a socket. For testing, nc (netcat) would do just nicely to feed it.

  ×
  Edit Comment 2896
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
  Coolo, good point; I hadn't thought about that. That would leaves us with an alternative approach I had considered, but I wanted to keep it simple: Use a socket. For testing, `nc` (netcat) would do just nicely to feed it.
   
  ×
  Reply to shundhammer
  Coolo, good point; I hadn't thought about that.
  That would leaves us with an alternative approach I had considered, but I wanted to keep it simple: Use a socket. For testing, nc (netcat) would do just nicely to feed it.
  ---
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
   
×
Edit Comment 2836
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation. What can work is a special spy for special cases - <hotkey> to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.
 
×
Reply to coolo
I don't see how a named pipe could work at all - openQA does not run in the SUT. openQA accesses the system remotely - through VNC or doing a ssh installation.
What can work is a special spy for special cases - to create the popup, enter something (I think QA engineers would prefer the label text instead of the widget ID) and then popup closes and action is triggered. This wouldn't interfere with screen matching at all.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  Since I had intended to try the popup solution first anyway as a very simple proof of concept, this would be one version, maybe even one to stay as an alternative to a socket connection. Both would feed the same internal queue anyway.

  As for widget labels: This is also very fragile; they might change due to proofreading or changed product manager preferences about wording, so widget IDs are definitely the prefered way. But as outlined here, we need some better tools to get the widget IDs; one is always displaying them in the YDialogSpy. A popup-based solution might use a combo box to provide some suggestions which should be obvious enough, maybe even with part of the widget label or whatever; we'll need to play with that to get an impression what it feels like.

×
Edit Comment 2898
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Since I had intended to try the popup solution first anyway as a very simple proof of concept, this would be one version, maybe even one to stay as an alternative to a socket connection. Both would feed the same internal queue anyway. As for widget labels: This is also very fragile; they might change due to proofreading or changed product manager preferences about wording, so widget IDs are definitely the prefered way. But as outlined here, we need some better tools to get the widget IDs; one is always displaying them in the YDialogSpy. A popup-based solution might use a combo box to provide some suggestions which should be obvious enough, maybe even with part of the widget label or whatever; we'll need to play with that to get an impression what it feels like.
 
×
Reply to shundhammer
Since I had intended to try the popup solution first anyway as a very simple proof of concept, this would be one version, maybe even one to stay as an alternative to a socket connection. Both would feed the same internal queue anyway.
As for widget labels: This is also very fragile; they might change due to proofreading or changed product manager preferences about wording, so widget IDs are definitely the prefered way. But as outlined here, we need some better tools to get the widget IDs; one is always displaying them in the YDialogSpy. A popup-based solution might use a combo box to provide some suggestions which should be obvious enough, maybe even with part of the widget label or whatever; we'll need to play with that to get an impression what it feels like.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  Result

  Implemented the popup-based version for both the Qt and the NCurses UI. So far, this seems to work well.

×
Edit Comment 2952
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
# Result Implemented the popup-based version for both the Qt and the NCurses UI. So far, this seems to work well.
 
×
Reply to shundhammer
Result
Implemented the popup-based version for both the Qt and the NCurses UI. So far, this seems to work well.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by riafarov | Reply

  Conclusion and future steps

  Defined goal was reached, pop-up approached was implemented and integrated with openqa to prove the concept. Here is link to the branch with changes: os-autoinst-distri-opensuse During the project I've learned more about yast gui internals. This functionality can be used in the tests with constantly changing keyboard hotkeys in first place.

  After seeing this possibility to have more stable tests using yast gui internals, we can use advantage of it and stop relying on needles and keyboard shortcuts. After that I was introduced to YCP functionality which is there for a long time and already has a recorder and a player. Documentation for the Yast Programming language can be found here. This functionality can be used for testing and already contains the functionality to read widget properties and set them, as well as interact with them simulating user input.

  YCP macro can be executed when application is started by simply calling: /usr/lib/YaST2/bin/y2base ./HelloWorld.rb qt --macro macro.ycp Or, it can be also called during the run using ctrl-alt-shift-p key combination and then selecting ycp file.

  This part makes it possible to operate on lower level and hence make automated tests more stable and scalable.

  Pros

  • Usage of widget IDs allows to write tests which are resistant to fonts and layout changes
  • Usage of YCP allows to avoid syncronization issues (when some control is not yet shown, but we try to act on it)
  • YCP allows to avoid send keys problems we experience in openQA
  • Reduced execution time as we are able to set controls property to certain value instead of typing
  • Macro recorder allows to partly reduce test code development
  • Tests developed in this way can be easily executed by developers and significantly reduce feedback cycle
  • Can be combined with needle matching approach
  • Easy migration to the solution (e.g. only newly or unstable developed tests are developed using YCP)

  Cons

  • Learning curve for test developers
  • Missing functionality and requires further development (e.g. not possible to verify values in the table or select row with certain cell)
  • Unstable behavior if used with installer (unfortunately due to some bugs installer may crash during macro execution, some trivial actions like pressing button may not work if change installers page, etc.)
  • Missing openQA integration (even though it's easy to run such a test, and log errors in y2log file, the results won't be parsed and displayed in friendly way on the dashboard)
  • Works only with Yast GUI, so usage scope is limited

  All the disadvantages are mainly caused by the fact that YCP is not widely used, but that can be solved with reasonable time investment. In order to prove benefits of the solution we could implement one of unstable tests using YCP and run them in parallel to calculate time spent on maintenance of both solutions.

×
Edit Comment 2968
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## Conclusion and future steps Defined goal was reached, pop-up approached was implemented and integrated with openqa to prove the concept. Here is link to the branch with changes: [os-autoinst-distri-opensuse](https://github.com/rwx788/os-autoinst-distri-opensuse/tree/hackweek17_widget-ids) During the project I've learned more about yast gui internals. This functionality can be used in the tests with constantly changing keyboard hotkeys in first place. After seeing this possibility to have more stable tests using yast gui internals, we can use advantage of it and stop relying on needles and keyboard shortcuts. After that I was introduced to YCP functionality which is there for a long time and already has a recorder and a player. Documentation for the Yast Programming language can be found [here](https://doc.opensuse.org/projects/YaST/openSUSE11.3/tdg/Book-YCPLanguage.html). This functionality can be used for testing and already contains the functionality to read widget properties and set them, as well as interact with them simulating user input. YCP macro can be executed when application is started by simply calling: ``` /usr/lib/YaST2/bin/y2base ./HelloWorld.rb qt --macro macro.ycp ``` Or, it can be also called during the run using ctrl-alt-shift-p key combination and then selecting ycp file. This part makes it possible to operate on lower level and hence make automated tests more stable and scalable. ###Pros * Usage of widget IDs allows to write tests which are resistant to fonts and layout changes * Usage of YCP allows to avoid syncronization issues (when some control is not yet shown, but we try to act on it) * YCP allows to avoid send keys problems we experience in openQA * Reduced execution time as we are able to set controls property to certain value instead of typing * Macro recorder allows to partly reduce test code development * Tests developed in this way can be easily executed by developers and significantly reduce feedback cycle * Can be combined with needle matching approach * Easy migration to the solution (e.g. only newly or unstable developed tests are developed using YCP) ###Cons * Learning curve for test developers * Missing functionality and requires further development (e.g. not possible to verify values in the table or select row with certain cell) * Unstable behavior if used with installer (unfortunately due to some bugs installer may crash during macro execution, some trivial actions like pressing button may not work if change installers page, etc.) * Missing openQA integration (even though it's easy to run such a test, and log errors in y2log file, the results won't be parsed and displayed in friendly way on the dashboard) * Works only with Yast GUI, so usage scope is limited All the disadvantages are mainly caused by the fact that YCP is not widely used, but that can be solved with reasonable time investment. In order to prove benefits of the solution we could implement one of unstable tests using YCP and run them in parallel to calculate time spent on maintenance of both solutions.
 
×
Reply to riafarov
Conclusion and future steps
Defined goal was reached, pop-up approached was implemented and integrated with openqa to prove the concept. Here is link to the branch with changes: os-autoinst-distri-opensuse During the project I've learned more about yast gui internals. This functionality can be used in the tests with constantly changing keyboard hotkeys in first place.
After seeing this possibility to have more stable tests using yast gui internals, we can use advantage of it and stop relying on needles and keyboard shortcuts. After that I was introduced to YCP functionality which is there for a long time and already has a recorder and a player. Documentation for the Yast Programming language can be found here. This functionality can be used for testing and already contains the functionality to read widget properties and set them, as well as interact with them simulating user input.
YCP macro can be executed when application is started by simply calling: /usr/lib/YaST2/bin/y2base ./HelloWorld.rb qt --macro macro.ycp Or, it can be also called during the run using ctrl-alt-shift-p key combination and then selecting ycp file.
This part makes it possible to operate on lower level and hence make automated tests more stable and scalable.
Pros
• Usage of widget IDs allows to write tests which are resistant to fonts and layout changes
• Usage of YCP allows to avoid syncronization issues (when some control is not yet shown, but we try to act on it)
• YCP allows to avoid send keys problems we experience in openQA
• Reduced execution time as we are able to set controls property to certain value instead of typing
• Macro recorder allows to partly reduce test code development
• Tests developed in this way can be easily executed by developers and significantly reduce feedback cycle
• Can be combined with needle matching approach
• Easy migration to the solution (e.g. only newly or unstable developed tests are developed using YCP)
Cons
• Learning curve for test developers
• Missing functionality and requires further development (e.g. not possible to verify values in the table or select row with certain cell)
• Unstable behavior if used with installer (unfortunately due to some bugs installer may crash during macro execution, some trivial actions like pressing button may not work if change installers page, etc.)
• Missing openQA integration (even though it's easy to run such a test, and log errors in y2log file, the results won't be parsed and displayed in friendly way on the dashboard)
• Works only with Yast GUI, so usage scope is limited
All the disadvantages are mainly caused by the fact that YCP is not widely used, but that can be solved with reasonable time investment. In order to prove benefits of the solution we could implement one of unstable tests using YCP and run them in parallel to calculate time spent on maintenance of both solutions.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  about 7 years ago by shundhammer | Reply

  Packages

  Popup-based solution implemented when pressing Shift-F6 in these packages:

  • libyui-3.4.0
  • libyui-qt-2.48.0
  • libyui-ncurses-2.49.0

×
Edit Comment 3056
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## Packages Popup-based solution implemented when pressing Shift-F6 in these packages: - libyui-3.4.0 - libyui-qt-2.48.0 - libyui-ncurses-2.49.0
 
×
Reply to shundhammer
Packages
Popup-based solution implemented when pressing Shift-F6 in these packages:
• libyui-3.4.0
• libyui-qt-2.48.0
• libyui-ncurses-2.49.0
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview