Martin Vermeer wrote:
> Be careful. I don't think it is wise to store everything and the kitchen
> sink in the document. And users shouldn't be able to modify a document
> class / layout... that stuff belongs more properly in template files.
I have to ponder that for the layout charstyles. But cer
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
On Mon, Oct 16, 2006 at 09:44:30PM +0200, Joost Verburg wrote:
> Enrico Forestieri wrote:
> > Joost, given that the preferences file takes precedence, why don't
> > simply modify configure.py such that when a preferences file does
> > not already exists, on Windows it provides a default one with a
Joost Verburg <[EMAIL PROTECTED]> writes:
| Bo Peng wrote:
| > Since session replaces lastfiles and involves many other things, it is
| > not easy to produce a patch just for toolbar status. A much larger
| > patch that backports the whole session stuff is possible, but will
| > most likely be too
Bo Peng wrote:
Since session replaces lastfiles and involves many other things, it is
not easy to produce a patch just for toolbar status. A much larger
patch that backports the whole session stuff is possible, but will
most likely be too big to be accepted by JMarc.
I think backporting session
Good work! Are you also going to create a 1.4 version?
Since session replaces lastfiles and involves many other things, it is
not easy to produce a patch just for toolbar status. A much larger
patch that backports the whole session stuff is possible, but will
most likely be too big to be accepte
On Mon, Oct 16, 2006 at 07:12:20AM +0200, Asger Ottar Alstrup wrote:
> But one more question: Where does output from lyxerr end up? I do not
> see it on the console...
Huh? I have no problem with that...
--
Enrico
Bo Peng wrote:
Attached is an updated toolbar/session patch that works for qt3/4. Can I
apply?
Good work! Are you also going to create a 1.4 version?
Joost
Enrico Forestieri wrote:
Joost, given that the preferences file takes precedence, why don't
simply modify configure.py such that when a preferences file does
not already exists, on Windows it provides a default one with a single
appropriate \format entry for pdf?
In my opinion, the new patch I
Hi, all,
Attached is an updated toolbar/session patch that works for qt3/4. Can I apply?
Problems:
1. view->toolbars-> is lacking.
2. For both qt3/4, session info is only saved with the close button.
File->exit does not work. As far as I remember, File->exit worked
before.
3. I do not know w
José Matos <[EMAIL PROTECTED]> writes:
| On Monday 16 October 2006 16:56, Lars Gullik Bjønnes wrote:
| > | Would you have a solution in search for a problem?
| >
| > Yes!
| >
| > Also also am trying to figure out something to use DHT for in LyX.
|
| http://en.wikipedia.org/wiki/Distributed_hash_t
On Mon, Oct 16, 2006 at 04:37:45PM +0200, Joost Verburg wrote:
> Then let's keep it simple. When the command starts with !, it gets
> priority. No modifications to configure.py or anything else.
>
> Is this OK?
Joost, given that the preferences file takes precedence, why don't
simply modify con
On Mon, Oct 16, 2006 at 09:35:52AM +0200, Georg Baum wrote:
> Joost Verburg wrote:
> > * It makes configuration faster because configure.py does not attempt to
> > detect UNIX applications on Windows.
>
> How much faster?
Negligibly faster...
--
Enrico
On Mon, Oct 16, 2006 at 07:47:24AM +0200, Joost Verburg wrote:
> Enrico Forestieri wrote:
> > Yes, I agree with that. My point is that the detection performed by
> > configure.py is still useful in case a default is not set in the OS.
> > Indeed, in this case you still have a viewer instead of not
On Monday 16 October 2006 16:56, Lars Gullik Bjønnes wrote:
> | Would you have a solution in search for a problem?
>
> Yes!
>
> Also also am trying to figure out something to use DHT for in LyX.
http://en.wikipedia.org/wiki/Distributed_hash_table
?! :-)
--
José Abílio
On Mon, Oct 16, 2006 at 06:04:35PM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > I did some work on this ages ago, and attach a diff saved from then.
> > Feel free to cannibalize... I have no free time right now to work on it.
>
> Many thanks, Martin. This will help indeed.
>
> >
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
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > | > "Lars" == Lars Gullik Bjønnes
| > <[EMAIL PROTECTED]> writes:
| > | | | Well, we can just store the timestamp at which a buffer has
| > been | | created.
| >
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
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| | Well, we can just store the timestamp at which a buffer has been
| | created.
|
| Lars> but that is so boring.
|
| Would you have a solution in
/sw/lib/odcctools/bin/ld: multiple definitions of symbol (anonymous
namespace)::ucs4_codeset
support/.libs/libsupport.a(unicode.o) definition of (anonymous
namespace)::ucs4_codeset in section (__DATA,__data)
support/.libs/libsupport.a(docstream.o) definition of (anonymous
n
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > Can you please use a proper include to
| > | > get to the declaration instead?
| > | | If you want but this is interim code.
| > Please.
|
| done as part of the NoG
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
> "Ran" == Ran Rutenberg <[EMAIL PROTECTED]> writes:
Ran> Hi, While creating a new translation of the Introduction, I found
Ran> I can not use Typewriter or Sans Serif fonts in Hebrew.
Ran> This problem is quite annoying because I can't go on with the
Ran> translation. I reported this bug (nu
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
FYI, I will apply these patches to branch and trunk, as discussed with
Jean-Marc on bugzilla.
Jürgen
Index: src/frontends/qt2/QDocumentDialog.C
===
--- src/frontends/qt2/QDocumentDialog.C (Revision 15297)
+++ src/frontends/qt2/QDocum
Martin Vermeer wrote:
> I did some work on this ages ago, and attach a diff saved from then.
> Feel free to cannibalize... I have no free time right now to work on it.
Many thanks, Martin. This will help indeed.
> I don't precisely remember how it was supposed to work, but I do
> remember that th
> "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.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| | Well, we can just store the timestamp at which a buffer has been
| | created.
|
| Lars> but that is so boring.
|
| Would you have a solution in search for a problem?
Yes!
Martin Vermeer wrote:
> There was a response by Jean-Marc in bugzilla, did you see it? This will
> probably require some back-and-forth debugging on the list, as most of
> us don't have a working Hebrew TeX installed.
I would be willing to install one. Can you give me a recipe for idiots,
please?
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
On Mon, 2006-10-16 at 15:54 +0200, Ran Rutenberg wrote:
> Hi,
>
> While creating a new translation of the Introduction, I found I can
> not use Typewriter or Sans Serif fonts in Hebrew.
>
> This problem is quite annoying because I can't go on with the
> translation. I reported this bug (number 29
On Mon, 2006-10-16 at 15:49 +0200, Juergen Spitzmueller wrote:
> On the way towards a charstyles gui, several things still need to be done.
> One is that currently char style definitions are only really possible by
> means
> of manual preamble definitions.
>
> I.e., if I want to have a char styl
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
In 10/16/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> As far as I can see, I am using the official one:
>
> http://www.zlib.net/zlib123-dll.zip
I test scons/msvc and confirm it works. I guess the problem was that
you have to specify both extra_lib_path and extra_inc_path for zlib. I
may add an opti
Then let's keep it simple. When the command starts with !, it gets
priority. No modifications to configure.py or anything else.
Is this OK?
Joost
Index: format.C
===
--- format.C(revision 15338)
+++ format.C(working copy)
As far as I can see, I am using the official one:
http://www.zlib.net/zlib123-dll.zip
Then I do not see why scons can not locate zlib. Things are fine here.
I got the cmake version to build, so this is not critical. I think the
chances are probably high that it's scons tool itself which is br
Hi,
While creating a new translation of the Introduction, I found I can
not use Typewriter or Sans Serif fonts in Hebrew.
This problem is quite annoying because I can't go on with the
translation. I reported this bug (number 2904) but no answer came
back. Does anyone knows how to overcome this p
On the way towards a charstyles gui, several things still need to be done.
One is that currently char style definitions are only really possible by means
of manual preamble definitions.
I.e., if I want to have a char style "keyword" that is roman, red and bold in
the output, I'll need to define:
Joost Verburg wrote:
> Peter Kümmel wrote:
>> Is there any reason why there are two command windows
>> poping up when starting LyX on Windows?
>
> Yes, LyX will be launched by a new wrapper application.
>
> Joost
>
But there's no reason to show up the windows,
or I'm wrong.
--
Peter Kümmel
On Oct 16, 2006, at 1:50 AM, Joost Verburg wrote:
Bennett Helm wrote:
On Mac OS X, what works best is not "auto" but "open" (which OS X
uses internally to open files). As I've discovered over the last
couple months, "auto" sometimes does strange things when the user
has not explicitly def
On Oct 16, 2006, at 4:47 AM, Jean-Marc Lasgouttes wrote:
"Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I don't know if 1) is supposed to only work on OSX, but (at
Enrico> least on Windows) the toolbar buttons remain active when a
Enrico> dialog is opened.
I gave up on disa
Hello,
This patch cuts down LyX::exec2 into two new methods
(execBatchCommands() and restoreGuiSession()) and introduce a number of
helper private function to sanitize the initialisation and exit process;
quitLyx() is replaced with LyX::quit(). The Application starting and
reset is done direc
Georg Baum wrote:
That breaks the auto feature on OS X and linux. OK, linux does only have it
in my experimental kde branch yet, but something like this will come sooner
or later.
When auto-detection is introduced for Linux, it can be just like on
Windows (add a check for linux to configure.py
Peter Kümmel wrote:
Is there any reason why there are two command windows
poping up when starting LyX on Windows?
Yes, LyX will be launched by a new wrapper application.
Joost
On 10/16/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> well, quite a diff..
>
> Giving a unique name for each params is a good idea. I didn't dare to
> touch getOptions() etc. functions since they are called everywhere. I
> see that you are bold enough. :) Thanks for the p
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| Well, we can just store the timestamp at which a buffer has been
| created.
Lars> but that is so boring.
Would you have a solution in search for a problem?
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | This is
| Lars> something I already wondered about. Do we have a clear |
| Lars> description of what is a same change by
Is there any reason why there are two command windows
poping up when starting LyX on Windows?
The first one is due to the batch file which starts lyx,
it could be suppressed by changing the property "show only
a minimized window".
And the second window is because lyx is linked as console
applicat
Georg Baum wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
Or maybe not. The coordcahce is for up/down navigation and vconverting
mouseclicks to text positions. It is not for pure display/export which
is whatr drawT is about.
I did not know, I thought it was also used for drawing.
So
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On Mac OS X, what works best is not "auto" but "open" (which
Bennett> OS X uses internally to open files). As I've discovered over
Bennett> the last couple months, "auto" sometimes does strange things
Bennett> when the user has n
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I am going to commit the attached patch. The tex2lyx part
Georg> should also go in 1.4.
Sure.
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think the most crucial part as of now is output, especially
Lars> output to latex and how to handle that. Will it mean
Lars> Omega/Lambda, some utf8 packages for LaTeX? How to solve this
Lars> with (La)TeX is pretty open.
Wha
Abdelrazak Younes wrote:
Asger Ottar Alstrup wrote:
Investigating further, it seems that QToc::update which is called
earlier does not make any toc_models entries: The getTypes() call
returns an empty vector. From there, I can see that TocBackend::types
is empty, and this is because the TocBac
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I don't know if 1) is supposed to only work on OSX, but (at
Enrico> least on Windows) the toolbar buttons remain active when a
Enrico> dialog is opened.
I gave up on disabling toolbars. So 1) should only be visible on OS X
(B
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Bo Peng wrote:
>> Done. Although I do not know why you want to write a new hidecmd.c.
Joost> Did you ask Jean-Marc to review the patch? It's quite trivial,
Joost> but I think he would have liked to see it.
I did not think it would
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Thu, Oct 12, 2006 at 03:35:06PM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> But we do not have any control on this menu, do we? I thought it
>> was handled by qt.
Andre> So what?
Andre> Install an event filter and catch the ev
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | This is
Lars> something I already wondered about. Do we have a clear |
Lars> description of what is a same change by one author? Same day?
Lars> Less | that 10 minutes? Same edi
Ozgur Ugras BARAN wrote:
> well, quite a diff..
>
> Giving a unique name for each params is a good idea. I didn't dare to
> touch getOptions() etc. functions since they are called everywhere. I
> see that you are bold enough. :) Thanks for the patch. I can
> participate by getting rid of those ge
Joost Verburg wrote:
> The attached patch solves the problem:
>
> * When running on Windows, configure.py will not detect viewers and let
> Windows handle it (write 'auto'). When an external application handles
> auto-detection, a viewer entry can be added.
>
> * Auto-detection inside LyX will u
well, quite a diff..
Giving a unique name for each params is a good idea. I didn't dare to
touch getOptions() etc. functions since they are called everywhere. I
see that you are bold enough. :) Thanks for the patch. I can
participate by getting rid of those get/set functions, if you wish. It
shou
Joost Verburg wrote:
> When an external application needs to be checked to enable a feature,
> like the pdftools here or the dtl tools for DVI files, that can only be
> done in configure.py.
It is important IMO that configure.py is not modified by the installer.
If checking in configure.py is nec
Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> Or maybe not. The coordcahce is for up/down navigation and vconverting
>> mouseclicks to text positions. It is not for pure display/export which
>> is whatr drawT is about.
I did not know, I thought it was also used for drawing.
>> So maybe Abde
Abdelrazak Younes wrote:
> Personally, I think the frontend fits very well in a dynamic library.
>From e theoretical PoV, yes.
> Being able to distribute a modified GUI dll without having to touch and
> distribute the core would be very nice.
But that would create a version problem. Right now w
71 matches
Mail list logo
