Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Is there a graphical GUI builder?

Reply
Thread Tools

Is there a graphical GUI builder?

 
 
Roland Koebler
Guest
Posts: n/a
 
      02-20-2013
Hi,

> That way of building a window tends to produce programs that port
> badly to other systems.

hmm, I don't think so. I've build several applications in C + GTK/Glade and
Python + GTK/Glade, which easily run on Linux and Windows without any GUI
changes.

> playing with Java applets introduced
> the novel and somewhat strange idea that your window should be built
> using rules and layouts, to avoid problems with button sizes, fonts,
> etc, etc.

Do you know the container-concept of GTK+ and Glade?

In many GUI-builders, you set your widgets to fixed positions (e.g. a text
field at x16/y16 with 100*30 pixels, a button at x16/y50 with 100*50 pixels
etc.). This is *bad*, and causes all kinds of problems with e.g. different
window- or font-sizes, like widgets outside of the visible window, text
running over the border of a widget or being cut at the edge of the widget
etc.

But: GTK+ has a wonderful concept of "containers"[*]. You normally don't
set widgets to fixed positions -- instead, you add layout tables (or
vertical boxes or horizontal boxes or ...), and essentially define
that some widgets should be above each other, side by side or in a grid
layout, so you more or less define the layout logically. The real size
and position of the widgets is dynamically calculated by GTK+, so they
always have the right size, and different font sizes, different window
sizes, etc. are not a problem anymore [q]. And Glade (the GTK+ GUI builder)
works exactly that way.

[*] Besides, the container-concept also allows such nice things like
putting anything inside a button (e.g. 2 images and a label), or inside
a notebook tab etc. pp.

[q] In Qt, it's also possible to generate such flexible layouts. But
it's unfortunately not the default way in Qt, and the Qt designer only
supports it rudimentarily, and in a much less obvious way. And Qt does
not have such a "container"-concept, where many widgets (e.g. buttons,
notebook registers etc.) contain other widgets.

> You have to think about your window differently - think about what
> you're putting where, rather than going visually "that looks about
> right" - but the reward is that it'll look right no matter where you
> run your app.

Yes, that's also true for GTK+/Glade.
But you have the choice to either build you GUI graphically with your
mouse, or textually in your editor -- or mix both.


regards
Roland
 
Reply With Quote
 
 
 
 
Phil Thompson
Guest
Posts: n/a
 
      02-20-2013
On Wed, 20 Feb 2013 10:34:50 +0100, Roland Koebler <(E-Mail Removed)>

....

> [q] In Qt, it's also possible to generate such flexible layouts. But
> it's unfortunately not the default way in Qt, and the Qt designer only
> supports it rudimentarily, and in a much less obvious way. And Qt does
> not have such a "container"-concept, where many widgets (e.g. buttons,
> notebook registers etc.) contain other widgets.


....

I'm sorry but all of that is completely wrong. Using layouts that
automatically adapt to fonts, the size of widgets being laid out etc. is
the default way. You could use explicit sizes and positions if you wanted
to, but that would be bad for the reasons you gave. Qt does have a
container concept - that's what a QWidget is (the base class of all
widgets).

Phil
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      02-20-2013
On Wed, Feb 20, 2013 at 8:34 PM, Roland Koebler <(E-Mail Removed)> wrote:
> Hi,
>
>> That way of building a window tends to produce programs that port
>> badly to other systems.

> hmm, I don't think so. I've build several applications in C + GTK/Glade and
> Python + GTK/Glade, which easily run on Linux and Windows without any GUI
> changes.
>
>> playing with Java applets introduced
>> the novel and somewhat strange idea that your window should be built
>> using rules and layouts, to avoid problems with button sizes, fonts,
>> etc, etc.

> Do you know the container-concept of GTK+ and Glade?


Yes, I do; it's just that I first met that concept when I started
playing with Java applets. Up until then, all my UIs had been either
textual or laid out with pixel-based positioning in a WYSIWYG layout
editor.

> In many GUI-builders, you set your widgets to fixed positions (e.g. a text
> field at x16/y16 with 100*30 pixels, a button at x16/y50 with 100*50 pixels
> etc.). This is *bad*, and causes all kinds of problems with e.g. different
> window- or font-sizes, like widgets outside of the visible window, text
> running over the border of a widget or being cut at the edge of the widget
> etc.
>
> But: GTK+ has a wonderful concept of "containers"[*]. You normally don't
> set widgets to fixed positions -- instead, you add layout tables (or
> vertical boxes or horizontal boxes or ...), and essentially define
> that some widgets should be above each other, side by side or in a grid
> layout, so you more or less define the layout logically. The real size
> and position of the widgets is dynamically calculated by GTK+, so they
> always have the right size, and different font sizes, different window
> sizes, etc. are not a problem anymore [q]. And Glade (the GTK+ GUI builder)
> works exactly that way.


Precisely. That's the fundamental difference of thinking. I haven't
actually used Glade, preferring to lay things out myself in actual
code, but the difference isn't so much between "visual layout editor"
and "code to create stuff" as it is between "pixel-positioning" and
"rule-based layout". And it's that difference that creates the
distinction between programs that look terrible on anything other than
the programmer's own system, and those that look fine on any platform.

Same thing happens with web browsers, too, except that they're a lot
more likely to be flat-out buggy (I do not EVER want to go back to
making a web page look correct in IE6).

>[*] Besides, the container-concept also allows such nice things like
> putting anything inside a button (e.g. 2 images and a label), or inside
> a notebook tab etc. pp.


Not that you'll actually *use* that flexibility very often, but it
sure is nice when you want it! And it's a cleanliness of design, too;
instead of having the PushButton subclassed to be the ImagePushButton,
and having the Notebook have special code to permit you to put an icon
on the tab, no, you just have the button surface and the tab accept
one child, which can be a layout manager. What if you like how the
image+text button looks, but want the image to take 25% of any spare
space and the text to grab the other 75%? I've no idea if that level
of flexibility will EVER be wanted, but you can do it with an Hbox
layout manager, so you can do it on a button.

It's a huge change of thinking, if you've grown up laying things out
on pixels. But it's SO worthwhile.

ChrisA
 
Reply With Quote
 
Roland Koebler
Guest
Posts: n/a
 
      02-20-2013
Hi,

> I agree that on Linux GTK is pretty darn slick. I use it for all my
> little GUIs. But on Windows, GTK, particularly under python, isn't
> quite as easy to get running.

installing GTK+ 2.x should be easy, since there are all-in-one-installers
for windows on http://www.gtk.org (for GTK+) and http://www.pygtk.org
(for Python+GTK+).

Installing GTK+ 3.x on windows is currently a bit more complicated, but this
situation should improve soon.

> I think if the OP is on windows (which it seems like he is) then Qt with
> PySide (using either QML or QtDesigner to manipulate ui files) is an
> excellent choice.

I never was happy with QtDesigner -- I always struggled *a lot*
(in contrast to Glade, where most things worked like a charm).

I not even achieved to rename the tab of a notebook (?!) or to create
a button with an icon above the text, or a grid layout without a fixed
layout. It even seems that the QtDesigner doesn't even provide standard-
icons (e.g. for open, close, exit etc.) or a file dialog. Am I doing
something fundamentally wrong in QtDesigner, or is QtDesigner really
that bad?

regards
Roland
 
Reply With Quote
 
Roland Koebler
Guest
Posts: n/a
 
      02-20-2013
Hi,

> > [q] In Qt, it's also possible to generate such flexible layouts. But
> > it's unfortunately not the default way in Qt, and the Qt designer only
> > supports it rudimentarily, and in a much less obvious way. And Qt does
> > not have such a "container"-concept, where many widgets (e.g. buttons,
> > notebook registers etc.) contain other widgets.

>
> ...
>
> I'm sorry but all of that is completely wrong. Using layouts that
> automatically adapt to fonts, the size of widgets being laid out etc. is
> the default way. You could use explicit sizes and positions if you wanted
> to, but that would be bad for the reasons you gave.

hmm, interesting, but then Qt Designer is a total mess.

In Qt Designer (at least in 4.x), the default is a fixed layout, where
I have to position the widgets at precise pixel-positions and have to
define the size in pixels. And I cannot remove the default fixed layout
without modifying the .ui-file in a text editor!

> Qt does have a
> container concept - that's what a QWidget is (the base class of all
> widgets).

A container concept like in GTK+ is *much* more than having a base
widget where all widgets are derived from, or having layout boxes.
It means that most widgets are containers, like buttons, notebook
labels, checkboxes, radio buttons, scrollbar-windows etc.
And I haven't seen anything like this in Qt (or: in Qt Designer).


regards
Roland
 
Reply With Quote
 
Phil Thompson
Guest
Posts: n/a
 
      02-20-2013
On Wed, 20 Feb 2013 11:42:48 +0100, Roland Koebler <(E-Mail Removed)>
wrote:
> Hi,
>
>> > [q] In Qt, it's also possible to generate such flexible layouts. But
>> > it's unfortunately not the default way in Qt, and the Qt designer

only
>> > supports it rudimentarily, and in a much less obvious way. And Qt

does
>> > not have such a "container"-concept, where many widgets (e.g.

buttons,
>> > notebook registers etc.) contain other widgets.

>>
>> ...
>>
>> I'm sorry but all of that is completely wrong. Using layouts that
>> automatically adapt to fonts, the size of widgets being laid out etc.

is
>> the default way. You could use explicit sizes and positions if you

wanted
>> to, but that would be bad for the reasons you gave.

> hmm, interesting, but then Qt Designer is a total mess.
>
> In Qt Designer (at least in 4.x), the default is a fixed layout, where
> I have to position the widgets at precise pixel-positions and have to
> define the size in pixels. And I cannot remove the default fixed layout
> without modifying the .ui-file in a text editor!


I'm sorry but that is just wrong. You position the widgets roughly, select
them, then click on the button corresponding to the layout you want to
apply. By selecting a sub-set of the widgets you can create a sub-layout
which itself can be part of a parent layout. You therefore create any sort
of layout you want without specifying a single pixel position or size.

Phil
 
Reply With Quote
 
Roland Koebler
Guest
Posts: n/a
 
      02-20-2013
Hi Phil,

> > In Qt Designer (at least in 4.x), the default is a fixed layout, where
> > I have to position the widgets at precise pixel-positions and have to
> > define the size in pixels. And I cannot remove the default fixed layout
> > without modifying the .ui-file in a text editor!

>
> I'm sorry but that is just wrong.

I now found out, that I can indeed change the default fixed layout by
clicking onto the empty main window or by selecting the main window in
the Object Inspector and then clicking on a layout-icon on the toolbar.
Thanks.

I hope that most developers who use Qt use this feature, since the fixed
layout is the default in Qt designer and it's not really obvious how to
change this for beginners...


regards
Roland
 
Reply With Quote
 
Laszlo Nagy
Guest
Posts: n/a
 
      02-20-2013

> You have to think about your window differently - think about what
> you're putting where, rather than going visually "that looks about
> right" - but the reward is that it'll look right no matter where you
> run your app. As an added bonus, you don't need any sort of graphical
> builder; you can just write code directly in your editor.

Yes, but these are not mutually exclusive. There can be (and there are)
GUI tools that let you arrange your widgets with layouts and rules. In
other words, using layouts and rules does not alone make it impossible
to use a GUI builder.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      02-20-2013
On Wed, Feb 20, 2013 at 11:09 PM, Laszlo Nagy <(E-Mail Removed)> wrote:
>
>> You have to think about your window differently - think about what
>> you're putting where, rather than going visually "that looks about
>> right" - but the reward is that it'll look right no matter where you
>> run your app. As an added bonus, you don't need any sort of graphical
>> builder; you can just write code directly in your editor.

>
> Yes, but these are not mutually exclusive. There can be (and there are) GUI
> tools that let you arrange your widgets with layouts and rules. In other
> words, using layouts and rules does not alone make it impossible to use a
> GUI builder.


Agreed, as I clarified in my subsequent post. My original statement
was a tad broad. The GUI builder isn't the problem, but the Visual
BASIC GUI builder is pixel-based, and is therefore part of what I
described as tending to produce non-portable UIs.

ChrisA
 
Reply With Quote
 
Kevin Walzer
Guest
Posts: n/a
 
      02-20-2013
On 2/19/13 5:19 PM, Rex Macey wrote:
> I see that there is TKinter, which is a scripting function to build GUIs. To be clear, I'm looking for a graphical interface to build GUIs.


Tkinter is so easy to use to build GUI's that a GUI tool isn't needed.
Hardly any Tk or Tkinter developer uses anything but a text editor and
console to develop a user interface.

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
GUI / graphical games: where to start? Aldric Giacomoni Ruby 3 02-12-2009 06:21 PM
GUI - GUI value passing paul.foreman Java 5 10-25-2004 08:06 AM
ANNEVOLVE Releases its First Graphical/GUI Program Michael Livsey Python 0 06-03-2004 06:48 PM
Graphical Ruby/Tk GUI designer? Asfand Yar Qazi Ruby 1 02-22-2004 05:49 PM
[PY GUI] interest function in python GUI(wxpython,pyqt) program.wxpython,pyqt ulysses Python 4 10-22-2003 03:28 PM



Advertisments