[ptx] artifacts when scrolling

[douglas wilkins]

Hi there,

--- Rob Park <rbpark at gmail.com> wrote:

> On 5/30/05, douglas wilkins <dgswilkins at yahoo.co.uk> wrote:
> > > http://artography.ath.cx/hugin-xul-images.png
> > 
> > I like the look of this, but isn't it a little too long vertically? There
> > doesn't seem to be enough space at the bottom for the preview image.
> 
> Yeah, it is a bit long. I had planned on making the preview image
> smaller to fit (about the size as seen in autopano-sift) eg, a small
> thumbnail.
> 
> > > http://artography.ath.cx/hugin-xul-lens.png
> > >
> > > At this point I have no idea how hard it would be to code in the
> > > actual functionality, but I'm having fun with this, it's so easy to
> > > write and it looks good (yes, I'm a superficial bastard) ;)
> > 
> > If you take a look at the mozilla site for XUL you'll find the following
> > statement:
> > "The intention is to build cross-platform applications like browsers and
> mail
> > clients from a set of tools designed for that purpose. The intention is not
> to
> > implement a generic cross-platform application framework. That's been done,
> and
> > is a great deal of work. We intend to provide a subset of cross-platform
> > functionality suitable for building network applications like browsers,
> > leveraging the cross-platform functionality already built into Gecko,
> Mozilla's
> > HTML layout engine."
> 
> Heh, missed that.
> 
> > hugin doesn't fit into any of these categories.
> 
> Well sure, but that's a poor reason to reject a toolkit... I mean,
> using code for something that the author hadn't anticipated is a sign
> of good, successfull code.

True, but the problem is that the toolkit needs to have the functionality of
more than just GUI layout. for example, wx allows us to store configuration
information in a platform transparent manner - in .hugin on linux and in the
registry on windows - with one piece of code and without multiple platform
dependant #ifdef statements to control it.

> 
> > Also using XUL would imply using the xpfe component to do layout rendering,
> but
> 
> xpfe?

The rendering engine that actually interprets the XUL

> 
> > work that we need the framework to do, on the control point tab for
> instance, I
> > doubt can be done by xpfe.
> 
> I think the control point tab would not be that hard. XUL has a widget
> called, IIRC, "stackbox", which allows you to basically lay widgets
> overtop of each other in an arbitrary way. So you just display the
> image, and then display control point widgets on top of it. You can
> embed SVG into XUL, so it'd be fairly straightforward to create little
> colored circles to represent the control points like hugin does now,
> without need for bitmapped images.

Yes you could display them with XUL, but you couldn't move them with the mouse,
or create them on the fly with a click of a mouse as far as I can see.

> 
> The difficulty that I'm actually having with XUL at this point is threefold:
> 
> 1. xul is missing the spinbox widget (eg, the text entry field with
> the "up" and "down" buttons on the right side, so we lose out on that.
> 
> 2. in Gtk, there are two kinds of dropdown boxes: the kind you can
> edit the value of like a text box, and the kind you can't. XUL allows
> you to control whether the dropdown box is editable or not, but either
> way the widget looks like Gtk's editable dropdown, it's impossible to
> create the Gtk "non-editable" dropdown box widget (well, you can
> create a widget that behaves the same way but it looks different).
> That breaks consistency in a bad way for me.
> 
> 3. XUL's grids (table layout widgets) don't support making a widget
> span multiple rows/columns, so eg for something like the
> hugin-test.png screenshot, it's impossible to make the "best fit"
> button be in the middle of two lines, and it's also impossible to make
> the "projection" drop down be the width of the two widgets combined,
> meaning that the dropdown list will stretch the textbox to be wider
> than necessary.
> 
> So the end result is that it's impossible to be compliant with *any*
> HIG (GNOME's or Apple's) using XUL.
> 
> XUL was very appealing to me at first just for the way it's simple
> XML, and the way you can actually style it with CSS, it's very slick
> and it's very easy to code up an elaborate interface quickly.
> Unfortunately it has a couple fatal flaws that make it unsuitable for
> hugin...
> 
> Back to the drawing board, I guess. What I really need is some kind of
> XUL/XRC thing, but for just straight Gtk. Preferrably more like XUL
> than XRC ;)

You're assuming that GTK is the only widget engine out there and the only one
we should use? :-)

regards,
Doug



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com