Commit graph

730 commits

Author SHA1 Message Date
1fbade3a67 Inv(#1020): find a reliable way to determine extension of the canvas
bottom line
- seems we need to do that manually
- must wait until in the on_draw() callback
- use Container::foreach() to visit all child widgets
- Layout::set_size()
2016-11-01 23:20:43 +01:00
6fd0045a65 Inv(#1020): adjust curtom drawing for scrolled viewport
this makes the custom drawing stiched to the absolute canvas,
allowing to move around with the help of the scrollbars...
2016-10-30 17:08:41 +01:00
90cc17b733 Inv(#1020): learn how to draw a simple line
here we draw a red diagnoal line behind the embedded widgets.
2016-10-30 02:55:38 +01:00
1255a4fc04 Inv(#1020): framework for custom drawing 2016-10-30 02:15:01 +01:00
ae07329ada Inv(#1020): expand some widgets by text change 2016-10-29 18:17:58 +02:00
f8d8a89220 Inv(#1020): reorganise tooltips and accelerators 2016-10-29 18:09:03 +02:00
1b9a45930b Inv(#1020): control extension of the scrollable area
this uncovers some possible problem in GTK (#1037)
2016-10-29 17:53:52 +02:00
9397f064c7 Inv(#1020): add some tooltips
...to describe the implemented experiments
2016-10-29 16:22:06 +02:00
e4bf84657c Inv(#1020): erase arbitrary child widgets 2016-10-29 16:05:37 +02:00
8348696a56 Inv(#1020): add function to align all widgets in a single row
...which allows us to verify consistency of z-order
2016-10-29 15:40:23 +02:00
03a9611608 Inv(#1020): iteration and moving of children 2016-10-29 03:26:07 +02:00
94a0adcb5b Inv(#1020): place widgets irregularily
- partially overlapping
- beyond the scrollable area
2016-10-29 00:51:28 +02:00
e7d284783b Inv(#1020): place widgets on canvas
- randomly
- partially overlapping
- event dispatch works as expected
2016-10-28 17:32:43 +02:00
5897d1ffad clean-up: unnecessary includes
they'll hamper the investigation by causing extended compilation round-trip
2016-10-28 16:54:03 +02:00
12f1165765 Inv(#1020): add code to monitor clean-up by GTK
I am still suspicious the cleanup mechanism for child widgets works as expected...
But right now, we can't verify that, since on shutdown we get an assertion failure
from ld.so "dl-close.c: 762: _dl_close: Assertion `map->l_init_called' failed!"
Seems we're loading the GUI plugin not properly
2016-10-27 23:36:20 +02:00
dd9f34e93a Inv(#1020): prepare Investigation
- define tasks to be addressed during investigation
- read documentation, identify problematic aspects
- prepare a child widget class to be placed on the canvas
2016-10-27 22:57:46 +02:00
2350998fdb setup layout for experiments (closes #1021) 2016-10-27 04:15:20 +02:00
0888e0afe7 new empty dock for research and experiments (#1020)
My intention is to use this space for experiments first,
and then as a construction site for a rewrite of the
custom timeline widget.

We really need a rewrite here, in order to be properly
aligned to the standard way of writing such a custom widget,
and also to build our first connection to the UI-Bus and then
remove the old placeholder UI model
2016-10-27 02:57:23 +02:00
3bb76f2f2c move asside old code to make room for investigation
...goal is to have a new dockable panel,
where we'll build the new timeline widget eventually.

Signed-off-by: Ichthyostega <prg@ichthyostega.de>
2016-10-26 18:44:27 +02:00
c8b6e7a699 mark some code smells (#1026) 2016-10-26 18:44:27 +02:00
2d8a595038 Finish AbstractTangible_test and the basic UI-Element protocol
closes #975 and #992
2016-10-04 03:50:44 +02:00
1725a31df1 Bugfix: insidious dangling pointer caused by move after construction
Damn sideeffect of the suppport for move-only types: since we're
moving our binding now into place /after/ construction, in some cases
the end() iterator (embedded in RangeIter) becomes invalid. Indeed this
was always broken, but didn't hurt, as long as we only used vectors.

Solution: use a dedicated init() hook, which needs to be invoked
*after* the TreeMutator has been constructed and moved into the final
location in the stack buffer.
2016-10-03 23:54:09 +02:00
ffcfa7afd4 WIP: draft a concrete TreeMutator binding for MockElm
...this is the first attempt to integrate the Diff-Framework into (mock) UI code.
Right now there is a conceptual problem with the representation of attributes;
I tend to reject idea of binding to an "attribute map"
2016-10-03 01:59:47 +02:00
c8ad698ac4 MutationMessage: limit to treating of gui::model::Tangible
the generic typing to DiffMutatble does not make much sense,
since the desired implementation within gui::ctrl::Nexus
is bound to work on Tangibles only, since that is what
the UI-Bus stores in the routing table
2016-10-02 23:51:45 +02:00
b251b9a022 MutationMessage: generic implementation based on the DiffMutable interface 2016-10-02 23:34:07 +02:00
76fc444437 MutationMessage: implementation draft 2016-10-02 22:21:17 +02:00
d2e4f826ed UI-Bus/mutation: expand on draft for mutation message 2016-10-01 23:09:08 +02:00
27ba8d5896 UI-Bus/mutation: draft idea for mutation message on UI-Bus 2016-09-30 22:23:55 +02:00
6c3024adcd UI-Bus/mutation: search for ways how to integrate Diff processing 2016-09-30 18:13:04 +02:00
d7d90bf491 Element protocol: broadcast of state reset messages unit test PASS
This basically finishes definition of the fundamental
UI-Element and Bus protocol -- with one notable exception:
how to mutate elements by diff.

This will be the next topic to address
2016-02-14 05:03:08 +01:00
5bbf08adcb implement deleting of individual property state data 2016-02-14 04:29:40 +01:00
18b6a388a0 implement state reset handlers / mock handlers 2016-02-14 03:42:10 +01:00
44bb044eee message broadcast implementation unit test PASS
...was indeed dead easy to implement
2016-02-14 02:20:51 +01:00
4da75dd4d3 bus protocol change: special handling for reset state marks
- suppres sending redundant stat mark messages from MockElm
- emit a "reset" state mark when an actual reset happens
- let the PresentationStateManager discard recorded special state
  when receiving a "reset" mark for a given element
2016-02-13 23:48:34 +01:00
d57af50ad6 state manager storage implemented and covered by unit test
sigh.
If you want to feel slick and cool,
never dare to write any unit test....
2016-02-13 22:55:59 +01:00
f80982b52b gen-node: fix insidious data conssitency problem
I assumed that, since GenNode is composed of copyable and
assignable types, the standard implementation will do.
But I overlooked the run time type check on the opaque
payload type within lib::Variant. When a type mismatch
is detected, the default implementation has already
assigned and thus altered the IDs.

So we need to roll our own implementation, and to add
insult to injury, we can't use the copy-and-swap idiom either.
2016-02-13 22:55:59 +01:00
121cd41408 ouch: GCC-4.9 doesn't yet support the C++14 transparent comparators
This is actually a STL library feature, and was added precisely
for the reason encountered here: if we want logarithmic search,
we'll have to construct a new GenNode object, just to have something
for the set to invoke the comparison operator.

C++14 introduced the convention that the Comparator of the set
may define a marker type `is_transparent` alongside with a generic
comparison operator. But, as is obvious from the source code of
our GNU Standard library implementation, our std::set has no such
overload to make use of that feature

http://en.cppreference.com/w/cpp/container/set/find
http://stackoverflow.com/questions/20317413/what-are-transparent-comparators

The only good thing is that, just 10 minutes ago, I felt like
a complete moron because I'm writing a unit test for such a simple
storage class. ;-)
2016-02-13 22:55:59 +01:00
94fc160525 implementation of storage for state manager 2016-02-13 22:55:59 +01:00
94576af4df finialise simple state manager implementation
...and rearrange storage interface to suit
2016-02-13 22:55:59 +01:00
92d9a7323f implement state manager through stubbed storage functions
...push down the frontier by one level
2016-02-13 22:55:58 +01:00
071f49027f change presentation state manager API
...based on elementIDs rather, to avoid any
tangling and trickery with reconstructing IDs
2016-02-13 22:55:58 +01:00
c54dfd6a94 factor out generic map based state manager implementation 2016-02-13 22:55:58 +01:00
15c1343fae class name rochade
it occured to me that my "mock implementation" actually
is entirely generic, so it could as well be "the" implementation
2016-02-13 22:55:58 +01:00
49a42b4d50 add outline of corresponding storage implementation 2016-02-13 22:55:58 +01:00
ef04ebfb17 add skeleton of a mock implementation within test::Nexus 2016-02-13 22:55:58 +01:00
f58b2af228 stub new parts 2016-02-13 22:55:58 +01:00
26d0f50e47 state mark handling within the base element: unit test PASS
...and I made the decision *not* to consider any kind of
generic properties for now. YAGNI.

UI coding is notorious spaghetti code.
No point in fighting that, it is just the way it is,
because somewhere you're bound to get concrete, hands-on.
2016-02-13 22:55:58 +01:00
0964e56c49 better use a named magic constant
right now, what we actually need here is just some integer,
so the GenNode payload is typed to int (or just to anything
different than a Record, because the Record signals that
we intend to bind, not to invoke the command)
2016-02-13 22:55:57 +01:00
fea6628b3c WIP some notes what could be addressed next 2016-02-13 22:55:57 +01:00
44785859ea convenience shortcut to simplify command invocation via Bus 2016-02-13 22:55:57 +01:00