Build 19: Active window tracking

[Freddie]

Anyway, we spend more time arguing whether this is an issue or not than actually fixing it would take -

Wheee. Our first drama on the Mojo project. Not fun.

Moorea, nobody is arguing about that except you (in the PM you just sent me).

All I've been doing is trying to find out what the problem is. From your posts last night, I couldn't tell if

(1) Mojo didn't work on your network at all, or

(2) Mojo worked but you had to resort to a manual setting.

Those are very different things.

If I had understood that you were saying (2), I would have told you:

--- The connection code is unfinished.

-- Of course I intend to enhance it.

-- Of course I am going to try to make it connect automatically under as many conditions as possible.

-- I can't talk about solutions for a problem until I understand what the problem is and I'm certain of what caused it.

And I would have made a special build that logs connection events and asked you to run that build on ICS, so I can see exactly what's happening.

[Freddie]

Regarding the question of two NICs, I don't want to get too far off track here. But since it came up:

When I wrote the early version of Mojo's connection code that we are using, I ordered a USB wireless adapter from Newegg and plugged it into my development machine.

The whole time I wrote and tested the code, there were two NICs in the machine. I did this to make sure the drop down list works with multiple NICs.

The drop down list is an important part of the program. It's there as a fail safe in case the automatic connection code fails.

At this early stage, the automatic connection code is unfinished. It's buggy. It's unreliable. For that reason, the drop down list is especially important in these early alpha builds.

My priority at this early stage is making sure that testers can use the program enough to test new code as I add it build by build.

[Fursphere]

All laptops come with 2+ nics : wireless and ethernet - if you want the best network performance and have 2 such laptops you will setup the ethernet to try to pay the wireless latency "price" only once - which is again my real (not hyphotetical either) case - if you have 1 wired computer, 2 laptops and want to box you may want to setup the way I had: the 2 laptops linked to each other with ethernet; and the rest in a home network; ie 2 interfaces used with 1 of the laptops in the middle

Ok, you've got a point.

But the intent is for the end user to use one or the other, not both at the same time (even though its possible)

And for the record, I said desktop PCs - not laptops.

[Freddie]

I'd like to put this thread in perspective.

This is an alpha test. That means you're watching the program's basic features get built. . Nothing is finished. Auto Connect isn't finished.

If a feature seems incomplete, or if you wished it did more than it does, that doesn't mean there's a bug. It probably just means the feature hasn't been finished yet.

Eventually, at some future time, I'll get back to Auto Connect and improve it. But for now, at this stage of the alpha test, as long as everybody can connect with manual settings, that's good enough.

Unless somebody finds a serious problem in Auto Connect that prevents people from using the program I'm not going to work on Auto Connect in the near future because just four days ago we decided on the development schedule for the next few builds. Here's what we decided.

I'd like to do DNP next but for technical reasons there are three pre-requisites that have to be done first. Here's the schedule for the next couple of weeks:

1. Rewrite the underlying data structures for config info.

2. Finish "launch WoW" because DNP and choosing particular output key combinations for particular WoWs is the same code, and I can't write it unless the program can identify particular WoWs, and its method for doing that will be launch.

3. Make a spreadsheet kind of control that will be used for the DNP/key-assignment screen.

4. Write the DNP/key-assignment screen.

[Moorea]

my view of a simple straightforward dnp is that it's not tied statically to a given wow but only tied to the focused window: the window under the cursor (or last clicked if the user didn't setup follow cursor) gets everything always and all the other ones get everything except the keys mentioned in dnp - in that sense "launch wow" (step 2 above) shouldn't matter - now again I can see that there is value in having a more complex setup too but I do hope this simple use case stay simple (and dynamic as I said; the "wow" that gets or doesn't get the key change depending on where the mouse is)

but I'll take any new build with any feature in any order either way


ps: this thread should probably die off and move on to another one

[Freddie]

I look forward to a ticketing system where interested party can follow the issues they care about and the people who do not care don't necessarily have to feel obliged to comment (can "vote" it down if they want I guess) - even if the resolution is "wontfix" at least it'd be documented why etc...

The issue that came up here -- the Auto Connect stuff --- is a design recommendation. You noticed that the program required you to use a manual setting and you're recommending that the automatic feature be enhanced so the manual setting isn't needed in that particular situation.

You want to call this a "bug." That's fine. Call it anything you like. But let's be very clear on what this bug is. You're recommending that I add additional functionality to unfinished code. That's the nature of your "bug."

Recommendations of this kind are very good. I welcome them. I rely on users to design the program. I want people to recommend new features and new functionality.

But I think it would be a bad idea to track design recommendations with a bug tracking system for several reasons.

For one thing, any given design recommendation is a spectrum of possibilities. It's not a single "item." You can't "track" a spectrum of possibilities. You can only discuss it.

For another thing, it would force us to design things prematurely. I want the program's design to evolve iteratively through a process where I publish builds, people react to them and make suggestions, I publish more builds, they react again, etc.

That kind of design is open ended. We make design decisions as we go along. We don't lock ourselves in by writing down what they will be more than a litle bit in advance.

Edit:

I just realized that it would be completely absurd to track design recommendations in a bug-tracking system, because potentially, the number of design recommendations is infinite.

There's no limit to the number of recommendations that people could make.

The purpose of a bug tracking system is to drive the number of entries to zero.

But if you put design recommendations in the system, it never gets to zero. It just gets larger and larger.

[Freddie]

my view of a simple straightforward dnp is that it's not tied statically to a given wow but only tied to the focused window: the window under the cursor (or last clicked if the user didn't setup follow cursor) gets everything always and all the other ones get everything except the keys mentioned in dnp - in that sense "launch wow" (step 2 above) shouldn't matter - now again I can see that there is value in having a more complex setup too but I do hope this simple use case stay simple (and dynamic as I said; the "wow" that gets or doesn't get the key change depending on where the mouse is)

Let's keep this discussion in the thread where we're discussing it, okay?

http://www.dual-boxing.com/showthrea...677#post260677:

[Fursphere]

Freddie - the only thing missing here is a clear project scope.

"A multiboxing program" is just way to vague. To design and publish a proper scope would take hours / days / weeks / months. This is what there are project development "teams" out there in the wild.

In this fashion you can track scope creep - when new feature requests are outside the original design intent.

But since this project is ad-hoc, the users should treat it as such. Freddie drives, we can all make recommendations on where to stop next, but ultimately Freddie gets to choose how and where we all go.

I'm just happy to be along for the ride.

[Freddie]

I like the way things worked with HotkeyNet. It was based on the idea "This program is like AutoHotKey, but easier and designed for networks."

That was the whole formal specification.

Then I published builds and people made suggestions. More builds, more suggestions, round and round. We just kept doing that for two years.

It worked great, it was fun. Eventually it bogged down because the original code was written in a half assed way and it got hard to add things.

[Freddie]

I'm just happy to be along for the ride.

P.S. I'm glad you're along for the ride too.