Le 22/08/2016 à 19:34, Richard Heck a écrit :
Richard, this is candidate for branch.
OK.
Thanks, done now.
JMarc
On 08/22/2016 12:22 PM, Jean-Marc Lasgouttes wrote:
> Le 20/08/2016 à 00:24, Pavel Sanda a écrit :
>>> Is the following what you had in mind? I have no idea of how people use
>>> minibuffer, so please test if you care.
>>
>> This is indeed the behaviour I w
Le 20/08/2016 à 00:24, Pavel Sanda a écrit :
Is the following what you had in mind? I have no idea of how people use
minibuffer, so please test if you care.
This is indeed the behaviour I would expect. Pavel
Thanks for confirmation. It is in master at [65b0e84b/lyxgit].
Richard, this is
Jean-Marc Lasgouttes wrote:
> Le 19/07/2016 ? 09:56, Scott Kostyshak a écrit :
>> if I open the minibuffer, then click into the work area, and then
>> execute alt+x, I expect the focus to switch to the mini-buffer (just as
>> it does if the mini-buffer is not open). Is that
Le 19/07/2016 à 09:56, Scott Kostyshak a écrit :
if I open the minibuffer, then click into the work area, and then
execute alt+x, I expect the focus to switch to the mini-buffer (just as
it does if the mini-buffer is not open). Is that a correct expectation?
Is the following what you had in
Le 12/08/2016 à 19:44, Scott Kostyshak a écrit :
On Fri, Aug 12, 2016 at 07:28:57PM +0100, Guillaume Munch wrote:
Le 12/08/2016 à 01:23, Scott Kostyshak a écrit :
The change is due to 7ac70092. From what I understand, this is an
intended change and there's no easy way to make alt+x work the se
On Fri, Aug 12, 2016 at 07:28:57PM +0100, Guillaume Munch wrote:
> Le 12/08/2016 à 01:23, Scott Kostyshak a écrit :
> >
> > The change is due to 7ac70092. From what I understand, this is an
> > intended change and there's no easy way to make alt+x work the second
> > time. I'll give up here on thi
Le 12/08/2016 à 01:23, Scott Kostyshak a écrit :
The change is due to 7ac70092. From what I understand, this is an
intended change and there's no easy way to make alt+x work the second
time. I'll give up here on this, unless someone gives me an idea for a
possible solution.
By looking at it,
On Tue, Jul 19, 2016 at 08:14:42PM -0400, Scott Kostyshak wrote:
> On Tue, Jul 19, 2016 at 10:57:11AM -0700, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > if I open the minibuffer, then click into the work area, and then
> > > execute alt+x, I expect the focus t
On Tue, Jul 19, 2016 at 10:57:11AM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > if I open the minibuffer, then click into the work area, and then
> > execute alt+x, I expect the focus to switch to the mini-buffer (just as
> > it does if the mini-buffer is not ope
Scott Kostyshak wrote:
> if I open the minibuffer, then click into the work area, and then
> execute alt+x, I expect the focus to switch to the mini-buffer (just as
> it does if the mini-buffer is not open). Is that a correct expectation?
this is definitely regression it works perfectl
Le 19/07/2016 à 09:56, Scott Kostyshak a écrit :
if I open the minibuffer, then click into the work area, and then
execute alt+x, I expect the focus to switch to the mini-buffer (just as
it does if the mini-buffer is not open). Is that a correct expectation?
A similar case is the outline. If
if I open the minibuffer, then click into the work area, and then
execute alt+x, I expect the focus to switch to the mini-buffer (just as
it does if the mini-buffer is not open). Is that a correct expectation?
A similar case is the outline. If the outline is open, ctrl+alt+o still
shifts focus to
> Author: Jean-Marc Lasgouttes
> > > Date: Sat Apr 18 19:10:33 2015 +0200
> > >
> > > Auto feature for minibuffer toolbar
> >
> > If I do
> >
> > 1. alt + x
> > 2. alt + x
> > 3. alt + x
> >
> > The first one open
>
> > Auto feature for minibuffer toolbar
>
> If I do
>
> 1. alt + x
> 2. alt + x
> 3. alt + x
>
> The first one opens the mini-buffer, the second switches back to the
> work area, and the third does nothing. I expected the third to switch
> back to the mini-
Am Mittwoch, 15. Juli 2015 um 18:43:36, schrieb Kornel Benko
> Am Mittwoch, 15. Juli 2015 um 17:44:22, schrieb Jean-Marc Lasgouttes
>
> > Le 15/07/2015 15:26, Kornel Benko a écrit :
> > >> So, can I apply my patch now?
> > >
> > > I have to fight with some tests, but YES.
> >
> > OK, I did it n
On Wed, Jul 15, 2015 at 11:43 AM, Jean-Marc Lasgouttes
wrote:
> commit 7ac700920f0de8165b834010e211517098afbe14
> Author: Jean-Marc Lasgouttes
> Date: Sat Apr 18 19:10:33 2015 +0200
>
> Auto feature for minibuffer toolbar
If I do
1. alt + x
2. alt + x
3. alt + x
The firs
Am 15.07.2015 um 20:46 schrieb Kornel Benko :
> Am Mittwoch, 15. Juli 2015 um 20:37:35, schrieb Stephan Witt
>>>
>>> Also I have now a reproducible crash, but only with my private user dir.
>>>
>>> 1.) Open a file
>>> 2.) try to insert space in the middle of a word ==> crash
>>
>> This recipe
Am Mittwoch, 15. Juli 2015 um 20:37:35, schrieb Stephan Witt
> >
> > Also I have now a reproducible crash, but only with my private user dir.
> >
> > 1.) Open a file
> > 2.) try to insert space in the middle of a word ==> crash
>
> This recipe doesn't work for me. Do you have an example file to re
Am 15.07.2015 um 19:07 schrieb Kornel Benko :
> Am Mittwoch, 15. Juli 2015 um 18:43:36, schrieb Kornel Benko
>> Am Mittwoch, 15. Juli 2015 um 17:44:22, schrieb Jean-Marc Lasgouttes
>>
>>> Le 15/07/2015 15:26, Kornel Benko a écrit :
> So, can I apply my patch now?
I have to fight
Am Mittwoch, 15. Juli 2015 um 18:43:36, schrieb Kornel Benko
> Am Mittwoch, 15. Juli 2015 um 17:44:22, schrieb Jean-Marc Lasgouttes
>
> > Le 15/07/2015 15:26, Kornel Benko a écrit :
> > >> So, can I apply my patch now?
> > >
> > > I have to fight with some tests, but YES.
> >
> > OK, I did it n
Am Mittwoch, 15. Juli 2015 um 17:44:22, schrieb Jean-Marc Lasgouttes
> Le 15/07/2015 15:26, Kornel Benko a écrit :
> >> So, can I apply my patch now?
> >
> > I have to fight with some tests, but YES.
>
> OK, I did it now. Have fun :)
>
> JMarc
In trying to correct a test, I see now the the men
Le 15/07/2015 15:26, Kornel Benko a écrit :
So, can I apply my patch now?
I have to fight with some tests, but YES.
OK, I did it now. Have fun :)
JMarc
our test.ui or xxdefaults.ui that contains
> >>
> >> ===
> >> Format 2
> >>
> >> Include "default.ui"
> >>
> >>
> >> Toolbars
> >>"minibuffer" "on,bottom"
> >>
Toolbars
"minibuffer" "on,bottom"
End
===
This should just work, IMO.
With respect to 'minibuffer' I am with you.
So, can I apply my patch now?
JMarc
t; Just create your test.ui or xxdefaults.ui that contains
>
> ===
> Format 2
>
> Include "default.ui"
>
>
> Toolbars
> "minibuffer" "on,bottom"
> End
> ===
>
> This should just work,
lt.ui"
Toolbars
"minibuffer" "on,bottom"
End
===
This should just work, IMO.
JMarc
could extend the default.ui.
> >
> > Say it has the content
> > ...
> > Toolbars
> > "minibuffer" "auto,off,bottom"
> > End
> > Toolbar "extra" "Extra"
> > Item "Set language slovak" "lan
Le 01/07/2015 11:34, Kornel Benko a écrit :
Thanks, after examining the patch, I already found it. But the lack of a
preference entry
makes it so un-handy.
We need something which could extend the default.ui.
Say it has the content
...
Toolbars
"minibuffer" "auto,
Am Mittwoch, 1. Juli 2015 um 10:57:59, schrieb Jean-Marc Lasgouttes
> Le 30/06/2015 11:32, Kornel Benko a écrit :
> >> I'll think about it. You can also have a working environment where the
> >> minibuffer toolbar is not auto but on. This supposedly works.
> >
>
from the start'
Clocking on 'yes' or 'no' closes the minibuffer _and_ also the spellchecker
window.
This behaviour is not OK, since our key-tests cannot work anymore.
Wrong example. The file had no problems with spellchecking, the behaviour with
the dialog is the same a
Commit fdcff02a3124845d1033d3d804cede127850ff0f:
This commit has 2 view modes:
1.) auto with the new behaviour
2.) no displayed command minibuffer at all
The second mode is very inconvenient compared to the previous behaviour.
Could it be please changed Jean-Marc?
Kornel
Am Montag, 22. Juni 2015 um 16:53:06, schrieb Kornel Benko
> Am Montag, 22. Juni 2015 um 16:10:35, schrieb Jean-Marc Lasgouttes
>
> > Le 19/06/2015 16:31, Kornel Benko a écrit :
> > > From memory:
> > > 1.) start lyx, the minibuffer is already displayed.
> &g
Am Montag, 22. Juni 2015 um 16:10:35, schrieb Jean-Marc Lasgouttes
> Le 19/06/2015 16:31, Kornel Benko a écrit :
> > From memory:
> > 1.) start lyx, the minibuffer is already displayed.
> > 2.) open any file
> > 3.) M-x, the cursor is displayed in the minibuffer
>
Le 19/06/2015 16:31, Kornel Benko a écrit :
From memory:
1.) start lyx, the minibuffer is already displayed.
2.) open any file
3.) M-x, the cursor is displayed in the minibuffer
4.) M-x, in the minibuffer appears 'x'
5.) click on a view, cursor is displayed in both, minibuffer an
Am Freitag, 19. Juni 2015 um 16:12:17, schrieb Jean-Marc Lasgouttes
> Le 18/06/2015 17:41, Kornel Benko a écrit :
> > With this patch every key is going to the minibuffer. I tried cua and emacs
> > binding.
>
> Could you give more details on what you do?
>
> JMarc
Le 18/06/2015 17:41, Kornel Benko a écrit :
With this patch every key is going to the minibuffer. I tried cua and emacs
binding.
Could you give more details on what you do?
JMarc
his
> "alt-x to close" feature?
>
> Here is a new patch updated to latest master changes.
>
> JMarc
With this patch every key is going to the minibuffer. I tried cua and emacs
binding.
Kornel
signature.asc
Description: This is a digitally signed message part.
n-Marc Lasgouttes
Date: Sat, 18 Apr 2015 19:10:33 +0200
Subject: [PATCH] Auto feature for minibuffer toolbar
Now the minibuffer toolbar is "auto" by default. It is opened by
command-execute (M-x) and closed when the command is executed.
---
lib/ui/default.ui
On Thu, Jun 18, 2015 at 03:11:25AM -0400, Scott Kostyshak wrote:
> On Thu, Jun 18, 2015 at 08:51:12AM +0200, Kornel Benko wrote:
> > Am Donnerstag, 18. Juni 2015 um 08:38:28, schrieb Enrico Forestieri
> >
> > > On Thu, Jun 18, 2015 at 02:24:30AM -0400, Scott Kostyshak wrote:
> > > >
> > > > Wha
On Thu, Jun 18, 2015 at 08:51:12AM +0200, Kornel Benko wrote:
> Am Donnerstag, 18. Juni 2015 um 08:38:28, schrieb Enrico Forestieri
>
> > On Thu, Jun 18, 2015 at 02:24:30AM -0400, Scott Kostyshak wrote:
> > >
> > > What do you mean? For me M-x does not toggle, it just opens the
> > > mini-buffer
Am Donnerstag, 18. Juni 2015 um 08:38:28, schrieb Enrico Forestieri
> On Thu, Jun 18, 2015 at 02:24:30AM -0400, Scott Kostyshak wrote:
> >
> > What do you mean? For me M-x does not toggle, it just opens the
> > mini-buffer. Actually I just tested and if I press it rapidly many times
> > sometime
On Thu, Jun 18, 2015 at 02:24:30AM -0400, Scott Kostyshak wrote:
>
> What do you mean? For me M-x does not toggle, it just opens the
> mini-buffer. Actually I just tested and if I press it rapidly many times
> sometimes I can get it to close the mini-buffer. Yours toggles
> perfectly? I wonder if
On Wed, Jun 17, 2015 at 05:51:28PM +0200, Jean-Marc Lasgouttes wrote:
> Le 14/06/2015 07:48, Scott Kostyshak a écrit :
> >>Note though that I do like that if I just press return (that is,
> >>entering an empty string), the command buffer closes. The only reason
> >>I like this though is that a subs
Le 14/06/2015 07:48, Scott Kostyshak a écrit :
Note though that I do like that if I just press return (that is,
entering an empty string), the command buffer closes. The only reason
I like this though is that a subsequent alt + x does not hide the
mini-buffer.
I am not sure that I follow you he
On Tue, Apr 21, 2015 at 03:57:22PM -0400, Scott Kostyshak wrote:
> On Mon, Apr 20, 2015 at 8:33 AM, Jean-Marc Lasgouttes
> wrote:
>
> >> Also, what if you misspelled the command you entered so that the
> >> command is disabled? Should the mini-buffer stay open so you can
> >> correct it quickly a
On Mon, Apr 20, 2015 at 8:33 AM, Jean-Marc Lasgouttes
wrote:
>> Also, what if you misspelled the command you entered so that the
>> command is disabled? Should the mini-buffer stay open so you can
>> correct it quickly and enter it (without having to open the
>> mini-buffer again)? I don't have m
Le 19/04/2015 00:00, Scott Kostyshak a écrit :
Regarding your comment
"No need to keep the minibuffer open anymore"
can you add why to the comment? Is it because a command was just executed?
Yes, exactly.
Also, what if you misspelled the command you entered so that the
command i
On Sat, Apr 18, 2015 at 1:18 PM, Jean-Marc Lasgouttes
wrote:
> This patch makes minibuffer work like it does in emacs: it is open when
> invoking M-x, and gets closed when the command has been executed.
>
> It may be necessary to remove you session data (.config/LyX/lyx.conf for
>
This patch makes minibuffer work like it does in emacs: it is open when
invoking M-x, and gets closed when the command has been executed.
It may be necessary to remove you session data (.config/LyX/lyx.conf for
linux) so that the toolbar gets the proper flags. This is probably a
problem when
Pavel Sanda wrote:
> Juergen?
I need to have a closer look, but let us first finish 1.6.2, please.
Jürgen
Vincent van Ravesteijn - TNW wrote:
>
> >Vincent, Juergen,
> >
> >is it ok with you to backport http://www.lyx.org/trac/changeset/28250
> >into 1.6.3?
>
> Ah, you like it!...
i found it the harder way when loosing elaborted command after unwanted
lyx closing... 10mins lost ;)
> I still want to
>Vincent, Juergen,
>
>is it ok with you to backport http://www.lyx.org/trac/changeset/28250
>into 1.6.3?
Ah, you like it!...
I still want to add another few thingies:
1. You're now able to choose a certain command with the mouse, but you
still have to press enter on the keyboard to execute it.
Vincent, Juergen,
is it ok with you to backport http://www.lyx.org/trac/changeset/28250
into 1.6.3?
pavel
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Is there some place where I can read about the new state to the inset
>> world, btw?
>
> Ah, you mean, like, "documentation"?
I thought about a wiki page for developers explaining how the
different insets fit together, but documentation is nice too.
On Sat, Sep 08, 2007 at 10:34:21AM +0200, Jean-Marc Lasgouttes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > It turns out to be possible to exter in the minibuffer
> > a command: flex-insert Note:Comment, which will enter a
> > flex inset under the
Martin Vermeer <[EMAIL PROTECTED]> writes:
> It turns out to be possible to exter in the minibuffer
> a command: flex-insert Note:Comment, which will enter a
> flex inset under the name Note:Comment, which looks,
> feels and probably behaves like the real thing... only,
> i
It turns out to be possible to exter in the minibuffer
a command: flex-insert Note:Comment, which will enter a
flex inset under the name Note:Comment, which looks,
feels and probably behaves like the real thing... only,
it's a flex inset.
I don't think we want this. The attached blocks
On Friday 22 June 2007 06:55:01 Andre Poenitz wrote:
> Pretty trivial patch attached.
>
> Ok?
>
> Andre'
OK.
--
José Abílio
Andre Poenitz wrote:
> On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote:
>> Andre Poenitz wrote:
>>> Pretty trivial patch attached.
>>>
>>> Ok?
>> can you add a comment?
>
> The feature (inserting a space via lfun) was asked for twice during the
> last few weeks. Now that is possible
On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote:
> Andre Poenitz wrote:
> >Pretty trivial patch attached.
> >
> >Ok?
>
> can you add a comment?
The feature (inserting a space via lfun) was asked for twice during the
last few weeks. Now that is possible using M-x unicode-insert 0x20.
Andre Poenitz wrote:
Pretty trivial patch attached.
Ok?
can you add a comment?
Pretty trivial patch attached.
Ok?
Andre'
Index: Text3.cpp
===
--- Text3.cpp (revision 18813)
+++ Text3.cpp (working copy)
@@ -973,7 +973,7 @@
docstring hexstring = cmd.argument();
if (lyx::sup
Jean-Marc Lasgouttes wrote:
> But it would only trigger if the minibuffer toolbar is in auto mode.
I understood. However, this would be an enhancement, not a contradicting
approach.
> I'll try to implement it later to see if it really makes sense.
It might make sense indeed, and s
>>>>> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Another con is that some people do not like the lyxview area
Jürgen> to be resized (which happens if the minibuffer hides), so I
Jürgen> wouldn't make this the general behaviour
Abdelrazak Younes wrote:
> OK, then call it hideParent() or hideToolbar() so that we know that this
> is really the toolbar that we're hiding.
done (hideParent()).
> > I have counted a slight majority for my solution, so I'll put it in.
>
> Fine.
done.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
but this interferes with Qt::widget->hide().
So? You don't need QWidget::hide() so better use it.
I had it called hide() in the first place, which resulted in unexpected
behaviour (all the widgets on the minibuffer disappeared, but
Abdelrazak Younes wrote:
> > but this interferes with Qt::widget->hide().
>
> So? You don't need QWidget::hide() so better use it.
I had it called hide() in the first place, which resulted in unexpected
behaviour (all the widgets on the minibuffer disappeared, but not the
m
ed to M-x for closing. If someone changes the shortcut
for "command-execute" in the bind-file to something else, opening and closing
the minibuffer will have different shortcuts. Ideally, if the shortcut for
opening is customized, the one for closing should be adapted likewise.
Ah..
t's hardcoded to M-x for closing. If someone changes the shortcut
for "command-execute" in the bind-file to something else, opening and closing
the minibuffer will have different shortcuts. Ideally, if the shortcut for
opening is customized, the one for closing should be adapted lik
Jürgen Spitzmüller wrote:
the attached patch implements a shortcut which leaves and closes the
minibuffer. It's hardcoded to M-x[1] and (intentionally) only works when the
cursor is inside the command buffer. So the behaviour would be
- cursor in main view
=> M-x opens the minibu
Jean-Marc Lasgouttes wrote:
> Would it be enough to be sure that the existing autotoolbars scheme
> makes the minibuffer toggle on/off as needed?
I'd prefer manual control.
Jürgen
[EMAIL PROTECTED] wrote:
> > personally i would prefer that the minibuffer would auto hide if it
> > looses focus (or after enter)...
>
> A few times I've copied-and-pasted things to the mini-buffer, i.e. long
> command sequences. Here it would have been annoying if it
Edwin Leuven wrote:
> perhaps we should simply have a toggleToolbar(string toolbarname)
> function/slot?
We have this.
Jürgen
>>>>> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> On Saturday 28 April 2007 9:45:37 am Jürgen Spitzmüller wrote:
>> - cursor in minbuffer => M-x leaves the minibuffer and closes it
Edwin> personally i would prefer that the minibuffer
perhaps we should simply have a toggleToolbar(string toolbarname)
function/slot?
On Sat, 28 Apr 2007, Edwin Leuven wrote:
On Saturday 28 April 2007 9:45:37 am Jürgen Spitzmüller wrote:
- cursor in minbuffer
=> M-x leaves the minibuffer and closes it
personally i would prefer that the minibuffer would auto hide if it
looses focus (or after enter)...
A few times I
On Saturday 28 April 2007 9:45:37 am Jürgen Spitzmüller wrote:
- cursor in minbuffer
=> M-x leaves the minibuffer and closes it
personally i would prefer that the minibuffer would auto hide if it
looses focus (or after enter)...
On Saturday 28 April 2007 9:45:37 am Jürgen Spitzmüller wrote:
> the attached patch implements a shortcut which leaves and closes the
> minibuffer. It's hardcoded to M-x[1] and (intentionally) only works when
> the cursor is inside the command buffer. So the behaviour would be
>
&
the attached patch implements a shortcut which leaves and closes the
minibuffer. It's hardcoded to M-x[1] and (intentionally) only works when the
cursor is inside the command buffer. So the behaviour would be
- cursor in main view
=> M-x opens the minibuffer, if necessary, and e
On Wednesday 21 February 2007 10:34:19 pm Andre Poenitz wrote:
> José, is this 1.5 stuff or for later?
How much code does it implies?
> Andre'
--
José Abílio
On Tue, Feb 20, 2007 at 08:47:03PM +0100, Georg Baum wrote:
> > So 16 and 22 then? The 22 can be padded automagically to 24 on Windows.
>
> Fine with me.
José, is this 1.5 stuff or for later?
Andre'
On Wed, Feb 21, 2007 at 09:34:00AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Ok. So how should we distinguish the two sets?
> >
> > svn cp images/* images/16/*
> > svn mv images/* images/22/*
> >
> > (For suitable values of '*')?
>
> Again I would follow kde:
>
> 16x16 and 22x22
On Wednesday 21 February 2007 8:34:00 am Georg Baum wrote:
> 16x16 and 22x22 as directory names. And I would take the opportunity to
> move from xpm to png, so no direct copying. And we could also copy those
> icons that came originally from kde icons in the right sizes again, that
> would save us
Andre Poenitz wrote:
> Ok. So how should we distinguish the two sets?
>
> svn cp images/* images/16/*
> svn mv images/* images/22/*
>
> (For suitable values of '*')?
Again I would follow kde:
16x16 and 22x22 as directory names. And I would take the opportunity to move
from xpm to png, so no
On Tue, Feb 20, 2007 at 08:47:03PM +0100, Georg Baum wrote:
> Am Montag, 19. Februar 2007 20:28 schrieb Andre Poenitz:
> > On Mon, Feb 19, 2007 at 08:03:34PM +0100, Georg Baum wrote:
> > > Am Montag, 19. Februar 2007 18:45 schrieb Andre Poenitz:
> > >
> > > > Have we settled on a list of wanted si
Am Montag, 19. Februar 2007 20:28 schrieb Andre Poenitz:
> On Mon, Feb 19, 2007 at 08:03:34PM +0100, Georg Baum wrote:
> > Am Montag, 19. Februar 2007 18:45 schrieb Andre Poenitz:
> >
> > > Have we settled on a list of wanted sizes?
> >
> > Not yet.
> >
> > > 18, 24, 32 perhaps?
> >
> > Accord
On Mon, Feb 19, 2007 at 08:03:34PM +0100, Georg Baum wrote:
> Am Montag, 19. Februar 2007 18:45 schrieb Andre Poenitz:
>
> > Have we settled on a list of wanted sizes?
>
> Not yet.
>
> > 18, 24, 32 perhaps?
>
> According to this thread
> http://marc.theaimsgroup.com/?l=lyx-devel&m=11648316642
Am Montag, 19. Februar 2007 18:45 schrieb Andre Poenitz:
> Have we settled on a list of wanted sizes?
Not yet.
> 18, 24, 32 perhaps?
According to this thread
http://marc.theaimsgroup.com/?l=lyx-devel&m=116483166427366&w=3
16, 24, 32 and 48 are the standard icon sizes on windows, while KDE al
tch reduces the size of the up and down button in the
> > > > minibuffer toolbar.
> > > >
> > > > Comments?
> > >
> > > This is a general problem with all icons that should be fixed in
> general.
> >
> > In this particular inst
Am Sonntag, 18. Februar 2007 19:32 schrieb Andre Poenitz:
> On Sun, Feb 18, 2007 at 04:38:44PM +0100, Georg Baum wrote:
> > Am Sonntag, 18. Februar 2007 15:51 schrieb Andre Poenitz:
> > > Attached patch reduces the size of the up and down button in the
> &
On Sun, Feb 18, 2007 at 04:38:44PM +0100, Georg Baum wrote:
> Am Sonntag, 18. Februar 2007 15:51 schrieb Andre Poenitz:
> > Attached patch reduces the size of the up and down button in the
> > minibuffer toolbar.
> >
> > Comments?
>
> This is a general problem wi
Am Sonntag, 18. Februar 2007 15:51 schrieb Andre Poenitz:
> Attached patch reduces the size of the up and down button in the
> minibuffer toolbar.
>
> Comments?
This is a general problem with all icons that should be fixed in general.
The icons where displayed using the original
Attached patch reduces the size of the up and down button in the
minibuffer toolbar.
Comments?
Andre'
Index: QCommandBuffer.C
===
--- QCommandBuffer.C(revision 17238)
+++ QCommandBuffer.C(working copy)
@@ -83,10 +
Am Samstag, 18. November 2006 18:09 schrieb Andre Poenitz:
> In any case, this one is serious. No Newbie would think of deleting
> .lyx/session just get LyX up.
Yes. since the session file could be corrupted by other means it should be
read in a fault tolerant way, i.e. if something invalid is en
John Levon wrote:
On Sun, Nov 19, 2006 at 04:29:54PM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sat, Nov 18, 2006 at 07:30:41AM -0600, Bo Peng wrote:
Having the minibuffer as tollbar is ugly and eats screen real estate for
no good reason. Should be merged with the status line
On Sun, Nov 19, 2006 at 04:29:54PM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Sat, Nov 18, 2006 at 07:30:41AM -0600, Bo Peng wrote:
> >>>Having the minibuffer as tollbar is ugly and eats screen real estate for
> >>>no good reason. Should be m
Andre Poenitz wrote:
On Sat, Nov 18, 2006 at 07:30:41AM -0600, Bo Peng wrote:
Having the minibuffer as tollbar is ugly and eats screen real estate for
no good reason. Should be merged with the status line.
I agree, but having a editable status line is kind of peculiar.
Any decent editor seem
On Sat, Nov 18, 2006 at 07:30:41AM -0600, Bo Peng wrote:
> >Having the minibuffer as tollbar is ugly and eats screen real estate for
> >no good reason. Should be merged with the status line.
>
> I agree, but having a editable status line is kind of peculiar.
Any decent editor s
I do not really like the idea of showing minibuffer with M-x but it
may be better than getting rid of M-x altogether, at least for power
users.
I have two patches: The first is needed anyway, and fixes the problem
so I applied it. The second patch removes M-x. It has no chance of
getting
1 - 100 of 262 matches
Mail list logo
