On 25/07/07, Veli-Pekka Tätilä [EMAIL PROTECTED] wrote:
Secondly, I know this is much easier said than done, but would be great
if the GridLayout control could be improved to be more like layout
managers are in other UIs.
I'd like to see a family of layout modules, offering capabilities from
the simplest grid layout through more complex schemes. I'm got a
half-written layout manager that works somewhat like Tk's pack()
command, but I'm not doing well on finding the tuits to complete it.
Java's Swing has excellent layout managers that fill both gaps I
mentioned but they are fairly complex. I've found that Gnome's take on
things is relatively simple to use and gets most jobs done all right.
Here's a brief and high-level explanation with in-line imagery:
http://www.gtk.org/tutorial1.2/gtk_tut-4.html
Thanks - I hadn't seen this one before. Having read it, I think that
what I'm working on, along with an enhanced grid layout manager would
probably do just about everything I can think of.
As GTK+ is open source, I wonder if you could actually borrow some of
the code doing the hard parts and rewrite only Win32 specific bits. The
grid control could then be XS code, too, like most of the Win32::GUI
package appears to be - at least I cannot find many pm files.
I'm not sure that it's a very hard problem - box layout is a well
understood problem, it's just a bit tedious getting all the
calculations correct and not having any 'off by one' errors.
I'm actually of the opinion that we should be moving more of the code
back into perl from XS. I don't think that speed is really much of an
issue for most GUI apps - and if we do have performance problems we
could keep the critical bits in XS.
The biggest advantage of moving more of the code into perl would be
that people who are not Win32 API gurus can see how things are done,
and modify things that they need to. I've got a side project going on
at the moment to look at this.
This is minority stuff, but optionally having the grid start its
indexing at $[ would be cool, too. While we're at this, could not you
make a grid object that works like an array or ref to one but let's you
call methods on it? Usage would be more intuitive then. I thought about
this and tentatively concluded that Perl 5 cannot do that. Tied arrays
lose their objectness and having the user directly access object
internals as an array leads one to trouble, even if you'd store object
data at the end or have per-object data as elements in a class array
datum. OBjects that also look like arrays are trivial in, say, Ruby,
though I mostly use Perl because of PPM and all the nifty modules like
Win32::GUI, for example. For me this is an accessibility issue, my
screen reader does not support most 3rd party UIs.
overloading allows objects to look like arrays - its not something
I've played with extensively, and I'm not sure that you can asign to
the array, but try reading up on the overload.pm pragma.
Regards,
Rob.
