Damon Chaplin wrote:
> Matt Goodall wrote:
> >
> > Damon Chaplin wrote:
> >
> > > T5 Check widget names for duplicates
> > > check when saving project?
> > > also check that widget names don't conflict with handler functions.
> >
> > Presumably, the duplicate widget name check will only be done on a per-window
> > basis. It is *very* useful to call the ok button something like "okBtn" on every
> > window.
> >
> > As long as you are given the option to say, "Yes, I'm absolutely sure that's what
> > I want", when warned then I would be happy.
>
> Hmmm. I was thinking of checking names are unique project-wide.
> If we start supporting rc files name clashes in a project may cause problems.
>
> Actually, now I think about it, we may be able to support that.
> I was thinking of using things like this in the rc file:
>
> widget "*.mybutton1" style "mystyle"
>
> But we could use something like:
>
> widget "mywindow1*.mybutton1" style "mystyle
Wouldn't it be better to use the full name of a widget, i.e.
mywindow1.this.that.mybutton1, in the rc files? That way there will never be name
clashes.
Is there any way of setting the style for widgets of a certain type within a widget
tree i.e. all buttons in this window's widget tree? If there is then that would be a
good use of ".*." in the rc files. I can't remember seeing this feature though -
another one for the list perhaps :-).
I think that not forcing unique names is important for object oriented style code.
If/when the 'C' code writer ever gets rewritten to use a structure for each window
with GtkWidget* members then common named widgets would be useful there too.
> Also, cut & paste currently expect unique project-wide names, but we could let
> the user sort any problems out with that.
Absolutely, Glade cannot guess how the user wants to use the widget name so it's the
users problem. Unique names is the safe option so that should be the default
behaviour.
> > > T15 Property editor
> > > improve the "Signals" page. Adding signal handlers can be confusing.
> > > It is probably better to have an "Add" button opening a dialog box.
> >
> > Also, it would be nice to add a few more handlers to the list. I posted a message
> > (with a patch I think) about this ages ago.
> >
> > IIRC the handlers I suggested adding were gtk_window_activate_default() and
> > gtk_widget_grab_focus(). Those two alone let you remove a lot of the mundane
> > navigation coding.
> >
> > I'm sure there are others that would be useful.
>
> OK. I'll add those 2 (they were the same 2 you had in your patch.)
What a memory :-). When I've get a moment I'll have a browe through code I've written
and the gtk heders to see what other handlers would be useful.
> > > T21 Default property values
> > > e.g. Glade assumes border_width default is always 0, but it isn't in
> > > the GtkDialog action_area, so we could generate incorrect source.
> >
> > This stuff should surely be in a data file in which case it would be nice to be
> > able to override the settings in a user's config file.
>
> I think that is a slightly different issue. I was thinking of code in Glade which
> assumes that properties have fixed default values. e.g. Glade only outputs
> gtk_container_set_border_width() when the border width is not 0, but this is
> actually incorrect for some widgets, usually widgets which are automatically
> created.
Yeah, I realised what you were getting at but it seemed like a good section to add my
suggestion to.
First though, can rc files be used for anything other than styles? If they can then
this entire section can be iignored!
I think I need to explain my idea more so here goes ...
If the values are put in a shared data file then "overriding" the values using data in
$HOME could use pretty much the same loading code.
Each value definition could be stored in a map as a structure containing id,
default_value and user_value. The shared data would fill in the id and default_value
and set the user_value to the default_value at the same time. The $HOME data would
then simply replace the user_data value.
I can see this sort of thing being useful for putting something like this in the $HOME
data:
GtkWindow.GtkContainer.border_width: 10
*.GtkButtonBox.layout: Spread
*.GtkTable.row_spacing: 5
*.GtkTable.cell_spacing: 5
All the code generators have to do is:
if user_data != default_data
write code
Unfortunately, this sort of change would affect all the code generators. If this is
seen as a good idea then it would probably be nice if glade supplied the parsing and
map building code as a separate, shared library to avoid duplication. I suppose that
libraries like libglade would also have to support this stuff which could be tricky.
More thought needed on that bit. Heh, this idea should panic some of the code
generator maintainers :-).
The other argument for this sort of info being supplied in a data file is that there
really shouldn't be stuff like this hard-coded anyway.
Yet another vaguely related thought is that Glade could even be distributed as glade
and glade-data packages to make changes/bug fixes to this sort of thing have less of
an impact on users.
> > Whenever I add a label to a table I *always* end up changing the fill and align
> > stuff which is pretty tedious.
>
> This is one thing I changed in 0.5.10. When labels are added to tables they are
> now set to GTK_FILL and left-aligned. (It was annoying me as well!)
You are officially a star :-). I'll download it immediately.
Please feel free to dismiss any of these ideas on the grounds that they are the
ramblings of an illinformed mind :-) I won't be too offended.
Cheers, Matt.
--
Matt Goodall, Software Engineer | Isotek Electronics Ltd
mailto:[EMAIL PROTECTED] | Claro House, Servia Road
http://www.isotek.co.uk | Leeds, LS7 1NL
Tel: +44 113 234320 | England
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
