Skip to Content.
Sympa Menu

texmacs-users - Re: [TeXmacs] Graphics mode issues

Subject: mailing-list for TeXmacs Users

List archive

Re: [TeXmacs] Graphics mode issues


Chronological Thread 
  • From: Joris van der Hoeven <address@hidden>
  • To: address@hidden
  • Subject: Re: [TeXmacs] Graphics mode issues
  • Date: Fri, 11 Nov 2005 11:31:19 +0100

On Thu, Nov 10, 2005 at 11:24:03AM +0100, Alvaro Tejero Cantero wrote:
> > A simple and doable solution would be to add a message showing what each
> > button function in the status line. For example:
> >
> > l: move | m: copy | r: delete
>
> maybe an extra line in the minibuffer when graphics are activated, if
> there is no place. Or might be just change the icons in the icon bar to
> bear the l, m, r superimposed.

I think that we do have *some* space on the status bar.
Indeed, the usual stuff (style properties + context) doesn't need
to be displayed in graphics mode. So one may use the left hand side
for help on the mouse buttons and the right hand side for
the current properties.

As to the current properties, I think that it might be nice for the future to
have a small 50x50 pixel rectangle in the upper right hand, eating from
the menu and item bars, in which an example of the current properties
is displayed (i.e. a filled polygon with 2ln thick penwidth).
Indeed, one concern is not to show too much information,
because that might again be distracting for the author.

> Another solution (partially used by Inkscape) is to display the
> functionality of a button/key whenever it is pressed). Less screen-space
> consumption, but allows to discover the interface by experimentation.
>
> > This is the solution used by Jfig:
> > http://tech-www.informatik.uni-hamburg.de/applets/jfig/images/screen-editor-annotated.png
>
> XFig is amongst the worst interfaces I've ever seen. Most people excuse
> it by saying that is rather old, or limited by the toolkit, or that it
> works as it works for historic reasons. Why not doing the standard and
> efficient thing, Inkscape for example:
>
> have succesive clicks over an object trigger the different modes

I don't see the advantage of using this mechanism over
using three different buttons which happen to be on my mouse.

> scaling & moving: use handlers, aspect ratio preservation via the use of
>
> control, scaling wrt the gravity center with shift. The
> center of gravity is user settable by dragging the small
> crosshair in the middle. Move just by clicking an anonymous
> point
> of the object.
>
> the turning/shearing mode: control again for discrete rotation steps,
> etc.

Sure, much of this kind of stuff still has to be done.



Archive powered by MHonArc 2.6.19.

Top of Page