- launch bar launch config was not handling add of another launch config
correctly - it was just resetting itself to handle new LC. This cannot
really be done because this dialog is bound to launch group and new lc
may not be part of it and may not even support the mode current dialog
is in. Also that make missyncronization between LC stored in parent and
LC stored in getTabViewer which can cause other nasty problems.
So let parent handle adding (which only handles locatio change) and for
duplication we just open a new dialog and close current one.
Change-Id: I2dde5c3af26d901d1f4b18cad84a83a9857a6ca9
Turns out to be pretty easy, just check the config for each launch
and stop the ones that match the active config.
Change-Id: Ib74a31405382b2d1996b257f7e8ad1d85a23e6c6
services
- if you select target for given launch config and restart IDE
it is not persistent, because it queries remote services and
it has not been set. Moving setting of target in the correct place
Note: if launch config is not created yet it would not be create
and mapping would not be set but it would be persisted by launch bar
itself
- also added protection against null listener
Change-Id: I41f8651ba2251ca9f841450fc1f511643bfde681
- prevent events dispatch during initialization of launch bar manager
- also fix case when connection is renamed - we don't need to remove it
Change-Id: I8ba5938afd21c9b2459563cd9e3385fb9a69f673
in last patch I did not actually remove setting active
config from configSelector - it should not set it, but
it will be set automatically when config is saved.
Change-Id: Idcb84d2d71567f1e60cb452fb4df15ed962dded6
mode
* added API for setting mode and target without changing active
descriptor
* used this API in the config selector to set the mode
* added guard against mismatched mode
Change-Id: I58da4aac12950c21192385820683623f9e939786
Signed-off-by: Alena Laskavaia <elaskavaia.cdt@gmail.com>
- also mocked another target so it does not always test local one
Change-Id: Idf59342aac75bf5c92c5ca63870eade760065f70
Signed-off-by: Alena Laskavaia <elaskavaia.cdt@gmail.com>
- restored test module in pom
- fixed tests - xml tag was renamed
- fixed tests - stub functionality that rely on o.e.remote
- fixed NPE when accesssing osname from LaunchTargetTypeInfo
- added guards when calling into user defined classes
- added more comments in java docs
- restored original launch bar tests
- current provider won't get notified when lc is removed, need to fix
more
Change-Id: I15f1a30e9f965ad5c84bdc51238ef129dc314450
Signed-off-by: Alena Laskavaia <elaskavaia.cdt@gmail.com>
- added command to open config selector (unbound now)
- refactored common code to edit config (move into edit config command)
- removed unused includes
- changed wording on other launch bar command for consistency
Change-Id: I9af26cc307cfde4e63d8caa3822a169f42638ef3
ILaunchTarget is removed and replaced with IRemoteConnection. You
still have to declare a launch target type to point at a connection
type. It uses os and arch to help decide what toolchains to use for
builds.
Change-Id: I8f21b4e5043ccd8af85be91c643f58ad301c3ac4
Not sure why this stuff was on master anyway. It was supposed to be
on the oeremote branch. At any rate, I've started to contribute the
new API to o.e.remote properly so this is no longer needed.
Change-Id: I83409423ee5d5ad1295efadabb9d686b4d0fce4f
- fixed issues when list is not drawn properly
- fixed that Esc does not work to close pop up sometimes
- fixed filtering for list with edit button
- fixed layout issues when only one item in the list and filter becomes
visible (filter is disabled in this case)
Change-Id: I562f12df8326b4efecf75150b57b699c53d398da
when launch descriptor (and other objects) are changed
using API it can create event storm which leaves control
changing rapidly. To prevent that added X ms delay
if API is used to change launch bar ui (or during initialization)
Change-Id: Ic02587cbd89c754abd6020cac2754e971ad50a37
- added ability to filter by typing in selector pop-up
- refactored list part of selection in its own components which is kind
of list viewer
- filter is visible by default if we have more than 7 elements in drop
down
- filter become visible if user start typing, even if it was not visible
originally
- moving storing of history size into the list viewer itself
- hooked up proper focus support and keyboard traversal
- modified CButton so we can re-use it for Edit button
of selectors and list items
- when filtering is activated history list is no longer available
Change-Id: I2057ad658f5a5c9f8fbce203748d26d7e4b14dd6
launch element drop down has hardcoded list of 3 elements
of recent history, sometimes it is too many, sometimes not enought.
added sash so user can resize it
save this as preference, but no ui to edit this preference in pref pages
for now
