[MonoDevelop] Comments on Stetic GU designer

Mon Jun 5 15:21:54 EDT 2006

Well I've been doing VB forms for twelve years now, and let me say, GTK (and
so GTK#) IMO is better even for "easy" forms, but...  The catch is: you need
to change your thinking, as when you go from procedural to OO to
event-driven to whatever programming.

In VB/WinForms, you have a blank surface and drop components and they stay
where you put them until you move/resize them, that makes it VERY fast to
have something on the form, and even compile and run the form, but then it a
chore to have to align/space/dock/etc. all of controls, precisely. That is
why the VS.NET designer has so many buttons in the toolbar to "align all
selected control by the left side, taking the last selected as the anchor",
"space all the selected controls vertically with equal spacing between them,
keeping the topmost and bottommost at their current positions", "make all
the selected controls have the same height as the last selected", and so on.
So you have an easy start and harder maintenance.

Well in GTK (GTK#), you have to think the overall layout first and select
the proper container (or more typically the nesting of some containers).
Particularly, answering to you Richard, the window widget HAS a default
layout: a single auto-adjustable slot for some other widget (normally a
container), because that is the only one able to work for nay kind of
window. In truth GTK isn't very similar to Java AWT/SWING, where you have a
generic container and change the applied layout: in GTK each container
expresses an specific layout, with some parameters to adjust some variations
like the number of columns in a table. The sizing responsibility is divided
between the container and the child widgets, and you can adjust who takes
precedence but beware that some defaults apply: when dropping a button on
the window, for instance, the button will expand to the client-size of the
window, but you can tell the window to resize around the minimum size of the
button that is itself calculated from its current content.

The good thing is that, for instance, laying out a tabular design in
WinForms and them adding a new "row" is a lot of work compared to just
right.clicking the table and adding a row, from the popup menu, where you
can drag the widgets you need, in GTK.

So I think, one need to adjust a bit the mental process behind form
designing when starting with GTK#, to think the overall layout first, and
know the available containers needed to achieve that. To me it's just second
nature now to add a vbox as my first (root) container in any GTK# form, with
an hbox inside in the last (bottommost) cell to be able to put the nearly
always needed buttons. That works for 99% of the dialogs and simple windows
I need to design, taking me no more than 30s to have it already with two or
three buttons, and it would take even less if I didn't have to adjust sizing
priorities/padding on some cells, to make it more like standard dialogs.

Some people, talked about templates, and yes this simple layout with already
adjusted sizing priorities probably is a good candidate for being a GTK#
template to add to MD.

Anyway, I think support for GTK.Fixed, or even better GTK.Layout (an
scrollable/directly-drawable version of GTK.Fixed), is needed in Stetic, but
really it isn't as easy to add, as Stetic would have to know and record all
that positional info that isn't normally associated with the
widgets/controls.

Thanks for the patience,

On 6/5/06, Richard Hendershot <rshendershot at mchsi.com> wrote:
>
>  I'd be happy if it were possible to manually add gtk.Fixed to the stetic
> design.  I tried modifying gui.stetic manually but compilation only showed
> that the Fixed class was unresolved.
>
> While I'm familiar with java layout manager classes and I can conceptually
> map gtk.Table to BorderLayout one interesting decision about Stetic is
> there is no default layout.  Also it seems that there is no corollary to the
> flow layout that would allow easily placing multiple widgets onto a frame.
> With Stetic, placing a widget onto a top level window only allows adding
> that *one* child.
>
> Javadocs show subclasses but mondocs seemingly make it hard to find
> classes that implement high-level concepts.  For example, I look at
> gtk.Bin and see Button.  That's mentioned in Remarks but not explicitly as
> a subclass, but anyway...  If I add a Bin::Button to the gui designer, I'm
> prevented from adding any other kind of control, including other containers.
>
>
> I'm sure that latecomers like myself are missing a lot of the design and
> tradeoff conversation.  Another issue for me though is I have yet to find
> hard crunchy documentation about Stetic itself.  Given Monodevelop 0.11, I
> had to create a few sample projects, really, just to verify that GTK was the
> only place Stetic allowed visual GUI design.  I probably just missed the
> place where this was stated, I'm just saying that was my experience.
> Linux.  Older Monodevelop. Upgrade.  Dive In!~
>
> So I probably missed some important things.  A tutorial and a core Stetic
> resource would be real helpful at this point.
>
> I agree generally that a fixed layout is probably a bad idea for 95% of
> any application, including those you only expect to use for yourself.  The
> tradeoff is "is it easy using Stetic to modify the UI".  At this point I
> have no idea but am excitedly anticipating finding out  ;)
>
> Thanks!
> -rsh
>
>
> On Mon, 2006-06-05 at 09:44 -0500, Tony Caduto wrote:
>
> JimD wrote:> Mario Carrión wrote:>   >> Currently, that Container isn't shown in the Containers list and it>> won't (probally) be due to disadvantages commented earlier, you may>> request that feature to Core MonoDevelop developers to add it in future>> releases, however I don't support adding that behavior.>>>> Cheers>> --->> Mario Carrión>>     >> Is there a way to add it?  Why can't you let developers make their own> choice?  Isn't that part of what Linux and Open Source is about?>>>   I agree, if there are core developers reading this, please add thefixed container so those of us that are used to win32 developmentcan have something that is similar.
> I don't want to hear "You have the source" fix it yourself either, I amnot a monodevelop hacker and by the time the learning curve is out ofthe way I would have wasted a ton of time, so let's not start the you have the source thing. (I only mention this because every time I have pointed out a shortcoming in a open source project someone will say it)
> I am sorry(not trying to start a flame war) but the whole panel way of building a GUI is not intuitive at all and makes designing a simple GUI a huge pain in the rear. A better solution would be to have anchor/alignment properties or something similar for the fixed panel, so I can make a edit control resize if I want to, that's how it's done in Delphi and VS.net. Also in Delphi I can put a panel and I can set alignment properties if I want stuff to resize automatically, for example I can put a panel and align it to bottom, add a splitter then another panel and align that to client.  The fact that MonoDevelop tries to force the whole panel thing is ridiculous.
> I love Linux and open source, but the development tools available pale in comparison to Delphi or VS.net (Delphi is the best of course :-)  Theonly one that is close right now would be NetBeans 5.x, sorry theeclipse GUI builder stinks.
> If Monodevelop is to be a success it needs to be easy to use, think VB 3 back in the early 90s.  without a doubt VB 3 is what led to the huge popularity of windows.  The same thing could happen to Gnome and Linux.
> Thanks in advance for listening :-)
>
>   --
> Richard Hendershot <rshendershot at mchsi.com>
>
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
>
>

-- 
Rafael "Monoman" Teixeira
---------------------------------------
As I'm currently working a lot with Java and even fixing Java VMs
(JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the title
(Javaman) from my friend Bruno Souza and become the MonoNJavaMan. Yeah, I
may currently be crazier than usual...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20060605/91e22d1e/attachment-0001.html