resync xpfe bindings with toolkit widgets

RESOLVED FIXED

Status

()

RESOLVED FIXED
14 years ago
7 years ago

People

(Reporter: mconnor, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
As part of the seamonkey-on-xulrunner work, we need to resync xpfe's bindings
with toolkit's widgets.  Added benefits to both sides will be picking up fixes
that have occured on one side of the fork or the other.  Right now, 13 are still
synced, not counting a couple with whitespace-only differences, and 15 have
differences to be merged.

As part of the process, we can use relative paths in the xpfe jar.mn to pick up
the toolkit versions of synced files, and cvs remove the xpfe versions.  The
xpfe files will always be there in the attic if we need them for cvs blame etc.

There's some issues to be resolved on the non-code level wrt code review as
well, but that's something that needs some discussion with xpfe and toolkit owners.

The following files are already in sync and we can start with them once the
non-code issues are resolved appropriately:
checkbox.xml, colorpicker.xml, editor.xml, groupbox.xml, menulist.xml,
nativescrollbar.xml, popup.xml, progressmeter.xml, scrollbar.xml, scrollbox.xml,
spinbuttons.xml, splitter.xml, stringbundle.xml
(Reporter)

Updated

14 years ago
Depends on: 282178
(Reporter)

Updated

14 years ago
Depends on: 282179
(Reporter)

Comment 1

14 years ago
radio.xml is just a blank line before a return statement, so that's 14.

Comment 2

14 years ago
Didn't BZ file an identical bug to this one a couple months back?
Somebody unsync'ed colorpicker.xml
Component: XP Toolkit/Widgets → XTF
Component: XTF → XP Toolkit/Widgets
Depends on: 285374
(Reporter)

Updated

13 years ago
Assignee: mconnor → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Depends on: 350221
No longer depends on: 282178

Comment 5

12 years ago
SeaMonkey works fine using the toolkit widgets (code-named "suiterunner"). 

Our intention is to flip the switch very soon and build the trunk suite on toolkit, so that xpfe loses its last big user. 

Improvements that have been done on the xpfe side might still be good to be ported over to their toolkit counterparts so that they aren't lost - porting in the other direction doesn't make sense any more, we'll just let xpfe die without toolkit's improvements ;-)

Could someone sort out the dependencies here that can just be closed out going this direction?

Updated

12 years ago
Depends on: 383936

Comment 6

12 years ago
is there still something in the widgets area that needs to be ported from xpfe to toolkit that is not tracked by bugs in the dependency list of this one? If so, we should file that soon as we'd like to kill xpfe ASAP.
Assignee: jag → nobody
XPFE is dead and all depending bugs are fixed
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 8

7 years ago
Matti, I think Bug 285374 is still open. It's a one line fix. Serge, do you want to take it?
you are right and I need glasses
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
and it's now really fixed :-)
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.