On Thu, Jun 10, 2004 at 16:42:41 +0200, Thierry Vignaud wrote:
Jan Hudec <bulb ucw cz> writes:As for your second question, I think that using Glade is the only way to go. Others will disagree with me. But using Glade means that you've got more time for actual coding, and also that modifications are much easier - especially when you're building complicated forms, and *especially* if someone else has to modify your creation.maybe do one save some time when prototyping a GUI, but when you'd to change sg, you'll have to change it everywhere whereas with real code, you can factorize common stuff (compare with HTML+CSS or LaTeX against HTML as found in most web pages) thus you eventually loose time while maintaining your application and it may be error prone (eg: one forget to update a place).Yes, it might be a problem, sometimes. The key to this is full use of possibilities glade allows. I especialy mean binding signal handlers and also custom naming of widgets. That way layout changes don't need to touch perl code and functionality changes do not need to touch the glade file (no, I never use the default handler names -- the handler name should be derived from what it does and not what widget it is bound to).you still have to change layout everywhere when eg you switch from old frame to new HIG blocks with bold title and left border in the logical block.
Oh, of course. If there are many similar elements in the UI, generating them programaticaly is surely simpler. And note, that you can create part of the UI in glade, leaving an empty container, and then pack the rest programaticaly.
in perl, you could have a function create_block(@widgets) that create either a frame or vbox with a bold title at top: when following new HIG releases, you would only have to look at one place whereas with glade files, you've to manually alter all dialogs in all xml files
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature