On Sun, Feb 04, 2007 at 11:02:07PM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >>And how many full-time people do you have to provide these 15
> >>versions for linux?
> >
> >Took me about two weeks full-time to set up all the virtual machines
> >(i.e. install OS, install required deve
On Sun, Feb 04, 2007 at 11:20:20PM +0100, [EMAIL PROTECTED] wrote:
> On Sun, 4 Feb 2007, Abdelrazak Younes wrote:
>
> >And could you do that for LyX? That would be very nice...
>
> Somewhat related (as we're already off-topic), it'd probably be a good
> idea testing the Windows installers in vir
On Sun, 4 Feb 2007, Abdelrazak Younes wrote:
And could you do that for LyX? That would be very nice...
Somewhat related (as we're already off-topic), it'd probably be a good
idea testing the Windows installers in virtual machines. Then it'd be
relatively easy to start from the same situation
Andre Poenitz wrote:
On Fri, Feb 02, 2007 at 09:42:23AM +0100, Jean-Marc Lasgouttes wrote:
"Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> We are currently releasing a new version of my day job's
Andre> bread-and-butter product for four versions of Windows and
Andre> fifteen(!) vari
On Sun, 4 Feb 2007, Andre Poenitz wrote:
Took me about two weeks full-time to set up all the virtual machines
(i.e. install OS, install required development packages, work around
installation quirks etc.) Now a full recompile of our stuff is a bit
more than an hour per platform, and about doub
On Fri, Feb 02, 2007 at 09:42:23AM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
> Andre> We are currently releasing a new version of my day job's
> Andre> bread-and-butter product for four versions of Windows and
> Andre> fifteen(!) variations of L
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> We are currently releasing a new version of my day job's
Andre> bread-and-butter product for four versions of Windows and
Andre> fifteen(!) variations of Linux. And yes, there are Qt 4.2 based
Andre> components in there.
And how man
So just because you refuse to use basic Qt 4.0 functionality we require
Qt 4.2.2 just to be able to uses a homegrown solution?
Yes. This is what I did because I could not find any better way.
If you are confident that saveState/restoreState can fit in our
backend <-> frontend <-> qt4 structure,
On Tue, Jan 30, 2007 at 09:48:23AM +1800, Bo Peng wrote:
> >Nonsense. It would be impossible to maintain that.
>
> Sounds reasonable. Jurgen or I will wrap the code. (I have no idea how
> to tell qt version now). This will leave this bug WONTFIX for qt <
> 4.2.2.
So just because you refuse to use
On Mon, Jan 29, 2007 at 04:24:24PM +0100, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> Bo> On 1/30/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> >> Georg Baum wrote: > No, it is not.
> >>
> >> So plesae, Bo, enclose your changes in #ifdef's. Breaking o
Bo Peng wrote:
If Bo has the energy and the time to do implement that, that would be a
killer feature!
If, like word, each window has its own buffers, I will be motivated
(forced?) to do it. However, for lyx, all windows have the same set of
buffers and there is no real need for multiple initia
If Bo has the energy and the time to do implement that, that would be a
killer feature!
If, like word, each window has its own buffers, I will be motivated
(forced?) to do it. However, for lyx, all windows have the same set of
buffers and there is no real need for multiple initial windows.
I ag
José Matos wrote:
On Tuesday 30 January 2007 3:20:18 pm Abdelrazak Younes wrote:
But we could...
And we will not before next beta.
Fine. I was not proposing to do it anyway ;-)
I am not so sure about the final version of 1.5.0...
If Bo has the energy and the time to do implement that, t
I am not sure I follow your discussion very well but please don't forget
something: multi-view!
This has to be saved for later.
The session info should be read on start-up and written on exit
following the last opened window, that's all there is to it. Everything
in-between should use real, on
On Tuesday 30 January 2007 3:20:18 pm Abdelrazak Younes wrote:
> But we could...
And we will not before next beta.
I am not so sure about the final version of 1.5.0...
--
José Abílio
Bo Peng wrote:
Only the last window state will be saved.
We do not start multiple windows automatically.
But we could...
so this makes sense.
Bo
Bo Peng wrote:
> OK. I will take care of this. My time is also limited though.
Thanks.
Could you merge the attached patch in your tree first (and modify, if you
think so)? Else solving the conflicts will be a pain probably.
Jürgen
Index: src/frontends/qt4/GuiView.C
==
Only the last window state will be saved.
We do not start multiple windows automatically so this makes sense.
Bo
Could you have a go at this, please? I'm running out of time ATM.
OK. I will take care of this. My time is also limited though.
Bo
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Bo, Jurgen, I am not sure I follow your discussion very
Abdelrazak> well but please don't forget something: multi-view!
Abdelrazak> The session info should be read on
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Bo, Jurgen, I am not sure I follow your discussion very
Abdelrazak> well but please don't forget something: multi-view!
Abdelrazak> The session info should be read on start-up and written on
A
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Bo, Jurgen, I am not sure I follow your discussion very
Abdelrazak> well but please don't forget something: multi-view!
Abdelrazak> The session info should be read on start-up and written on
Abdelrazak> exit following
Bo Peng wrote:
> Then, in frontends/Toolbars.C, Toobars::init(),
>
> inifFlags of all the toolbars
> load session for all 'ON' (or all?) toolbars
> for each dock:
> add toolbars in order, according to session info
>
> We should also change Toolbars::add(name) to Toolbars::add(name, dock,
> line)
Abdelrazak Younes wrote:
> Would it be possible to delay those advanced toolbar placement up until
> these are known? I guess that is after WorkArea::redraw().
That would be ideal (I haven't checked that yet). Ideally, the toolbar
placement would have to be redone after each resize event (this wo
That's what we should do anyway. Else the whole session thing is wrong as soon
as a user swaps the order.
Then, in frontends/Toolbars.C, Toobars::init(),
inifFlags of all the toolbars
load session for all 'ON' (or all?) toolbars
for each dock:
add toolbars in order, according to session info
Bo, Jurgen,
I am not sure I follow your discussion very well but please don't forget
something: multi-view!
The session info should be read on start-up and written on exit
following the last opened window, that's all there is to it. Everything
in-between should use real, on-screen, values.
Bo Peng wrote:
> val = session().sessionInfo().load("WindowHeight", false);
Thanks, that works much better. See attached patch.
Jürgen
Index: src/frontends/qt4/GuiView.C
===
--- src/frontends/qt4/GuiView.C (Revision 16927)
+++ src/fr
Bo Peng wrote:
> > But what happens if a short toolbar (not in its own line) becomes longer
> > because a user has added some actions? Or vice versa, if he removes some
> > actions and makes it shorter?
>
> Then we still try to follow suggestions from session and put
> shortened/longered toolbars t
Bo Peng wrote:
> Session saved toolbar size is the real size. If a short toolbar
> occupies the whole line, its width is the whole line. Then, two short
> toolbars in different lines will have long widths saved in session,
> which then tells us to put them into two separate lines during
> restorati
I don't think this is a good idea. As soon as the user changes the toolbar,
this data becomes invalid. And it is no problem to get the width on the fly.
Session saved toolbar size is the real size. If a short toolbar
occupies the whole line, its width is the whole line. Then, two short
toolbars
Bo Peng wrote:
> Actually, with the attached patch, real toolbar width and height is
> saved to session so you should get enough information about previous
> layout.
I don't think this is a good idea. As soon as the user changes the toolbar,
this data becomes invalid. And it is no problem to get
Already done.
The patch defines ToolbarSize but how would you fill the information?
Actually, with the attached patch, real toolbar width and height is
saved to session so you should get enough information about previous
layout.
With your approach, short \n short ==> short short. With real widt
Bo Peng wrote:
> Sounds reasonable. Jurgen or I will wrap the code. (I have no idea how
> to tell qt version now).
Already done.
Jürgen
Nonsense. It would be impossible to maintain that.
Sounds reasonable. Jurgen or I will wrap the code. (I have no idea how
to tell qt version now). This will leave this bug WONTFIX for qt <
4.2.2.
Bo
Bo Peng wrote:
> Please add them when you are implementing your patch. I did not do it
> because I thought that we are going to bundle qt libs with lyx on all
> platforms. After all, qt4 is not standard on any platform.
Nonsense. It would be impossible to maintain that. I was told several times
t
Sorry, I don't understand. Could you elaborate?
Window geometry is supposed to be used once so in src/lyx_main.C
val = session().sessionInfo().load("WindowHeight");
is called with a second default parameter release=true. Then,
"WindowHeight" is removed from session and you are supposed
Bo Peng wrote:
> Please add them when you are implementing your patch. I did not do it
> because I thought that we are going to bundle qt libs with lyx on all
> platforms.
I don't think we'll do that on Linux. And as of distributions, we have no say
about which qt version they gonna compile LyX a
Bo Peng wrote:
> There is one trick here. Session Geometry is released when it is used
> once (to save a few bytes of ram), you will need to change a previous
> call to load(key, false) to be able to load it again.
Sorry, I don't understand. Could you elaborate?
> What session file provies you ar
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> On 1/30/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
>> Georg Baum wrote: > No, it is not.
>>
>> So plesae, Bo, enclose your changes in #ifdef's. Breaking older qt
>> versions is not acceptable IMHO.
Bo> Please add them when you are impl
On 1/30/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Georg Baum wrote:
> No, it is not.
So plesae, Bo, enclose your changes in #ifdef's. Breaking older qt versions is
not acceptable IMHO.
Please add them when you are implementing your patch. I did not do it
because I thought that we are g
not known yet at this stage. I tried to read the session file directly, but
all I get are empty values.
There is one trick here. Session Geometry is released when it is used
once (to save a few bytes of ram), you will need to change a previous
call to load(key, false) to be able to load it again
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Bad... Then I suggest to use WorkArea::width() or
BufferView::workWidth() and add some pixels to take the scrollbar into
account.
Doesn't work either. The problem seems to be that the actual dimensions are
not known yet at this stage.
Would
Abdelrazak Younes wrote:
> Bad... Then I suggest to use WorkArea::width() or
> BufferView::workWidth() and add some pixels to take the scrollbar into
> account.
Doesn't work either. The problem seems to be that the actual dimensions are
not known yet at this stage. I tried to read the session fil
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I guess that when it is maximized, Qt has no way to know its size under
X11 as this is handled by the Window manager. In this case, you'd better
take the width of the GuiWorkArea (but not WorkArea::width as this would
give you the width of the c
Jürgen Spitzmüller wrote:
> I don't think so, but I think the attached patch probably will.
> Georg, could you test this?
Maybe tonight.
Georg
Abdelrazak Younes wrote:
> Your patch will solve that, won't it?
I don't think so, but I think the attached patch probably will.
Georg, could you test this?
Jürgen
Index: src/frontends/qt4/GuiView.C
===
--- src/frontends/qt4/GuiView.
Abdelrazak Younes wrote:
> I guess that when it is maximized, Qt has no way to know its size under
> X11 as this is handled by the Window manager. In this case, you'd better
> take the width of the GuiWorkArea (but not WorkArea::width as this would
> give you the width of the content pane).
In fac
Jürgen Spitzmüller wrote:
Georg Baum wrote:
No, it is not.
So plesae, Bo, enclose your changes in #ifdef's. Breaking older qt versions is
not acceptable IMHO.
Your patch will solve that, won't it? In which case, I'd say just commit
your patch.
Abdel.
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Why? WorkArea::width should always gives you the true width of the
content pane (excluding scrollbar). But I think that for toobar purpose
you'd rather need the width of the _window_ instead. This is given to
you by GuiView::width(). You can cre
Georg Baum wrote:
> No, it is not.
So plesae, Bo, enclose your changes in #ifdef's. Breaking older qt versions is
not acceptable IMHO.
Jürgen
Jürgen Spitzmüller wrote:
> Bo Peng wrote:
>> But if you ever want to insert the break at non-TOP dock, 4.2.2 is
>> required.
>
> What happens if you use an older version? Is LyX still usable (else, we
> have to use #ifdef's IMO)?
No, it is not. The view toolbar is currently always over the file
Abdelrazak Younes wrote:
> Why? WorkArea::width should always gives you the true width of the
> content pane (excluding scrollbar). But I think that for toobar purpose
> you'd rather need the width of the _window_ instead. This is given to
> you by GuiView::width(). You can create a new pure virtua
Jürgen Spitzmüller wrote:
Bo Peng wrote:
But if you ever want to insert the break at non-TOP dock, 4.2.2 is
required.
What happens if you use an older version? Is LyX still usable (else, we have
to use #ifdef's IMO)?
As already announced, I have a different solution in the pipe (only
inser
Bo Peng wrote:
> But if you ever want to insert the break at non-TOP dock, 4.2.2 is
> required.
What happens if you use an older version? Is LyX still usable (else, we have
to use #ifdef's IMO)?
> > As already announced, I have a different solution in the pipe (only
> > inserting ToolbarBreaks i
On 1/28/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
> The problem is partially fixed, but
>
> 1. qt >= 4.2.2 is required
This is bad.
But if you ever want to insert the break at non-TOP dock, 4.2.2 is required.
As already announced, I have a different solution in the pip
Bo Peng wrote:
> The problem is partially fixed, but
>
> 1. qt >= 4.2.2 is required
This is bad.
> 2. toolbars on the same line are restored to different lines
This is bad as well.
As already announced, I have a different solution in the pipe (only inserting
ToolbarBreaks if the toolbar exceed
On Sat, Jan 27, 2007 at 04:18:45PM +1800, Bo Peng wrote:
> >My approach would be to simply erase all session stuff related to
> >toolbar appearance and positioning and just Qt integrated support.
>
> What I am not quite sure is about the interaction between backend and
> frontend. You see, addTool
Unfortunately, LyX don't remember the position completely.
The problem is partially fixed, but
1. qt >= 4.2.2 is required
2. toolbars on the same line are restored to different lines
I also save posx, posy to session but they can not be restored yet
because move(posx, posy) does not work for t
I think that the problem is that Qt4 does not allow this kind of (x,y)
positionning of the toolbars. Qt4 just needs to know the logical
position (top, bottom, left, or right) of the toolbars and the order.
I am not quite sure. As I have said, if you stop at show(), with an
added move() call, the
Bo Peng wrote:
> I agree with you but right now, the easy solution may be what I have
> suggested. Moving frontend/MLToolbar to qt4/ is something for later.
Agreed.
Abdel,
I can not figure out how to restore toolbar position. (move does not
seem to work).
I think that the problem is that Qt
Abdelrazak Younes wrote:
> > Now, if you really want to use the saveState and restoreState
> > functions, session itself is not a problem. You can choose to add a
> > binary field to ToolbarSection::ToolbarInfo, or use saveSessionInfo to
> > save a string-repsentation of QByteArray.
> >
> > You th
> I agree with you but right now, the easy solution may be what I have
> suggested. Moving frontend/MLToolbar to qt4/ is something for later.
Agreed.
Abdel,
I can not figure out how to restore toolbar position. (move does not
seem to work).
The attached patch add posx, posy to
Session::Toolba
If only you agreed with me when you started this toolbar session
management... ;-)
At that time, qt3 and xform were still alive and there is no saveState for them.
Bo
Bo Peng wrote:
The toolback backend should only be for reading ui files and checking
status. Everything related to appearance, including toolbar
showing.hiding, should be frontend specific. This has really nothing to
do in the backend. The backend shouldn't even know about it.
I agree with you
The toolback backend should only be for reading ui files and checking
status. Everything related to appearance, including toolbar
showing.hiding, should be frontend specific. This has really nothing to
do in the backend. The backend shouldn't even know about it.
I agree with you but right now, t
Bo Peng wrote:
My approach would be to simply erase all session stuff related to
toolbar appearance and positioning and just Qt integrated support.
What I am not quite sure is about the interaction between backend and
frontend. You see, addToolbar etc is done in the backend and display
is done
My approach would be to simply erase all session stuff related to
toolbar appearance and positioning and just Qt integrated support.
What I am not quite sure is about the interaction between backend and
frontend. You see, addToolbar etc is done in the backend and display
is done from the fronten
Bo Peng wrote:
> You then need to make sure your restoreState work with all our backend
> code for toolbars (addToolbar etc).
This looks like a good plan ;-)
I would rather go another way. Namely, figure out
1. location (left, top etc), already done.
2. line (first, second line etc)
3. positi
Bo Peng <[EMAIL PROTECTED]> writes:
> > > You then need to make sure your restoreState work with all our backend
> > > code for toolbars (addToolbar etc).
> I would rather go another way. Namely, figure out
So, what's the disadvantage of doing what Abdel proposes and letting each
frontend deal w
> You then need to make sure your restoreState work with all our backend
> code for toolbars (addToolbar etc).
This looks like a good plan ;-)
I would rather go another way. Namely, figure out
1. location (left, top etc), already done.
2. line (first, second line etc)
3. position at a line
an
Bo Peng wrote:
Man, the moment you start copying Qt I suggest to simply use Qt.
Sorry Bo, but this looks a bit masochistic to me.
I fully understand your feeling. :-)
Now, if you really want to use the saveState and restoreState
functions, session itself is not a problem. You can choose to a
Man, the moment you start copying Qt I suggest to simply use Qt.
Sorry Bo, but this looks a bit masochistic to me.
I fully understand your feeling. :-)
Now, if you really want to use the saveState and restoreState
functions, session itself is not a problem. You can choose to add a
binary fiel
Bo Peng wrote:
The simple answer is that because (future) frontend XXX does not have
saveState. As a matter of fact, even qt 3 does not have it.
Then for this hypothetical platform you will have to implement the feature.
So, what is needed:
1. add some fields to Session::ToolbarSection::To
The simple answer is that because (future) frontend XXX does not have
saveState. As a matter of fact, even qt 3 does not have it.
So, what is needed:
1. add some fields to Session::ToolbarSection::ToolbarInfo which is
supposed to be a superset of info that different frontends choose to
use.
2.
what do you mean by "overlapping"? Isn't the problem that you just store the
area, not the position within the area?
I mean, disable multiple toolbars on the same Line (Qt term). Then, we
do not need to save position.
Why don't we store QMainWindow::saveState?
The simple answer is that becau
Bo Peng wrote:
> That is great. The problem is that toolbars can overlap with each
> other but session does not record such information
what do you mean by "overlapping"? Isn't the problem that you just store the
area, not the position within the area?
> (QKToolbar::saveInfo). In this particular
> Is this easy, or do you want a bugzilla entry?
There's already a bugzilla entry.
I have a half-finished patch in the pipe.
That is great. The problem is that toolbars can overlap with each
other but session does not record such information
(QKToolbar::saveInfo). In this particular example, to
Helge Hafting wrote:
> Is this easy, or do you want a bugzilla entry?
There's already a bugzilla entry.
I have a half-finished patch in the pipe.
Jürgen
78 matches
Mail list logo
