Giter Club home page Giter Club logo

emeus's Introduction

Emeus - Constraint-based layout manager for GTK+

Build Status

What is Emeus?

Emeus is a constraint-based layout manager widget for GTK+, written using the Cassowary constraint solving algorithm.

What's the difference between Emeus and GTK+'s layout managers?

GTK+ has two different sorts of layout managers:

  • the boxes-inside-boxes model, represented by GtkBox and which is the preferred layout management mechanism
  • the fixed positioning and sizing model, using the GtkFixed and the GtkLayout containers

The first model works really well in ensuring that UIs are responsive to size changes, by avoiding pixel-perfect positioning on the screen, as well as ensuring that changing the font size or margins and paddings do not break the user interface; its main down side is that it requires accurate, and often verbose packing of widgets inside boxes, inside other boxes.

The second model allows a more efficient way to construct a user interface, at the major costs of either "freezing" it, or requiring constant recalculations of the relative position and size of each UI element.

Emeus provides a third layout management policy, based on constraints; each UI element binds one of more of its attributes — like its width, or its position — to other UI elements, in a way that is more natural to describe from a UI building perspective, and hopefully more efficient that stacking piles of boxes one inside another.

Constraints

EmeusLayoutConstraint is a GtkContainer that can support multiple children; each child, in turn, is associated to one or more EmeusConstraint instances. Each constraint is the expression of a simple linear equation:

item1.attr1 = item2.attr2 × multiplier + constant

Where:

  • item1 is the target widget, that is the widget we want to constraint; if unset, the target will be the layout itself
  • attr1 is an attribute of the target widget, like width or end, that we want to constraint
  • item2 is the source widget, that is the widget that provides the value of the constraint; if unset, the source will be the layout itself
  • attr2 is an attribute of the source widget that provides the value of the constraint
  • multiplier is a multiplication factor, expressed as a floating point value
  • constant is an additional constant factor, expressed as a floating point value

Using both notations, then, we can construct user interfaces like:

+-------------------------------------------+
|   [ button 1 ] [ button 2 ] [ button 3]   |
+-------------------------------------------+

By expressing the constraints between the UI elements. For instance, we can center button2 within its parent and give it a minimum width of 250 logical pixels:

button2.width >= 250
button2.centerX = parent.centerX
button2.centerY = parent.centerY

Then, we can tie button1 and button3 to button2, and ensure that the width and height of all three buttons are the same:

button1.end = button2.start - 8
button1.width = button2.width
button1.height = button2.height

button3.start = button2.end + 8
button3.width = button2.width
button3.height = button2.height

The EmeusConstraintLayout widget will attempt to resolve all the constraints, and lay out its children according to them.

Building

  • Install meson
  • Install ninja
  • Create a build directory:
  • $ mkdir _build && cd _build
  • Run meson:
  • $ meson
  • Run ninja:
  • $ ninja
  • $ ninja test
  • # ninja install

Documentation

The API reference for Emeus is available online.

Licensing

Emeus is released under the terms of the GNU Lesser General Public License, either version 2.1 or, at your option, any later version.

The Cassowary simplex solving algorithm implementation is largely inspired by the equivalent implementations written in various other language, including:

  • Cassowary — the original C++ implementation, released under the terms of the GNU Lesser General Public License, version 2.1 or later
  • Cassowary.js — JavaScript implementation, released under the terms of the Apache License, Version 2.0
  • Cassowary — Python implementation, released under the terms of the BSD 3-clause license

Additionally, the automatic layout solving is inspired by autolayout.js, a JavaScript automatic constraint-based layout, which, in turn, is based on the Apple autolayout layout manager.

You can check on the Overconstrained website for additional Cassowary implementations in various languages.

emeus's People

Contributors

danyeaw avatar ebassi avatar emerentius avatar joanafilizola avatar jpakkane avatar piotrdrag avatar ptomato avatar tchx84 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

emeus's Issues

Build VAPI

Do you plan to build a VAPI for Vala?

shrinkability issues

I have a working system of constraints that generates the expected layout, but in a small window. Now I'm adding constraints

super.width <= 1000
super.height <= 1000

and my window gets big.

I can sort-of understand that the solution with a window thats as big as allowed might be the optimum.

But why can't I shrink the window now ?

Constraints' minimum sizes are not consistent

Here's a GJS script that illustrates the bug:

const Emeus = imports.gi.Emeus;
const Gtk = imports.gi.Gtk;
Gtk.init(null);

let view = new Emeus.ConstraintLayout();
let widgets = {
    w1: new Gtk.Button({ label: "Hello" }),
    w2: new Gtk.Button({ label: "world" }),
};
view.add(widgets.w1);
view.add(widgets.w2);

let constraints = Emeus.create_constraints_from_description([
    "|-[w1(200)]-(>=0)-|",
    "|-[w2(300)]-(>=0)-|",
    "V:|-[w1]-(>=100)-[w2]",
], 15, 15, widgets, {});
constraints.forEach(view.add_constraint, view);

let win = new Gtk.Window();
win.add(view);
win.connect('destroy', Gtk.main_quit);
win.show_all();
Gtk.main();

When you run this, the initial size of the window (215x200) is big enough to take the vertical size of the layout and the horizontal size of w1 into account, but not the horizontal size of w2, which is cut off.

If you drag the window's lower right resize grip around in circles, you can get into one of two states: either (1) the window will not size smaller vertically than 200 pixels but will size horizontally down to 1 pixel wide, or (2) the window will not size smaller than 215x200 pixels. It's unclear to me how to reproducibly get into each state, but each time you restart the program and drag the resize grip around, you will get into one of the two. (Very rarely, you can even change by just frenetically dragging the resize grip without restarting the program.)

It seems to me that the minimum size should be more like 315x200 (to take w2 into account) and should be consistent no matter how many times you resize the window.

Build fails with FileNotFoundError: [Errno 2] No such file or directory: 'gtkdoc-scan'

When I build Emeus, I get the following error at sudo ninja install

[0/1] Installing files.
Installing src/libemeus-1.0.so.0.9901.0 to /usr/local/lib64/libemeus-1.0.so.0.9901.0
Installing src/Emeus-1.0.gir to /usr/local/share/gir-1.0/Emeus-1.0.gir
Installing src/Emeus-1.0.typelib to /usr/local/lib64/girepository-1.0/Emeus-1.0.typelib
Installing src/tools/emeus-gen-constraints to /usr/local/bin/emeus-gen-constraints
Installing src/tools/com.endlessm.EmeusEditor.desktop to /usr/local/share/applications/com.endlessm.EmeusEditor.desktop
Installing src/tools/emeus-edit-constraints to /usr/local/bin/emeus-edit-constraints
Installing examples/simple-grid to /usr/local/share/emeus-1.0/examples/simple-grid
Installing doc/emeus-gen-constraints.1 to /usr/local/share/man/man1/emeus-gen-constraints.1
Installing emeus-constraint.h to /usr/local/include/emeus-1.0
Installing emeus-constraint-layout.h to /usr/local/include/emeus-1.0
Installing emeus-version-macros.h to /usr/local/include/emeus-1.0
Installing emeus-types.h to /usr/local/include/emeus-1.0
Installing emeus-utils.h to /usr/local/include/emeus-1.0
Installing emeus.h to /usr/local/include/emeus-1.0
Installing /home/julian/dev/emeus/_build/src/emeus-version.h to /usr/local/include/emeus-1.0
Installing /home/julian/dev/emeus/_build/src/emeus-1.0.pc to /usr/local/lib64/pkgconfig
Installing /home/julian/dev/emeus/_build/src/tools/com.endlessm.EmeusEditor.service to /usr/local/share/dbus-1/services
Installing /home/julian/dev/emeus/src/tools/com.endlessm.EmeusEditor.png to /usr/local/share/icons/hicolor/256x256/apps
Installing /home/julian/dev/emeus/examples/simple-grid.c to /usr/local/share/emeus-1.0/examples
Installing /home/julian/dev/emeus/examples/simple-grid.js to /usr/local/share/emeus-1.0/examples
Installing /home/julian/dev/emeus/examples/centered.js to /usr/local/share/emeus-1.0/examples
Running custom install script '/usr/bin/python3 /usr/bin/meson --internal gettext install --subdir=po --localedir=share/locale --pkgname=emeus --langs=en_GB'
Installing /home/julian/dev/emeus/_build/po/en_GB.gmo to /usr/local/share/locale/en_GB/LC_MESSAGES/emeus.mo
Running custom install script '/usr/bin/python3 /usr/bin/meson --internal gtkdoc --sourcedir=/home/julian/dev/emeus --builddir=/home/julian/dev/emeus/_build --subdir=doc --headerdirs=/home/julian/dev/emeus/src --mainfile=emeus-docs.xml --modulename=emeus --mode=auto --scanargs=--rebuild-types@@--ignore-decorators=_EMEUS_PUBLIC@@--ignore-headers=emeus.h config.h emeus-constraint-layout-private.h emeus-constraint-private.h emeus-expression-private.h emeus-macros-private.h emeus-simplex-solver-private.h emeus-types-private.h emeus-utils-private.h emeus-variable-private.h emeus-version.h emeus-vfl-parser-private.h emeus-test-utils.h --gobjects-types-file=emeus.types --fixxrefargs=--html-dir=/usr/local/share/gtk-doc/html@@--extra-dir=/usr/share/gtk-doc/html/glib@@--extra-dir=/usr/share/gtk-doc/html/gobject@@--extra-dir=/usr/share/gtk-doc/html/gtk3 --cflags=-I/home/julian/dev/emeus/_build/src/. -I/home/julian/dev/emeus/src/. -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -pthread --ldflags=-L/home/julian/dev/emeus/_build/src -Wl,-rpath,/home/julian/dev/emeus/_build/src -lemeus-1.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm --cc=cc --ld=cc'
Building documentation for emeus
Traceback (most recent call last):
File "/usr/bin/meson", line 37, in
sys.exit(main())
File "/usr/bin/meson", line 34, in main
return mesonmain.run(sys.argv[1:], launcher)
File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 312, in run
sys.exit(run_script_command(args[1:]))
File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 279, in run_script_command
return cmdfunc(cmdargs)
File "/usr/lib/python3.6/site-packages/mesonbuild/scripts/gtkdochelper.py", line 218, in run
options.mode)
File "/usr/lib/python3.6/site-packages/mesonbuild/scripts/gtkdochelper.py", line 109, in build_gtkdoc
gtkdoc_run_check(scan_cmd, abs_out)
File "/usr/lib/python3.6/site-packages/mesonbuild/scripts/gtkdochelper.py", line 51, in gtkdoc_run_check
p, out = Popen_safe(cmd, cwd=cwd, stderr=subprocess.STDOUT)[0:2]
File "/usr/lib/python3.6/site-packages/mesonbuild/mesonlib.py", line 521, in Popen_safe
stderr=stderr, **kwargs)
File "/usr/lib64/python3.6/subprocess.py", line 707, in init
restore_signals, start_new_session)
File "/usr/lib64/python3.6/subprocess.py", line 1333, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'gtkdoc-scan'
Failed to run install script '/usr/bin/python3 /usr/bin/meson --internal gtkdoc --sourcedir=/home/julian/dev/emeus --builddir=/home/julian/dev/emeus/_build --subdir=doc --headerdirs=/home/julian/dev/emeus/src --mainfile=emeus-docs.xml --modulename=emeus --mode=auto --scanargs=--rebuild-types@@--ignore-decorators=_EMEUS_PUBLIC@@--ignore-headers=emeus.h config.h emeus-constraint-layout-private.h emeus-constraint-private.h emeus-expression-private.h emeus-macros-private.h emeus-simplex-solver-private.h emeus-types-private.h emeus-utils-private.h emeus-variable-private.h emeus-version.h emeus-vfl-parser-private.h emeus-test-utils.h --gobjects-types-file=emeus.types --fixxrefargs=--html-dir=/usr/local/share/gtk-doc/html@@--extra-dir=/usr/share/gtk-doc/html/glib@@--extra-dir=/usr/share/gtk-doc/html/gobject@@--extra-dir=/usr/share/gtk-doc/html/gtk3 --cflags=-I/home/julian/dev/emeus/_build/src/. -I/home/julian/dev/emeus/src/. -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -pthread --ldflags=-L/home/julian/dev/emeus/_build/src -Wl,-rpath,/home/julian/dev/emeus/_build/src -lemeus-1.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm --cc=cc --ld=cc'
FAILED: meson-install
/usr/bin/python3 /usr/bin/meson --internal install /home/julian/dev/emeus/_build/meson-private/install.dat
ninja: build stopped: subcommand failed.

Emeus Constraint Layout does not play well with nested layout inside GtkGrid

I have: EmeusConstraintLayout --> GtkGrid --> EmeusConstraintLayout

Under this setup, widgets (specifically, GtkLabels) added to the inner EmeusConstraintLayout are not arranged properly - indeed they seem to not show up at all. However, if I substitute the GtkGrid for a GtkFrame, then everything works as expected.

Minimal example: https://gist.github.com/rmacqueen/2799077115ef59cbd7e187c2fccd8c73

In this example, labels (added to inner, nested layout) will not show up at all. However, if, on line 10, you replace GtkGrid with a GtkFrame, then you get the desired result.

unclear strengths

get_layout_attribute sets up internal constraints to tie together the various attributes, but while the relations for center-x and center-y are created with required strength, right and bottom are only defined with medium strength.

Why is that ? Would be good to have a comment explaining it.

bad weak ref

When i close the simple-grid example, I get:

$ valgrind ./build/examples/simple-grid
==28422== Memcheck, a memory error detector
==28422== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==28422== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==28422== Command: ./build/examples/simple-grid
==28422==
==28422== Invalid write of size 8
==28422== at 0x62EAFE5: g_nullify_pointer (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x602C41E: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602EE5B: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x5178ABB: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x51C3C3D: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x6028650: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x603B651: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x6043D04: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x604466E: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53E05AF: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x602EE5B: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53EC958: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== Address 0x12f18d10 is 368 bytes inside a block of size 464 free'd
==28422== at 0x4C2ED18: free (vg_replace_malloc.c:530)
==28422== by 0x62BC4AD: g_free (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D44EF: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x604D2A2: g_type_free_instance (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x4E43AED: emeus_constraint_layout_forall (emeus-constraint-layout.c:854)
==28422== by 0x51C3C3D: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== by 0x4E41EC1: emeus_constraint_layout_destroy (emeus-constraint-layout.c:239)
==28422== by 0x6028650: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x603B651: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x6043D04: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x604466E: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x53E05AF: ??? (in /usr/lib64/libgtk-3.so.0.2200.24)
==28422== Block was alloc'd at
==28422== at 0x4C2DB6B: malloc (vg_replace_malloc.c:299)
==28422== by 0x62BC398: g_malloc (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D3F75: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x62D4408: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.5400.1)
==28422== by 0x604CFA0: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602DDB7: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602FC2F: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x602FFA8: g_object_new (in /usr/lib64/libgobject-2.0.so.0.5400.1)
==28422== by 0x4E46C6C: emeus_constraint_layout_child_new (emeus-constraint-layout.c:2242)
==28422== by 0x4E458C9: emeus_constraint_layout_pack (emeus-constraint-layout.c:1716)
==28422== by 0x40144A: build_grid (simple-grid.c:64)
==28422== by 0x401A7D: emeus_test_application_window_init (simple-grid.c:2

Taking out the

g_object_add_weak_pointer (G_OBJECT (layout), (gpointer*) &layout_child->solver);

in emeus_constraint_layout_pack makes this go away. I assume the children are already gone by the time the weak refs get cleaned up.

unclear unref

In the middle of simplex_solver_remove_constraint, I see:

no_columns:
if (g_hash_table_lookup (solver->rows, marker) != NULL)
simplex_solver_remove_row (solver, marker, TRUE);
else
variable_unref (marker);

But I can't find a corresponding ref that the unref would match up with.

And also, a few lines further down, I see:

      if (v != marker)
        simplex_solver_remove_column (solver, v);

Even if we had a reference, should we really be dropping it before this use of marker ?

Example not rendered in editor

With this input

H:|-[view0(view2)]-[view2]-|
H:|-[view1(view3)]-[view3]-|
H:[view4(view3)]-|
V:|-[view0(view1)]-[view1]-|
V:|-[view2(view3,view4)]-[view3]-[view4]-|

I get

image

Info

Distro: Arch Linux
Version: 1.0+5d38cc3

Segfault when adding widget to child of layout that has not been laid out yet

I have a frame as a child of a constraint layout. If I try to add a Gtk.Image to that frame, then I often (4 times out of 5) get a segfault.

Traceback from running under gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7542fe5 in g_slice_alloc () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x00007ffff7542fe5 in g_slice_alloc () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff754361e in g_slice_alloc0 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffbc553484 in variable_new (solver=0xbd4730, type=VARIABLE_DUMMY) at ../src/emeus-expression.c:71
#3  0x00007fffbc557398 in simplex_solver_new_expression (solver=0xbd4730, constraint=0x15232d0, eplus_p=0x7ffffffec5f8, eminus_p=0x7ffffffec600, 
    prev_constant_p=0x7ffffffec608) at ../src/emeus-simplex-solver.c:998
#4  0x00007fffbc558543 in simplex_solver_add_constraint_internal (solver=0xbd4730, constraint=0x15232d0) at ../src/emeus-simplex-solver.c:1466
#5  0x00007fffbc558911 in simplex_solver_add_constraint (solver=0xbd4730, variable=0x148b5c0, op=OPERATOR_TYPE_EQ, expression=0x15fca70, 
    strength=1001001000) at ../src/emeus-simplex-solver.c:1568
#6  0x00007fffbc550cd4 in create_child_constraint (layout=0xbd4700, child=0xdd9ba0, constraint=0x171d350) at ../src/emeus-constraint-layout.c:1437
#7  0x00007fffbc550de4 in add_child_constraint (layout=0xbd4700, child=0xdd9ba0, constraint=0x171d350) at ../src/emeus-constraint-layout.c:1468
#8  0x00007fffbc5513b2 in layout_add_constraint (layout=0xbd4700, constraint=0x171d350) at ../src/emeus-constraint-layout.c:1614
#9  0x00007fffbc55142f in emeus_constraint_layout_add_constraint (layout=0xbd4700, constraint=0x171d350) at ../src/emeus-constraint-layout.c:1633
#10 0x00007ffff5e9cba0 in ffi_call_unix64 () from /lib/x86_64-linux-gnu/libffi.so.6
#11 0x00007ffff5e9c608 in ffi_call () from /lib/x86_64-linux-gnu/libffi.so.6
#12 0x00007ffff72557b0 in ?? () from /lib/libgjs.so.0
#13 0x00007ffff7256c4e in ?? () from /lib/libgjs.so.0
#14 0x00007ffff48472c8 in ?? () from /lib/x86_64-linux-gnu/libmozjs-31.so.0
#15 0x00007ffff48573f1 in ?? () from /lib/x86_64-linux-gnu/libmozjs-31.so.0
#16 0x00007ffff4558cb7 in ?? () from /lib/x86_64-linux-gnu/libmozjs-31.so.0

obvious constraints

I wonder why emeus isn't adding the 'obvious'

width >=0
height >= 0

constraints for all widgets automatically.
When I tried that, it did seem to make things a bit more stable - I see fewer assertions on negative allocations with it.

misleading comment

add_layout_stays has a comment that says: /* Add two required stay constraints for the top left corner */
but looking at the code:

  1. it also creates stay constraints for width and height
  2. it creates weak constraints, not required ones

Who is right, the comment or the code ?

Constraints should take height-for-width widget sizes into account

I've been experimenting with translating some examples from Apple's autolayout code to Emeus. Here is my translation of http://commandshift.co.uk/blog/2013/01/31/visual-format-language-for-autolayout/, as a gist: https://gist.github.com/ptomato/4f43834abc431705f515985fd8b53fcf

(To run it, download the two files from the gist, fetch the picture with wget -O kitten.jpg http://placekitten.com/150/150, and run gjs kitten.js.)

If you run the example with the short label string in headline, it looks perfect:
screenshot from 2016-12-20 15-46-21

However, if you comment out the short string and uncomment the long string, the constraint layout doesn't make room for the label's height:
screenshot from 2016-12-20 15-46-33

I suspect this is because the constraint layout is only taking the label's minimum height (the height that it would be if it had infinite width) into account and not its natural height.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.