Prev: subprocess.Popen()/call() and appending file
Next: File descriptor to file object
From: lkcl on 14 Jun 2010 09:44
On Jun 13, 3:43 pm, Michael Torrie <torr...(a)gmail.com> wrote:
> 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.

yeahh... it's kinda necessary to have done complex HTML/CSS-based
layouts (or better yet, an equivalent, e.g. using declarative python-
driven widget-enhanced DOM programming) to appreciate the perspective
i'm coming from.

the "rules" for table layouts in browsers are (aside from their
technical limitations) incredibly powerful, flexible and ultimately
very very forgiving of users' lack of knowledge and experience.

use of - reliance upon - these rules results in quite a bit less code
(both for the pyjamas ui widget developers to have to write, and also
for the users/developers of the pyjamas widget set).

so my expectations were that i should be able to do the same sort of
thing with GTK or QT, and... it just wasn't happening.

to highlight this further, i should point out that i looked up paul
bonser's browser-written-in-python, called pybrowser:
http://git.paulbonser.com/

in it, you can find some pseudo-code for table/div which he's
obviously looked up somewhere, presumably in W3C DOM specifications.
he's already successfully implemented <span /> rules, but the <div />
rules he left for another time.

i tried implementing them: i cannot make head nor tail of the
algorithm/pseudocode :) it's _that_ complex a recursive interaction,
between block-based and flowing layout objects.

i mention this because to even _remotely_ attempt to accurately re-
create pyjamas desktop using Qt4 or Gtk2, it would be necessary,
ultimately, to implement the same browser-based recursive layout
algorithm that is already in existing web browsers.

by doing that, effectively i would actually be creating the vast
majority of the functionality of a web browser... in python!

and rather than do that from scratch, i would actually be better off
either helping (or waiting for) paul to work on pybrowser, or recover
and work on grailbrowser (which i've begun doing - it now runs under
python 2.4 and just needs all its regular expressions converted from
regex to sre in order to run under python2.5+) http://github.com/lkcl/grailbrowser
....

... and then using _that_ as the basis for another pyjamas port, by
adding and using W3C DOM functions (which don't exist in grailbrowser
sadly). paul bonser's work is actually the better underlying
framework: he's already added the W3C DOM TR1 through to TR3
properties and functions, such as getElementById(), appendChild(),
offsetWidth and so on, but grailbrowser is the better _actual_ browser
on account of it actually... working! :)

in a delicious piece of irony, which brings us back full circle to
the original discussion, python/tk-haters will howwl with fury to
learn that grailbrowser is a fully-functioning 35,000-line python/tk
application :)


> 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?

yes.

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

sadly, not to the kind of recursive / child _and_ parent inter-
dependent level as browser layouts that would make it a simple viable
alternative.


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

i did map pyjamas UI HorizontalPanel directly onto GtkHBox, and so
on: i got a long long way, very very quickly by doing that.

perhaps... perhaps if you have time, if you could take a look at the
pyjd-gtk2 and/or the pyjd-qt4 ports, you might be able to point out
where i'm going wrong. they're both here:

http://github.com/lkcl/pyjamas-desktop

they're a bit old, but are functional (install python-gtkhtml2 even
to get the pyjd-qt4 port to run, there's some code still accidentally
left in) and you run them with "hello_loader.py" by hacking in the
appropriate class - you'll see what i mean.

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

ok - it resized, yes? so...

* what happens if you shrink the window to 50 px by 50px and it
_only_ contains RichText widgets, placed in any QLayout derivative
(horiz, vert, grid, doesn't matter) which has had "100% width" and
"100% height" placed on it?

* does the text "force" the QLayout-derivative to expand outwards to
allow all text to be displayed? or does the QLayout-derivative
"override" the displaying of text and thus only display the top left
portion of the text, cutting it off until, eventually, when that 100%
width and 100% height get close to zero, the entire text disappears.

* is there any way to get the behaviour where an effectively free-
form RichText widget's text determines the sizes of its containers,
_without_ having to set either the width or the height to specific
pixel values?

* is there a way to set RichText "percentage width" but still also
say "when that percentage goes below the minimum threshold required to
actually display all text, please ignore the percentage width" ?

additionally:

* how do you tell the RichText to not have a margin? i could not
find a way to specify the text to be hard against the edges of the
RichText container.

* can you insert widgets into the text? say, if i have two words
"menu here" can i place a QMenuBar widget in between those two words
*inside* the actual RichText widget?

from this latter, you can see: there are distinct advantages to using
something like DOM as the basis for a widget set. if the "Rich Text"
comprises the following: "menu <div id='menuplease'> here" then you
can use a widget (HTMLPanel) which has an "add by id" method, where it
will search through all child DOM using elem.getElementById, and then
add the widget as a child to the "Rich Text".

in fact, there's a demo of exactly this, here - page-down to
HTMLPanel: http://pyjs.org/examples/kitchensink/output/KitchenSink.html#Layouts

abstracting out the layouts and the widgets in this way, such that
they're constructed in terms of an underlying "display engine" can
therefore be seen to have real powerful advantages over "hard-coded"
layout classes which are solely and exclusively responsible for their
child widgets, with (as far as i am aware) virtually no interaction
"allowed" between their child widgets and *their* parent. please
correct me if i am wrong on this rather crucial last point, as it was
the whole reason why i stopped the pyjd-qt4 and pyjd-gtk2 ports: if it
_can_ be done i'll happily continue with them.

many thanks,

l.
 | 
Pages: 1
Prev: subprocess.Popen()/call() and appending file
Next: File descriptor to file object