[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ve-dev] Approve two bug fixes for 1.0.2
|
I imagine it as a per-editor feature. The goal would be to make it
easy to toggle on and off the mode and whatever other visual effects
we show. I like the idea of hiding the warning icons as well.
Unfortunately I don't think showing/hiding the grid would work, as
it's context sensitive to a specific container - you wouldn't want to
show all the grids in the given editor, as that can be a mess with
nested grid bag layouts. Maybe that option would be sensitive to the
selection in the design view and be disabled if a grid isn't
applicable to the selected component's layout.
While on the topic, we may want to consider the choice of the word
"grid" for persistent layout feedback. It works well so far with
null, grid bag and grid layouts by chance, but should be replaced with
a more general term that's applicable to other layouts such as
FormLayout, SpringLayout, TableLayout, JGoodies Forms, etc. Thoughts
on this?
- Jeff
On Mon, 18 Oct 2004 23:59:49 +0100, Joe Winchester <winchest@xxxxxxxxxx> wrote:
>
> 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
>
>
>
>
>
>
>
>
>
>
>
