Re: workaround for generating gui tools
Hi, So, instead, with this new system (note I wasn't involved with the old system), I do everything with metadata. (Credit where credit is due, the other programmer was starting to do some of this, though he couldn't quite take it down to the interface and there are some things I had to add later.) Every thing (class) has a description of what it's made out of, and what type each of those things are. When I go to edit an instance, the Javascript pulls down that description, and a description of the instance (and all of its associated sub-instances), and instead *generates* a form to edit the object based on what it is made of. Ok. I can assure you that I've been doing that myself, and that this attitude describes my general approach to computers and programming: If the machine can be told to do tedious work for me, I'd rather tell her how to do it than do that work myself for the thousands time. I did this for a LDAP browser/editor once, nice thing. But - there is a big BUT here - if we're talking about GUIs, we inevitably enter the realm of taste and customization requirements. And that's the point where things get tricky: technically inclined people can be easily satisfied with simple and pureley functional interfaces. But even I as a strong FFF (form follows function) believer have to say: The form _does_ matter, once the function is in place. In my more complicated qt forms, I had to invest quite an amount of time to rearrange my controls in a way that (hopefully) communicated the purpose of the whole thing. These days the rollout will come and certainly some feedback will tell me that I still didn't do a perfect or even good job. But then I'll fire up my designer, and can rearrange things - without further bothering in the code. To me the importent lesson to learn is not to mingle layout with logic. And as layout follows its own rules (that techies sometimes have difficulties to grasp), one should be as flexible and powerful with layouting tools as it gets. How do I decide the order to create the fields? Classes carry a metadata field called order that lists the fields it wants in order, the remainder will by default be tacked on the end. What if I don't want a certain field to display? There's a metadata field that lists the ones we want to display for editing, there's another I can use to just filter a couple out if the first isn't present. What if I want a particular widget to do something special like be a certain width? I've created a metadata escape hatch that lets me pass parameters directly to the input node; it's bad style, but sometimes useful. Everything I use is backed by a database which has limited typing abilities, so I have a field called humantype that declares the human type of the data, so I can then create intelligent widgets for that, too. One of the things we can do, for instance, is create an image widget that specifies a URL for an image, and as validation, shows it there in the browser. We could also make it accept uploads. Then, just by labelling a field as an htmlImage, we get the image editor, no form redesign, no muss, no fuss. I'm not convinced that this is really a superiour way to go. I'm all with you in terms of form-validation, constraint checking and mapping to the persistence layer. I do all of this based on meta-information (or reflection, which is the same). But what you propose is that you create a style-annotation which in the end will grow until it becomes a unmanagable beast. Instead, I prefer to have the designer (this time the person doing the html templates, not the tool) make the decision if a text-property of my object becomes a simple input type='text' or a textarea - to me, both just contain and propagate strings. So I say: Use html (or qt xml gui description files) for what they are, and programming for the rest. Having said that, I can only emphasize again that I'm very well in favour of automation of tasks - and where my data-types have an inherant flexibility, I certainly prefer to generate editing forms (as e.g. zope does for zclasses) instead of having to write them on my on. But usually customization will be required, and then I'll have to deliver it. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Dave Cook wrote: On 2005-04-09, flupke [EMAIL PROTECTED] wrote: i create my GUIs mainly via wxGlade. However when you start of to program and want to do some rearranging to the gui, wxglade overwrites your file and you've got to put your own code back in. How about generating XRC files instead of Python? I admit I've never tried it with wxGlade, so I don't know how well it works, but with the original Glade one only uses XML, you can't generate Python at all. Dave Cook That sounds like a good idea. I'm going to check how i can load stuff from the resource file. Thanks for the tip Regards, Benedict Verheyen -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Apr 10, 2005 11:08 PM, Bengt Richter [EMAIL PROTECTED] wrote:
On Sat, 9 Apr 2005 19:22:16 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
open('mywidget_v2.txt','w').write(repr(mywidget.textview)
How about a pickle hook?
You'd just unpack the pickle data, and end up with a pointer to a
frame(?) containing all the goods, then just .pack() it into whatever
you want.
--
http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Mon, 11 Apr 2005 10:05:49 -0300, Gabriel B. [EMAIL PROTECTED] wrote:
On Apr 10, 2005 11:08 PM, Bengt Richter [EMAIL PROTECTED] wrote:
On Sat, 9 Apr 2005 19:22:16 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
open('mywidget_v2.txt','w').write(repr(mywidget.textview)
How about a pickle hook?
You'd just unpack the pickle data, and end up with a pointer to a
frame(?) containing all the goods, then just .pack() it into whatever
you want.
Pickle is one way to store a representation of something, but it isn't
programming-language-agnostic ;-)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Can you show me some working, in-use example for that? I _seriously_ doubt that the process of rearranging and tuning the layout can be done faster in the text-world than with a good designer like qt-designer. But I'm all ears for better solutions. BTW, when I talk of gui designers, I _only_ have them for creating guis - no attaching of event code or stuff like that (except from some trivial signal-slot-connections, that is) As a programmer, the only thing of interest to me are the certain widgets I need my logic to bind to. The structure of the thing itself I don't care about. Heck, switch 'em out dynamically based on what day of the week it is and how the user feels today. Let's see your GUI-designer do that. And if you're not used to doing it that way, you'll be *stunned* at how much stuff tends to factor out and get easily re-used. Well - stun me by example :) An approach that has more data to work with (some idea of what things are doing and what they are for) will beat an approach with less data (thing at row 4, col 2 or, worst case, thing at 233,144) any day. Hm. There certainly are cases where I take smaller building blocks and rearrange them according to my current needs - all in python of course. But that's only a comparably small part - at least to my current apps. It could grow depending on the type of application - e.g. database driven stuff - but so far, I'm pretty well with creating the larger dialogs/widgets in the designer and when the functionality is working, the rearranging of these widgets for better usability is pretty important and certainly easier done in the designer. To me the whole discussion is similar to generating html using python or using templates - templates need only to conform to a certain interface for the app writer to work. Sure, sometimes things get a little bit more tedious compared to just printing out html fragments. But the more control you want over the look of your results, the less powerful the generating approach becomes - because you simply lack the features to control the layout or you take deep steps into parameter hell - but then I see html as a domain specific language and prefer to use that to control the layout. I've seen such development in the java-world using struts, where people introduced their own tags for displaying data objects - over time, some of these grew 10 or more cryptic attributes for fine-controlling the layout. Instead of just providing the necessary data and letting jsp do the layout. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On 2005-04-09, flupke [EMAIL PROTECTED] wrote: i create my GUIs mainly via wxGlade. However when you start of to program and want to do some rearranging to the gui, wxglade overwrites your file and you've got to put your own code back in. How about generating XRC files instead of Python? I admit I've never tried it with wxGlade, so I don't know how well it works, but with the original Glade one only uses XML, you can't generate Python at all. Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sun, 10 Apr 2005 13:57:26 +0200, Diez B. Roggisch wrote: Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Can you show me some working, in-use example for that? I _seriously_ doubt that the process of rearranging and tuning the layout can be done faster in the text-world than with a good designer like qt-designer. But I'm all ears for better solutions. Regrettably, no. I have them but they are all unsharable, either because the real owner would consider them proprietary, or because they are an unreleased and at the moment unfinished product I can't give the code out for. But I can help some. Part of the problem is the incredible cognitive disconnect between the layout system of design and the system I'm advocating. You're looking at your designer and saying something like, well, if I want to re-order these two options, it's three drags, even less if there's an 'exchange' option, how can anything possibly be any easier? (At least, that's my guess.) But that is not where the advantage lies. One of the things I can't show you at the moment is actually written as a web application using Javascript and mod_perl. It's a bog-standard GUI app that edits databases, from the surface. SOP for the forms designer approach is to create a form for each thing that will be edited; in this case in HTML, but that's not particularly different and you can get form editors for that, too, if you try. But even now, we have at least 20 different types of things to edit, and the full power of databases is at play here; we have foreign keys that may have an arbitrary number of certain things (customers may have an arbitrary number of phone numbers, for instance; in practice of course you won't have 20, but they may have home, the may have home + work, the may have work + fax, etc.), and a customer's address may actually be in an Address table, rather than directly in their record. Add up all the little pieces and at the moment we've got around 100 different types of things that might need editing, many of which can have arbitrary links to other things. (Some of these 100 things are just link tables, SQL tables that link an ID in one table to an ID in another for many-to-many relationships and these will not directly be edited, but still there's a lot of things in play here.) We could try to create a form for each one, and in fact earlier versions of the system did just that. But that solution sucked, for all of the reasons I typically rant against these solutions; they rapidly got out of sync with the database schema, a bug fix in one was a bug fix in no others (copy and paste code tends to run rampant in this situation, though technically that's just a tendency, not a requirement), and any but the most critical enhancements are out of the question because they only affect a small part of the system. So, instead, with this new system (note I wasn't involved with the old system), I do everything with metadata. (Credit where credit is due, the other programmer was starting to do some of this, though he couldn't quite take it down to the interface and there are some things I had to add later.) Every thing (class) has a description of what it's made out of, and what type each of those things are. When I go to edit an instance, the Javascript pulls down that description, and a description of the instance (and all of its associated sub-instances), and instead *generates* a form to edit the object based on what it is made of. Right now, I'm emulating the old two col approach, labels on the left, values on the right, but I'll be changing that later. For now, though, that makes it easy (and like I said, as nice as forms are, having to do that many they bailed out and went with a standard design). And since I'm putting these things in by hand, I can also create custom widget types and use them. (For that, I'm using my XBLinJS library, so you can actually think of the HTML widgets as having capabilities much like Tkinter widgets, in that I can subclass from them and make them do domain-specific things just like Tk.) Integer value types get integer text boxes; these do not allow you to type anything but numbers. Floating point is the same way, but adds the . (although only one). All numeric fields do math within themselves, which is something that should have been standard for a decade now but programmers had to actually do something special in their forms to get it; I get it for the same price as anything else, once I wrote the code. (By that I mean, type 1+4 in and it will resolve itself to 5.) That's one of the reasons I rant about this; there is *so much* functionality like that that ought to be standard because done correctly it's trivial to plunk the right text widget subclass down if you're generating the screen, but form designers make this a lot of extra work.
Re: workaround for generating gui tools
Jeremy Bowers wrote: On Sun, 10 Apr 2005 13:57:26 +0200, Diez B. Roggisch wrote: Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Can you show me some working, in-use example for that? I _seriously_ doubt that the process of rearranging and tuning the layout can be done faster in the text-world than with a good designer like qt-designer. But I'm all ears for better solutions. Regrettably, no. I have them but they are all unsharable, either because the real owner would consider them proprietary, or because they are an unreleased and at the moment unfinished product I can't give the code out for. But I can help some. This guys gotta be a politician or english major or something! :) 155 lines, 1706 words, 9493 character reply, but his method is so simple he still can't show us an example! The original poster was just asking for an example of how to sub class his code generated form into his program for easy future updates, a VERY STANDARD way of doing it. I tried at first to follow this Great Way of doing it, but I guess I'm to simple minded, or just got to damed borded. Hey, that's just me. I guess I'll just be stuck zapping out forms with qt designer, the old fashion way. -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sun, 10 Apr 2005 13:02:27 -0700, Ken Godee wrote: The original poster was just asking for an example of how to sub class his code generated form into his program for easy future updates, a VERY STANDARD way of doing it. I recognize your sarcasm, and I recognize the poor attitude it shows, but underneath it you do have a point. Continuing the (still IMHO very good) OO vs. procedural metaphor, the problem is that posting a trivial example of a dynamic interface, even were I to take the time to create one for you for free, would meet with exactly the same response that posting an OO snippet of some reasonable newsgroup size would receive from someone skeptical of OO. Well, heck, I can do that all in a procedural program, and it would be a little shorter, too! I am *particularly* not inclined to post a trivial example because it would do nothing to blunt your skepticism, or your sarcasm, and regardless, people who are genuinely curious simply need to try it for themselves. The advantages only start kicking in with large programs. But I do recall a book with similar themes, though I do not endorse it whole-heartedly: Software Development On A Leash, which also gives you sample code for his particular framework. http://www.apress.com/book/bookDisplay.html?bID=29 My opinion of this book is like my opinion of XP: Every serious programmer ought to be exposed to the ideas contained in it (even if not by exposure to this book or the actual XP writings), and ought to give them serious thought, but 100% acceptance is not necessary. To address your sarcasm directly, there's 456 pages of examples in professionally written prose and real code samples, which I don't entirely agree with but they do serve to show the point, available for the price of $39.95. I consider my obligation to you discharged on this point; if you prefer sarcasm to investing anything into your personal development, that's your problem, not mine. (If this were a private email, I would have just deleted it, but the underlying criticisms, even if uncivilly phrased, bore answering.) Even though you probably won't adopt this guys framework, if you're paid anything at all for programming you'll recover the $40 in no time with the ideas in that book. -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sat, 9 Apr 2005 19:22:16 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
Reinhold Birkenfeld wrote:
It's evil anyway (for more complex applications) to put GUI construction
in your code. GUI should be described appropriately in data files.
why use data files when you have an extremely powerful programming
language in your toolbox? the advantage of building UI's in Python is
that you can quickly create domain specific UI languages, and use them
to generate the interfaces for you. UI editors may be useful for trivial
applications, but if you're doing complex stuff, you sure want domain-
specific abstractions. Python gives you that, XML files don't.
Suppose tkinter elements all had a standard python property called, say,
textview,
and for any given element in a GUI hierarchy, you could get and set and delete
this textview property, with suitable side effects. If you wrote python like
print mywidget.textview
You might see something like Delphi's representation of a nested panel widget
with a label, text entry slot, and button (excerpted from a full form
representation):
object Panel1: TPanel
Left = 400
Top = 160
Width = 185
Height = 113
TabOrder = 0
object Label2: TLabel
Left = 24
Top = 16
Width = 65
Height = 13
Caption = 'Example label'
end
object Edit1: TEdit
Left = 24
Top = 32
Width = 121
Height = 21
TabOrder = 0
Text = ' (example text entry)'
end
object Button1: TButton
Left = 24
Top = 64
Width = 121
Height = 25
Caption = 'Example Submit'
TabOrder = 1
end
end
(The parent form or GUI element specifies other things that are inherited (e.g.
fonts etc),
so those aren't part of the widget representation unless you have locally
edited those attributes one way or another, in which case they would show up)
(I might add a standard TEXTVIEW_VERSION = ... line as the first line of output
in case you wanted to save a design for later (perhaps much later) but Delphi
doesn't seem to).
Anyway, with a textview property you could write
open('mywidget_v2.txt','w').write(repr(mywidget.textview)
and if the textview property round-tripped, you could edit mywidget_v2.txt
with emacs or vim or a program, and then (just as an example) write
mywidget.textview = open('mywidget_v2.txt').read()
and see the changes. Creating or deleting mywidget would be modifying the
textview
of the parent, if you were doing it via textview, except that del
mywidget.textview
might effectively delete mywidget from the parent. Not sure what would be most
useful.
The textview is an alternate and fairly programming-language-agnostic
representation
of a GUI design element. Obviously it would not be much of a transformation to
convert
to nested python dict representation for the above (and for a python interface
to tkinter
that might be better than text). It would not surprise me to find that someone
has
done a tkinter walker (maybe it's built into tkinter, I haven't dug) that does
something
like this for the read view, but I wonder about the round trip replacement
write.
Anyway, I think this kind of programming-language-agnostic representation may
be what
Reinhold is getting at, and the evil being
non-programming-language-agnosticism
in GUI design representation (though textview representation syntax would be a
language syntax too ;-)
Using Delphi's conventions might permit interesting interchange with the Delphi
world, and I know
there is some Delphi/Python synergy being pursued, though I haven't looked into
it, so I'd bet
there is python code somewhere translating between Delphi and tkinter. I just
thought of this
textview property to help make my take on Reinhold's post clear, but I could
see it making
GUI design interchange in general easier to have a standard representation for
that purpose.
XML is too crufty for my taste, but the idea of a very broadly applicable
definition of
useful pure abstractions with standard concrete representations appeals to me
(I know of ASN ;-)
IMO XML has gotten a place in the world because it works well enough that people
who want to get other work done can't wait for it to be replaced with something
better,
not because it's the best thing. Sort of like how MSDOS got its place in the
world.
Alternatively, GUI elements could have registrable encode/decode methods with
some kind of UniGUIcode abstract core ;-) I kind of like that, off hand...
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
workaround for generating gui tools
Hi, i create my GUIs mainly via wxGlade. However when you start of to program and want to do some rearranging to the gui, wxglade overwrites your file and you've got to put your own code back in. I think i can work around that (at least a bit) by making a second file that imports the gui generated by wxglade and make classes that extend the original ones. For instance i could have a class MainForm that extends the wxFrame class that wxGlade produces. Are there other clever ways to work around this problem? Thanks, Benedict -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Benedict, Best to hand-code your code ;-) -- even GUI. This is kind of why I like Tkinter so much. Good luck. Harlin Seritt -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Harlin Seritt wrote: Benedict, Best to hand-code your code ;-) -- even GUI. This is kind of why I like Tkinter so much. Good luck. Have to disagree strongly. It's evil anyway (for more complex applications) to put GUI construction in your code. GUI should be described appropriately in data files. Glade does this very good, and with pygtk it's no problem to use the XML files. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Reinhold Birkenfeld wrote: It's evil anyway (for more complex applications) to put GUI construction in your code. GUI should be described appropriately in data files. why use data files when you have an extremely powerful programming language in your toolbox? the advantage of building UI's in Python is that you can quickly create domain specific UI languages, and use them to generate the interfaces for you. UI editors may be useful for trivial applications, but if you're doing complex stuff, you sure want domain- specific abstractions. Python gives you that, XML files don't. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
why use data files when you have an extremely powerful programming language in your toolbox? the advantage of building UI's in Python is that you can quickly create domain specific UI languages, and use them to generate the interfaces for you. UI editors may be useful for trivial applications, but if you're doing complex stuff, you sure want domain- specific abstractions. Python gives you that, XML files don't. If you do some creative rearranging of widgets and play around with different layouts and geometry managers, a good gui-designer becomes very useful. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sat, 09 Apr 2005 19:59:18 +0200, Diez B. Roggisch wrote: why use data files when you have an extremely powerful programming language in your toolbox? the advantage of building UI's in Python is that you can quickly create domain specific UI languages, and use them to generate the interfaces for you. UI editors may be useful for trivial applications, but if you're doing complex stuff, you sure want domain- specific abstractions. Python gives you that, XML files don't. If you do some creative rearranging of widgets and play around with different layouts and geometry managers, a good gui-designer becomes very useful. Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Heck, switch 'em out dynamically based on what day of the week it is and how the user feels today. Let's see your GUI-designer do that. And if you're not used to doing it that way, you'll be *stunned* at how much stuff tends to factor out and get easily re-used. An approach that has more data to work with (some idea of what things are doing and what they are for) will beat an approach with less data (thing at row 4, col 2 or, worst case, thing at 233,144) any day. GUI designers are like the regexs in the famous jwz quote: Some people, when confronted with a problem, think 'I know, I'll use a GUI designer'. Now they have two problems. Both have a niche in the quick fix department, both are typically over-used, but overall regexs are the more useful of the two; at least there are cases where they are the undisputed right answer (like defining tokens in a language parser). Generally, over the first couple of weeks of a project, the domain-specific language writer may seem to be behind the GUI designer cranking out screen after screen of templated GUI widgets, but after a couple of weeks the domain-specific language user will pull into the lead and never give it up, and will be a lot happier to boot. -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
Jeremy Bowers wrote: snip Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Heck, switch 'em out dynamically based on what day of the week it is and how the user feels today. Let's see your GUI-designer do that. And if you're not used to doing it that way, you'll be *stunned* at how much stuff tends to factor out and get easily re-used. An approach that has more data to work with (some idea of what things are doing and what they are for) will beat an approach with less data (thing at row 4, col 2 or, worst case, thing at 233,144) any day. GUI designers are like the regexs in the famous jwz quote: Some people, when confronted with a problem, think 'I know, I'll use a GUI designer'. Now they have two problems. Both have a niche in the quick fix department, both are typically over-used, but overall regexs are the more useful of the two; at least there are cases where they are the undisputed right answer (like defining tokens in a language parser). Generally, over the first couple of weeks of a project, the domain-specific language writer may seem to be behind the GUI designer cranking out screen after screen of templated GUI widgets, but after a couple of weeks the domain-specific language user will pull into the lead and never give it up, and will be a lot happier to boot. First time i hear about domain-specific abstractions. Do you mean that instead of using a GUI designer, you make some sort of engine that constructs a gui for you? One thing i find repetitive to do is designing gui's that are just simple views on a database tables where one can create,edit and delete records. If one could construct a gui dynamically for these types of things, that would be great. Benedict -- http://mail.python.org/mailman/listinfo/python-list
