use AnyGUI

Replies are listed 'Best First'.
Re: use AnyGUI by dws (Chancellor) on Mar 01, 2003 at 20:37 UTC
So, what I want to know is, is there a GUI wrapper module that presents a single interface to the calling code but internally uses whichever of those it can find present on the system? If not, why not? This was tried several times in the C/C++ world. The "high-order bit" problem is that such an approach forces you towards the lowest common denomimator in feature set and behavior. That tends to underwhelm UI designers.	[reply]
Re: use AnyGUI by jonadab (Parson) on Mar 01, 2003 at 23:48 UTC
such an approach forces you towards the lowest common demonimator in feature set and behavior. That tends to underwhelm UI designers. Sure, but if we were willing to sacrifice the less capable GUIs (Motif, Tk), I think that for many projects the LCD between Win32, GTK, and Qt would be acceptable. Even GTK and Qt would be a welcome combination: there is Qt for OS X and GTK for WinXP, so such a module would be able to be used on (recent versions of) all three major GUI platforms (Windows, X11, Aqua). `for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}` [download]	[reply] [d/l]
Re**2: use AnyGUI by xmath (Hermit) on Mar 01, 2003 at 20:56 UTC
Well, you can ofcourse support more advanced features, but it means that for GUI-frameworks that do not natively support such a feature the author of "AnyGUI" would have have implement this using the capabilities that are available. This is however obviously a rather tedious job and makes AnyGUI a very complex project.	[reply]
Re: Re**2: use AnyGUI by webfiend (Vicar) on Mar 01, 2003 at 21:36 UTC
This sounds a bit like the approach taken by wxWindows. It interfaces to GTK, motif, the Windows API, and OS X (I think). Anything that one or the other can't do is implemented directly by wxWindows. So everybody gets a high-functioning almost native toolkit. Pretty sweet. Too bad I haven't been able to get wxPerl to compile, but that's just me :-) I just realized that I was using the same sig for nearly three years.	[reply]
Re: use AnyGUI by Aristotle (Chancellor) on Mar 02, 2003 at 00:48 UTC
The problem with such a thing would not be that it can only offer a lowest common denominator of widgets (it can offer more), but that it can only offer the lowest common denominator of the APIs. The event models in particular would probably be very hard to integrate behind a single consistent interface if that interface is to be at all powerful. If you drop Tk from the mix, then it might just be doable though. GTK, Qt and Win32/GDI are similar enough that it shouldn't be too hard to offer a wrapper. On the other hand, wxWindows already does that for Motif, GTK and Win32/GDI on a lower level. On Windows, a binary PPM of WxPerl and PAR should make end-user ready distribution easy. On Unix, pretty much everyone who is running a GUI has a compiler as well anyway. Makeshifts last the longest.	[reply]
Re: use AnyGUI by Abigail-II (Bishop) on Mar 03, 2003 at 00:47 UTC
On Unix, pretty much everyone who is running a GUI has a compiler as well anyway. Oh, really? Several major Unix vendors do not ship a compiler with their OS. But they do ship a GUI. Abigail	[reply]
Re^3: use AnyGUI by Aristotle (Chancellor) on Mar 03, 2003 at 01:38 UTC
I knew someone was gonna call me on that one. `:)` What I mean is desktop machines (as opposed to servers) running one of the free OSes are very nearly always equipped with a gcc. It's certainly not an absolute truth, but one can presume the availability of a compiler in reasonably large percentile of their target market. Certainly, it's much more valid to do so than when targetting Windows or Mac (though OS X is a slight change of course, in that even though AFAIK it does not ship with a compiler, a free one is available). Makeshifts last the longest.	[reply]
Re: use AnyGUI by pg (Canon) on Mar 02, 2003 at 07:22 UTC
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.	[reply]
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]
Re: use AnyGUI by crenz (Priest) on Mar 01, 2003 at 23:24 UTC
Don't forget that all these have different ways not only for creating Windows etc., but also more intricate things -- handling callbacks, messages etc. It is possible to implement a "use AnyDBM;", but only because the interfaces are all very similar. It would be too complex to "use AnyGUI;". And not worth it. The better approach is IMHO to use wxWindows, as mentioned above. Yes, you're forcing the user to install wxPerl (or yourself to distribute it), but at least it will run on different platforms natively.	[reply]
there.is.only.xul by Ctrl-z (Friar) on Mar 02, 2003 at 15:45 UTC
why interface to any of them, they are all sh...<edit>not very good</edit> <hijack> now, over at mozdev, there is project to interface Perl and XPCOM. Just one of the great things about this would be that Perl could use the righteous Gecko engine and XUL as a GUI kit - cross platform consistent, aesthetically beautiful, skinnable, embeddable, can be internationally localised, a breeze to develop and deploy, can be delivered across the network... great, where do i get it? you cant. At least, not on CPAN and not for Mac/Windows. As far as I can tell there is not a lot of support and/or word of mouth about this project among the Perl community. IMHO this is a goddamned tradegy. </hijack> time was, I could move my arms like a bird and...	[reply]
Re: there.is.only.xul by Corion (Patriarch) on Mar 02, 2003 at 15:58 UTC
>> great, where do i get it? > you cant. At least, not on CPAN and not for Mac/Windows In other words, if you want a cross-platform GUI toolkit, simply restrict yourself to one platform and you can have it ?? I know there is a book out about programming user interfaces in XUL, but honestly, I don't really see that XUL is the way to go, if it dosen't support Win32 or Mac, as these two platforms are the platforms where the users are. For Win32, there actually is something like XUL btw, called HTA (HTML Application) - IE displays these in a window of their own, and you can program them in JavaScript (and propably PerlScript as well), or you can simply use the HTA as your user interface and have your main program docked to the application via Win32::OLE `WithEvents`. But don't propose yet another open source brainchild that is supposed to be there-in-the-next-release. At least Linux celebrates the 5th year in sequence of "next year Linux will be ready for the desktop". `perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web` [download]	[reply] [d/l]
Re: Re: there.is.only.xul by Ctrl-z (Friar) on Mar 02, 2003 at 16:06 UTC
In other words, if you want a cross-platform GUI toolkit, simply restrict yourself to one platform and you can have it ?? XUL/XPCOM is cross platform, its the perl bindings that are not. XPCOM is what powers Mozilla, Netscape, Komodo - This is not a OS fad. What you describe with HTA, is a lightweight hack in comparison. XPCOM works similarly to COM, but is available on any platform that has a Mozilla port. plXPCOM supports two-way communication - from any mozilla/gecko based application out to perl, and from perl out to any XPCOM component. This is powerful stuff. But the mailing list for plXPCOM is empty. I havn't heard anyone mention either xul or xpcom in the perl community. Python and Java already have bindings. In other words, lets get this thing made as Perl needs it (and maybe it needs perl). I cant program in C++ and dont know perl internals, spreading the word is the best i have to offer. I know there are people on these boards who are up to this, and could make this happen. time was, I could move my arms like a bird and...	[reply]
Re: there.is.only.xul by jonadab (Parson) on Mar 03, 2003 at 04:33 UTC
Popping up XUL content from Perl would indeed be cool, if the project were far enough along to be available via PPM (in ActiveState Perl) and CPAN (other platforms), and if installing that package (either the PPM or the CPAN package) would be adequate without separately installing other stuff. (Not that Mozilla isn't needed on every computer anyway, but that's a separate issue.) It's a very cool idea, certainly... But developing on it would mean working in heinous languages like C++, and I have no interest in doing that. A wrapper around existing modules, however, like I was talking about, could be done all in Perl, and while it would be a huge stretch for me (I have not yet written a module of any complexity in Perl...) and I couldn't do it alone and would probably end up with no more than a proof of concept before handing it off, it nevertheless interests me to some extent. `for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}` [download]	[reply] [d/l]
Re: Re: there.is.only.xul by Ctrl-z (Friar) on Mar 03, 2003 at 15:36 UTC
Popping up XUL content from Perl would indeed be cool, if the project were far enough along to be available via PPM and CPAN me thinks it would be more than cool ;) I understand what you are saying - my rant wasn't specifically directed at you, sorry! I am surprised and dissappointed that the perl community isn't all over this like a fat kid on skittles. A slick, efficient GUI, Cross language components and no XS - Mozilla's technologies are a godsend, especially for interpretted languages. time was, I could move my arms like a bird and...	[reply]
Re: use AnyGUI by bsb (Priest) on Mar 02, 2003 at 07:45 UTC
I think Mandrake's install system can use either text, curses or gtk. The file might be interface.pm. Then again...	[reply]
Re^2: use AnyGUI by Aristotle (Chancellor) on Mar 02, 2003 at 11:56 UTC
That is very likely going to be tailored quite closely to the needs of an installer, though. I don't know about Mandrake, but I've seen similar solutions elsewhere (Debian's DebConf f.ex), and they were very limited in scope. In that case they're also easy to implement, so no surprise there. Makeshifts last the longest.	[reply]
Re: use AnyGUI by adrianh (Chancellor) on Mar 07, 2003 at 11:03 UTC
As others have pointed out, this kind of cross-GUI system is hard to do right. Since nobody else has mentioned it I would take a look at Java's AWT & Swing APIs for an example of how one language has done it.	[reply]


Pathologically Eclectic Rubbish Lister
	PerlMonks