Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

1. On device debugging
2. Documentation on Various BREW file formats such as BCI and purevoice.
3. Some Enhancements for visually appealing Controls. Such as skinning for controls should be provided.
4. Also Transparency level for controls should be controlled by user.
5. A proper framework that will take care of of stacking of windows. This will allow standardisation of most application in the way they handle their own screens.

Anything more ?

Please go on adding to the thread ...

:)
Regards

ShantanuDeo wrote:1. On device debugging
2. Documentation on Various BREW file formats such as BCI and purevoice.
3. Some Enhancements for visually appealing Controls. Such as skinning for controls should be provided.
4. Also Transparency level for controls should be controlled by user.
5. A proper framework that will take care of of stacking of windows. This will allow standardisation of most application in the way they handle their own screens.
Anything more ?
Please go on adding to the thread ...
:)
Regards
1. Already exists, but it requires the device to support IPort
2. Provided to strategic developers on request - contact your developer relations agent
3. Provided in UI Toolkit
4. Don't have any information on this
5. Also assisted by UI Toolkit

ShantanuDeo wrote:1. On device debugging
2. Documentation on Various BREW file formats such as BCI and purevoice.
3. Some Enhancements for visually appealing Controls. Such as skinning for controls should be provided.
4. Also Transparency level for controls should be controlled by user.
5. A proper framework that will take care of of stacking of windows. This will allow standardisation of most application in the way they handle their own screens.
Anything more ?
Please go on adding to the thread ...
:)
Regards
1. Already exists, but it requires the device to support IPort
2. Provided to strategic developers on request - contact your developer relations agent
3. Provided in UI Toolkit
4. Don't have any information on this
5. Also assisted by UI Toolkit

Max,
I wish on-device debugging were really available! "Available" means "in developers' hands and working" "Existing" doesn't do developers any good...
Right now no such solution exists - at least not to my knowledge. The old Sharp-thingie is horribly outdated and I think you can't even find it anywhere any more and everything else is locked away in Qualcomm's super secret paranoia-proof lab vaults.
While I don't care much for ShantanuDeo's other points, on-device debugging is definitely something that should have been at the top of QC's list for the last two years - but evidently wasn't.

Max,
I wish on-device debugging were really available! "Available" means "in developers' hands and working" "Existing" doesn't do developers any good...
Right now no such solution exists - at least not to my knowledge. The old Sharp-thingie is horribly outdated and I think you can't even find it anywhere any more and everything else is locked away in Qualcomm's super secret paranoia-proof lab vaults.
While I don't care much for ShantanuDeo's other points, on-device debugging is definitely something that should have been at the top of QC's list for the last two years - but evidently wasn't.

Devices just have to play catch-up. :mad:

Devices just have to play catch-up. :mad:

API functionalities enhancement. Eventhough there are many on my list, couple of them are,
1. Adding support for asynchronous file write, where you can specify callback function.
2. Exposing JPEG, MP3 and other decoders to application, so that application can provide data and get back decoded data.
3. Adding real support for streaming sound.
4. Sound mixing.

API functionalities enhancement. Eventhough there are many on my list, couple of them are,
1. Adding support for asynchronous file write, where you can specify callback function.
2. Exposing JPEG, MP3 and other decoders to application, so that application can provide data and get back decoded data.
3. Adding real support for streaming sound.
4. Sound mixing.

Some of the tools could do with a couple of enhancements too. For example....
1) The Brew Apploader. Why does it have to attempt to connect 5 times when it failed on its first occurence because i selected the wrong port? Or at least the addition of a cancel button.
2) The brew "Simulator".
a) Can we please make it a proper simulator? So we can actually simulate compiled ARM code.
b) Any chance of better debug output too?
3)The brew Logger.
a) Can we merge the brew apploader and logger into one tool? When your working with a bug on the handset you have to physically close the loader and then load the logger.
b) On that note, why does logging only work properly on 1 or 2 handsets? surely it SHOULD work on them all. Otherwise whats the point of a logging tool?
But otherwise they aren't bad tools.
- Skavenger

Some of the tools could do with a couple of enhancements too. For example....
1) The Brew Apploader. Why does it have to attempt to connect 5 times when it failed on its first occurence because i selected the wrong port? Or at least the addition of a cancel button.
2) The brew "Simulator".
a) Can we please make it a proper simulator? So we can actually simulate compiled ARM code.
b) Any chance of better debug output too?
3)The brew Logger.
a) Can we merge the brew apploader and logger into one tool? When your working with a bug on the handset you have to physically close the loader and then load the logger.
b) On that note, why does logging only work properly on 1 or 2 handsets? surely it SHOULD work on them all. Otherwise whats the point of a logging tool?
But otherwise they aren't bad tools.
- Skavenger

One thing that I think would be nice would be a utility/upgrade to the Brew Resource editor that would let you move resources from one bri to another. Ideally it would just let you copy and paste them or drag them from one BRE window to another. This would be useful for example if you are starting a new project with lots of old resources, or if you are consolidating BRI/BARs.
-Ted

One thing that I think would be nice would be a utility/upgrade to the Brew Resource editor that would let you move resources from one bri to another. Ideally it would just let you copy and paste them or drag them from one BRE window to another. This would be useful for example if you are starting a new project with lots of old resources, or if you are consolidating BRI/BARs.
-Ted

How about a resource editor that can cope with multiple resources outputs for one project? I for one have to have multiple resource bri/brx's for one project because each device has to have different size graphics in it. If we could just have one source file that has n output for different handsets it might may life a little easier...
I.e.
ID STRING Audiovox8900 Nokia3589I
--------------------------------------------------------------------------------------------
IDI_GRAPHIC_TITLE largeIntro.bmp smallIntro.bmp
IDI_GRAPHIC_BACKDROP BackdropLarge.bmp backdropsmall.bmp
Results in....
audiovox8900/resource.bar
nokia3589i/resource.bar
- Skavenger.

How about a resource editor that can cope with multiple resources outputs for one project? I for one have to have multiple resource bri/brx's for one project because each device has to have different size graphics in it. If we could just have one source file that has n output for different handsets it might may life a little easier...
I.e.
ID STRING Audiovox8900 Nokia3589I
--------------------------------------------------------------------------------------------
IDI_GRAPHIC_TITLE largeIntro.bmp smallIntro.bmp
IDI_GRAPHIC_BACKDROP BackdropLarge.bmp backdropsmall.bmp
Results in....
audiovox8900/resource.bar
nokia3589i/resource.bar
- Skavenger.

user barc instead of bri files, then you can do that kind of thing with a preprocess step and theres a lot more you can do with barc than with the gui tool
just expose the JTAG connector on all phones and supply firmware with JTAG support , use a standard JTAG connector across phones, then you don't need an arm simulator , oh and world peace, but sure a real emulator would be cool, of course it'd need firmware for each of the phones to be given out to be truely useful, and theres the rub

user barc instead of bri files, then you can do that kind of thing with a preprocess step and theres a lot more you can do with barc than with the gui tool
just expose the JTAG connector on all phones and supply firmware with JTAG support , use a standard JTAG connector across phones, then you don't need an arm simulator , oh and world peace, but sure a real emulator would be cool, of course it'd need firmware for each of the phones to be given out to be truely useful, and theres the rub

Just a couple of points to note.
BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
JTAG...
If you want a JTAG'd phone unless your good at soldering and are able to open your phone (if it is yours and not borrowed) then you'd have to get one from the handset manufacturer and this is not easy, unless you want to pay a premium.
So for most developers using JTAG is completely out of the question.
I have used a JTAG system in the past and its slow, especially when your trying to write a game that has timers....
- Skavenger.

Just a couple of points to note.
BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
JTAG...
If you want a JTAG'd phone unless your good at soldering and are able to open your phone (if it is yours and not borrowed) then you'd have to get one from the handset manufacturer and this is not easy, unless you want to pay a premium.
So for most developers using JTAG is completely out of the question.
I have used a JTAG system in the past and its slow, especially when your trying to write a game that has timers....
- Skavenger.

Skavenger wrote:How about a resource editor that can cope with multiple resources outputs for one project? I for one have to have multiple resource bri/brx's for one project because each device has to have different size graphics in it. If we could just have one source file that has n output for different handsets it might may life a little easier...
I.e.
ID STRING Audiovox8900 Nokia3589I
--------------------------------------------------------------------------------------------
IDI_GRAPHIC_TITLE largeIntro.bmp smallIntro.bmp
IDI_GRAPHIC_BACKDROP BackdropLarge.bmp backdropsmall.bmp
Results in....
audiovox8900/resource.bar
nokia3589i/resource.bar
- Skavenger.
Now THAT is a good idea! I demand immediate implementation of this! :p
...
please? :D
-Ted

Skavenger wrote:How about a resource editor that can cope with multiple resources outputs for one project? I for one have to have multiple resource bri/brx's for one project because each device has to have different size graphics in it. If we could just have one source file that has n output for different handsets it might may life a little easier...
I.e.
ID STRING Audiovox8900 Nokia3589I
--------------------------------------------------------------------------------------------
IDI_GRAPHIC_TITLE largeIntro.bmp smallIntro.bmp
IDI_GRAPHIC_BACKDROP BackdropLarge.bmp backdropsmall.bmp
Results in....
audiovox8900/resource.bar
nokia3589i/resource.bar
- Skavenger.
Now THAT is a good idea! I demand immediate implementation of this! :p
...
please? :D
-Ted

I have all that and more in a custom BAR editor that friend of mine wrote.
Here's more info on it...
http://brewforums.qualcomm.com/showthread.php?s=&threadid=1792
I've been using it for a year now and would never want to go back.

I have all that and more in a custom BAR editor that friend of mine wrote.
Here's more info on it...
http://brewforums.qualcomm.com/showthread.php?s=&threadid=1792
I've been using it for a year now and would never want to go back.

Skavenger wrote:BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
If you look at the makefile for the resources in the BREW Browser Sample Source Kit, you'll see that the BRC file includes external bitmap files. The include path is then set on the barc command line to include the proper bitmaps for a certain bit depth. This concept could probably be extended to other types of resources.

Skavenger wrote:BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
If you look at the makefile for the resources in the BREW Browser Sample Source Kit, you'll see that the BRC file includes external bitmap files. The include path is then set on the barc command line to include the proper bitmaps for a certain bit depth. This concept could probably be extended to other types of resources.

Quote:
BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
JTAG...
If you want a JTAG'd phone unless your good at soldering and are able to open your phone (if it is yours and not borrowed) then you'd have to get one from the handset manufacturer and this is not easy, unless you want to pay a premium.
barc, thats why i said use a preprocess step, just just run it through the C/C++ preprocessor to switch on what you need or M4 and still only have one file, what skavenger suggested is already available, just needs a little thought, do i need to do all the work for you ;)
jtag, its no where near that bad, you probably had a bad experience or crappy interface, i have a few JTAG enabled devices including brew phones, its all dependant on the interface you get some of them can talk at 100Mb/s most embeded developers work via JTAG , thats what qualcomm uses internally as do most OEM's, if developers can use psx or n64 devboards JTAG isn't an issue.

Quote:
BARC
The brew command line resource compiler is okay it still means you have to have multiple .brc files this time instead of multiple .bri/.brx's, which doesn't solve the problem.
JTAG...
If you want a JTAG'd phone unless your good at soldering and are able to open your phone (if it is yours and not borrowed) then you'd have to get one from the handset manufacturer and this is not easy, unless you want to pay a premium.
barc, thats why i said use a preprocess step, just just run it through the C/C++ preprocessor to switch on what you need or M4 and still only have one file, what skavenger suggested is already available, just needs a little thought, do i need to do all the work for you ;)
jtag, its no where near that bad, you probably had a bad experience or crappy interface, i have a few JTAG enabled devices including brew phones, its all dependant on the interface you get some of them can talk at 100Mb/s most embeded developers work via JTAG , thats what qualcomm uses internally as do most OEM's, if developers can use psx or n64 devboards JTAG isn't an issue.