wx.lib conversion status for Phoenix

Hi,

the other day I was curious how far this is and also wanted to see which ones to 'attack' next, so I generated a list list which is attached.

As you can see quit a lot of work has been done but there is still much to do before wx.lib is fully converted to Phoenix.

A lot of the work is really quit easy/simple, even I can do it;-) , so if a few jump in and help on this it shouldn't take that long.

I think the easiest for Robin is for us to generate PR's on:
https://github.com/RobinD42/Phoenix/pulls

Werner

checkwxlibstatus.pdf (31.7 KB)

Thats nice little pdf table but will become outdated as WIPz continues.
Would you mind uploading the script that generates the pdf.
Looks like you are just parsing the beginning of file tags.
So making one on the fly from the snapshot would a plus, as a quick look at the PR list would tell what is still WIPz.

···

On Monday, May 26, 2014 5:04:22 AM UTC-6, werner wrote:

Hi,

the other day I was curious how far this is and also wanted to see which
ones to ‘attack’ next, so I generated a list list which is attached.

As you can see quit a lot of work has been done but there is still much
to do before wx.lib is fully converted to Phoenix.

A lot of the work is really quit easy/simple, even I can do it;-) , so
if a few jump in and help on this it shouldn’t take that long.

I think the easiest for Robin is for us to generate PR’s on:

https://github.com/RobinD42/Phoenix/pulls

Werner

I’ll just attach it here, not sure it is worse while to add to
source tree.
I then take the generated csv and open it with LibreOffice calc to
generate the .PDF.
Werner

checkwxlibstatus.py (1.63 KB)

···

Hi,

  On 6/8/2014 23:58, Metallicow wrote:
    On Monday, May 26, 2014 5:04:22 AM UTC-6, werner wrote:
      Hi,




      the other day I was curious how far this is and also wanted to

see which

      ones to 'attack' next, so I generated a list list which is

attached.

      As you can see quit a lot of work has been done but there is

still much

      to do before wx.lib is fully converted to Phoenix.




      A lot of the work is really quit easy/simple, even I can do

it;-) , so

      if a few jump in and help on this it shouldn't take that long.




      I think the easiest for Robin is for us to generate PR's on:


      [https://github.com/RobinD42/Phoenix/pulls](https://github.com/RobinD42/Phoenix/pulls)




      Werner
      Thats nice little pdf table but will become outdated as WIPz

continues.

      Would you mind uploading the script that generates the pdf.

      Looks like you are just parsing the beginning of file tags.

      So making one on the fly from the snapshot would a plus, as a

quick look at the PR list would tell what is still WIPz.

Simple enough. looks like just drop it into the snapshot head.
Well, the LibreOffice part could probably be automated too. might look into the command line switches. I think libre uses python also for scripting. probably wouldn’t be to much work.

or look around for a text to pdf generator to tack on to the end of the script maybe.

Looks like it flagged a few things wrong tho. Ex: FlatMenu is a hard crasher upon opening a menu atm, so that actually would be wrong even tho it passes a unittest, etc.
But besides thos instances, It looks fairly well squared up

···

On Monday, June 9, 2014 8:34:18 AM UTC-6, werner wrote:

  I'll just attach it here, not sure it is worse while to add to

source tree.

I then take the generated csv and open it with LibreOffice calc to

generate the .PDF.

Werner

...

Looks like it flagged a few things wrong tho. Ex: FlatMenu is a hard crasher upon opening a menu atm, so that actually would be wrong even tho it passes a unittest, etc.

Yeap, but there is no test for opening a menu.

Any idea how I could show a menu in the unittest to force that error.

Werner

···

On 6/10/2014 15:02, Metallicow wrote:

Hi Werner,

...

Looks like it flagged a few things wrong tho. Ex: FlatMenu is a hard crasher upon opening a menu atm, so that actually would be wrong even tho it passes a unittest, etc.

Yeap, but there is no test for opening a menu.

Any idea how I could show a menu in the unittest to force that error.

You may be able to use wx.UIActionSimulator to simulate the sequence of mouse (and/or keyboard) events the user would perform to click on the menu. For example, programmatically get the menu's position on screen, simulate a mouse movement to that position (+ perhaps a couple pixels to make sure we're inside the control) and then simulate a mouse click.

Thanks,

Kevin

···

On Jun 10, 2014, at 6:35 AM, Werner <wernerfbd@gmx.ch> wrote:

On 6/10/2014 15:02, Metallicow wrote:

Werner

--
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Werner,

Looks like it flagged a few things wrong tho. Ex: FlatMenu is a hard crasher upon opening a menu atm, so that actually would be wrong even tho it passes a unittest, etc.

Yeap, but there is no test for opening a menu.

Any idea how I could show a menu in the unittest to force that error.

You may be able to use wx.UIActionSimulator to simulate the sequence of mouse (and/or keyboard) events the user would perform to click on the menu. For example, programmatically get the menu’s position on screen, simulate a mouse movement to that position (+ perhaps a couple pixels to make sure we’re inside the control) and then simulate a mouse click.

Thanks,

Kevin

Werner


You received this message because you are subscribed to the Google Groups “wxPython-dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

While that should work… The MenuBar/Menus often are different than when trying toacces other stuff.
Ex:

gMenuBar.Position
wx.Point(59922485, 26571305)
Nope. That is wild also.

I think the thing to do would be get the gMainWin.Position, the add up the system metrics for the topborder/titlebars/etc, then add a couple pixels.
Themes will be different on different os’s so I would tend to think something along these lines would work better as the sizes will change…
Just figure out which all values to add up and you should be right on top of the menu with UISimulator, assuming all menubars attach to the top of the frame in all os’s.

···

On Tuesday, June 10, 2014 9:38:19 AM UTC-6, Kevin Ollivier wrote:

On Jun 10, 2014, at 6:35 AM, Werner wern...@gmx.ch wrote:

On 6/10/2014 15:02, Metallicow wrote:

Hi Metallicow and Kevin,

Thanks for the suggestion, will give that a try. In the mean time I managed to use the flatmenu.Popup method which shows the same crash as selection a menu from the menu bar, an I updated the unittest with that.

Werner

···

On 6/11/2014 7:39, Metallicow wrote:

On Tuesday, June 10, 2014 9:38:19 AM UTC-6, Kevin Ollivier wrote:

    Hi Werner,

    On Jun 10, 2014, at 6:35 AM, Werner <wern...@gmx.ch <javascript:>> > wrote:

    > On 6/10/2014 15:02, Metallicow wrote:
    > ...
    >>
    >> Looks like it flagged a few things wrong tho. Ex: FlatMenu is a
    hard crasher upon opening a menu atm, so that actually would be
    wrong even tho it passes a unittest, etc.
    > Yeap, but there is no test for opening a menu.
    >
    > Any idea how I could show a menu in the unittest to force that
    error.

    You may be able to use wx.UIActionSimulator to simulate the
    sequence of mouse (and/or keyboard) events the user would perform
    to click on the menu. For example, programmatically get the menu's
    position on screen, simulate a mouse movement to that position (+
    perhaps a couple pixels to make sure we're inside the control) and
    then simulate a mouse click.

    Thanks,

    Kevin

    > Werner
    >
    > --
    > You received this message because you are subscribed to the
    Google Groups "wxPython-dev" group.
    > To unsubscribe from this group and stop receiving emails from
    it, send an email to wxPython-dev...@googlegroups.com <javascript:>.
    > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout&gt;\.

While that should work... The MenuBar/Menus often are different than when trying toacces other stuff.
Ex:
>>> gMenuBar.Position
wx.Point(59922485, 26571305)
Nope. That is wild also.

I think the thing to do would be get the gMainWin.Position, the add up the system metrics for the topborder/titlebars/etc, then add a couple pixels.
Themes will be different on different os's so I would tend to think something along these lines would work better as the sizes will change...
Just figure out which all values to add up and you should be right on top of the menu with UISimulator, assuming all menubars attach to the top of the frame in all os's.

--
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev+unsubscribe@googlegroups.com <mailto:wxPython-dev+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

Hi,

trying to use UIActionSimulater.

Came up with following test:

     def test_lib_agw_flatmenuSelectMenu(self):
         self._mb = FM.FlatMenuBar(self.frame)

         subMenu = FM.FlatMenu()
         menuItem = FM.FlatMenuItem(subMenu, 20001, "First Menu Item", "", wx.ITEM_CHECK)
         subMenu.AppendItem(menuItem)

         self._mb.Append(subMenu, "File")

         self._mb.Refresh()

         subMenuPos = subMenu.GetPosition()
         subMenuPosScreen = self.frame.ClientToScreen(subMenuPos + (2, 2))
         uisim = wx.UIActionSimulator()
         uisim.MouseMove(subMenuPosScreen)
         uisim.MouseClick()

It passes but I think that is due to the test 'self.frame' not yet having layed out correctly when the test is running. I see this if I run the test in WingIDE 'debug test' and stop e.g. on the MouseClick line.

Hopefully Robin can give me some pointer on how to ensure that the layout is done.

Werner

When going to link

https://github.com/RobinD42/Phoenix/pulls

in the top left corder under RobinD42/Phoenix I see some text “forked from wxWidgets/Phoenix

If I click that 2nd link it goes away. What is that for and should we be clicking it and getting the project from there; I am presuming that is the “master”?

I think the ultimate master is still in the wxWidgets SVN repo as
github is not the official repo for wxWidgets (at least not yet,
see: note that trac has
recently been upgraded by Robin).
I forked the following repo and Robin has merged some of my PR’s, so
it should be the correct one.
Werner

···

Hi,

  On 6/12/2014 8:58, DevPlayer wrote:

When going to link

https://github.com/RobinD42/Phoenix/pulls

      in the top left corder under RobinD42/Phoenix I see some

text “forked from wxWidgets/Phoenix

      If I click that 2nd link it goes away. What is that for and

should we be clicking it and getting the project from there; I
am presuming that is the “master”?

http://trac.wxwidgets.org/ticket/15588

https://github.com/RobinD42/Phoenix

Hi Werner,

Hi,

trying to use UIActionSimulater.

Came up with following test:

   def test_lib_agw_flatmenuSelectMenu(self):
       self._mb = FM.FlatMenuBar(self.frame)

       subMenu = FM.FlatMenu()
       menuItem = FM.FlatMenuItem(subMenu, 20001, "First Menu Item", "", wx.ITEM_CHECK)
       subMenu.AppendItem(menuItem)

       self._mb.Append(subMenu, "File")

       self._mb.Refresh()

       subMenuPos = subMenu.GetPosition()
       subMenuPosScreen = self.frame.ClientToScreen(subMenuPos + (2, 2))
       uisim = wx.UIActionSimulator()
       uisim.MouseMove(subMenuPosScreen)
       uisim.MouseClick()

It passes but I think that is due to the test 'self.frame' not yet having layed out correctly when the test is running. I see this if I run the test in WingIDE 'debug test' and stop e.g. on the MouseClick line.

I thought this was solved at least for the C++ wxWidgets unit tests. I think basically what we need to do is make sure the unit tests don't run before the event loop has fully spun up. e.g. a wx.CallAfter at the end of OnInit to start the unit tests.

Thanks,

Kevin

···

On Jun 11, 2014, at 6:49 AM, Werner <wernerfbd@gmx.ch> wrote:

Hopefully Robin can give me some pointer on how to ensure that the layout is done.

Werner

--
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.