Re: The Future?

On Wed, 13 Mar 2019 at 16:16, Igor Korot wrote: > >> How about porting recent GTK version to OpenVMS? > > > > > > If you want to add a new platform to GTK, you will need to: > > Here is the problem - it is not a new port. > The last version of GTK+ on OpenVMS is GTK+1.x. > The last GTK 1.x

Re: The Future?

Hi, On Wed, Mar 13, 2019 at 11:08 AM Emmanuele Bassi wrote: > > On Wed, 13 Mar 2019 at 15:53, Igor Korot wrote: >> >> Hi, Emmanuel et al, >> >> On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list >> wrote: >> > >> > Meta: having this discussion on gtk-list is probably the best example

Re: The Future?

On Wed, 13 Mar 2019 at 15:53, Igor Korot wrote: > Hi, Emmanuel et al, > > On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list > wrote: > > > > Meta: having this discussion on gtk-list is probably the best example as > to why we need to move to Discourse. Nobody involved with the

Re: The Future?

Hi, Emmanuel et al, On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list wrote: > > Meta: having this discussion on gtk-list is probably the best example as to > why we need to move to Discourse. Nobody involved with the development of GTK > even reads this list, except me, so you're

Re: The Future?

Thanks, very much appreciated! Ciao, Emmanuele. On Wed, 13 Mar 2019 at 13:56, Kasper Peeters wrote: > > Care to file an issue: > > > > https://gitlab.gnome.org/Infrastructure/gtk-web > > > > to update the wording? > > Done, see > >

Re: The Future?

> Care to file an issue: > > https://gitlab.gnome.org/Infrastructure/gtk-web > > to update the wording? Done, see https://gitlab.gnome.org/Infrastructure/gtk-web/merge_requests/5 Thanks, Kasper ___ gtk-list mailing list gtk-list@gnome.org

Re: The Future?

FWIW, the GJS experience is increasingly improving and keeping the pace of modern JS syntax and features, but also with react-gtk moving on top of node-gtk, hopefully more people will try to contribute to the GTK project. It sadden me to read there's no intent whatsoever to land on mobile, 'cause

Re: The Future?

On Sun, 2019-03-10 at 09:38 +, Emmanuele Bassi via gtk-list wrote: > Nobody involved with the development of GTK even reads this list, > except me, I had that impression in the last 6 years, thanks for confirming. My conclusion was, that nearly no one was working on or with GTK any more.

Re: The Future?

what you think they should be. Among those goals are the development of the Gnome desktop environment and the development of graphical Linux (and to a lesser extent, Unix) applications. I suspect that if GTK future development wasn't including shaders, animated transitions, and GL rendering, folks

Re: The Future?

On Mon, Mar 11, 2019 at 7:54 AM Jerome Flesch wrote: > Le 2019-03-10 12:01, Kasper Peeters a écrit : > >> 1. GTK is not so cross-platform anymore: on Windows and macOS, you > >> are supposed to build your own library binaries (gvsbuild for Windows > >> and jhbuild for macOS exist, but are not

Re: The Future?

Le 2019-03-10 12:01, Kasper Peeters a écrit : 1. GTK is not so cross-platform anymore: on Windows and macOS, you are supposed to build your own library binaries (gvsbuild for Windows and jhbuild for macOS exist, but are not foolproof). That's definitely not true; on Windows there's vcpkg and

Re: The Future?

I meant 'You'll need to first write"C" wrappers for C++ code'. --Sergei. On 3/10/19 7:53 PM, Sergei Steshenko via gtk-list wrote: 'Speaking of "why can't?", why can't I write a C application using Qt  ? :))' - actually, you can. You'll need to first run "C" wrappers for C++ code (for top

Re: The Future?

'Speaking of "why can't?", why can't I write a C application using Qt  ? :))' - actually, you can. You'll need to first run "C" wrappers for C++ code (for top level functions), and then you can write in "C". And using LLVM other forms of language integration is possible. --Sergei. On 3/9/19

Re: The Future?

> Care to file an issue: > > https://gitlab.gnome.org/Infrastructure/gtk-web > > to update the wording? Sure, no problem. Cheers, Kasper ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

On Sun, 10 Mar 2019 at 11:02, Kasper Peeters wrote: But for the 'big picture documentation', which includes up-to-date > instructions on how to get it up and running on all platforms. Why > gtk.org does not even seem to mention vpckg and Homebrew is a mystery > to me, and seems easy to fix. >

Re: The Future?

> 1. GTK is not so cross-platform anymore: on Windows and macOS, you > are supposed to build your own library binaries (gvsbuild for Windows > and jhbuild for macOS exist, but are not foolproof). That's definitely not true; on Windows there's vcpkg and on macOS there is Homebrew; both let you

Re: The Future?

Meta: having this discussion on gtk-list is probably the best example as to why we need to move to Discourse. Nobody involved with the development of GTK even reads this list, except me, so you're never going to get more than my opinion about it. Meta × 2: while I am employed by the GNOME

Re: The Future?

I think the question is a valid one and there is a plenty of evidence of people moving to Qt due to some issues of GTK. Some notable examples: - VLC (https://ubuntuforums.org/showthread.php?t=316155=54b259f2cb2d1a30ca8dc269d0561537) - Wireshark

Re: The Future?

On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list wrote: > > 2. How does Gtk address the issue of its users moving to Qt? > What evidence is there of this? Who are the "users" of GTK that you're referring to? Moving an existing GUI app between toolkits is typically almost equivalent to a

The Future?

Hello, I understand that these questions could have been asked a number of times, but still, my questions are- 1. Will Gtk ever start its support for Mobile platform? 2. How does Gtk address the issue of its users moving to Qt? 3. What makes them move to Qt? Why can't Gtk have that respective

Re: GTK_MODULES removal and the future of existing modules

On Sun, Feb 25, 2018 at 4:11 AM, Philipp Emanuel Weidmann < p...@worldwidemann.com> wrote: > Greetings, > > I am the author of Plotinus[1], a GTK+ module that provides a > searchable command palette to GTK+ applications. Recently, it was > brought to my attention[2] that module loading has been

Re: GTK_MODULES removal and the future of existing modules

On 26 February 2018 at 13:17, Philipp Emanuel Weidmann wrote: > Thank you for the quick response! > > I'm not sure anything short of direct access to the widget tree would > suffice for a GTK4 version of Plotinus to provide the functionality it > does today on GTK3. Which

Re: GTK_MODULES removal and the future of existing modules

Thank you for the quick response! I'm not sure anything short of direct access to the widget tree would suffice for a GTK4 version of Plotinus to provide the functionality it does today on GTK3. The problem is that in practice, some of the most important applications use GTK in an "incomplete"

Re: GTK_MODULES removal and the future of existing modules

Hi; On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann < p...@worldwidemann.com> wrote: > Greetings, > > I am the author of Plotinus[1], a GTK+ module that provides a > searchable command palette to GTK+ applications. Recently, it was > brought to my attention[2] that module loading has been

GTK_MODULES removal and the future of existing modules

Greetings, I am the author of Plotinus[1], a GTK+ module that provides a searchable command palette to GTK+ applications. Recently, it was brought to my attention[2] that module loading has been removed[3] on GTK+ master. It appears that this change could mean the end for Plotinus and other

Re: Past and future evolution of Gtk+

On 09/18/2017 09:03 AM, Carsten Mattner wrote: > Qt5 and GTK3 both seem to be very hard to write a Hello World > X11 or Wayland window that uses less than 25MB to 30MB. > This is something that can quickly become a problem and > deal breaker if you want to run more than a few GUI applications.

Re: Past and future evolution of Gtk+

On 09/18/2017 07:39 AM, Carsten Mattner wrote: > Ian, Qt and FLTK have GUI builders and FLTK generates code, not markup. > Qt is used heavily with the declarative variant QML in entertainment > systems of cars and such. If QML is something that works for you > and the licensing is compatible, then

Re: Past and future evolution of Gtk+

Sorry, wrong message. On Mon, Sep 18, 2017 at 11:04 AM, Carsten Mattner wrote: > On 9/18/17, Igor Korot wrote: >> On Mon, Sep 18, 2017 at 10:53 AM, Carsten Mattner >> wrote: >>> Thanks Igor for the wxWidgets clarification.

Re: Past and future evolution of Gtk+

On 9/18/17, Igor Korot wrote: > On Mon, Sep 18, 2017 at 10:53 AM, Carsten Mattner > wrote: >> Thanks Igor for the wxWidgets clarification. > > NP. > After 7 years working with the library, submitting patches to it and > doing development with it I

Re: Past and future evolution of Gtk+

One difference to take into account is how much memory overhead the different toolkits have. Responsiveness these days is mostly down to drawing and input architecture. For instance GTK3 does not behave smoothly when used with a different than GNOME3 or no compositor at all, while curiously Qt5

Re: Past and future evolution of Gtk+

t;>>> >>>> Point 1 >>>> >>>> In glade I can select GtkMenuItem and GtkImageMenuItem and when I look >>>> at the GTK+ 3 Reference Manual the latter is depreciated. It's working >>>> great so I wonder what depreciated actually

Re: Past and future evolution of Gtk+

>>> In glade I can select GtkMenuItem and GtkImageMenuItem and when I look >>> at the GTK+ 3 Reference Manual the latter is depreciated. It's working >>> great so I wonder what depreciated actually implies? At some time in the >>> future will it vanish and w

Re: Past and future evolution of Gtk+

subject. > > Point 1 > > In glade I can select GtkMenuItem and GtkImageMenuItem and when I look > at the GTK+ 3 Reference Manual the latter is depreciated. It's working > great so I wonder what depreciated actually implies? At some time in the > future will it vanish and wo

Re: Past and future evolution of Gtk+

and when I look at the GTK+ 3 Reference Manual the latter is depreciated. It's working great so I wonder what depreciated actually implies? At some time in the future will it vanish and working software will fail or simply fail to compile on the newer distribution? Point 2 Lots of acronyms were

Re: Past and future evolution of Gtk+ (was: How to get a "traditional" file-chooser)

1) this is the wrong mailing list 2) it has been made clear many, many, many times that, largely as a result of the developers of GTK+ largely being associated with the GNOME project, the development priorities reflect what GNOME needs/wants. 3) no other community of interest has stepped up to

Past and future evolution of Gtk+ (was: How to get a "traditional" file-chooser)

Le nonidi 29 fructidor, an CCXXV, Daniel Kasak a écrit : > Come on. It's troll bait. I am very sure you will consider this mail troll bait too, but I assure you it is not, and an honest reading of its contents, with the definition of troll in mind, will show that it is not. This thread shows a

Application development for MS Windows now and in the future

Hello, I was warned about possible near future problems with my software. I use mingw and GTK+ to make software for current MS Windows to be used with the hardware I make. I just learned about Windows 10 S and I was warned that applications not build with MS tools may soon lack the API

will gobject-introspection build system migrate to cmake or meason in the future?

Hi, I am a fun of python and gtk, I want to port gobject-introspection to windows, the current manul update VS project make upstream a little hard. Will gobect-introspection migrate to a modern and cross platform friendly solution like cmake or meason in the near future? And when

about the future deprecation of style properties

Hi, I have read that the usage of custom style properties in Css ( **gtk_widget_class_install_style_property ) will be deprecated. sources: http://stackoverflow.com/questions/31075437/methods-to-install-custom-style-properties-in-gtk-widgets https://wiki.gnome.org/Projects/GTK+/Roadmap In

Re: gnome in the future?

Ok, but the port and the themes for windows? also the recent version of Gtk enabling animations is also a problem. Compiling Gtk+ on windows is very hard when using MinGw Le Lundi 6 octobre 2014 16h11, Matthias Clasen matthias.cla...@gmail.com a écrit : It is hard to know what to reply to

gnome in the future?

Hello, I have a big problem with the future of Gnome. It seems that ubuntu want to completly goes to Qt So what about Gtk?... Gtk3 is good but there is a leak of animation, no support of embeded environment and the support of different resolution the design has to evolved...Gtk is very very simple

Re: gnome in the future?

It is hard to know what to reply to this. GTK+ is not going away. A large part of what we've been doing over the last few years is about enabling animations, and adding animations to core widgets. Bindings are available and work well for the most part.

Re: future of development for the desktop

On Tue, 12 Jun 2012 00:43:28 +0200 Enrico Weigelt weig...@metux.de wrote: * Gour g...@atmarama.net wrote: Found it...it talks about gtk3 2x slower than gtk2 which I really did not notice and cannot say how good that benchmark is to reflect real speed. Well, AFAIK, gtk had become much

Re: future of development for the desktop

* Gour g...@atmarama.net wrote: Found it...it talks about gtk3 2x slower than gtk2 which I really did not notice and cannot say how good that benchmark is to reflect real speed. Well, AFAIK, gtk had become much more dynamic than its older versions. Maybe that's the problem: too many dynamic

Re: future of development for the desktop

On Mon, Jun 11, 2012 at 6:43 PM, Enrico Weigelt weig...@metux.de wrote: * Gour g...@atmarama.net wrote: Found it...it talks about gtk3 2x slower than gtk2 which I really did not notice and cannot say how good that benchmark is to reflect real speed. Well, AFAIK, gtk had become much more

Re: future of development for the desktop

On Mon, Jun 11, 2012 at 6:43 PM, Enrico Weigelt weig...@metux.de wrote: * Gour g...@atmarama.net wrote: Found it...it talks about gtk3 2x slower than gtk2 which I really did not notice and cannot say how good that benchmark is to reflect real speed. Well, AFAIK, gtk had become much more

Re: future of development for the desktop

* Paul Davis p...@linuxaudiosystems.com wrote: Well, AFAIK, gtk had become much more dynamic than its older versions. Maybe that's the problem: too many dynamic (heap) allocations, lookups, etc, etc. hmm, what could we possibly do about it ? measuring it would

Re: future of development for the desktop

On Mon, Jun 11, 2012 at 7:38 PM, Enrico Weigelt weig...@metux.de wrote: * Paul Davis p...@linuxaudiosystems.com wrote: Well, AFAIK, gtk had become much more dynamic than its older versions. Maybe that's the problem: too many dynamic (heap) allocations, lookups, etc,

Re: future of development for the desktop (C++ vs C)

Is gtk+ 3.*.* now faster than the latest gtk+-2.*.* ? If not, since even gtk+-2.*.* is slower than Qt, gtk+ loses. ... Here is another thread: http://stackoverflow.com/questions/1887070/what-should-i-choose-gtk-or-qt . FWIW, Qt now also is LGPL. I wouldn't mind giving Qt a trial but I

Re: future of development for the desktop (C++ vs C)

- Original Message - From: Marshall Lake ml...@mlake.net To: gtk-list@gnome.org Cc: Sent: Saturday, May 26, 2012 4:26 PM Subject: Re: future of development for the desktop (C++ vs C) Is gtk+ 3.*.* now faster than the latest gtk+-2.*.* ? If not, since even gtk+-2

future of development for the desktop

/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/ http://www.reddit.com/r/programming/comments/u3pqj/microsoft_pulling_free_development_tools_for/ It looks that OS vendors are greedy to lock their platforms more more, so the question arises what is the future

Re: future of development for the desktop

their platforms more more, so the question arises what is the future for open-source development of desktop apps on Windows Mac OS X platforms? If it is not so bright, then it might be easiest/simplest to simply forget about those platforms, focus on Linux and develop using GTK+ and let users

Re: future of development for the desktop

On Fri, 25 May 2012 19:08:30 +0300 Dov Grobgeld dov.grobg...@gmail.com wrote: Will that be possible for Windows 8, or is Microsoft going the Apple way of requiring developers to do some kind of proprietary signing of the applications before you can distribute your software to end users?

Re: future of development for the desktop

On Fri, 25 May 2012 09:22:55 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote: Nowadays there is QML ( http://en.wikipedia.org/wiki/QML ) and in my opinion, though I do not know Javascript, it can be compared to Perl (e.g. closures are present), so today I'd probably choose Qt + QML.

Re: future of development for the desktop

- Original Message - From: Gour g...@atmarama.net To: gtk-list@gnome.org Cc: Sent: Friday, May 25, 2012 7:40 PM Subject: Re: future of development for the desktop On Fri, 25 May 2012 09:22:55 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote: Nowadays there is QML

Re: future of development for the desktop

On Fri, 25 May 2012 09:49:28 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote: Still, since we are discussing bare-naked gtk+, I am re-asking my question: in what aspects gtk+ is better than Qt ? Especially, since we already know it (used to be ? still is ?) slower tan Qt. I simply

Re: future of development for the desktop

wrote: - Original Message - From: Gour g...@atmarama.net To: gtk-list@gnome.org Cc: Sent: Friday, May 25, 2012 7:40 PM Subject: Re: future of development for the desktop On Fri, 25 May 2012 09:22:55 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote:  Nowadays

Re: future of development for the desktop

- Original Message - From: Gour g...@atmarama.net To: gtk-list@gnome.org Cc: Sent: Friday, May 25, 2012 7:56 PM Subject: Re: future of development for the desktop On Fri, 25 May 2012 09:49:28 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote: Still, since we

Re: future of development for the desktop

From: Kevin Anthony kevin.s.anth...@gmail.com To: Cc: gtk-list@gnome.org Sent: Friday, May 25, 2012 7:59 PM Subject: Re: future of development for the desktop Sergei, what metric are you using to base slowness on?  [snip] I am reading this list - see

Re: future of development for the desktop

On Fri, 25 May 2012 09:58:35 -0700 (PDT) Sergei Steshenko sergst...@yahoo.com wrote: Will you search this list archives yourself or need a link from me ? Found it...it talks about gtk3 2x slower than gtk2 which I really did not notice and cannot say how good that benchmark is to reflect real

Re: future of development for the desktop

7:59 PM Subject: Re: future of development for the desktop Sergei, what metric are you using to base slowness on? [snip] I am reading this list - see my a little bit earlier reply for details. Regards,   Sergei. ___ gtk-list mailing list gtk

Re: future of development for the desktop

- Original Message - From: Jasper St. Pierre jstpie...@mecheye.net To: Sergei Steshenko sergst...@yahoo.com Cc: Kevin Anthony kevin.s.anth...@gmail.com; gtk-list@gnome.org gtk-list@gnome.org Sent: Friday, May 25, 2012 8:12 PM Subject: Re: future of development for the desktop

Re: future GTK+ rendering to browser

* Andre Osku Schmidt andre.osku.schm...@osku.de wrote: i mean, through javascript, that is... and yeah, not that big drawback in general, but was for me yesterday... As it should be. I'd feel very scared if my browser would allow local clipboard access to arbitrary webapps. cu --

Re: future GTK+ rendering to browser

* shakil anwar s...@emailwhale.com wrote: Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : - More bandwidth efficient way to provide remote and multi-user interfaces than VNC, NX. - Would enable web-enabling of existing

Re: future GTK+ rendering to browser

On Mon, 2010-04-05 at 21:18 +0100, a lister wrote: Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : and what i found out yesterday would be a pretty big drawback: - there is no cross-browser way to copy text to systems

Re: future GTK+ rendering to browser

On Sat, 2010-04-10 at 11:43 +0200, Andre Osku Schmidt wrote: On Mon, 2010-04-05 at 21:18 +0100, a lister wrote: Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : and what i found out yesterday would be a pretty big

Re: future GTK+ rendering to browser

Hi all, Is possible develop complex web systems with this API? Complex as PHP/AJAX/JS. 2010/4/6 Michael Torrie torr...@gmail.com: On 04/05/2010 08:34 AM, shakil anwar wrote: Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : In

Re: future GTK+ rendering to browser

On 04/07/2010 11:25 AM, frederico schardong wrote: Hi all, Is possible develop complex web systems with this API? Complex as PHP/AJAX/JS. What do you mean? With API are you referring to? I don't mean GTK should generate the HTML (the web interface). Only that GTK apps could (depending on

future GTK+ rendering to browser

Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : - More bandwidth efficient way to provide remote and multi-user interfaces than VNC, NX. - Would enable web-enabling of existing apps. rather than having to create a web UI from

Re: future GTK+ rendering to browser

Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : - More bandwidth efficient way to provide remote and multi-user interfaces than VNC, NX. - Would enable web-enabling of existing apps. rather than having to create a web

Re: future GTK+ rendering to browser

On 04/05/2010 08:34 AM, shakil anwar wrote: Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : In practice conventional desktop apps don't translate directly to the web very well, even with things like ajax. Hence you're unlikely

future GTK+ rendering to browser

Hi, Is there anyone working on or planning to create a way to render GTK+ UI's in a browser ? The benefits would be : - More bandwidth efficient way to provide remote and multi-user interfaces than VNC, NX. - Would enable web-enabling of existing apps. rather than having to create a web UI from

gtk canvas future

Hi, It's about time to ask if any headway has been made on a new canvas? Any thoughts on http://live.gnome.org/ProjectRidley/CanvasOverview ? I did like the GooCanvas, but it seems the developer has something better to do no more development. I prefer the c style of goo, rather than the

Future GTK+ projects and 1.18 new features page

Hello, I've recollected some info about future GTK+ features that people is now developing. I'd like to share this info, maybe It's useful for someone: [1] (I can move it to [2] if you want) Also, I think that would be great create a page with the new features of the future 2.18 GTK+ version

Current status of GtkPlug/GtkSocket and plans for the future

Hi, I am a planner developper, currently doing technical writing for a customer (in a chapter about GNOME). I recently discovered GtkPlug/GtkSocket and I have a few questions to ask before I talk about it in the book. 1 - Has GtkPlug/GtkSocket really been accepted in the GNOME landscape? How

RE: Current status of GtkPlug/GtkSocket and plans for the future

- From: gtk-list-boun...@gnome.org [mailto:gtk-list-boun...@gnome.org] On Behalf Of Alexandre Franke Sent: Tuesday, August 18, 2009 12:25 PM To: gtk-list@gnome.org Subject: Current status of GtkPlug/GtkSocket and plans for the future Hi, I am a planner developper, currently doing technical

Printing dialog without 'Print' button, to collect printing settings for future usage. Is it possible ?

Just like GtkPageSetup* gtk_print_run_page_setup_dialog(...) which returns GtkPageSetup, i need GtkPrintSettings* gtk_print_run_print_settings_dialog(...) which would return GtkPrintSettings. And here is a scenario I'd like to achieve: User selects printing settings, modifies and

Padding for future expansion

When looking at some GTK widgets, you see things like... void (*_gtk_reserved0) (void); Why is it necessary to reserve the space for them? Why not just add the functions when new versions come out? -- - Micah Carrick Developer - http://www.micahcarrick.com GTK+ Forums -

Re: Future of GtkTooltips

Owen Taylor schrieb: Have you read the thread from: http://mail.gnome.org/archives/gtk-devel-list/2004-October/msg00099.html ? I'm not sure we came up with a decent design there, but there are several concrete proposals. To answer the question to be posted in advance: ;-) No I did not invest any

Re: Future of Canvas on GTK+ (and probably GNOME)

On Feb 11, 2005, at 3:21 PM, Havoc Pennington wrote: An important question is what a canvas widget is for. In the GNOME 1.x days, GnomeCanvas was used to implement a lot of custom widgets. However, in GNOME 2.x that is very uncommon; because of accessibility concerns and because GTK+ itself

Future of GtkTooltips

Problems - in short - with the current tooltip system: - Not flexible enough (only plain text can be set) - Unable to set popup location - Exposes too many internals (GtkTooltipsData, tip_text, tip_private) without getters/setters Proposed resultions: Flexibility: - Use either GtkTextBuffer

Re: Future of GtkTooltips

On Wed, 2005-02-09 at 12:23, Christian Neumair wrote: Problems - in short - with the current tooltip system: - Not flexible enough (only plain text can be set) - Unable to set popup location - Exposes too many internals (GtkTooltipsData, tip_text, tip_private) without getters/setters

Future of Canvas on GTK+ (and probably GNOME)

for a new canvas library (possibly basead on Cairo)? What's the future of canvas in GTK+ and GNOME? Regards, Fabrcio [0] http://live.gnome.org/ThreePointZero [1] http://diacanvas.sourceforge.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

future windows port availability

Hi, after some technical evaluation our company is to decide whether to use GTK or another toolkit for it's software tools. Of course, not only technical aspects are of importance. An important point is GTK's availability in the future, especially concerning the windows port, which is (by far

Re: gtk_paint_string future

will the gtk_paint_string be in Gtk+? I know gtk_paint_string is deprecated but it seems to be the only thing that can make my app usable. Can I count on it in future? I also know that with gtk_paint_string there's no bi-di, antialiasing, etc. but I'd give all these for fast text output. It would be much

Re: gtk_paint_string future

Da St, 2002-06-05 at 22:49, Chris Nystrom napsal: On 5 Jun 2002, Daniel Elstner wrote: I just can't stand it. That's so damn egoistic. Yes, I honestly hope others will be able to help you with the performance problems. But performance reasons just can't be taken as an excuse for not

Re: gtk_paint_string future

Matej Knopp [EMAIL PROTECTED] writes: I can hardly imagine the rendering could undertake some significant optimization without huge increasing of the memory consumption. I've mentioned the other possible optimizations but I don't dare to do it myself (I'm not a GtkTreeView hacker...).

gtk_paint_string future

will the gtk_paint_string be in Gtk+? I know gtk_paint_string is deprecated but it seems to be the only thing that can make my app usable. Can I count on it in future? I also know that with gtk_paint_string there's no bi-di, antialiasing, etc. but I'd give all these for fast text output. I've also some comments

Re: gtk_paint_string future

cannot be represented in an 8bit encoding? So my question is: How long will the gtk_paint_string be in Gtk+? I know gtk_paint_string is deprecated but it seems to be the only thing that can make my app usable. Can I count on it in future? I also know that with gtk_paint_string there's no bi

Re: gtk_paint_string future

On 5 Jun 2002, Daniel Elstner wrote: I just can't stand it. That's so damn egoistic. Yes, I honestly hope others will be able to help you with the performance problems. But performance reasons just can't be taken as an excuse for not using Unicode. If the performance is unacceptable,

Re: Future of GTK

D-Man [EMAIL PROTECTED] writes: Currently GTK is primarily for Unix and Unix-like operating systems. Is it the intention that GTK (and libglade of course) will be cross-platform? Yes. The most important difference between GTK and wxWindows in this respect is that GTK will always be an