Menu
▾
▴
wxperl-users
|
From: Bob H. <cat...@ya...> - 2007-03-01 18:15:54
|
... an alternative to hand coding would be one that I have long wanted to have, but were afraid to ask, that is, to make a clear cut between the GUI and the actual routines, and use an Interface Builder to design the GUI with ease, provided the I.B. generates perl/wx code. If you have references on how to do this, it would be wonderful to have them. Bob ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ |
|
From: Bob H. <cat...@ya...> - 2007-03-05 20:12:17
|
I think I've been here before, however... wxGlade would be a very nice tool, if only it would stop crashing. wxDesigner, on the other hand, is a tool for sado-maso; it does not show the complete GUI, like wxGlade or Apple's Interface Builder, and this is a major limitation on usability, which is not what one expects from a GUI builder... Apple's Interface Builder seems locked on its perfect world, and I could not find any way extension or converter (so far). Other tools are either worse on usability, or available for platforms other than OSX. Can I pick your brains again? I need something like wxGlade, but stable! Bob ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
|
From: Daniell F. <win...@gm...> - 2007-03-05 21:11:10
|
I here you Bob. I have had the very same dilemma. I've used wxDesigner and while it can get the job done, it doesn't function like any other GUI designer I've used, and I have the same crashing problems with wxGlade. Despite the unstable nature of wxGlade, it still does a better job, by far, than wxDesigner (and I've even paid for wxDesigner). I just make it a habit to save after every major change I make. I don't think there is any alternative for OSX beyond those two, at lease not for Wx. Thanks, Dan Freed On Mar 5, 2007, at 2:12 PM, Bob Hunter wrote: > I think I've been here before, however... > > wxGlade would be a very nice tool, if only it would > stop crashing. wxDesigner, on the other hand, is a > tool for sado-maso; it does not show the complete GUI, > like wxGlade or Apple's Interface Builder, and this is > a major limitation on usability, which is not what one > expects from a GUI builder... Apple's Interface > Builder seems locked on its perfect world, and I could > not find any way extension or converter (so far). > Other tools are either worse on usability, or > available for platforms other than OSX. Can I pick > your brains again? I need something like wxGlade, but > stable! > > > Bob > > > > > ______________________________________________________________________ > ______________ > Expecting? Get great news right away with email Auto-Check. > Try the Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > wxperl-users mailing list > wxp...@li... > https://lists.sourceforge.net/lists/listinfo/wxperl-users Daniell Freed win...@gm... Bereshit bara Elohim et hashamayim ve'et ha'arets... |
|
From: Bob H. <cat...@ya...> - 2007-03-05 21:50:06
|
I'v just had a hell of a roundtrip. I thought that the reason for wxGlade crashing so much (to a point that it just keeps crashing with no opportunity to save any work in between) is that it needs updates. So I read from the home page that wxGlade requires wxPython, which in turn requires an updated version of python. So on my OS 10.4.8 with python 2.3.5 I had to install python 2.5 (100MB+) and wxPython 2.8 on top of it (100MB+). Then I fire wxGlade with pythonw2.5 ~/Applications/se/wxGlade-0.4.1/wxglade.py & only to have the following warning: --> /Applications/se/wxGlade-0.4.1/main.py:9: DeprecationWarning: The wxPython compatibility package is no longer automatically generated or activly maintained. Please switch to the wx package as soon as possible. from wxPython.wx import * ... ARGH! Did I miss something? wxGlade's home page at http://wxglade.sourceforge.net/ clearly says that it is written in Python and wxPython, and there is no mention to the above news. So, now I have to uninstall wxPython, in replacement of what, exactly? Oh... The positive side is, that wxGlade is more stable. It does not crash as it used to. However, it became chatty, and fills the console with error messages about wxGlade's own bugs. Bob ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news |
|
From: Bob H. <cat...@ya...> - 2007-03-05 21:53:40
|
I forgot, one thing. If I uninstall wxPython, then
call wxGlade, I get the following:
--> python2.5
/Applications/se/wxGlade-0.4.1/wxglade.py
Traceback (most recent call last):
File
"/Users/sb/Applications/se/wxGlade-0.4.1/wxglade.py",
line 148, in <module>
run_main()
File
"/Users/sb/Applications/se/wxGlade-0.4.1/wxglade.py",
line 135, in run_main
import main
File
"/Users/sb/Applications/se/wxGlade-0.4.1/main.py",
line 9, in <module>
from wxPython.wx import *
ImportError: No module named wxPython.wx
Which means that wxGlade still depends on wxPython
after all.
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
|
|
From: Eric W. <scr...@gm...> - 2007-03-05 22:17:20
|
# from Bob Hunter
# on Monday 05 March 2007 01:53 pm:
>Which means that wxGlade still depends on wxPython
>after all.
I think the warning was trying to tell you that wxGlade is using the
wxPython code, which apparently is now a compatibility wrapper around
what is now called "wx". FWIW, wxGlade's Perl output and various other
issues are so bad that I've gone to hand-written layout code and have
been sleeping much better ever since.
--Eric
--
"Left to themselves, things tend to go from bad to worse."
--Murphy's Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
|
|
From: Bob H. <cat...@ya...> - 2007-03-05 22:48:32
|
I'm so close to scream like an awk to this python... ...and stick to Tk. Why is that Perl/Wx must be so cumbersome? Perl/Tk is so easy to manage by hand, by comparison. After all, we are talking about Perl/Wx, which everyone assumed it to have the same coding ease of Perl/Tk. Why is that Perl/Wx is so cumbersome? Who cares about all those details? Why can't Perl/Wx be as easy as Perl/Tk? Can't you make an effort to hide the complexity, and deliver an API that is similar, whether not identical to Perl/Tk? Bob ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com |
|
From: John R. <jr...@ce...> - 2007-03-06 04:53:45
|
On Mar 5, 2007, at 2:48 PM, Bob Hunter wrote: > > I'm so close to scream like an awk to this python... > > ...and stick to Tk. Why is that Perl/Wx must be so > cumbersome? Perl/Tk is so easy to manage by hand, by > comparison. After all, we are talking about Perl/Wx, > which everyone assumed it to have the same coding ease > of Perl/Tk. Why is that Perl/Wx is so cumbersome? Who > cares about all those details? Why can't Perl/Wx be as > easy as Perl/Tk? Can't you make an effort to hide the > complexity, and deliver an API that is similar, > whether not identical to Perl/Tk? > > Bob I think that you misunderstand both wxWidgets and wxPerl. wxPerl is a wrapper around (most of) wxWidgets. It is not particularly perlish, and it is most definitely not like Perl/Tk, because wxWidgets isn't like Tk. wxWidgets in turn wraps various platform GUI frameworks -- Carbon or Cocoa for OSX, GTK (and not as well developed, Motif) for X11, Win32, Wince, PalmOS, and others. It also provides a common API to some of the underlying OS services, like sockets, and fills in holes in some areas like regular expressions. It's a C++ library, for which wrappers in other languages are available, including wxPerl and wxPython. wxWidgets is emphatically *not* intended to do what Tk does: Provide a quick-and-dirty graphical front end to quick-and-dirty "scripts". It *is* a full-featured framework for developing full-featured applications. Only you can decide which is the more appropriate tool for your use. Regards, John Ralls |
|
From: Eriam S. <er...@er...> - 2007-03-06 08:01:56
|
> > Only you can decide which is the more appropriate tool for your use. > It is very clear and totally right. Also I suggest that you take a look at visualWx (which is for windows I know but you can eventually have a windows box and give it a try ..). That one is IMHO the best one (despite not free etc). You can for instance place controls without sizers (x and y) which is good for fixed size frames like Wizards and so on. I've not found this feature already in other gui ide but maybe I didnt looked in the correct direction. I would also say the price of the effort is worth it. Thanks Eriam |
|
From: Bob H. <cat...@ya...> - 2007-03-06 08:44:22
|
I understand that wxWidgets is a very complex meta-library for local graphic libraries, but why would anyone be bothered with so many details? tkPerl could be just as cumbersone as wxPerl, but is not. I still think that a perl interface to wxWidgets, wxPerl that is, could be more perlish, easier that is. The complexity of the underlying library needs not to show up in the API. No one could fly an airplane with two arms if the interface would be closer to the hardware than to the human. My programs are intellectually manageable because I make an effor in that direction, including using PERL instead of JAVA, for example. I was perfectly happy with tkPerl's API, but had the well known limitations of a tk interface. Can't we have an easier API for wxPerl? I think we can. One approach would be to retain the API of tkPerl, or possibly have a simpler one, and move additional detail to a separate file, if any are needed, with no need to struggle with unintuitive interface builders and our code, going mad in between. Perhaps I will get used to it, but I cannot believe I have to give up PERL's philosophy when programming in PERL. "The computer languages taught in schools and used in industry, from Fortran and Pascal to C and C++, all share in common the mis-feature of forcing programmers to worry about all kinds of things that get in the way of expressing what they're trying to do. [...] We need to optimize both computer time and human time, but when push comes to shove, computer time is getting cheaper, and human time is (we hope) getting more valuable. The person has to come first." [Larry Wall, The Origin of the Camel Lot in the Breakdown of the Bilingual Unix, Communications of the ACM, 42(4):40-41, 1999.] ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ |
|
From: Eric W. <scr...@gm...> - 2007-03-06 09:38:48
|
# from Bob Hunter # on Tuesday 06 March 2007 12:44 am: >Can't we >have an easier API for wxPerl? I think we can. I think so too. I believe tkPerl has had a bit more time (8 years?) and maybe a few more developers. If you're impatient, the standard procedure is to send large bundles of money or small bundles of code. Rants don't compile, sorry. >One approach would be to retain the API of tkPerl, That seems very doubtful. Besides being very different, Wx is quite a bit more flexible than Tk. >possibly have a simpler one, and move additional >detail to a separate file, if any are needed, I've toyed with some DWIM stuff in the dotreader repository, but haven't been particularly happy with the loss of control that inevitably leads to. DWIM not always being DWYM, etc. However, I have identified a few areas where I think we could get some shorter code, such as in using the object as the constructor for its child widgets: my $thingy = $self->newThingy(...); vs my $thingy = Wx::Thingy->new($self, -1, ...); Though named (not positional) parameters and *reasonable* defaults would certainly help. There are a few other things and observations, like that Wx->can should mirror the AUTOLOAD, a huge pile of shortcuts, yaml-driven menus, etc. Some of these ideas have been written and some haven't. Nevertheless, the code is all completely visible at svn.dotreader.com. >with no >need to struggle with unintuitive interface builders >and our code, going mad in between. What interface builder are you using for Tk? >Perhaps I will get >used to it, but I cannot believe I have to give up >PERL's philosophy when programming in PERL. Perl's philosophy is that you write Perl. The trouble with wxPerl is that it is very nearly a straight-port of the C++ Wx, which is no small effort, but is bound to be far from a perlish API. So, you can either wrap it and provide some mixins, traits, etc that make it more perlish, or you can try to redo the binding code to handle 20-odd cases of hash values in XS. Keep in mind that you're talking about a redesign of the API. That's no small task and it is not easily done well. --Eric -- Peer's Law: The solution to the problem changes the problem. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- |
|
From: Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...> - 2007-03-06 09:38:36
|
> I understand that wxWidgets is a very complex > meta-library for local graphic libraries, but why > would anyone be bothered with so many details? tkPerl OTOH, why would someone (me!) already knowing wxWidgets, bother to write _and_ docuemnt a different interface. For users? Good point, but I when? > could be just as cumbersone as wxPerl, but is not. I > still think that a perl interface to wxWidgets, wxPerl > that is, could be more perlish, easier that is. The I agree. The answer is not necessarily a Tk-ish interface (which would be nevertheless good for compatibility). > cheaper, and human time is (we hope) getting more > valuable. The person has to come first." [Larry Wall] ...and mine is limited... if anybody feels like writing Wx::Perl::Tk (or whatever), please feel free to do so. Regards Mattia =0A=0A=0A------------------------------------------------------=0ACon Pro= meteo prestiti senza spese fino a 31.000 Euro!=0Ahttp://click.libero.it/w= ebnation06marz07=0A |
|
From: Bob H. <cat...@ya...> - 2007-03-06 16:44:04
|
Mattia, your message is already an important step forward. At least you acknowledge that wxPerl can be improved from that point of view, and are open to change/improvement. Given that time is limited for everyone, the best approach to proceed is to post a general "call for contributions", and leverage from the open source community. Design ideas are valuable as much as, if not more than, specific code, because they can save a lot of coding. To make the first two contributions, these are two ideas. The first is to talk to the developers of tkPerl and ask them whether they want to merge with wxPerl. It might sound odd at first, to both the tkPerl and wxPerl communities, but read on. The first aim would be to *design* the same API for both projects. This API has to be consistent with PERL's philosophy, profit from the existent API of tkPerl and allow for wxPerl's enhanced features. When people have debated at length on design, and everybody is happy about the final resolution, then it is coding time for both communities. The tkPerl community would have (a) an improved API, (b) a means to port applications from tk to wx with minimal effort, and (b) stay with a tk interface if they like (wx can interface to gtk, cocoa, etc., and thus also with tk). The wxPerl community would finally have an API that is consistent with PERL's philosophy. The second idea is a tiny little one, and arises from a simple problem that I encountered today on tk/Perl.---I moved the mouse around the application, and noted that different parts of the GUI highlight differently and with different colors. I also noted that different text areas have different background colors. I spent two hours to fix a number of them, in detail, coding in. An idea that saved time was the following: 1. define a general color for the background and the highlight, at the beginning of the code, say: my $bg_text = "#efefef"; my $bg_texth = "#adbcd6"; 2. state the following in the option area of relevant widgets: -background => $bg_text, -highlightcolor => $bg_texth, -highlightbackground => $bg_text, The result is that those widgets now have consistent look and feel. The problem is, that I still have to specify this detail for each relevant widget, coding by hand. And I am lucky I do not have to do that with an Interface Builder, clicking around hundreds of time on various panels. Now, the idea is to specify this consistent behaviour only one time. The question is where? I propose to gather all such customizations in a separate "policy" file, so that, if you have k entries you just write the policy once. Regards, Bob ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ |
|
From: Daniell F. <win...@gm...> - 2007-03-06 16:55:10
|
While I am not a detractor of new projects, I think a project such as this should be an different beast than wxPerl. It should be a compatibility layer of sorts for wxPerl and Perk/tk. I for one like the way wxPerl currently works (i.e. just like the C++ version and python version). I loath the thought of having to change all of my code to some new API because we wanted to dumb it down a bit (and I mean no disrespect by that). I'm all for having a way to create quick and dirty GUI's using wxPerl, but that isn't always the appropriate way to do things. wxPerl as it stands (and as others have already said) is a very complete GUI API that has a lot of power. Yes there is some complexity to using it, but once you learn to code using it, it isn't any worse than any other API. Just my 2 cents worth. Thanks, Dan Freed On Mar 6, 2007, at 10:43 AM, Bob Hunter wrote: > Mattia, your message is already an important step > forward. At least you acknowledge that wxPerl can be > improved from that point of view, and are open to > change/improvement. Given that time is limited for > everyone, the best approach to proceed is to post a > general "call for contributions", and leverage from > the open source community. Design ideas are valuable > as much as, if not more than, specific code, because > they can save a lot of coding. > > To make the first two contributions, these are two > ideas. > > The first is to talk to the developers of tkPerl and > ask them whether they want to merge with wxPerl. It > might sound odd at first, to both the tkPerl and > wxPerl communities, but read on. The first aim would > be to *design* the same API for both projects. This > API has to be consistent with PERL's philosophy, > profit from the existent API of tkPerl and allow for > wxPerl's enhanced features. When people have debated > at length on design, and everybody is happy about the > final resolution, then it is coding time for both > communities. The tkPerl community would have (a) an > improved API, (b) a means to port applications from tk > to wx with minimal effort, and (b) stay with a tk > interface if they like (wx can interface to gtk, > cocoa, etc., and thus also with tk). The wxPerl > community would finally have an API that is consistent > with PERL's philosophy. > > The second idea is a tiny little one, and arises from > a simple problem that I encountered today on > tk/Perl.---I moved the mouse around the application, > and noted that different parts of the GUI highlight > differently and with different colors. I also noted > that different text areas have different background > colors. I spent two hours to fix a number of them, in > detail, coding in. An idea that saved time was the > following: > > 1. define a general color for the background and the > highlight, at the beginning of the code, say: > > my $bg_text = "#efefef"; > my $bg_texth = "#adbcd6"; > > 2. state the following in the option area of relevant > widgets: > > -background => $bg_text, > -highlightcolor => $bg_texth, > -highlightbackground => $bg_text, > > The result is that those widgets now have consistent > look and feel. The problem is, that I still have to > specify this detail for each relevant widget, coding > by hand. And I am lucky I do not have to do that with > an Interface Builder, clicking around hundreds of > time on various panels. Now, the idea is to specify > this consistent behaviour only one time. The question > is where? I propose to gather all such customizations > in a separate "policy" file, so that, if you have k > entries you just write the policy once. > > Regards, > Bob > > > > > ______________________________________________________________________ > ______________ > TV dinner still cooling? > Check out "Tonight's Picks" on Yahoo! TV. > http://tv.yahoo.com/ > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > wxperl-users mailing list > wxp...@li... > https://lists.sourceforge.net/lists/listinfo/wxperl-users Daniell Freed win...@gm... Bereshit bara Elohim et hashamayim ve'et ha'arets... |
|
From: Bob H. <cat...@ya...> - 2007-03-06 17:30:37
|
"While I am not a detractor of new projects, I think a project such as this should be an different beast than wxPerl. It should be a compatibility layer of sorts for wxPerl and Perk/tk." I like it. The API of wxPerl could stay as it is, and then one could have a layer built on top of wxPerl that has an API which is very similar or possibly better than that of tkPerl. In this way, wxPerl's existent users would not have to rewrite their legacy code, and wxPerl would gain popularity among the tkPerl users (I am one of them). Three cheers for Daniell! Bravo. Bob ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ |
|
From: Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...> - 2007-03-07 07:54:57
|
> Dan Freed wrote: > While I am not a detractor of new projects, I think a project such as = > this should be an different beast than wxPerl. It should be a > compatibility layer of sorts for wxPerl and Perk/tk. I completely agree (that's why I proposed something like Wx::Perl::Tk for this). > On Mar 6, 2007, at 10:43 AM, Bob Hunter wrote: > > > Mattia, your message is already an important step > > forward. At least you acknowledge that wxPerl can be > > improved from that point of view, and are open to > > change/improvement. Given that time is limited for > > everyone, the best approach to proceed is to post a > > general "call for contributions", and leverage from > > the open source community. Design ideas are valuable > > as much as, if not more than, specific code, because > > they can save a lot of coding. I believe you are a bit over-optimistic: I expect there will be a loto of people wanting to _use_ this compatibility layer, but not many (IOW, none...) that want to actually code it. I don't know if I am being cynical or have just been an OSS developer for too much time... Best regards, Mattia =0A=0A=0A------------------------------------------------------=0ALeggi G= RATIS le tue mail con il telefonino i-mode=99 di Wind=0Ahttp://i-mode.win= d.it=0A |
|
From: Bob H. <cat...@ya...> - 2007-03-07 18:27:00
|
Mattia, I do not know wxPerl, so I cannot code in it. In my last mail I mentioned tk::ApplicationNest http://search.cpan.org/dist/Tk-ApplicationNest/ I can do better myself with tk, but I think it would be a good starting point to approach wxPerl. Someone that knows wxPerl could write a similar module for us. The task does not involve writing a whole API interface, nor the API for wxPerl itself; it is only a super-widget for the main window, with a menubar, a taskbar, and a statusbar. Served with an example would be even more useful, say, with a movable splitframe, a listbox on the left and a notebook on the right. It would be a very good framework to get started. With one such framework, well coded by someone who knows wxPerl, many tkPerl users would be able to get started properly and quickly, playing with it, customizing it, adding objects, etc. I understand that one can do something more complex with a proprietary interface builder running on windows, but everybody else (osx,linux,bsd,...) who codes by hand would just be happy with minimal GUI code a' la tkPerl, with a clear and minimal interface where to attach one's data to the GUI. There is a gap, but someone from the wxPerl community has to go the extra mile to attract more users. I think that a "tk::ApplicationNest" for wxPerl would be enough of a bridge. Do you know of a good fellow who would agree to do it? :-) Regards, Bob ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ |
|
From: Bob H. <cat...@ya...> - 2007-03-17 20:44:55
|
I spent the whole day reading and experimenting with wxPerl. I think I have a grasp of the most elementary parts, but got stuck when adding the menu bar and its items. I went back to wxGlade, only to find that the code it generates is both old and bugged. Further, a tutorial makes it clear that wxGlade overwrites the code, so we cannot change it by hand. Thus, if we must use a GUI builder (because writing by hand from scratch is just insane), and cannot change the code by hand (because the builder overwrites it), why bothering at all about having perl code for the main GUI inside our scripts? Why bothering with wxPerl/wxPython etc in the first pace, if we could do otherwise? The idea is this: wxGlade generates the XML description of the GUI, then we "use" an interface to this description, that is, we use a module that reads the XML file and generates a list of all the variables we can use to fill the GUI with data and events. The script, as a result, would be smaller than using tk. Do I make sense? ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 |
|
From: Eric W. <scr...@gm...> - 2007-03-17 21:03:21
|
# from Bob Hunter # on Saturday 17 March 2007 01:44 pm: >but got stuck when adding the menu bar and its >items. I went back to wxGlade, only to find that the >code it generates is both old and bugged. Further, a >tutorial makes it clear that wxGlade overwrites the >code, so we cannot change it by hand. Imagine that! And here everyone else says it's good enough, so it must be, right? The solution that I chose involves storing the menu declaration in YAML, though the caller loads the YAML and passes a data-structure to the API. It's still preliminary and obviously not for everyone, but hey it's not a one-way street that starts in python and drops your menu items on the floor. http://svn.dotreader.com/svn/dotreader/trunk/lib/WxPerl/MenuMaker.pm http://svn.dotreader.com/svn/dotreader/trunk/lib/dtRdr/GUI/Wx/Frame.pm http://svn.dotreader.com/svn/dotreader/trunk/client/data/menu.conf --Eric -- "...our schools have been scientifically designed to prevent overeducation from happening." --William Troy Harris --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- |
|
From: Peter G. <pe...@pg...> - 2007-03-17 21:54:11
|
DialogBlocks is a Gui Builder, produces XXL code which can be loaded by Perl. So I don't really understand this thread. On Sat, 2007-03-17 at 14:03 -0700, Eric Wilhelm wrote: > # from Bob Hunter > # on Saturday 17 March 2007 01:44 pm: > > >but got stuck when adding the menu bar and its > >items. I went back to wxGlade, only to find that the > >code it generates is both old and bugged. Further, a > >tutorial makes it clear that wxGlade overwrites the > >code, so we cannot change it by hand. > > Imagine that! And here everyone else says it's good enough, so it must > be, right? > > The solution that I chose involves storing the menu declaration in YAML, > though the caller loads the YAML and passes a data-structure to the > API. It's still preliminary and obviously not for everyone, but hey > it's not a one-way street that starts in python and drops your menu > items on the floor. > > http://svn.dotreader.com/svn/dotreader/trunk/lib/WxPerl/MenuMaker.pm > http://svn.dotreader.com/svn/dotreader/trunk/lib/dtRdr/GUI/Wx/Frame.pm > http://svn.dotreader.com/svn/dotreader/trunk/client/data/menu.conf > > --Eric |
|
From: Eric W. <scr...@gm...> - 2007-03-17 22:05:59
|
# from Peter Gordon
# on Saturday 17 March 2007 02:53 pm:
>DialogBlocks is a Gui Builder, produces XXL code which can be loaded
> by Perl.
What's XXL?
--
Consumers want choice, consumers want openness.
--Rob Glaser
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
|
|
From: Johan V. <jvr...@sq...> - 2007-03-18 12:24:52
|
Bob Hunter <cat...@ya...> writes: > I went back to wxGlade, only to find that the code it generates is > both old and bugged. FUD. I'm looking forward to your bug reports. > Further, a tutorial makes it clear that wxGlade overwrites the code, > so we cannot change it by hand. More FUD. As with many tools it takes a couple of minuted to get the hang of it. I use wxGlade on a daily basis. It works, generates good code, code that works, and never overwrites my code. And saves me hours of boring programming. > [...] wxGlade generates the XML description of the GUI, then we > "use" an interface to this description, that is, we use a module > that reads the XML file and generates a list of all the variables we > can use to fill the GUI with data and events. Sounds like XRC all over again. -- Johan |
|
From: Bob H. <cat...@ya...> - 2007-03-19 08:00:40
|
Following my last message, I spotted that it is indeed possible to do what I wanted, but I still miss the docs. This is all I managed to find on the topic: http://www.arcknowledge.com/gmane.comp.lang.perl.wxperl/2004-07/msg00017.html (which says that it is possible, but does not explain how) http://www.arcknowledge.com/gmane.comp.lang.perl.wxperl/2006-01/msg00084.html (which is informative) http://www.arcknowledge.com/gmane.comp.lang.perl.wxperl/2006-01/msg00074.html (a link) http://wxperl.pvoice.org/kwiki/index.cgi?SubclassingXRC (the linked page, which includes a broken link to the file Demo/XRCCustom.pl, so we can't read it; it also mentions two messages in the list, but does not link to them, so we do not know what they are.) And (rolls of drums please) the uninformative perldoc, which I quote in full, noting that it is a perldoc for wxPerl on a mac... Library::Perl::5.8.6::ULibrary::Perl::5.8.6::darwin-thread-multi-2level::Wx(3) NAME Wx - interface to the wxWidgets cross-platform GUI toolkit SYNOPSIS use Wx; my $app = Wx::SimpleApp->new; my $frame = Wx::Frame->new( undef, -1, 'Hello, world!' ); $frame->Show; $app->MainLoop; DESCRIPTION The Wx module is a wrapper for the wxWidgets (formerly known as wxWindows) GUI toolkit. This module comes with extensive documentation in HTML format; you can download it from http://wxperl.sourceforge.net/ INSTALLATION Please see docs/INSTALL.pod in source package. Windows XP look <--------------????? For standalone (packed using PAR, Perl2Exe, Perl2App, ...) applications to get Windows XP look, a file named "App.exe.manifest" (assuming the program is named "App.exe") and containing the text below must be placed in the same directory as the executable file. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0 "> <assemblyIdentity processorArchitecture="x86" version="5.1.0.0" type="win32" name="Controls" /> <description>Super wxPerl Application</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="x86" /> </dependentAssembly> </dependency> </assembly> AUTHOR Mattia Barbon <mb...@cp...> LICENSE This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.8.6 Library::Perl::5.8.6::darwin-thread-multi-2level::Wx(3) (END) So, it is possible to use XRC files, but the official docs do not have a chapter devoted to it. I am collecting information on this, so please reply to this message with everything you know/have on the topic. The purpose is to gather enough information to add a chapter to the wxPerl wiki site, or, even better, to have a dedicated perldoc in the next release of wxPerl. Finally. Last week I was stressing out, so I might have been an ... ass royal (read it as a French would, for greater laughter). I apologise if I hitted your nerves. wxPerl is a royal work, it just needs better docs, I think. Bob ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ |
|
From: Bob H. <cat...@ya...> - 2007-03-19 08:13:49
|
Further on the previous message. The page http://wxperl.pvoice.org/kwiki/index.cgi?SubclassingXRC mentions use Wx; use base "Wx::XmlSubclassFactory"; However, there is no perldoc for "Wx::XmlSubclassFactory", and CPAN says... Warning: Cannot get Wx::XmlSubclassFactory, don't know what it is. Try the command i /Wx::XmlSubclassFactory/ to find objects with matching identifiers. cpan[2]> i /Wx::XmlSubclassFactory/ No objects found of any type for argument /Wx::XmlSubclassFactory/ Un bordel royal... ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
|
From: Bob H. <cat...@ya...> - 2007-03-19 08:21:21
|
... I foresee someone would reply that there is plenty of documentation. Indeed, I would reply, wxWindows and wxPython have it, but the former is a 700+pages book for for c++ and the latter is all for python. I do not need a PhD to port a tkPerl application into wxPerl, do I? I think it must be possible to have a short paper, possibly a perldoc, that guides you step-by-step, following the perl philosophy. (Am I stressing out again? Oh....) Bob ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front |
Thanks for helping keep SourceForge clean.
X