Re: Element in GTK which can be used for graphs
Hi, My be goffice has what you need. It is used by gnumeric for the graphs and more. You can find simple samples in the tests directory. https://gitlab.gnome.org/GNOME/goffice Hope this helps, Jean Le lundi 05 novembre 2018 à 00:40 +0100, bouke haarsma via desktop- devel-list a écrit : > Dear all, > > I am currently working on a tool to monitor and overclock a graphics > card with Python3+GTK. As part of the monitoring tool, I have been > using the python matplotlib library. However, I am looking for a > graph type element which integrates better inside all the GTK3 > widgets I use. I was hoping some of you could maybe help to guide me > towards this. What, well supported, options do I have to do this? > > For those of you interested what the project is. You can find it > here: https://github.com/BoukeHaarsma23/WattmanGTK > > Thanks in advance! > > Kind regards, > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: check your grid spacings
May be it would have been wiser to fix the documentation instead of breaking a lot of code. Best regards, Jean Le mercredi 21 septembre 2011 à 06:50 -0400, Matthias Clasen a écrit : > Hi, this commit: > > http://git.gnome.org/browse/gtk+/commit/gtk/gtkgrid.c?id=d717a2dcfc8603561f8a0f78982244e8b8fd9006 > > fixed GTK+ to interpret GtkGrid spacing properties as documented. > This change has happened in GTK+ 3.1.18. > > We've seen a number of modules affected by this, so here is a general > call to action: > > If your modules is using GtkGrid, please check your row and column spacings. > > > Matthias > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: FooCanvas for 3.0?
Hi, Gnumeric does not use FooCanvas anymore. Regards, Jean Le jeudi 06 mai 2010 à 11:46 +0200, Johannes Schmid a écrit : > Hi! > > As many of you probably know, GnomeCanvas is the only component that has > no replacement for 3.0 while being deprecated for some time. There was > kind of a discussion not to include any full-featured Canvas in the > future in the GNOME platform. > > However, in the current state nautilus and gnumeric already include the > FooCanvas sources. FooCanvas is a stripped down version of GnomeCanvas > with better integration into Gtk2 drawing cycle (according to Alex). > Currently we are discussing if we include FooCanvas in anjuta, too, to > get back the class-browser from anjuta-extras to anjuta. So, this will > make 3 modules inluding the source. In the evolution GnomeCanvas bug [1] > they also prefer FooCanvas, so I count 4. > > Wouldn't it make sense to include this as a standalone module to be used > as a simple canvas inside GNOME instead of copying the source around? > > Regards, > Johannes > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
RE: Appearance properties
+1 Le mardi 10 novembre 2009 à 10:28 +0100, Uros Nedic a écrit : > I'm also concerned regarding that process. My proposal is that > developers should enable in Appearance menu some configuration > options regarding this issue. > > > It is not so hard to implement. > > > Uros > > > --- > "Every kind of peaceful cooperation among men > is primarily based on mutual trust and only > secondarily on institutions such as courts of > justice and police." > > - Albert Einstein (1879 - 1955) > > > > > Subject: Appearance properties > > From: xclae...@gmail.com > > To: desktop-devel-list@gnome.org > > Date: Tue, 10 Nov 2009 10:18:36 +0100 > > > > Hi, > > > > In GNOME 2.28 some default settings changed for the desktop: > > 1) In toolbar, text is next to icon instead of below. > > 2) Icons got removed from menus. > > 3) Icons got removed from action buttons in dialogs. > > > > 1 and 2 were still configurable from gnome-appearance-properties, 3 > was > > not possible to change (Bug #595341). > > > > And now the whole interface tab was dropped. Making 1, 2 and 3 not > > configurable anymore (Bug #592756). > > > > Am I the only one to think something really insane is happening? It > > seems all those decisions are taken by a few developers that like > > that... This impact the whole desktop and is very visible to all > users, > > so I think the discussion should be wider. That's why I'm posting > here. > > > > So if you agree/disagree with those changes, please tell your > opinion! I > > would like to know if I'm the only one to be worried. > > > > Regards, > > Xavier Claessens. > > > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > __ > Windows Live Hotmail: Your friends can get your Facebook updates, > right from Hotmail®. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GnomeGoal: use GSEAL macro
I don't think it is a so good idea as long as many accessors are still missing. GTK_WIDGET_REALIZED and friends do not work anymore (at least with gtk+-2.16.x). Regards, Jean Le lundi 08 juin 2009 à 00:34 +0200, Andre Klapper a écrit : > Am Samstag, den 06.06.2009, 15:28 +0200 schrieb Javi: > > I'd like to propose a new GnomeGoal and it'd be > > great hear your opinion. > > > > [2] http://live.gnome.org/GnomeGoals/UseGseal > > I'm all for it - it's needed for GNOME 3 anyway and it's time to make > maintainers aware of it. > > andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Le lundi 06 avril 2009 à 17:10 +0300, Stefan Kost a écrit : > Andre Klapper schrieb: > > Ahoj, > > > > a draft for the GNOME 2.27 & 2.29 schedule is now available at > > > > http://live.gnome.org/TwoPointTwentyseven . > > > > The schedule also includes a plan to clean up the platform by getting > > rid of deprecated modules. > > Maintainers can see the GNOME 3 readiness of their modules on Frederic's > > awesome status page at http://www.gnome.org/~fpeters/299.html . > > Comments & discussion welcome. > > > I woner what we will do with gnome-canvas? I don't think we should > deprecate it without an official alternative and some migration > support/guide. If nothing uses it anymore in the official gnome modules (btw, did something used it?), deprecate it. It is almost unmaintained, AFAIK. Of course, there is no official alternatives, but I don't think there will be one in a foreseeable future. Just defining what it should do will be quite difficult since there seems to be so many divergent opinions among the community. And even if somebody is able to write a multipurpose canvas, it might not fulfill everybody's needs. For my use case, I tested libccc and goocanvas, and in the end it took me less time to write a new widget from scratch with all the features I need and just these. Best regards, Jean > Stefan > > Notes: > > * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general > > GNOME 3 debate, please see other threads like Vincent's recent > > posting at > > > > http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html > > and > > http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html > > ). I don't plan to cover everything+1 in this schedule, it's just that I > > concentrated on platform streamlining.) > > * Only two maintenance releases for 2.28.x > > * Early module freeze for 2.30 > > * More & earlier 2.29.x releases than normally (better testing) > > * Two weeks hardcode freeze before 2.30.0 - late release at the > > last day of march 2010 > > * Still to discuss: dconf vs gconf. This is not yet covered by > > this plan, but crucial to discuss (as gconf depends on Bonobo) - > > robtaylor and/or desrt will probably elaborate its current > > state. > > * Still to discuss: a11y plan for GNOME3 - see > > http://live.gnome.org/Accessibility/BonoboDeprecation > > > > > > Already know some 2.28 plans for the module you maintain? > > Add them to http://live.gnome.org/RoadMap now! > > > > andre > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Testers wanted] No tearing for libgnomecanvas
Tested with GChemPaint. Apparently no regression. It even seems to repaint better. I encountered sqome repaint issues without the patch and they seem to be gone with it :-) Jean Le mercredi 22 août 2007 à 16:14 -0500, Federico Mena Quintero a écrit : > Hi, > > Libgnomecanvas has this horrible thing where there is a lot of visible > tearing when large areas are repainted. You can see this when the GDM > greeter paints its background, and when Evolution scrolls its message > list quickly. > > The attached patch removes this tearing, and makes repainting smooth. > It works fine for me in GDM and Evolution; they look much nicer with the > patch! > > I'm pretty confident that the patch works fine in non-antialiased mode. > > I'm not that confident about AA mode, however. In the past I saw > libgnomecanvas/demos/canvas_demo repaint incorrectly in AA mode with > this patch, but now it seems to be working correctly... (I tested it > with 2.12 back then and it was buggy; now with 2.19 it seems to be > okay). > > Does anyone know of any apps that are crazy enough to use the > antialiased gnome-canvas? If so, could you please test them with this > patch to see if there are any regressions? > > Thanks, > > Federico > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First Post To A GNOME Developer Noobie
Le mercredi 03 janvier 2007 à 11:39 -0800, Redefined Horizons a écrit : > I have just subscribed to the list, and I wanted to make an > introduction. If this isn't the correct maling list at GNOME, I > apologize, and would welcome direction to the correct list. > > I have been using GNOME and Linux for the past year. I volunteer as a > Java developer for an open source project. I'd like to start learning > about GNOME and GNOME development so I can give a little back to my > favorite Linux desktop. I'm especially interested in helping with > Nautilus. > > Before I try to contribute any code to GNOME I thought it would be > wise to work through a simple GNOME application. I hope to write a > calculator program for the GNOME desktop that works with angles and > coordinates. This type of program will be handy for surveyors and > mapping professionals. After I get the kinks in this trial run worked > out, I'll try helping with Nautilus or other parts of the GNOME > Desktop. > > I've been programming for several years. I have very limited > experience with C programming, but I've got a couple of good books on > the language and a willingness to learn. I've also got several books > that have been published on GTK and GNOME. However, I'm sure I'll have > lots of questions. > > My first question is this: > > If I am writing code for the "back-end" of my GNOME Application, > should I use GLIB types and try to extend GObject whenever possible, > or is this only required for the GUI code? It's just required for the GUI code if you create custom widgets. > For example, I'll be creating an "object" to represent angles. Should > I do this with a regular C struct, or should I subclass GObject? Both things are possible. If using GObject helps you, especially with memory management (ref/unref), use it, but it is not mandatory. > My second question is this: > > Where can I find user interface design guidelines for GNOME? You ca consult the Human Interface Guidelines (HIG) at: http://developer.gnome.org/projects/gup/hig/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Gnome-OCR] Integration of Tesseract-OCR...
Le lundi 27 novembre 2006 à 11:22 +0100, Emmanuel Fleury a écrit : > Jean Bréfort wrote: > > Le lundi 27 novembre 2006 à 10:55 +0100, Emmanuel Fleury a écrit : > > > >> I don't know exactly what should be the API and what could be the usage > >> of such library but with the help of Étienne Bersac (the author of > >> libgnome-scan) I though about few examples: > >> - A plug-in for Abiword (outputting also formatting informations); > > > > Great idea, you should contact the abiword developers > > > > Hum, there must have been some misunderstanding. The Abiword plug-in is > not really the goal of the project. It would be more a long term > consequence of it. There is no misunderstanding. I did not think it would be possible for abiword-2.6, but may be 2.8? > I think we should first focus on the development of libgnome-ocr before > starting to write plug-ins. :) > > Regards > -- > Emmanuel Fleury | Office: 261 > Associate Professor, | Phone: +33 (0)5 40 00 69 34 > LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69 > 351, Cours de la Libération | email: [EMAIL PROTECTED] > 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Gnome-OCR] Integration of Tesseract-OCR...
Le lundi 27 novembre 2006 à 10:55 +0100, Emmanuel Fleury a écrit : > Hi all, > > As I'm pretty new here just forgive me if I'm not at the right place. :) > > I am associate professor at Bordeaux-I university (France) and I have > submitted a project for students about integrating tesseract-OCR in > Gnome (the student project starts only in January). > > My plan is more or less to: > - make them develop a libgnome-ocr as wrapper to tesseract-OCR, > - clean the code of tesseract-OCR, > - refactor tesseract-OCR within the Gnome libs and, > - try to add some extra features. > > (I think the students will stop at the first item but we never know !) > > I don't know exactly what should be the API and what could be the usage > of such library but with the help of Étienne Bersac (the author of > libgnome-scan) I though about few examples: > - A plug-in for Abiword (outputting also formatting informations); Great idea, you should contact the abiword developers > - A plug-in for e-mail readers (image spam analysis); > - ... and so forth ... > > I guess, that the API should include an initialization function, setting > the image input format, the output format plus some settings > (recognition strategy, drawing recognition, where to store the output, etc). > > For now, waiting for the start of the project in January I'm trying to > port Tesseract-OCR to 64bits plate-forms... and I'm a bit horrified by > the way they handle basic types and data-structures... My guess is that > a lot of cleaning is needed there. :-/ > > Anyway, is this project interesting for the Gnome community, would you > have comments, advices or objections ? > > Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I18n in plugin
Le lundi 22 mai 2006 à 14:06 +0800, Yang Hong a écrit :
> Hi all,
>
> There are many applications use plugin based architecture to expand it's
> function, such as Evolution (EPlugin), Anjuta 2.x, Gedit, Gaim,
> Xchat-gnome, etc. The problem is that if the plugins was released
> outside of the main app, the user interface of the plugin is NOT I18n
> able. even I added bindtextdomain(...) and bind_textdomain_codeset (...)
> in the initialize code of the plugin.
>
> In my anjuta-foobar-plugin [1]:
>
> static void
> anjuta_plugin_foobar_instance_init (GObject *obj)
> {
> AnjutaFoobarPlugin *plugin = (AnjutaFoobarPlugin*)obj;
>
> bindtextdomain (GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR);
> bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
> /* textdomain (GETTEXT_PACKAGE); */
>
> plugin->uiid = 0;
> plugin->widget = NULL;
>
> }
>
> You cann't use textdomain (...) in a plugin, or you'll get all NEW
> interface in english (un i18ned).
I don't see why. I do that quite often and it work. The trick is to
include gi18n-lib.h instead of gi18n.h
> Yestoday, I got a remove-duplicates plugin for evolution 2.4 from
> #342378 [2], after some hack it for evolution 2.6, added LINGUAS suport,
> added zh_CN translate [3], intalled it and got a untranslate menu item
> "Remove duplicates". and then I found that there is even not point to
> add the bindtextdomain for it, there's only one entrance for this
> plugin's functional. how can it could be i18ned?
>
> void
> org_gnome_duplicates_remove (EPlugin *ep, EMPopupTargetSelect *target)
> {
> handle_messages (target->folder, target->uids);
> }
>
> [1]
> http://www.gnome-cn.org/software/anjuta-plugin-foobar/releases/0.1/anjuta-plugin-foobar-0-1-tar.gz
> [2] http://bugzilla.gnome.org/show_bug.cgi?id=342378
> [3]
> http://www.gnome-cn.org/software/remove-duplicates-plugin/releases/0.0.3/remove-duplicates-plugin-0-0-3-tar.gz
>
> any comments?
>
> Yang Hong
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [BUG?] Issues in recent doc switch for gnome-panel
Le mercredi 20 juillet 2005 à 12:10 +0200, Vincent Untz a écrit : > Hi Luca, > > On Wed, July 20, 2005 10:17, Luca Ferretti said: > > I'm porting Italian user's guide in gnome-panel package to recently > > switched gnome-doc-utils. There are 3 issues: > > > > 1. Figures are not installed. See the console log[1] for clock. In > > Makefile there are those entries[2], but no DOC_FIGURES is > > declared. So I suppose it depends on some Makefile.am missing, > > but I did't explore it deeply. > > Looks like a gnome-doc-utils problem (?). I encountered the same problem and filed a bug report (#311007) -- Jean Bréfort <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
