Re: Windows Build Question
Paul Matthew Bombach writes: > I'm trying to build gtk under windows using MinGW. and MSYS, it seems like. (Good.) > > glib-mkenums --fprod "/* enumerations from \"@[EMAIL PROTECTED]" > > */\n" > Produces the following output: > > > /* Generated data (by glib-mkenums) */ > > > > C:/msys/1.0/* enumerations from "gdkrgb.h" *//n > As you can see, the output is garbled with the addition of the root > path. I think the problem is caused by using a non-MSYS Perl (like ActiveState's Perl perhaps?). MSYS thinks that the argument to the --fprod switch is a "Unix" pathname and thus turns it into a full Windows pathname by prepending a C: when invoking a non-MSYS program. MSYS isn't clever/brave enough to "guess" that a string like /* enumerations from "gdkrgb.h" */ that theoreticaly could be an absolute Unix pathname (glob pattern eben maybe) actually isn't, but just a string that should be passed on as such to the program. So the solution is to make sure glib-mkenums is run by the MSYS Perl. The glib-mkenums script I distribute in my glib developer packages for Windows starts with #!/bin/perl , . What does the glib-mkenums you use start with? --tml ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Thank you for all your reply.
It's been really useful.
I am getting really good info about all of it. Not just the "what use to
develop", but also about what technique to use.
For example, I use A LOT of variables to construct a simple dialog, but I
think it will be more sane to use just one or two, as mention by Richard
Boaz. Take a look at this part of my code: (don't mind for the names of the
variables, it's in my local language. And yes, I like to initialize
variables, always. :-) )
/***/
GtkWidget*
create_dialog_edit_disciplina_horario(void)
{
GtkWidget *dialog = NULL;
GtkWidget *vbox01 = NULL;
GtkWidget *rotulo_codigo = NULL;
GtkWidget *entrada_codigo = NULL;
GtkWidget *rotulo_nome = NULL;
GtkWidget *entrada_nome = NULL;
GtkWidget *rotulo_ano = NULL;
GtkWidget *spin_ano = NULL;
GtkObject *spin_ano_adj = NULL;
GtkWidget *rotulo_sem = NULL;
GtkWidget *spin_sem = NULL;
GtkObject *spin_sem_adj = NULL;
GtkWidget *rotulo_escolhe_semestre = NULL;
GtkWidget *cbox_escolhe_semestre = NULL;
GtkWidget *arvore_dados = NULL;
GtkTreeStore *armazena = NULL;
GtkWidget *hbox01 = NULL;
GtkWidget *hbox02 = NULL;
GtkWidget *hbox03 = NULL;
GtkWidget *hbox04 = NULL;
GtkWidget *hbox05 = NULL;
[...]
/***/
Another good one I think I will use is the reduced number of callbacks.
Every dialog in my code, for example, has its own callback. I think its
going to be more clear if I group all of them at the same one.
And more ideas that I am not going to bother you about.
I am a little excited about the possibilities, I admit. ;-)
Well, getting back to the IDEs (or as mentioned by Tristan Berkom, "User
interface Designer"), I am still thinking about it. I installed the new
version of Glade (was running glade-2, now running glade-3) and took a look
at the libglade. It seems to be a great idea, although I didn't really got
into it. Need more research by myself to understand how to use it.
What I am realizing is that if you want a specific GUI it's more convenient
to do it by hand but, if it's a general one, which will use the standard
widgets at the standard ways, the IDEs (or UIDs) happens to be a very good
idea.
Still a little confuse about what paradigm to use, I confess. But now with
more baggage to make my choice. :-)
Sincerely,
2007/4/14, Robert Pearce <[EMAIL PROTECTED]>:
On Sat, 14 Apr 2007 12:42:21 +0100 [EMAIL PROTECTED] wrote:
>
> Having said that, most people tell me it has an awful interface, so
> maybe you shouldn't listen to me.
If the sort of people who like most of what's out there think your
interface is "awful" then I'd probably think it's really nice. I'm
amazed at how ghastly most GUIs are. But then I think of computers as
tools for doing what I want them to do, not a display case for
avant-garde graphic design, so what would I know?
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Diogo F. S. Ramos
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Sat, 14 Apr 2007 12:42:21 +0100 [EMAIL PROTECTED] wrote: > > Having said that, most people tell me it has an awful interface, so > maybe you shouldn't listen to me. If the sort of people who like most of what's out there think your interface is "awful" then I'd probably think it's really nice. I'm amazed at how ghastly most GUIs are. But then I think of computers as tools for doing what I want them to do, not a display case for avant-garde graphic design, so what would I know? ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Converting Yahoo Desktop widget to a web widget
I have developed a few Yahoo Desktop widgets. I want to put them on to a web site. Is there a way to convert these desktop widgets to web widgets? Is there a way to host the Yahoo Widget engine (their xml specification) on to the web and put the widgets on a web site? Thanks, Apurv. -- View this message in context: http://www.nabble.com/Converting-Yahoo-Desktop-widget-to-a-web-widget-tf3569005.html#a9970768 Sent from the Gtk+ - General mailing list archive at Nabble.com. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: calendar with Gtk+ 2.0
vicente garcia wrote: > Hi, I'm programming a GTK program with freepascal and MySQL. The > application > must administer a Medical center and I need a calendar to show when the > patients must go to the doctor. I'm working with the widget GtkCalendar, > it's cool but I need something like this: > http://farm1.static.flickr.com/176/434960008_65ab81bc16_o.jpg > > I need something that show me the weeks and the hours of the day that is > occupated the medical center. I think I can't do this with GtkCalendar. > > Can somebody help me, please? You'll have to write your own widget [1]. That said, check out the source code for Evolution and Dates [2], which both implement something like this. You might be able to steal their code :) (The Dates code is likely to be simpler and less full of CORBA than Evolution.) -- Andrew [1] http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28 and http://gnomejournal.org/article/36/writing-a-widget-using-cairo-and-gtk28-part-2 are good starting points. [2] http://pimlico-project.org/dates.html ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
calendar with Gtk+ 2.0
Hi, I'm programming a GTK program with freepascal and MySQL. The application must administer a Medical center and I need a calendar to show when the patients must go to the doctor. I'm working with the widget GtkCalendar, it's cool but I need something like this: http://farm1.static.flickr.com/176/434960008_65ab81bc16_o.jpg I need something that show me the weeks and the hours of the day that is occupated the medical center. I think I can't do this with GtkCalendar. Can somebody help me, please? Thanks :) ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
I do pretty much as you, regarding variable naming,
unneeded vars (i.e. mainly layout containers and
static labels in glade), are just left to be named via
glade's default naming system. Since my app
(megatunix) is 100% built in glade, pretty much evey
widget there that require signal handlers has them
defined IN GLADE, but on app initialization when the
gui is created, I have extra config files I built,
that share a common naming scheme with the glade
files. I wrote a .ini style parser and code that
traverses the weidget tree of each Gui tab, search for
those widget names in my .ini files. if ti findsa
match, it runs some code that looks for custom
attributes I created and sets them on the widgets.
(things like signal handler enumerations, and other
simple and some very complex attributes.
NOTE: My app is very much a NICHE app, and is designed
to be modular as it has to adapt on runtime, and
statically defining all these attributes in code made
the code IMPOSSIBLE to be extensible. (megatunix
adapts to ECU firmware on startup using a minimalist
gui, and once it determines the ecu capability, it
ONLY loads specific Glade tabs that correspond to
controls valid for the device, hence my needs to be
able to define my extended attributes outside of the
application itself).
I also use the trick of a global hashtable to store
pointers to "customized" widgets, so they are easily
retrieved without having to use:
glade_xml_get_widget(). This is done because I want
to reference NON glade created widgets, and prefer to
rather just name one global definition of "extern
GHashTable *dynamic_widgets;" instead of a pile of
other externs.
In one of my simple apps (part of megatunix), called
gaugedesigner, this app is 100% glade, and I designed
it the same way as megatunix, defining all signal
handlers in the glade UI. On app startup are init
functions that specifically retrieve widgets by name
to manipulate or bind additional data to them
tmp=glade_xml_get_widget(xml,"save_gauge_menuitem");
gtk_widget_set_sensitive(tmp,FALSE);
tmp=glade_xml_get_widget(xml,"save_as_menuitem");
gtk_widget_set_sensitive(tmp,FALSE);
g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"precision_spin")),"
handler",GINT_TO_POINTER(PRECISION));
g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"value_xpos_spin")),
"handler",GINT_TO_POINTER(VALUE_XPOS));
g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"value_ypos_spin")),
"handler",GINT_TO_POINTER(VALUE_YPOS));
and so on.
--- Richard Boaz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Like the others posting so far, I do not use any IDE
> to program my gtk
> + app. I had a quick look once upon a time, but
> quickly determined
> that if you want or require to change the code that
> is automatically
> generated, you might as well just write your own
> instead of trying to
> get in the deep-end of someone else's ideas about
> how this should be
> done.
>
> This subject came up a little while ago as well.
> Then, the poster
> found that writing your own code was a big pain
> since this required
> coming up with a variable name for every widget
> needing to be
> created. But I didn't and still don't understand
> this complaint.
> When creating widgets, two types of widgets are
> required, one which
> never again needs to be accessed (e.g., a static
> label (don't even
> start talking about dynamic labels...:) ), and the
> other requiring
> accessing (e.g., an entry area taking input from the
> user). For
> those widgets not needing to be accessed, it is not
> necessary to
> provide a unique variable name, rather, you can
> re-use the same
> variable over and over since once a widget is
> registered/packed/
> whatever, you need not reference it again.
>
> To illustrate, the following snippet generates two
> buttons and an
> entry area with a label laid out simply in a
> vertical container:
>
> vbox = gtk_vbox_new(FALSE, 0);
>
> button = gtk_button_new_with_label("TRACES");
> g_signal_connect((button), "clicked",
> G_CALLBACK(buttonCallback),
> &enums[TRACES]);
> gtk_size_group_add_widget(size_group, button);
> gtk_container_add(GTK_CONTAINER (vbox), button);
> strcpy(toolTip, "Open Trace files");
> gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button,
> toolTip, toolTip);
>
> button = gtk_button_new_with_label("Next");
> g_signal_connect((button), "clicked",
> G_CALLBACK(nextTrace), &enums
> [NEXT]);
> gtk_size_group_add_widget(size_group, button);
> gtk_container_add(GTK_CONTAINER (vbox), button);
> strcpy(toolTip, "Display NEXT Screen of Trace
> Files");
> gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button,
> toolTip, toolTip);
>
> hbox = gtk_hbox_new(FALSE, 0);
> label = gtk_label_new("min:");
> MTfixed[MIN] = entry = gtk_entry_new();
> g_signal_connect(MTfixed[MIN], "activate",
> G_CALLBACK(reMag), &OV
> [MAGNIFYSCR]);
>
Re: How do you develop you GTK code?
In the case of my app (MegaTunix) the app gui is 100% glade, though some widget are built manually and placed into of a glade designed object as like others have said, they are dynamic and not predictable until during runtime. Due to the niche nature of my app, and the multitude of controls (well over 1500), I had to extend things as glade didn't do enough, but it worked and is fairly extensible even if it's design has numerous flaws... http://megatunix.sourceforge.net -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Sat, 2007-04-14 at 15:00 +0200, Richard Boaz wrote:
> Hi,
>
>
> Like the others posting so far, I do not use any IDE to program my gtk
> + app. I had a quick look once upon a time, but quickly determined
> that if you want or require to change the code that is automatically
> generated, you might as well just write your own instead of trying to
> get in the deep-end of someone else's ideas about how this should be
> done.
Right, first of all I dont think its correct to suppose that generated
code is anyone's idea of "how it should be done", generated code is
a mechanical spew of "code that works" and should NEVER be used as
an example or reference implementation.
My opinions about glade are biased because I maintain glade, but my
opinion anyway: glade is not an IDE, its a user interface designer -
adding application data and modeling of that data is not a desirable
thing, you want to keep your user interface in one corner and your
data in another - not mix them up in one big pot of spaghetti code.
If you have concerns about dynamic portions of your interface, I agree
they should mostly be done by hand, but wait - glade can still help you
here, say you have a hbox with a label and an entry as was previously
described, you can always put one instance of that in your glade file
and loop like so:
for (i to ... dataentries) {
xml = glade_xml_new (..."dataentryitem"...);
widget = glade_xml_get_widget (xml, "dataentryitem");
/* ... pack into your program somewhere by hand ... */
g_object_unref (xml);
}
This might or might not make sence depending on the application, but
it does have the advantage of keeping your UI dynamic, if you need to
add an item/label/separator or whatever to that subhierarchy than you
dont need to edit or compile code to update your interface.
I also believe that following a template design might be good
for a dumb little CLI wrapper in a GUI - but if you are really
developing an industry grade application then please use your
brain and understand the code - using libglade for your interface
is a good thing because it defers all the repetitive rigid GUI
building code to a library that takes care of it for you - it
also allows you to use YOUR OWN design that is appropriate for
your own application, either by loading dialogs on the fly or
at initialization time - keeping pointers around for the widgets that
you need referenced by name, or by using lookup_widget() types of
paradigms - point being - you are the author of your application
and the sources are in your hands, you should be able to organize
your code in a way that suits the application at hand.
For a good reference implementation - I've repeatedly been pointing
people in the direction of the DevHelp sources, since IMO they use
a sound OO design and a very practical use of libglade (its also
very simple code to understand).
Just my 2 cents, cheers,
-Tristan
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Hi,
Like the others posting so far, I do not use any IDE to program my gtk
+ app. I had a quick look once upon a time, but quickly determined
that if you want or require to change the code that is automatically
generated, you might as well just write your own instead of trying to
get in the deep-end of someone else's ideas about how this should be
done.
This subject came up a little while ago as well. Then, the poster
found that writing your own code was a big pain since this required
coming up with a variable name for every widget needing to be
created. But I didn't and still don't understand this complaint.
When creating widgets, two types of widgets are required, one which
never again needs to be accessed (e.g., a static label (don't even
start talking about dynamic labels...:) ), and the other requiring
accessing (e.g., an entry area taking input from the user). For
those widgets not needing to be accessed, it is not necessary to
provide a unique variable name, rather, you can re-use the same
variable over and over since once a widget is registered/packed/
whatever, you need not reference it again.
To illustrate, the following snippet generates two buttons and an
entry area with a label laid out simply in a vertical container:
vbox = gtk_vbox_new(FALSE, 0);
button = gtk_button_new_with_label("TRACES");
g_signal_connect((button), "clicked", G_CALLBACK(buttonCallback),
&enums[TRACES]);
gtk_size_group_add_widget(size_group, button);
gtk_container_add(GTK_CONTAINER (vbox), button);
strcpy(toolTip, "Open Trace files");
gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip);
button = gtk_button_new_with_label("Next");
g_signal_connect((button), "clicked", G_CALLBACK(nextTrace), &enums
[NEXT]);
gtk_size_group_add_widget(size_group, button);
gtk_container_add(GTK_CONTAINER (vbox), button);
strcpy(toolTip, "Display NEXT Screen of Trace Files");
gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip);
hbox = gtk_hbox_new(FALSE, 0);
label = gtk_label_new("min:");
MTfixed[MIN] = entry = gtk_entry_new();
g_signal_connect(MTfixed[MIN], "activate", G_CALLBACK(reMag), &OV
[MAGNIFYSCR]);
gtk_entry_set_width_chars(GTK_ENTRY (entry, 5);
gtk_container_add(GTK_CONTAINER (hbox), label);
gtk_container_add(GTK_CONTAINER (hbox), entry);
gtk_container_add(GTK_CONTAINER (vbox), hbox);
strcpy(toolTip, "MIN: define as absolute (e.g., 1000) or as
Percentage of MAX/MIN Mean (e.g., 50%) (BLANK = Real MIN)");
gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), entry, toolTip, toolTip);
As another poster pointed out, this repetitive type of widget
creation can be contained within its own routine. But basically,
once you've got the various types of widgets and layouts you require,
it is trivial to copy and paste the code over and over, only
requiring the widget's creation details to be changed for each new
instance.
The above snippet requires only that the entry area be uniquely named
for later reference. In my code, all widgets are globally defined as
GtkWidget *, casting when- and wherever appropriate. (Some purists
might balk at global variables but I have no problem with globals
which never change value over the entire life of a program,
especially when they're widgets needed possibly anywhere.) To handle
the problem of having to name so many widgets nonetheless, adopt a
simple and shorthand naming convention you can immediately recognize,
deduce, and even guess which makes sense somehow to the program and
their usage. As well, arrays of widgets can be very helpful here.
And like another poster, I highly recommend attaching as few
callbacks as possible to the widgets. Like he does, as can be seen
above, each button is attached to the same callback with an enum
value passed to the callback routine. Once called, case statements
handle each button's differing requirements. (Unlike how he does it,
however, I do this more directly in the signal connection itself;
either method works though depending on exact requirements, using
g_object_*_data() may be more appropriate.) In general, try to
attach like widgets to the same callback. In practice this won't be
universal, some callbacks demand their own routine; the point is,
maintaining code in the future is always made easier when the number
of callbacks is minimized to the greatest extent possible.
And good luck,
richard___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On Sat, 2007-04-14 at 02:10 -0700, David J. Andruczyk wrote: > though QT's designer offers something along > those lines, as subclassing existing widgets is about > 1000x easier than doing it in GTK+. if you opted to work in the same object oriented language that Qt uses, and just used gtkmm, you would find that subclassing existing widgets is about 1000x easier than doing it in GTK+. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On 4/14/07, Robert Pearce <[EMAIL PROTECTED]> wrote:
> The other thing to bear in mind is this:
> If you have a row or column of similar widgets, say buttons, then a tool
> like Glade or BCB requires you to place every one individually. Writing the
> code by hand lets you do:
> for ( cc=0; cc<10; cc++ )
> {
> MyButtons[cc] = gtk_button_new (..);
> gtk_box_pack_start ( );
> }
>
> This is even more relevant if the number of buttons isn't known at design
> time!
This is a good point. In my app I have functions like (an example)
build_label_entry() which makes a GtkLabel + GtkEntry with layout
following the HIG guidelines. Once you have a few of these set up,
building a dialog from code is really easy. Plus now your layout is
just in one function, so you can change the layout of all label +
entry pairs by just altering a couple of lines of code.
It also depends on the kind of program you are writing. Mine has a
relatively 'small' GUI (most of the code is in the back end) so Glade
would not save me a significant amount of time.
Having said that, most people tell me it has an awful interface, so
maybe you shouldn't listen to me.
John
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
> On Fri, 13 Apr 2007 23:57:12 -0300 you wrote: > > I am curious about it and really want to know: How > do you develop your GTK > > codes? > I do a combination of by hand and via glade. Glade has several faults, the one being not being able to bind arbritrary information to widgets in the designer, which I doun't think would be possible anyways, though QT's designer offers something along those lines, as subclassing existing widgets is about 1000x easier than doing it in GTK+. So for my niche use, in order to be able to reuse signal handlers, and not end up with one handler per control, I have glue code in place that on initialization of the application it binds additional data per applicable widget which the signal handlers use to take appropriate action. so my code makes very extensive use of g_object_set_data(), and g_object_get_data(). Thus for all my buttons I have one handler std_button_handler(), and in my code I assign an enum to each control (i.e. g_object_set_data(G_OBJECT(widget), "handler" GINT_TO_POINTER(SOME_ENUM_NAME)); so that when that handler is called, it's is handled in a case statement inside that handler. -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
Hi Diogo,
On Fri, 13 Apr 2007 23:57:12 -0300 you wrote:
> I am curious about it and really want to know: How do you develop your GTK
> codes?
Mostly by hand.
Before coming to GTK I had done some GUI apps on Windows with Borland C++
Builder, which is quite nice for drawing fixed size dialogs with a small
selection of different widgets. I had also briefly tried customizing a GUI
written in Tcl/Tk (and later Python/Tkinter) with no RAD support.
My first few GTK apps were hand written using tables of widgets. It does make
it harder to visualize what you're creating as you go, but anyone that's done
HTML will be accustomed to how tables work. If you draw your GUI out on paper,
it's really not hard to code from that.
I tried Glade more recently, thinking it would be easier, like the Borland
tool. Well, it does work as a drawing tool, and I guess if you use libglade and
don't care how it ends up being implemented then it isn't too bad. But the code
generator (now deprecated) produces something truly horrid.
The other thing to bear in mind is this:
If you have a row or column of similar widgets, say buttons, then a tool like
Glade or BCB requires you to place every one individually. Writing the code by
hand lets you do:
for ( cc=0; cc<10; cc++ )
{
MyButtons[cc] = gtk_button_new (..);
gtk_box_pack_start ( );
}
This is even more relevant if the number of buttons isn't known at design time!
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
