new_window* signals need revamping/substituting for language bindings

NEW
Assigned to

Status

Core Graveyard
Embedding: GTK Widget
16 years ago
5 years ago

People

(Reporter: Mark Crichton, Assigned: blizzard)

Tracking

Trunk
Future
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 years ago
The current implementation of the new_window signal makes writing language bindings for the gtkmozembed widget extremely cumbersome.  A better way to handle this signal is to do a "proper" return of the GtkMozEmbed pointer, rather than stuffing it into space saved for it my the function call.



The easiest way to do this change (and keep people who already use the current API) is to create another set of signals that instead of returning void, return a GtkMozEmbed widget.
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 1

15 years ago
This one doesn't seem to be fixed at all.  Chris, we talked about this a while
back.  Would making a new_window2 signal be the sane thing to do here?
(Assignee)

Comment 2

15 years ago
Yep.
(Reporter)

Comment 3

15 years ago
Created attachment 74975 [details] [diff] [review]
Patch to add new_window2 signal

patch to add new_window2 signal with different semantics.  This version is 
much friendlier to language bindings.

Comment 4

15 years ago
The change doesn't look like it has any obvious problems.  I would probably make
the new marshal function static though -- no need to clutter the symbol table.

Comment 5

15 years ago
Also sounds important. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch

Comment 6

15 years ago
Is this patch going into CVS anytime soon (propably before the 1.0 final 
release)?

Updated

15 years ago
Keywords: mozilla1.0.1

Comment 7

15 years ago
we're not going to hold 1.0.1 for this.
Keywords: mozilla1.0.1 → mozilla1.0.1-

Updated

15 years ago
Keywords: mozilla1.1

Comment 8

15 years ago
Created attachment 87515 [details] [diff] [review]
added NEW_WINDOW2 to gtkmozembedprivate.h

This patch replaces the patch already in here. The given patch didn't compile
with mozilla 1.0.0, mine does (at least with the debian source, but AFAIK the
debinan patches don't change anything here.). The only difference to Marks
patch is that NEW_WINDOW2 is added to the enum of possible signals in
gtkmozembedprivate.h.

It works fine on my machine, tried using debian pygtk 0.6.9-3 and current cvs
pygme (in gnome CVS server).
(Reporter)

Comment 9

15 years ago
Created attachment 109151 [details] [diff] [review]
new_window2 implementation for gtk1 and gtk2

New new_window2 patch.	This has been tested with gtk1 and gtk2.  Hoping this
can actually get included at some point for people working on gtk language
bindings.
Attachment #74975 - Attachment is obsolete: true
Attachment #87515 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Blocks: 92033

Comment 10

15 years ago
The current patch needs the patch from bug 121253 applied.

I know that bug 121253 is already closed, but this is to make clear that the patch doesn't compile using mozilla 1.0 or 1.2 based mozillas.

I also hope that this patch will be accepted soon, to help all pygme users (e. G. http://pykiosk.sourceforge.net/) because it is annoying to tell your users that not only they need a specific beta from mozilla, but they also have to patch and compile it themselves.
Depends on: 121253

Comment 11

14 years ago
retargeting
Target Milestone: mozilla1.0 → Future

Comment 12

13 years ago
Hello? Anyone alive? ...
QA Contact: pavlov → gtk-widget
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.