On 20/05/2011 8:43 AM, venom00 wrote:
If this are all changes, I wouldn't touch it any more, maybe
we update it later,
and if we have changed it there would be too much noise in the diff.
You mean update from the original Qt Creator source? Yeah, that's a good idea.
Then here's the patch with
> If this are all changes, I wouldn't touch it any more, maybe
> we update it later,
> and if we have changed it there would be too much noise in the diff.
You mean update from the original Qt Creator source? Yeah, that's a good idea.
Then here's the patch with camel-cased filenames.
venom00
In
On 18.05.2011 23:03, venom00 wrote:
Are the fancylineedit.* files 1:1 copied from qtcreator? Then
we should not
touch them otherwise we could lyxify them.
I've changed the namespace, removed an export macro and changed the copyright
notice as you can see in the patch or in a previous mail.
We s
> Are the fancylineedit.* files 1:1 copied from qtcreator? Then
> we should not
> touch them otherwise we could lyxify them.
I've changed the namespace, removed an export macro and changed the copyright
notice as you can see in the patch or in a previous mail.
We should LyXify them... Whatever it
On 18.05.2011 11:51, venom00 wrote:
And... Scons? :P However I'll test it under Linux with
autotools to be sure everything is right.
OK, here's the version of the patch working under Linux with autotools.
So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I
have to:
On 18.05.2011 11:51, venom00 wrote:
And... Scons? :P However I'll test it under Linux with
autotools to be sure everything is right.
OK, here's the version of the patch working under Linux with autotools.
So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I
have to:
> And... Scons? :P However I'll test it under Linux with
> autotools to be sure everything is right.
OK, here's the version of the patch working under Linux with autotools.
So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I
have to:
- include the moc file at the end
Am Dienstag, 17. Mai 2011 schrieb Vincent van Ravesteijn:
> On 17-5-2011 22:02, Peter Kümmel wrote:
> > On 17.05.2011 21:46, Vincent van Ravesteijn wrote:
> >> Mmmh, now I'm starting to get confused about your question. Are
> >> you asking why you have to include the moc_* files or why the
> >> moc
On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote:
> On 16.05.2011 23:54, venom00 wrote:
> >Vincent or someone else, can you tell me if it's OK to include a pair
> >of files directly from the Qt Creator code? Just a quick reply so I
> >can go on with the patch.
>
> Isn't QtCreator LGPL
> The creation of the moc_* file is not trigged by including it.
Mmmh, it seems that including it triggers its creation, take a look at the
lyx_automoc macro. For how I've understood it, it checks all the file against
the following regexp:
#include +["<]moc_[^]+\\.cpp[">]
And then runs the moc g
On 17-5-2011 22:02, Peter Kümmel wrote:
> On 17.05.2011 21:46, Vincent van Ravesteijn wrote:
>>
>> Mmmh, now I'm starting to get confused about your question. Are
>> you asking why you have to include the moc_* files or why the
>> moc_* file was not created for fancylineedit ? The creation of
>> th
On 17.05.2011 21:46, Vincent van Ravesteijn wrote:
Mmmh, now I'm starting to get confused about your question. Are
you asking why you have to include the moc_* files or why the
moc_* file was not created for fancylineedit ? The creation of
the moc_* file is not trigged by including it.
macro(
Is there a reason for which the moc_ file is included at the end? I've spent an
The include triggers the moc generation. I've moved fancylineedit.* into qt4
(no gui code in support, only QtCore classes), then called cmake again and it
build without errors.
hour (in cmake's lyx_automoc& frien
On 17-5-2011 21:37, venom00 wrote:
>> But... I think there are quite some places where we can pimp LyX a
>> bit and maybe we can use it in more places as you say.
>
> Very well!
>
>>> Is there a reason for which the moc_ file is included at
>> the end? I've spent an
>>> hour (in cmake's lyx_aut
> But... I think there are quite some places where we can pimp LyX a
> bit and maybe we can use it in more places as you say.
Very well!
> > Is there a reason for which the moc_ file is included at
> the end? I've spent an
> > hour (in cmake's lyx_automoc & friends) to understand why
> the moc
On 17-5-2011 20:15, venom00 wrote:
>> Hi Venom,
>> Sorry for not responding earlier.
>> It feels like it's a bit too much to include a pair of files from another
> project just to add a "rubber button" to your search box.
>> Can you point at the code that you want to use. Maybe there is a simpler
> Hi Venom,
> Sorry for not responding earlier.
> It feels like it's a bit too much to include a pair of files from another
project just to add a "rubber button" to your search box.
> Can you point at the code that you want to use. Maybe there is a simpler
solution ?
>
> Vincent
Maybe we can reus
On Mon, May 16, 2011 at 11:54 PM, venom00 wrote:
> Vincent or someone else, can you tell me if it's OK to include a pair of
> files
> directly from the Qt Creator code?
> Just a quick reply so I can go on with the patch.
>
Hi Venom,
Sorry for not responding earlier.
It feels like it's a bit to
On 16.05.2011 23:54, venom00 wrote:
Vincent or someone else, can you tell me if it's OK to include a pair of files
directly from the Qt Creator code?
Just a quick reply so I can go on with the patch.
Isn't QtCreator LGPL? Then it would be ok.
Peter
On 05/16/2011 05:54 PM, venom00 wrote:
> Vincent or someone else, can you tell me if it's OK to include a pair of files
> directly from the Qt Creator code?
> Just a quick reply so I can go on with the patch.
>
We've done this sort of thing before. Depending upon what they are, they
should perhaps
Vincent or someone else, can you tell me if it's OK to include a pair of files
directly from the Qt Creator code?
Just a quick reply so I can go on with the patch.
Thanks,
venom00
> Ping
>
> > > > The patch looks pretty good now, so I'll put it in my
> > testing tree.
> > >
> > > I'm not compl
Ping
> > > The patch looks pretty good now, so I'll put it in my
> testing tree.
> >
> > I'm not completely sure of the red highlighting. Red is a
> > color for errors, I'll try green, yellow and maybe bold.
> > Moreover I want to add the "rubber" button.
>
> I was thinking to use the FancyLin
> > The patch looks pretty good now, so I'll put it in my testing tree.
>
> I'm not completely sure of the red highlighting. Red is a
> color for errors, I'll try green, yellow and maybe bold.
> Moreover I want to add the "rubber" button.
I was thinking to use the FancyLineEdit widget of Qt Crea
> The patch looks pretty good now, so I'll put it in my testing tree.
I'm not completely sure of the red highlighting. Red is a color for errors, I'll
try green, yellow and maybe bold.
Moreover I want to add the "rubber" button.
> Just a last nitpick: we try to keep the lines shorter than 80
>
Hi Venom,
> I've removed searchTimeout as it was just a call to search(). I've also
> removed
> resetSearch() as the only caller now is hideEvent.
>
> venom00
>
The patch looks pretty good now, so I'll put it in my testing tree.
Just a last nitpick: we try to keep the lines shorter than 80 ch
>> However, you should then set the text in the textfield and then
>> manually reset all widgets to enabled. This means you have to either
>> block the signals, but better .. listen to textEdited instead of
>> textChanged.
>>> +
>>> + connect(search_, SIGNAL(textChanged(QString)), this,
>>> SLOT(
> hideView() doesn't work as this is only called when the Ok or Close
> button are pressed. Not when the dialog is canceled by Escape.
>
> Maybe you should put the resetSearch function in a showEvent function
> which is called when the dialog is shown.
OK, that's a good idea, this makes the patch
On 29-4-2011 15:03, venom00 wrote:
>> Style and form comments are always welcome but please give a
>> little attention to the content too:
>> - Alternative ideas to highlight matching widgets? Currently
>> they become red.
>> - Ideas on how to make the research faster? In the next patch
>> I'll
> Style and form comments are always welcome but please give a
> little attention to the content too:
> - Alternative ideas to highlight matching widgets? Currently
> they become red.
> - Ideas on how to make the research faster? In the next patch
> I'll try to add a little delay.
Here's the ne
> Hi.
>
> On Wed, Apr 27, 2011 at 02:07:55PM +0200, venom00 wrote:
> > > +void GuiDocument::hideView() {
> > > + Dialog::hideView();
> > > + // Reset the search box
> > > + this->docPS->resetSearch();
> > > +}
>
> Style nits: { on a separate line for the function body, and this->
> seems superflu
Hi.
On Wed, Apr 27, 2011 at 02:07:55PM +0200, venom00 wrote:
> > +void GuiDocument::hideView() {
> > + Dialog::hideView();
> > + // Reset the search box
> > + this->docPS->resetSearch();
> > +}
Style nits: { on a separate line for the function body, and this->
seems superfluous.
> > + /
On 28-4-2011 18:08, venom00 wrote:
>> On 27-4-2011 14:07, venom00 wrote:
>>> Ping
>>>
>>
>> Yes, shame on me...
>>
>> Vincent
>>
>
> Np, it's just that I want this patch commited before going to other
> improvements.
>
> venom00
>
It won't get committed soon though, as we are in the middle of
> On 27-4-2011 14:07, venom00 wrote:
> > Ping
> >
>
> Yes, shame on me...
>
> Vincent
>
Np, it's just that I want this patch commited before going to other
improvements.
venom00
On 27-4-2011 14:07, venom00 wrote:
> Ping
>
Yes, shame on me...
Vincent
Ping
> -Original Message-
> From: lyx-devel@lists.lyx.org
> [mailto:lyx-devel@lists.lyx.org] On Behalf Of venom00
> Sent: Friday, April 22, 2011 5:24 PM
> To: lyx-devel@lists.lyx.org
> Cc: 'Vincent van Ravesteijn'; 'Peter Kümmel'
> Subject:
OK, I've fixed everything you suggested me.
Here's the new version. I've tried to limit the search to QAbstractButton,
QGroupBox and Qlabel but no big improvements. Maybe we should simply add a
delay, so the user can type the whole search query and then start the search,
200-400 ms. Other ideas?
> I've no clue what a "rubber" button is. But something to clear the field would
be useful.
A rubber :P you use it to delete things you wrote with a pencil. Take a look at
the Eclipse option dialog, there's a small rubber inside the search box.
> I don't know whether we can use it as it was only
On 17-4-2011 17:30, venom00 wrote:
>> We try to sort the includes.
>
> OK
>
>> #if QT_VERSION >= 0x040700
>>> + search_->setPlaceholderText(tr("Search"));
>> #endif
>
> Nice.
>
>> if (!item->child(i)->isDisabled()) {
>> (although now I see this is introduced in Qt
On 17-4-2011 17:59, Peter Kümmel wrote:
>
>>
>> - To translate the string I used tr("Search"), is that correct?
>
> We use gettext, there and also here underscore is common:
> _("Search");
The correct way in the frontends/qt4 part is to use qt_("Search") instead.
>
>> - Currently the widgets a
Le 17/04/11 17:30, venom00 a écrit :
I think this syntax it's very hard to understand, we should use Qt's foreach
macro (if we'll ever want to drop Qt it's just a file to import), much more
elegant. However if it's a strict coding rule I'll follow it.
We do have our own foreach (support/foreach
On 17.04.2011 17:52, venom00 wrote:
>>> + if (QAbstractButton * button =
>> qobject_cast(children[child_index])) {
>>> + widget_matches = (new
>> QString(button->text()))->replace('&', "")
>>> +
>
> - To translate the string I used tr("Search"), is that correct?
We use gettext, there and also here underscore is common:
_("Search");
> - Currently the widgets are highlighted in red, alternative ideas? Maybe bold
> or
> nothing at all.
> - Do you think a "rubber" button in (or next to)
> > + if (QAbstractButton * button =
> qobject_cast(children[child_index])) {
> > + widget_matches = (new
> QString(button->text()))->replace('&', "")
> > +
> .contains(search, Qt::CaseInsensiti
> public Q_SLOTS:
> + /// the option filter changed
> + void filterChanged(QString search);
Pass by reference:
> + void filterChanged(QString const & search);
Peter
> + if (QAbstractButton * button =
> qobject_cast(children[child_index])) {
> + widget_matches = (new
> QString(button->text()))->replace('&', "")
> + .contains(search,
> Qt::CaseInsensit
> We try to sort the includes.
OK
> #if QT_VERSION >= 0x040700
> > + search_->setPlaceholderText(tr("Search"));
> #endif
Nice.
> if (!item->child(i)->isDisabled()) {
> (although now I see this is introduced in Qt 4.3)
I was using other flags before the final pat
On 17.04.2011 16:01, Richard Heck wrote:
> On 04/17/2011 06:46 AM, Vincent van Ravesteijn wrote:
>> On 13-4-2011 16:26, venom00 wrote:
>>
>>> + // Try to cast to the most common widgets and
>>> looks in it's content by each
>>> + // It's bad OOP,
On 04/17/2011 06:46 AM, Vincent van Ravesteijn wrote:
On 13-4-2011 16:26, venom00 wrote:
+ // Try to cast to the most common widgets and
looks in it's content by each
+ // It's bad OOP, it would be nice to have a
QWidget::toString()
On 13-4-2011 16:26, venom00 wrote:
> Here's the patch. I hope works fine. It would be nice to put it in 2.0 but I
> think it's impossible as it's late and I've added a string ("Search", maybe
> we already have it). Moreover it's my first patch in C++ to LyX, so probably
> it will be full of inco
On 17-4-2011 11:58, venom00 wrote:
>> On 14-4-2011 19:22, venom00 wrote:
Here's the patch. I hope works fine. It would be nice to put
it in 2.0 but I think it's impossible as it's late and I've
added a string ("Search", maybe we already have it). Moreover
it's my first patch
> On 14-4-2011 19:22, venom00 wrote:
> >> Here's the patch. I hope works fine. It would be nice to put
> >> it in 2.0 but I think it's impossible as it's late and I've
> >> added a string ("Search", maybe we already have it). Moreover
> >> it's my first patch in C++ to LyX, so probably it will b
On 14-4-2011 19:22, venom00 wrote:
>> Here's the patch. I hope works fine. It would be nice to put
>> it in 2.0 but I think it's impossible as it's late and I've
>> added a string ("Search", maybe we already have it). Moreover
>> it's my first patch in C++ to LyX, so probably it will be
>> full
> Here's the patch. I hope works fine. It would be nice to put
> it in 2.0 but I think it's impossible as it's late and I've
> added a string ("Search", maybe we already have it). Moreover
> it's my first patch in C++ to LyX, so probably it will be
> full of inconsistencies.
Could someone give
Here's the patch. I hope works fine. It would be nice to put it in 2.0 but I
think it's impossible as it's late and I've added a string ("Search", maybe we
already have it). Moreover it's my first patch in C++ to LyX, so probably it
will be full of inconsistencies.
It adds a search box to Tools
On Sat, Apr 9, 2011 at 12:56 PM, Sam Lewis
wrote:
>
>> Why don't we add an option in the Tools -> Preferences (and maybe in
>> Document -
>> Settings too) dialog to show
>> only the most important options, you know, that "basic" and "expert"
>
> Are not most LyX users "expert" users anyway?
>
In
> Why don't we add an option in the Tools -> Preferences (and maybe in Document
> -
> Settings too) dialog to show
> only the most important options, you know, that "basic" and "expert"
Are not most LyX users "expert" users anyway?
Cheers, Sam
56 matches
Mail list logo
