fxruby-enhancement 0.1.0 → 0.2.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.semver +1 -1
- data/Gemfile +5 -4
- data/Gemfile.lock +8 -7
- data/README.org +492 -13
- data/build/scrape-rdoc.rb +288 -0
- data/examples/bounce.rb +4 -2
- data/examples/data_target.rb +0 -0
- data/examples/debug +10 -0
- data/examples/dialog_box.rb +0 -0
- data/examples/hello.rb +0 -0
- data/examples/images/bounce.rb.png +0 -0
- data/examples/images/data_target.rb.png +0 -0
- data/examples/images/dialog_box.rb.png +0 -0
- data/examples/images/hello-world-new-and-old.png +0 -0
- data/examples/images/hello.rb.png +0 -0
- data/examples/images/rubyneat-panel.png +0 -0
- data/examples/images/scribble.rb.png +0 -0
- data/examples/scribble.rb +175 -0
- data/fxruby-enhancement.gemspec +21 -3
- data/lib/fxruby-enhancement.rb +4 -1
- data/lib/fxruby-enhancement/api-mapper.rb +4967 -3793
- data/lib/fxruby-enhancement/api-mapper.rb.erb +17 -12
- data/lib/fxruby-enhancement/color-mapper.rb +1103 -0
- data/lib/fxruby-enhancement/color-mapper.rb.erb +23 -0
- data/lib/fxruby-enhancement/enhancement.rb +41 -2
- data/lib/fxruby-enhancement/ostruct-monkey.rb +18 -3
- data/lib/fxruby-enhancement/rgb-monkey.rb +54 -0
- data/lib/fxruby-enhancement/xtras.rb +1 -0
- data/lib/fxruby-enhancement/xtras/charting-boxes.rb +247 -0
- data/lib/fxruby-enhancement/xtras/charting.rb +336 -0
- metadata +31 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: cfd73446a24b417b0c41b762e70cb6c815da4e6a
|
4
|
+
data.tar.gz: f90abfe19864abba1041a367b2b2e55c9aa6f7f4
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 5b5a377b7ccec9ccc3a85709945f26d5bdae3695b5b7a7248d0d3523308de7e33b4487729178f5032fcf9c67b12ec5ee6df82c9e643e04358d9d4dacc57fee7c
|
7
|
+
data.tar.gz: 21d5d97c3b5b7af4c6ab9a453702efe1f38a685685861b568373b89284f2fb5f60920e83a93e09597f5b714a6465d498c1d29e0da083899f793f48add70a506f
|
data/.semver
CHANGED
data/Gemfile
CHANGED
@@ -1,10 +1,11 @@
|
|
1
1
|
source "https://rubygems.org"
|
2
2
|
|
3
|
-
gem "semver2",
|
4
|
-
gem "fxruby",
|
3
|
+
gem "semver2", "~> 3"
|
4
|
+
gem "fxruby", "~> 1.6"
|
5
5
|
gem "awesome_print", ">= 1"
|
6
|
-
gem "json",
|
7
|
-
gem "queue_ding",
|
6
|
+
gem "json", "~> 2.0", ">= 2.0.2"
|
7
|
+
gem "queue_ding", "~> 0"
|
8
|
+
gem "rgb", "~> 0"
|
8
9
|
|
9
10
|
group :development do
|
10
11
|
gem "rspec", "~> 3"
|
data/Gemfile.lock
CHANGED
@@ -16,8 +16,8 @@ GEM
|
|
16
16
|
docile (1.1.5)
|
17
17
|
faraday (0.9.2)
|
18
18
|
multipart-post (>= 1.2, < 3)
|
19
|
-
fxruby (1.6.
|
20
|
-
|
19
|
+
fxruby (1.6.35)
|
20
|
+
mini_portile2 (~> 2.1)
|
21
21
|
git (1.3.0)
|
22
22
|
github_api (0.14.5)
|
23
23
|
addressable (~> 2.4.0)
|
@@ -25,11 +25,11 @@ GEM
|
|
25
25
|
faraday (~> 0.8, < 0.10)
|
26
26
|
hashie (>= 3.4)
|
27
27
|
oauth2 (~> 1.0)
|
28
|
-
hashie (3.
|
28
|
+
hashie (3.5.3)
|
29
29
|
highline (1.7.8)
|
30
30
|
interception (0.5)
|
31
31
|
json (2.0.3)
|
32
|
-
juwelier (2.3.
|
32
|
+
juwelier (2.3.5)
|
33
33
|
builder
|
34
34
|
bundler (>= 1.13)
|
35
35
|
git (>= 1.2.5)
|
@@ -42,7 +42,6 @@ GEM
|
|
42
42
|
semver2
|
43
43
|
jwt (1.5.6)
|
44
44
|
method_source (0.8.2)
|
45
|
-
mini_portile (0.6.2)
|
46
45
|
mini_portile2 (2.1.0)
|
47
46
|
multi_json (1.12.1)
|
48
47
|
multi_xml (0.6.0)
|
@@ -68,7 +67,7 @@ GEM
|
|
68
67
|
pry-remote (0.1.8)
|
69
68
|
pry (~> 0.9)
|
70
69
|
slop (~> 3.0)
|
71
|
-
pry-rescue (1.4.
|
70
|
+
pry-rescue (1.4.5)
|
72
71
|
interception (>= 0.5)
|
73
72
|
pry
|
74
73
|
pry-stack_explorer (0.4.9.2)
|
@@ -82,6 +81,7 @@ GEM
|
|
82
81
|
rack (2.0.1)
|
83
82
|
rake (12.0.0)
|
84
83
|
rdoc (5.0.0)
|
84
|
+
rgb (0.1.0)
|
85
85
|
rspec (3.5.0)
|
86
86
|
rspec-core (~> 3.5.0)
|
87
87
|
rspec-expectations (~> 3.5.0)
|
@@ -96,7 +96,7 @@ GEM
|
|
96
96
|
rspec-support (~> 3.5.0)
|
97
97
|
rspec-support (3.5.0)
|
98
98
|
semver2 (3.4.2)
|
99
|
-
simplecov (0.
|
99
|
+
simplecov (0.13.0)
|
100
100
|
docile (~> 1.1.0)
|
101
101
|
json (>= 1.8, < 3)
|
102
102
|
simplecov-html (~> 0.10.0)
|
@@ -122,6 +122,7 @@ DEPENDENCIES
|
|
122
122
|
pry-stack_explorer
|
123
123
|
queue_ding (~> 0)
|
124
124
|
rdoc (~> 5)
|
125
|
+
rgb (~> 0)
|
125
126
|
rspec (~> 3)
|
126
127
|
semver2 (~> 3)
|
127
128
|
simplecov
|
data/README.org
CHANGED
@@ -1,10 +1,12 @@
|
|
1
1
|
#+OPTIONS: broken-links:mark
|
2
2
|
* FXRuby Enhancement Table of Contents :TOC_5_gh:
|
3
3
|
- [[#fxruby-enhancement][fxruby-enhancement]]
|
4
|
+
- [[#showcase][Showcase]]
|
4
5
|
- [[#introduction][Introduction]]
|
5
6
|
- [[#installation][Installation]]
|
6
7
|
- [[#documentation][Documentation]]
|
7
8
|
- [[#in-general][In General]]
|
9
|
+
- [[#the-use-of--vs-doend-to-define-your-blocks][The use of {...} vs do...end to define your blocks]]
|
8
10
|
- [[#execution-phases-of-fxruby-enhancement][Execution Phases of fxruby-enhancement]]
|
9
11
|
- [[#declarative][Declarative]]
|
10
12
|
- [[#fxruby-instantiation][FXRuby Instantiation]]
|
@@ -16,9 +18,13 @@
|
|
16
18
|
- [[#reusable-components-and-dynamic-creation-and-the-reuse-flag][Reusable components and dynamic creation, and the 'reuse' flag]]
|
17
19
|
- [[#api--dsl][API & DSL]]
|
18
20
|
- [[#ref-refc-and-tagging-your-objects][ref(), refc() and tagging your objects]]
|
21
|
+
- [[#as----adding-new-child-components-to-already-declared-ones][as -- adding new child components to already declared ones]]
|
19
22
|
- [[#fox_component-and-fox_instance][fox_component and fox_instance]]
|
20
23
|
- [[#fx_app][fx_app]]
|
24
|
+
- [[#fx_chart----not-implemented-yet-still-in-development][fx_chart -- NOT IMPLEMENTED YET! STILL IN DEVELOPMENT!]]
|
25
|
+
- [[#data-format-and-labeling----not-implemented-yet][Data Format and Labeling -- NOT IMPLEMENTED YET!]]
|
21
26
|
- [[#fx_data_target][fx_data_target]]
|
27
|
+
- [[#fx_dc][fx_dc]]
|
22
28
|
- [[#instance][instance]]
|
23
29
|
- [[#ingress_handler][ingress_handler]]
|
24
30
|
- [[#starten-and-stoppen-with-resuable-components][#starten and #stoppen with resuable components]]
|
@@ -39,8 +45,29 @@
|
|
39
45
|
- [[#junkyard-genesis-of-the-meta-meta-programming-whereby-brain-goes-boom][JUNKYARD Genesis of the meta-meta programming, whereby brain goes boom]]
|
40
46
|
- [[#junkyard-resuable-components-and-data-targets][JUNKYARD Resuable components and data targets]]
|
41
47
|
- [[#junkyard-data-targets][JUNKYARD Data Targets]]
|
48
|
+
- [[#junkyard-subtle-ruby-bug-detected-chartrb-ruby-240][JUNKYARD Subtle Ruby Bug detected. (chart.rb) Ruby 2.4.0]]
|
49
|
+
- [[#junkyard-as-execution-issue-debugging-code][JUNKYARD 'as' execution issue DEBUGGING CODE]]
|
50
|
+
- [[#scratchpad-fxdcwindow][SCRATCHPAD FXDCWindow]]
|
51
|
+
- [[#junkyard-thoughs-on-doing-the-layout][JUNKYARD Thoughs on doing the layout]]
|
52
|
+
- [[#junkyard-superior-layout-calculations][JUNKYARD Superior layout calculations]]
|
53
|
+
- [[#junkyard-debug-layout-dump][JUNKYARD Debug layout dump]]
|
42
54
|
|
43
55
|
* fxruby-enhancement
|
56
|
+
#+caption: Enhancement vs. FXRuby versions of Hello World.
|
57
|
+
#+name: fig:hello-world
|
58
|
+
[[./examples/images/hello-world-new-and-old.png]]
|
59
|
+
- On the left: Enhancement version of hello world.
|
60
|
+
- On the right: FXRuby version.
|
61
|
+
** Showcase
|
62
|
+
| Screenshot | Code Links |
|
63
|
+
|--------------------------------------+----------------|
|
64
|
+
| [[./examples/images/hello.rb.png]] | [[file:./examples/hello.rb][Hello World]] |
|
65
|
+
| [[./examples/images/dialog_box.rb.png]] | [[file:,/examples/dialog_box.rb][Dialog Box]] |
|
66
|
+
| [[./examples/images/bounce.rb.png]] | [[file:./examples/bounce.rb][Bounce]] |
|
67
|
+
| [[./examples/images/scribble.rb.png]] | [[file:./examples/scribble.rb][Scribble]] |
|
68
|
+
| [[./examples/images/chart.rb.png]] | [[file:./examples/chart.rb][Chart]] |
|
69
|
+
| [[./examples/images/rubyneat-panel.png]] | [[https://github.com/flajann2/rubyneat-panel/tree/master/lib/rubyneat-panel][RubyNEAT Panel]] |
|
70
|
+
|
44
71
|
** Introduction
|
45
72
|
The fxruby library is an excellent wrapper for the FOX Toolkit.
|
46
73
|
However, it reflects the C++-ness of FOX, rather than being more
|
@@ -72,7 +99,9 @@
|
|
72
99
|
issues on GitHub. I have not anticipated all the ways someone might try
|
73
100
|
to use Enhancement. I am making heavy use of Enhancement in my RubyNEAT
|
74
101
|
project -- which is why I created it.
|
75
|
-
|
102
|
+
|
103
|
+
[[https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=4AZLVF9WH9J3C&lc=US&item_name=FXRuby%20Enhancement&item_number=enhancement¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted][Donations are appreciated.]]
|
104
|
+
|
76
105
|
** Installation
|
77
106
|
To install the gem from commandline:
|
78
107
|
|
@@ -144,6 +173,44 @@
|
|
144
173
|
So when the actual FXImage object is instantiated, it is associated to
|
145
174
|
the :back_buffer tag, which then is found by ref() and can be used
|
146
175
|
anywhere in the instantiation phase.
|
176
|
+
**** The use of {...} vs do...end to define your blocks
|
177
|
+
This is something to be aware of, depending on
|
178
|
+
how you'd like to style your code for Enhancement.
|
179
|
+
I prefer the use of the braces {}, but others
|
180
|
+
might prefer the use of do...end.
|
181
|
+
|
182
|
+
Even though Ehnancement is a bit "opionated", I don't
|
183
|
+
wish to impose a coding style on you. But I do wish
|
184
|
+
to alert you to the subtle difference in syntax
|
185
|
+
that Ruby expects.
|
186
|
+
|
187
|
+
If you use the braces, you must enclose the
|
188
|
+
parameters to the directive in parens (). If
|
189
|
+
you use do...end, you have no such requirement.
|
190
|
+
for example, to use do...end:
|
191
|
+
#+begin_src ruby
|
192
|
+
fx_app :app do
|
193
|
+
...
|
194
|
+
end
|
195
|
+
#+end_src
|
196
|
+
|
197
|
+
is perfectly OK, whereas:
|
198
|
+
#+begin_src ruby
|
199
|
+
fx_app :app {
|
200
|
+
...
|
201
|
+
}
|
202
|
+
#+end_src
|
203
|
+
|
204
|
+
would generate a syntax error. You must, in this case:
|
205
|
+
#+begin_src ruby
|
206
|
+
fx_app (:app) {
|
207
|
+
...
|
208
|
+
}
|
209
|
+
#+end_src
|
210
|
+
|
211
|
+
And that won't get your hands slapped by the Ruby
|
212
|
+
parser.
|
213
|
+
|
147
214
|
*** Execution Phases of fxruby-enhancement
|
148
215
|
This represents the work flow, in the order stated:
|
149
216
|
| State | Description |
|
@@ -331,6 +398,37 @@
|
|
331
398
|
this is frowned upon because it might conflict with Enhancement.
|
332
399
|
If you have a need for this, please do a issue in GitHub.
|
333
400
|
|
401
|
+
**** as -- adding new child components to already declared ones
|
402
|
+
The 'as' clause allow you to shift context back
|
403
|
+
to a previously defined component, so that you
|
404
|
+
can factor your code in a way to promote
|
405
|
+
encapsulation.
|
406
|
+
|
407
|
+
This is especially useful in large projects
|
408
|
+
where you are making heavy use of binding.fx
|
409
|
+
to modularize your GUI layout. It helps
|
410
|
+
you keep everything related in one place.
|
411
|
+
|
412
|
+
For example, deep within a
|
413
|
+
window definition, you made need to define
|
414
|
+
an image to be used by a widget. However,
|
415
|
+
the image needs to be defined in the fx_app
|
416
|
+
context, taking it far away from where
|
417
|
+
it is actially needed. Here's an example of how
|
418
|
+
you would do that:
|
419
|
+
#+begin_src ruby
|
420
|
+
fx_main_window(:bounce_window) {
|
421
|
+
title "Bounce Demo"
|
422
|
+
...
|
423
|
+
as (:app) {
|
424
|
+
fx_image(:back_buffer) { opts IMAGE_KEEP }
|
425
|
+
}
|
426
|
+
...
|
427
|
+
#+end_src
|
428
|
+
|
429
|
+
As you can see, your components will need to be tagged
|
430
|
+
to be referenced by 'as'.
|
431
|
+
|
334
432
|
**** fox_component and fox_instance
|
335
433
|
fox_component and fox_instance are roughly the
|
336
434
|
equivalent of refc() and ref(), respecively. The
|
@@ -376,6 +474,77 @@
|
|
376
474
|
Typeically you'd do this inside of a module, but you could do it also
|
377
475
|
in a class body. Please see the examples.
|
378
476
|
|
477
|
+
**** TODO fx_chart -- NOT IMPLEMENTED YET! STILL IN DEVELOPMENT!
|
478
|
+
- NOTE WELL: fx_chart is still under development, and
|
479
|
+
has not been released yet for general usage. The
|
480
|
+
documentation in this section will change, I promise,
|
481
|
+
so please be aware of that. I am open to your suggestions
|
482
|
+
and input diring development, so feel free to raise
|
483
|
+
issues.
|
484
|
+
|
485
|
+
fx_chart is a custom widget supplied by Enhancement,
|
486
|
+
and provides very simple charting abilities. We have mainly created
|
487
|
+
this with the needs of RubyNEAT in mind, but hopefully we will
|
488
|
+
eventually grow the scope of what fx_chart can do.
|
489
|
+
|
490
|
+
Initally, we provide basic x-y Cartesian charting suitable for
|
491
|
+
representing time series, etc.
|
492
|
+
***** Data Format and Labeling -- NOT IMPLEMENTED YET!
|
493
|
+
Data is in the format of an array of vectors,
|
494
|
+
with each update adding a new vector to the array. For example:
|
495
|
+
#+begin_src ruby
|
496
|
+
[
|
497
|
+
[1, 22.1, 34.2, 11],
|
498
|
+
[2, 23.4, 25.0, 14],
|
499
|
+
[3, 25.2, 35.2, 12],
|
500
|
+
[4, 21.9, 63.3, 11],
|
501
|
+
[5, 11.4, 50.1, 20],
|
502
|
+
]
|
503
|
+
#+end_src
|
504
|
+
|
505
|
+
Even though the "vectors" are themselves arrays, we shall refer
|
506
|
+
to them as such for the sake of this discussion.
|
507
|
+
|
508
|
+
You may specify the first entry in the vector as the range,
|
509
|
+
in which case it will be used to plot the rest of the vector
|
510
|
+
as the "range" on the chart.
|
511
|
+
****** Labeling Series Data -- NOT IMPLEMENTED YET!!!
|
512
|
+
Each entry in the vectors must have some sort of
|
513
|
+
designation to describe how the chart will display them.
|
514
|
+
So we represent this as an association of labels, and each
|
515
|
+
label will define how the data from that position in the
|
516
|
+
vector will be drawn and labeled. For example:
|
517
|
+
#+begin_src ruby
|
518
|
+
{
|
519
|
+
0 => {
|
520
|
+
label: 'x-axis',
|
521
|
+
type: :range
|
522
|
+
},
|
523
|
+
1 => {
|
524
|
+
label: 'Germany',
|
525
|
+
type: :data,
|
526
|
+
color: :yellow,
|
527
|
+
thickness: 3
|
528
|
+
},
|
529
|
+
2 => {
|
530
|
+
label: 'Poland',
|
531
|
+
type: :data,
|
532
|
+
color: :blue,
|
533
|
+
thickness: 1
|
534
|
+
},
|
535
|
+
3 => {
|
536
|
+
label: 'Östereich',
|
537
|
+
type: :data,
|
538
|
+
color: :green,
|
539
|
+
thickness: 2
|
540
|
+
},
|
541
|
+
}
|
542
|
+
#+end_src
|
543
|
+
|
544
|
+
Specifying the position of the vector as keys in the hash
|
545
|
+
will allow us to "leave gaps" in the specification, particulary
|
546
|
+
when the number of entries in that vector become large.
|
547
|
+
|
379
548
|
**** fx_data_target
|
380
549
|
FOX (and therefor FXRuby) supports data synchronization among components.
|
381
550
|
fx_data_target encapsulates the FXDataTarget class, just like all the
|
@@ -407,6 +576,33 @@
|
|
407
576
|
Otherwise, you can deal with fx_data_target as expected. See
|
408
577
|
the [[#datatarget-example][DataTarget Example]].
|
409
578
|
|
579
|
+
**** fx_dc
|
580
|
+
For canvas work, you typically have to create and
|
581
|
+
destory the FXDCWindow object. To ease this, use the
|
582
|
+
fx_dc instead. For example:
|
583
|
+
#+begin_src ruby
|
584
|
+
button.sel_command {
|
585
|
+
fx_dc :canvas do |dc|
|
586
|
+
dc.foreground = ref(:canvas).backColor
|
587
|
+
dc.fillRectangle(0, 0, ref(:canvas).width, ref(:canvas).height)
|
588
|
+
@dirty = false
|
589
|
+
end
|
590
|
+
}
|
591
|
+
#+end_src
|
592
|
+
|
593
|
+
instead of:
|
594
|
+
#+begin_src ruby
|
595
|
+
button.sel_command {
|
596
|
+
FXDCWindow.new(ref(:canvas)) do |dc|
|
597
|
+
dc.foreground = ref(:canvas).backColor
|
598
|
+
dc.fillRectangle(0, 0, ref(:canvas).width, ref(:canvas).height)
|
599
|
+
@dirty = false
|
600
|
+
end
|
601
|
+
}
|
602
|
+
#+end_src
|
603
|
+
|
604
|
+
This example has been borrowed from [[file:./examples/scribble.rb][Scribble]].
|
605
|
+
|
410
606
|
**** instance
|
411
607
|
Inside of your component declaration, you will undoubtly
|
412
608
|
want to specify what you want to do once the FXRuby object
|
@@ -518,7 +714,9 @@
|
|
518
714
|
FOX component, not within the FXRuby object itself.
|
519
715
|
|
520
716
|
**** TODO deferred_setup
|
717
|
+
This feature is still under development, and is not fully implemented yet.
|
521
718
|
**** TODO Mapping between fx_* declarations and the FX* FXRuby objects
|
719
|
+
To be documented.
|
522
720
|
**** binding.fx
|
523
721
|
This is a way to split up your layouts into different .fx "modules", purely for
|
524
722
|
organizational reasons. For example,
|
@@ -1092,19 +1290,23 @@ end
|
|
1092
1290
|
#+end_src
|
1093
1291
|
|
1094
1292
|
** Release Notes
|
1095
|
-
| Version | Date | Notes
|
1096
|
-
|
1097
|
-
| 0.0
|
1098
|
-
| 0.0
|
1099
|
-
| 0.0.
|
1100
|
-
| 0.
|
1293
|
+
| Version | Date | Notes |
|
1294
|
+
|---------+------------+------------------------------------------------------------------------------------------------|
|
1295
|
+
| 0.2.0 | 2017-02-16 | Releasing xtras without charting, which is still in progress. Many bug fixes and enhancements. |
|
1296
|
+
| 0.1.0 | 2017-01-18 | special handling for fx_data_target and resuable components |
|
1297
|
+
| 0.0.3 | 2017-01-15 | Needed to require fox16/colors for FXColor to be loaded |
|
1298
|
+
| 0.0.4 | 2017-01-16 | ingress_handler now handles multiple tags. |
|
1299
|
+
| 0.0.2 | 2017-01-11 | Initial release |
|
1101
1300
|
|
1102
1301
|
** Known Issues
|
1103
|
-
| Version |
|
1104
|
-
|
1105
|
-
| 0.0
|
1106
|
-
| 0.
|
1107
|
-
| |
|
1302
|
+
| Version | Date | Issues |
|
1303
|
+
|---------+-----------------------------------------+--------------------------------------------------------------------------|
|
1304
|
+
| 0.2.0 | Shudown of a window, dialog box example | Seems to pop the same window to the middle of the screen first. |
|
1305
|
+
| 0.2.0 | Subtle Ruby Bug | There are TODO notes in chart.rb, and there is something in The Junkyard |
|
1306
|
+
| | | Bug moved into bug/ruby240 branch. Workaround now in place here. |
|
1307
|
+
| 0.1.0 | Trump Inaguration Day, | deferred_setup not fully implemented, and may go away. |
|
1308
|
+
| | 2017-01-20 | compose is not really needed, and is not fully implemented anyway. |
|
1309
|
+
| 0.0.2 | 2017-01-11 | Not enough example code!!! Need more documentation!!! |
|
1108
1310
|
|
1109
1311
|
** Contributing to fxruby-enhancement
|
1110
1312
|
|
@@ -1159,7 +1361,6 @@ end
|
|
1159
1361
|
<% end %>
|
1160
1362
|
#+end_src
|
1161
1363
|
|
1162
|
-
|
1163
1364
|
*** JUNKYARD Resuable components and data targets
|
1164
1365
|
We have an issue with needing to have reusable components
|
1165
1366
|
(dialog boxes, say), and ṕroperly handling data targets designations.
|
@@ -1176,3 +1377,281 @@ end
|
|
1176
1377
|
rather than the object itself. So now you simply use refc()
|
1177
1378
|
in those cases.
|
1178
1379
|
|
1380
|
+
*** JUNKYARD Subtle Ruby Bug detected. (chart.rb) Ruby 2.4.0
|
1381
|
+
This bug is a bit difficult to describe, but want to capture it here. It
|
1382
|
+
has to do with my "pushing the limits" of Ruby's metaprogramming features.
|
1383
|
+
#+begin_src ruby
|
1384
|
+
module Fox
|
1385
|
+
module Enhancement
|
1386
|
+
module Mapper
|
1387
|
+
def fx_chart name = nil, ii: 0, pos: Enhancement.stack.last, reuse: nil, &block
|
1388
|
+
Enhancement.stack << (@os = os =
|
1389
|
+
OpenStruct.new(klass: FXCanvas,
|
1390
|
+
op: [],
|
1391
|
+
ii: ii,
|
1392
|
+
fx: nil,
|
1393
|
+
kinder: [],
|
1394
|
+
inst: nil,
|
1395
|
+
instance_result: nil,
|
1396
|
+
reusable: reuse,
|
1397
|
+
type: :cartesian,
|
1398
|
+
axial: OpenStruct.new, #TODO: name changed to protect the innocent
|
1399
|
+
background: OpenStruct.new))
|
1400
|
+
Enhancement.components[name] = os unless name.nil?
|
1401
|
+
unless pos.nil?
|
1402
|
+
pos.kinder << os
|
1403
|
+
else
|
1404
|
+
Enhancement.base = os
|
1405
|
+
end
|
1406
|
+
|
1407
|
+
@os.op[0] = OpenStruct.new(:parent => :required,
|
1408
|
+
:target => nil,
|
1409
|
+
:selector => 0,
|
1410
|
+
:opts => FRAME_NORMAL,
|
1411
|
+
:x => 0,
|
1412
|
+
:y => 0,
|
1413
|
+
:width => 0,
|
1414
|
+
:height => 0)
|
1415
|
+
|
1416
|
+
# Initializers for the underlying
|
1417
|
+
def target var; @os.op[@os.ii].target = var; end
|
1418
|
+
def selector var; @os.op[@os.ii].selector = var; end
|
1419
|
+
def opts var; @os.op[@os.ii].opts = var; end
|
1420
|
+
def x var; @os.op[@os.ii].x = var; end
|
1421
|
+
def y var; @os.op[@os.ii].y = var; end
|
1422
|
+
def width var; @os.op[@os.ii].width = var; end
|
1423
|
+
def height var; @os.op[@os.ii].height = var; end
|
1424
|
+
|
1425
|
+
# Chart specific
|
1426
|
+
def type var; @os.type = var; end
|
1427
|
+
|
1428
|
+
#TODO: Subtle bug in Ruby 2.4.0 tripped over here with
|
1429
|
+
#TODO: the name of this funcion being the same as the
|
1430
|
+
#TODO: initialized variable in the OS, so I had to make
|
1431
|
+
#TODO: them different, hence the "axial".
|
1432
|
+
def axis ax, **kv
|
1433
|
+
ap @os.axial[ax] = OpenStruct.new(**kv)
|
1434
|
+
end
|
1435
|
+
|
1436
|
+
def background **kv; kv.each{ |k,v| @os.background[k] = v }; end
|
1437
|
+
|
1438
|
+
# What will be executed after FXCanvas is created.
|
1439
|
+
def instance a=nil, &block
|
1440
|
+
@os.instance_name = a
|
1441
|
+
@os.instance_block ||= []
|
1442
|
+
@os.instance_block << [a, block]
|
1443
|
+
end
|
1444
|
+
|
1445
|
+
self.instance_eval &block
|
1446
|
+
|
1447
|
+
os.fx = ->(){
|
1448
|
+
FXCanvas.new(*([pos.inst] + os.op[os.ii].to_h.values[1..-1]
|
1449
|
+
.map{ |v| (v.is_a?(OpenStruct) ? v.inst : v)
|
1450
|
+
} ))
|
1451
|
+
}
|
1452
|
+
|
1453
|
+
Enhancement.stack.pop
|
1454
|
+
@os = Enhancement.stack.last
|
1455
|
+
return os
|
1456
|
+
end
|
1457
|
+
end
|
1458
|
+
end
|
1459
|
+
end
|
1460
|
+
#+end_src
|
1461
|
+
|
1462
|
+
Change "axial" to "axis" to recrystalize this bug. I suspect that the parser
|
1463
|
+
or some aspect of the intepreter is confusing the "axis" function with
|
1464
|
+
the "axis" variable on the OpenStruct object, and it has to do with the
|
1465
|
+
exact way I am doing the parameters for the axis function that trips it up.
|
1466
|
+
A similar approach with the background function works perfectly fine:
|
1467
|
+
#+begin_src ruby
|
1468
|
+
def axis ax, **kv
|
1469
|
+
ap @os.axis[ax] = OpenStruct.new(**kv)
|
1470
|
+
end
|
1471
|
+
|
1472
|
+
def background **kv; kv.each{ |k,v| @os.background[k] = v }; end
|
1473
|
+
#+end_src
|
1474
|
+
|
1475
|
+
Which results in the error of:
|
1476
|
+
#+begin_src
|
1477
|
+
ArgumentError: wrong number of arguments (given 0, expected 1)
|
1478
|
+
from /home/alveric/.rbenv/versions/2.4.0/lib/ruby/gems/2.4.0/gems/fxruby-enhancement-0.2.0/lib/fxruby-enhancement/xtras/chart.rb:46:in `axis'
|
1479
|
+
#+end_src
|
1480
|
+
|
1481
|
+
A simple workaround was to rename the variable to "axial" or anything different
|
1482
|
+
from the function "axis".
|
1483
|
+
|
1484
|
+
I need to investigate if this bug also exists in prior releases of Ruby, and
|
1485
|
+
also produce a single-file scaled down example of this bug, so it can be reported
|
1486
|
+
back to Matz.
|
1487
|
+
|
1488
|
+
Oh, the time...
|
1489
|
+
*** JUNKYARD 'as' execution issue DEBUGGING CODE
|
1490
|
+
It is critical where the 'as' clause is executed, and we
|
1491
|
+
need to alter that, because the fx_data_target instance
|
1492
|
+
is not established at the time it's needed.
|
1493
|
+
|
1494
|
+
It is thought that the execution must take place before
|
1495
|
+
kinder create_fox_components, but I need to think about this.
|
1496
|
+
It's execution time is critical to the proper flow of Enhancement.
|
1497
|
+
|
1498
|
+
The following debug code allows you to specify
|
1499
|
+
not only which files to trace, but also a line
|
1500
|
+
range. And colored to. Massively useful. Maybe should
|
1501
|
+
be a gem in its own right?
|
1502
|
+
#+begin_src ruby
|
1503
|
+
### debugging
|
1504
|
+
TRACE_FILES = %w{
|
1505
|
+
api-mapper.rb:1832-1887
|
1506
|
+
enhancement.rb
|
1507
|
+
scribble.rb
|
1508
|
+
ostruct-monkey.rb:16-29
|
1509
|
+
}
|
1510
|
+
|
1511
|
+
TFILES = TRACE_FILES.map{ |s| s.split(':').first }
|
1512
|
+
|
1513
|
+
set_trace_func proc { |event, file, line, id, binding, classname|
|
1514
|
+
base, srange = File.basename(file).split(':')
|
1515
|
+
stnum, endnum = srange.split('-') unless srange.nil?
|
1516
|
+
stnum = srange.nil? ? nil : stnum.to_i
|
1517
|
+
endnum = srange.nil? && endnum.nil? ? nil : endnum.to_i
|
1518
|
+
if TFILES.member?(base) && (srange.nil? ||
|
1519
|
+
(endnum.nil? && line == stnum) ||
|
1520
|
+
(stnum <= line && line <= endnum))
|
1521
|
+
printf "%8s \033[32m%s:%-2d\033[0m %10s \033[33m%.50s\033[0m \033[36m%.50s\033[0m\n",
|
1522
|
+
event,
|
1523
|
+
base, #green
|
1524
|
+
line, #green
|
1525
|
+
id,
|
1526
|
+
classname, #yellow
|
1527
|
+
binding.receiver #cyan
|
1528
|
+
end
|
1529
|
+
}
|
1530
|
+
### end debugging
|
1531
|
+
#+end_src
|
1532
|
+
|
1533
|
+
It is now indeed clear that the 'as' must stick its
|
1534
|
+
kinder in the kinder list of 'as'es parent component,
|
1535
|
+
NOT the referred 'as' component itself. This is conceptually
|
1536
|
+
tricky from the code point of view, BUT it is the intuitive
|
1537
|
+
assumption from the programmer's point of view. From his
|
1538
|
+
perspective, 'as' "executes" at the place he put it.
|
1539
|
+
|
1540
|
+
And so let us do the "hard" thing here to make the lives
|
1541
|
+
of our users happy. :D
|
1542
|
+
|
1543
|
+
We have solution. We simply will put the kinder parent
|
1544
|
+
in a hash with the Enhancement.stack level that
|
1545
|
+
this kinder parent as opposed to the "real" parent is to be
|
1546
|
+
used. When the owner 'as' completes, it removes that entry
|
1547
|
+
from the hash.
|
1548
|
+
|
1549
|
+
This will allow for nesting of 'as' declerations as well,
|
1550
|
+
with the intituively expected result. I do not recommend
|
1551
|
+
nesting 'as' declarations, but at the same time I do not
|
1552
|
+
wish to restrict our users from doing so. I simply cannot
|
1553
|
+
conceive of all the possible ways Enhancement will be
|
1554
|
+
leveraged.
|
1555
|
+
|
1556
|
+
*** SCRATCHPAD FXDCWindow
|
1557
|
+
Passing in a nil for the event is not the same
|
1558
|
+
as passing in nothing at all. Probably has to
|
1559
|
+
do with how the C interface is implemented or works.
|
1560
|
+
|
1561
|
+
*** JUNKYARD Thoughs on doing the layout
|
1562
|
+
As such, we have the components of the chart laid out
|
1563
|
+
as boxes linking to each other to represent their relative
|
1564
|
+
positions to each other. As such:
|
1565
|
+
|
1566
|
+
| | | Null Top -0 | | | |
|
1567
|
+
| | | Title F-1 | | | |
|
1568
|
+
| | | Top Ruler -2 | | | |
|
1569
|
+
| Null Left-0 | Left Ruler -2 | Graph F-3 | Right Ruler -2 | Legend F-1 | Null Right -0 |
|
1570
|
+
| | | Bottom Ruler -2 | | | |
|
1571
|
+
| | | Caption F-1 | | | |
|
1572
|
+
| | | Null Bottom -0 | | | |
|
1573
|
+
|
1574
|
+
And so, given the initial width and height of the
|
1575
|
+
canvas, we work to determine everything else. For
|
1576
|
+
those boxes that contain text, we know what the
|
1577
|
+
text will be, and therefore how long and tall -- minimum --
|
1578
|
+
they will need to be. And thusly we use the hints.
|
1579
|
+
|
1580
|
+
Boxes can define their margins, and therefore, coupled
|
1581
|
+
with the float factor, determine their relationship
|
1582
|
+
with their neighors. a dominance score as shown
|
1583
|
+
in the diagram above determins how the layout will
|
1584
|
+
proceed.
|
1585
|
+
|
1586
|
+
Since the chart will have the same basic layout, with
|
1587
|
+
some components enabled and disabled and like, we shall
|
1588
|
+
work our way from the outside in.
|
1589
|
+
|
1590
|
+
Some boxes, like the Rulers, will take their width
|
1591
|
+
and height based on the dominate they are connected to.
|
1592
|
+
Others, like the title and caption and legend boxes,
|
1593
|
+
are floating.
|
1594
|
+
|
1595
|
+
We have come up with the splendid idea of creating
|
1596
|
+
the "NullBox" -- basically the equivalent of having
|
1597
|
+
zero or the empty set. It will simplify the layout
|
1598
|
+
algorithm
|
1599
|
+
|
1600
|
+
The layout algorithm shall procede as follows:
|
1601
|
+
- nil out all x,y, with, and heigts of all boxes
|
1602
|
+
- set up the NullBox with the intitals
|
1603
|
+
- work from the null box to its superiors, and so on,
|
1604
|
+
setting what can be set, leaving the rest for later.
|
1605
|
+
- when you reach the most dominant box (with no
|
1606
|
+
superiors of its own), you should be able to fully
|
1607
|
+
determine its dimensions.
|
1608
|
+
- work back down the chain and fill in anything that's
|
1609
|
+
missing.
|
1610
|
+
|
1611
|
+
For the float layout:
|
1612
|
+
- We really want to keep this simple (for now), so
|
1613
|
+
its with and height is already set by the hints.
|
1614
|
+
- for the most superior, it will have no superiors, just
|
1615
|
+
subordinates only, so its dimensions will be determined
|
1616
|
+
thusly.
|
1617
|
+
|
1618
|
+
In all of this, this layout will take place everytime the application
|
1619
|
+
window is resized, so be aware of this. The computaitons shall be swift,
|
1620
|
+
just basic MDAS arithemtic. Nothing heavy-duty or fancy.
|
1621
|
+
|
1622
|
+
**** JUNKYARD Superior layout calculations
|
1623
|
+
For the superior layout, we calculate the x and height,
|
1624
|
+
or the y and width respectively, for the boxes. Floating
|
1625
|
+
status becomes critical here, for the above will only
|
1626
|
+
need to be determined thusly for the non-floating cases,
|
1627
|
+
where there is dependency on the superior's dimensions
|
1628
|
+
and position.
|
1629
|
+
**** JUNKYARD Debug layout dump
|
1630
|
+
#+begin_src
|
1631
|
+
-->PureText unresolved: comparison of NilClass with 20 failed
|
1632
|
+
-->Graph: unresolved: undefined method `-' for nil:NilClass
|
1633
|
+
left dom=0 xywh=[0,0,0,300] LRTB=[0,0,0,0]
|
1634
|
+
right dom=0 xywh=[400,0,0,300] LRTB=[0,0,0,0]
|
1635
|
+
top dom=0 xywh=[0,0,400,0] LRTB=[0,0,0,0]
|
1636
|
+
bottom dom=0 xywh=[0,300,400,0] LRTB=[0,0,0,0]
|
1637
|
+
Fox::Enhancement::Xtras::Charting::Title dom=1 xywh=[190,0,20,10] LRTB=[0,0,0,0] floater
|
1638
|
+
Fox::Enhancement::Xtras::Charting::Caption dom=1 xywh=[190,290,20,10] LRTB=[0,0,0,0] floater
|
1639
|
+
Fox::Enhancement::Xtras::Charting::Legend dom=1 xywh=[350,135,50,30] LRTB=[0,0,0,0] floater
|
1640
|
+
|
1641
|
+
Fox::Enhancement::Xtras::Charting::TopRuler dom=2 xywh=[NIL,10,20,10] LRTB=[0,0,0,0]
|
1642
|
+
Fox::Enhancement::Xtras::Charting::BottomRuler dom=2 xywh=[NIL,280,20,10] LRTB=[0,0,0,0]
|
1643
|
+
Fox::Enhancement::Xtras::Charting::LeftRuler dom=2 xywh=[0,NIL,20,10] LRTB=[0,0,0,0]
|
1644
|
+
Fox::Enhancement::Xtras::Charting::RightRuler dom=2 xywh=[330,NIL,20,10] LRTB=[0,0,0,0]
|
1645
|
+
|
1646
|
+
Fox::Enhancement::Xtras::Charting::Graph dom=3 xywh=[-20,0,350,280] LRTB=[0,0,0,0]
|
1647
|
+
Fox::Enhancement::Xtras::Charting::Graph dom=3 xywh=[-20,0,350,280] LRTB=[0,0,0,0]
|
1648
|
+
|
1649
|
+
Fox::Enhancement::Xtras::Charting::TopRuler dom=2 xywh=[-20,10,350,10] LRTB=[0,0,0,0]
|
1650
|
+
Fox::Enhancement::Xtras::Charting::BottomRuler dom=2 xywh=[-20,280,350,10] LRTB=[0,0,0,0]
|
1651
|
+
Fox::Enhancement::Xtras::Charting::LeftRuler dom=2 xywh=[0,0,20,280] LRTB=[0,0,0,0]
|
1652
|
+
Fox::Enhancement::Xtras::Charting::RightRuler dom=2 xywh=[330,0,20,280] LRTB=[0,0,0,0]
|
1653
|
+
|
1654
|
+
Fox::Enhancement::Xtras::Charting::Title dom=1 xywh=[190,0,20,10] LRTB=[0,0,0,0] floater
|
1655
|
+
Fox::Enhancement::Xtras::Charting::Caption dom=1 xywh=[190,290,20,10] LRTB=[0,0,0,0] floater
|
1656
|
+
Fox::Enhancement::Xtras::Charting::Legend dom=1 xywh=[350,135,50,30] LRTB=[0,0,0,0] floater
|
1657
|
+
#+end_src
|