Re: minibuffer design problems
On Tue, Jul 16, 2002 at 04:54:11PM +1000, Allan Rae wrote: While I agree with the separate implementation you suggest I don't like the waste of screenspace experienced with KDE/Gnome/Mozilla because they are afraid of having two separate widgets share the same space -- especially when the proportion of their usage tends to be statusbar 90% and minibuffer 10% (for some wildly enthusiastic minibuffer user). Yes, screen real estate is a problem, and it should always be considered. But considering how confusing the minibuffer is : o you lose info on current font state etc. if you want to enter a command o it is less than apparent you can type there (it took me personally 2 years of occassional lyx usage before I noticed, and this was when you could click on it) Also, bear in mind that it will be possible to hide the command buffer toolbar, and we fit in with the standard UI of a status bar, and I hope you'll agree that measure for measure, a separation is probably best. But then I'm into bad UI. heh :) Just make sure there's an interface around for we emacsers to feel at home in. lyx 1.1.6 ? /me runs john -- i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, NO EMALES FROM PEOAPAL UNDER IQ OF 1 - jeffk
Re: minibuffer design problems
On Tue, Jul 16, 2002 at 04:54:11PM +1000, Allan Rae wrote: > While I agree with the separate implementation you suggest I don't > like the waste of screenspace experienced with KDE/Gnome/Mozilla > because they are afraid of having two separate widgets share the same > space -- especially when the proportion of their usage tends to be > statusbar > 90% and minibuffer < 10% (for some wildly enthusiastic > minibuffer user). Yes, screen real estate is a problem, and it should always be considered. But considering how confusing the minibuffer is : o you lose info on current font state etc. if you want to enter a command o it is less than apparent you can type there (it took me personally 2 years of occassional lyx usage before I noticed, and this was when you could click on it) Also, bear in mind that it will be possible to hide the "command buffer" toolbar, and we fit in with the standard UI of a status bar, and I hope you'll agree that measure for measure, a separation is probably best. > But then I'm into bad UI. heh :) > Just make sure there's an interface around > for we emacsers to feel at home in. lyx 1.1.6 ? /me runs john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: minibuffer design problems
John Levon wrote: I don't think you understand: they are two entirely separate UI objects, both visible at once. I don't think they are visible at once. There is or the message bar or the input buffer visible (well they have the same design so you won't notice. But they use the same space. Do you say you want to make that part higher and so make visible both at the same time? I don't Lars will agree with that. We always implemented it like an Emacs minibuffer and it handles stuff more or less the same as we do. Well I don't know zip about Qt, but that's not really relevant anyway. This is a sane design regardless of toolkit IMHO. Why do you prefer to conflate two entirely separate concepts into one set of code ? It seems to me that it's only because xforms has happened to do the same previously. I don't have any strong opinion about this, to tell you the truth. So if you implement it in a, for you, cleaner way for me you may go ahead, just leave the xforms behaviour as it is now and also the look and feel. After that if behind the scenes it is one or two classes I really don't care much about. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
John Levon wrote: > I don't think you understand: they are two entirely separate UI objects, > both visible at once. I don't think they are visible at once. There is or the message bar or the input buffer visible (well they have the same design so you won't notice. But they use the same space. Do you say you want to make that part higher and so make visible both at the same time? I don't Lars will agree with that. We always implemented it like an Emacs minibuffer and it handles stuff more or less the same as we do. > Well I don't know zip about Qt, but that's not really relevant anyway. > This is a sane design regardless of toolkit IMHO. Why do you prefer to > conflate two entirely separate concepts into one set of code ? It seems > to me that it's only because xforms has happened to do the same > previously. I don't have any strong opinion about this, to tell you the truth. So if you implement it in a, for you, cleaner way for me you may go ahead, just leave the xforms behaviour as it is now and also the look and feel. After that if behind the scenes it is one or two classes I really don't care much about. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
John Levon wrote: I guess we also need something to get the information string (I assume this is the keyboard shortcut list string ?) It's quite wrong IMHO for the core code to push /anything/ to the MiniBuffer: it should only push to the StatusBar Note such a scheme still alllows the xforms-style commingling Does anybody have any comments / objections ? Jug ? Asger ? I don't understand really what problems you have with this? Why do you need two different objects? Isn't it possible to do this internal to the Minibuffer-Object? Why should the core care to change between a StatusBar and a Minibuffer. What real problem do you have to make this internal to the object? You just have to define a Input object and a display object and change between them when needed. That shouldn't be that big of a problem (just show/hide calls to the objects which have the same size/position). IMO that for the core it should be just one object to not complicate the stuff to much and for the frontend it should be really easy to implement this as such. But obviously you are the qt expert (I only made such small projects as publicity KSendFax, KGoodStuff /publicity which I recently ported to qt3 ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
On Fri, Jul 12, 2002 at 09:28:56AM +0200, Juergen Vigna wrote: I don't understand really what problems you have with this? Why do you need two different objects? Mainly because commingling (oooh yeah) two different purposes into the one buffer is really bad UI Isn't it possible to do this internal to the Minibuffer-Object? No. What do I return for isEditingMode() ? Yes AND no ? Why should the core care to change between a StatusBar and a Minibuffer. The core doesn't know about /either/ of these things in my design. It just has a LyXView::statusMessage(string), and it us up tothe frontend to do what it likes. What real problem do you have to make this internal to the object? Just look at the methods I have to implement and the code in MiniBuffer.C ! e.g. MiniBuffer::message() Rather I would turn it round and ask: what is your problem with my changes ? You just have to define a Input object and a display object and change between them when needed. That shouldn't be that big of a problem (just show/hide calls to the objects which have the same size/position). I don't think you understand: they are two entirely separate UI objects, both visible at once. IMO that for the core it should be just one object to not complicate the stuff to much What is copmlicated about the 3 or 4 methods I have outlined ? It couldn't get much simpler : showMessage(string) showMessagePush(string) vectorstring showCompletions(string prefix) string showShortcuts(string cmd) void dispatch(string cmd) is what the core implements. The frontend may now do as it chooses. and for the frontend it should be really easy to implement this as such. My design is /far/ simpler to implement. But obviously you are the qt expert Well I don't know zip about Qt, but that's not really relevant anyway. This is a sane design regardless of toolkit IMHO. Why do you prefer to conflate two entirely separate concepts into one set of code ? It seems to me that it's only because xforms has happened to do the same previously. regards john -- I hope you will find the courage to keep on living despite the existence of this feature. - Richard Stallman
Re: minibuffer design problems
John Levon wrote: > I guess we also need something to get the "information" string > (I assume this is the keyboard shortcut list string ?) > > It's quite wrong IMHO for the core code to push /anything/ to the > MiniBuffer: it should only push to the StatusBar > > Note such a scheme still alllows the xforms-style commingling > > Does anybody have any comments / objections ? Jug ? Asger ? I don't understand really what problems you have with this? Why do you need two different objects? Isn't it possible to do this internal to the Minibuffer-Object? Why should the core care to change between a StatusBar and a Minibuffer. What real problem do you have to make this internal to the object? You just have to define a Input object and a display object and change between them when needed. That shouldn't be that big of a problem (just show/hide calls to the objects which have the same size/position). IMO that for the core it should be just one object to not complicate the stuff to much and for the frontend it should be really easy to implement this as such. But obviously you are the qt expert (I only made such small projects as KSendFax, KGoodStuff which I recently ported to qt3 ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
On Fri, Jul 12, 2002 at 09:28:56AM +0200, Juergen Vigna wrote: > I don't understand really what problems you have with this? > Why do you need two different objects? Mainly because commingling (oooh yeah) two different purposes into the one buffer is really bad UI > Isn't it possible to > do this internal to the Minibuffer-Object? No. What do I return for isEditingMode() ? Yes AND no ? > Why should the core > care to change between a StatusBar and a Minibuffer. The core doesn't know about /either/ of these things in my design. It just has a LyXView::statusMessage(string), and it us up tothe frontend to do what it likes. > What real > problem do you have to make this internal to the object? Just look at the methods I have to implement and the code in MiniBuffer.C ! e.g. MiniBuffer::message() Rather I would turn it round and ask: what is your problem with my changes ? > You just have to define a Input object and a display object and > change between them when needed. That shouldn't be that big of > a problem (just show/hide calls to the objects which have the same > size/position). I don't think you understand: they are two entirely separate UI objects, both visible at once. > IMO that for the core it should be just one object > to not complicate the stuff to much What is copmlicated about the 3 or 4 methods I have outlined ? It couldn't get much simpler : showMessage(string) showMessagePush(string) vector showCompletions(string prefix) string showShortcuts(string cmd) void dispatch(string cmd) is what the core implements. The frontend may now do as it chooses. > and for the frontend it should > be really easy to implement this as such. My design is /far/ simpler to implement. > But obviously you are the qt expert Well I don't know zip about Qt, but that's not really relevant anyway. This is a sane design regardless of toolkit IMHO. Why do you prefer to conflate two entirely separate concepts into one set of code ? It seems to me that it's only because xforms has happened to do the same previously. regards john -- "I hope you will find the courage to keep on living despite the existence of this feature." - Richard Stallman
minibuffer design problems
There are two main problems: the commingling (I love that word) of a status bar with a command buffer, and the push/pull mixup thereof. For xforms, fine, but for Qt there must be a separation. I propose : a StatusBar instance with one method show_message(string const msg, int timeout) (and a push/pop variant perhaps like before) StatusBar is entirely readonly, and the core code only ever pushes information to it. Core --msgs-- StatusBar a separate object called MiniBuffer This is an independent GUI-only object. The core only knows about : focus(); to focus the object. Everything else is toolkit-private. However, the MiniBuffer needs to be able to complete commands, and dispatch them. I don't see this as a big deal. We initialise it with a reference to lyxfunc object, and have vectorstring getCompletions(string const prefix); for the MiniBuffer object to call when it receives a Tab I guess we also need something to get the information string (I assume this is the keyboard shortcut list string ?) It's quite wrong IMHO for the core code to push /anything/ to the MiniBuffer: it should only push to the StatusBar Note such a scheme still alllows the xforms-style commingling Does anybody have any comments / objections ? Jug ? Asger ? regards john -- I hope you will find the courage to keep on living despite the existence of this feature. - Richard Stallman
minibuffer design problems
There are two main problems: the commingling (I love that word) of a status bar with a command buffer, and the push/pull mixup thereof. For xforms, fine, but for Qt there must be a separation. I propose : a StatusBar instance with one method show_message(string const & msg, int timeout) (and a push/pop variant perhaps like before) StatusBar is entirely readonly, and the core code only ever pushes information to it. Core -->msgs--> StatusBar a separate object called MiniBuffer This is an independent GUI-only object. The core only knows about : focus(); to focus the object. Everything else is toolkit-private. However, the MiniBuffer needs to be able to complete commands, and dispatch them. I don't see this as a big deal. We initialise it with a reference to lyxfunc object, and have vector getCompletions(string const & prefix); for the MiniBuffer object to call when it receives a "Tab" I guess we also need something to get the "information" string (I assume this is the keyboard shortcut list string ?) It's quite wrong IMHO for the core code to push /anything/ to the MiniBuffer: it should only push to the StatusBar Note such a scheme still alllows the xforms-style commingling Does anybody have any comments / objections ? Jug ? Asger ? regards john -- "I hope you will find the courage to keep on living despite the existence of this feature." - Richard Stallman
