I thought there was some QMainWindow::save/restoreState doing something
like this...
There might be but we have multiple frontends. :-) The toolbar on/off
control is independent of frontends.
Bo
On Mon, Oct 16, 2006 at 01:00:51AM -0500, Bo Peng wrote:
> Hi, All
>
> Attached is a patch to save/restore toolbar status. Any opinion? (It
> is qt4 only right now, and is not thoroughly tested).
I thought there was some QMainWindow::save/restoreState doing something
like this...
Andre'
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Anyway, all I'm trying to say, though, is that a single
Juergen> toggle for every toolbar isn't enough, IMHO.
Agreed.
JMarc
Jean-Marc Lasgouttes wrote:
> Juergen> It's not on/off only in KDE. It's a context menu with
> Juergen> detailed settings (position, icon size etc.) for every
> Juergen> toolbar. On/off won't be enough IMO.
>
> Why would we want to do that for *every* toolbar?
It looks most intuitive to me. Of cou
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Joost Verburg wrote:
>> Windows applications also have menu to turn toolbars on/off and a
>> Customize dialog to change the buttons.
Juergen> It's not on/off only in KDE. It's a context menu with
Juergen> detailed settin
Joost Verburg wrote:
> Windows applications also have menu to turn toolbars on/off and a
> Customize dialog to change the buttons.
It's not on/off only in KDE. It's a context menu with detailed settings
(position, icon size etc.) for every toolbar. On/off won't be enough IMO.
Jürgen
Juergen Spitzmueller wrote:
Hm, I just saw that KDE apps have an individual elaborated context menu for
each toolbar (i.e. you can toggle them on/off in "Settings->Toolbars", then
you can do the fine tuning in the context menu). And in the dialog, only the
actions can be customized. This would
John Levon wrote:
> Then we need both, I think, with the dialog under Toolbars->Customize.
> Or consider making the menu items three-state, and just leave the
> position to drag and drop.
Hm, I just saw that KDE apps have an individual elaborated context menu for
each toolbar (i.e. you can toggle
On Mon, Oct 16, 2006 at 06:25:24PM +0200, Juergen Spitzmueller wrote:
> > Why a dialog?
>
> To add, remove and move actions. To set the position.
> And because I don't see a good solution to switch between "on, off, math,
> table" in a menu.
Then we need both, I think, with the dialog under To
John Levon wrote:
> > Joost> Juergen Spitzmueller wrote:
> > >> I think we will get rid of the right click menu in favour of a
> >
> > View-> Toolbars dialog. There, people should also set math/table.
>
> Why a dialog?
To add, remove and move actions. To set the position.
And because I don't see
John Levon wrote:
Why a dialog?
It should be a menu.
Joost
On Mon, Oct 16, 2006 at 05:59:53PM +0200, Jean-Marc Lasgouttes wrote:
> Joost> Juergen Spitzmueller wrote:
> >> I think we will get rid of the right click menu in favour of a
> View-> Toolbars dialog. There, people should also set math/table.
Why a dialog?
> Joost> Don't get rid of it. Keep both
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Juergen Spitzmueller wrote:
>> I think we will get rid of the right click menu in favour of a
View-> Toolbars dialog. There, people should also set math/table.
Joost> Don't get rid of it. Keep both like all other applications do.
Juergen Spitzmueller wrote:
I think we will get rid of the right click menu in favour of a View->Toolbars
dialog. There, people should also set math/table.
Don't get rid of it. Keep both like all other applications do.
Joost
Bo Peng wrote:
> > Do you plan similar functions for the toolbar position? For a toolbar
> > GUI, this needs to be saved, also "math" or "table" (i.e. context
> > sensitive visibility).
>
> I do not know. I am not sure how much information people want to
> save/restore. I do not know how to handle
Bo Peng wrote:
I do not know. I am not sure how much information people want to
save/restore. I do not know how to handle math/table toolbars either.
Anyway, I will add toolbar position in.
For now just saving toolbar states is already a huge improvement.
There is a *big* problem though: how
I didn't test it, but
> -if (tbb.flags & ToolbarBackend::ON)
> +// load last saved toolbasr status, if possible
> +lyx::Session & session = LyX::ref().session();
> +string visibleToolbars = session.loadSessionInfo("VisibleToolBars",
> false); +if (tbb.flags & ToolbarBackend::ON &
Bo Peng wrote:
> Attached is a patch to save/restore toolbar status. Any opinion? (It
> is qt4 only right now, and is not thoroughly tested).
I didn't test it, but
> - if (tbb.flags & ToolbarBackend::ON)
> + // load last saved toolbasr status, if possible
> + lyx::Session & sess
Hi, All
Attached is a patch to save/restore toolbar status. Any opinion? (It
is qt4 only right now, and is not thoroughly tested).
Bo
Index: src/frontends/Toolbars.C
===
--- src/frontends/Toolbars.C (revision 15344)
+++ src/frontend
19 matches
Mail list logo
