Re: ButtonController Mark III
On Fri, 13 Apr 2001, John Levon wrote: > On Thu, 12 Apr 2001, Allan Rae wrote: > > > I have been. Trouble is other people want to do more with it than I > > originally meant it for. In particular people want to disable entries for > > read-only documents when AFAIAC this is unnecessary because the OK and > > Apply buttons are disabled in those policies. > > It is very necessary for well-behaved feedback to the user. Sure. Not everyone reads the "This buffer is readonly -- you can't change stuff" dialog. But you are right though. > > How much complexity in the policy state machine is it worth to have clever > > interactive dialogs? Each dialog designer should be asking themselves if > > they need the extra fancy control at all or whether they should be > > thinking up a better interface design. > > FWIW, the KDE frontend was managing just fine without an explicit controller. > I am perfectly happy for each frontend to NOT use a button controller at all. As am I. > And frankly I think it is somewhat lax of you to blame the controller design > problems on poor dialog design ! Especially as we have inherited some, erm, > interesting dialog designs from xforms that take some time to re-assess. How complex a dialog do people want? If you follow the KISS principle you get simple elegent designs. Fancy stuff like Angus' colour selection switcheroo is possible with the new controller but is it really necessary? After all the button controller did what it was designed for very well. Trouble is, people wanted more than what I did which looks like a design flaw. It was meant to really simple and small. The new one will see most of the controller hierarchy for XForms at least shuffled around and has a more general state machine engine. > I do not consider a single thing I've asked for as "fancy" I don't remember saying you did. > > If anyone thinks of some fancy feature they want that this new group > > activation model doesn't support I'm prepared to tell them to rethink > > their interface -- such as if someone wants to hide/show widgets rather > > than activating them. > > In 90% of cases this is a terrible idea. The user should be able to > see roughly what a dialog can do when they first see it, *without* having > to mess around with the widgets. One commone exception is tabbed dialogs, > and as I'm sure you know they are awfully overused anyway. Gotta put all those configuration items somewhere the screen isn't big enough for one dialog and having multiple dialogs that you blaze a trail through like W2k networking config is a bigger pain than tabs IMO. Anyway, we need to try setting shortcuts for the tab folders in XForms -- this should be doable but may need to be done manually because they are available in the data structures. > so it can go back to an ad-hoc per-frontend approach. That's fine by me... Did it ever leave there? Allan. (ARRae)
aussie...
some disk problems... (severe) I guess I can have a backup machine up in not too long. anyhow... no crucial services was run by aussie. aussie ran: - some mail stuff (lists etc) - anoncvs - www-user Once I get hold of the hardware I will try to save as much as possible. Especially the mail stuff. Anoncvs will not be moved to baywatch, but I thing there should be a mirror? Or perhaps someone is willing to setup an official mirror? (rsync is your friend) WWW... you should be able to use www.no.lyx.org, that is the backup of www.lyx.org that I have control over. CVS should work as usual, except that you won't get cvslog mail. I cannot promise to get everything working super quick... it might take some days or up to a week. btw. [EMAIL PROTECTED] is not working. One good thing is that this is an excellent opurtunity to upgrade aussie (software and hardware). -- Lgb
test
Testing if I am subscribed. -- Lgb
Long mails
It would be really nice if we could refrain from posting large mails to the list. Not everybody has a cheap high-speed connection to the net all the time... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Long mails
Andre Poenitz <[EMAIL PROTECTED]> writes: | It would be really nice if we could refrain from posting large mails to | the list. Not everybody has a cheap high-speed connection to the net all | the time... What's the limit on a "large" mail? 1k 10k 100k? 1M? -- Lgb
mathed behaviour
A short request for comments to prepare the step after the macro stuff: Currently \eqnarray and math tables are internally stored as a single inset with "embedded" TABs and CRs to mimic "next cell in a row" and "next row". In parallel to this structure there exists another structure that handles labels and numbers (which is somewhat difficult to keep in sync with the "real" structure as you might have noticed in current CVS...) Apart from a couple of disadvantages (implementation-wise) this has a big advantage: It is comparatively easy to implement cutting and pasting parts of an array or a matrix that span more than one "entry" _including_ parts of an "entry". I think a more suitable implementation of matrices and array would involve a one-dimesional array (i.e. std::vector) of "row structures", each holding another one-dimensional array of "entries", an optional number, and an optional label. Obtaining the current functionality with this "new" internal layout should be obvious in most cases, but implementing that "cut & paste of one entry and a half" would be more demanding. I do not think that it will be impossible, it's just a bit ugly, but if nobody uses that feature regularly, I'd rather drop it entirely and keep the implementation small... [I have to rework that part anyway in some way or another, since labels/numbers for multiline stuff seems still to be broken...] Andre' PS: Would be nice to get some more feedback to the "macro monster patch", otherwise I'll have a hard time to force-feed this down Lars's throat ;-} -- André Pönitz . [EMAIL PROTECTED]
New Basque doc
I seem not to have karma to check in the updated Basque eu_splash.lyx. Which
is fine; it's not like I've been checking much in lately. But could somebody
check it in?
Dooteo tells me he's got a new eu.po coming in soon, too.
-Amir
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 2.16
\textclass article
\language english
\inputencoding default
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Title
Ongietorri LyX-era!
\layout Section*
LyX erabiltzean lehendabizi jakin beharreko gauzak
\layout Enumerate
LyX-ek laguntza eskuliburu bikain bat dauka (erabil ezazu).
\family sans
\bar under
L
\bar default
aguntza
\bar under
\SpecialChar \menuseparator
S
\bar default
arrera
\family default
zerrenda aukerarekin hasi (eskuliburuei buruzko sarreratxo bat da).
Ondoren,
\family sans
\bar under
L
\bar default
aguntza
\bar under
\SpecialChar \menuseparator
T
\bar default
utoretza-n
\family default
laguntzaz LyX erabiltzen ikasi
\family sans
.
\layout Enumerate
LyX
\begin_inset Quotes eld
\end_inset
idazki prozesatzailea
\begin_inset Quotes erd
\end_inset
deritzoguna da.
Bere egituragatik ohizko idazki prozesatzaileen aldean ezberdina da, idazkiak
idazteko lana errazago eginez.
Apur bat ezberdina soilik, ez zaitez beldurtu.
Eskuliburu laguntzaileek gauza denak argituko dizkizute
\begin_float footnote
\layout Standard
Laguntzako eskuliburuak irakurtzea komeni zaizkizula esan al dizugu?
\end_float
.
\layout Enumerate
LyX-en irteera emaitzak (output) itxura hobezina dauka.
Begiztatzeko
\family sans
\bar under
F
\bar default
itxategia\SpecialChar \menuseparator
Dvi\SpecialChar ~
ikusi
\family default
lan dezakezu (une honetan adibidez).
\layout Enumerate
Bai,.
LyX-ek LaTeX-en betebeharreko ia dena errepika (edo landu) dezake.
Eta bai, LyX-ek LaTeX-eko fitxategiak beregana (
\family sans
\bar under
F
\bar default
itxategia\SpecialChar \menuseparator
Barneratu
\family default
) ditzake.
LaTeX-eko erabiltzaile adituei
\emph on
Tutoretzako
\emph default
\begin_inset Quotes eld
\end_inset
LyX LaTeX-eko erabiltzaileentzat
\begin_inset Quotes erd
\end_inset
alea irakurtzea komeni zaie, eta gainerakoentzat gainetik begiradatxo bat
ematearekin nahikoa izango da.
Beste irakurle guztiontzat (ez zaitez kezkatu), LyX erabiltzeko LaTeX jakin
beharrik ez dago.
\layout Enumerate
Inglesez gain beste edozein hizkuntzetan idazten edo irakurtzen duten erabiltzai
leentzat abantaila ugari daude.
Gainera tekla elkarte, tresna barra eta beste hainbat ezaugarriek egokitze
maila handia eskeintzen diote (ia dena
\family typewriter
lyxrc
\family default
fitxategia landuz).
\family sans
\bar under
L
\bar default
aguntza\SpecialChar \menuseparator
\bar under
E
\bar default
gokitua
\family default
ikus ezazu.
\layout Enumerate
LyX-en Interneteko orria
\family typewriter
\begin_inset LatexCommand \url{http://www.lyx.org/}
\end_inset
\family default
da.
Bertan programari buruzko informazioa lortu, gutun zerrendetan harpidetu,
\emph on
LyX-eko Marrazkidun Ibilalditxoa (edo Tour)
\emph default
-a lortu eta gauza gehiago egin dezakezu.
\the_end
unicode fonts
Hello everybody...
Has anybody thought about implementing Unicode support into LyX?
I'm currently plan to support an extended set of math symbols and characters
into LyX (for myself or others if it is needed).
Here are my thoughts to be discussed:
I'm thinking of a re-implementation of the font engine to support more than
the standard font encodings and to support more languages and symbols. At the
moment I'm looking at the pango code if it can be used as the new font engine
for LyX. This will make the code depending on glib of course which is not
available for OS/2 at the moment, I think.
The LyX file format has to be changed to support more than the current
character set. This could be implemented by using a new command (e.g.
"\LyXUNICODE{code}").
The internal typedef LyXParagraph::value_type has to be changed to 16 bit
type (wchar_t) and the TeX- and SGML-exporters and -importers have to be
changed to support more characters.
Anyone satisfied with this ideas :-)
Stephen
--
Stephen Reindl [EMAIL PROTECTED]
Swinemünder Straße 43
13355 Berlin
Germany
Phone: +49 (30) 46 79 17 52
Fax:+49 (721) 151 220 366
Re: unicode fonts
Stephen Reindl <[EMAIL PROTECTED]> writes:
| Hello everybody...
|
|
| Has anybody thought about implementing Unicode support into LyX?
Yes, this is on the agenda.
| I'm currently plan to support an extended set of math symbols and characters
| into LyX (for myself or others if it is needed).
Ok. You should talk to André Pönitz, he is currently rewritint the
low-level mathed code.
| Here are my thoughts to be discussed:
|
| I'm thinking of a re-implementation of the font engine to support more than
| the standard font encodings and to support more languages and
| symbols. At the
| moment I'm looking at the pango code if it can be used as the new
| font engine
| for LyX. This will make the code depending on glib of course which is not
| available for OS/2 at the moment, I think.
|
| The LyX file format has to be changed to support more than the current
| character set. This could be implemented by using a new command (e.g.
| "\LyXUNICODE{code}").
The plan (Plan?) is to make the LyX fileformat UTF-8, and also more
xml-like.
| The internal typedef LyXParagraph::value_type has to be changed to 16 bit
| type (wchar_t) and the TeX- and SGML-exporters and -importers have to be
| changed to support more characters.
This is planned, except that wchar_t is 32 bit on most os's.
| Anyone satisfied with this ideas :-)
It needs to be discussed, and also we need to clean up the current
development / changes first.
--
Lgb
what to do...
... if somebody deletes a macro _definition_ (aka "template") but still uses the macro somewhere in the document? Whirling through all math insets to find such situations and disallow the deletion is not really an option, and simply disallow the deletion in all cases does not sound ok, either. The "clean" way could be some kind of registration of macro with their tenmplate and allow the deletion of the template only if the last "user" is gone... Sounds like obverkill, though... Ideas? What would you expect? Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: what to do...
Andre Poenitz <[EMAIL PROTECTED]> writes: | ... if somebody deletes a macro _definition_ (aka "template") but still | uses the macro somewhere in the document? | | Whirling through all math insets to find such situations and disallow the | deletion is not really an option, and simply disallow the deletion in all | cases does not sound ok, either. | | The "clean" way could be some kind of registration of macro with their | tenmplate and allow the deletion of the template only if the last "user" | is gone... Sounds like obverkill, though... This is what we must do. | Ideas? What would you expect? I have thought that the templates should not really be a part of the document proper. the macros are only inserted into the document when needed, upson save, export etc. -- Lgb
minibuffer changes ++
I have committed my changes to the minibuffer code, some of this will need some tweeking, but most is fine. -- Lgb
Re: minibuffer changes ++
Lars Gullik Bjønnes wrote: > > I have committed my changes to the minibuffer code, some of this will > need some tweeking, but most is fine. > > -- > Lgb is that on anoncvs.no.lyx.org? Garst
Re: minibuffer changes ++
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > | > I have committed my changes to the minibuffer code, some of this will | > need some tweeking, but most is fine. | > | > -- | > Lgb | is that on anoncvs.no.lyx.org? no such thing... -- Lgb
Re: minibuffer changes ++
Lars Gullik Bjønnes wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: > | > > | > I have committed my changes to the minibuffer code, some of this will > | > need some tweeking, but most is fine. > | > > | > -- > | > Lgb > | is that on anoncvs.no.lyx.org? > > no such thing... > > -- > Lgb anoncvs.lyx.org is timing out. Garst
Re: mathed behaviour
On Tue, Apr 17, 2001 at 06:00:58PM +0200, Andre Poenitz wrote: > PS: Would be nice to get some more feedback to the "macro monster patch", > otherwise I'll have a hard time to force-feed this down Lars's throat ;-} I had few problems with your patch: 1. In macro instances, the argument where not expanded to their values, i.e. I got #1,#2 etc. 2. The cursor is broken when it is inside a macro instance. Also, what is the reason for the new behavior when the cursor moves into a macro instance (i.e. the box with the argument) ? Do you think that it is a better UI ? (due to (2) above I couldn't do a real test of this new behavior).
minipage in latest cvs
creating a minipagepage via insert->minipage with the
default width of 100% gives in latex:
\begin{minipage}[c]{.100\columnwidth}%
^
it should be 1.00
all other values less than 100% are okay, all over
99% are wrong!
Herbert
--
http:[EMAIL PROTECTED]
Re: minibuffer changes ++
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > | > "Garst R. Reese" <[EMAIL PROTECTED]> writes: | > | > | Lars Gullik Bjønnes wrote: | > | > | > | > I have committed my changes to the minibuffer code, some of this will | > | > need some tweeking, but most is fine. | > | > | > | > -- | > | > Lgb | > | is that on anoncvs.no.lyx.org? | > | > no such thing... | > | > -- | > Lgb | anoncvs.lyx.org is timing out. It not even up, so no wonder... (as said HD problem) -- Lgb
Re: mathed behaviour
> On Tue, Apr 17, 2001 at 06:00:58PM +0200, Andre Poenitz wrote: > > PS: Would be nice to get some more feedback to the "macro monster patch", > > otherwise I'll have a hard time to force-feed this down Lars's throat ;-} > > I had few problems with your patch: > 1. In macro instances, the argument where not expanded to their values, i.e. > I got #1,#2 etc. That is one of the remaining issues, it is solvable by extensive redrawing > 2. The cursor is broken when it is inside a macro instance. How? > Also, what is the reason for the new behavior when the cursor moves into a > macro instance (i.e. the box with the argument) ? > Do you think that it is a better UI ? Sort of, yes. But it's an implementation issue, too. If an argument is used more than once (ie #1 + #2 + #1), it is now obvious that there is only one argument and there is no surprise if the display changes in several places after this argument has changed. >From the implementation pov it's simply that the old macro code did not allow editing of nested macros of the same kind at all and editing and displaying macro of the same kind were not independent (I'd even say impossible, but I probably have not understood the inner workings of the old implemnetation entirely). Anyway, I had to break a few things to make nested macros of the same kind work in a manner that I understand and one of the things that are seemingly gone is some knowledge the macro had of its arguments... but I actually think of changing this again so this won't hold true for long... I just noticed another bug, so maybe its worthwhile to wait a bit for your next try... Andre' -- André Pönitz . [EMAIL PROTECTED] C++-Programmierer gesucht ... Naeheres unter http://mathematik.htwm.de/job
