GSoC 2017 call for mentors/proposals

[Vadim Zeitlin]

Hello,

Today is the opening date for submitting applications for participating,
as an organization, in GSoC 2017. As usual, there are 2 questions:

1. Do we have any good project ideas?
2. Do we have any mentors?

Looking at http://www.wxwidgets.org/gsoc/projects/ there is really not that
much exciting there... wxiOS one is by far the most interesting, of
course, but I'm not sure if we have any mentors of it and whether we want
to spend yet another GSoC opportunity on this kind of pie in the sky
projects. Personally, I think that wxGrid improvement would be very welcome
as many people asked about it during the years, but it's not very sexy.
Still, I guess there should be enough there to interest 2-3 students (and
we probably wouldn't get, nor be able to handle, more than that). So the
really critical question is the second one. I think I should be able to
mentor this year, but we need at least 2 more people. Who would be
interested in doing it?

We have until Feb 9 to submit our application (see
https://developers.google.com/open-source/gsoc/timeline) and it would
surely be better to not wait until the last moment.

Thanks in advance,
VZ

[Eric Jensen]

Hello Vadim,

Thursday, January 19, 2017, 12:35:02 AM, you wrote:

VZ> Hello,

VZ> Today is the opening date for submitting applications for participating,
VZ> as an organization, in GSoC 2017. As usual, there are 2 questions:

VZ> 1. Do we have any good project ideas?
VZ> 2. Do we have any mentors?

I still think that my proposal from 3 years ago, a wxGraphicsContext
implementation using OpenGL for 2D drawing, is a good idea.

It would be very useful, should be relatively interesting for the
student and has the right size for a GSoC project.

I guess GSoC project should be about something new and not just a fix?
Otherwise i think there are several things that could be done for
wxRichTextCtrl. E.g. the printer output (different result on screen
than on printer).

How about a OpenDocument import/export for wxRTC? Or at least RTF?

Eric




--

[Julian Smart]

Hi Vadim, Eric,

On 19/01/2017 21:51, Eric Jensen wrote:
> I guess GSoC project should be about something new and not just a fix?
> Otherwise i think there are several things that could be done for
> wxRichTextCtrl. E.g. the printer output (different result on screen
> than on printer).
>
> How about a OpenDocument import/export for wxRTC? Or at least RTF?

I do have code for wxRTC ODT import/export but it's got a lot of
functionality/bloat related to implementing features not directly
supported by standard wxRTC, including fields, TOCs, indexes,
bibliographies, automatic style naming (e.g. Normal + Alignment instead
of P654), and page layout styles. I'd be happy to contribute it for
someone to strip down or simply look at while reimplementing simpler ODT
support. I suppose a valid question would be whether it's likely that a
reasonable number of people would need this functionality built into
wxWidgets.

I'm not sure RTF is really a useful thing to implement given it's quite
obsolete now; ODT is still current and IMO easier to manage since (among
other things) it's XML-based.

I find printing to be such a minefield I don't go there any more :-) and
instead generate HTML or ODT for my customers to use with a web browser
or word processor, if they need to print. So I suppose generating ODT
would potentially reduce the need for printing directly from wxRTC - let
another application do the heavy lifting.

I would be very interested in RTL support for wxRTC, if that's a
realistic goal for a student.

Regards,

Julian

[Eric Jensen]

Hello Julian,

Friday, January 20, 2017, 9:22:22 AM, you wrote:

JS> Hi Vadim, Eric,

JS> On 19/01/2017 21:51, Eric Jensen wrote:
>> I guess GSoC project should be about something new and not just a fix?
>> Otherwise i think there are several things that could be done for
>> wxRichTextCtrl. E.g. the printer output (different result on screen
>> than on printer).
>>
>> How about a OpenDocument import/export for wxRTC? Or at least RTF?

JS> I do have code for wxRTC ODT import/export but it's got a lot of
JS> functionality/bloat related to implementing features not directly
JS> supported by standard wxRTC, including fields, TOCs, indexes,
JS> bibliographies, automatic style naming (e.g. Normal + Alignment instead
JS> of P654), and page layout styles. I'd be happy to contribute it for
JS> someone to strip down or simply look at while reimplementing simpler ODT
JS> support. I suppose a valid question would be whether it's likely that a
JS> reasonable number of people would need this functionality built into
JS> wxWidgets.

JS> I'm not sure RTF is really a useful thing to implement given it's quite
JS> obsolete now; ODT is still current and IMO easier to manage since (among
JS> other things) it's XML-based.

I only mentioned RTF because it's probably easier to implement than
ODT. ODT export should be possible, but ODT format is so powerful,
that a full import is probably impossible, because RTC just doesn't
support all the features.


JS> I find printing to be such a minefield I don't go there any more :-) and
JS> instead generate HTML or ODT for my customers to use with a web browser
JS> or word processor,
I think the printing itself works good enough, the problem i have is
that the screen output doesn't match the printer output (text is
formatted differently). In addition to a bug regarding margin
calculations (i made a ticket somewhere), the main problem just is
that text dimensions behave slightly different when rendered at
different resolutions. The solution is to use the same trick that is
used for printer preview: Render into a metafile at high resolution
and then "play" into into the paintdc. I once started implementing
that, but there were so many changes that had to be made, i gave up
after a while.

Eric




--

[Gerald Brandt]

I have a very basic RTF reader/writer. It doesn't tie in with wxRTC, but
it shouldn't be hard to do. I'd be happy to contribute it.

I'd love to take a quick look at the odt code.

Gerald

[Vadim Zeitlin]

On Thu, 19 Jan 2017 22:51:10 +0100 Eric Jensen wrote:

EJ> Thursday, January 19, 2017, 12:35:02 AM, you wrote:
EJ>
EJ> VZ> Hello,
EJ>
EJ> VZ> Today is the opening date for submitting applications for participating,
EJ> VZ> as an organization, in GSoC 2017. As usual, there are 2 questions:
EJ>
EJ> VZ> 1. Do we have any good project ideas?
EJ> VZ> 2. Do we have any mentors?
EJ>
EJ> I still think that my proposal from 3 years ago, a wxGraphicsContext
EJ> implementation using OpenGL for 2D drawing, is a good idea.

Hi,

I'm not sure if wxGraphicsContext API really maps that well to modern
OpenGL but, I guess, why not. Do you have any realistic ideas of when
exactly would you want to use wxGC instead of OpenGL directly if you're
going to use OpenGL for rendering anyhow?

EJ> It would be very useful, should be relatively interesting for the
EJ> student and has the right size for a GSoC project.

Yes, I agree with the latter. Would you also be available for mentoring
such a project? If so, could you please submit a PR against the web site
repository adding it?

EJ> I guess GSoC project should be about something new and not just a fix?

I think implementing new things is more fun and so should attract more
candidates, but we had a couple of successful projects involving only bug
fixing and/or testing too, so I don't think it's really a requirement.

Regards,
VZ

[Eric Jensen]

Hello Vadim,

Friday, January 20, 2017, 2:42:05 PM, you wrote:

VZ> On Thu, 19 Jan 2017 22:51:10 +0100 Eric Jensen wrote:

EJ>> Thursday, January 19, 2017, 12:35:02 AM, you wrote:
EJ>>
EJ>> VZ> Hello,
EJ>>
EJ>> VZ> Today is the opening date for submitting applications for participating,
EJ>> VZ> as an organization, in GSoC 2017. As usual, there are 2 questions:
EJ>>
EJ>> VZ> 1. Do we have any good project ideas?
EJ>> VZ> 2. Do we have any mentors?
EJ>>
EJ>> I still think that my proposal from 3 years ago, a wxGraphicsContext
EJ>> implementation using OpenGL for 2D drawing, is a good idea.

VZ> Hi,

VZ> I'm not sure if wxGraphicsContext API really maps that well to modern
VZ> OpenGL but, I guess, why not. Do you have any realistic ideas of when
VZ> exactly would you want to use wxGC instead of OpenGL directly if you're
VZ> going to use OpenGL for rendering anyhow?

It's not aimed at people who are using OpenGL anyway. It's for people
who already have wxGraphicsContext drawing code, but need fast,
hardware-accelerated output. Especially under Windows where the
Direct2D context is still in an unusable state (just tested again with
the drawing sample).

The advantages i see:

- OpenGL is hardware-accelerated on the 3 major platforms

- i expect all OpenGL drivers to be very stable and mature, so that
one could expect very consistent output over all platform. Ideally
pixel-identical.

- it might even be usable for Android and iOS, although wx is pretty
much dead on mobile.

EJ>> It would be very useful, should be relatively interesting for the
EJ>> student and has the right size for a GSoC project.

VZ> Yes, I agree with the latter. Would you also be available for mentoring
VZ> such a project?
In principle, yes. My problem is that - although i know wxWidgets in
general pretty well - i know very little about OpenGL and the general
wxGraphicsContext architecture in wxWidgets. So i had to learn about
this myself first. When using legacy OpenGL, it shouldn't be so hard
and AFAIK no GPU manufacturer is going to drop support for that
anytime soon. When using shaders, i have no clue at all about those.

Eric


--

[Manolo]

Hi

> In principle, yes. My problem is that - although i know wxWidgets in
> general pretty well - i know very little about OpenGL and the general
> wxGraphicsContext architecture in wxWidgets. So i had to learn about
> this myself first. When using legacy OpenGL, it shouldn't be so hard
> and AFAIK no GPU manufacturer is going to drop support for that
> anytime soon. When using shaders, i have no clue at all about those.
>

I'm not an expert in OpenGL. But I know enough for saying that 2D
rendering is half the problem, even when more difficult things such as
ligthing or tesselation will not be used in wxGraphicsContext.
The other half is mathematics: lines, circles, ellipses, splines.
Ah, and text. OGL provides absolutely nothing on text.

Learning shaders is easy: they are programs written in something very
similar to C language. In these programs is where most maths happen.

Regards,
Manolo

[Manolo m s]

Perhaps the integration of wxVirtualDataViewCtrl (track ticket 17775) with current wxDVC and keeping actual API and backwards compatibility is a challenging idea.

[Catalin]

Hello,

On Thursday, 19 January 2017, 1:35, Vadim Zeitlin wrote:

> 1. Do we have any good project ideas?

One idea: a "virtual window" / "virtual sizer" system. By "virtual" I mean windows that when not visible on the screen due to scrolling or out-of-sight positioning, would destroy their wxWindow [derived] component and keep only useful information (occupied space, label, flags etc), and would recreate the wxWindow component when becoming visible again.
Maybe a window-XRC-window transformation could be used for this.

That would be useful for releasing OS resources (window handlers, fonts etc).
It should also work around MSW window client size limitation (in a scrolled window, things after pixel 32767 are not rendered). However, a "virtual scrolled window" that only simulates the huge client size might be needed for this.

Of course, there would be limitations, like a pointer to the wxWindow component of a "virtual window" or its id should not be stored, maybe initially event handlers would not be allowed on them, re-creating things on the fly might be slower, and maybe others.

Examples of using such a component / system: a long list of static texts, a long list of image thumbnails.


There may be other ways of achieving such a system (un-Create()-ing already Create()-d windows?). Other ideas would be welcome.
Does it sound feasible?

A second idea would be for another enhancement to wxGrid: copy-pasting cell data. I have actually implemented this some years back, using wxDF_HTML clipboard format (BTW, at least at that time the support for it was broken in wxClipboard), so it is definitely possible. It was not public code so I don't think I can contribute any of it now. Copy-pasting did work both ways between wxGrid and {MS Excel, LibreOffice Calc, wxGrid}, so I'd say that the "html clipboard format" was correctly used.

> 2. Do we have any mentors?

I think I could mentor a project about wxGrid, sizers or other non-platform-specific component.


Regards,
C

[Vadim Zeitlin]

On Fri, 20 Jan 2017 08:30:39 -0800 (PST) Manolo m s wrote:

Mms> Perhaps the integration of wxVirtualDataViewCtrl (track ticket 17775) with
Mms> current wxDVC and keeping actual API and backwards compatibility is a
Mms> challenging idea.

Too challenging for any student I'm afraid. The experience of letting
students work on wxDVC code (there was at least one project involving it,
maybe two?) is very underwhelming so far, I'm not even sure if it was a net
benefit because while some bugs were undoubtedly fixed, a lot of very
strange code has also been introduced. Arguably, this is more of the
mentor's, rather than student's, fault, but who is going to mentor a wxDVC
project anyhow?

Regards,
VZ

[Vadim Zeitlin]

On Fri, 20 Jan 2017 15:30:14 +0100 Eric Jensen wrote:

EJ> VZ> I'm not sure if wxGraphicsContext API really maps that well to modern
EJ> VZ> OpenGL but, I guess, why not. Do you have any realistic ideas of when
EJ> VZ> exactly would you want to use wxGC instead of OpenGL directly if you're
EJ> VZ> going to use OpenGL for rendering anyhow?
EJ>
EJ> It's not aimed at people who are using OpenGL anyway. It's for people
EJ> who already have wxGraphicsContext drawing code, but need fast,
EJ> hardware-accelerated output.

Are we really certain that we can map wxGC API to fast OpenGL? I'm pretty
sure that we should be able to emulate it somehow, but if the main (only?)
goal is performance, it's not really obvious that we can achieve it like
this.

EJ> Especially under Windows where the Direct2D context is still in an
EJ> unusable state (just tested again with the drawing sample).

This is bad news, I thought it was in not a too bad shape :-( This is OT
here, but please do open bugs for the problems you found if we don't have
them already.

Regards,
VZ

[Vadim Zeitlin]

On Fri, 20 Jan 2017 16:29:08 +0000 (UTC) 'Catalin' via wx-dev wrote:

Cvwd> On Thursday, 19 January 2017, 1:35, Vadim Zeitlin wrote:
Cvwd>
Cvwd> > 1. Do we have any good project ideas?
Cvwd>
Cvwd> One idea: a "virtual window" / "virtual sizer" system. By "virtual" I
Cvwd> mean windows that when not visible on the screen due to scrolling or
Cvwd> out-of-sight positioning, would destroy their wxWindow [derived]
Cvwd> component and keep only useful information (occupied space, label,
Cvwd> flags etc), and would recreate the wxWindow component when becoming
Cvwd> visible again.

I don't think this can be implemented without the underlying toolkit
support for this and the only toolkit which does support it is Cocoa, with
its NSCell/NSControl separation and, as I was dismayed (because IMO it was
a really nice idea) to learn recently, even Apple is moving away from it.

Cvwd> Examples of using such a component / system: a long list of static
Cvwd> texts, a long list of image thumbnails.

The proper way to do is to do what wxGrid/wxDVC do and not use windows at
all and just render everything ourselves. BTW, this is what all browsers/
rendering engines do too, none of them uses native windows for HTML
elements.

Cvwd> A second idea would be for another enhancement to wxGrid:
Cvwd> copy-pasting cell data. I have actually implemented this some years
Cvwd> back, using wxDF_HTML clipboard format (BTW, at least at that time
Cvwd> the support for it was broken in wxClipboard), so it is definitely
Cvwd> possible. It was not public code so I don't think I can contribute
Cvwd> any of it now. Copy-pasting did work both ways between wxGrid and {MS
Cvwd> Excel, LibreOffice Calc, wxGrid}, so I'd say that the "html clipboard
Cvwd> format" was correctly used.

This does sound useful, but looks a bit too small for 2+ months of work.
Or am I underestimating the difficulty?

Cvwd> > 2. Do we have any mentors?
Cvwd>
Cvwd> I think I could mentor a project about wxGrid, sizers or other
Cvwd> non-platform-specific component.

Great, thanks!
VZ

[Eric Jensen]

Hello Manolo,

Friday, January 20, 2017, 5:15:39 PM, you wrote:

M> Hi

>> In principle, yes. My problem is that - although i know wxWidgets in
>> general pretty well - i know very little about OpenGL and the general
>> wxGraphicsContext architecture in wxWidgets. So i had to learn about
>> this myself first. When using legacy OpenGL, it shouldn't be so hard
>> and AFAIK no GPU manufacturer is going to drop support for that
>> anytime soon. When using shaders, i have no clue at all about those.
>>

M> I'm not an expert in OpenGL. But I know enough for saying that 2D
M> rendering is half the problem, even when more difficult things such as
M> ligthing or tesselation will not be used in wxGraphicsContext.
M> The other half is mathematics: lines, circles, ellipses, splines.
These are all trivial to implement.

M> Ah, and text. OGL provides absolutely nothing on text.
Yes, that's indeed a problem. But in a first stage it would work to
use the standard api to render into a bitmap and then draw the bitmap.
These should be cached so that they're not generated each time.

Eric


--

[Eric Jensen]

Hello Vadim,

Friday, January 20, 2017, 5:44:50 PM, you wrote:

VZ> On Fri, 20 Jan 2017 15:30:14 +0100 Eric Jensen wrote:

EJ>> VZ> I'm not sure if wxGraphicsContext API really maps that well to modern
EJ>> VZ> OpenGL but, I guess, why not. Do you have any realistic ideas of when
EJ>> VZ> exactly would you want to use wxGC instead of OpenGL directly if you're
EJ>> VZ> going to use OpenGL for rendering anyhow?
EJ>>
EJ>> It's not aimed at people who are using OpenGL anyway. It's for people
EJ>> who already have wxGraphicsContext drawing code, but need fast,
EJ>> hardware-accelerated output.

VZ> Are we really certain that we can map wxGC API to fast OpenGL?
Looking through the api i'm not sure about these:

- clipping by region

- Begin/Endlayer (but AFAIK they're no implemented everywhere either)

- all text related things. But i think it should be possible to use
the standard api to draw into a bitmap and then draw the bitmap

- Gradients - i have no idea how that could be done in OpenGL. But
again, i don't know much about OpenGL


VZ> sure that we should be able to emulate it somehow, but if the main (only?)
VZ> goal is performance, it's not really obvious that we can achieve it like
VZ> this.
The slow things are rendering filled polygons and bitmaps. And these
will be very fast with OpenGL.

EJ>> Especially under Windows where the Direct2D context is still in an
EJ>> unusable state (just tested again with the drawing sample).

VZ> This is bad news, I thought it was in not a too bad shape :-( This is OT
VZ> here, but please do open bugs for the problems you found if we don't have
VZ> them already.
When you start the drawing sample, all you get is asserts when
switching to Direct2D. In a release build without asserts, most
screens are just empty. Maybe it's just one small thing that causes
all others to fail, so i don't know if it's easily fixable.

Eric



--

[Manolo]

El 20/01/2017 a las 18:31, Eric Jensen escribió:
>
> Looking through the api i'm not sure about these:
>
> - clipping by region

Use a Stencil Buffer. Or Mask. Or Scissors.

>
> - Begin/Endlayer (but AFAIK they're no implemented everywhere
> either)

Transparency (blending on OGL parlance) is common in OGL.

>
> - all text related things. But i think it should be possible to use
> the standard api to draw into a bitmap and then draw the bitmap

I have never seen another method.

>
> - Gradients - i have no idea how that could be done in OpenGL. But
> again, i don't know much about OpenGL

Interpolation colors between triangle vertices. Automatic.

Other difficulties I see:
Pens & Brushes, Text measures (except when pixels map one to one to
bitmaps), Doc & Pages. And not all current API applies: DPI, NativeContext.

[Artur Wieczorek]

>
> EJ> Especially under Windows where the Direct2D context is still in an
> EJ> unusable state (just tested again with the drawing sample).
>
> This is bad news, I thought it was in not a too bad shape :-( This is OT
> here, but please do open bugs for the problems you found if we don't have
> them already.
>

Maybe version matters. I have just launched drawing sample with 3.1 (Win
7) and Direct2D renderer seems to work quite nice for all available screens.
Regards,
AW

[Catalin]

On Friday, 20 January 2017, 20:06, Artur Wieczorek wrote:

>>
>> EJ> Especially under Windows where the Direct2D context is still in an

?> EJ> unusable state (just tested again with the drawing sample).

>>
>> This is bad news, I thought it was in not a too bad shape :-( This is OT
>> here, but please do open bugs for the problems you found if we don't have
>> them already.
>>

> Maybe version matters. I have just launched drawing sample with 3.1 (Win
7) and Direct2D renderer seems to work quite nice for all available screens.

When using both Direct2D and GDI+, "Mask screen" (F6) does assert a lot for me too (there is trac ticket #14175 opened about it) with message
"Assert failure" failed in wxGCDCImpl::DoStretchBlit(): Blitting is not supported with this logical operation.

Also "Raster operations screen" (F7) displays only a subset of the graphics that are shown with plain wxDC.
But apart from things related to raster ops the other drawings look ok.

Win 7, VC 12.

Regards,
C

[Vadim Zeitlin]

On Fri, 20 Jan 2017 19:02:58 +0100 Manolo wrote:

M> El 20/01/2017 a las 18:31, Eric Jensen escribió:
M> >
M> > Looking through the api i'm not sure about these:
M> >
M> > - clipping by region
M> Use a Stencil Buffer. Or Mask. Or Scissors.
M>
M> >
M> > - Begin/Endlayer (but AFAIK they're no implemented everywhere
M> > either)
M> Transparency (blending on OGL parlance) is common in OGL.
M>
M> >
M> > - all text related things. But i think it should be possible to use
M> > the standard api to draw into a bitmap and then draw the bitmap
M> I have never seen another method.

We'd probably need to define (and cache) textures for all glyphs. We'll
need to use an (external, although maybe natively available) rasterizer
library too, because it's hopeless to even think about doing it on our own.

M> > - Gradients - i have no idea how that could be done in OpenGL. But
M> > again, i don't know much about OpenGL
M> Interpolation colors between triangle vertices. Automatic.
M>
M> Other difficulties I see:
M> Pens & Brushes, Text measures (except when pixels map one to one to
M> bitmaps), Doc & Pages. And not all current API applies: DPI, NativeContext.

The two latter ones are minor and not really a problem even if they were
not implemented, but there is a lot of work to be done here even without
them. I'm not sure how realistic is it to expect a student to do all, or
even most, of it... But I guess we could still offer it. And maybe Eric and
Manolo could co-mentor this project?

Regards,
VZ

[Eric Jensen]

2nd attempt, my last post was probably filtered, because it contained
an image attachment.

Hello Artur,

Friday, January 20, 2017, 7:06:28 PM, you wrote:

>>
>> EJ> Especially under Windows where the Direct2D context is still in an
>> EJ> unusable state (just tested again with the drawing sample).
>>
>> This is bad news, I thought it was in not a too bad shape :-( This is OT
>> here, but please do open bugs for the problems you found if we don't have
>> them already.
>>

AW> Maybe version matters. I have just launched drawing sample with 3.1 (Win
AW> 7) and Direct2D renderer seems to work quite nice for all available screens.
AW> Regards,
AW> AW


Windows 7 here, too. Freshly pulled from GIT a few hours ago.

See screenshot.
http://i.imgur.com/I0Wk02X.png

Eric




--

[Eran Ifrah]

On Thu, Jan 19, 2017 at 1:35 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

 Hello,

 Today is the opening date for submitting applications for participating,
as an organization, in GSoC 2017. As usual, there are 2 questions:

1. Do we have any good project ideas?

 

​I don't know if it is "sexy" or an attractive suggestion, but having the ability to handle modern WebAPI calls over HTTPS from wxWidgets desktop application will be great.

An example:

wxURL url("https://api.youtube.com");

The above is not possible atm with wxURL (at least last time I tried it)

Also, adding OAuth2 classes for wxWidgets would also be a good project

​

2. Do we have any mentors?

Looking at http://www.wxwidgets.org/gsoc/projects/ there is really not that
much exciting there... wxiOS one is by far the most interesting, of
course, but I'm not sure if we have any mentors of it and whether we want
to spend yet another GSoC opportunity on this kind of pie in the sky
projects. Personally, I think that wxGrid improvement would be very welcome
as many people asked about it during the years, but it's not very sexy.
Still, I guess there should be enough there to interest 2-3 students (and
we probably wouldn't get, nor be able to handle, more than that). So the
really critical question is the second one. I think I should be able to
mentor this year, but we need at least 2 more people. Who would be
interested in doing it?

 We have until Feb 9 to submit our application (see
https://developers.google.com/open-source/gsoc/timeline) and it would
surely be better to not wait until the last moment.

 Thanks in advance,
VZ

--

Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Artur Wieczorek]

W dniu 20.01.2017 o 19:28, 'Catalin' via wx-dev pisze:

And for Cairo (MSW release) this assertion is thrown as well. Apparently
this feature/issue with raster operations is related to wxGC in general,
not to Direct2D only.
Regards,
AW

[Artur Wieczorek]

W dniu 20.01.2017 o 20:43, Eric Jensen pisze:

As Vadim said, it would be good if you could open a bug ticket for this
issue. Now it's hard to say what is the reason for this assertion message.
Regards,
AW

[Vadim Zeitlin]

On Fri, 20 Jan 2017 21:47:40 +0200 Eran Ifrah wrote:

EI> On Thu, Jan 19, 2017 at 1:35 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
EI>
EI> > Hello,
EI> >
EI> > Today is the opening date for submitting applications for participating,
EI> > as an organization, in GSoC 2017. As usual, there are 2 questions:
EI> >
EI> > 1. Do we have any good project ideas?
EI> >
EI>
EI> I don't know if it is "sexy" or an attractive suggestion, but having the
EI> ability to handle modern WebAPI calls over HTTPS from wxWidgets desktop
EI> application will be great.

Yes, it would be useful, but we can only provide it under Windows without
requiring more 3rd party libraries, which is not good enough I'm afraid.
For any cross-platform application you would still need to use C++ REST SDK
or libcurl or whatever.

EI> Also, adding OAuth2 classes for wxWidgets would also be a good project

But it depends on the above, unfortunately.

Regards,
VZ

[Manolo]

El 20/01/2017 a las 20:36, Vadim Zeitlin escribió:
>
> The two latter ones are minor and not really a problem even if they were
> not implemented, but there is a lot of work to be done here even without
> them. I'm not sure how realistic is it to expect a student to do all, or
> even most, of it... But I guess we could still offer it. And maybe Eric and
> Manolo could co-mentor this project?
>

By pure coincidence with this proposal, I'm going to code, likely before
summer, drawing with OGL millions of lines, arcs and plenty of text.
I'll test then my strategy to transfer data from RAM to GPU, which may
be relevant on performance.

The whole wxGraphicsContext is a lot of work. But if you never begin
then you never finish.

[ardi]

VZ wrote:

wxiOS one is by far the most interesting, of
course, but I'm not sure if we have any mentors of it and whether we want
to spend yet another GSoC opportunity on this kind of pie in the sky
projects.

As a long-time wxWidgets user, and with several inhouse projects that use wxWidgets daily, I can say that the only lacking point I find in wxWidgets is mobile development. It's very sad that wxIOS and wxAndroid are not ready. This fact makes us use other toolkits for mobile development, breaking the multiplatform coding paradigm within wxWidgets.

Apart from that, I find all other things great, that's the only issue for me.

ardi
 

[Stefano Mtangoo]

On Thursday, January 19, 2017 at 2:35:04 AM UTC+3, VZ wrote:

Hello,

 Today is the opening date for submitting applications for participating,

as an organization, in GSoC 2017. As usual, there are 2 questions:

1. Do we have any good project ideas?

1. I second Eran on having good handling of Rest APIs. Its common for applications to use data from remote servers. So Here is my list on that: (1) Http Support (2) JSon Support. I see the hard part of writing cross platform codes but if we use zip and XML libraries what is wrong wih picking light http library and may be json library and write wrapper around them for Rest API?

Using libcurl will improve things not only on HTTP but also on FTP and we may expose native handle for simple interface just like we do for wxWindow native handle if someone want to use t for other protocol. Also we can make this optional.


2. Also I would like to see support for ODT. At least all features that wxRTC supports should be in export/import. I think IMHO, we don't need all features that ODT provides. Trying to implement all of them will be like trying to make wxLibreOffice or wxOO which should not be the case.


 

2. Do we have any mentors?

If the first one is accepted, I'm ready to help on that as I have been using curl and jsoncpp for quiet some time and quiet happy with them (I use them for REST API of course and SFTP.

As for (2) my understanding of wxRTC internals is very limited. So I will extend my hand to only where I can.

Cheer!
Stefano

Looking at http://www.wxwidgets.org/gsoc/projects/ there is really not that

much exciting there... wxiOS one is by far the most interesting, of

course, but I'm not sure if we have any mentors of it and whether we want
to spend yet another GSoC opportunity on this kind of pie in the sky

[Catalin]

On Friday, 20 January 2017, 19:12, Vadim Zeitlin wrote:
On Fri, 20 Jan 2017 16:29:08 +0000 (UTC) 'Catalin' via wx-dev wrote:

Cvwd> Examples of using such a component / system: a long list of static
Cvwd> texts, a long list of image thumbnails.

> The proper way to do is to do what wxGrid/wxDVC do and not use windows at all and just render everything

> ourselves. BTW, this is what all browsers/rendering engines do too, none of them uses native windows for HTML
> elements.

That is true, and I actually know that, but it would have been more comfortable to use the layout already implemented in sizers.
Then a relatively simple "graphic sizer" comes to my mind. It would accept only text (wxString) and images (i.e. wxBitmap), spacers, stretch spacers (which would assert if wxFULL_PAINT_ON_RESIZE was not used). Multi-line text would probably need more work. Layout would be the same as in sizers. Alignment could also be allowed, and maybe some font attributes for text elements.
But OTOH I think something mixing text and images is already implemented in wxRichTextCtrl so I don't really know about this..

Cvwd> A second idea would be for another enhancement to wxGrid:
Cvwd> copy-pasting cell data.

> This does sound useful, but looks a bit too small for 2+ months of work.
> Or am I underestimating the difficulty?

I don't remember all that much. There was a bug with wxClipboard under MSW, which unfortunately I don't really recall and never got to fix it in a decent manner so I could have contributed it, then there was the wxDF_HTML issue (it is a non-default format and it had to be registered in a different way than it was attempted by wxW, which didn't work IIRC), then there was some reverse engineering of the actual html used in the clipboard for transferring copied data. Then some functions for getting data in and out of the proper format. But all this only made it work under MSW, so for other platforms some more effort might be needed.

Regards,
C

[Teodor Petrov]

On 01/19/2017 01:35 AM, Vadim Zeitlin wrote:
> 1. Do we have any good project ideas?

What about a project to merge the AUI branch in master? Or reimplement
the most
important features/bug fixes from the branch in a merge-able way?

/Teodor

[Tobias T]

EI> I don't know if it is "sexy" or an attractive suggestion, but having the
EI> ability to handle modern WebAPI calls over HTTPS from wxWidgets desktop
EI> application will be great.

 Yes, it would be useful, but we can only provide it under Windows without
requiring more 3rd party libraries, which is not good enough I'm afraid.
For any cross-platform application you would still need to use C++ REST SDK
or libcurl or whatever.

I would also really like having a single HTTP(s) interface with various OS specific backends in wxWidgets.

• Under Windows this should probably use WinINet/WinHTTP
• At least partly implemented in the current code base when defining wxUSE_URL_NATIVE
• Can handle complex corporate proxy settings
• HTTPS support
  
• Under macOS NSURLSession could be used
• There are various HTTP APIs available on macOS but NSURLSession seems to be the latest
• HTTPS support
• HTTP/2 support
  
• A generic curl fallback for Linux (maybe also for special cases on Win and macOS)
• Probably a reasonable requirement on Linux
• cURL should not become a bundled third party library with wxWidgets
  
• A light JSON parser (included third party) could be added and wrapped
• OAuth could be an added bonus.

On Windows and macOS no third party libraries would be required and any future improvements in the underlying OS implementation (e.g. HTTP/2) would be directly available to wxWidgets applications.

It is probably realistic to be implemented in 2 month as it is mostly wrapping existing functionality.
Maybe this could also be split in two GSoC projects one for the HTTP wrapper and another for JSON and OAuth.


Tobias

[Eric Jensen]

Hello Vadim,

Friday, January 20, 2017, 2:42:05 PM, you wrote:

EJ>> It would be very useful, should be relatively interesting for the
EJ>> student and has the right size for a GSoC project.

VZ> Yes, I agree with the latter. Would you also be available for mentoring
VZ> such a project? If so, could you please submit a PR against the web site
VZ> repository adding it?

Done. I didn't know Manolo's last name, so that still needs to be
added.

Eric

[Kenneth Porter]

On 1/21/2017 2:17 AM, Stefano Mtangoo wrote:
> 1. I second Eran on having good handling of Rest APIs. Its common for
> applications to use data from remote servers. So Here is my list on
> that: (1) Http Support (2) JSon Support. I see the hard part of
> writing cross platform codes but if we use zip and XML libraries what
> is wrong wih picking light http library and may be json library and
> write wrapper around them for Rest API?

I've moved away from using wx for non-GUI elements. A framework should
excel at its core mission, and diverting attention to other things that
are handled by other libraries just thins the available resources for
focusing on its original mission.

I'm using Boost now for a lot of non-GUI portable APIs, like threading.
The wx XML support has been neglected due to it not being part of the
core GUI focus.

This isn't a criticism of the wx development team, but a realistic
recognition that a framework shouldn't be everything but the kitchen
sink without a very good justification.

If you're going to pull in REST, then you need someone to permanently
maintain that. That means the team has to grow in size, and that makes
management more difficult.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Eric Jensen]

Hello Artur,

Friday, January 20, 2017, 7:06:28 PM, you wrote:

>>

>> EJ> Especially under Windows where the Direct2D context is still in an
>> EJ> unusable state (just tested again with the drawing sample).
>>
>> This is bad news, I thought it was in not a too bad shape :-( This is OT
>> here, but please do open bugs for the problems you found if we don't have
>> them already.
>>

AW> Maybe version matters. I have just launched drawing sample with 3.1 (Win
AW> 7) and Direct2D renderer seems to work quite nice for all available screens.
AW> Regards,
AW> AW


Windows 7 here, too. Freshly pulled from GIT a few hours ago.

See screenshot.

Eric




--

[Vadim Zeitlin]

On Sat, 21 Jan 2017 12:21:31 +0200 Teodor Petrov wrote:

TP> On 01/19/2017 01:35 AM, Vadim Zeitlin wrote:
TP> > 1. Do we have any good project ideas?
TP>
TP> What about a project to merge the AUI branch in master? Or reimplement
TP> the most important features/bug fixes from the branch in a merge-able
TP> way?

I don't think it's an appropriate project for a student as it's more about
source code/compatibility management than programming and students are not
typically very expert in this area and, worse, the mentor would still need
to review and retest all the work.

Regards,
VZ

[Vadim Zeitlin]

On Sat, 21 Jan 2017 13:10:17 -0800 (PST) Tobias T wrote:

TT> I would also really like having a single HTTP(s) interface with various OS
TT> specific backends in wxWidgets.

I'm rather ambivalent about this, to be honest. On one hand, it would
definitely be useful to have, for me as a user. OTOH there is already C++
REST SDK and using it in wxWidgets applications is not a problem at all. So
what advantage exactly would we provide? C++ REST SDK requires C++11, of
course, but it seems completely misguided to speak about C++98
compatibility as a real advantage nowadays. And I just don't see much else.

And, of course, as a maintainer, this would create a lot more code to take
care of in the future.

So, on balance, I think we should leave this out of scope of wxWidgets,
otherwise it just risks ending as wxODBC did.

Regards,
VZ

[Vadim Zeitlin]

On Sat, 21 Jan 2017 10:12:29 +0000 (UTC) 'Catalin' via wx-dev wrote:

Cvwd> On Friday, 20 January 2017, 19:12, Vadim Zeitlin wrote:

Cvwd> On Fri, 20 Jan 2017 16:29:08 +0000 (UTC) 'Catalin' via wx-dev wrote:
Cvwd>

Cvwd> Cvwd> Examples of using such a component / system: a long list of static
Cvwd> Cvwd> texts, a long list of image thumbnails.
Cvwd>
Cvwd> > The proper way to do is to do what wxGrid/wxDVC do and not use windows at all and just render everything
Cvwd> > ourselves. BTW, this is what all browsers/rendering engines do too, none of them uses native windows for HTML
Cvwd> > elements.
Cvwd>
Cvwd> That is true, and I actually know that, but it would have been more
Cvwd> comfortable to use the layout already implemented in sizers. Then a
Cvwd> relatively simple "graphic sizer" comes to my mind. It would accept
Cvwd> only text (wxString) and images (i.e. wxBitmap), spacers, stretch
Cvwd> spacers (which would assert if wxFULL_PAINT_ON_RESIZE was not used).
Cvwd> Multi-line text would probably need more work. Layout would be the
Cvwd> same as in sizers.

This is not the first time this idea comes up and there is definitely
something appealing in being able to use familiar sizers API for laying out
custom-rendered things. But for me this means that this is not really about
creating some wxPseudoWindow, but about refactoring sizers API to work with
any objects satisfying some interface implemented by wxWindow and not only
the real windows themselves, doesn't it?

Seen like this, it definitely could be worth doing, and should be also
possible and even relatively simple to do. But I don't know if it's
suitable for a GSoC project for the same reasons as the AUI branch merge
isn't: it's more about refactoring the code than really programming (even
if refactoring is part of programming, of course, I don't think it's the
part most GSoC students would be interested in) and it has a big potential
of breaking something, so doing it would basically be 20% of the work with
the remaining 80% being carefully reviewing it when merging -- and would
need to be done by the mentor.


Cvwd> Cvwd> A second idea would be for another enhancement to wxGrid:
Cvwd> Cvwd> copy-pasting cell data.
Cvwd>
Cvwd> > This does sound useful, but looks a bit too small for 2+ months of work.
Cvwd> > Or am I underestimating the difficulty?
Cvwd>
Cvwd> I don't remember all that much. There was a bug with wxClipboard
Cvwd> under MSW, which unfortunately I don't really recall and never got to
Cvwd> fix it in a decent manner so I could have contributed it, then there
Cvwd> was the wxDF_HTML issue (it is a non-default format and it had to be
Cvwd> registered in a different way than it was attempted by wxW, which
Cvwd> didn't work IIRC), then there was some reverse engineering of the
Cvwd> actual html used in the clipboard for transferring copied data. Then
Cvwd> some functions for getting data in and out of the proper format. But
Cvwd> all this only made it work under MSW, so for other platforms some
Cvwd> more effort might be needed.

It still looks like something relatively trivial to me...

Regards,
VZ

[Vadim Zeitlin]

On Sun, 22 Jan 2017 18:03:12 +0100 Eric Jensen wrote:

EJ> Friday, January 20, 2017, 2:42:05 PM, you wrote:
EJ>

EJ> EJ>> It would be very useful, should be relatively interesting for the
EJ> EJ>> student and has the right size for a GSoC project.
EJ>
EJ> VZ> Yes, I agree with the latter. Would you also be available for mentoring
EJ> VZ> such a project? If so, could you please submit a PR against the web site
EJ> VZ> repository adding it?
EJ>
EJ> Done.

Thanks!

EJ> I didn't know Manolo's last name, so that still needs to be added.

Hopefully I used the right one, please correct me if not,
VZ

[Ulrich Telle]

I fully agree. Nevertheless, such a feature could be provided as a
separate add-on library.

For example, there exists already a component wxCURL
(http://wxcode.sourceforge.net/components/wxcurl/), based on the curl://
library (https://curl.haxx.se/). It is currently not actively
maintained, but it is definitely in a usable status.

I myself use a (slightly patched) version of wxCURL together with
wxWidgets 2.8.12 and 3.1.0 for accessing HTTPS sites from behind company
firewalls with user authentication.

Regards,

Ulrich

[Teodor Petrov]

Agree. But the project could be described as "Implement moving notebook tabs
from one AuiNotebook to another". If I remember correctly this is the most
important improvement in the branch. Another project could be "Implement
better
overlays when moving windows in an AuiManager" (similar to the overlays in
Visual Studio). The mentor could guide the student to the branch to get
inspiration
and ideas. I know the probability of such project starting and even
succeeding is
very small, because almost no one cares too much about AUI or understands it
well enough.

/Teodor

[Catalin]

Hello,

On Thursday, 19 January 2017, 1:35, Vadim Zeitlin wrote:

> We have until Feb 9 to submit our application

There are 2 days left for this.
Will it still happen?

Regards,
C

[Vadim Zeitlin]

On Tue, 7 Feb 2017 09:17:57 +0000 (UTC) 'Catalin' via wx-dev wrote:

Cvwd> On Thursday, 19 January 2017, 1:35, Vadim Zeitlin wrote:
Cvwd>
Cvwd> > We have until Feb 9 to submit our application
Cvwd>
Cvwd> There are 2 days left for this.
Cvwd> Will it still happen?

Sorry, I thought we agreed to apply this year -- so I did do it. Of
course, the real question is whether we're going to be accepted and I'm not
very optimistic about this, but would be glad to be surprised.

In any case, thanks a lot for updating the GSoC web site page and
(keeping :-) reminding about this, this was very helpful!
VZ

[Catalin]

On Tuesday, 7 February 2017, 15:09, Vadim Zeitlin wrote:

> I thought we agreed to apply this year -- so I did do it.

Oh, great, I did't know you already did it.

> the real question is whether we're going to be accepted and I'm not very optimistic about this

Well, the first condition to win the lottery is to play :)

Hoping for surprises,
C

[Vadim Zeitlin]

On Tue, 7 Feb 2017 13:17:43 +0000 (UTC) 'Catalin' via wx-dev wrote:

Cvwd> On Tuesday, 7 February 2017, 15:09, Vadim Zeitlin wrote:
Cvwd>
Cvwd> > I thought we agreed to apply this year -- so I did do it.
Cvwd>
Cvwd> Oh, great, I did't know you already did it.

Unfortunately I can't even give a link to the organization application,
this doesn't seem to be possible (probably on purpose). FWIW I used the
following links in it:

- Ideas List: http://www.wxwidgets.org/gsoc/projects/
- Application Instructions: http://www.wxwidgets.org/gsoc/
- Chat: http://www.wxwidgets.org/support/irc/
- Mailing List: http://www.wxwidgets.org/support/mailing-lists/

so any updates/improvements to the first two would be visible to the people
examining our application.

Cvwd> > the real question is whether we're going to be accepted and I'm not
Cvwd> > very optimistic about this
Cvwd>
Cvwd> Well, the first condition to win the lottery is to play :)

Oh, so this is why I've never won the lottery then...
VZ