Re: [ve-dev] Approve two bug fixes for 1.0.2

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

So is the choice for whether borders
are shown or not global (applies to all editors) or local (applies to just
the selected editor)  ?  I'd have thought it was on a per-editor
basis, perhaps even persisting with the editor as well as things like split
pane positions and maybe even palette expansion state/customization (once
it's available).  If so then having a single toolbar option that was
a drop down toggle button for "visual effects" could work where
"toggle disabled" means everything loooks purely as it would
at runtime and "toggle enbled" means all of the checked sub options
are applied. 

I agree that if it's global and applies
to all editors then it should be on the Preferences pages.

Jeff - do you see this as being on a
per-editor basis or having global scope ?

Please respond to ve-dev@xxxxxxxxxxx

Sent by:        ve-dev-admin@xxxxxxxxxxx

To:        ve-dev@xxxxxxxxxxx
cc:        
Subject:        Re: [ve-dev] Approve two bug fixes for 1.0.2



... it sounds like the "View" menu option - typically used by applications today for these kind of purposes.   A tool bar should be an optional thing, as it can get busy quite quickly  in some perspectives.
Also, when you use the tooBar/Menu option, it is typically a setting for "the file" (vs. a preference/option that is a global default); something we need to step up and support.


------------
Dr. Gili Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408, tie: 441 6408

Joe Winchester <WINCHEST@xxxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx

10/15/2004 07:25 PM

Please respond to
ve-dev

To	ve-dev@xxxxxxxxxxx
cc
Subject	Re: [ve-dev] Approve two bug fixes for 1.0.2

Jeff, 

It'd be nice as well if it wasn't just border/no border.  Instead
it's more annotated/preview or something more akin to that.  The reason
is that the toolbar can get cluttered so on its own my vote would be a
preference, however a toolbar is good if we make it more generic.  In
one more the user sees the GUI canvas exactly as it does at runtime.  The
other is the GUI canvas with annotations/visual effects or whatever we
decide to call it.  Drawing GEF borders around things like labels
and panels is one visual effect but there could be others.  For example,
we could put the show/hide grid on there too other visual effects like
the error symbols on the figures and others we might come up with in future.

Tthe toolbar button could be called "Visual effects" and has
a drop down list.  Sort of like the JDT editor does for its back and
next and annotations.  This drop down is a check box list and includes
details of each option such as "borders" and "error icons"
and "grid".  These could be individually selectable so the
user can fine control what options they see, and also the overall on/off
of the toolbar in a single clicks sets off all of them, and sets on only
those that are individually selected.  We could even do things like
put the look and feels in the drop down list perhaps with a radio choice
(as these are mutual) 

Does this make sense ?  I might not have explained it very well, but
I'm basically saying toolbar is good and we could think about extending
it to be more powerful. 

Best regards, 

Joe Winchester

Please respond to ve-dev@xxxxxxxxxxx

Sent by:        ve-dev-admin@xxxxxxxxxxx

To:        ve-dev@xxxxxxxxxxx
cc:        
Subject:        Re: [ve-dev] Approve two bug fixes for 1.0.2


I discussed this with Seth yesterday and it does seem like it'd
function much better as a toggle on the toolbar.  I'll see about
implementing this, but it won't be for 1.0.2.

- Jeff


On Fri, 15 Oct 2004 10:23:48 -0400, Rich Kulp <richkulp@xxxxxxxxxx> wrote:
>  
> I thought a little more about it, and I think it actually needs to be a
> toggle on the toolbar. I don't know if someone would want it always off. it
> would be annoying to have to close the editor and change the preference and
> open it again. but that is too much for 1.0.2.
>  
> thoughts anyone?
>  
> Rich
>  
>  
>  
>  Dr Gili Mendel/Raleigh/IBM@IBMUS
> Sent by: ve-dev-admin@xxxxxxxxxxx
>
> 10/15/2004 08:18 AM
>  
> Please respond to
>  ve-dev
>  
>  
> To ve-dev@xxxxxxxxxxx
>  
> cc
>  
> Subject Re: [ve-dev] Approve two bug fixes for 1.0.2
>  
>  
>
>
>  
>  
>  
>
>  We should try and limit defects for 1.0.2 for stability/consistency
> reasons. Though, we should plan for a test pass before we release the 1.0.2
> driver.  This is since our focus (and HEAD) is going to move to the 1.1
> release with breaking changes thereafter.
>  
>  This feature (48554 ) has been asked for multiple times... as a matter of
> fact, it was considered a "bug".   Given the low risk, and the availability
> of a fix from Jeff... I'll vote to let it in.  The UI change is quiet small
> ... doubt that an extra check box will throw a users off to the point that
> we need to wait another release.... This is an open source project, and if
> someone wants something really bad, to the point that they are willing to
> put the time/effort to get the code available, and if it will not impact the
> stability of a delivery, and does not change any semantics... I'll say
> "bring it on":-)
>  
>  
>  ------------
>  Dr. Gili Mendel
>  IBM
>  Software Development
>  RTP Raleigh, NC
>  (919)543 6408, tie: 441 6408
>  
>  
>  
>  Peter Walker/Raleigh/IBM@IBMUS
>  Sent by: ve-dev-admin@xxxxxxxxxxx
>
> 10/14/2004 01:53 PM
>  
>  
> Please respond to
>  ve-dev
>
>  
>  
> To ve-dev@xxxxxxxxxxx
>  
> cc ve-dev@xxxxxxxxxxx, ve-dev-admin@xxxxxxxxxxx
>  
> Subject Re: [ve-dev] Approve two bug fixes for 1.0.2
>  
>  
>  
>  
>
>  
>  
>  
>  Jeff,
>  I would recommend commiting 73117 for the 1.0.2 maintenance build
> (currently HEAD) since it's for critical, blocker bugs. But hold off 48554
> for the 1.1 (or 1.5?) development.work which will be HEAD once we GA 1.0.2.
> The reason for this is this bug is more of an enhancement and affects the UI
> visually, requiring NL and documentation changes.
>  
>  Thanks...
>  
>  Peter Walker
>  -------------------------------------
>  Eclipse JVE Development
>  919-254-1558 - T/L 444, Fax 254-8169, HYSA/501/K107
>  IBM SWG at RTP, 3039 Cornwallis Rd, RTP, NC 27709
>  Lotus Notes: Peter Walker/Raleigh/IBM   Internet: walkerp@xxxxxxxxxx
>  
>  Jeff Myers <myersj@xxxxxxxxx>
>  Sent by: ve-dev-admin@xxxxxxxxxxx
>
> 10/14/2004 11:56 AM
>  
>  
> Please respond to
>  ve-dev
>  
>  
>  
> To ve-dev@xxxxxxxxxxx
>  
> cc
>  
> Subject [ve-dev] Approve two bug fixes for 1.0.2
>
>  
>  
>  
>  
>
>  
>  
>  
>  Greetings all,
>  
>  I've got bug fixes for bugs 48554 and 73117 sitting in my workspace.
>  Can either of these or both be committed into the 1.0.2 stream?
>  
>  My fix for 48554 involves adding a check box to the Visual Editor's
>  preference page that says "Show borders around invisible components"
>  that is checked by default.  Unchecking this box disables drawing
>  outline borders around all edit parts, which makes the VE's design
>  view reflect the runtime view exactly.
>  
>  - Jeff
>  _______________________________________________
>  ve-dev mailing list
>  ve-dev@xxxxxxxxxxx
>  http://dev.eclipse.org/mailman/listinfo/ve-dev
>  
>
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ve-dev