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.
