From: Michael Torrie on 13 Jun 2010 11:43
On 06/13/2010 05:29 AM, lkcl wrote:
> really? drat. i could have done with knowing that at the time.
> hmmm, perhaps i will return to the pyqt4 port after all.
We're now wandering well off-topic here, but then again this thread was
never really on any particular topic.
I have to say I'm really confused as to your issues with GTK and Qt.
I've seen and done all kinds of fancy widget layouts in Qt and have
*never* had to subclass layout. If you think you need to subclass
QLayout, most of the time you're doing it wrong. You are familiar with
how the vertical and horizontal layouts and spacers work in Qt, aren't
you? Sometimes you need a grid for a table or the specialized form
grid. But other than that you want a dynamically-sizing layouts most
of the time. And Qt's Vertical and Horizontal layouts do that.
I'm also confused by your claim that GTK lacks the layout widgets you
need as well. GTK has the GtkHBox layout class which acts much like
your <span> tag. Anything to pack in the hbox is automatically layed
out in a dynamicially-resizing way. Any GTK dialog or window is a
combination of different layouts, nested to get the desired layout.
Works extremely well.
> excellent! that actually makes it worthwhile carrying on. the only
> other thing that needs solving is that RichText is forced to have its
> width and height set. but it mayyy be possible to create an
> appropriate QLayout derivative: i'll have to see.
Again I'm confused here. I just created a little Window in Qt Designer
and was able to get my RichText (There isn't a "Rich Text" widget in Qt;
Just TextEdit with Rich text enabled) widget to resize automatically
just fine as I resized the window. I'm obviously missing something.
From: Arndt Roger Schneider on 13 Jun 2010 11:52
> it's the exact same thing for SVG image file-format. i'm
>_definitely_ not convinced that "SVG the image fileformat" is The One
>True Way to design images - but i'm equally definitely convinced of
>the power of SVG manipulation libraries which allow for the creation
>SVG images using declarative programming.
You rather severly underestimate the impact from SVG!
1. SVG is a complete visualization system and not an fancy way to create
SVG and SMIL are an extreme powerful environment. With it's
possible to create(design) sophisticated graphical and interactive
visualization, but not for much more. Further more SVG and the GPU are
a natural combination.
2. Many of CSS shiny new features --such as animation originate
3. SVG-Print: Printing is one of the biggest problems in
the current IT-landscape. I do not want to install printer
drivers on each telephon I own, neither on any other device --mobile
or not. The printer must contain a computer running an OS and has to
handle an agreed upon page description language (Xml based)...
Well, yes can be done. HTML is however text oriented; each
application entirely based on this technology will be satured
with text. HTML works reasonable well with applications of the past
two decades, but the importance of text is dwindling and other
graphical means of communication become more and more relevant.
> but, all that having been said, and returning to "HTML and CSS (the
>fileformats)", there's a lot to be said for convincing people who are
>stuck in those worlds of the benefits and freedom of declarative
>programming... _without_ having to get involved directly in
Any User Interface should be pre-determined;
this concept allows the consequent separation of
application logic and presentation. It's not only important
>>that web apps are about to take over
>>the world, etc. There is still a place for GUI toolkits
>>are not based on the DOM,
> that there definitely are.
>>or whatever the W3C technology of the month is.
> :) don't underestimate how much time and money is going into the W3C
>standards! and remember, someone's got to implement them, so the
>actual proof of the pudding is not what the W3C thinks but whether the
>technology ends up actually in the hands of users and is successful
The mony part is definitly important. Tk is actually a good example for
the working of money-politics (the absence thereof).
From: lkcl on 13 Jun 2010 13:08
On Jun 13, 3:52 pm, Arndt Roger Schneider <arndt.ro...(a)addcom.de>
> lkcl schrieb:
> > [snip]
> > it's the exact same thing for SVG image file-format. i'm
> >_definitely_ not convinced that "SVG the image fileformat" is The One
> >True Way to design images - but i'm equally definitely convinced of
> >the power of SVG manipulation libraries which allow for the creation
> >SVG images using declarative programming.
> You rather severly underestimate the impact from SVG!
no - i kept things brief, so as not to dominate the postings here:
you've very kindly filled in the blanks, and given far more
information than even i was aware of, which is great.
> 1. SVG is a complete visualization system and not an fancy way to create
... all of which is accessible via DOM manipulation, via the W3C-DOM-
specified functions through the <canvas /> element. use of which has
resulted in the creation of a very powerful _python_ library which re-
presents those SVG Canvas functions. fillRect. saveContext.
demo of end-result usage can be seen here:
> Well, yes can be done.
it's too dreadful. :)
> HTML is however text oriented; each
> application entirely based on this technology will be saturated
> with text.
ah - no, it won't. isn't. pyjamas apps are the proof that that
isn't the case. pyjamas applications contain, at the absolute basics,
_one_ HTML file comprising... about eight lines, the most important
two bits being a "meta" tag naming the pre-compiled application, and a
"script" tag with bootstrap.js which knows about the aforementioned
"meta" tag. that's _it_. the rest can be done _entirely_ using
but... if you _want_ to, that "loader" file can be a full-blown PHP
app: just as long as that meta tag is there, and the bootstrap.js is
there, the pyjamas app can be initiated "on top of" the PHP page.
the DOM. so it's just a matter of degree. you can either specify
almost everything in "text" HTML/CSS or you can do entire DOM-
manipulation or anything in between, to suit _your_ personal
i must not be explaining this very well, for which i apologise.
> >>or whatever the W3C technology of the month is.
> > :) don't underestimate how much time and money is going into the W3C
> >standards! and remember, someone's got to implement them, so the
> >actual proof of the pudding is not what the W3C thinks but whether the
> >technology ends up actually in the hands of users and is successful
> >_for users_.
> > l.
> The mony part is definitly important. Tk is actually a good example for
> the working of money-politics (the absence thereof).
:) yehhs... and then people complain when it doesn't "look good".
hence a reason why i'm advocating to "leverage" the incredible power
of the technologies which _have_ had vast amounts of money/effort
poured into them, with very little effort spent on the "leveraging"
From: Terry Reedy on 13 Jun 2010 13:22
On 6/13/2010 7:20 AM, lkcl wrote:
>> I'm far from convinced that HTML and CSS are the One True Way
>> to design GUIs these days,
> if you have "HTML the fileformat" and "CSS the fileformat" in mind
> when saying that, i can tell you right now that they're not.
> fortunately, with the W3C DOM functions exposing properties and style
> attributes, it's possible to manipulate the exact same attributes that
> CSS and HTML "files" provide access to, using a declarative
> programming style.
With all the glamour hoopla over html/css/xml, it took me a while to
realize that the really important thing is the underlying object model
that the serialization formats communicate. I know this is a bit like
saying "words are important because of the thougths they express" (which
is not to say that beauty of expression is unimportant), but my point is
that in explaining pyjames, you are sometimes running up against a
fascination with the surface layers. Pyjamas requires a different
Terry Jan Reedy
From: Mark Lawrence on 13 Jun 2010 14:20
On 12/06/2010 14:44, lkcl wrote:
> On Jun 6, 10:49 pm, Kevin Walzer<k...(a)codebykevin.com> wrote:
>>> - Pythonic
>>> - The default GUI (so it replaces Tkinter)
>>> - It has the support of the majority of the Python community
>>> - Simple and obvious to use for simple things
>>> - Comprehensive, for complicated things
>>> - Cross-platform
>>> - Looks good (to be defined)
>>> - As small as possible in its default form
>> These goals are not all complementary. In fact, some of them, such as
>> "small" and "comprehensive," are mutually exclusive.
> that's not quite true - you can create a simple core which is easily
> extensible with third party contributions to create more comprehensive
> in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so
> on, all of which were created very easily thanks to the power of the
> underlying GWT core codebase, _none_ of which are actually included
> into GWT by default, _all_ of which can be installed by users and
> simply "imported" just like the core.
> now s/GWT/pyjamas and you have the exact same thing, and all the
> satisfiable requirements are met.
I'd just like to say thanks for opening up this thread. I've never yet
written any GUI in Python, but should I need to do so this your comments
and the responses will certainly stick in my mind.