Closed Bug 331416 Opened 16 years ago Closed 15 years ago
Move toolkit/components/gnome somewhere else
toolkit/components/gnome should not be part of toolkit. It doesn't depend on toolkit at all, and it's quite generic. In particular I want to make my system-proxy patch use it, and my system-proxy patch is app-agnostic. The question is where to move it. The most obvious place is extensions/gnome. We already have extensions/gnomevfs. Brian, what do you think?
sure, any place is fine.
I decided on extensions/gnomeservices. ("extensions/gnome" wasn't good because having one extension name be a substring of another extension name breaks things.) The IDL files can't go in extensions/gnomeservices because they need to be accessible whenever GTK2 is built, even if the gnomeservices component isn't built. So I put them in widget/src/gtk2. So here is a list of CVS copies to be made.
preed, are you doing CVS repository copies these days?
Assignee: roc → preed
Ugh, why extensions/ ? I've been trying to move code out of extensions that wasn't actually going to be an extension. Where does the system-proxy code live? Or, to start over, why is toolkit/ a bad place for this code? toolkit/ is app-agnostic, and we already build parts of it for seamonkey etc.
bsmedberg: Then where should optional toolkit components live? Right now, mozilla/extensions seems to be the best place. roc: I think that extensions/gnomevfs could be merged with the stuff in toolkit/components/gnome.
What does "optional" mean?
I was referring to 'optional' from the point-of-view of applications bundling the toolkit. We have many optional components in toolkit today, and the various apps pick-n-choose components that they wish to bundle. Obviously, some (or all) of that goes away when those apps target xulrunner.
> Where does the system-proxy code live? My current patch has it in toolkit/components/unixproxy, but I was going to move it to extensions/unixproxy. It depends only on the gnome service and netwerk. I've always thought of toolkit as components for XUL applications, and this is a lot lower-level than that. However I'm happy to close this bug as WONTFIX and land my original patch. Please decide amongst yourselves.
Toolkit is not just for XUL apps nowadays, so I'd vote to WONTFIX this.
> I've been trying to move code out of extensions that wasn't actually going to > be an extension If we go down this path, then toolkit is going to become one big grab-bag of independent modules and collect a lot of what's in extensions/ today. Looking at extensions/, these look like candidates for toolkit/: auth cookie gnomevfs help manticore mono permissions pref python schema-validation spellcheck sql tridentprofile typeaheadfind sroaming universalchardet wallet webdav webservices xmlextras xml-rpc Is that going to be OK? I'm a bit concerned that modules which are extensions today might not be extensions in the future, and vice versa, and it would be nice to not have to move them around the tree to keep things consistent.
There are better places for some of these directories > auth netwerk/auth? > gnomevfs netwerk/ ? > help replaced by toolkit help viewer > pref modules/libpref > typeaheadfind Replaced by toolkit TAF > universalchardet intl/universalchardet > webdav > webservices > xmlextras > xml-rpc All belong in content/... and several are built in tier 9 already. > I'm a bit concerned that modules which are extensions today might not be > extensions in the future, and vice versa, and it would be nice to not have to > move them around the tree to keep things consistent. Absolutely. I'm of the opinion that we ought not check anything in under extensions/, instead finding or creating an appropriate module for it. And I have most of the build-config goop in place already to make that possible.
Given those decisions, then the proper place for unixproxy would seem to be netwerk/, but having a netwerk component depend on gnomeservice in toolkit/ doesn't seem good. I guess this particular problem is that we need somewhere to put GNOME platform stuff that's really below both netwerk/ and toolkit/. The closest we have is widget/, but that doesn't seem quite right.
I've also got a dbus component that depends on nothing, implements a netwerk/ interface, but might be extended to implement other non-netwerk stuff. My opinion is hardening that extensions/ is the right place for gnomeservice and dbus. These are optional components that are not needed for Gecko products to function, and they are not strongly associated with another Gecko module. Other Gecko modules need not explicitly depend on them as long as the interfaces they implement live elsewhere. On the other hand, I think it would be reasonable to put unixproxy in netwerk/system/unixproxy. There is still the question of where to put nsIGConfService.idl so that we can access it from netwerk without creating horrid dependencies. My current best idea is to create a new directory xpcom/system for platform-specific, low-level interfaces (not implementations) to components exposing system services. mkaply, would that have served your OS/2 WPS needs?
yeah, that would work. We've actually created a service for this stuff with IDL and the works...
I'm not sure about netwerk/system and xpcom/system yet. Let's get a discussion going in dev-platform :)
A decision has been reached. The IDL is going to xpcom/system. The actual component is going to toolkit/system/gnome.
This is the updated cvsmoves file. These moves can go ahead. Note that the directories toolkit/system and xpcom/system don't currently exist and may need to be created in the repository.
I do wonder why it's called 'cvsmoves' when we really want copies.
16 years ago
Attachment #215978 - Attachment is obsolete: true
16 years ago
Assignee: preed → server-ops
Assignee: server-ops → nobody
Component: Widget: Gtk → CVS: Copy
Product: Core → mozilla.org
QA Contact: gtk → cvs-moves
Version: Trunk → other
ETA on some action on these is 4/28.
Justdave will take care of these cvs moves during the scheduled CVS server outage the evening of 4 May.
Assignee: nobody → justdave
pre-flight sanity check says: destination directory toolkit/system does not exist, will be created destination directory xpcom/system does not exist, will be created If that's a problem you've got about 15 minutes to say so before I make it happen.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Thanks, that's good.
Argh. I stuffed it up. Those files should have landed in toolkit/system/gnome, not toolkit/system. My script in comment #2 was wrong.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
very, very sorry :-(
I'm aiming to hit all these this weekend at some point while everything's offline anyway.
Status: REOPENED → NEW
Status: NEW → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → FIXED
15 years ago
You need to log in before you can comment on or make changes to this bug.