[Glade-users] [Glade-devel] Making property editor as big as posible!

On Mon, Mar 11, 2013 at 9:58 PM, Igor Chetverovod <chetverovod at gmail.com> wrote:
Hi Tristan,
About a bit another thing:)

I think it  would be great  if property editor could have possibility
to add new properties to the widget and GObject  functions
g_object_set_data () / g_object_get_data () could be used for access
to those properties.

Yes, we've discussed that more than once before, the possibility of
setting qdata on a GObject.

I'm not completely convinced that using qdata is the best programming
paradigm, but in any case it requires some GtkBuilder features before
we can really discuss adding such a thing to Glade.

Any qdata parsing from GtkBuilder files should also be typed
(probably only allowing for fundamental types to be parsable).

I.e. parsing the value "GtkButton" as a "string" type would make
a string "GtkButton" be allocated and tied to the GObject's
life cycle, parsing it as a "GType" would have different results.

Again, I think there are other directions to take to make Glade
and GtkBuilder more usable, without encouraging programmers
to hack with GObject qdata.



2013/3/9, Tristan Van Berkom <tristan.van.berkom at gmail.com>:
On Sat, Mar 9, 2013 at 8:13 PM, Johannes Schmid <jhs at jsschmid.de> wrote:
Hi Juan!


Overall it looks better to me (I don't really know what the clean button
is for, maybe we can just remove it from such a prominent place). I
would consider to replace the switch buttons with a toggle button that
doesn't have "on/off" but just the name of the property to save more

I still favor some kind of GtkTreeView thing like done in Visual Basic
for example but it seems the current GtkTreeView is too limited for that

  Just reiterating what I've said many times before,
the reason I don't want to go in the direction of GtkTreeView, is
that it treats widget properties like rows of data, this approach
limits our capability of providing more user friendly editors.

I would rather go in a direction where property editors see
more per-widget type customization (i.e. a GtkLabel editor
is different than a GtkButton editor), this let's us organize
the view in a more human friendly way.

I know, most of Glade's property editors don't leverage
the custom editor approach enough yet to justify this
approach (most of Glade's editors still look like a dumb
list of properties), but I think it's the right direction to
take in general, so I don't want to frame us into a corner
where editor customization becomes impossible.

Perhaps with the new dogfooding that we've been
doing this will be more easily achieved (i.e. Glades
main UI is made with Glade, hopefully the individual
property editors soon can also be made with Glade).


PS: For a basic example of what I ultimately want,
I know it sucks to refer to OSX tooling /again/ but
here's a screen shot from Interface Builder:


Notice the property editor on the right hand side,
the amount of properties exposed to the user are
limited to configuring "things that matter", and
there is some interesting grouping of properties
going on... this kind of custom layouting is what
I really want to see more of in Glade, while the
core allows for this customization, it just hasn't
been leveraged enough yet to really look great.


Glade-devel maillist  -  Glade-devel at lists.ximian.com
Glade-users maillist  -  Glade-users at lists.ximian.com

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