Possible inconsistency between GtkBuilder and GtkUIManager.
Hi, After the fix to #591085, to get the id of a widget, say a toolbar, and if I understand things correctly, we need to call gtk_buildable_get_name to retrieve the name of the toolbar if it has been created from a ui file and gtk_widget_get_name if it was created using gtk_ui_manager_add_ui*. Is this true or should gtk_widget_get_name always used for toolbars and menus? Also in the documentation, I'd propose to add an indication about the need to use gtk_buildable_get_name when migrating from libglade to GtkBuilder. Best regards, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Graph Widget Development
You might also have a look at the goffice library (which provide the charting engine to gnumeric, abiword, gnucash and others). Le mercredi 06 mai 2009 à 16:18 -0400, Keith Williams a écrit : > You might want to take a look at the GIW library (it's hosted on > sourceforge). I'm not sure if it will save you any coding or not. > > Also, a guy I was working with wrote a patch for GIW's x-y plot that > utilized Cairo's anti-aliased drawing capability. I can probably dig > that up if you're interested. > > HTH, > > Keith > > David Brigada wrote: > > Hello, > > > > I am currently developing an X-Y graph widget that I think could > > someday be included in GTK+. I'd just like to get a little bit of > > feedback on the design so that I don't start spinning my wheels in the > > wrong direction. My plan is to make the usage of GtkGraph similar to > > that of GtkTreeView---they are both widgets that can show large > > amounts of data. > > > > The widget would be GtkGraph (analogous to GtkTreeView). This would > > show axes, labels and numbers on the axes, and provide the drawing > > region to show the plots on. On the GtkGraph widget, application > > programmers could add GtkGraphPlot objects (similar to > > GtkTreeViewColumn), each of which would plot a single series of data. > > The plot objects would be connected to two things, first a > > GtkGraphRenderer (similar to GtkCellRenderer) that would determine how > > to plot the data on the graph, and second a GtkTreeModel (usually a > > GtkListStore or possibly a lightweight replacement that uses an array > > instead of a linked list for backing) that provides the data that the > > renderer uses to generate its plots. Each GtkGraphPlot object would > > also hold one or more column numbers indexing into the tree model. > > > > At some point, when I'm done with a basic implementation of this, I'll > > send an update with (a link to) the code to the list, if anyone's > > interested in giving a brief review so that I can try to fit it better > > to GTK+'s style. > > > > Please let me know what you think about this idea. > > > > Thanks, > > David Brigada > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
Le vendredi 06 juin 2008 à 18:22 +0100, Gustavo J. A. M. Carneiro a écrit : > I think I agree with Muntyan here. Gtk+ 3.0 brings nothing exciting, so > why break API? It's just so pointless and painful for everyone. So > much effort done with memory profiling and now we'll have to have two > libraries, gtk+ 2.0 and gtk+ 3.0, side by side, for a few more years? > > If, as I suspect, Gtk+ 3.0 is more of a marketing stunt than anything > else, great, we can release the next gtk+ 2.x as two separate libraries > and header files: >1. gtk+-3.0: only the non-deprecated APIs >2. gtk+-2.0 deprecated: only the deprecated APIs > > $(pkg-config --libs gtk+-2.0) would yield -lgtk+-2.0 -lgtk+-3.0, > while $(pkg-config --libs gtk+-3.0) would give -lgtk+-3.0. Hmm, if gtk+-3.0 is released under lgpl-v3, gpl-v2 only projects such as gnumeric would not be able to link gtk+-2 anymore. Regards, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Windows API (and may be DirectX) is a special case, because you can't write a Windows program without using it. Le mardi 18 mars 2008 à 12:57 +0100, Lieven van der Heide a écrit : > Ok, according to the matrix on > > http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility > > it's indeed not allowed, although I don't really understand why. > > On 3/18/08, Lieven van der Heide <[EMAIL PROTECTED]> wrote: > > Does that really apply for the code you link to? Afaik, if a GPL > > program uses an LGPL library, it doesn't relicense that library under > > GPL too, it merely links to it, and leaves it up to the user to make > > sure the library is available. If this would be the case, than it > > wouldn't be possible for GPL code to use something like the Windows > > API or DirectX either. > > > > I think the restriction from the link you posted only apply to GPL > > libraries, but not LGPL. > > > > > > On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote: > > > > > > Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann: > > > > > > > I am really wondering what's the reason for FSF claiming, that > > > > programs > > > > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The > > LGPL-3 > > > > allows non-free, proprietary programs to use LGPL-3 libraries, but > > > > excludes free software, licensed GPL-2 only? This sounds absurd to me! > > > > > > > > Is the FSF spreading FUD with their license matrix? Why doesn't the > > > > matrix have footnotes explaining that absurd conflict? > > > > > > > > > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes > > > additional restrictions not found in the GPLv2. So it isn't the LGPLv3 > > > that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is > > > the GPLv2 which forbids to linking against libraries more restrictive > > > than itself. > > > > > > See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility > > > for details. > > > > > > In theory LGPLv3 allows addition of exceptions, but they have to be > > > approved by all copyright holders. Doubt this will happen. So only > > > chance for upgrading to a new version of the LGPL is waiting for an FSF > > > approved version of the LGPL, which drops those additional restrictions > > > for GPLv2-only programs. > > > > > > Total insanity... > > > > > > > > > Ciao, > > > Mathias > > > -- > > > Mathias Hasselmann <[EMAIL PROTECTED]> > > > Openismus GmbH: http://www.openismus.com/ > > > Personal Site: http://taschenorakel.de/ > > > > > > > > ___ > > > gtk-devel-list mailing list > > > gtk-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > > > > > > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Le samedi 15 mars 2008 à 21:43 +0100, Christian Persch a écrit : > Hi Jean; > > Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: > > Hmm, and what will happen to applications using at least one GPLv2-only > > libraries? > > This might indeed pose a problem, though I'm not sure how major it is. I > have to admit that it is however not a theoretical problem, since we > just found out that we do depend on one such library in Gnome: evince > uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. > Other affected projects are Goffice (GPL-v2 only) and all those which depend on it, namely Gnumeric, Abiword, Gnucash and GChemUtils (the last also use OpenBabel, another GPL-v2 only library). Seems that all the projects I'm involved in would be affected. Some can be relicensed, but probably not all, just because some previous contributors seem to have disappeared from the earth surface. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Hmm, and what will happen to applications using at least one GPLv2-only libraries? Regards, Jean Le samedi 15 mars 2008 à 21:03 +0100, ryan lortie a écrit : > Hello. > > After some talk at the Hackfest about it, I'm writing the list to > officially request that glib and GTK be moved to LGPL "version 3 or > later". > > The reasons for this are the increased clarity in the language of the > license plus the ability to accept LGPL3 code into glib/gtk ((since it > seems like things will be increasingly using LGPL3 in the future)). > > There is also the matter of the additional protections offered by the > LGPL3. Everyone I talked to at the hackfest was in favour of these. > > There is the option of simply making a policy change and saying "we now > accept code under LGPL3+, but existing code is still LGPL2+" and leaving > all of the copyright notices alone. Tim thought that probably it would > be a better idea to change all of the headers to explicitly state LGPL3+ > (in order to, among other things, avoid confusion about what license new > contributions occur under). > > If we decide to change all of the existing copyright notices, I'd > volunteer to make the patch to do so. > > Cheers > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Canvas and Gladebuilder API in gtk??
Le samedi 02 décembre 2006 à 23:53 +0100, Mikael Hermansson a écrit : > Hello gtk developers. > > > For a long time now I have study the gtk+ and its development. > > And here is some things we really need to make better in GTk+ to make > it success as a good toolkit. > > Kill gnomecanvas and integrate a canvas widget in gtk+ > > * What is the status of > > foocancanvas > goocanvas > The other canvas Havoc talked about for some time ago.. (dont remember > the name... libccc (criawips canvas). I made some tests recently with it, and I feel it shows great promises, even if it is probably some more work to migrate from GnomeCanvas to CriawipsCanvas than to GooCanvas. Foocanvas is not based on cairo. Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Le mercredi 30 août 2006 à 15:52 +0200, W. Borgert a écrit : > Hi, > > sorry, if this is an FAQ, my checks didn't reveal anything: > AFAIK, GTK+ does not have a standard canvas widget. GNOME > does have a canvas widget, but it seems to be not very > popular. And having it in the GNOME libraries is not useful > for programs that should run on multiple platforms (win32). > Is there any plan or idea for a GTK+ canvas widget? http://www.gtk.org/plan/meetings/20060625.txt ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Histogram widget
Le jeudi 01 juin 2006 à 13:03 +0200, Alberto Mardegan a écrit : > Hi all! > I'm going to write a widget for displaying histograms. Would it be > elegant/smart/useful if it were to fetch the data from a GtkTreeModel, > or would it be an unneeded complexity and just some GArrays are better? > > I'm thinking of a GtkTreeModel, in which every row is a histogram bar; > hence we would/could have a double field for the value, a string field > for the label in the X axis, maybe a GdkColor for the color and whatever > can come to mind. > > Many thanks in advance to all those who will share their thoughts on the > matter. Do you want histograms or column charts? Anyway both already exist in goffice and we have the GOGraphWidget widget to display a large variety of 2D charts. Regards, Jean Bréfort ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_statusbar_push!!
Le vendredi 12 mai 2006 à 11:03 +0200, [EMAIL PROTECTED] a écrit : > Hi everyone!! > I need your help... > I built a window with glade_gtk,including an statusbar,but the problem is > that i > want to write in the statusbar,different sentences telling me about the > process...just after click one button of my window. > Like this... > first: "processing file" > (and after process it) > "end of process" > > The code i'm using is this: > > gtk_statusbar_push(GTK_STATUSBAR(statusbar1),1,"Procesing..."); > > /now,is my code about the process*/ > > gtk_statusbar_pop (GTK_STATUSBAR(statusbar1),1); > > > gtk_statusbar_push(GTK_STATUSBAR(statusbar1),1,"End..); > > /close the process**/ > > The problem is that during the process,the statusbar is empty,and when it > finished writes in the bar "End...". the status bar is updated from the main loop; during a lengthy process, use: while (gtk_events_pending ()) gtk_main_iteration(); > I tried to put sleep(5000) to delay the process(i thought that maybe the > process > is so quikly)but neither happes) > > Can you help me?? > Thanks a lot!!! > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: newbie and ask show window
Le mercredi 10 mai 2006 à 13:23 +0700, Ade Amrillah a écrit :
> hi all
> i'm newbie in gtk+. i was create simple programme for testing
> "gtk_widget_show()" function.
> my program has tow windows
> first window i put button for call second window, i develop GUI with
> Glade and anjuta for code.
> my code are
>
> void on_openbtn_clicked (GtkButton *button,gpointer user_data)
> {
> GtkWidget * window2;
> window2=create_window2();
> gtk_widget_show(window2);
>
> }
>
> and it's working. but if i press button again a new window (window2)
> will be create.
> i want just one window created if i press again button.
> ask: how i change the programme for show window for only one show?
> for illustrated:
> i use gedit and i click preferences (menu edit->preperences) just one
> window showed and if i click again did not show again new window.
> sorry for my english :)
Use something like:
GtkWidget * window2 = NULL;
void on_openbtn_clicked (GtkButton *button,gpointer user_data)
{
if (window2 != NULL)
return;
window2=create_window2();
gtk_widget_show(window2);
}
and add an event handler to reste window2 to NULL when the window is
destroyed.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GooCanvas 0.3
Le mardi 25 avril 2006 à 21:02 +0100, Damon Chaplin a écrit : > I've put GooCanvas 0.3 (a GTK+ cairo canvas widget) up at: > http://www.dachaplin.dsl.pipex.com/goocanvas/ > > This release adds pretty much all of my list of essential features: > > o New GooCanvasPath item (similar to SVG path element). > o Accessibility support. > o Keyboard focus navigation. > o API documentation. > o Convenience functions for coordinate conversions. > o Smooth scrolling & zooming. > o Zoom-independent text layout. > o Render part or all of canvas to a cairo_t, for ps/pdf output. > o New "visibility" and "visibility-threshold" properties for items. > o New "pointer-events" property specifying which parts of items get >events (like SVG). > > It should be usable now. Though there will probably be a few bugs to > iron out. > > The main thing I want to add now is an editable text item, like > GtkTextView. Other than that it depends on what features people need. I need such an item and am already working on one for GChemPaint (it uses GnomeCanvas at the moment, but rendering use pango and cairo). The editing capabilities are still limited and are tightly linked to the needs of GChemPaint, so I don't know if it might be useful for others. Cheers, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
Le lundi 27 mars 2006 à 02:08 -0600, Yevgen Muntyan a écrit : > Hey, > > First of all, I implemented some printing in my application, > and it works! > > I have a question about generating postscript. Using > copy/paste method I implemented postscript print backend, > and it's working fine. While generated postscript is just > a bunch of page images due to cairo problems, the GtkPrint* > stuff works fine. So, shouldn't PDF backend be really a > "File" backend which can write PDF or PS? Or maybe just > separate PS backend, in addition to PDF? An what about an EPS backend? I feel it might be useful for many people (not only myself). Cheers, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: compiling atk
Le dimanche 05 février 2006 à 02:04 +1100, electroteque a écrit : > It looks like a make install solved my issue with glib, i ignored those > errors. Ive moved onto atk compiling with ./autogen.sh --prefix=$prefix > --disable-gtk-doc > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_DISABLE_DEPRECATED > -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I /sw/include > -I/sw/include -Wall -MT atk-enum-types.lo -MD -MP -MF > .deps/atk-enum-types.Tpo -c atk-enum-types.c -fno-common -DPIC -o > .libs/atk-enum-types.o > /bin/sh ../libtool --mode=link gcc -I/sw/include -Wall -L/sw/lib -o > libatk-1.0.la -rpath /usr/lib -version-info :0: atkaction.lo > atkcomponent.lo atkdocument.lo atkeditabletext.lo > atkgobjectaccessible.lo atkhyperlink.lo atkhypertext.lo atkimage.lo > atknoopobject.lo atknoopobjectfactory.lo atkobject.lo > atkobjectfactory.lo atkregistry.lo atkrelation.lo atkrelationset.lo > atkselection.lo atkstate.lo atkstateset.lo atkstreamablecontent.lo > atktable.lo atktext.lo atkutil.lo atkvalue.lo atk-enum-types.lo > -L/sw/lib -lgobject-2.0 -lglib-2.0 -lintl -liconv > > libtool: link: CURRENT `' is not a nonnegative integer > libtool: link: `:0:' is not valid version information > make[3]: *** [libatk-1.0.la] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > I dont understand what its doing here ? I don't know OSX, but this is quite strange. What is the size of an integer in the console ? should be positive if it is at least two bytes. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: compiling glib on OSX.
Le dimanche 05 février 2006 à 01:31 +1100, electroteque a écrit : > Ive reverted back to automake-1.7 and still more issues > > Making all in po > file=./`echo fa | sed 's,.*/,,'`.gmo \ >&& rm -f $file && /sw/bin/msgfmt -c -o $file fa.po > fa.po:95: number of format specifications in `msgid' and `msgstr' does > not match > fa.po:210: number of format specifications in `msgid' and `msgstr' does > not match > fa.po:215: number of format specifications in `msgid' and `msgstr' does > not match > found 3 fatal errors > make[2]: *** [fa.gmo] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 Hmm, seems the po/fa.po on your machine has some problems. What do you see in this file around line 95? > This whole thing has been a pain from the start, any help would be > greatful, i have tried installing gtk hundreds of times and given up :) > > On 05/02/2006, at 1:15 AM, electroteque wrote: > > > Hi there, im having some issues getting glib compiled for OSX. Ive > > been going through these steps on this page which aparantly doesnt > > require X11. > > http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Build_Instructions > > > > I had some great pain getting up to glib, especially cairo where i had > > to tweak system variables and lots of symblinks everywhere. > > > > Anyway here is what autogen.sh tells me > > > > cd . && /bin/sh ./config.status glibconfig.h > > config.status: executing glibconfig.h commands > > config.status: glibconfig.h is unchanged > > echo timestamp > stamp-gc-h > > cd . && /bin/sh /usr/share/sources/gtk/glib/missing --run autoheader > > configure.in:10: warning: file `acglib.m4' included several times > > configure.in:11: warning: file `glib/libcharset/codeset.m4' included > > several times > > configure.in:12: warning: file `glib/libcharset/glibc21.m4' included > > several times > > rm -f stamp-h1 > > touch config.h.in > > cd . && /bin/sh ./config.status config.h > > config.status: creating config.h > > config.status: config.h is unchanged > > make all-recursive > > Making all in . > > make[2]: *** No rule to make target `mkinstalldirs', needed by > > `all-am'. Stop. > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > > > any ideas ? > > > > my steps before that was > > > > ln -s /usr/share/aclocal/gtk-doc.m4 /sw/share/aclocal/gtk-doc.m4 > > > > ./autogen.sh --prefix=$prefix --disable-gtk-doc > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Conflicting recommendations about using GTK_BIN(widget)->child in Gtk+ documentation
Le mardi 03 janvier 2006 à 12:00 +0200, Kalle Vahlman a écrit : > Hi all. > > I noticed that there is a conflict in what GtkBin docs say: > > http://developer.gnome.org/doc/API/2.0/gtk/GtkBin.html#GtkBin-struct > " > The GtkBin-struct struct contains the following fields. (These fields > should be considered read-only. They should never be set by an > application.) > > GtkWidget *child; the child widget. > " > > and what the GtkComboBoxEntry docs say: > > http://developer.gnome.org/doc/API/2.0/gtk/GtkComboBoxEntry.html#gtk-combo-box-entry-new-with-model > " > You can get the GtkEntry from a GtkComboBoxEntry using GTK_ENTRY > (GTK_BIN (combo_box_entry)->child). > " > > So either the GtkBin or GtkComboBoxEntry docs needs to be changed in > this regard. Why? You can access it, but it is read-only; you must not set it. Using: GTK_BIN (combo_box_entry)->child = my_widget; is a bug, even if the compiler accepts it. > Considerations: > > 1) GTK_BIN(widget)->child is officially available as > gtk_bin_get_child(), so it's not like it would be required to retrieve > the entry from a GtkComboBoxEntry. > > 2) GTK_BIN(widget)->child is insanely more pleasant to use in code, > and a little more object oriented than gtk_bin_get_child() (which is > in my books always a good thing :) > > 3) Use of public widget struct members are used succesfully with > GtkDialog (->vbox and ->action_area), so it's not like doing something > new. > > 4) Given the GtkComboBoxEntry docs recommendation and personal > observations, GTK_BIN(widget)->child is a common trait so it can't > really be considered as a contender for change in any way without > breaking a multitude of code. No point in trying to hide it instead of > embracing it, right?-) > > So my score is on the side of admitting GtkBin->child as a public > member in the docs, what's yours? > > -- > Kalle Vahlman, [EMAIL PROTECTED] > Powered by http://movial.fi > Interesting stuff at http://syslog.movial.fi > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
Le mardi 13 décembre 2005 à 11:44 -0500, Matthias Clasen a écrit : > On 12/13/05, Murray Cumming <[EMAIL PROTECTED]> wrote: > > > > > gtkmm 2.8 depends on glib/gtk 2.8, right? then you don't > have > > g_object_force_floating() there. would it be of any help to > you > > if glib 2.8 had g_object_force_floating() already (whether > function > > or not)? > > Yes, or something in GTK+. Though it would be an act of > desparation. > > One could conceivably modify GTK_OBJECT_SET_FLAGS to do the right > thing for floating, but > direct setting/checking of the flag is not fixable. goffice uses GTK_OBJECT_SET_FLAGS object, GTK_FLOATING), so, PLEASE, do that. We only request gtk+-2.0 >= 2.6.0. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook signals
Le mardi 22 novembre 2005 à 15:20 -0500, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN a écrit : > Can someone fill me in if there is proper documentation for the signals on > GtkNotebook? Specifically, these: > > "change-current-page" > "focus-tab" > "select-page" > "switch-page" > > If an application wishes to prevent the notebook from switching pages if some > type of validation fails on the current existing page, is "select-page" the > proper signal to use with a return of FALSE? I had this problem with GChemPaint a long time ago. To solve it, I use the "expose-event" signal for the child widget. When this signal is fired, I check the state of the current active page, and if the validation fails, I use gtk_notebook_set_current_page to set the active page. http://savannah.nongnu.org/cgi-bin/viewcvs/gchempaint/gchempaint/src/standaloneapp.cc the code is in : gcpStandaloneApp::SetActive (gcpDocument* pDoc, GtkWidget* w) (line 963 or so). This code is somewhat old now, so I can't remember why I could not use the GtkNotebook signals... so there might beis a better solution ;-) > If someone can explain these in a bit more detail, we could update the > function > comments so the docs are more clear. > > Thanks, > > Andrew > Bloomberg LP > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sponsored Canvas (was: Re: The state of the canvas)
Le vendredi 18 novembre 2005 à 11:00 +0100, Sven Herzberg a écrit : > Hi all, > > On Do, 2005-11-17 at 12:47 +0100, Jean Bréfort wrote: > > It seems that things do not advance a lot by now. AFAIK, no much work > > have been done except Alexander Larsson's patch available at: > > http://bugzilla.gnome.org/show_bug.cgi?id=318807 > > > > David Bellot told me he is too busy at the moment to work on the canvas > > and, personally, I am not just not able to write the whole thing alone. > > As GnomeCanvas does not fulfill all my needs and might be soon > > deprecated, I decided to replace it for GChemPaint by a light canvas (I > > do not need many items, nor an optimized canvas) starting from > > libgnomecanvas code. > > > > At the moment, I am working on a text item (still for the Gnome Canvas) > > which uses Cairo and Pango for rendering. Hopefully, this code might be > > useful for GtkCanvas if it exists one day ;-) > > sorry for the late reply, but I have been busy on the LWE 2005 in > Frankfurt the last days. I was talking with Thomas Uhl about a > cairo-based canvas for GTK+ which doesn't inherit ANY of the limitations > that the GNOME Canvas and the deriving ones (Foocanvas, Goocanvas, etc.) > already have [2]. > > Good news now: Thomas is sponsoring my work on a cairo based canvas > which I want to use for my presentation application and which he needs > for several other projects. The contract says that I will finish my work > until the middle of February. I still have 3 weeks at my former > employer, so I'd like to use these three weeks for discussion of the > canvas and how it should be like. Great :-) > I've already set up a wiki page [1] about this. Feel free to add > requirement there and please provide API samples if you need special > features (so I have a clear impression of what you need). > > [1]http://www.criawips.org/wiki/Canvas The correct link is http://www.criawips.org/wiki/index.php/Canvas > [2]These limitations are (partially) documented on my canvas wiki page. Cheers, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
The state of the canvas
Hi, It seems that things do not advance a lot by now. AFAIK, no much work have been done except Alexander Larsson's patch available at: http://bugzilla.gnome.org/show_bug.cgi?id=318807 David Bellot told me he is too busy at the moment to work on the canvas and, personally, I am not just not able to write the whole thing alone. As GnomeCanvas does not fulfill all my needs and might be soon deprecated, I decided to replace it for GChemPaint by a light canvas (I do not need many items, nor an optimized canvas) starting from libgnomecanvas code. At the moment, I am working on a text item (still for the Gnome Canvas) which uses Cairo and Pango for rendering. Hopefully, this code might be useful for GtkCanvas if it exists one day ;-) Best regards, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: canvas notes
Le samedi 10 septembre 2005 à 10:29 +0100, Damon Chaplin a écrit : > On Fri, 2005-09-09 at 20:23 -0400, Havoc Pennington wrote: > > On Fri, 2005-09-09 at 09:53 +0200, Alexander Larsson wrote: > > > * OpenGL > > > > Any thoughts on that 3D vs. 2D thing? i.e. it seems like we want to be > > able to mix OpenGL and Cairo at will, but it isn't clear to me what that > > really means. > > > > Kind of a similar question to is a compositing manager best done with > > RENDER or GL as the foundation maybe... > > I think you should take it one step at a time, i.e first get a 2D > zoomable, printable, cairo canvas working, then think about 3D. Anyway, making a printable 3D canvas is all but easy. > Otherwise you'll probably spend the next year just discussing what > features should be in it! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: canvas notes
Le lundi 15 août 2005 à 02:38 -0400, Havoc Pennington a écrit : > Hi, > > Been thinking about canvas widgets a little this weekend, thought I'd > write down some notes. Some people are doubtless way ahead of me. > > This isn't very organized. Summary of this mail is that GnomeCanvas was > missing some very useful features a canvas can have, so I was > underestimating the value of a canvas widget. > > Among other things I've been looking at scene graph APIs, specifically > Piccolo (a 2D scene graph using Java2D): > http://www.cs.umd.edu/hcil/piccolo/ > and Java3D: > http://java.sun.com/products/java-media/3D/ > > Piccolo is BSD-license. Java3D be careful with since it has a > noncommercial use license, I avoided looking at source code or Sun > specs. > > There's Avalon also I suppose but I haven't read recent things about it. > > I see Piccolo was cited here: > http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00071.html > > So random thoughts. > > 1. 2D vs. 3D (Cairo vs. GL) seems like a tricky question >that we also face on the compositing manager level. >Do we want two entirely different scene graph APIs >for this? Or one grand unified scheme where you can >put Cairo-on-Glitz into flat portions of the 3D graph? > >Possibility: a hybrid approach which is an OpenGL scene >but designed for a mostly-2D desktop UI. i.e. a not-very-rich 3D >API, and convenience weighted toward 2D. Not sure what this >means. > > 2. Animations. Scene graph APIs make it simple to say >"this object should move back and forth" or whatever. They have >built-in stock animations such as animated affine transforms >(translation, shrinking, etc.) Very useful for smoother >and snazzier UIs. > > 3. Behaviors. It should be trivial to implement "object is >draggable by mouse" for example without writing your >own event handler. > > 4. Widget embedding. Absolutely critical to using the canvas >for real-world UI. The widget embedding can't be broken >as in GnomeCanvas or it isn't useful; layering and events must work >properly. Affine transforms probably should work properly, and >when you think about animations (minimization, etc.) could even be >useful. > > 5. Multiple views. Sometimes useful, needs to be designed-in. >Should probably be item-by-item rather than for an entire >tree of items... > >Multiple views means that you can have 1-1 mapping from >application data objects to canvas nodes. > > 6. Path item. In C at least it's easier to do this: > path = path_item_new(); > cairo_t* state = path_item_get_cairo(); > cairo_line_to(state, ...); > cairo_line_to(state, ...); >Than to create piles of Line items. Also, piles of >Line items won't get the joins right and won't be as >efficient. > > 7. Usable for a compositing manager. This should not really >be very hard, I don't think. > > 8. Data/markup form of the graph; with a GUI editor usable >by an artist. > > 9. Layouts. Parent nodes should have "layout policies" that can >be applied to their child nodes (stack, tile, springs-and-struts, >hbox, whatever). > > The basic idea here would be to make high-quality custom displays much > easier to implement. One kind of custom display is the > window/compositing manager; another is the "middle" of most main > application windows (whether presentation app, UI builder, graphing > calculator, or whatever it is); another might be panel applets or > gdesklets-style thingies. All these ideas are interesting IMHO. I'd add at least printing and svg export for 2D items (hopefully cairo will help). Now, the main point is that we need to rewrite a canvas widget since the current one will be soon deprecated. Now that gtk+-2.8.0 is available, I feel it is time to start working on it and avoid to depend on both cairo and libart, cairo is enough. I am willing to participate with my modest competencies. Anyway, I need a functional canvas for my app (GChemPaint). Hope others will join ;-) Best regards, Jean -- Jean Bréfort <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I thought that gtkCanvas would be in gtk 2.8?
Le vendredi 22 juillet 2005 à 15:42 +0200, Kristof Vansant a écrit : > Or did I miss it's inclusion somewhere? > > lupusBE (Kristof Vansant Belgium) I am not aware of that. But much interested. Is there already some code? How can I participate? Cheers, -- Jean Bréfort <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
