Just a comment

[macnab]

Did the menubar.xml chamge. Now, at FG start up, it says
undefined symbol elements , joystick,nas, line 746

Add menubar.xml to your push.

EDIT: Another missing file, the widgets?

[Philosopher]

Darn it, will fix that! Sorry.

[macnab]

So easy to forget. It is a serious problem when downloading custom scenery, half the models are missing.

[Hooray]

use "git status" and "git diff origin/master" (or origin/next in the case of FG/SG)

[macnab]

Tested joystick configure.

My pedals are js[0] and my yoke is js[1]. Works correctly with the pedals when dialog opened.

The Selected joystick dropdown is not 100% opaque. (Some setting on my PC?).

Selecting the yoke from the dropdown passes the correct joystick name to the popuptip, but doesn't change anything.

EDIT: On my pedals, the rudder is axis 2. The mac and unix numbers are 2, but the windows number is 3. With both the old and the new configure GUIs, Axis 3 (actually 2) is shown as Rudder, but it is Axis 4 (actually 3) which works. This can lead to all sorts of confusion if it is not fixed. It means that you need to look at /input/joysticks/js[x]/axis[y]/number and read either mac, unix or windows, depending on the current OS.

The same with every single button as well. An absolute pain.

Don't know why no-one has ever mentioned it before.

[stuart]

Hi Guys,

I've had a look at the latest code. I really like how joylib.nas is structured now - much clearer to my eyes. Thanks.

I'm also really impressed with what you've done with Canvas for the GUI.

I spotted some issues with the dialog itself (for example I couldn't select another input device and there were some debug pop-ups), so I assume that is still under development?

What do you think the next step is here? Do you want to wait until the new GUI is complete, or look at including some joylib.nas functions in the existing XML-based Joystick Configuration dialog as a half-way house?

-Stuart

[Philosopher]

Uh yeah, sorry about that. I got distracted (almost forgot about it!). Someday of me was hoping that I could use widgets from Thomas, but that's not going to work (especially for macnab). I only have one joystick to test with, but I thought it would work with multiple. In any case, I mostly got the other things working, but the next task is the settings (need a Boolean toggle and - harder - a slider, which never appeared for some reason , though it was functional if you correctly guessed where it was).

My thoughts at this point would be to get me to work at this and wait to integrate Macnab's library into the new GUI. I wouldn't want to find myself writing the same code multiple times and the files have already diverged enough to make me think twice about we're code would go. Plus, I've basically automatized the GUI so adding in all of Macnab's extra functions would be simpler. (I added markup in between the button/axis entries and to some extent can just run through that and generate a selection dialog, though it currently only has 3 columns.)

[macnab]

There were one or two things that just couldn't be done (extra/new stuff), so I have removed that code.

I have just pushed the trimmed down version.

[TheTom]

Someday of me was hoping that I could use widgets from Thomas, but that's not going to work (especially for macnab).

Whats the problem with my widget(s)? (I know, currently its only a button^^)

[Hooray]

I think some folks here may not be able to use the latest stuff from git - IIRC, Philosopher had to use 2.8 for quite a while, he only started using git a couple of weeks ago, I assume that macnab may be similarly restricted. So I guess that's why...

[Philosopher]

Whats the problem with my widget(s)? (I know, currently its only a button^^)

Well, what you stated, and since I can't figure out how to make my own (the Nasal code... I got lost - very lost, 'specially the inheritance and classes). No drop-down .

Hey, when you do inheritance of classes, basically when possible, can you write «classeA = { parents:[classeB] }» versus doing:

Code: Select all

classeA = {
    new: func objA = { parents:[classeA,classeB] }
}

because that hides the inheritance in the constructor, besides making it just... weird . If that doesn't work, then you can also do something like this (which is what Hooray did for a Lockable class and derived "Counter" class):

Code: Select all

var classeA = classeB.new();
classeA.do_something = ...

[Hooray]

sorry, you lost me: what's the issue again ? Multiple inheritance or what ? I know you mentioned me for using a certain solution, but I am not sure I understand the problem?
Again, I don't see anything wrong with the construct you posted, and I think I used it myself in dozens of tutorials, too.

If there's a deeper issue here that I am not -consciously- aware of, which I somehow happen to work around intuitively, we should probably fix our tutorials ?

[Philosopher]

sorry, that was badly written...

In a class in Thomas' code, I really didn't get a good look, but I believe it was implementing a base class, using hash syntax versus member syntax (basically the former versus latter code snippets I posted above). The constructor was returning an object with its parents being the (implementation) and (base) classes, respectively. Again, it was only a quick look and I'm not sure if I'm getting this right. But I think the class itself could do the inheritance instead of the object, to make it clearer; basically they should use the parents vector when possible. If it is not possible, i.e. if things need to be initialized for the base class in a constructor, then using the member syntax and starting with an instance of the base class instead of an empty hash would again make things clearer. So:

Code: Select all

var BaseClass = {};
BaseClass.new = func(name)
    return { parents:[BaseClass], name:name };
BaseClass.log = func
    print(me.name,": ",string.join(arg,"")," from ",caller(2)[2],", line ",caller(2)[3]);

var Implementation = BaseClass.new("Lock");
Implementation.new = func
    return { parents:[Implementation], lock: thread.newlock() };
Implementation.lock = func {
    me.log("Trying lock");
    thread.lock(me.lock);
    me.log("Holds lock");
};

Or (slightly different usage of name, but basically same thing in the other syntax option):

Code: Select all

var BaseClass = {
    new: func(name)
        return { parents:[BaseClass], name:name },
    log: func
        print(me.name,": ",string.join(arg,"")," from ",caller(2)[2],", line ",caller(2)[3]),
};

var Implementation = {
    new = func(name)
        return { parents:[Implementation], lock: thread.newlock(), name: name },
    lock: func {
        me.log("Trying lock");
        thread.lock(me.lock);
        me.log("Holds lock");
    },
};

Anyways - Nasal doesn't really have classes

[Philosopher]

Okay, working on the dialog... macnab, I'm getting these errors at reinit:

Code: Select all

Nasal runtime error: undefined symbol: lisReinitJoyLib
  at /Users/philosopher/Documents/FlightGear/fgdata/Nasal/joylib.nas, line 1043
  called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/joylib.nas, line 142
  called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/globals.nas, line 109
Nasal runtime error: removelistener() with invalid listener id
  at /Users/philosopher/Documents/FlightGear/fgdata/Nasal/io.nas, line 343
  called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/joylib.nas, line 1042
  called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/joylib.nas, line 142
  called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/globals.nas, line 109

[macnab]

lisReinitJoyLib is created as part of initJoyLib

initJoyLib and reinitJoyLib are currently still up for discussion. Maybe don't call either at the moment until I have had better input.