On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >The attached patch replaces the signal/slot connections between Buffer
> >and BufferView to LyXView by ordinary delegates.
> >
> >There has always been only (at most) a single connection of each type
> >wit
Basically, everything is ready (the recent performance fixes have been a very
valuable last-minute contribution, IMHO). So branch is frozen, except for
urgent fixes (crashes, building, etc.), documentation and l10n.
However, I have to modify the original plan, which was to prepare the release
t
Abdelrazak Younes wrote:
> > already approved. However, there were discussions about the
> > implementation, so this was postponed to 1.5.3.
>
> The only potential problem was Mac. But it appeared that Mac won't let
> us catch the exception anyway. So it can go in whenever you want.
>
> Together wi
Jürgen Spitzmüller wrote:
Michael Gerz wrote:
Supported by author ---
http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify():
don't crash with abort() but exit gracefully when an exception is
caught. try to catch LyX specific exceptions.
already approved. However,
Bo Peng wrote:
> > There is a way to introduce a bold button cleanly. But it includes
> > removing emph and noun and replacing it with textit and textsc.
>
> I do not see why textit, em and charstyle Emph can not co-exist, and I
> have no objection to use em instead of textit after textbf.
Because
Andre Poenitz wrote:
The attached patch replaces the signal/slot connections between Buffer
and BufferView to LyXView by ordinary delegates.
There has always been only (at most) a single connection of each type
with known endpoints, so full-blown signal/slot was overkill anyway -
I am sorry bu
> There is a way to introduce a bold button cleanly. But it includes removing
> emph and noun and replacing it with textit and textsc.
I do not see why textit, em and charstyle Emph can not co-exist, and I
have no objection to use em instead of textit after textbf.
Under the Edit->Text Style memu
On Tue, Oct 02, 2007 at 07:15:40AM +0300, Martin Vermeer wrote:
> On Tue, Oct 02, 2007 at 12:36:39AM +0200, Andre Poenitz wrote:
> > On Tue, Oct 02, 2007 at 12:04:13AM +0200, Andre Poenitz wrote:
> > > The attached patch replaces the signal/slot connections between Buffer
> > > and BufferView to Ly
Michael Gerz wrote:
> Supported by author
> ---
> http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify():
> don't crash with abort() but exit gracefully when an exception is
> caught. try to catch LyX specific exceptions.
already approved. However, there were discussion
Jean-Marc Lasgouttes schrieb:
"Bo Peng" <[EMAIL PROTECTED]> writes:
Finally, someone agrees with me on this. I have said again and again
that this is not *my* problem because I have my shortcuts, but it is a
big problem for new users. Also even if \strong is provided, most
users may still pre
Richard Heck wrote:
> > http://www.lyx.org/trac/changeset/20437 - Remove redundant
> > AlignPossible? lines
> > http://www.lyx.org/trac/changeset/20438 - Disallow setting of
> > alignment in protected environments, where it is broken.
>
> Maybe. Jurgen should have a look.
Could you explain again w
Michael Gerz wrote:
> Wrong! I raised the same problem a long time ago. We had a lengthy
> discussion but nothing happened.
We brought up the same arguments back then. I didn't hear a good argument
against the separation of semantic/physical markup.
And my statement was related to the lyx-users
On Tue, Oct 02, 2007 at 12:36:39AM +0200, Andre Poenitz wrote:
> On Tue, Oct 02, 2007 at 12:04:13AM +0200, Andre Poenitz wrote:
> > The attached patch replaces the signal/slot connections between Buffer
> > and BufferView to LyXView by ordinary delegates.
>
> Updated patch after Abdel's ToolBar wo
> What simplicity (assuming that the style is easy to find)? Different
> interface of font vs inset? or pavlovian need of having the real
> 'bold'?
\textbf is simpler than \strong because
1. it is simply \textbf, and \strong can be anything, and to
understand what is \strong, someone needs to und
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
"standard" is the key word yes. INI-like or XML is easy to parse and
is understood by a lot of application. Designing an UI to change an
XML or an INI file is easy. XML offers much more possibilities of
extension though.
On Tue, Oct 02, 2007 at 12:04:13AM +0200, Andre Poenitz wrote:
> The attached patch replaces the signal/slot connections between Buffer
> and BufferView to LyXView by ordinary delegates.
Updated patch after Abdel's ToolBar work attached.
And just for fun a list of winners and losers:
-31423 .
The attached patch replaces the signal/slot connections between Buffer
and BufferView to LyXView by ordinary delegates.
There has always been only (at most) a single connection of each type
with known endpoints, so full-blown signal/slot was overkill anyway -
at least given the price of boost's s
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Finally, someone agrees with me on this. I have said again and again
> that this is not *my* problem because I have my shortcuts, but it is a
> big problem for new users. Also even if \strong is provided, most
> users may still prefer \texbf for its simplicit
Richard Heck <[EMAIL PROTECTED]> writes:
>> You say 20ms. How does it compare to the time spent refreshing the
>> screen at each keypress, for example?
>>
> I don't remember exactly, but it was far less. On the order of 1-2ms.
> Anything more, and I at least had a closer look. Of course, this w
Andre Poenitz wrote:
On Mon, Oct 01, 2007 at 09:35:43PM +0200, Abdelrazak Younes wrote:
Citation seems to be "Old Standard" (or whatever is left of that):
class GuiCitationDialog : public GuiDialog, public Ui::CitationUi
It was not before your controller cleanup. I think you changed it back
to
On Mon, Oct 01, 2007 at 09:35:43PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Mon, Oct 01, 2007 at 06:23:16PM +, Angus Leeming wrote:
> >>Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>>So possible resolutions in my eyes are
> >>>
> >>> (1) "physically merge C and V" (that wou
Andre Poenitz wrote:
On Mon, Oct 01, 2007 at 06:23:16PM +, Angus Leeming wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
So possible resolutions in my eyes are
(1) "physically merge C and V" (that would be 1:0 for KISS vs MVC)
or
(2) "put C and V in the same files" (that would be so
On Mon, Oct 01, 2007 at 06:23:16PM +, Angus Leeming wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > So possible resolutions in my eyes are
> >
> > (1) "physically merge C and V" (that would be 1:0 for KISS vs MVC)
> >
> > or
> >
> > (2) "put C and V in the same files" (that would
On Mon, Oct 01, 2007 at 06:56:44PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
> >>Jean-Marc Lasgouttes wrote:
> >>>Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >>>
> Edwin Leuven wrote:
> >Richard Heck wrot
On Mon, Oct 01, 2007 at 08:09:39PM +0200, Michael Gerz wrote:
> Hi,
>
> the list has become a bit lengthy. Time to filter out useless entries.
>
> Regards, Michael
>
>
>
>
> Patch Candidate List #5
>
> Approved by Jürgen
> --
>
>
> Supported by author
> ---
On Mon, Oct 01, 2007 at 01:21:12PM -0400, Richard Heck wrote:
> Jürgen Spitzmüller wrote:
> >John Levon wrote:
> >
> >>You remember that far back too :)
> >>
> >I do. And I'm pinning all my hope on Richard and Martin, so that this
> >crucial feature will eventually become reality. I really h
On Mon, Oct 01, 2007 at 06:36:16PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> Could give a more precise scenario where this happens?
> >
> > Would be irrelevant. There is no reason that the status update is
> > triggered _only_ by a cursor move.
>
> It i
On Mon, Oct 01, 2007 at 12:29:14PM -0400, Richard Heck wrote:
> Martin Vermeer wrote:
> >On Mon, 01 Oct 2007 11:56:31 -0400
> >Richard Heck <[EMAIL PROTECTED]> wrote:
> >
> >>John Levon wrote:
> >>
> >>>On Mon, Oct 01, 2007 at 11:37:43AM -0400, Richard Heck wrote:
> >>>
> You mean:
Michael Gerz wrote:
New
---
http://www.lyx.org/trac/changeset/20437 - Remove redundant
AlignPossible? lines
http://www.lyx.org/trac/changeset/20438 - Disallow setting of
alignment in protected environments, where it is broken.
Maybe. Jurgen should have a look.
Richard
Andre Poenitz <[EMAIL PROTECTED]> writes:
> So possible resolutions in my eyes are
>
> (1) "physically merge C and V" (that would be 1:0 for KISS vs MVC)
>
> or
>
> (2) "put C and V in the same files" (that would be something like
>0.3 : 0.7 for KISS vs MVC, but would at least not ma
Hi,
the list has become a bit lengthy. Time to filter out useless entries.
Regards, Michael
Patch Candidate List #5
Approved by Jürgen
--
Supported by author
---
http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify():
don't crash with abort() b
> This is no options for new unexperienced users. Really, ask *real* users
> on this subject. You won't be amused by their answer :-)
Finally, someone agrees with me on this. I have said again and again
that this is not *my* problem because I have my shortcuts, but it is a
big problem for new user
Jürgen Spitzmüller schrieb:
Jean-Marc Lasgouttes wrote:
As juergen pointed out, this is something that dates back to LyX
1.4.0. We cannot add 'strong' support to 1.5 (format change). Bold is
available through a couple of key bindings, which make it convenient
for people who really need it (I
On Oct 1, 2007, at 12:17 PM, Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Yes, but it remains the case that these toolbar updates are taking a
long time---on the wall clock, which is what matters to the user. If
the time is being spent in Qt, or wherever , then we shoul
Jürgen Spitzmüller wrote:
John Levon wrote:
You remember that far back too :)
I do. And I'm pinning all my hope on Richard and Martin, so that this crucial
feature will eventually become reality. I really hope this will make it into
1.6.0.
Document-internal layout is fairly easy to
Andre Poenitz wrote:
On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Edwin Leuven wrote:
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a desi
On Mon, Oct 01, 2007 at 07:02:02PM +0200, Jürgen Spitzmüller wrote:
> I do. And I'm pinning all my hope on Richard and Martin, so that this crucial
> feature will eventually become reality. I really hope this will make it into
> 1.6.0.
Me too. I'd be happy to help out with UI design or whatever
John Levon wrote:
> You remember that far back too :)
I do. And I'm pinning all my hope on Richard and Martin, so that this crucial
feature will eventually become reality. I really hope this will make it into
1.6.0.
Jürgen
John Levon wrote:
On Mon, Oct 01, 2007 at 12:44:35PM -0400, Richard Heck wrote:
I'm not sure what you mean by `transmitted' here. But at present,
charstyle definitions are stored in layout files or, at least in
1.6.svn, in layout "modules", which can be used with different
document-class l
On Mon, Oct 01, 2007 at 06:45:05PM +0200, Jürgen Spitzmüller wrote:
> I think we will have to store some of then in the document.
>
> We already had this discussion. I think we ended with three kind of char
You remember that far back too :)
john
On Mon, Oct 01, 2007 at 12:44:35PM -0400, Richard Heck wrote:
> I'm not sure what you mean by `transmitted' here. But at present,
> charstyle definitions are stored in layout files or, at least in
> 1.6.svn, in layout "modules", which can be used with different
> document-class layouts. (This i
John Levon wrote:
> This I think is the difficult bit. Where are they stored, and how are
> they transmitted? "It's a layout thing" won't do...
I think we will have to store some of then in the document.
We already had this discussion. I think we ended with three kind of char
styles:
a.) global
John Levon wrote:
On Mon, Oct 01, 2007 at 12:29:14PM -0400, Richard Heck wrote
What did you do with the charstyle once you had it? Write it to a file?
This I think is the difficult bit. Where are they stored, and how are
they transmitted? "It's a layout thing" won't do...
I'm not sure w
On Mon, Oct 01, 2007 at 05:16:25PM +0200, Ramon Flores wrote:
> Hi:
>
> I'm the galician translator, and finishing the lyx-1.5.2 translation. But I
> can not figure what is the meaning of message 3541:
>
> No vertical grid lines in 'cases': feature %1$s
>
> So I would thank for a explanation of
On Mon, Oct 01, 2007 at 05:10:00PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >>>Assuming the two choices are ini or xml, I fail to see the advantages
> >>>of xml for what we want to do.
> >>Structured tree-like structure.
>
On Mon, Oct 01, 2007 at 04:06:10PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Are you just trying to avoid the discussion?
>
> No, I just believe that the model of updating after the lfun execution
> is a robust one.
>
> > If not and you genuinely
On Mon, Oct 01, 2007 at 12:29:14PM -0400, Richard Heck wrote:
> What did you do with the charstyle once you had it? Write it to a file?
This I think is the difficult bit. Where are they stored, and how are
they transmitted? "It's a layout thing" won't do...
regards
john
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Could give a more precise scenario where this happens?
>
> Would be irrelevant. There is no reason that the status update is
> triggered _only_ by a cursor move.
It is not a cursor move, it is any action going through dispatch.
Then the update mechani
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Yes, but it remains the case that these toolbar updates are taking a
long time---on the wall clock, which is what matters to the user. If
the time is being spent in Qt, or wherever , then we should avoid
going there. Right?
On Mon, Oct 01, 2007 at 12:19:20PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Moreover, with the current architecture, a status change is not
> > immediately reflected in the relevant icon, you will have to trigger a
> > new action to update all the ot
Martin Vermeer wrote:
On Mon, 01 Oct 2007 11:56:31 -0400
Richard Heck <[EMAIL PROTECTED]> wrote:
John Levon wrote:
On Mon, Oct 01, 2007 at 11:37:43AM -0400, Richard Heck wrote:
You mean: No gui for constructing character styles? If so, that's right.
Right. That's c
On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >>Edwin Leuven wrote:
> >>>Richard Heck wrote:
> >Well, toolbars have not been designed for several dozens of entries.
> >>>calling this a desi
On Mon, Oct 01, 2007 at 12:18:01PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> >> why not use signals: if a tabular gets focucs it sends an enabled
> >> signal to the associated actions, and a disabled signal when it
> >> looses focus?
> >
> > That would
On Mon, 01 Oct 2007 17:16:25 +0200
Ramon Flores <[EMAIL PROTECTED]> wrote:
> Hi:
>
> I'm the galician translator, and finishing the lyx-1.5.2 translation. But I
> can not figure what is the meaning of message 3541:
>
> No vertical grid lines in 'cases': feature %1$s
>
> So I would thank for a
Andre Poenitz wrote:
> Of course not using math is objectable.
I use it _rarely_, if only to celebrate otherness.
Jürgen
On Mon, 01 Oct 2007 11:56:31 -0400
Richard Heck <[EMAIL PROTECTED]> wrote:
> John Levon wrote:
> > On Mon, Oct 01, 2007 at 11:37:43AM -0400, Richard Heck wrote:
> >
> >> You mean: No gui for constructing character styles? If so, that's right.
> >>
> > Right. That's critical before char st
Richard Heck <[EMAIL PROTECTED]> writes:
> Yes, but it remains the case that these toolbar updates are taking a
> long time---on the wall clock, which is what matters to the user. If
> the time is being spent in Qt, or wherever , then we should avoid
> going there. Right?
You say 20ms. How does i
On Mon, Oct 01, 2007 at 11:34:38AM +0200, Edwin Leuven wrote:
> Jürgen Spitzmüller wrote:
> >Do you have some (subjective or objective) measures on the speed
> >improvement?
>
> no, but richard was complaining that the panels took a bit of time to update
>
> >I.e., is it worth to shove this in
On Mon, Oct 01, 2007 at 11:33:55AM +0200, Abdelrazak Younes wrote:
> Edwin Leuven wrote:
> >Abdelrazak Younes wrote:
> >>>However, I would be surprised to see someone come up with a
> >>>proper alternative to the general idea of polling getStatus
> >>
> >>No but we could add an option for not polli
On Mon, Oct 01, 2007 at 11:27:10AM +0200, Edwin Leuven wrote:
> Abdelrazak Younes wrote:
> >>However, I would be surprised to see someone come up
> >>with a proper alternative to the general idea of polling getStatus
> >
> >No but we could add an option for not polling getStatus and return early
>
> Edwin is working (AFAIR) on a property editor style interface.
brooding is a better word than working
...
if someone finds time: it would be useful to store package information in a
definition file and parse this, where we would like the following.
parameter
description
type {e.g. LENGTH,TE
On Mon, Oct 01, 2007 at 10:07:54AM +0200, Abdelrazak Younes wrote:
> I just tried it and it worked out of the box after removing everything I
> had in the preamble (things that I never understood). Anyway, thanks a
> lot to Pavel, Uwe, and anyone else who has participated; this is a great
> feat
John Levon wrote:
On Mon, Oct 01, 2007 at 11:37:43AM -0400, Richard Heck wrote:
You mean: No gui for constructing character styles? If so, that's right.
Right. That's critical before char styles can be said to be done
We lack any sort of layout editor, which we very much need.
We
> > I actually had a look at this dialog, it does not seem to fit our
> > need. You know, we do *not* have a fixed number of things to assign
> > shortcuts for, and we need to categorize what we have (math, layout
> > etc).
> >
> Right. Oh well.
But you know that I have a strong tendency to o
On Mon, Oct 01, 2007 at 09:41:23AM +0200, Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
> > > Ah, silly me. Much simpler patch attached.
> >
> > Looks better ;-)
>
> I guess it cannot do any harm. And it improves the situation
> significantly for people like me who only use the math toolbar
On Mon, Oct 01, 2007 at 11:37:43AM -0400, Richard Heck wrote:
> You mean: No gui for constructing character styles? If so, that's right.
Right. That's critical before char styles can be said to be done.
> We lack any sort of layout editor, which we very much need.
We also need this; however, i
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
FWIW, I agree that the toolbar design is awkward, and that a rewrite
would be welcome.
The first thing to do would be to move *all* code related to toolbar
and menubar handling to the frontend. We should do the toolbar/menubar
Action unifica
Bo Peng wrote:
I may have mentioned this before, but KDE applications all have this
kind of dialog. It's obviously KDE specific, but maybe it wouldn't be
too hard to adapt it. And wouldn't it be appropriate to borrow something
back from KDE? It's here:
http://websvn.kde.org/trunk/KDE/kdelibs/kdeu
> I may have mentioned this before, but KDE applications all have this
> kind of dialog. It's obviously KDE specific, but maybe it wouldn't be
> too hard to adapt it. And wouldn't it be appropriate to borrow something
> back from KDE? It's here:
> http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/dialo
John Levon wrote:
I'm a bit confused, I just compiled svn, and there's no style UI. So,
that would be what's missing.
You mean: No gui for constructing character styles? If so, that's right.
We lack any sort of layout editor, which we very much need.
rh
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes
I am not 100% sure but I don't think so. Unless you are talking about
the drawing of the toolbars themselves, all drawing/metrics operations
have already been done at this stage so the 13.5 really are taken by
Toolbars::up
Bo Peng wrote:
Could we talk again about 1.6 timeline?*
I am extremely busy recently but embedding should be done in a few
weeks (it is more or less done now). I have a shortcut editing dialog
in mind, which becomes more important after the recent Bold/C-B fight.
I may have mentioned thi
On Mon, Oct 01, 2007 at 10:03:16AM -0500, Bo Peng wrote:
> > Why isn't this a listbox + tooltips?
>
> Because there are 163+ options (and most of them are rarely used).
There are ways to deal with this.
> Edwin is working (AFAIR) on a property editor style interface.
Cool.
john
Jean-Marc Lasgouttes wrote:
Edwin Leuven <[EMAIL PROTECTED]> writes
Jürgen Spitzmüller wrote:
Do you have some (subjective or objective) measures on the speed
improvement?
no, but richard was complaining that the panels took a bit of time to update
A simple test to see wheth
Hi:
I'm the galician translator, and finishing the lyx-1.5.2 translation. But I
can not figure what is the meaning of message 3541:
No vertical grid lines in 'cases': feature %1$s
So I would thank for a explanation of this message.
Cheers
Ramon
> Could we talk again about 1.6 timeline?*
I am extremely busy recently but embedding should be done in a few
weeks (it is more or less done now). I have a shortcut editing dialog
in mind, which becomes more important after the recent Bold/C-B fight.
I will need about two month to do it.
Bo
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Assuming the two choices are ini or xml, I fail to see the advantages
of xml for what we want to do.
Structured tree-like structure.
It is great to represent data that does not have a tree structure, right;)
INI is s
Richard Heck <[EMAIL PROTECTED]> writes:
> Thanks, Abdel, for doing this. It'll make a big difference for a lot
> of people. Including me.
+1
JMarc
Thanks, Abdel, for doing this. It'll make a big difference for a lot of
people. Including me.
rh
[EMAIL PROTECTED] wrote:
Author: younes
Date: Sun Sep 30 22:28:15 2007
New Revision: 20617
URL: http://www.lyx.org/trac/changeset/20617
Log:
Fix slowness issue with Clipboard. Cache the Clipboar
> Why isn't this a listbox + tooltips?
Because there are 163+ options (and most of them are rarely used).
Edwin is working (AFAIR) on a property editor style interface.
Bo
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I think you are only trying to scare yourself ;-)
It might be...
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Assuming the two choices are ini or xml, I fail to see the advantages
>> of xml for what we want to do.
>
> Structured tree-like structure.
It is great to represent data that does not have a tree structure, right;)
> I reckon that even more people
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Are you just trying to avoid the discussion?
No, I just believe that the model of updating after the lfun execution
is a robust one.
That what I understood yes :-)
If not and you genuinely want to discuss then I'
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
"standard" is the key word yes. INI-like or XML is easy to parse and
is understood by a lot of application. Designing an UI to change an
XML or an INI file is easy. XML offers much more possibilities of
extension though.
John Levon wrote:
> It's just plain bizarre. (A good rule is: if
> you're inventing a new form of UI, you're most likely doing something
> wrong.)
You see, we really missed you ;-)
Jürgen
John Levon <[EMAIL PROTECTED]> writes:
> (A good rule is: if you're inventing a new form of UI, you're most
> likely doing something wrong.)
Very true.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> "standard" is the key word yes. INI-like or XML is easy to parse and
> is understood by a lot of application. Designing an UI to change an
> XML or an INI file is easy. XML offers much more possibilities of
> extension though. the layout-like format
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
XML because it's easy to parse and modify via a GUI.
And also because I like XML :-)
I see :)
But an INI-like format could do too:
We should probably try to reduce the number of formats we use:
lyx-format-like (pr
> The only way this could happen is when this other app automatically put the
> X11 selection in the X11 clipboard (which is bad).
no its not bad, once you get accustomed to it its very useful on contrary.
(btw i dont use any desktop manager here and works too).
pavel
On Mon, Oct 01, 2007 at 04:09:24PM +0200, Jürgen Spitzmüller wrote:
> > I just came across this. Is there a bug filed on fixing this UI?
> > I'm a bit concerned that new UI isn't getting the review it deserves.
>
> No.
>
> What's the problem?
We have a list of options that's presented as some h
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> XML because it's easy to parse and modify via a GUI.
>
> And also because I like XML :-)
I see :)
> But an INI-like format could do too:
We should probably try to reduce the number of formats we use:
lyx-format-like (prefs, bindings), layout lik
John Levon wrote:
> I just came across this. Is there a bug filed on fixing this UI?
> I'm a bit concerned that new UI isn't getting the review it deserves.
No.
What's the problem?
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Are you just trying to avoid the discussion?
No, I just believe that the model of updating after the lfun execution
is a robust one.
> If not and you genuinely want to discuss then I'd say yes,
> basically. This example shows that we do a lot of
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
>> Why? I do not like using a gui name to look up a function. lfun+arg
>> looks better to me.
>
> Hum, thinking a bit more about it, we should probably have an ascii ID
>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Why? I do not like using a gui name to look up a function. lfun+arg
>> looks better to me.
>
> lfun+arg might be very long, especially if the action is a command
> sequence. And the name is defined already in the menu description file
> (stmenu.inc)
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The first thing to do would be to move *all* code related to toolbar
and menubar handling to the frontend. We should do the toolbar/menubar
Action unification we were talking about back before 1.
I just came across this. Is there a bug filed on fixing this UI?
I'm a bit concerned that new UI isn't getting the review it deserves.
cheers
john
I'm a bit confused, I just compiled svn, and there's no style UI. So,
that would be what's missing.
john
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Why? I do not like using a gui name to look up a function. lfun+arg
looks better to me.
Hum, thinking a bit more about it, we should probably have an ascii ID
and a GUI description string, ex:
name="select-all"
desc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I am not 100% sure but I don't think so. Unless you are talking about
the drawing of the toolbars themselves, all drawing/metrics operations
have already been done at this stage so the 13.5 really are taken by
Toolbars::
1 - 100 of 160 matches
Mail list logo
