After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620454 - Auto-alignment of children of GtkFixed/GtkLayout
Auto-alignment of children of GtkFixed/GtkLayout
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: user interface
3.7.x
Other Linux
: Normal enhancement
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-03 10:06 UTC by 200224279
Modified: 2018-03-26 15:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add menu for Auto-alignment children of GtkFixed/GtkLayout (93.25 KB, patch)
2010-06-07 10:34 UTC, 200224279
none Details | Review
Auto-alignment & auto-placement children of GtkFixed/GtkLayout (97.90 KB, patch)
2010-06-12 04:31 UTC, 200224279
none Details | Review

Description 200224279 2010-06-03 10:06:02 UTC
If user selects two or more children of GtkFixed or GtkLayout container, glade will activate alignment icons in tool-bar. Once user click the icon, children will be aligned. Glade support the several alignment (left/right/top/bottom/center).
Actually, User can set the x, y value of each widget in the property editor tab.
But, it is a advanced feature.

This feature is restricted to GtkFixed and GtkLayout
Only these widgets can pack child with x, y position.
Another container widgets are placing their children based on several packing options : padding, filling, expanding, position.

What do you think about it??
Comment 1 Tristan Van Berkom 2010-06-03 15:05:26 UTC
I think it should simply work with a kind of "snap" feature.

For instance:
   a.) Add button to GtkLayout at position 152,14
   b.) Add another button next to it, say it lands at 120,15
   c.) When Dragging either of the two buttons then you need
       rules to determine whether there will be a "snap"
   d.) If there is a snap, then during the drag, the widget
       being dragged will always be aligned with its closest
       neighbor while the drag is in the "snap threshold"

So that would mean while doing a vertical drag and the neighbor
X is 15, if the "snap threshold" is 5 pixels then the drag widget
should be placed at pixel 15 for all the possible pixels from 10-20

I would think mouse velocity would be the right indicator that a snap is
undesired, but that would need testing ofcourse. If the mouse is moving
very slowly one would think the user is trying to avoid snapping onto
the alignment of its neighbor.

By the way, why would you say modifying the x/y coordinates is an advanced
feature ?
Comment 2 200224279 2010-06-07 10:34:27 UTC
Created attachment 162918 [details] [review]
Add menu for Auto-alignment children of GtkFixed/GtkLayout
Comment 3 200224279 2010-06-07 10:35:24 UTC
I mean I would like to add feature "Auto-alignment of children of GtkFixed/GtkLayout".

1) Add left/right/top/bottom alignment menu in toolbar of GladeWindow
2) User selects several children of GtkLayout/GtkFixed
3) Click the one of the toolbar menu
4) Children's x or y position is changed.

I attached my patch for it.
Please check it.
Comment 4 200224279 2010-06-12 04:27:40 UTC
(In reply to comment #1)
> I think it should simply work with a kind of "snap" feature.
> For instance:
>    a.) Add button to GtkLayout at position 152,14
>    b.) Add another button next to it, say it lands at 120,15
>    c.) When Dragging either of the two buttons then you need
>        rules to determine whether there will be a "snap"
>    d.) If there is a snap, then during the drag, the widget
>        being dragged will always be aligned with its closest
>        neighbor while the drag is in the "snap threshold"
> So that would mean while doing a vertical drag and the neighbor
> X is 15, if the "snap threshold" is 5 pixels then the drag widget
> should be placed at pixel 15 for all the possible pixels from 10-20
> I would think mouse velocity would be the right indicator that a snap is
> undesired, but that would need testing ofcourse. If the mouse is moving
> very slowly one would think the user is trying to avoid snapping onto
> the alignment of its neighbor.
> By the way, why would you say modifying the x/y coordinates is an advanced
> feature ?

I attached my patch for auto-alignment and auto-placement children of GtkLayout/GtkFixed.
Please find the patch and check.
If there is any critical issue, let me know.

Thanks
Comment 5 200224279 2010-06-12 04:31:12 UTC
Created attachment 163448 [details] [review]
Auto-alignment & auto-placement children of GtkFixed/GtkLayout

Attach my new patch.
Using this, 
user can auto-placement child of GtkFixed/GtkLayout 
- Vertical Center Placement
- Horizontal Center Placement

and auto-alignemnt children of GtkFixed/GtkLayout
- Left/Vertical Center/Right Placement
- Top/Horizontal Center/Bottom Placement
Comment 6 Tristan Van Berkom 2010-06-12 04:47:28 UTC
The attached file is not a patch so its hard to tell what it does
without manually diffing it with the source myself.

First off, I'm not sure the approach is nice - modern tools provide
visual hints inside the layout while positioning (i.e. grid lines show up
when dragging a widget across an aligned region, widgets generally slide
along an automated grid-line until a user-friendly threshold is crossed,
at least I've seen this functionality in adobe and osx tools...).

Another more general approach (that we have a years old bug filed for) is
to modify properties of multiple widgets in a single pass, that is
allow some properties to show up in the editor while multiple widgets
are selected - this would allow us to set 'x' of all selected widgets
relative to the primary selection (or set all text label foregrounds 'blue'
in one pass).

So I'm not convinced that adding a toolbar button for the special
case of sync'ing the x/y positions of selected children during a drag
(is that what you propose ? not sure I get it) would really be a desirable
solution - as you can see proceeding in this way will leave us with lots
of menu-items and toolbar buttons in the future but not much of a usable
Glade.

However, if a special case menu-item/toolbar action were to be defined
for the GtkLayout/GtkFixed widgets (if we were to agree on including
a relevant one in the UI that is), the place to do it would be in the
GTK+ plugin (plugins/gtk+/gtk+.xml.in, plugins/gtk+/glade-gtk.c).
Comment 7 Tristan Van Berkom 2010-06-12 04:49:02 UTC
Note if you want to play with adding special actions to 
widgets and their children, see the 'actions' section in
the docs for the plugin:
  http://library.gnome.org/devel/gladeui/3.6/widgetclasses.html
Comment 8 200224279 2010-06-21 10:53:52 UTC
If you build the glade using my patch. You can follow the below step.

1. Add GtkWindow
2. Add GtkFixed on GtkWindow.
3. Add GtkButton on GtkFixed.
4. Add GtkToolButton on GtkFixed (different x/y position with GtkButton).
5. Select GtkButton and GtkToolButton.
6. Several toolbar item will be activated.
7. If you select the "Left Alignment", the x position of GtkButton and GtkToolButton will be same.
8. If you select the "Vertical Center Placement", the x position of GtkButton and GtkToolButton will be same as the center of GtkFixed.


At first time, I'd considered using "action" tag of GtkFixed in catalog for toolbar. In that case, if I add "action" of GtkFixed/GtkLayout in catalog, it will be activated when user selects the gtkfixed or gtklayout.
But, these "actions" should be enabled the children of gtkfixed/gtklayout are selected. Is it possible using "action" tag??

And as you said, when user try to add widget if the guide line is shown, it's very good.
Comment 9 GNOME Infrastructure Team 2018-03-26 15:14:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/64.