Making property editor as big as posible!

[Juan Pablo Ugarte]

Hi guys, I am trying to polish the Glade UI and one of the goals is to
make better use of vertical space in the property editor so we can fit
more properties at the same time.

There are a few modification in 3.15 as mention in my blog post

https://blogs.gnome.org/xjuan/2013/03/06/glade-drag-drop-support

But now I am playing a little bit more and choose a somewhat unorthodox
layout for the UI I basically took out the inspector/property editor out
of the hierarchy and put it on a side so that it can take the whole
vertical space of the window (no more wasted space by the menu and tool
bar)

Loading Image...

I must say it looks odd at the beginning but after a few minutes it gets
better :)

What do you guys think?

Is it something worth considering?

What about adding it at least as an optional layout?

anyways, its late so I should probably get some sleep!

greets

Juan Pablo


_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

On Fri, Mar 8, 2013 at 3:35 PM, Juan Pablo Ugarte

Post by Juan Pablo Ugarte
Hi guys, I am trying to polish the Glade UI and one of the goals is to
make better use of vertical space in the property editor so we can fit
more properties at the same time.
There are a few modification in 3.15 as mention in my blog post
https://blogs.gnome.org/xjuan/2013/03/06/glade-drag-drop-support
But now I am playing a little bit more and choose a somewhat unorthodox
layout for the UI I basically took out the inspector/property editor out
of the hierarchy and put it on a side so that it can take the whole
vertical space of the window (no more wasted space by the menu and tool
bar)
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png
I must say it looks odd at the beginning but after a few minutes it gets
better :)
What do you guys think?

Hi Juan,
I don't think it's a good idea at all to "chop" the menubar/toolbar off the
way you did (it looks so unnatural and it's so non-standard that I can't
agree with it) *but* perhaps something can be salvaged from this...

One thing that I find interesting about this experiment is that, perhaps
it could be nice to place the <search widgets> entry in the toolbar aligned
to the right hand side (this would save vertical space from the inspector &
property editor zone without creating this really weird interface, also it
would be a natural place to put the search entry I think, similar to firefoxes
search entry and not so far off from where Glade originally had it).

Also, I still really don't like what you've done to the "Docs" and "Clear"
buttons, they should really be implemented as contextual "actions"
and automatically appear in the context menu (as the Docs already
does) or optionally in the toolbar (perhaps the "Docs" button should
also appear in the toolbar).

I think that we can remove the "Clear" button completely, I think
I recall Vincent Geddes arguing the same thing; the "Clear" button
is probably never used.

So I would prescribe:
a.) Remove the "Clear" button altogether
b.) Make sure the "Read Documentation" feature is implemented
as an action, and make it "important" so that it also shows
up in the toolbar.

Cheers,
-Tristan
_______________________________________________
Glade-users maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users

[Juan Pablo Ugarte]

Post by Tristan Van Berkom
On Fri, Mar 8, 2013 at 3:35 PM, Juan Pablo Ugarte

Post by Juan Pablo Ugarte
Hi guys, I am trying to polish the Glade UI and one of the goals is to
make better use of vertical space in the property editor so we can fit
more properties at the same time.
There are a few modification in 3.15 as mention in my blog post
https://blogs.gnome.org/xjuan/2013/03/06/glade-drag-drop-support
But now I am playing a little bit more and choose a somewhat unorthodox
layout for the UI I basically took out the inspector/property editor out
of the hierarchy and put it on a side so that it can take the whole
vertical space of the window (no more wasted space by the menu and tool
bar)
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png
I must say it looks odd at the beginning but after a few minutes it gets
better :)
What do you guys think?

Hi Juan,
I don't think it's a good idea at all to "chop" the menubar/toolbar off the
way you did (it looks so unnatural and it's so non-standard that I can't
agree with it) *but* perhaps something can be salvaged from this...

Yeah I know I would not either, I was just playing and wanted to share
it. I got to tell that having the UI made with glade makes it very easy
to play with it! heheh but what I was trying to do was move the status
bar under the workspace, but that also looks bad.

Post by Tristan Van Berkom
One thing that I find interesting about this experiment is that, perhaps
it could be nice to place the <search widgets> entry in the toolbar aligned
to the right hand side (this would save vertical space from the inspector &

Yes that would be good!

Post by Tristan Van Berkom
property editor zone without creating this really weird interface, also it
would be a natural place to put the search entry I think, similar to firefoxes
search entry and not so far off from where Glade originally had it).
Also, I still really don't like what you've done to the "Docs" and "Clear"
buttons, they should really be implemented as contextual "actions"
and automatically appear in the context menu (as the Docs already
does) or optionally in the toolbar (perhaps the "Docs" button should
also appear in the toolbar).

Well you can set the default value from the property editor contextual
menu, but adding a clear properties context menu item sounds even better
than adding an item to the toolbar.

Post by Tristan Van Berkom
I think that we can remove the "Clear" button completely, I think
I recall Vincent Geddes arguing the same thing; the "Clear" button
is probably never used.
a.) Remove the "Clear" button altogether
b.) Make sure the "Read Documentation" feature is implemented
as an action, and make it "important" so that it also shows
up in the toolbar.

Yup, sounds good!

greets

JP

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Johannes Schmid]

Hi Juan!

Post by Juan Pablo Ugarte
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png

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
space.

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
approach.

Regards,
Johannes

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Johannes Schmid
Hi Juan!

Post by Juan Pablo Ugarte
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png

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
space.
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
approach.

Hi,
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).

Cheers,
-Tristan

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:

Loading Image...

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.

Post by Johannes Schmid
Regards,
Johannes
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Igor Chetverovod]

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.

Igor

Post by Tristan Van Berkom

Post by Johannes Schmid
Hi Juan!

Post by Juan Pablo Ugarte
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png

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
space.
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
approach.

Hi,
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).
Cheers,
-Tristan
PS: For a basic example of what I ultimately want,
I know it sucks to refer to OSX tooling /again/ but
http://disanji.net/iOS_Doc/referencelibrary/GettingStarted/URL_Tools_for_iPhone_OS_Development/Art/interface_builder.jpg
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.

Post by Johannes Schmid
Regards,
Johannes
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-users

_______________________________________________
Glade-users maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users

[Tristan Van Berkom]

Post by Igor Chetverovod
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.

Cheers,
-Tristan

Post by Igor Chetverovod
Igor

Post by Tristan Van Berkom

Post by Johannes Schmid
Hi Juan!

Post by Juan Pablo Ugarte
https://blogs.gnome.org/xjuan/files/2013/03/glade_new_layout.png

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
space.
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
approach.

Hi,
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).
Cheers,
-Tristan
PS: For a basic example of what I ultimately want,
I know it sucks to refer to OSX tooling /again/ but
http://disanji.net/iOS_Doc/referencelibrary/GettingStarted/URL_Tools_for_iPhone_OS_Development/Art/interface_builder.jpg
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.

Post by Johannes Schmid
Regards,
Johannes
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-users

_______________________________________________
Glade-users maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users