RE: [dsdp-ercp-dev] [eRCP] Multiple LCDs enhancement request posted onbu

[Mark Rogalski <rogalski@xxxxxxxxxx>]

You have some convincing points. I have
to disagree about there not being any conflicts between the approaches
though. Both the workbench and individual apps can't control the displays.
There is also a use case for have different apps on different displays,
which the workbench model can support, but I don't think the stand-alone
model can. I see your need in the non eRCP case and am leaning toward providing
support for that. However, we need to figure out how we reconcile the two
schemes. Maybe a best practice note that eRCP workbench apps should not
specify particular screens might be sufficient. I would prefer a stronger
mechanism though. Perhaps somehow by only allowing the creator of the primary
Display to use secondary display objects...

On the MobileDevice.alert() topic...
 The alert is to get the user's attention when the device is in a
pocket or on a table. It should produce an audible or viration alert unless
the device is in silent mode, when perhaps flashing would be used. So there
really is no need to specify a display  to use. (If the device is
closed, only flashing on the external display would make sense.) Once the
user is alerted, they would need to look for where a visual alert is displayed
(dialog, icon, shell, etc.).

Birkler, Jörgen <Jorgen.Birkler@xxxxxxxxxxxxxxxx>
Sent by: dsdp-ercp-dev-bounces@xxxxxxxxxxx

06/29/2007 09:07 AM

Please respond to
DSDP ercp list <dsdp-ercp-dev@xxxxxxxxxxx>

To	"DSDP ercp list" <dsdp-ercp-dev@xxxxxxxxxxx>
cc
Subject	RE: [dsdp-ercp-dev] [eRCP] Multiple LCDs enhancement request posted        onbugzilla #194749

Thank you for your feedback. We
investigated the approach that you outline and also the monitor concept
from SWT.
There are a number of reasons
why they are not sufficient:
* Monitor concept makes assumptions
about the color depth and pixel density (pixels/inch), not true for mobile
phone domain.
* Apps _want_ to control the output
explicitly and have control of what to show on main display and external
display.
* Apps will use eSWT and not necessarily
eRCP 
 
The advantage with the "new
MobileDisplay(screen)" approach is that:
* Resources created can be tied
to the properties of the display(device) (color depth, resolution, etc).
This
 is important for fonts but
also for images, etc.
* Widgets created on a specific
device can be tailored by the implementation to suit the behavior of the
output device;
this is impossible if you only
assign (x,y)=10000,10000 to be the external display.
* Widget might need different
configuration/implementation to suit the characteristics of the output
display. Unless we can tie the Widget to a specific output this is impossible
in the implementation.
* App can have explicit control
of the different output devices
* App can react if an screen goes
away or becomes available.
 
I see no conflict between the
approaches and can be a complement to each other. eRCP can be implemented
using the "new MobileDisplay(screen)" approach or the (x,y)=(10000,10000)
approach.
 
The reason for moving the alert
was so that the implementation can choose the correct implementation alert
method depening on the target. What does does MobildeDevice.alert(1) mean?
Is it on all display, only on main or only on the active? mAybe we need
both?
 
    Jörgen

---

From: dsdp-ercp-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-ercp-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark Rogalski
Sent: torsdag den 28 juni 2007 16:34
To: DSDP ercp list
Cc: dsdp-ercp-dev@xxxxxxxxxxx; dsdp-ercp-dev-bounces@xxxxxxxxxxx
Subject: Re: [dsdp-ercp-dev] [eRCP] Multiple LCDs enhancement request
posted onbugzilla #194749


Thanks so much for contributing ideas for eSWT. I'm happy to see more community
participation. I think your proposed API may be unnecessary though. The
concept of Eclipse views already provides an abstraction for an app to
put content on a different screen. And since views are controlled by an
eRCP workbench, the application does not have to worry about other displays
or where they are located. How displays are used is device specific and
we really don't want apps to have to know this information for each device.
(For instance, on most phones the external display can show something different
than the internal screen, but on some the same content is shown.) This
requires that you have a customized workbench for your device, but then
generic apps can run on the device and take advantage of multiple displays.
 The workbench may have to know something about the eSWT implementation
for the platform. For instance, know that displaying a shell at location
(10000, 10000) puts that shell on the external display.
I also think the alert on a shell in not needed. In most cases, only one
display is active at a time and eSWT should display the alert on the active
display. If both displays are active (think Nintendo DS), then either screen
could be used for alerts. Tying an alert to a Shell is dangerous because
Shells may be in the background or invisible at times and alert behavior
is not obvious in this situation. 

                Mark

Birkler, Jörgen <Jorgen.Birkler@xxxxxxxxxxxxxxxx>
Sent by: dsdp-ercp-dev-bounces@xxxxxxxxxxx

06/28/2007 07:40 AM

Please respond to
DSDP ercp list <dsdp-ercp-dev@xxxxxxxxxxx>

To	<dsdp-ercp-dev@xxxxxxxxxxx>
cc
Subject	[dsdp-ercp-dev] [eRCP] Multiple LCDs enhancement request posted on        bugzilla #194749

Hi eSWT developers, 
I've prepared an enhancement poroposal so that multiple dispays (i.e. LCDs)
can be supported by eSWT. 
Please comment: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=194749

If the approach seem acceptable we will provide more detailed javadoc.

/Jörgen

-------------------------------------------------------------------
Jörgen Birkler
Senior Software Architect - Software Architecture Team
Sony Ericsson Mobile Communications  AB
Nya Vattentornet
Lund, SWEDEN
mailto:jorgen.birkler@xxxxxxxxxxxxxxxx
The information in this e-mail, and attachment(s) thereto, is strictly confidential and may be legally privileged. It is intended solely for the named recipient(s), and access to this e-mail, or any attachment(s) thereto, by anyone else is unauthorized. Violations hereof may result in legal actions. Any attachment(s) to this e-mail has been checked for viruses, but please rely on your own virus-checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications in the matter concerned. If you do not consent to us storing your name and address for above stated purpose, please notify the sender promptly. Also, if you are not the intended recipient please inform the sender by replying to this transmission, and delete the e-mail, its attachment(s), and any copies of it without, disclosing it._______________________________________________
dsdp-ercp-dev mailing list
dsdp-ercp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-ercp-dev_______________________________________________
dsdp-ercp-dev mailing list
dsdp-ercp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-ercp-dev