|
ok... let me return to my original comment
:)
by default mtj runtime will never have any vendor specific
page on the jad editor (at least this is the current design). the only place
that it will appear would be in a nokia IDE that distribute mtj and only if
nokia decide to implement the jad editor extension point and add their own page.
in this scenario, maybe it is not bad that the nokia page is shown with a nokia
sdk and, if the user decide to use the same nokia IDE to develop to motorola,
the page will not be shown (actually the page is not even in that
distribution :)).
so i think that probably those changes that we are
discussing make more sense only if we decide to move the vendor specific pages
to MTJ runtime and maintain that code inside MTJ. does that make sense
to everyone?
:)
gep
Perhaps it is time to add some new UI to control the JAD editor?
A preference page that lists the available pages and allows them to be
turned on and off? For instance, if I never want to make vendor-specific
changes, I could go into the preferences and deselect those pages? Even
better would be if the pages could be closed from the editor and then reenabled
from the preferences. That would solve these issues because it would be an
explicit action on the part of the user.
On Aug 5, 2008, at 6:36 AM, Paula Gustavo-WGP010 wrote:
hi gang,
the problem is that the vendor that diego mentioned is
not the device manufacturer. this field on the jad is the midlet suite
developer (like gameloft, EA games, etc.). since that, i don't think that we
make the nokia, mot, etc pages context sensitive based on this
information.
:)
gep
Hi, I think Diego's suggestion that make the vendor specific page be context
sensitive can avoid the confusion Craig
described, need we do like that? Best Regards
Gang(Allen) Ma
Hi everyone, Maybe we can have a
4th option. We could set the vendor specific page to be context
sensitive to the attributes available in the Application Descriptor.
For instance, if a Motorola or Nokia vendor attribute is
in the Application Descriptor, we add the vendor page that can
handle that attribute. If the attribute is unknown to any vendor that
implemented the venderSpecJADAttributes Extension Point it can
be displayed in the User Defined page We
could also add an action Add Vendor Specific JAD Attribute that would
open a list of all Vendor Specific JAD Attributes, and after the user select
the ones he want, the vendor pages are displayed automatically in the
editor. Regards Diego
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
On Behalf Of Paula Gustavo-WGP010
Sent: Monday, August 04,
2008 11:04 AM
To: Mobile Tools for The Java Platform mailing
list
Cc: dsdp-mtj-dev-bounces@xxxxxxxxxxx
Subject:
RE: [dsdp-mtj-dev] The new JAD editor extension point hi craig,
actually it is really nice to have you
very active on the list. about the jad
editor... actually I committed the code on svn without any of the extensions
implementations. all extensions implementations (nokia and mot) are on MTJ
examples (just to give an idea on how to use the extension). so by default the
user will not see any vendor specific page on MTJ runtime / sdk.
the original idea is that each vendor would be able to pack
MTJ with its own extensions and provide an environment that is suppose to
target only its own devices. i see three options 1- keep this original idea (mtj runtime all not shown any
vendor specific page) 2- move
nokia and mot specific extensions to MTJ runtime and keep current code (mtj
runtime will show nokia / mot specific pages, based on current SDK)
3- move nokia and mot specific
extensions to MTJ runtime and change code to shown all vendor specific pages
(mtj runtime will show both nokia and mot pages) i tend to like current solution designed and implemented by gang, but
i'm open to change my mind. :)
gep
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gang.Ma@xxxxxxxxxx
Sent:
domingo, 3 de agosto de 2008 22:48
To: Mobile Tools for The Java
Platform mailing list
Cc: Mobile Tools for The Java Platform mailing
list; dsdp-mtj-dev-bounces@xxxxxxxxxxx
Subject: Re: [dsdp-mtj-dev]
The new JAD editor extension point
Hi Craig,
In the scenario you described, the
Motorola attributes will be shown on the User Defined page, and he/she can
change them there. If he/she switches back to Motorola SDK, the defined
Moto-specific attributes will still be shown on the Motorola page, and the
nokia-specific attributes will be shown on the User Defined page.
Is
it ok for that?
Thanks!
Best
Regards
Gang(Allen) Ma
email: gang_ma@xxxxxxxxxx
I apologize to everyone for the email "spam" today. That's
what happens
when I do all of my MTJ work in one marathon
session!
I took a look at the new JAD editor extension point
functionality today
and I'm good with the code. I am a bit concerned
about the ability to
configure a vendor-specific filter for the pages
though. Imagine a user
scenario that looks like this:
-
Developer starts by using a Motorola-based SDK, which causes the
Moto-specific JAD editor page(s) to be added to the editor.
- Developer
configures some Moto-specific JAD attributes using the
vendor-specific
editor page(s)
- Developer switches to a Nokia-based SDK, which causes the
Nokia-specific editors page(s) to be added the Moto pages to be
*removed*
- Developer alters the Nokia specific attributes and wants to
make a
change to the Motorola attributes as well... *but can't find
them*
While I understand the idea of not forcing the user to see pages
that
don't apply for the current device, it feels to me like the pages
should
be shown no matter what if there are vendor-specific attributes
that
have been altered. One option is to always show all pages.
The other
is to show pages that apply to the current SDK *and* those
that have
been previously shown.
I'd appreciate
thoughts.
Thanks,
Craig
_______________________________________________
dsdp-mtj-dev
mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev
mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev
mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
|
