wxlua-users

[wxlua-users] wxLuaIDE

[klaas.holwerda <kho...@xs...>]

Hi John,

I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D, 
to keep up o date.

I use wxLuaIDE to have a console to run script from my Application 
written with wxArt2D.
In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just 
to make it a modeless dialog to run scripts.
It works more or less. E.g. it comes up but i need to resize it a little 
to show it properly.

Any way, i would like very much to have this  wxLuaIDE  inside one of 
the libaries instead of having it as  part of  a wxLua application.
Then i would not need to copy wxledit.* anymore into wxArt2D.
Also  i think it would be  good to have  inside the library some 
standard dialogs to work with wxLua script inside an application. WxLua 
being meant to integrate with application, to extend it with scripting, 
currently does need some work to get a nice dialog to run those scripts.
The best way would be to have some ready made IDE dialog (modeless or 
modal), to run and maybe debug application scripts.
Like step through a script line by line. I think it is all there 
already, but because it not inside a library, it is a bit copy/paste to 
use it.

If we had such a dialog, we could use wxluacan to test it, currently it 
just has this menu to choose a script to run.

Do you think this is possible?

Klaas

Re: [wxlua-users] wxLuaIDE

[John L. <jla...@gm...>]

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>
> I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D,
> to keep up o date.

Sorry about the rename, the wxLua app had a class called wxLuaConsole already.

> I use wxLuaIDE to have a console to run script from my Application
> written with wxArt2D.
> In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just
> to make it a modeless dialog to run scripts.
> It works more or less. E.g. it comes up but i need to resize it a little
> to show it properly.

What doesn't work right? I'm guessing the splitter position?

> Any way, i would like very much to have this  wxLuaIDE  inside one of
> the libaries instead of having it as  part of  a wxLua application.
> Then i would not need to copy wxledit.* anymore into wxArt2D.

Umm, we alreay have a lot of module libs, it's a little anoying to for
me to work on all the little bits, plus since the wxLuaEdit app
depends on wxStEdit I think it'd be best to keep it off to the side.
Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
app and not make another module directory?

> Also  i think it would be  good to have  inside the library some
> standard dialogs to work with wxLua script inside an application. WxLua
> being meant to integrate with application, to extend it with scripting,
> currently does need some work to get a nice dialog to run those scripts.
> The best way would be to have some ready made IDE dialog (modeless or
> modal), to run and maybe debug application scripts.
> Like step through a script line by line. I think it is all there
> already, but because it not inside a library, it is a bit copy/paste to
> use it.

I'm not sure exactly what you mean. I think you're saying that you
would like a wxDialog with a child wxLuaIDE to run scripts in. Maybe
you can point me to the code using web cvs to see what you actually
need to do to make this work? I also use the wxLuaIDE, but I don't
think I need to do all that much to it, it's just a window in a
notebook page.

> If we had such a dialog, we could use wxluacan to test it, currently it
> just has this menu to choose a script to run.

Sure, but again, this adds the wxStEdit dependency which makes things
harder for people to compile it.

Regards,
    John Labenski

Re: [wxlua-users] wxLuaIDE

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:
> On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
>   
>> Hi John,
>>
>> I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D,
>> to keep up o date.
>>     
>
> Sorry about the rename, the wxLua app had a class called wxLuaConsole already.
>
>   
>> I use wxLuaIDE to have a console to run script from my Application
>> written with wxArt2D.
>> In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just
>> to make it a modeless dialog to run scripts.
>> It works more or less. E.g. it comes up but i need to resize it a little
>> to show it properly.
>>     
>
> What doesn't work right? I'm guessing the splitter position?
>   
It stays gray at first, so the wxLuaIDE does not adjust itself to the 
wxDialog that is around it somehow.
And i don't know  what to call to make it size properly.

http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/

in the files luawrap.cpp and luawrap.h
http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/include/luawrap.h?revision=1.27&view=markup
http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/src/luawrap.cpp?revision=1.35&view=markup

>   
>> Any way, i would like very much to have this  wxLuaIDE  inside one of
>> the libaries instead of having it as  part of  a wxLua application.
>> Then i would not need to copy wxledit.* anymore into wxArt2D.
>>     
>
> Umm, we alreay have a lot of module libs, it's a little anoying to for
> me to work on all the little bits, plus since the wxLuaEdit app
> depends on wxStEdit I think it'd be best to keep it off to the side.
> Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
> app and not make another module directory?
>   
That would mean more include paths. Is there not an existing module 
where this fits in? Aah wxstedit needed right!
It would also exclude it from use in wxluacan, which would  be a nice 
demo on how to integrate wxlua scripting  in any app.
I think a module would be best, although i understand that you are not 
happy with that.
Maybe we just need a "misc" module, in which we can put all the smaller 
things, which are too small for a new module.

Just curious, why do you find it annoying?, i work with VC IDE and there 
it does not bother me that i have 16 modules?
Without and IDE, it might be cd'ing a lot, but for that we have krusader 
is't it :-)
>   
>> Also  i think it would be  good to have  inside the library some
>> standard dialogs to work with wxLua script inside an application. WxLua
>> being meant to integrate with application, to extend it with scripting,
>> currently does need some work to get a nice dialog to run those scripts.
>> The best way would be to have some ready made IDE dialog (modeless or
>> modal), to run and maybe debug application scripts.
>> Like step through a script line by line. I think it is all there
>> already, but because it not inside a library, it is a bit copy/paste to
>> use it.
>>     
>
> I'm not sure exactly what you mean. I think you're saying that you
> would like a wxDialog with a child wxLuaIDE to run scripts in. Maybe
> you can point me to the code using web cvs to see what you actually
> need to do to make this work? 
See above, it is exactly what you say that i have.
> I also use the wxLuaIDE, but I don't
> think I need to do all that much to it, it's just a window in a
> notebook page.
>   
Right, and copy wxledit.* plus the art/*.bmp etc.  ;-)
>   
>> If we had such a dialog, we could use wxluacan to test it, currently it
>> just has this menu to choose a script to run.
>>     
>
> Sure, but again, this adds the wxStEdit dependency which makes things
> harder for people to compile it.
>   
wxLua already detects if wxstedit is available, if its not, it is not 
included. I think Francesco does not find it much of a problem to arrange.
At least on Unix.

Thanks,

Klaas

Re: [wxlua-users] wxLuaIDE

[John L. <jla...@gm...>]

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> John Labenski wrote:
> > On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> >> It works more or less. E.g. it comes up but i need to resize it a little
> >> to show it properly.
> >
> It stays gray at first, so the wxLuaIDE does not adjust itself to the
> wxDialog that is around it somehow.
> And i don't know  what to call to make it size properly.

I think I should use a sizer to arrange things, maybe it's not getting
a final wxSizeEvent so that the code in wxLuaIDE::OnSize isn't run.

> http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/
> in the files luawrap.cpp and luawrap.h

I don't see that you really do anything special to get it working? The
class "a2dLuaConsole" as used in this dialog "a2dLuaExecDlg" right?

> >> Any way, i would like very much to have this  wxLuaIDE  inside one of
> >> the libaries instead of having it as  part of  a wxLua application.
> >> Then i would not need to copy wxledit.* anymore into wxArt2D.
> >
> > Umm, we alreay have a lot of module libs, it's a little anoying to for
> > me to work on all the little bits, plus since the wxLuaEdit app
> > depends on wxStEdit I think it'd be best to keep it off to the side.
> > Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
> > app and not make another module directory?
> >
> That would mean more include paths. Is there not an existing module
> where this fits in? Aah wxstedit needed right!
> It would also exclude it from use in wxluacan, which would  be a nice
> demo on how to integrate wxlua scripting  in any app.
> I think a module would be best, although i understand that you are not
> happy with that.

What about just adding the path $(WXLUA) to your include path and then
include this in the header
#include "apps/wxluaedit/src/wxledit.h"
and this in the cpp file
#include "apps/wxluaedit/src/wxledit.cpp"

It's a little unconventional, but will easily work. The only thing is
that it won't work if you install wxlua to a system directory? Do you
do that?

> Maybe we just need a "misc" module, in which we can put all the smaller
> things, which are too small for a new module.

Nah, again it needs wxstedit and I don't think anything else ever will.

> Just curious, why do you find it annoying?, i work with VC IDE and there
> it does not bother me that i have 16 modules?
> Without and IDE, it might be cd'ing a lot, but for that we have krusader
> is't it :-)

Its ok I guess. I hate to have a whole separate module for just
wxledit.h/cpp, seems like overkill. Let me know what you think about
the #include hack above.

On the code editor standpoint, I haven't found  good one for Linux. I
just use my editor in the modules directory to load all the files.
$wxStEdit -r *.h *.cpp &

The problem I have is that all the IDEs I've tried want to generate
build files or other files for me, but all my projects are complete
and I can't find how to not make them be so "helpful". The last I
tried kdevelop was the least intrusive, but I forget why I stopped
using it.

Regards,
    John Labenski

Re: [wxlua-users] wxLuaIDE

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:
>> http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/
>> in the files luawrap.cpp and luawrap.h
>>     
>
> I don't see that you really do anything special to get it working? The
> class "a2dLuaConsole" as used in this dialog "a2dLuaExecDlg" right?
>   
Right. I normally just call things like Fit(), what special think should 
i try?
I must admit that i am not so good in sizers and how and why what to call.
>
> What about just adding the path $(WXLUA) to your include path and then
> include this in the header
> #include "apps/wxluaedit/src/wxledit.h"
> and this in the cpp file
> #include "apps/wxluaedit/src/wxledit.cpp"
>   
In that case better copy, since how will users understand such things.
Currently i do already set WXLUA (after installing), just to get to the 
script for generating the bindings.
This is part of the Cmake files. But not needed, if using a released 
distribution, so acceptable.
But asking users to have wxLua installed, and the wxLua source to get to 
the two wxledit files, is a bit to much.
> It's a little unconventional, but will easily work. The only thing is
> that it won't work if you install wxlua to a system directory? Do you
> do that?
>   
Yes, that i always do. Do you use  it with --prefix?
> Its ok I guess. I hate to have a whole separate module for just
> wxledit.h/cpp, seems like overkill. Let me know what you think about
> the #include hack above.
>   
You have seen the problem with it already. Also the bitmaps in the art 
directory is a problem, they would need to be installed too, if it were 
a library. So if it not will be a module, i stick to copying for the 
moment. Still wxluacan would be oke to include/use the files like you 
propose.  Maybe a nice add once it starts working.

BTW is  a step mode in scripts possible from the wxLuaIDE class?

> On the code editor standpoint, I haven't found  good one for Linux. I
> just use my editor in the modules directory to load all the files.
> $wxStEdit -r *.h *.cpp &
>   
You should have a look at krusader, almost the same as windows commander 
on windows.
I use it for almost anything (edit, search, pack, browse dirs.).

Klaas

Re: [wxlua-users] wxLuaIDE

[John L. <jla...@gm...>]

On 12/17/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> >> What about just adding the path $(WXLUA) to your include path and then
> >> include this in the header
> >> #include "apps/wxluaedit/src/wxledit.h"
> >> and this in the cpp file
> >> #include "apps/wxluaedit/src/wxledit.cpp"
> >>
> > In that case better copy, since how will users understand such things.
> > Currently i do already set WXLUA (after installing), just to get to the
> > script for generating the bindings.
> > This is part of the Cmake files. But not needed, if using a released
> > distribution, so acceptable.
> > But asking users to have wxLua installed, and the wxLua source to get to
> > the two wxledit files, is a bit to much.
> I agree.

Ok, lets make a wxluaedit module with the two files wxledit.h/cpp in it.

> I also think that having a stock dialog for running wxLua scripts and
> maybe debug them would be very nice. Unfortunately I don't really know
> much about wxLua internals and wxStEdit, so here it is my dumb question:
> do such things need wxStEdit? wouldn't it be possible to add such things
> to "wxlua" module _without_ making it depending on wxStEdit?

The wxStEdit lib provides all the nice wxStyledTextCtrl functionality
that is needed to actually make it work. There's a lot of code to keep
menu/toolbar items updated and I'd hate to have to duplicate it.
Find/Replace is another bit of non trivial code, splitting is also
nice and you have to create your own splitter to get it to work by
refing the editor, the wxNotebook doesn't send enough events so again
wxStEdit has it's own subclassed wxNotebook to make sure menu/tool
items are updated. I would not want to maintain two copies of the same
thing

We could make a dumb wxTextCtrl based editor. I'm still not sure how
much and what functionality is wanted though.

An editor to edit the scripts (notebook too?)
File open/save
Run scripts
Debug them?
Scripts are run in main thread? Safety issues?
Want toobar and menubar?
Need output window for errors

> If it's really required, maybe we could still add it to wxlua module and
> then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.

Wouldn't we still need the #include stedit stuff making wxStEdit a
compile time dependency? Can you subclass classes in DLLs?

> >> It's a little unconventional, but will easily work. The only thing is
> >> that it won't work if you install wxlua to a system directory? Do you
> >> do that?
> >>
> > Yes, that i always do.
> I always do that, too ;)

Ok, I never do, had a really bad experience with an install script
messing up my system years ago and have been afraid of them since. :)

> > You should have a look at krusader, almost the same as windows commander
> > on windows.
> > I use it for almost anything (edit, search, pack, browse dirs.).
> I'm now get used to KATE. It's great I think.

I like Kate too, the one thing I miss is not being able to click in
the output window during a compile to go to the line of an error or
warning easily, I don't think it can do that.

Regards,
    John Labenski

Re: [wxlua-users] wxLuaIDE

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:
> Ok, lets make a wxluaedit module with the two files wxledit.h/cpp in it.
Thanks a lot!
When the module is there, i will fix the wxluacan sample to use it, what 
more can i do :-(
What can we do with the files in the art directory?
>  I would not want to maintain two copies of the same
> thing
>   
Just stick to wxstedit, if its not available, don't compile the module. 
Is that actually possible with bakefiles/makefiles?
> We could make a dumb wxTextCtrl based editor. I'm still not sure how
> much and what functionality is wanted though.
>
> An editor to edit the scripts (notebook too?)
>   
Notebook is not needed.
> File open/save
> Run scripts
> Debug them?
>   
That very much.
> Scripts are run in main thread? 
I think for general use this is good enough.
> Safety issues?
>   
Don't know what you mean by this?
> Want toobar and menubar?
>   
Nice to have but for a simple version control nothing fancy would be needed
> Need output window for errors
>   
Yes, that is a needed. And especially  a step mode  for debugging. And i 
don't know what wxLuaIDE  can do, but making breakpoints  would be  real 
cool.
If possible, i think we can add a modeless  version of wxLuaIDE in the 
module, people can use that without much trouble.
One more request :-) A way to set the default place to open scripts 
files. Very likely already there?
>   
>> If it's really required, maybe we could still add it to wxlua module and
>> then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.
>>     
>
> Wouldn't we still need the #include stedit stuff making wxStEdit a
> compile time dependency? Can you subclass classes in DLLs?
>   
Right, i think a dummy wxTextCtrl when wxStedit is not available would 
be ideal.
>
> Ok, I never do, had a really bad experience with an install script
> messing up my system years ago and have been afraid of them since. :)
>   
I was like that, but now that i know it is just going to /usr/local/ i 
feel more save.
But i agree it is risky. Normally there is also an install prefix option 
in configure.
I used that a lot at work on solaris, where becoming root to "install 
what  i think might be oke" is out of the question :-)
So you can always test using the install scripts being non root.
>
> I like Kate too, the one thing I miss is not being able to click in
> the output window during a compile to go to the line of an error or
> warning easily, I don't think it can do that.
>   
Now that would be handy indeed.

Klaas

Re: [wxlua-users] wxLuaIDE

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
>> What about just adding the path $(WXLUA) to your include path and then
>> include this in the header
>> #include "apps/wxluaedit/src/wxledit.h"
>> and this in the cpp file
>> #include "apps/wxluaedit/src/wxledit.cpp"
>>   
> In that case better copy, since how will users understand such things.
> Currently i do already set WXLUA (after installing), just to get to the 
> script for generating the bindings.
> This is part of the Cmake files. But not needed, if using a released 
> distribution, so acceptable.
> But asking users to have wxLua installed, and the wxLua source to get to 
> the two wxledit files, is a bit to much.
I agree.

I also think that having a stock dialog for running wxLua scripts and 
maybe debug them would be very nice. Unfortunately I don't really know 
much about wxLua internals and wxStEdit, so here it is my dumb question:
do such things need wxStEdit? wouldn't it be possible to add such things 
to "wxlua" module _without_ making it depending on wxStEdit?

If it's really required, maybe we could still add it to wxlua module and 
then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.

>> It's a little unconventional, but will easily work. The only thing is
>> that it won't work if you install wxlua to a system directory? Do you
>> do that?
>>   
> Yes, that i always do. 
I always do that, too ;)


>> On the code editor standpoint, I haven't found  good one for Linux. I
>> just use my editor in the modules directory to load all the files.
>> $wxStEdit -r *.h *.cpp &
>>   
> You should have a look at krusader, almost the same as windows commander 
> on windows.
> I use it for almost anything (edit, search, pack, browse dirs.).
I'm now get used to KATE. It's great I think.

Just my 2 cents,
Francesco

Re: [wxlua-users] wxLuaIDE

[klaas.holwerda <kho...@xs...>]

Francesco Montorsi wrote:
> I agree.
>
> I also think that having a stock dialog for running wxLua scripts and 
> maybe debug them would be very nice.
Yep, i think it will make things much easier for new users which want to 
integrate wxLua in there app.
Especially if the wxluacan shows them how to do it. With debug the 
scripts and stepping through your own scripts, what more does one want.
>  Unfortunately I don't really know 
> much about wxLua internals and wxStEdit, so here it is my dumb question:
> do such things need wxStEdit? wouldn't it be possible to add such things 
> to "wxlua" module _without_ making it depending on wxStEdit?
>   
A simplified version i think.
> If it's really required, maybe we could still add it to wxlua module and 
> then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.
>   
Better if its available use it, and else fall back on a simpled text 
control.
But i don't know is this is possible at all.
>>
> I'm now get used to KATE. It's great I think.
>   
My other favorite ;-)
And the same editor component is used in krusader.

Klaas