Home » Language IDEs » ServerTools (WTP) » EclipseXUL initial code submitted
|
| Re: EclipseXUL initial code submitted [message #133397 is a reply to message #133222] |
Wed, 17 August 2005 18:45   |
Eclipse User |
|
|
|
Originally posted by: jens.ja-web.de
This sounds great!
I wonder whether you're aware of this project
http://solid.mozdev.org/index.html?
Why not join forces and get something great going?
Jens
lars gersmann wrote:
> hi guys,
>
> Because of the lack of XUL development tools I created EclipseXUL at
> Sourceforge adding XUL support to Eclipse.
>
> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL Page
> and whole XULRunner Applications), XUL Nature, XUL Perspective, XUL
> Console, Chrome URI Resolution Support, WTP Editor extensions for XUL
> and - last but not least - the debugger.
>
> I submitted the initial code base to CVS (at
> http://www.sourceforge.net/projects/eclipsexul).
>
> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>
> The current CVS Codebase is a fully working Eclipse Extension mainly for
> developing XULRunner based Applications.
>
> The following features are implemented and working :
>
> * XUL Nature
> * XUL Perspective
> * XUL Application Project Wizard
>
> I invested a little more time in the XUL Application Project Wizard.
> The Wizard generates a complete working XULRunner Application
> regarding of your input.
>
> Just create a new XUL Application Project and the generated
> application is ready to run.
> * Chrome URI Resolver (only for XULRunner based Applications right
> now …)
> * The XUL XML Schema is registered by EclipseXSLT
> * UUID Generator
> * Launch Configuration and Launch Shortcut for XUL Application Projects
> * XULRunner Preferences for configuring XULRunner.
>
> The Codebase is stable and ready for use.
>
> many regards,
>
> lars
|
|
| | |
| Re: EclipseXUL initial code submitted [message #133549 is a reply to message #133222] |
Thu, 18 August 2005 11:24 |
 Axel Hecht
Messages: 16
Registered: July 2009 |
Junior Member |
|
|
lars gersmann wrote:
> hi guys,
>
> Because of the lack of XUL development tools I created EclipseXUL at
> Sourceforge adding XUL support to Eclipse.
>
> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL Page
> and whole XULRunner Applications), XUL Nature, XUL Perspective, XUL
> Console, Chrome URI Resolution Support, WTP Editor extensions for XUL
> and - last but not least - the debugger.
>
> I submitted the initial code base to CVS (at
> http://www.sourceforge.net/projects/eclipsexul).
>
> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>
> The current CVS Codebase is a fully working Eclipse Extension mainly for
> developing XULRunner based Applications.
>
> The following features are implemented and working :
>
> * XUL Nature
> * XUL Perspective
> * XUL Application Project Wizard
>
> I invested a little more time in the XUL Application Project Wizard.
> The Wizard generates a complete working XULRunner Application
> regarding of your input.
>
> Just create a new XUL Application Project and the generated
> application is ready to run.
> * Chrome URI Resolver (only for XULRunner based Applications right
> now …)
> * The XUL XML Schema is registered by EclipseXSLT
> * UUID Generator
> * Launch Configuration and Launch Shortcut for XUL Application Projects
> * XULRunner Preferences for configuring XULRunner.
>
> The Codebase is stable and ready for use.
Hi Lars,
I took a closer look now.
Firstly, I'd appreciate if you wouldn't require jdk 1.5. There is a
jface assert replacement, IIRC.
The thing that worries me most right now, your code doesn't have a
license. That makes reading closely a little worrysome for me.
I do have to admit that I hate tabs in source, being mozilla-educated.
Reading patches with tabs is even worse.
If you feel like it, we should talk about merging our efforts. I'm still
not so darn sure about the licensing of the schema (maybe your mail was
in that discussion, though I only see nickolay, I guess).
Currently, the project part of focus is l10n support on my side.
Nickolay created a chrome manifest editor, which I'm somewhat reviewing,
too. (Slacker me, darn). Nickolay and I are both hanging around on
news://news.mozdev.org:119/public.mozdev.solid, btw.
If I only knew why setting up the java tooling on first check-out of
plugins always hangs eclipse for me. :-(
Re the wizard, could you move over to the new style IDs? Something like
project@URL is legal now, that'd obsolete the IID generator.
Axel
|
|
|
| Re: EclipseXUL initial code submitted [message #133650 is a reply to message #133222] |
Thu, 18 August 2005 21:43 |
David Goodenough
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
lars gersmann wrote:
> hi guys,
>
> Because of the lack of XUL development tools I created EclipseXUL at
> Sourceforge adding XUL support to Eclipse.
>
> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL Page
> and whole XULRunner Applications), XUL Nature, XUL Perspective, XUL
> Console, Chrome URI Resolution Support, WTP Editor extensions for XUL
> and - last but not least - the debugger.
>
> I submitted the initial code base to CVS (at
> http://www.sourceforge.net/projects/eclipsexul).
>
> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>
> The current CVS Codebase is a fully working Eclipse Extension mainly for
> developing XULRunner based Applications.
>
> The following features are implemented and working :
>
> * XUL Nature
> * XUL Perspective
> * XUL Application Project Wizard
>
> I invested a little more time in the XUL Application Project
> Wizard. The Wizard generates a complete working XULRunner
> Application regarding of your input.
>
> Just create a new XUL Application Project and the generated
> application is ready to run.
> * Chrome URI Resolver (only for XULRunner based Applications right
> now ?)
> * The XUL XML Schema is registered by EclipseXSLT
> * UUID Generator
> * Launch Configuration and Launch Shortcut for XUL Application
> Projects * XULRunner Preferences for configuring XULRunner.
>
> The Codebase is stable and ready for use.
>
> many regards,
>
> lars
I tried to install this from the update site, and Eclipse (3.1) complained
that there should be a space between the public and system IDs. I am not
sure that this is a problem with EclupseXUL (I have seen it before but I can
not be sure where) but does anyone know how to get around it?
David
|
|
|
| Re: EclipseXUL initial code submitted [message #134073 is a reply to message #133549] |
Mon, 22 August 2005 11:31 |
lars gersmann
Messages: 77
Registered: July 2009 |
Member |
|
|
hi axel,
>
>> hi guys,
>>
>> Because of the lack of XUL development tools I created EclipseXUL at
>> Sourceforge adding XUL support to Eclipse.
>>
>> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL Page
>> and whole XULRunner Applications), XUL Nature, XUL Perspective, XUL
>> Console, Chrome URI Resolution Support, WTP Editor extensions for XUL
>> and - last but not least - the debugger.
>>
>> I submitted the initial code base to CVS (at
>> http://www.sourceforge.net/projects/eclipsexul).
>>
>> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>>
>> The current CVS Codebase is a fully working Eclipse Extension mainly
>> for developing XULRunner based Applications.
>>
>> The following features are implemented and working :
>>
>> * XUL Nature
>> * XUL Perspective
>> * XUL Application Project Wizard
>>
>> I invested a little more time in the XUL Application Project
>> Wizard.
>> The Wizard generates a complete working XULRunner Application
>> regarding of your input.
>>
>> Just create a new XUL Application Project and the generated
>> application is ready to run.
>> * Chrome URI Resolver (only for XULRunner based Applications right
>> now …)
>> * The XUL XML Schema is registered by EclipseXSLT
>> * UUID Generator
>> * Launch Configuration and Launch Shortcut for XUL Application
>> Projects
>> * XULRunner Preferences for configuring XULRunner.
>>
>> The Codebase is stable and ready for use.
>
>
> Hi Lars,
>
> I took a closer look now.
>
> Firstly, I'd appreciate if you wouldn't require jdk 1.5. There is a
> jface assert replacement, IIRC.
i think so. will change that.
>
> The thing that worries me most right now, your code doesn't have a
> license. That makes reading closely a little worrysome for me.
>
thats true for the docs at eclipsexul.sourceforge.net (but as stated
there "the documentation is preliminary and subject of change").
if you download the stuff you will see at the eclipsexul summary page
(http://www.sourceforge.net/projects/eclipsexul) that eclipsexul is
licensed under CPL.
> I do have to admit that I hate tabs in source, being mozilla-educated.
i like tabs because of faster navigation.
in general it doesnt matter for me.
> Reading patches with tabs is even worse.
ack - thats true.
>
> If you feel like it, we should talk about merging our efforts. I'm still
> not so darn sure about the licensing of the schema (maybe your mail was
> in that discussion, though I only see nickolay, I guess).
i think so. i looked into nickolay's source drop and was impressed - i
dint know in depth whats possible using javascript (i think of his
js-server stuff for live editing).
> Currently, the project part of focus is l10n support on my side.
> Nickolay created a chrome manifest editor, which I'm somewhat reviewing,
> too. (Slacker me, darn). Nickolay and I are both hanging around on
> news://news.mozdev.org:119/public.mozdev.solid, btw.
just subscribed (not that much traffic there, where do you talk with
nickolay ?).
>
> If I only knew why setting up the java tooling on first check-out of
> plugins always hangs eclipse for me. :-(
hmm - sounds strange for me...
>
> Re the wizard, could you move over to the new style IDs? Something like
> project@URL is legal now, that'd obsolete the IID generator.
will do that. is that also true for creating xpcom components ? i mean
is it now possible to create xpcom components using project@URL instead
of an uuid ?
where can i find such brand new information ?
>
> Axel
have added most of your suggestions to the bug tracker (see
sourceforge.net/projects/eclipsexul)
many regards,
lars
|
|
|
| Re: EclipseXUL initial code submitted [message #134080 is a reply to message #133650] |
Mon, 22 August 2005 11:35 |
lars gersmann
Messages: 77
Registered: July 2009 |
Member |
|
|
hi david,
> lars gersmann wrote:
>
>
>>hi guys,
>>
>>Because of the lack of XUL development tools I created EclipseXUL at
>>Sourceforge adding XUL support to Eclipse.
>>
>>The EclipseXUL project includes XUL Wizards (for XUL Project, XUL Page
>>and whole XULRunner Applications), XUL Nature, XUL Perspective, XUL
>>Console, Chrome URI Resolution Support, WTP Editor extensions for XUL
>>and - last but not least - the debugger.
>>
>>I submitted the initial code base to CVS (at
>>http://www.sourceforge.net/projects/eclipsexul).
>>
>>EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>>
>>The current CVS Codebase is a fully working Eclipse Extension mainly for
>>developing XULRunner based Applications.
>>
>>The following features are implemented and working :
>>
>> * XUL Nature
>> * XUL Perspective
>> * XUL Application Project Wizard
>>
>> I invested a little more time in the XUL Application Project
>> Wizard. The Wizard generates a complete working XULRunner
>> Application regarding of your input.
>>
>> Just create a new XUL Application Project and the generated
>>application is ready to run.
>> * Chrome URI Resolver (only for XULRunner based Applications right
>>now ?)
>> * The XUL XML Schema is registered by EclipseXSLT
>> * UUID Generator
>> * Launch Configuration and Launch Shortcut for XUL Application
>> Projects * XULRunner Preferences for configuring XULRunner.
>>
>>The Codebase is stable and ready for use.
>>
>>many regards,
>>
>>lars
>
> I tried to install this from the update site, and Eclipse (3.1) complained
> that there should be a space between the public and system IDs.
as noted in
http://orangevolt.com/wordpress/archives/2005/08/17/eclipsex ul-initial-code-submitted/
and
http://orangevolt.com/wordpress/archives/2005/08/18/prelimin ary-eclipsexul-documentationscreenshots-released/
the update site is currently not available.
you have to checkout the source from cvs and run eclipse inside eclipse
right now.
i will create an update site as soon as possible.
> I am not
> sure that this is a problem with EclupseXUL (I have seen it before but I can
> not be sure where) but does anyone know how to get around it?
>
> David
many regards,
lars
|
|
|
| Re: EclipseXUL initial code submitted [message #134132 is a reply to message #134073] |
Mon, 22 August 2005 14:24 |
Axel Hecht
Messages: 16
Registered: July 2009 |
Junior Member |
|
|
lars gersmann wrote:
> hi axel,
>>
>>> hi guys,
>>>
>>> Because of the lack of XUL development tools I created EclipseXUL at
>>> Sourceforge adding XUL support to Eclipse.
>>>
>>> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL
>>> Page and whole XULRunner Applications), XUL Nature, XUL Perspective,
>>> XUL Console, Chrome URI Resolution Support, WTP Editor extensions for
>>> XUL and - last but not least - the debugger.
>>>
>>> I submitted the initial code base to CVS (at
>>> http://www.sourceforge.net/projects/eclipsexul).
>>>
>>> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>>>
>>> The current CVS Codebase is a fully working Eclipse Extension mainly
>>> for developing XULRunner based Applications.
>>>
>>> The following features are implemented and working :
>>>
>>> * XUL Nature
>>> * XUL Perspective
>>> * XUL Application Project Wizard
>>>
>>> I invested a little more time in the XUL Application Project
>>> Wizard.
>>> The Wizard generates a complete working XULRunner Application
>>> regarding of your input.
>>>
>>> Just create a new XUL Application Project and the generated
>>> application is ready to run.
>>> * Chrome URI Resolver (only for XULRunner based Applications
>>> right now …)
>>> * The XUL XML Schema is registered by EclipseXSLT
>>> * UUID Generator
>>> * Launch Configuration and Launch Shortcut for XUL Application
>>> Projects
>>> * XULRunner Preferences for configuring XULRunner.
>>>
>>> The Codebase is stable and ready for use.
>>
>>
>> Hi Lars,
>>
>> I took a closer look now.
>>
>> Firstly, I'd appreciate if you wouldn't require jdk 1.5. There is a
>> jface assert replacement, IIRC.
>
> i think so. will change that.
>
>>
>> The thing that worries me most right now, your code doesn't have a
>> license. That makes reading closely a little worrysome for me.
>>
>
> thats true for the docs at eclipsexul.sourceforge.net (but as stated
> there "the documentation is preliminary and subject of change").
>
> if you download the stuff you will see at the eclipsexul summary page
> (http://www.sourceforge.net/projects/eclipsexul) that eclipsexul is
> licensed under CPL.
Isn't CPL deprecated? All I see in eclipse is EPL now.
I do suggest to use license headers in all files, too.
>> I do have to admit that I hate tabs in source, being mozilla-educated.
>
> i like tabs because of faster navigation.
>
> in general it doesnt matter for me.
>
>> Reading patches with tabs is even worse.
>
> ack - thats true.
And at least for the generated files, I suggest following the mozilla
coding style.
>> If you feel like it, we should talk about merging our efforts. I'm
>> still not so darn sure about the licensing of the schema (maybe your
>> mail was in that discussion, though I only see nickolay, I guess).
>
> i think so. i looked into nickolay's source drop and was impressed - i
> dint know in depth whats possible using javascript (i think of his
> js-server stuff for live editing).
>
>> Currently, the project part of focus is l10n support on my side.
>> Nickolay created a chrome manifest editor, which I'm somewhat
>> reviewing, too. (Slacker me, darn). Nickolay and I are both hanging
>> around on news://news.mozdev.org:119/public.mozdev.solid, btw.
>
> just subscribed (not that much traffic there, where do you talk with
> nickolay ?).
There are old discussions, but we don't really have day-to-day stuff to
talk about. Yet, hopefully.
>>
>> If I only knew why setting up the java tooling on first check-out of
>> plugins always hangs eclipse for me. :-(
>
> hmm - sounds strange for me...
>
>>
>> Re the wizard, could you move over to the new style IDs? Something like
>> project@URL is legal now, that'd obsolete the IID generator.
>
> will do that. is that also true for creating xpcom components ? i mean
> is it now possible to create xpcom components using project@URL instead
> of an uuid ?
>
> where can i find such brand new information ?
Usually, following planet.mozilla.org is good, increasingly,
http://developer.mozilla.org/en/docs should have some, esp the Toolkit
API section is interesting.
And no, we don't support new IDs for components or interfaces.
>
> have added most of your suggestions to the bug tracker (see
> sourceforge.net/projects/eclipsexul)
Hrm. sourceforge. Bugtracker sucks and ever since sourceforge changed
their terms of service, I refuse to open an account there. I actually
made quite some hassle to get mine removed back then. Yep, tough
measure, but I don't buy in to a crappy service that changes his privacy
policy without telling me.
Axel
|
|
|
| Re: EclipseXUL initial code submitted [message #134159 is a reply to message #134132] |
Mon, 22 August 2005 15:14 |
lars gersmann
Messages: 77
Registered: July 2009 |
Member |
|
|
Axel Hecht wrote:
> lars gersmann wrote:
>
>> hi axel,
>>
>>>
>>>> hi guys,
>>>>
>>>> Because of the lack of XUL development tools I created EclipseXUL at
>>>> Sourceforge adding XUL support to Eclipse.
>>>>
>>>> The EclipseXUL project includes XUL Wizards (for XUL Project, XUL
>>>> Page and whole XULRunner Applications), XUL Nature, XUL Perspective,
>>>> XUL Console, Chrome URI Resolution Support, WTP Editor extensions
>>>> for XUL and - last but not least - the debugger.
>>>>
>>>> I submitted the initial code base to CVS (at
>>>> http://www.sourceforge.net/projects/eclipsexul).
>>>>
>>>> EclipseXUL is based in Eclipse 3.1 and Eclipse Webtools 0.7.
>>>>
>>>> The current CVS Codebase is a fully working Eclipse Extension mainly
>>>> for developing XULRunner based Applications.
>>>>
>>>> The following features are implemented and working :
>>>>
>>>> * XUL Nature
>>>> * XUL Perspective
>>>> * XUL Application Project Wizard
>>>>
>>>> I invested a little more time in the XUL Application Project
>>>> Wizard.
>>>> The Wizard generates a complete working XULRunner Application
>>>> regarding of your input.
>>>>
>>>> Just create a new XUL Application Project and the generated
>>>> application is ready to run.
>>>> * Chrome URI Resolver (only for XULRunner based Applications
>>>> right now …)
>>>> * The XUL XML Schema is registered by EclipseXSLT
>>>> * UUID Generator
>>>> * Launch Configuration and Launch Shortcut for XUL Application
>>>> Projects
>>>> * XULRunner Preferences for configuring XULRunner.
>>>>
>>>> The Codebase is stable and ready for use.
>>>
>>>
>>>
>>> Hi Lars,
>>>
>>> I took a closer look now.
>>>
>>> Firstly, I'd appreciate if you wouldn't require jdk 1.5. There is a
>>> jface assert replacement, IIRC.
>>
>>
>> i think so. will change that.
>>
>>>
>>> The thing that worries me most right now, your code doesn't have a
>>> license. That makes reading closely a little worrysome for me.
>>>
>>
>> thats true for the docs at eclipsexul.sourceforge.net (but as stated
>> there "the documentation is preliminary and subject of change").
>>
>> if you download the stuff you will see at the eclipsexul summary page
>> (http://www.sourceforge.net/projects/eclipsexul) that eclipsexul is
>> licensed under CPL.
>
>
> Isn't CPL deprecated? All I see in eclipse is EPL now.
oops - youre right. have to change the license.
> I do suggest to use license headers in all files, too.
>
>>> I do have to admit that I hate tabs in source, being mozilla-educated.
>>
>>
>> i like tabs because of faster navigation.
>>
>> in general it doesnt matter for me.
>>
>>> Reading patches with tabs is even worse.
>>
>>
>> ack - thats true.
>
>
> And at least for the generated files, I suggest following the mozilla
> coding style.
i will think about it.
>
>>> If you feel like it, we should talk about merging our efforts. I'm
>>> still not so darn sure about the licensing of the schema (maybe your
>>> mail was in that discussion, though I only see nickolay, I guess).
>>
>>
>> i think so. i looked into nickolay's source drop and was impressed - i
>> dint know in depth whats possible using javascript (i think of his
>> js-server stuff for live editing).
>>
>>> Currently, the project part of focus is l10n support on my side.
>>> Nickolay created a chrome manifest editor, which I'm somewhat
>>> reviewing, too. (Slacker me, darn). Nickolay and I are both hanging
>>> around on news://news.mozdev.org:119/public.mozdev.solid, btw.
>>
>>
>> just subscribed (not that much traffic there, where do you talk with
>> nickolay ?).
>
>
> There are old discussions, but we don't really have day-to-day stuff to
> talk about. Yet, hopefully.
>
>>>
>>> If I only knew why setting up the java tooling on first check-out of
>>> plugins always hangs eclipse for me. :-(
>>
>>
>> hmm - sounds strange for me...
>>
>>>
>>> Re the wizard, could you move over to the new style IDs? Something like
>>> project@URL is legal now, that'd obsolete the IID generator.
>>
>>
>> will do that. is that also true for creating xpcom components ? i mean
>> is it now possible to create xpcom components using project@URL
>> instead of an uuid ?
>>
>> where can i find such brand new information ?
>
>
> Usually, following planet.mozilla.org is good, increasingly,
> http://developer.mozilla.org/en/docs should have some, esp the Toolkit
> API section is interesting.
>
> And no, we don't support new IDs for components or interfaces.
ok - but this means that the uuid generator is always needed when
creating xpcom components.
to be correct - i can only use the new project@URL id style for
xulrunner apps ?
>
>>
>> have added most of your suggestions to the bug tracker (see
>> sourceforge.net/projects/eclipsexul)
>
>
> Hrm. sourceforge. Bugtracker sucks and ever since sourceforge changed
> their terms of service, I refuse to open an account there. I actually
> made quite some hassle to get mine removed back then. Yep, tough
> measure, but I don't buy in to a crappy service that changes his privacy
> policy without telling me.
what would you suggest - mozdev ?
>
> Axel
regards,
lars
|
|
|
| Re: EclipseXUL initial code submitted [message #134197 is a reply to message #134159] |
Mon, 22 August 2005 16:44 |
Axel Hecht
Messages: 16
Registered: July 2009 |
Junior Member |
|
|
lars gersmann wrote:
<...>
>>>>
>>>> Re the wizard, could you move over to the new style IDs? Something like
>>>> project@URL is legal now, that'd obsolete the IID generator.
>>>
>>>
>>> will do that. is that also true for creating xpcom components ? i
>>> mean is it now possible to create xpcom components using project@URL
>>> instead of an uuid ?
>>>
>>> where can i find such brand new information ?
>>
>>
>> Usually, following planet.mozilla.org is good, increasingly,
>> http://developer.mozilla.org/en/docs should have some, esp the Toolkit
>> API section is interesting.
>>
>> And no, we don't support new IDs for components or interfaces.
>
> ok - but this means that the uuid generator is always needed when
> creating xpcom components.
>
> to be correct - i can only use the new project@URL id style for
> xulrunner apps ?
>
And for extensions. http://developer.mozilla.org/en/docs/install.rdf#id.
>>
>>>
>>> have added most of your suggestions to the bug tracker (see
>>> sourceforge.net/projects/eclipsexul)
>>
>>
>> Hrm. sourceforge. Bugtracker sucks and ever since sourceforge changed
>> their terms of service, I refuse to open an account there. I actually
>> made quite some hassle to get mine removed back then. Yep, tough
>> measure, but I don't buy in to a crappy service that changes his
>> privacy policy without telling me.
>
> what would you suggest - mozdev ?
>
I would suggest merging on mozdev. A big step, I understand, but I
expect things on mozdev to be better exposed to moz hackers, too.
Do you have an account on mozdev already? It really shouldn't be a biggy
from that perspective. If we merge, we may want to start abusing the
wiki [1] a bit more, to stake our claims and see how to integrate the
different parts more. I'm not religious about the name of the result
itself, btw, though I find "solid" a fun name.
Axel
[1] http://wiki.mozilla.org/Solid:Home_Page
|
|
|
| Re: EclipseXUL initial code submitted [message #134359 is a reply to message #134197] |
Tue, 23 August 2005 08:54 |
lars gersmann
Messages: 77
Registered: July 2009 |
Member |
|
|
Axel Hecht wrote:
> lars gersmann wrote:
> <...>
>
>>>>>
>>>>> Re the wizard, could you move over to the new style IDs? Something
>>>>> like
>>>>> project@URL is legal now, that'd obsolete the IID generator.
>>>>
>>>>
>>>>
>>>> will do that. is that also true for creating xpcom components ? i
>>>> mean is it now possible to create xpcom components using project@URL
>>>> instead of an uuid ?
>>>>
>>>> where can i find such brand new information ?
>>>
>>>
>>>
>>> Usually, following planet.mozilla.org is good, increasingly,
>>> http://developer.mozilla.org/en/docs should have some, esp the
>>> Toolkit API section is interesting.
>>>
>>> And no, we don't support new IDs for components or interfaces.
>>
>>
>> ok - but this means that the uuid generator is always needed when
>> creating xpcom components.
>>
>> to be correct - i can only use the new project@URL id style for
>> xulrunner apps ?
>>
>
> And for extensions. http://developer.mozilla.org/en/docs/install.rdf#id.^
got it.
>
>>>
>>>>
>>>> have added most of your suggestions to the bug tracker (see
>>>> sourceforge.net/projects/eclipsexul)
>>>
>>>
>>>
>>> Hrm. sourceforge. Bugtracker sucks and ever since sourceforge changed
>>> their terms of service, I refuse to open an account there. I actually
>>> made quite some hassle to get mine removed back then. Yep, tough
>>> measure, but I don't buy in to a crappy service that changes his
>>> privacy policy without telling me.
>>
>>
>> what would you suggest - mozdev ?
>>
>
> I would suggest merging on mozdev. A big step, I understand, but I
> expect things on mozdev to be better exposed to moz hackers, too.
accepted. for me it doesnt really matter. if you 2 guys think it should
better located at mozdev - its ok for me.
how do we start ?
>
> Do you have an account on mozdev already?
not yet. can i create an account by myself or do you need to do it ?
> It really shouldn't be a biggy
> from that perspective.
> If we merge, we may want to start abusing the
> wiki [1] a bit more, to stake our claims and see how to integrate the
> different parts more.
makes sense for me too.
have just started to enter my personal view about the xul builder.
> I'm not religious about the name of the result
> itself, btw, though I find "solid" a fun name.
hhm - i dont really care about the name. but i have choosen EclipseXUL
because it says nearly 100% about the project :-)
>
> Axel
>
> [1] http://wiki.mozilla.org/Solid:Home_Page
many regards,
lars
|
|
|
Goto Forum:
Current Time: Sat Nov 09 02:36:48 GMT 2024
Powered by FUDForum. Page generated in 0.03815 seconds |
] 
Search
Help
Register
Login
Home
