Re: use AnyGUI

Some related thoughts:

When it is quite difficult to wrap around those existing GUI implementation, another way to look at the issue is that, we may need a standard for Perl GUI.

The standard should specify what wighets are mandatory for all Perl GUI implementation, what are optional, and for each wighet, what its default rendering is, what its default behavior is, what API's it should support...
Tk should be repackaged. Tk does not provide us enough functionality we want, but at the same time, Tk is a little bit fat, if you take a look at how many modules are bundled under Tk. Also some of the high-end widgets are poorly developed. Actually if Perl provides a strong core GUI implementation (a kind of leadership), it might attract the majority of Perl developers, and become the de facto standard, which is a role Tk failed to play so far.

For example, Tk::Table is one of those poorly designed widget. It is not easy to use (alomst cannot be used directly), and its default behavior (provided) is really limited. One might view this as flexibility, but I would argue, fair enough, but then let's have a sub class of Tk::Table, for example Tk::Table::Default, to provide a concret default table implementation, and bundle it as core module.

Comment on Re: use AnyGUI

Replies are listed 'Best First'.
Re^2: use AnyGUI by atcroft (Abbot) on Mar 02, 2003 at 07:58 UTC
It sounds to me as if what you're suggesting in point 1 would be a graphics equivalent to DBI, where there would be modules specifically to handle particular graphics systems much as DBD::* modules handle the particulars for any one type of database. IIRC, the combination of DBI and DBD::* allows for the use of database-specific enhanced functions while giving a general set of workable functionality. While likely very difficult, involving a lot of work by a number of developers, providing such a functionality for those looking at GUI applications does seem like a very intriguing idea...	[reply]

Replies are listed 'Best First'.

Re^2: use AnyGUI
by atcroft (Abbot) on Mar 02, 2003 at 07:58 UTC

It sounds to me as if what you're suggesting in point 1 would be a graphics equivalent to DBI, where there would be modules specifically to handle particular graphics systems much as DBD::* modules handle the particulars for any one type of database. IIRC, the combination of DBI and DBD::* allows for the use of database-specific enhanced functions while giving a general set of workable functionality. While likely very difficult, involving a lot of work by a number of developers, providing such a functionality for those looking at GUI applications does seem like a very intriguing idea...

[reply]