Hi,
I'm not a trained programmer, so feel free to ignore me... as in "take
my advice - I wasn't using it anyway".
I think your design isn't reflecting your mental model. The table,
rather than being 34+ separate widgets, is one widget, because the
relationship of the parts of the widget to each other is critical to its
function. Breaking it down further will increase complexity because
there are considerable interdependencies between the child widgets
dependent on the appearance; Gtk's packing structure is about being able
to specify a minimum set of relative relationships and then ignore the
appearance, relying on the toolset to adjust the child widgets within
the available space.
Also, it seems to me the table is a visual "mat"; the chip appears to be
the more important widget.
If you do it with a single table widget you could conceivably have a
base class of "table", and derive from it to specify the appearance of
various subtypes of table, which would solve the different look aspect.
Ian
On 16/12/15 12:33, codekiddy wrote:
hello Ian,
I'm implementing a roulette table, each number on the table is a
custom made widget (derived from Gtk::Widget).
Top widget is a Gtk::Grid, The grid attaches child widgets, in the end
there is a grid of 3 x 12 visible child widgets. (number fields),
I'm assuming you didn't player roulette...
when you place a chip on, let's say on.. half a number, the widget
will draw one half of a chip, and its neighboring widget is signaled
to draw the other half (so that entry chip is drawn on the table )
The widget who sends a signal also sends coordinates on where to draw.
the child widgets are interconnected by signals to their neighboring
widgets.
However the table, that is their parent(Gtk::Grid) might change from
vertical to horizontal view of the table, in that case child widgets
(numbers) and their neighboring widgets are reordered and do not have
the same coordinate system any more, and x y points that were valid in
vertical view will be wrong in that horizontal view because signal
handlers of neighboring widgets are fixed to vertical table not
horizontal.
This might be better illustrated by looking at following 2 images,
(vertical numbers and horizontal numbers)
http://www.bettingcorp.com/wp-content/ups/european-roulette-table2.jpg
http://www.outsidebet.net/wp-content/uploads/even-chance-bets.jpg
So I want to change the view of the table and preserve coordinate
system of child widgets, otherwise I need to reconnect all child
widget handlers to different signals so that chips get drawn correctly.
I would like to post a code but there is a lot of it.
It could be my design is bad, so any design recommendations specific
for this case is welcome.
On Tue, Dec 15, 2015 at 10:51 PM, Ian Martin <[email protected]
<mailto:[email protected]>> wrote:
Hi,
From that description I don't understand where the x/y coordinates
you want are coming from or going to, or what they're relative
to. Are you trying to deduce the signal's location within the
widget you're clicking on, or the location of the widget clicked
on within the Gtk::Window? Or is the problem that you're
connecting a signal, but when that signal gets activated it's
passing location data that's no longer correct?
Some code might make things clearer.
Ian.
On 16/12/15 07:36, codekiddy wrote:
Hello, not sure if this is right question, but I have a case
where a top widget might reorder positions of it's child widgets
(rotate them in some fashion for 90 degrees).
However child widgets are connecting signals with each other and
these signals depend on x y coordinates of Gdk::Window for.
once the top widgets reorders it's childs their signals are wrong
since coordinate system is not the same any more, to avoid
duplicating code for each reorder of widgets with signals
connecting to different handlers I wonder is there is a way
to just rotate the Gdk::Window of child widgets in order to
preserve it's old x and y?
I see there is a Gdk::Window::move_resize() function but this
function moves the Gdk::Window, and does not provide ability to
rotate it. (I might be wrong)
any hints are welcome.
thanks.
_______________________________________________
gtkmm-list mailing list
[email protected] <mailto:[email protected]>
https://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected] <mailto:[email protected]>
https://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
