Roadmap to 3.2

[Vadim Zeitlin]

Hello,

Now that 3.1.1 is done (thanks again to all for helping with it!), I'd
like to think about plans for 3.2. Several things were originally planned
according to our own roadmap (http://trac.wxwidgets.org/wiki/Roadmap) but,
to be honest, none of them looks very realistic:

- I haven't heard anything about the new AUI branch since a very long time
and the last commit to https://github.com/nhold/wxWidgets/ which is,
AFAIK, its latest home, dates from 2 years ago. So I'm afraid we'll just
have to admit that this was, unfortunately, a failed experiment and is
never going to be integrated into the mainline. It's really sad to end
like this, but it doesn't make much sense to pretend that it's going to
be merged neither, IMO...

- wxMaskedEdit control doesn't work at all under non-MSW ports and I think
we need a very different approach to make it work in wxGTK and it looks
unlikely that anybody will implement this any time soon.

- Frozen rows/columns in wxGrid would be nice, but I haven't heard anything
about the attempt to implement them since several years neither, so it
seems safe to conclude this is not coming neither.

- Finally, I don't even know any more what was meant by better support for
window-modal dialogs. It's not even impossible that this has been already
implemented?


OTOH I still hope to work myself on per-monitor DPI support, i.e. merge
https://github.com/wxWidgets/wxWidgets/pull/334 (although, probably, with
quite a few changes). Other PRs I'd like to integrate -- but would really
appreciate help with reviewing/testing them -- are the "raw" touch events
one (https://github.com/wxWidgets/wxWidgets/pull/649) and CEF-based
wxWebView implementation (https://github.com/wxWidgets/wxWidgets/pull/706).
There are also 36 tickets with 3.2.0 milestone in wxTrac currently, see

http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&milestone=3.2.0&group=component&col=id&col=summary&col=status&col=type&col=priority&col=component&col=time&col=changetime&col=patch&order=priority

and I'll try to at least have a look at some of them, but this will be on
"best effort" basis only (and, of course, any help with triaging/testing/
fixing them would be very welcome too).

Is there anything else I'm forgetting? If not, I think that making 3.1.2
in June should be doable and we could create 3.2 branch after it and make
3.2.0 with only bug-fixes in, say, September.

What do you think?
VZ

[Laurent Poujoulat]

Le 20/02/2018 à 15:13, Vadim Zeitlin a écrit :
> Hello,
Hello Vadim,

>
> Now that 3.1.1 is done (thanks again to all for helping with it!), I'd
> like to think about plans for 3.2. Several things were originally planned
> according to our own roadmap (http://trac.wxwidgets.org/wiki/Roadmap) but,
> to be honest, none of them looks very realistic:
>
> - I haven't heard anything about the new AUI branch since a very long time
> and the last commit to https://github.com/nhold/wxWidgets/ which is,
> AFAIK, its latest home, dates from 2 years ago. So I'm afraid we'll just
> have to admit that this was, unfortunately, a failed experiment and is
> never going to be integrated into the mainline. It's really sad to end
> like this, but it doesn't make much sense to pretend that it's going to
> be merged neither, IMO...

Just a few words about this: as one of those who spent a lot of time in
it, I think we were just all tired of waiting/trying to get it merged. I
remember we started to have discussions about this in 2013 (!) and it
was already an ongoing story. I can't really understand why it has not
been already merged; maybe it's because it's not fully compatible with
the current AUI, but the structure of new AUI is such that it will never
be 100% compatible with the previous one, so no point to try anymore if
we can't break at all the API.

I agree it's rather sad to end like this, but I don't see how to avoid it.

Anyway for those interested, the New AUI is really working well and as
rather less bugs than the original one for a shitload of new
possibilities. In my case, I just maintain a private branch for my
products that use it a lot, and I can live without it being integrated
upstream.

Best regards
Laurent

[Vadim Zeitlin]

On Tue, 20 Feb 2018 16:24:07 +0100 Laurent Poujoulat wrote:

LP> Le 20/02/2018 à 15:13, Vadim Zeitlin a écrit :
LP> > Hello,
LP> Hello Vadim,
LP> >
LP> > Now that 3.1.1 is done (thanks again to all for helping with it!), I'd
LP> > like to think about plans for 3.2. Several things were originally planned
LP> > according to our own roadmap (http://trac.wxwidgets.org/wiki/Roadmap) but,
LP> > to be honest, none of them looks very realistic:
LP> >
LP> > - I haven't heard anything about the new AUI branch since a very long time
LP> > and the last commit to https://github.com/nhold/wxWidgets/ which is,
LP> > AFAIK, its latest home, dates from 2 years ago. So I'm afraid we'll just
LP> > have to admit that this was, unfortunately, a failed experiment and is
LP> > never going to be integrated into the mainline. It's really sad to end
LP> > like this, but it doesn't make much sense to pretend that it's going to
LP> > be merged neither, IMO...
LP> Just a few words about this: as one of those who spent a lot of time in
LP> it, I think we were just all tired of waiting/trying to get it merged.

I know, but from my point of view it was never ready to be merged, so it
was a vicious circle. I did try to merge it several times, but every time I
found bugs and incompatibilities after only very cursory testing. The last
time we discussed this, I asked for just 2 things:

1. A list of incompatible changes compared to the current API.
2. Absence of obvious user-visible bugs.

which really doesn't seem to be that much to ask for. Unfortunately I've
never seen (1) and I don't think it's responsible to merge breaking changes
without even knowing what exactly they break.

Previously, I had been also worried by a lot of gratuitous changes, like
changes to naming convention, indentation and so on, which should really
have been never done in the first place, but, again, later I was ready to
merge it even with all these changes in place -- but we do need to know
what exactly needs to be updated in the user code and, of course, the new
version needs to work at least as well as the current one (just to be
clear, when I say bugs, I mean crashes when dragging the notebook pages
around in the aui sample, not just some minor aesthetic issues).


LP> I remember we started to have discussions about this in 2013 (!)

I'm afraid it's much older than this, even :-(

Once again, I'd be very sorry to see all the effort on new AUI to be
wasted. It's clearly not the fault of people who worked on it, but of
project (lack of) organization. But I still don't know what can we do about
it now.

I'd be ready to try to merge the new AUI one last time, but we really,
really need (1) first -- and, of course, I hope it's not too extensive
and/or that we may provide some compatibility/migration helpers. I don't
know if anybody of new-AUI developers would be (still) ready to spend time
on this...

Regards,
VZ

[Mart Raudsepp]

On Tue, 2018-02-20 at 15:13 +0100, Vadim Zeitlin wrote:
>  Is there anything else I'm forgetting? If not, I think that making
> 3.1.2
> in June should be doable and we could create 3.2 branch after it and
> make
> 3.2.0 with only bug-fixes in, say, September.

To me that sounds like a good timeline for a 3.4.0 release, not 3.2.

This is making various Linux distributions users have to suffer with a
4-5 year old cycle for another half a year.


Need to stop thinking about "what all should be included and delay the
release more and more", and just release more often. What doesn't cut
it, too bad, there'll be a next release soon enough. Now it's a vicious
cycle of "lets get everything, delay it as long as needed, there won't
be a new feature release after this one for another 5 years" still.


Still very very grumpy downstream maintainer,
Mart

[Teodor Petrov]

On 02/20/2018 05:24 PM, Laurent Poujoulat wrote:
> Anyway for those interested, the New AUI is really working well and as
> rather less bugs than the original one for a shitload of new
> possibilities. In my case, I just maintain a private branch for my
> products that use it a lot, and I can live without it being integrated
> upstream.

Can you share a branch that could be merged with the latest wx-master
(master to
the branch), so I can do some testing?

/Teodor

[Laurent Poujoulat]

Our own repository is under SVN, but I will setup this under github for
you before monday.
>
> /Teodor
>
Laurent

[Iwbnwif Yiw]

On Tuesday, February 20, 2018 at 2:13:04 PM UTC, VZ wrote:

 Now that 3.1.1 is done (thanks again to all for helping with it!), I'd
like to think about plans for 3.2. 

Thank you to everyone for releasing 3.1.1. At the risk of promoting one of my own tickets - which is exactly what I am doing ;) - I would like to see if it is possible to implement automatic spell checking in wxTextCtrl.

https://trac.wxwidgets.org/ticket/17544

I don't believe this needs much work from others, principally the following:

1. Review and approve the revised API

2. Provide some guidance on the build methodology to include the necessary libraries

... and of course to merge the changes.

I was thinking about re-proposing this as a PR, but not sure if that will help or hinder things.

Thanks for considering!

[Vadim Zeitlin]

On Wed, 21 Feb 2018 09:51:11 -0800 (PST) Iwbnwif Yiw wrote:

IY> On Tuesday, February 20, 2018 at 2:13:04 PM UTC, VZ wrote:
IY> >
IY> >
IY> > Now that 3.1.1 is done (thanks again to all for helping with it!), I'd
IY> > like to think about plans for 3.2.
IY> >
IY>
IY> Thank you to everyone for releasing 3.1.1. At the risk of promoting one of
IY> my own tickets - which is exactly what I am doing ;) - I would like to see
IY> if it is possible to implement automatic spell checking in wxTextCtrl.
IY>
IY> https://trac.wxwidgets.org/ticket/17544

This one does have 3.2.0 milestone so I was already going to look at it,
but thanks for the reminder.

IY> I don't believe this needs much work from others, principally the following:
IY>
IY> 1. Review and approve the revised API
IY> 2. Provide some guidance on the build methodology to include the necessary
IY> libraries
IY>
IY> ... and of course to merge the changes.
IY>
IY> I was thinking about re-proposing this as a PR, but not sure if that will
IY> help or hinder things.

It would be definitely helpful, as it would allow to check that it builds
on all platforms and also leaving comments for any issues in the code
directly in the PR, so please do it.

TIA!
VZ

[Iwbnwif Yiw]

IY> I was thinking about re-proposing this as a PR, but not sure if that will 

IY> help or hinder things.

 It would be definitely helpful, as it would allow to check that it builds
on all platforms and also leaving comments for any issues in the code
directly in the PR, so please do it.

The patch was rather old, so it required a bit of work to be able to be applied to the current source tree.

I think it is okay now and I have created a PR as discussed. Unfortunately, I missed that src/stc/stc.cpp somehow got caught up in the change.

As it stands, it builds and the sample works on Linux. The point of this commit was to refresh my memory on the PR process and also to provide the sample API for people to comment on. 

If all is good, then I will continue on the wxMSW and wxMAC versions.

I won't add any more to this thread. We can continue the discussion against the PR on GitHub :)

[Laurent Poujoulat]

Le 21/02/2018 à 01:16, Teodor Petrov a écrit :

Sorry for the delay, but I'm not fluent in Git/Github (I even created an
unwanted pull request to the actual wxWidgets) . I merged against master
and checked it compiles under MSYS2/MinGW64, but had not time for more
testing.

You can find the result here:
https://github.com/lpoujoulat/wxWidgets
Check the NewAUI branch

Regards

>
> /Teodor
>
Laurent

[Vadim Zeitlin]

On Mon, 26 Feb 2018 17:09:45 +0100 Laurent Poujoulat wrote:

LP> Sorry for the delay, but I'm not fluent in Git/Github (I even created an
LP> unwanted pull request to the actual wxWidgets)

Thanks, the PR is not really unwanted and actually it would be very nice
to have it. But the problem is that it's not a real merge: you just
replaced the files in master with your files, which has 2 rather bad
consequences:

1. You've lost all the changes done in master in the meanwhile, e.g. all
the trivial changes like the use of wxOVERRIDE, wx-prefixed-macros etc
and at least one non-trivial one: addition of native MSW art. Worse,
we don't even know what else has been lost, but there is surely more,
e.g. I can see after only some very cursory inspection that
wxAuiFloatingFrame::IsTopNavigationDomain() has disappeared as well. And
it's going to be a lot of work to review everything and undo all these
unwanted changes.

2. You've completely lost the history of modifications in the new branch.
This is perhaps less catastrophic, but it would almost certainly be
useful to be able to track the provenance of some change in the future
and without having any history information, this will be completely
impossible.

In principle, both problems could be avoided by doing a real merge, i.e.
"git merge" (or "git imerge", perhaps, if the merge is too difficult, see
https://github.com/mhagger/git-imerge). But, of course, this would require
much more work than just replacing files.

Unfortunately it really needs to be done if only to allow really reviewing
the changes, we're not going to just rollback several years of changes in
the master sources blindly...


LP> I merged against master and checked it compiles under MSYS2/MinGW64,
LP> but had not time for more testing.

FWIW, Appveyor CI shows some errors, but this isn't really the worst
problem.

Regards,
VZ

[Laurent Poujoulat]

Le 26/02/2018 à 19:24, Vadim Zeitlin a écrit :

Hello Vadim,

> On Mon, 26 Feb 2018 17:09:45 +0100 Laurent Poujoulat wrote:
>
> LP> Sorry for the delay, but I'm not fluent in Git/Github (I even created an
> LP> unwanted pull request to the actual wxWidgets)
>
> Thanks, the PR is not really unwanted and actually it would be very nice
> to have it. But the problem is that it's not a real merge: you just
> replaced the files in master with your files, which has 2 rather bad
> consequences:

It is not intended at all to be an actual merge. It's just a way to
publish my personal state of the new AUI if anyone is interested in it.
Nothing more.

>
> 1. You've lost all the changes done in master in the meanwhile, e.g. all
> the trivial changes like the use of wxOVERRIDE, wx-prefixed-macros etc
> and at least one non-trivial one: addition of native MSW art. Worse,
> we don't even know what else has been lost, but there is surely more,
> e.g. I can see after only some very cursory inspection that
> wxAuiFloatingFrame::IsTopNavigationDomain() has disappeared as well. And
> it's going to be a lot of work to review everything and undo all these
> unwanted changes.

It's obviously a problem, but it's a result of having wait too long for
the merge. Tracking things is really difficult  outside of the tree, and
not really necessary for my company own use.

>
> 2. You've completely lost the history of modifications in the new branch.
> This is perhaps less catastrophic, but it would almost certainly be
> useful to be able to track the provenance of some change in the future
> and without having any history information, this will be completely
> impossible.
>
> In principle, both problems could be avoided by doing a real merge, i.e.
> "git merge" (or "git imerge", perhaps, if the merge is too difficult, see
> https://github.com/mhagger/git-imerge). But, of course, this would require
> much more work than just replacing files.

I would gladly do this, but unfortunately, I honestly don' have the time
for this in the foreseeing future, especially now that all interested
persons (and manpower) has vanished.

>
> Unfortunately it really needs to be done if only to allow really reviewing
> the changes, we're not going to just rollback several years of changes in
> the master sources blindly...

I perfectly understand that, and I don't request such thing. Again, it's
just publishing what I use, nothing more.

>
>
> LP> I merged against master and checked it compiles under MSYS2/MinGW64,
> LP> but had not time for more testing.
>
> FWIW, Appveyor CI shows some errors, but this isn't really the worst
> problem.
>
> Regards,
> VZ

Regards,
Laurent

[Vadim Zeitlin]

On Tue, 27 Feb 2018 08:23:45 +0100 Laurent Poujoulat wrote:

[...]
LP> > Unfortunately it really needs to be done if only to allow really reviewing
LP> > the changes, we're not going to just rollback several years of changes in
LP> > the master sources blindly...
LP> I perfectly understand that, and I don't request such thing. Again, it's
LP> just publishing what I use, nothing more.

I understand this but, unfortunately, I simply can't afford doing the
merge myself neither. So we'll just have to accept that it's not going to
happen, which is, once again, very sad, but it's just not useful to
continue pretending that it's going to be done.

Thanks for all your (and others, of course) work on this, I sincerely
regret that it couldn't be better managed, but there is not much we can do
about it now.

Best regards,
VZ

[New Pagodi]

Is it alright if I try to merge the two?  I've looked at the files in winmerge, and I don't think it will be too bad.  It might take a couple days though.

[Kinaou Herve]

It would be very welcome :)

[g...@be-enabled.de]

Am Dienstag, 20. Februar 2018 15:13:04 UTC+1 schrieb VZ:

Other PRs I'd like to integrate -- but would really
appreciate help with reviewing/testing them -- are the "raw" touch events
one (https://github.com/wxWidgets/wxWidgets/pull/649) 

Hi, 

i tested touch support under Windows and it didn't work at all. Mainly, because the event structure was filled incorrectly ( eventype instead of window id).

Changes i made:

- set id and event object in wxMultiTouchEvent

- fix clearing the event mask which lead to an assert in the sample in debug mode

- remove "numConfigs" variable which was set to 1, but never increased. Use "configs.size()" instead.

- don't call SetGestureConfig() at all if we're not interested in gestures

- small fix to silence compiler warning (int to bool)

As they were small changes, i put them all in out patch, sorry if that causes additional work.

Regards,

Markus

 

[Vadim Zeitlin]

On Sun, 11 Mar 2018 05:27:57 -0700 (PDT) wrote:

> Am Dienstag, 20. Februar 2018 15:13:04 UTC+1 schrieb VZ:
> >
> > Other PRs I'd like to integrate -- but would really
> > appreciate help with reviewing/testing them -- are the "raw" touch events
> > one (https://github.com/wxWidgets/wxWidgets/pull/649)
> >
> Hi,
>
> i tested touch support under Windows

Thanks for testing this!

> i and it didn't work at all.

Oops...

> Mainly, because the event structure was filled incorrectly ( eventype
> instead of window id).
>
> Changes i made:
>
> - set id and event object in wxMultiTouchEvent
>
> - fix clearing the event mask which lead to an assert in the sample in
> debug mode
>
> - remove "numConfigs" variable which was set to 1, but never increased. Use
> "configs.size()" instead.
>
> - don't call SetGestureConfig() at all if we're not interested in gestures
>
> - small fix to silence compiler warning (int to bool)
>
> As they were small changes, i put them all in out patch, sorry if that
> causes additional work.

I didn't have time to look at these changes yet, but I've updated the PR
with a link to this patch, so we won't forget to include it when applying
this.

The fact that the original PR didn't work at all is a bit discouraging
however, it would be great if people could test it under the other
platforms to check that it works there.

Thanks again,
VZ

[Eric Jensen]

Hello Vadim,

Sunday, March 11, 2018, 10:27:21 PM, you wrote:

VZ> On Sun, 11 Mar 2018 05:27:57 -0700 (PDT) wrote:

>> Am Dienstag, 20. Februar 2018 15:13:04 UTC+1 schrieb VZ:
>> >
>> > Other PRs I'd like to integrate -- but would really
>> > appreciate help with reviewing/testing them -- are the "raw" touch events
>> > one (https://github.com/wxWidgets/wxWidgets/pull/649)
>> >
>> Hi,
>>
>> i tested touch support under Windows

VZ> Thanks for testing this!

VZ> The fact that the original PR didn't work at all is a bit discouraging
VZ> however, it would be great if people could test it under the other
VZ> platforms to check that it works there.

FWIW, the only "real" problem was the incorrectly constructed event.
If the original author didn't have access to a Windows tablet, that
can happen.

I could try to boot Linux on my (Windows) tablet, but even if that
works, i guess the chance that the touch screen is recognized is
rather small?

I'll try anyway, but that won't happen before the end of the week.

Markus

[g...@be-enabled.de]

Am Sonntag, 11. März 2018 22:27:24 UTC+1 schrieb VZ:

I didn't have time to look at these changes yet, but I've updated the PR
with a link to this patch, so we won't forget to include it when applying
this.

 The fact that the original PR didn't work at all is a bit discouraging
however, it would be great if people could test it under the other
platforms to check that it works there.

 Thanks again,
VZ

Unforunately i wasn't able to get any Linux distro to boot on the Windows tablet, so i couldn't test the GTK version.

But looking into the sources, i think both the GTK and OSX version have the same problem regarding the wrong parameter order to the wxMultiTouchEvent ctor.

Are there any OSX devices with touch support anyway? I can only think of iPads etc that use iOS.

Markus

[Luke A. Guest]

Hi,

What's the status of this merge? I tried to merge and it wasn't clean at all.

Luke.

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Urs Hanselmann]

Hi Laurent,

do you still have your private branch online somewhere?

The github repo you shared seems to be offline.

[Laurent Poujoulat]

Le 02/09/2018 à 16:39, Urs Hanselmann a écrit :

Hi Laurent,

Hi Urs

do you still have your private branch online somewhere?

The github repo you shared seems to be offline.

I removed it from github with my account because I don't wish to let a company I don't trust manage my data and my work.
As you seem interested, I will put it back online this week in another forge and post back the new location.

Sorry for the inconvenience,
Best regards
Laurent

On Monday, February 26, 2018 at 5:09:38 PM UTC+1, lpoujoulat wrote:

Le 21/02/2018 à 01:16, Teodor Petrov a écrit :
> On 02/20/2018 05:24 PM, Laurent Poujoulat wrote:
>> Anyway for those interested, the New AUI is really working well and as
>> rather less bugs than the original one for a shitload of new
>> possibilities. In my case, I just maintain a private branch for my
>> products that use it a lot, and I can live without it being integrated
>> upstream.
>
> Can you share a branch that could be merged with the latest wx-master
> (master to
> the branch), so I can do some testing?
Sorry for the delay, but I'm not fluent in Git/Github (I even created an
unwanted pull request to the actual wxWidgets) . I merged against master
and checked it compiles under MSYS2/MinGW64, but had not time for more
testing.

You can find the result here:
https://github.com/lpoujoulat/wxWidgets
Check the NewAUI branch

Regards

>
> /Teodor
>
Laurent

--

[Urs Hanselmann]

That would be very nice, thank you :)

Best,

Urs

[Laurent Poujoulat]

As promised,
I set a new repository with my code for the alternate wxAUI branch. It is there:

https://framagit.org/lpoujoulat/wxWidgets.NewAUI
Check the NewAUI branch.

I made this "quick and dirty", especially the wxWidgets version it is based on is rather old and not updated.

As I don't think it will ever go up-stream, I plan to pull it out and made it a standalone component in the future, so it would be no more necessary to mess with the reference wxWidgets, especially with the new AUI more and more diverging from the original AUI.

Meanwhile, I will continue to push my changes  to the new repository. I will of course welcome any enhancement, fix, issue report or question ...

Best regards,
Laurent

[Teodor Petrov]

On 09/07/2018 04:06 PM, Laurent Poujoulat wrote:
>
> As promised,
> I set a new repository with my code for the alternate wxAUI branch. It
> is there:
>
> https://framagit.org/lpoujoulat/wxWidgets.NewAUI
> Check the NewAUI branch.
>
> I made this "quick and dirty", especially the wxWidgets version it is
> based on is rather old and not updated.

Thanks,

I've tested the aui sample from your branch on linux  and I've found at
least four problems:
1. some sizer assert at the beginning
2. there are not overlays showing where a pane would be dropped
3. I crashed it while moving toolbars
4. The size of the toolbars changes pretty strangely.

The most serious one is 2. Is this the expected behaviour?

/Teodor

[Laurent Poujoulat]

Not at all. It should behave as the regular AUI out of the box because
no new feature in on by default.
I know it's running flawlessly in my applications, but I did not checked
the AUI sample since a very long time, and as I work on Windows, I admit
I did no test on Linux or MacOS.

I will try to spare some time to run the sample on Windows to see what's
going on, at least on this platform.

>
> /Teodor
>
Laurent

[Mart Raudsepp]

Ühel kenal päeval, T, 20.02.2018 kell 15:13, kirjutas Vadim Zeitlin:
> Is there anything else I'm forgetting? If not, I think that making
> 3.1.2
> in June should be doable and we could create 3.2 branch after it and
> make
> 3.2.0 with only bug-fixes in, say, September.

It is September now, and still not even a 3.1.2 release.

I continue to refuse packaging 3.1.x releases downstream for good
reasons and thus various applications can not be updated to their newer
versions, as they've made the apparently bad choice of relying on a
development release that doesn't seem to ever get a stable series.

Please stop thinking about all the features and fixes you could get
included in a 3.2.0 and instead just do it, with all these features and
bug fixes in future releases at the same date than your current
approach would result in a 3.2.0. Consumers are suffering from all the
existing bugs and lack of features during all this time, that are
available in 3.1 but not usable if you want to support Linux - which is
kind of a point of wxWidgets (supporting all big 3).


Mart

[Teodor Petrov]

On 09/08/2018 08:34 AM, Laurent Poujoulat wrote:
>> I've tested the aui sample from your branch on linux  and I've found
>> at least four problems:
>> 1. some sizer assert at the beginning
>> 2. there are not overlays showing where a pane would be dropped
>> 3. I crashed it while moving toolbars
>> 4. The size of the toolbars changes pretty strangely.
>>
>> The most serious one is 2. Is this the expected behaviour?
> Not at all. It should behave as the regular AUI out of the box because
> no new feature in on by default.
> I know it's running flawlessly in my applications, but I did not
> checked the AUI sample since a very long time, and as I work on
> Windows, I admit I did no test on Linux or MacOS.
>
> I will try to spare some time to run the sample on Windows to see
> what's going on, at least on this platform.

OK, It seems this is an optional behaviour and after enabling the option
for blinds in the menu. I can see the hints.
Apart from the assert at the beginning and the crash, I'm not able to
reproduce :(, the two samples seems to
behave the same.

What is the problem with fulfilling the Vadim's requirements from an
earlier post? At least requirement 1?
How hard would it be to make a list with all the api changes? I'm
willing to spend time on merging this thing to
the latest master.

Also what are the benefits of the branch? Would I be able to move a pane
from one notebook to another?
This is the main missing feature of AUI at the moment. The second
missing feature is more user friendly
hints (something like the hints in visual studio would be best).

/Teodor

[Lauri Nurmi]

Mart Raudsepp kirjoitti 8.9.2018 klo 16:40:
> Ühel kenal päeval, T, 20.02.2018 kell 15:13, kirjutas Vadim Zeitlin:
>> Is there anything else I'm forgetting? If not, I think that making
>> 3.1.2
>> in June should be doable and we could create 3.2 branch after it and
>> make
>> 3.2.0 with only bug-fixes in, say, September.
> It is September now, and still not even a 3.1.2 release.
>

> Please stop thinking about all the features and fixes you could get
> included in a 3.2.0 and instead just do it, with all these features and
> bug fixes in future releases at the same date than your current
> approach would result in a 3.2.0. Consumers are suffering from all the
> existing bugs and lack of features during all this time, that are
> available in 3.1 but not usable if you want to support Linux - which is
> kind of a point of wxWidgets (supporting all big 3).

I agree. It is hopeless to aim for a perfect release that has everything
fixed and thoroughly tested. Years and years go by, and new features
that already are in the 3.1 branch cannot be taken advantage of, unless
one wants to package and maintain one's own wxGTK.

Lauri

[Vadim Zeitlin]

On Thu, 13 Sep 2018 21:23:25 +0300 Lauri Nurmi wrote:

LN> I agree. It is hopeless to aim for a perfect release that has everything
LN> fixed and thoroughly tested.

We're not aiming for perfect release, but we can't release 3.1.2 right now
until the wxFont changes are stabilized. Initially I planned to have
wxValidator changes and better high DPI support in it, but we'll almost
certainly have to do without the latter and possibly without the former as
well. We do need to polish wxFont changes before even a point release
however, this is an unexpected but welcome bonus if you wish.

Anyhow, I don't want to overreact but I really wish people who want so
much to make release just went ahead and made them instead of periodically
making passive-aggressive (with the accent on the latter) posts here. It's
not like anybody is preventing anybody from making wxWidgets releases.

[...rest of my thoughts about this censored...]
VZ

[Frédéric]

> We're not aiming for perfect release, but we can't release 3.1.2 right now
> until the wxFont changes are stabilized.

In older messages you suggested that master was rather stable so that
it could be used in production. Are you saying that right now there
are some changes about wxFont that are not mature enough? Or is it all
in other branches or PR?

> Anyhow, I don't want to overreact but I really wish people who want so
> much to make release just went ahead and made them

We cannot rely on you alone for everything. In particular, your time
is probably better spent on some difficult bugs that you only can
understand.
In a previous message you said "It has become much better but it's
still not 100% automate". Is it something somebody else than you can
do?

It would be nice to have a dev release every 6 months or so. In my
opinion it is important to show that the project is alive. When I
choose to add a dependency in my project, I try to see if the project
is moving and release frequency is one aspect (not all, commit
frequency is another).

F

[Vadim Zeitlin]

On Fri, 14 Sep 2018 17:03:54 +0200 Frédéric wrote:

F> > We're not aiming for perfect release, but we can't release 3.1.2 right now
F> > until the wxFont changes are stabilized.
F>
F> In older messages you suggested that master was rather stable so that
F> it could be used in production. Are you saying that right now there
F> are some changes about wxFont that are not mature enough? Or is it all
F> in other branches or PR?

Yes, master is supposed to be stable all the time, but right now it
contains some not fully finished changes to wxFont and the rest of these
changes is in a yet unmerged PR (#919).

F> > Anyhow, I don't want to overreact but I really wish people who want so
F> > much to make release just went ahead and made them
F>
F> We cannot rely on you alone for everything. In particular, your time
F> is probably better spent on some difficult bugs that you only can
F> understand.
F> In a previous message you said "It has become much better but it's
F> still not 100% automate". Is it something somebody else than you can
F> do?

It's much simpler than it used to be, but it still requires a couple of
hours from me and probably more from Xavier and Danny who build binaries,
so it's still not 100% automatic and probably can't be.

F> It would be nice to have a dev release every 6 months or so.

Yes, I'm fully aware of it. I hoped to have a release in September, but
this probably won't happen because the font changes were unplanned. I think
it's more important to integrate them before 3.1.2 than to release it
without them, but we will make 3.1.2 soon afterwards.

With 3.2.0 the story is more difficult because both high DPI support and
better validators API will almost certainly require some not perfectly
backwards compatible API changes and I'd really, really like to have them
in this release. I don't know when is it going to happen yet.

Regards,
VZ

[Danny Scott]

I am now full-time retired so time is not so much an issue for me. Just let me know what and when you need anything done.

--

Danny Scott