Scripting to be added to Screenshot Captor

[mouser]

I have decided to add a scripting facility to Screenshot Captor.

This will let you define any number of scripts which can be triggered manually or automatically, that do various operations.
You will be able to define a script to do bordering, cropping, shadows, rename, save, etc., as well as launch other programs with the file (ftp, mail, etc.).

This is just a heads up, i'm not starting work on it yet, i still have FARR 2 which will be done before this.  It's just a heads up for people who want to add suggestions related to this, and so there is time to debate about this new feature.  I havent decided whether to use an existing language like lua or python, or go some other route.

[AbteriX]

I have decided to add a scripting facility to Screenshot Captor.

-mouser (August 10, 2006, 01:58 AM)

Fine.

It's just a heads up for people who want to add suggestions related to this,
and so there is time to debate about this new feature.

-mouser

I like to see a few (~3 or 5) "quick launch buttons" to execute a few preferred scripts.
Or an drop-down box: click on the arrow - hoover the mouse over an script name and click it.

  I havent decided whether to use an existing language like lua or python, or go some other route.

-mouser

Must i install smtg for this? Why not VBS?

[f0dder]

LUA, most definitely. Very low overhead (size as well as speed), great license, pretty familiar to people who know C/C++.

And of course the "if it works for them, it'll work for you factor" - LUA is used in a lot of places now. First two things off top of my head would be World of Warcraft and Painkiller.

[mouser]

i am not that fond of lua.  but i might try squirrel.

[f0dder]

i am not that fond of lua.  but i might try squirrel.

-mouser (August 10, 2006, 10:45 AM)

It's "tried and tested" though, and has a couple advantages over Python (more C-like, less overhead).The key to comfortable LUA scripting is adding decent bindings.

Squirrel looks interesting.

[Eóin]

Hmm, hadn't heard of Squirrel before must look ito it, but must mention I was always fond of Lua, especially with the luabind library which seems to make interaction with C++ a breeze.

[NeilS]

I've integrated Lua and Ruby into programs in the past.

Lua was pretty easy to get going, but the stack-based API was a pain to work with and pretty error prone, so you'd want to wrap that up so you don't have to deal with it. There's a mod of Lua called LuaPlus which adds some handy features and also wraps the stack-based API nicely for you. Not sure if any of that functionality has made it into the core since then (it was a while ago). In terms of the language, I never really liked it that much - the philosophy of a lightweight language that you can bend to your will is a nice one, but I think they could have built-in some decent OOP support by default.

Ruby was a bit harder to get going. It was never designed to be used as an embedded language, and the source is... interesting (very diplomatic term there). There's also not a lot of info on embedding it - mostly lots of scraps and slightly weird docs kicking around. It basically took a fair bit of digging and experimentation, but it's simple enough once you get used to it. In terms of language, well, I don't think I've ever used a language which is more enjoyable and productive - there's a reason a lot of people are getting into Ruby these days.

Lua is generally quite a bit faster than Ruby, although that's not really an issue if you're using it to automate a program. I wouldn't use Ruby in a game, for example, but then, I wouldn't use Lua either. Don't ask what I would use.

My overall opinion, having tried both, is that Ruby is worth the extra effort, so long as your program doesn't rely on it being really fast.

Mouser, if you decide to try Ruby out, I can give you some pointers to help speed things up if you want. I could probably help a bit with Lua if you decided to use that, although my Lua knowledge is a bit out of date, and there's lots of Lua info out there anyway.

[mouser]

for some reason lua just didn't capture my heart from the book i read; ruby the same, though i feel more like i could maybe adjust to ruby.  my programming style in general lends itself more to big oop programs rather than scripts.  i always do things in 100 lines which could be done in 1 line of a scripting language, for better or worse.

but squirrel (http://www.squirrel-lang.org/) really seemed to appeal to the c++ coder in me, so i may give that a try.  on the other hand, scripting for screenshot captor will be very light weight and minimal, and so lua might end up being perfect for that.

[Eóin]

... squirrel (http://www.squirrel-lang.org/) really seemed to appeal to the c++ coder in me

-mouser (August 10, 2006, 12:39 PM)

I must admit it grabbed my attention too, it would be nice to hear from people who have worked with both, but such people might be hard to find.

[NeilS]

for some reason lua just didn't capture my heart from the book i read; ruby the same, though i feel more like i could maybe adjust to ruby.  my programming style in general lends itself more to big oop programs rather than scripts.  i always do things in 100 lines which could be done in 1 line of a scripting language, for better or worse.

-mouser (August 10, 2006, 12:39 PM)

I'm not quite sure what you mean by "big oop programs" versus scripts. Do you mean "big C++ programs", where the meaning of the code is more explicit, at the expense of being larger (not to mention about a squillion times faster)?

but squirrel (http://www.squirrel-lang.org/) really seemed to appeal to the c++ coder in me, so i may give that a try.

All I can say to that is that there's more than one type of coder inside every programmer. You just need to let the other ones come out and play sometime.

on the other hand, scripting for screenshot captor will be very light weight and minimal, and so lua might end up being perfect for that.

Are you likely to add scripting to any of your other apps?

[mouser]

I'm not quite sure what you mean by "big oop programs" versus scripts. Do you mean "big C++ programs", where the meaning of the code is more explicit, at the expense of being larger (not to mention about a squillion times faster)?

yes i meant oop as in object oriented programming.

my philsophy of programming is that verbosity is good.  i find that some people are really drawn to languages like perl where you can write one line that does a lot.  i prefer having a longer function and bigger infrastructure that feels to me more organized.

>Are you likely to add scripting to any of your other apps?

yep, that's part of the calculus involved; even thought sc will have only minimal scripting, ill be using it more in other more substantial roles in other projects, so i have to take that into consideration yet.

[NeilS]

yes i meant oop as in object oriented programming.

my philsophy of programming is that verbosity is good.  i find that some people are really drawn to languages like perl where you can write one line that does a lot.  i prefer having a longer function and bigger infrastructure that feels to me more organized.

-mouser (August 10, 2006, 09:17 PM)

I think what confused me was that it seemed as if you were implying that scripts weren't OOP programs, but you were actually talking about the verbosity of the code you would normally write in a language like C++ versus the average scripting language.

The idea that verbose code is more organised is an interesting notion. Say you have a sequence of code that you tend to write a lot in C++, but the same thing can be expressed in one line or one operator in, say, Ruby. Do you think that having to repeat those code sequences in C++ in lots of places is more organised than having a construct which does the same thing without the repetition? (I'm not saying that's wrong, btw, although I suspect it means that we have different definitions of "more organised").

>Are you likely to add scripting to any of your other apps?

yep, that's part of the calculus involved; even thought sc will have only minimal scripting, ill be using it more in other more substantial roles in other projects, so i have to take that into consideration yet.

Hehe, you read my mind.

[f0dder]

Say you have a sequence of code that you tend to write a lot in C++, but the same thing can be expressed in one line or one operator in, say, Ruby. Do you think that having to repeat those code sequences in C++ in lots of places is more organised than having a construct which does the same thing without the repetition?

-NeilS

You wouldn't repeat those code sequences, though, you would factor them out to a function or similar. You might then argue that nothing has been won, but au contraire; it's easy to follow into a function call (visual studio or similar IDEs, or CTAGS based stuff), where you can then read the proper and verbose code.

Compare that to some of the atrocious one-liners you can do in perl

[NeilS]

You wouldn't repeat those code sequences, though, you would factor them out to a function or similar. You might then argue that nothing has been won, but au contraire; it's easy to follow into a function call (visual studio or similar IDEs, or CTAGS based stuff), where you can then read the proper and verbose code.

-f0dder (August 11, 2006, 06:53 AM)

Not all code sequences can be converted into functions easily though, certainly not in a language like C++. The classic example is using a for loop with iterators into a container, e.g:

[Select]

for(AList::iterator it = list.begin(); it != list.end(); ++it)
{
  // Do something with 'it'
}

That's a pretty common code sequence in a lot of C++ programs. There are various ways to implement it so that the for loop is more concise (e.g. functors). But functors just add more code somewhere else and you still have the problem of not having access to any of the local variables in the function where the for loop resides.

Contrast that with the Ruby equivalent:

[Select]

list.each do |it|
  // Do something with 'it'
end

There's no reasonable way to achieve something this concise and readable in C++ by factoring out into functions.

In case you're wondering, I'm not trying to make some sort of language advocacy point here. I'm just trying to understand Mouser's philosophy about preferring verbosity, and what he actually means by that.

Compare that to some of the atrocious one-liners you can do in perl

Don't get me wrong, I'm in complete agreement that atrocious one-liners are, well... atrocious. But just because you can write such lines in languages like Perl and Ruby, that doesn't mean you have to. In fact, the Ruby community is trying to encourage people to stop using the various "Perlisms" available in Ruby because Ruby is plenty concise and very readable without them.

Besides, you can write pretty atrocious one-liners in C++ using macros or templates.

[Eóin]

[Select]

for(AList::iterator it = list.begin(); it != list.end(); ++it)
{
  // Do something with 'it'
}

That's a pretty common code sequence in a lot of C++ programs. There are various ways to implement it so that the for loop is more concise (e.g. functors).

-NeilS (August 11, 2006, 08:22 AM)

Sorry mouser for dragging this so far of topic, but NeilS another option for C++ code is Boost.FOR_EACH .

[mouser]

f0dder basically covered my point of view.  i'd rather have a hierarhcy of objects and function indirection that takes up 200 lines than 10 lines of code, IFF it seemed more logical and reusable to me.

however, longer code does not mean repeating code; any time you are repeating blocks of code is a good sign that the code is not as elegant as it should be.

your example above comparin a foreach type statement with c++ use of templates and iterators is a fair one.  personally i find iterators in c++ pretty damn ugly, though they are powerful.  don't get me wrong, i think c++ is full of flaws and ugly stuff.

and as you said the scripting languages today are becoming full oop programing languages (unlike the early days of toy scripting languages).

however, i am a fan of strong static typing.  any programming language where you can just start using a variable without declaring it, or do some weird assignments between incompatible types without generating an error, is not going to be something i am happy with.

i do believe this is represents a fundamental difference in the basic approach to using a scripting language and other languages.  scripting languages tend to be designed for quick and dirty coding, and try to save you the time and effort of writing elaborate stuff that the interpreter can do a pretty good job of guessing.  I prefer to have a language that requires strict declaration of type information and can catch potential errors at compilation time.

for me this is a fundamental (perhaps *THE* fundamental) mistake that language designers make - not taking seriously the idea that the language should be designed to make it as hard as possible to make a mistake without it being flagged as a mistake.

99% of the problems with css and html could be solved if the damn implementations threw up real errors when something was non-compliant, instead of silently just trying to do their best to guess what you wanted to do, which makes it 100x harder to find and fix bugs.

[NeilS]

Sorry mouser for dragging this so far of topic, but NeilS another option for C++ code is Boost.FOR_EACH .

-Eóin (August 11, 2006, 08:53 AM)

Of course, but that's a macro, and it was just an example.

[NeilS]

however, i am a fan of strong static typing.  any programming language where you can just start using a variable without declaring it, or do some weird assignments between incompatible types without generating an error, is not going to be something i am happy with.

<snip>

-mouser (August 11, 2006, 08:57 AM)

So are you basically saying that you want a scripting language that's pretty much the same as C++?

What about something like Ch?

[mouser]

i looked at Ch a long time ago (don't think it was free then), but it didn't really do it for me.
i'm going to have to give it more thought before i make a commitment to choosing one, and im not dead set against using something like lua or ruby or python in a program, i just cant help but feel not completely satisfied with any of them.

[NeilS]

I'm getting the distinct impression that we might be seeing something called "DCScript" on the horizon.

[mouser]

writing a full language is something most coders dream of.. i only wish i had the time to spend on it - but i know i dont, so dont hold your breath.

[NeilS]

I hope you realise I was kidding there. 

[AbteriX]

back to topic
i have a few questions to be up to state:

1. i don't like to script SC in OOP, that's sounds i have to wrote a lot of code
to e.g. put an border around an image ?
Can we have some scripting code examples for imagine please?

2. again, what means to use e.g. LUA... i would need my
SC to come with me on my USB-Stick.
I don't want/can't install a language on all PCs.....or can i use LUA 'stand alone'?
And how big would e.g. the LUA folder be?

Again, why not VBS with an captor.dll as 'API' .....(i don't know if i use the right terms)
I think WSH is on the most PCs standard?

Can't we use a portable scripting language like AHK or AutoIt?

[f0dder]

AbteriX: LUA is small and embedded, so you don't need to install anything. I think a *full* LUA system can be added in less than 100kb.

 
 

[mouser]

whatever scripting i add to sc will be built in and small; as f0dder says it really shouldnt have much of an impact and im not going to use anything big or anything that requires a separate install.

all of the discussion above is more philosophical.  for sc the script will be EXTREMELY simple:
it will be stuff like this
ResizeTo(320,200);
Border("white",2);
Border("blank",1);
DropShadow(4);