Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CMainTab ui
So we ok reversing fields? And adding optional in label?
Me changing this in abstract main class will affect all product using it. And it hard to do a good job there because all internal details of this page is API.
There are few options
- I don't do anything in CDT and just change our product
- I change current AbstarctMain tab with some ugly hacks to not break API
- I create another AbstractMain2 and deprecated existing one but leave old one as is

Regarding projectless, ignore my statement that it does not work in cdt, I just testing something something else. Default launch config allows it, but it also disables ALL validation
of project and path which I think is really not good. Because if there is mistake there you will get an ugly error in "final launch sequence", If you do a new tab, I can add
more granular validation rules, i.e.
- check that project is empty OR exists and open
- check that binary exists (in workspace or outside)

In general I think we need more due diligence when committees changing UI, It is hard to understand what ui looks like by doing reviews. If somebody would change common UI
I would suggest to post mockups/screenshots on this list so people can reviews prior to getting into stage where is too late to change (like right now)


On Thu, Oct 23, 2014 at 9:56 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

It also always bothered me to have the Binary above the project.  I believe that in bug 285904 [1], when adding the control to build-before-launch, the idea was to keep the project field and the build before launch fields next to each other, so the project field was moved down.  This was in CDI at the time.

 

DSF-GDB at that time had the project field at the top because it seemed more user-friendly.  In bug 285907 [2], we united the CDI and DSF launches somewhat and for the sake of consistency, we move the project box lower.

 

I still think the other way around is nicer though.

If we can agree on it, I suggest we move the project box at the top.

Also, to address Elena’s point about project-less debugging, how about we put some text above the project box saying “it can be left empty” or maybe simply putting “(optional)” would be nice.

 

Ø  but this workflow is not even supported in default cdt ui

 

I’m not sure what you mean by the above?  Project-less debugging should be supported in most cases in DSF (not CDI though).

 

 

[1] http://eclip.se/285904

[2] http://eclip.se/285907

 

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
Sent: Thursday, October 23, 2014 8:16 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] CMainTab ui

 

I was brought up few times. I am not sure what is reasoning for the original design. Technically binary can be selected without a project outside of workspace, but this workflow is not even supported in default cdt ui

 

On Thu, Oct 23, 2014 at 7:26 AM, Rafael Peria de Sene <rpsene@xxxxxxxxxxxxxxxxxx> wrote:


Regarding usability. When creating a new launcher, we need first select the project and then select the binary, which does not follow the UI organization. What if we change the order of the C/C++ Application  and Project fields ?

 

On 10/22/2014 12:28 PM, Alena Laskavaia wrote:

CAbstractMainTab because all code is there

 

On Wed, Oct 22, 2014 at 10:19 AM, Mikhail Khodjaiants <mikhailkhod@xxxxxxxxxxxxxx> wrote:

Are you planning to modify CAbstractMainTab or a particular CMainTab (CDI or DSF)?



On 22/10/2014 9:57 AM, Alena Laskavaia wrote:

I would like to get rid of extra checkbox in CMainTab ui for build config selector

called "Select configuration using 'C/C++ Application'" and move it to Combo instead

This is how it looks now
…

What I am proposing is this:

So "Auto" in this case is same choice as previous checkbox but it uses less space
and less confusing

It also by discretion of the launch config delegate to interpret this value and pick

configuration based on some other logic (rather then application path only)

Thoughts?

(Note: this button is API unfortunately, so I am planning to keep it but make invisible,
programmatic logic of enabling/disabling it will be supported)

​

​

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 

 

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top