suggestions

Mar 10, 2009 at 12:54 PM
hi!!
first of all i want to wish highsign team good luck with this project.

second, i am a programmer and i worked with a lot of programming languages, including asm.
My opinion is that this application was more stable, and low resource consumption if it was written in a native programming language with no dll's needed (like c++ builder or delphi).

third, all i want from a mouse gesture app is to control a specific application, not all of them, and of course not the desktop. What i mean is that it will be very efficient
if is implemented a menu, checkbox or anything where i can choose if highsign will control only the application i want.

four, it even be more useful if a gesture has different effect on different app [send different keystrokes or...], or it would be amazing if
every application i want to contol has its own mouse gestures, even if they are the same with another application. I mean i wish highsign will detect current window and
will take associated action if gesture and current window are correct and defined in highsign lists.

five, thank you!!

six, [I currently learn english and I have a lot of writing mistakes]
Mar 10, 2009 at 6:17 PM
Hi kornellh and thanks for your input!

I'll respond in the order of your comments.

1. Thanks!  We're working very diligently in making High Sign the best that it can be.

2. I can agree that this type of program would ideally be a more native one, however, development time and maintenance (see StrokeIt  :-] ) are factors in the decision to use C#.  Windows is quite a moving target regarding window interaction, etc. and utilizing the .NET framework helps to ensure that compatibility issues don't snowball as time moves forward and more Windows core functions change.  Resource-wise, there's a large misconception about what Task Manager reports for a .NET application vs. a native one.  While I don't disagree that a native app consumes less resources, the .NET framework is shared and these days it's becoming increasingly rare that a system won't already have the .NET framework loaded into memory for at least one other application anyway.  To that end, utilizing the .NET framework also makes exception handling, etc. a snap, so the likelihood of strange, subtle behavior far less likely than a native program, especially considering we're not being paid to spend all day chasing down pointers, etc.  :-]  Regarding stability, we are still in alpha, and while I think it's actually quite stable for such a release, there are a number of enhancements and refactoring that are underway right now, all in the goal of making High Sign as efficient and streamlined as possible; which generall equates to stability in the end.

3. The High Sign release currently available does support application specific gestures.  In addition, the code has been completed which will allow you to instruct High Sign to ignore any application you wish; this will go a long way to increasing the flexibility of High Sign and put you in control.

4. See 3, High Sign does support application specific gestures, if you're having an issue with that, please provide us with some details and we'll look into it.

5. You're welcome!

6. I am fluent in English and still make mistakes all the time  :-]

Robert Larkin
Coordinator
Mar 10, 2009 at 6:43 PM
kornellh,

Thank you for your feedback! We use all the valuable feedback provided by our users to make HighSign better everyday.

Regarding your comment about native code being more stable than the managed CLR of the .NET framework, I'd have to disagree. The reason for managed code (in the .NET Framework) is to reduce the risk of memory leaks and clashes, as well as abstracting low level functionality to provide consistent interfaces and behavior for every application. Also, it's worth noting that the .NET CLR compiles .NET code (MSIL) to machine code when it's ran the first time (see JIT), so we're not dragged down by a heavy VM like some people believe. As for the memory footprint of High Sign, people see the "memory usage" listed next to the application in the task manager and get all up in arms about how high it is. But in reality that number simply represents the working set of memory that the .NET framework has allocated for us, which 99% of the time we're not using close to that amount. This is actually a benefit of using managed code because when we cache more memory than we need, we don't have to reallocate memory for every new bit of information we need to store (unless we step over the amount we've been allocated). Here is a well written article by Tim Anderson explaining the memory usage misconception.

It should also be said that High Sign is fully capable of having application specific gesture and actions. It has always existed since the beginning of High Sign. Allow me to direct you to a wiki page describing how to train High Sign with new gestures and applications.

We really appricate your interest in testing High Sign during the Alpha phase, and hope you will continue to use High Sign as it matures. Your feeback is paramount to High Sign's success so please keep it coming.

Dylan Vester
Mar 11, 2009 at 9:01 PM
ok, thanks for replys!

Probably I never expressed how.
I said I wanted to control only one application, not the rest, that is when you do right click and move mouse in another application  I want to nothing to happen (no line draw, nothing) without say HS explicitly which applications I want to do this (pure and easy to ignore all the applications that are not listed in HS). Oh, and I said that i whised different lists for each app i define something like that:

app 1 -> gesture 1 -> keystroke  or something
              gesture 2 -> ----------||-------------
               .....................................................
              gesture n -> ----------||-------------

app 2 -> gesture 1 -> keystroke  or something
              gesture 2 -> ----------||-------------
               .....................................................
              gesture n -> ----------||-------------

......................................................................

app n -> gesture 1 -> keystroke  or something
              gesture 2 -> ----------||-------------
               .....................................................
              gesture n -> ----------||-------------

ALL OTHER apps just ignore, i don't need a gesture for them (nothing to be drawn when i right click and move mouse)
Probably I will take a deep look in the source, sometime, and modify what i need, but i need first to understand how was written (which is a lot of time...)



about .net framework, I want to say that all apps written for .net are interpreted by a virtual machine, and never, i mean never, such app will be more fast that one written in a native language.
.net is thinked for portability, so if you translate let's say framwork 2 for linux, applications written for framework 2 will run in linux and windows but, i repeat, under a virtual machine.
Practically is easier to write and mantain a app written for .net becouse the tools you have in the ide and externally.
.net is increasing productivity but has some minor disavantages.
Probably I have choosen .net for writing a open source app. I don't want to get into controversial i've just exprimed my opinions,

gj, keep going
Mar 11, 2009 at 9:23 PM
Ok, now I see what you mean about the applications, that's a somewhat inverted approach that you're looking for.  I'll have to talk with Dylan about the feasibility of essentially excluding the global app and testing the target window to see if it has been defined.  I have no idea how complicated it may be and if it's something that will be addressed sooner, rather than later.

Not to turn this into a debate, but .NET executables are, in fact, compiled to native machine code when first executed on each machine, it simply uses the .NET framework as a runtime library.  They do not run in a virtual machine.  It's no different than compiling native with C++ runtime libraries being accessed/referenced, other than there is more overhead since .NET takes care of more things automatically.


Robert Larkin