Any GTK/OS X projects ideas for the GSoC?

[Vadim Zeitlin]

Hi,

I've added another 2 projects to http://www.wxwidgets.org/gsoc/2013/:
"Windows 7 Taskbar" and "Cross Platform Animation" (the latter was already
part of GSoC 2011 but was never finished...). Considering that
"cross platform" in the latter means Windows+OSX (AFAIK there is still no
support for animation in GTK+) and that the former is obviously
Windows-specific, this makes our project list even more unbalanced in
favour of Windows. It would be nice to add some GTK and/or OSX-specific
projects to compensate for this but I don't have any ideas. We've discussed
creating native versions of some generic controls for wxGTK but there
doesn't seem to be enough to do there and I have no idea at all about what
could a student do in wxOSX.

If anybody does have any ideas of interesting/fun/important GTK/OSX
projects, please don't hesitate to submit them as pull requests to
https://github.com/wxWidgets/gsoc-pages (see Bryan's message at
http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/147780 for more
details).

TIA,
VZ

[Marian 'VooDooMan' Meravy]

Greetings,

On 2013-04-03 17:12, Vadim Zeitlin wrote:
> Hi,
>
> I've added another 2 projects to http://www.wxwidgets.org/gsoc/2013/:
> "Windows 7 Taskbar" and "Cross Platform Animation" (the latter was already

just a side note...

I would suggest (call it "fun"ny) placing a plus sign after Windows 7,
like windows 7+... I hope ideas and their implementation for Windows 7
are present in Windows 8 as well and are compatible in their
implementation... but I hope I'm not wrong...

best,
vdm
.

[Eran Ifrah]

On Wed, Apr 3, 2013 at 6:12 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

 Hi,

 I've added another 2 projects to http://www.wxwidgets.org/gsoc/2013/:
"Windows 7 Taskbar" and "Cross Platform Animation" (the latter was already
part of GSoC 2011 but was never finished...). Considering that
"cross platform" in the latter means Windows+OSX (AFAIK there is still no
support for animation in GTK+) and that the former is obviously
Windows-specific, this makes our project list even more unbalanced in
favour of Windows. It would be nice to add some GTK and/or OSX-specific
projects to compensate for this but I don't have any ideas.

Not a UI specific but more related to the completion of the library, I would really like to see SSL support in wxWidgets

Specifically in wxURL / wxSocket

 

We've discussed
creating native versions of some generic controls for wxGTK but there
doesn't seem to be enough to do there and I have no idea at all about what
could a student do in wxOSX.

 If anybody does have any ideas of interesting/fun/important GTK/OSX
projects, please don't hesitate to submit them as pull requests to
https://github.com/wxWidgets/gsoc-pages (see Bryan's message at
http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/147780 for more
details).

 TIA,
VZ

--

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

wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org

[Vadim Zeitlin]

On Wed, 3 Apr 2013 19:07:58 +0300 Eran Ifrah wrote:

EI> Not a UI specific but more related to the completion of the library, I
EI> would really like to see SSL support in wxWidgets
EI> Specifically in wxURL / wxSocket

Call me too picky as I keep asking for ideas and then discarding them, but
I'd really prefer to not do this at all. There are other libraries with SSL
support and what we really need to do is to allow to use them from wx
applications, notably by making it easy to integrate them with the main
event loop. But adding SSL support to wxSocket itself would just saddle us
with more unmaintainable code and I'd rather avoid this.

Regards,
VZ

[Hans Mackowiak]

I will do more native gtk controls, more native ones, more features to
existing ones, maybe also patches to gtk itself because some features
are hidden currently from us
(okay i can write around but its still not nice from gtk)

i also thought about how to make the new ones in generic too for the
other Ports

we could also use GStreamer as/in wxSound as bigger Project
(i don't know if MediaCtrl can do that, and it might be also to big for me)


the bad thing is that i am not a Student, so i cant practice at gsoc right?


PS: while i am working in the wxGTK stuff, is there a method that wraps
an gtkWidget into the right wxWindow?
(maybe with remembering the created wxWindow?) or would it be good to
make such a method?


Hanmac

[Manolo]

A useful job: Try to make wx in Ubuntu 12 fails as much as possible.

This sounds strange for GSoC (this job is not about coding at all).
But I find two good goals:
* The student would improve a lot his skills with GTK, looking at
both wx and gtk code to figure out how things work.
* Vadim will be slightly discharged of fighting Ubuntu.

Regards,
Manolo

[Igor Korot]

Hi,
I think iOS port is in compilable state right now, at least thru the XCode.

Why not make a GSoC to compile this from the terminal and add more

controls to it?

At least this project will help the person with not just wxWidgets but

something else (iOS/XCode/Apple dev tools).

It would be nice to have wxAndroid at least compile right now, but

I guess I am dreaming right now... ;-)

Thank you.

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

[Vadim Zeitlin]

On Wed, 03 Apr 2013 22:14:07 +0200 Manolo wrote:

M> A useful job: Try to make wx in Ubuntu 12 fails as much as possible.

GSoC projects must be about programming (they can include some amount of
testing/documentation but not as the major part).

M> This sounds strange for GSoC (this job is not about coding at all).
M> But I find two good goals:
M> * The student would improve a lot his skills with GTK, looking at
M> both wx and gtk code to figure out how things work.
M> * Vadim will be slightly discharged of fighting Ubuntu.

I'm sure Ubuntu will be able to break things faster than we can fix them...
VZ

[Vadim Zeitlin]

On Wed, 3 Apr 2013 13:19:18 -0700 Igor Korot wrote:

IK> I think iOS port is in compilable state right now, at least thru the XCode.
IK> Why not make a GSoC to compile this from the terminal and add more
IK> controls to it?

I don't know if you looked at http://www.wxwidgets.org/gsoc/2013/ but you
probably should.

IK> It would be nice to have wxAndroid at least compile right now

See above.
VZ

[Vadim Zeitlin]

On Wed, 03 Apr 2013 21:27:30 +0200 Hans Mackowiak wrote:

HM> we could also use GStreamer as/in wxSound as bigger Project
HM> (i don't know if MediaCtrl can do that, and it might be also to big for me)

wxMediaCtrl for Unix is entirely built on top of GStreamer.

HM> the bad thing is that i am not a Student, so i cant practice at gsoc right?

No, you must have a student card to be able to participate in it.

HM> PS: while i am working in the wxGTK stuff, is there a method that wraps
HM> an gtkWidget into the right wxWindow?

No, there is wxNativeContainerWindow but it's for top level windows only.
As the comments in wx/nativewin.h say, we did want to have wxNativeWindow
that could be used to wrap an arbitrary HWND/GtkWidget but this was never
even started.

Regards,
VZ

[Hans Mackowiak]

Am 04.04.2013 01:30, schrieb Vadim Zeitlin:

On Wed, 03 Apr 2013 21:27:30 +0200 Hans Mackowiak wrote:

HM> we could also use GStreamer as/in wxSound as bigger Project
HM> (i don't know if MediaCtrl can do that, and it might be also to big for me)

 wxMediaCtrl for Unix is entirely built on top of GStreamer.

Okay i thought that MediaCtrl is more for Videos than for Audiofiles, but i need to test that.
PS: there is an new Gst version (1.0), we do not support yet

HM> the bad thing is that i am not a Student, so i cant practice at gsoc right?

 No, you must have a student card to be able to participate in it.

HM> PS: while i am working in the wxGTK stuff, is there a method that wraps 
HM> an gtkWidget into the right wxWindow?

 No, there is wxNativeContainerWindow but it's for top level windows only.
As the comments in wx/nativewin.h say, we did want to have wxNativeWindow
that could be used to wrap an arbitrary HWND/GtkWidget but this was never
even started.

 Regards,
VZ

i thought about something like:

wxWindow* createWidget(GtkWigdet*) //this creates an new wxWindow out of the gtkWidget

wxWindow* wrapGtkwidget(GtkWigdet*) // this returns the wxWindow that is binded at the gtkWidget (via set_data) or create an new one

void bindGTypeToWxClass(GType,wxClassInfo) //that is used so the create function knows that it should use wxButton for an GtkButton widget

the createWidget function may not working as i thought, but thats may ideas yet



i may need that for ScaleButton:

GtkWidget *         gtk_scale_button_get_popup          (GtkScaleButton *button);
GtkWidget *         gtk_scale_button_get_plus_button    (GtkScaleButton *button);
GtkWidget *         gtk_scale_button_get_minus_button   (GtkScaleButton *button);

Hanmac

[Vadim Zeitlin]

On Thu, 04 Apr 2013 10:01:44 +0200 Hans Mackowiak wrote:

HM> i thought about something like:
HM>
HM> wxWindow* createWidget(GtkWigdet*) //this creates an new wxWindow out of
HM> the gtkWidget
HM>
HM> wxWindow* wrapGtkwidget(GtkWigdet*) // this returns the wxWindow that is
HM> binded at the gtkWidget (via set_data) or create an new one

I really think it should be a separate class which would be created using

new wxNativeWindow(wxparent, gtkwidget);

Why not?

HM> void bindGTypeToWxClass(GType,wxClassInfo) //that is used so the create
HM> function knows that it should use wxButton for an GtkButton widget

I don't believe it's realistic to be able to create objects of specific
classes from native widgets with the current wx API. Of course it would be
nice to be able to do this but this almost certainly will never work
reliably. Maybe we can add ad-hoc functions to specific classes, such as
the existing wxTextCtrl::AdoptAttributesFromHWND() in wxMSW. But I don't
like the idea of adding a general function which will work only in a
handful of cases.


HM> i may need that for ScaleButton:

I have trouble understanding what this one does and failed to find any
screenshots for it, could you please explain?

Thanks,
VZ

[Hans Mackowiak]

Am 04.04.2013 13:20, schrieb Vadim Zeitlin:
> On Thu, 04 Apr 2013 10:01:44 +0200 Hans Mackowiak wrote:
>
> HM> i thought about something like:
> HM>
> HM> wxWindow* createWidget(GtkWigdet*) //this creates an new wxWindow out of
> HM> the gtkWidget
> HM>
> HM> wxWindow* wrapGtkwidget(GtkWigdet*) // this returns the wxWindow that is
> HM> binded at the gtkWidget (via set_data) or create an new one
>
> I really think it should be a separate class which would be created using
>
> new wxNativeWindow(wxparent, gtkwidget);
>
> Why not?
>
> HM> void bindGTypeToWxClass(GType,wxClassInfo) //that is used so the create
> HM> function knows that it should use wxButton for an GtkButton widget

It would be possible with mapping GType objects to wxClassInfo Objects
and then using the ClassInfo->CreateObject function,
with that we have an empty wxWindow* of the currect wxWindow type
where we could set the m_widget attribute

i did similar with my wxWidgets ruby binding, so when i get an
wxWindow*, i uses the ClassInfo from it
to get the best fitting ruby class for it. for sample when the correct
Class is not binded, it trys the parent class)

PS: i can manage that the gtk widget remembers an already created wx
window, thats why an

wxNativeWindow::New(wxparent, gtkwidget);

would be maybe better, but its not such as cool as windows of the
correct wx class

> I don't believe it's realistic to be able to create objects of specific
> classes from native widgets with the current wx API. Of course it would be
> nice to be able to do this but this almost certainly will never work
> reliably. Maybe we can add ad-hoc functions to specific classes, such as
> the existing wxTextCtrl::AdoptAttributesFromHWND() in wxMSW. But I don't
> like the idea of adding a general function which will work only in a
> handful of cases.
>
>
> HM> i may need that for ScaleButton:
>
> I have trouble understanding what this one does and failed to find any
> screenshots for it, could you please explain?

https://developer.gnome.org/gtk3/unstable/GtkScaleButton.html
its a button like that:
https://developer.gnome.org/gtk3/unstable/volumebutton.png

it has getter methods for the buttons so we could maybe modify the icons
if we want
or changing other functions of the buttons
but ScaleButton was only a sample, it may be interesting for other
native gtk widgets too
> Thanks,
> VZ


i hope i did not annoy you with my ideas.

Hanmac

[Vadim Zeitlin]

On Thu, 04 Apr 2013 13:56:18 +0200 Hans Mackowiak wrote:

HM> It would be possible with mapping GType objects to wxClassInfo Objects
HM> and then using the ClassInfo->CreateObject function,
HM> with that we have an empty wxWindow* of the currect wxWindow type
HM> where we could set the m_widget attribute

I understand that it would be possible, in principle, but as I tried to
explain in my previous message, I have serious doubts about whether this is
going to really work in practice. I.e. creating the widget would succeed,
but some class-specific methods might not work afterwards because some
initialization done in wxFoo::Create() wasn't performed. It looks much
safer to just wrap the widget inside a generic wx(Native)Window.

HM> > HM> i may need that for ScaleButton:
HM> >
HM> > I have trouble understanding what this one does and failed to find any
HM> > screenshots for it, could you please explain?
HM> https://developer.gnome.org/gtk3/unstable/GtkScaleButton.html
HM> its a button like that:
HM> https://developer.gnome.org/gtk3/unstable/volumebutton.png

This is a button?? Someone must have changed the meaning of this word
while I wasn't looking...

HM> i hope i did not annoy you with my ideas.

No, absolutely not, sorry if I gave you such impression (completely
inadvertently if I really did). I agree that it would be nice to be able
wrap arbitrary native widgets, there will always be some GTK+ widgets that
won't be supported by wx. I just think that, realistically, wrapping them
should be used to be able to use them alongside normal wx controls in the
dialogs and such, so basically we just need to be able to position/show/
enable them correctly. If we could have wxNativeWindow implementation
allowing to do this, it would be already great.

Regards,
VZ

[Hans Mackowiak]

Am 05.04.2013 13:30, schrieb Vadim Zeitlin:
> On Thu, 04 Apr 2013 13:56:18 +0200 Hans Mackowiak wrote:
>
> HM> It would be possible with mapping GType objects to wxClassInfo Objects
> HM> and then using the ClassInfo->CreateObject function,
> HM> with that we have an empty wxWindow* of the currect wxWindow type
> HM> where we could set the m_widget attribute
>
> I understand that it would be possible, in principle, but as I tried to
> explain in my previous message, I have serious doubts about whether this is
> going to really work in practice. I.e. creating the widget would succeed,
> but some class-specific methods might not work afterwards because some
> initialization done in wxFoo::Create() wasn't performed. It looks much
> safer to just wrap the widget inside a generic wx(Native)Window.

I need to test it, if it works or not currently i cant tell,
and if it does not work, then we maybe add some
CreateFromNative(GtkWidget *)
Function into wxWindow so we could react to that case

> HM> > HM> i may need that for ScaleButton:
> HM> >
> HM> > I have trouble understanding what this one does and failed to find any
> HM> > screenshots for it, could you please explain?
> HM> https://developer.gnome.org/gtk3/unstable/GtkScaleButton.html
> HM> its a button like that:
> HM> https://developer.gnome.org/gtk3/unstable/volumebutton.png
>
> This is a button?? Someone must have changed the meaning of this word
> while I wasn't looking...

its like a Button with a speaker icon .. and when you press the button,
the scale apears.
similar to an MenuButton where an ContextMenu Appears when you press it

> HM> i hope i did not annoy you with my ideas.
>
> No, absolutely not, sorry if I gave you such impression (completely
> inadvertently if I really did). I agree that it would be nice to be able
> wrap arbitrary native widgets, there will always be some GTK+ widgets that
> won't be supported by wx. I just think that, realistically, wrapping them
> should be used to be able to use them alongside normal wx controls in the
> dialogs and such, so basically we just need to be able to position/show/
> enable them correctly. If we could have wxNativeWindow implementation
> allowing to do this, it would be already great.
>
> Regards,
> VZ

Yeah we will see what the future will bring.