Uwe Stöhr wrote:
> Can you please open a regression bug report so that Abdel won't forget to
> fix this?
this is now:
http://www.lyx.org/trac/ticket/6364
pavel
Abdelrazak Younes wrote:
>>> The one sane way to solve this rapidly is to create a new dialog for
>>> that as I outlined earlier. Should be quite easy but I don't have the
>>> time...
>>
>> Or use the support for tristate checkbox that exists in qt.
>
> From an ui point of view tristate checkbox in
Abdelrazak Younes writes:
>> Or use the support for tristate checkbox that exists in qt.
>
> From an ui point of view tristate checkbox in menu is very very bad IMO.
Fair enough.
JMarc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
The one sane way to solve this rapidly is to create a new dialog for
that as I outlined earlier. Should be quite easy but I don't have the
time...
Or use the support for tristate checkbox that exists in qt.
From an ui point of
Abdelrazak Younes writes:
> The one sane way to solve this rapidly is to create a new dialog for
> that as I outlined earlier. Should be quite easy but I don't have the
> time...
Or use the support for tristate checkbox that exists in qt.
JMarc
Pavel Sanda wrote:
Abdelrazak Younes wrote:
bisect leads to r24954:
commit 7fd567d187e51c6168dfb4af991ee6aff82f
Author: younes
Date: Tue May 27 11:15:17 2008 +
Re-engineer the toolbar support code:
- We now rely more upon Qt features,
- the initial toolbar positioning
Abdelrazak Younes wrote:
>>> bisect leads to r24954:
>>> commit 7fd567d187e51c6168dfb4af991ee6aff82f
>>> Author: younes
>>> Date: Tue May 27 11:15:17 2008 +
>>>
>>> Re-engineer the toolbar support code:
>>> - We now rely more upon Qt features,
>>> - the initial toolbar positi
Uwe Stöhr wrote:
Abdelrazak Younes schrieb:
and also 4 radio buttons for the position in the window.
Why that? When the menubar is shown I drag it to a position of my
choice. Even when it is in the auto mode, the toolbar will then appear
at the wanted position.
Maybe it's needed... But so
Abdelrazak Younes schrieb:
OK, I guess this is an ui description problem as the three possible
states are still possible:
Yes, the problem is that the label "auto" indicates that it is in auto state while this is not
always the case.
The problem is that this menubar access is very bad. We n
e cursor is inside a formula
OK, I guess this is an ui description problem as the three possible
states are still possible:
When you are in math mode and the math toolbar is auto, you can disable
it by invoking the menu. When you are *not* in math mode and the toolbar
is auto you can enab
Abdelrazak Younes schrieb:
First we have to agree that there is something to fix.
What we need to fix is:
- use the menu View->Toolbar to deactivate the math toolbars
Result: the checkmark is correctly removed and the menu entry contains "(auto)"
- now try to change the state from auto to c
Uwe Stöhr wrote:
Pavel Sanda schrieb:
bisect leads to r24954:
commit 7fd567d187e51c6168dfb4af991ee6aff82f
Author: younes
Date: Tue May 27 11:15:17 2008 +
Re-engineer the toolbar support code:
- We now rely more upon Qt features,
- the initial toolbar positioning defined
Pavel Sanda schrieb:
bisect leads to r24954:
commit 7fd567d187e51c6168dfb4af991ee6aff82f
Author: younes
Date: Tue May 27 11:15:17 2008 +
Re-engineer the toolbar support code:
- We now rely more upon Qt features,
- the initial toolbar positioning defined in "lib/ui/default
after this commit tristate in menu for toolbars no more works.
Yes, and I complained about it at the time.
JMarc
Pavel Sanda wrote:
> Richard Heck wrote:
> > On 11/30/2009 06:15 PM, Uwe Stöhr wrote:
> >> rgheck schrieb:
> >>
> >>>> Use the menu View->Toolbars or alternatively the toolbar button at the
> >>>> right of the main toolbar that
David Raymond wrote:
> One minor problem: When adding math to the end of a file, the
> automatic popup of the toolbar (which I like very much) partially
> covers the math box until one starts typing math. If the math panel
> is also activated, it completely covers the box. The box pops into
> vie
I use math a lot in lyx, and it would seem simpler to me to combine
the math toolbar and the math panel into a single, double-decker
toolbar. I find myself using the panel as much as the toolbar, and I
am not sure why they are separated.
One minor problem: When adding math to the end of a file
Pavel Sanda wrote:
hi,
in short the problem is that at the end of lyxfunc dispatch we firstly
processUpdateFlags and after we do restartCursor() which in turn updates
toolbar, which toggling-on hides the cursor. moving processUpdateFlags after
restartCursor leads to crashes.
the following patch
hi,
in short the problem is that at the end of lyxfunc dispatch we firstly
processUpdateFlags and after we do restartCursor() which in turn updates
toolbar, which toggling-on hides the cursor. moving processUpdateFlags after
restartCursor leads to crashes.
the following patch is a workaround for
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Well, I have to confess that I hate this menu based UI. The only sane
>> UI for this would be a context menu with three radio buttons
>> (on/off/auto) for all available toolbar. The default Qt toolb
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Well, I have to confess that I hate this menu based UI. The only sane
> UI for this would be a context menu with three radio buttons
> (on/off/auto) for all available toolbar. The default Qt toolbar menu
> is good but is disabled because of the icon s
end with the
GUI, the information is now lost. I think the new behaviour does not
make sense...
After getting a vehement complaint from Abdel, I got to try out again
the behaviour of the toolbars ;) The situation now is that auto toolbars
(like the math toolbar) have two possible positions: auto
the information is now lost. I think the new behaviour does not
> make sense...
After getting a vehement complaint from Abdel, I got to try out again
the behaviour of the toolbars ;) The situation now is that auto toolbars
(like the math toolbar) have two possible positions: auto and off. In
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Neal Becker<[EMAIL PROTECTED]> writes:
Neal Becker wrote:
Does 'auto' work?
When I choose math (auto), with cursor in plain text, math toolbar is
still there.
Actually, IMO the design is really confusing. What does
Jean-Marc Lasgouttes wrote:
Neal Becker<[EMAIL PROTECTED]> writes:
Neal Becker wrote:
Does 'auto' work?
When I choose math (auto), with cursor in plain text, math toolbar is
still there.
Actually, IMO the design is really confusing. What does 'chec
Neal Becker <[EMAIL PROTECTED]> writes:
> Neal Becker wrote:
>
>> Does 'auto' work?
>>
>> When I choose math (auto), with cursor in plain text, math toolbar is
>> still there.
>
> Actually, IMO the design is really confusing. What does &#x
Neal Becker wrote:
> Does 'auto' work?
>
> When I choose math (auto), with cursor in plain text, math toolbar is
> still there.
Actually, IMO the design is really confusing. What does 'checking' math(auto)
mean?
According to the math manual, it's au
Does 'auto' work?
When I choose math (auto), with cursor in plain text, math toolbar is still
there.
> Having icons for actions is always a good thing; e.g. a user might want to
> customize his toolbar etc.
As said I'll add them as soon as somebody proposed some icons.
regards Uwe
Am Mittwoch, 23. Januar 2008 09:33:18 schrieb Jean-Marc Lasgouttes:
> Uwe Stöhr <[EMAIL PROTECTED]> writes:
> > The math toolbar misses a submenu where the user can insert the following
> > boxes \fbox, \framebox, \mbox, \makebox, and \boxed
> >
> > Has anyb
Jean-Marc Lasgouttes schrieb:
OK, but we should have at least have two icons for \fbox and \boxed.
Could you recall what \boxed does?
\fbox : to frame inline formulas
\boxed : to frame displayed formulas
Both are already supported by mathed, only a math toolbar icon is missing.
regards
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes schrieb:
>
>> Do we need all of these boxes in the toolbar? If somebody understands
>> the difference between \fbox and \framebox, he is probably able to
>> just type the macro name.
>
> OK, but we should have at least have two icons for
Jean-Marc Lasgouttes schrieb:
Do we need all of these boxes in the toolbar? If somebody understands
the difference between \fbox and \framebox, he is probably able to
just type the macro name.
OK, but we should have at least have two icons for \fbox and \boxed.
regards Uwe
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> The math toolbar misses a submenu where the user can insert the following
> boxes
> \fbox, \framebox, \mbox, \makebox, and \boxed
>
> Has anybody a proposal for icons for them?
Do we need all of these boxes in the toolbar? If som
The math toolbar misses a submenu where the user can insert the following boxes
\fbox, \framebox, \mbox, \makebox, and \boxed
Has anybody a proposal for icons for them?
thanks and regards
Uwe
>> The phantom feature is a math feature
>
> No, \phantom, \vphantom and \hphantom are general (plain TeX) commands, which
> also work outside mathed (I use them from time to time).
I know and use them often e.g. also in the EmbeddedObjects manual. But the suport for these comands
is at the mome
On Tue, Nov 06, 2007 at 08:40:19AM +0100, Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
> > > I like this phantom feature a lot myself, but I think it qualifies as
> > > expert feature. I am not sure it belongs to the toolbar, but I do not
> > > oppose it.
> >
> > The phantom feature is a math featu
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> This is not good. The text should be any possible Text Inset (even a
>> font change would make the metrics bad).
>
> Then we need Tommaso's input widget (or a collapsable).
A collapsable separate from the space inset
Jean-Marc Lasgouttes wrote:
> This is not good. The text should be any possible Text Inset (even a
> font change would make the metrics bad).
Then we need Tommaso's input widget (or a collapsable).
Jürgen
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> Where would you put the text?
>
> Like Helge outlined. The dialog would include a combo with all the predefined
> spaces (enspace etc.), then custom for a length (\hspace) and a widget for
> text ("Space in the lengt
Jean-Marc Lasgouttes wrote:
> Where would you put the text?
Like Helge outlined. The dialog would include a combo with all the predefined
spaces (enspace etc.), then custom for a length (\hspace) and a widget for
text ("Space in the length of the following string").
Jürgen
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> I never thought about that... But of course you are right.
>
> I think ui-wise, phantoms should be implemented in a forthcoming InsetSpace
> dialog (in Texted).
Where would you put the text?
JMarc
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
I never thought about that... But of course you are right.
I think ui-wise, phantoms should be implemented in a forthcoming InsetSpace
dialog (in Texted).
Good idea. A dialog like:
_ short space
_ interword space
_ enskip
_ ems
Jean-Marc Lasgouttes wrote:
> I never thought about that... But of course you are right.
I think ui-wise, phantoms should be implemented in a forthcoming InsetSpace
dialog (in Texted).
Jürgen
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
>> The phantom feature is a math feature
>
> No, \phantom, \vphantom and \hphantom are general (plain TeX) commands, which
> also work outside mathed (I use them from time to time).
I never thought about that... But of course you are right.
JMarc
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> I like this phantom feature a lot myself, but I think it qualifies as
>> expert feature. I am not sure it belongs to the toolbar, but I do not
>> oppose it.
>
> The phantom feature is a math feature so it should be accessib
ral (plain TeX) commands, which
also work outside mathed (I use them from time to time).
That's why I wondered how common they are in math (as opposed to text).
> so it should be accessible via the math toolbar.
OK. Put it in, then.
Jürgen
I like this phantom feature a lot myself, but I think it qualifies as
expert feature. I am not sure it belongs to the toolbar, but I do not
oppose it.
The phantom feature is a math feature so it should be accessible via the
math toolbar. The math toolbar contains much more expert stuff than
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Uwe Stöhr wrote:
>> What about the other changes (fraction, placeholders)?
>
> The fraction changes are OK. For the placeholders, I'd like to have some
> input
> from math users first.
I like this phantom feature a lot myself, but I think it qual
Uwe Stöhr wrote:
> What about the other changes (fraction, placeholders)?
The fraction changes are OK. For the placeholders, I'd like to have some input
from math users first.
Jürgen
>> OK I'll postpone this change to LyX 1.6.0.
>
> Yes, please.
What about the other changes (fraction, placeholders)?
Uwe
Uwe Stöhr wrote:
> OK I'll postpone this change to LyX 1.6.0.
Yes, please.
Jürgen
> was the change from "math-insert
> \choose" to "math-insert \binom" intentional? And if so, why?
This is intended because LyX 1.6.0 will have \tbinom and \dbinom. So it will be confusing that the
standard binom command is \choose. \choose is identic to \binom.
OK I'll postpone this change to
Uwe Stöhr wrote:
> The attached patch registeres placeholders to the math toolbar and clarify
> some entries. OK for branch?
As I'm no math user, I do not have strong opinions. I guess \phantom is
useful. Is it also often used? What do others say?
The Fractions changes look good. H
On Sun, Nov 04, 2007 at 08:33:59PM +0100, Uwe Stöhr wrote:
> The attached patch registeres placeholders to the math toolbar and clarify
> some entries.
> OK for branch?
>
> regards Uwe
>
> p.s. lyx.org is currently dead
In deep coma. But I did get a commit through...
- Martin
The attached patch registeres placeholders to the math toolbar and clarify some
entries.
OK for branch?
regards Uwe
p.s. lyx.org is currently dead
Index: stdtoolbars.inc
===
--- stdtoolbars.inc (revision 21421)
+++ stdtoolbars.inc
Sven Schreiber wrote:
> So does this mean the issue is resolved or will it be forgotten unless I
> file a bug?
is resolved.
Jürgen
Selon José Matos <[EMAIL PROTECTED]>:
> On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote:
> > There is actually arguments to give when you insert such a function. I
> > think it is clear enough that no computation will be made (LyX is for
> > writing only).
> >
> > Mael.
>
> Oops, that is not
hzluo schrieb:
> Current install version do not have an icon for functions popup.
>
> I think the patch is on the way.
> We now have a functions.xpm for that button.
> So you will have a 20x20 button instead of a long string.
>
> BTW, I think the provided functions.xpm is not
> so informative. I
On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote:
> There is actually arguments to give when you insert such a function. I
> think it is clear enough that no computation will be made (LyX is for
> writing only).
>
> Mael.
Oops, that is not correct. It can connect to a CAS (like maxima) and ret
Selon "Leuven, E." <[EMAIL PROTECTED]>:
> > What about an "f(x)" symbol?
>
> this suggests to me that there is an argument to give or a function to build,
> and i would expect it more on a toolbar to interface with maple etc (imho of
> course...)
There is actually arguments to give when you inser
Jean-Marc Lasgouttes" <[EMAIL PROTECTED]>; "hzluo" <[EMAIL PROTECTED]>; "LyX
Mechanics"
Sent: Friday, June 08, 2007 11:24 AM
Subject: RE: math toolbar usability suggestion (tiny)
Selon "Leuven, E." <[EMAIL PROTECTED]>:
> What about an &q
Selon Mael Hilléreau <[EMAIL PROTECTED]>:
> > > BTW, I think the provided functions.xpm is not
> > > so informative. I made another one.
> > > Please see attached. If anyone wants to test
> > > it, just put it in images\math
> > > I have tested it at normal size and large size.
> > > It looks good
Selon Alfredo Braunstein <[EMAIL PROTECTED]>:
> hzluo wrote:
>
> >>I am not sure I understand. Do the labels appear under the icons? Do
> >>we support that?
> >>
> >>JMarc
> >
> > Current install version do not have an icon for functions popup.
> >
> > I think the patch is on the way.
> > We now h
> What about an "f(x)" symbol?
this suggests to me that there is an argument to give or a function to build,
and i would expect it more on a toolbar to interface with maple etc (imho of
course...)
hzluo wrote:
>>I am not sure I understand. Do the labels appear under the icons? Do
>>we support that?
>>
>>JMarc
>
> Current install version do not have an icon for functions popup.
>
> I think the patch is on the way.
> We now have a functions.xpm for that button.
> So you will have a 20x20 bu
> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes:
>> Current install version do not have an icon for functions popup.
Edwin> missing entry in scons_manifest and makefile i guess
>> BTW, I think the provided functions.xpm is not so informative. I
>> made another one.
Edwin> i like it.
I lik
> Current install version do not have an icon for functions popup.
missing entry in scons_manifest and makefile i guess
> BTW, I think the provided functions.xpm is not so informative. I made another
> one.
i like it.
josé?
I am not sure I understand. Do the labels appear under the icons? Do
we support that?
JMarc
Current install version do not have an icon for functions popup.
I think the patch is on the way.
We now have a functions.xpm for that button.
So you will have a 20x20 button instead of a long string.
On Sunday 22 April 2007 8:21:39 am Martin Vermeer wrote:
> >
> > sigh, let's standardize on a single language to get rid of is
> > translation business.
> >
> > i suggest dutch...
>
> +1
Being a python fan is for me difficult to disagree. ;-)
$ python -c 'import this' | grep -B1 Dutch
There sho
On Sat, Apr 21, 2007 at 08:51:58PM +0200, Edwin Leuven wrote:
> Edwin Leuven wrote:
> >Edwin Leuven wrote:
> >>Michael Gerz wrote:
> >>>The problem is the double \\ which is collapsed into a single
> >>>\ somewhere in your code. However, in the po files we assume
> >>>that the message has two \\
Neal Becker wrote:
> Sorry, I haven't been following the discussion. I don't see any math
> toolbar. Am I missing something?
Nevermind - found it.
Sorry, I haven't been following the discussion. I don't see any math
toolbar. Am I missing something?
Edwin Leuven schrieb:
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the
translation do not match => no translation.
the attached
Edwin Leuven wrote:
Edwin Leuven wrote:
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the
translation do not match => no translati
Edwin Leuven wrote:
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the
translation do not match => no translation.
the attached th
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the translation
do not match => no translation.
the attached then?
Index: src/front
Michael Gerz schrieb:
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid "Scriptscript (smaller) style\tscriptscriptstyle"
msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle"
However, the German translations
Edwin Leuven schrieb:
Michael Gerz wrote:
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid "Scriptscript (smaller) style\tscriptscriptstyle"
msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle"
However, the
Michael Gerz wrote:
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid "Scriptscript (smaller) style\tscriptscriptstyle"
msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle"
However, the German translations ar
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid "Scriptscript (smaller) style\tscriptscriptstyle"
msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle"
However, the German translations are not shown in the ma
On Thu, Oct 26, 2006 at 09:23:15AM +0200, Abdelrazak Younes wrote:
> Edwin Leuven wrote:
> >Abdelrazak Younes wrote:
> >>I have to find some time to solved it. If someone wants to look at it,
> >>the problem is related to a toolbar separator inserted between the
>
Peter Kümmel wrote:
> Jonathan Vogt wrote:
>> Hi all,
>>
>> first of all thanks for your work and keep it up.
>>
>> I've been compiling the source from subversion for a couple of days now and
>> I
>> noticed that when starting some math the math
Jonathan Vogt wrote:
> Hi all,
>
> first of all thanks for your work and keep it up.
>
> I've been compiling the source from subversion for a couple of days now and I
> noticed that when starting some math the math toolbar shows up (nothing wrong
> with that) but i
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I have to find some time to solved it. If someone wants to look at it,
the problem is related to a toolbar separator inserted between the
table toolbar and the math toolbar. If the cursor goes in math within
the table, you will notice that the two
Abdelrazak Younes wrote:
I have to find some time to solved it. If someone wants to look at it,
the problem is related to a toolbar separator inserted between the table
toolbar and the math toolbar. If the cursor goes in math within the
table, you will notice that the two toolbars show
Jonathan Vogt wrote:
Hi all,
first of all thanks for your work and keep it up.
I've been compiling the source from subversion for a couple of days now and I
noticed that when starting some math the math toolbar shows up (nothing wrong
with that) but it shows up right under the menu b
Hi all,
first of all thanks for your work and keep it up.
I've been compiling the source from subversion for a couple of days now and I
noticed that when starting some math the math toolbar shows up (nothing wrong
with that) but it shows up right under the menu bar.
I also don't k
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now t
Abdelrazak Younes schrieb:
Only qt4 for now... I am willing to adapt gtk to the Toolbars API
change but please, could we once and for all forget about qt3?
A couple of weeks ago, Lars said that he is willing to drop qt3 if qt4
no longer relies on QT3_SUPPORT. Since QT3_SUPPORT has gone, nobody
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now the toolbars are
hard-code
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now the toolbars are
hard-coded to be at the top because
Abdelrazak Younes wrote:
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now the toolbars are
hard-coded to be at the top because I didn't have the time to
John Levon schrieb:
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote:
Why don't we activate the toolbars for now (and for 1.4.3)? The
activation is not a showstopper in case someone wants to optimize the
look & feel later.
Let's activate it for 1.5.0svn and see what happe
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote:
> Why don't we activate the toolbars for now (and for 1.4.3)? The
> activation is not a showstopper in case someone wants to optimize the
> look & feel later.
Let's activate it for 1.5.0svn and see what happens, but not 1.4...
regar
Jean-Marc Lasgouttes schrieb:
John> This is a really difficult one to decide. I can see this being
John> enormously irritating default behaviour for some people, and we
John> don't yet have a View->Toolbars that can easily turn it off. On
John> the other hand, these toolbars are extremely useful.
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote:
>> I think this patch (or a similar one) has been discussed already.
>> Should I commit it?
John> This is a really difficult one to decide. I can see this being
John> enormou
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now the toolbars are
hard-coded to be at the top because I didn't have the time to fix it
properly last chr
On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote:
> I think this patch (or a similar one) has been discussed already. Should
> I commit it?
This is a really difficult one to decide. I can see this being
enormously irritating default behaviour for some people, and we don't
yet have a
Hello,
I think this patch (or a similar one) has been discussed already. Should
I commit it?
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Michael
Index: default.ui
==
1 - 100 of 123 matches
Mail list logo
