GNOME.org
 

Re: Rotate Gdk::Window

thank you for reply.

I was thinking about single "table" widget already, such as canvas or drawing area, but then new problems arise such as motion effects of single table fields.
things go easy with multiple widgets and letting them respond separately.
But obviously the limitation is a rotation, meaning code duplication to some extent is imminent.

thanks a lot for response!

On Wed, Dec 16, 2015 at 3:22 AM, Ian Martin <martin_id vodafone co nz> wrote:
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)

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 <martin_id vodafone co nz> 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
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]