texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] New features for menus in TeXmacs 1.0.0.11


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] New features for menus in TeXmacs 1.0.0.11
Date: Tue, 30 Jul 2002 15:39:18 +0200 (MET DST)

> > > What are the intended semantics of the "o" toggle?
> > 
> > I explained this before.
> > o corresponds to *structured* selection.
> > Selecting one item and then reselecting the old one is *not* a noop.
> 
> Part of my proposal of menu reorganisation included modification of
> the behaviour of the editor make that kind of operation mostly no-op.

A few exceptions like this one (another one is selecting a new value 'y'
for a variable var inside a <with|var|x|...> at the beginning or
the end of the "with") should probably be implemented indeed.
But, this not withhold the main observation that inserting
a with is inserting new structure in general and not changing
some settings.

> So, if I understand well, "o" toggle is only informative of the
> context at the cursor position. It is being used instead of standard
> checkmarks because standard checkmark semantic is not to be expected.

Yes, "o" is only informative.

> > We'll see. But remember that I am also very busy.
> > At a certain point, I will freeze the user interface, ready or not.
> 
> I know exactly what I want to do. I understand it is better to go
> there incrementally, but forcing incrementality and then freezing
> change in an authoritarian manner is not what I call good teamwork.

Yes, but at a certain point things have to be frozen,
and for many reasons: the users do not like interfaces which change
all the time, the documentation is more and more outdated, etc.
Incremental changes in the user interface are OK for minor points,
but very hard to follow and maintain for major points.

Lately, I have been working for at least a month on the GUI
already and I have been asking for remarks since a long time.
You are saying that I behave in an authoritarian way and
that I do not practice teamwork. But, as you see, I have kept
everybody publicly informed about my plans and progress.
I can understand that you did not have time for participating;
but you should not blame me that I did not give you and
everybody else the opportunity to do so. Things change as
a function of the time that everybody has to make changes.
If I get little feedback, then it is legitimate that
I take the decisions myself.

As to a clear roadmap: the major architecture of the user interface
for the years to come has not been fixed yet. However, it this will
be so in the next stable 1.0.1.0 release, which is planned for
october or so. This will mean a gap of six months between
two stable releases, which is extremely long in the case of TeXmacs.
Also, during august and september, I will have many other things to do,
so all time I spend on coding the user interface is less time that
I will spend on discussions (and vice versa).

> > The more you help, the more time we will have to make it really good and
> > the more that you will be able to influence the design.
> 
> More on that below.

> You said that you already explained what "o" checks meant. Which is
> not very helpful on the subject of using "*" and "v" checks or only
> "v" checks.

OK, I think that we misunderstand each other on this point:
I mean that one should use "v" for toggles (like showing
the status bars) and "*" for choice lists (like the document language).

> The point is which kind of teamwork do you want? I try not to be
> offensive. Really, I only want to go back to real work, that is fixing
> the GUI, getting done with my placement report and making more good
> code. But you are not making that easy.

What we need on the GUI and what can well be done by you now are
precisely the points that I mentioned in the original email.
This is not very hard and not very long, maybe a bit boring,
but not completely boring (in general, I do not consider to give
you the boring part of the work on TeXmacs; the rewriter project
is extremely interesting). I also stated some guidelines on
how this work should articulate with my next work.
This is not meant to be authoritarian: it is there for efficiency.

> Please let us not start another flamewar, I just wanted to share my
> thoughts about teamwork.

OK, so let's stop arguing about this;
I think that I explained my point of view enough now.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]