DSL PanelI

Forum: Apps
Topic: DSL PanelI
started by: zakiakhmad

Posted by zakiakhmad on Sep. 21 2007,09:17

Halo

I'm trying to make similar application to DSL Panel. There is button, and then execute application. Could someone tell me, how to make DSL Panel?

Previously, I tried tor made with Tcl/Tk. Unfortunately, within default condition, isn't available on DSL. I've tried also with Perl Gtk2.

Thanks!

Posted by curaga on Sep. 21 2007,10:03

The DSL panel is made with Lua. I cannot help with that though..

Posted by Juanito on Sep. 21 2007,11:16

You could try looking at /usr/sbin/cpanel.lua

Posted by mikshaw on Sep. 21 2007,13:11

check here:
< http://www.murga-projects.com/murgaLua/index.html >
and here:
< http://www.lua.org/manual/5.1/ >

Posted by roberts on Sep. 21 2007,19:20

You might want to look at the over 50 examples of lua and lua/fltk programs already in DSL. Use the find tool and look for *.lua

The murgaLua site is usually using a newer version of their software so it may or may not work. Or hopefully will be backward compatible.

FYI
Actually, I am concerned with the direction of that project, as they seem to be loading in more and more. What is typically is a module choice is no longer such and murgaLua is becoming like AIOLua.

The latest version seems to run much more slowly on my old boxes. Of course, I could not expect that project to not accomodate their user base wanting an all-in-one gui language system.

This is in no way a negative but only another realization of how most software progresses. DSL is always faced with larger software packages and thus the need for larger or more powerful hardware on which to run it.

Most of the lua/fltk in DSL was written before murgaLua project started.

Posted by zakiakhmad on Sep. 22 2007,04:21

OK, thank you guys for the attention. I really appreciate it. I'll try the lua/fltk later.

Posted by mikshaw on Sep. 22 2007,13:25

Quote

Or hopefully will be backward compatible.

Sadly, it's not entirely backward compatible. This was known when the latest was released, and it seems that the decision was to bite the bullet in order to make use of lua filesystem without including redundant features.
It is possible to do checks within your script that will enable the script to be run on either version, but existing scripts may not work...if it expects murgaLua.readDirectory it won't work in 0.5 and if it expects lfs.dir it won't work in 0.4.

I haven't noticed any performance hit myself, but then I haven't booted up the older box since before 0.5 was released. I wonder if Mr. Murga is aware of this, and if there is any optimization that could repair the slowdown. I haven't got a clue how toolkit bindings work, but maybe the method he's using is in need of some performance tweaks. I undertstand that it is fairly common practice for some developers to use the same techniques on a growing project that they used when it was a tiny project, and often these techniques do not scale well.

My own personal wish for its development includes what some may consider creeping featurism, but as long as there are important (?) parts of FLTK that are not implemented, or only partially implemented, the project seems incomplete to me. After all, it is essentially Lua+FLTK.

Quote

What is typically is a module choice is no longer such

I have only looked briefly into the possibility of using Lua modules in murgaLua, but so far have had no success understanding the process. I suppose it will become easy enough eventually, but the documentation on this subject is vague.
If modules can be loaded into murgaLua as they are in Lua proper, it might be silly to include them, but I think it depends on what modules they are. Some things, such as lfs, are things that I consider vital for any task that involves working with files (which is nearly everything i've ever done). And then I think modules themselves can contribute to their own form of bloat, in that the number of modules a user needs seems to grow at a greater rate than the number of scripts using those modules (see Perl, Python).

Posted by curaga on Sep. 22 2007,14:57

I recently played around with Xdialog, and gotta recommend it. It's a whole lot easier than Lua, but not of course as suitable for many cases.

Posted by roberts on Sep. 23 2007,15:09

I believe some of murga's choices is because his Lua language system is supporting multiple operating systems, i.e., the inclusion of lfs. Supporting only Linux one can get by with much less than supporting Windows and Mac.

Like I said I cannot find fault with that it is just on a 300Mhz machine the latest version is noticeable slower. I no longer use murga.isDirectory or lfs, but instead popen to access file system features. I use similiar syntax to support isDir readDir and getDirs. I am aware that popen is not supported on all other OS and thus the need for lfs

Personally I would agree that focus should remain on implementing the fltk bindings and not importing other third party libraries.

mikshaw, perhaps a custom build (Linux only) could be achieved using the documented build process? That way we could have just the fltk bindings?

Posted by mikshaw on Sep. 23 2007,16:40

Quote

Supporting only Linux one can get by with much less

I fully agree. It's a whole lot easier to write your scripts when doing only Linux, too. As you said, you can rely a lot on pre-existing programs to do things that would waste a lot of space and time in Lua script

Quote

perhaps a custom build (Linux only) could be achieved using the documented build process?

I had never thought of that, but I suppose it would probably work. I haven't looked at the bindings at all, but I suspect it could be cut down a bit without having to study it to the finest detail. Hmmm...a new distraction =o)
Maybe I'll look at it after the sox game.

Posted by mikshaw on Sep. 23 2007,20:51

I didn't see anything os-specific that could easily be removed (by me), but I did make a test with a non-Xft FLTK installation (1.1.7 stable doesn't work, by the way), disabling lfs, sqlite, LZO, and iostring (luasocket is a little more tricky, since it's used in multiple files). The result came out to about 305k, though I haven't compared its performance.

It got me thinking that perhaps some of the slowdown is in the Xft version of murgaLua? Just a guess, though. I have no idea if you were comparing 0.5.5 Xft with 0.4 non-Xft. I can see a slight performance difference between Xft and non-Xft within the same release

Posted by roberts on Sep. 29 2007,16:11

Yes. Since I had added the libXft library I was using the xft version.

The difference is much more noticeable on older low end machines.

But it is true about memory consumption. Newer version consumes more:

ps cpanel.lua

0.4 3272
0.5.5 3520 non-xft
0.5.5 4848

Even running non-GUI lua scripts show a slowdown, i.e., more time needed to complete the same task, tested with time.

I would still encourage their project to please try to stay trim and FAST!

I will update to v0.5.5 nonXft for now.

Thanks for your input, mikshaw.