Re: grid widget (was Re: possible removal of GtkWrapBox)
- From: Tristan Van Berkom <tristanvb openismus com>
- To: Federico Mena Quintero <federico ximian com>
- Cc: gtk-devel-list gnome org, Havoc Pennington <hp pobox com>
- Subject: Re: grid widget (was Re: possible removal of GtkWrapBox)
- Date: Fri, 08 Oct 2010 14:25:12 +0900
On Thu, 2010-10-07 at 14:37 -0500, Federico Mena Quintero wrote:
> On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote:
>
> > It's a valid point, but I don't know that Glade is always easiest. I
> > don't think it's a good excuse for making the actual API crappy.
>
> Oh, no, of course not. What I mean is that if few apps actually do
> complex layout by hand, then maybe it's better to spend effort in making
> Glade good. But I like a lot what you say below.
>
> > (In fact I'd almost think Glade should have its own container widget
> > that's designed to be easy to use in a builder, just as in code it's
> > good to have a container widget that's easy to use in code. Do the
> > same top-down exercise with Glade - what would make a container easy
> > to work with in a UI builder - and design based on that.)
>
> This is very interesting. We should definitely ask the designers. Off
> the top of my head, here is what happens right now:
>
> 1. You sketch your UI in a napkin or some suitable fibrous material.
> Due to your extensive training in visual aesthetics, your UI is
> well-balanced, it has good use of whitespace, etc.
>
> 2. You fire up Glade.
>
> 3. You throw in some tables and boxes to contain the elements which are
> visually aligned in your sketch.
>
> 4. ... Hours pass ...
>
> 5. You give up as GTK+ plainly doesn't let you adjust whitespace in an
> intuitive way, and it is really hard to size widgets like treeviews,
> etc. Your UI looks halfway decent but squashed, like if you had run
> GIMP's "zealous crop" on your napkin sketch (that's the filter that
> removes all empty rows/columns of pixels, leaving effectively no
> whitespace).
>
> 6. At some point you actually run your UI against translations which
> change the length of the text labels, and you give up for the second
> time :)
>
> When using Glade, the problem is not usually figuring out the grid you
> need (you just throw in a table and insert/delete cells as appropriate).
> The problem is having to endlessly tweak all the parameters that modify
> how things respond to their cells. Then tweaking all the things that
> affect how things resize. Then realizing that whitespace is basically
> impossible to do.
>
> There's too much mousing around. Click on a widget. Move the mouse all
> the way to the properties area. Tweak tweak tweak. Move back to the UI
> to click on another widget. All that back-and-forth is very wasteful.
>
> OK, I'm just complaining here. It would be good to sit down together in
> the Summit and see how people use Glade.
Maybe this is a good time to revive my pet composite containers
branch[0]...
I've tried to explain this a hand-full of times, hopefully by now
it's understandable in detail in the bug report[1].
Generally, the way that *I* would like people to use Glade is a little
more like adobe flash or the NextStep Interface Builder... that is
to say... you go ahead and design an interface and then break it down
into sub-ui files... each UI file can be implemented as a composite
widget class (i.e., right-click on your "user information" box full
of entries and "Export As Class", then write your FooUserInformation
widget which will show up inline in the main UI... copy/paste/reuse at
will... in your language binding of choice, exported "named" composite
children show up as object properties/instance-members auto-magically).
So far the branch transforms most of the internal dialogs to use
GtkBuilder xml to define the UI (i.e. GtkAboutDialog is *not* a
special-case with hand-written code anymore... it's defined with
it's own .ui file).
When I last touched this "pet branch" of mine a few months ago I
think the final thing lacking was to update the GTK+ build system
so that header files can be generated for the .ui files (currently
the xml is declared as a string constant inside the dialog widget
classes themselves which is a little awkward for editing with Glade,
however ultimately they should be included as a string constant
to avoid scratching the hard-disks just to create/show a dialog).
Cheers,
-Tristan
[0] http://git.gnome.org/browse/gtk+/log/?h=composite-widget-templates
[1] https://bugzilla.gnome.org/show_bug.cgi?id=612036
Note on Glade,
With all the big plans for Glade and short amount of time I've had
in the past (I've always been a little over-ambitious I guess), I think
I will have to drop support for libglade and GTK+2.0's deprecated
widgets completely... and then we can focus on doing a really rocking
Glade for GTK+ 3.0... another big focus will be better interaction
in the workspace, this should be much improved by rendering all the
project widgets offscreen and allowing us to paint on top of them
with cairo directly.
>
> Federico
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]