Re: The Future?

[Emmanuele Bassi via gtk-list]

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 release (1.2.10) was last released 18 years ago. Compared
to the existing GTK code base—both in the stable (3.24) and master
(4.0-pre) branches—is a completely different project.


> There was an effort to upgrade GTK+ for OpenVMS, but unfortunately it
> failed.
>

Not much we can do about that.


> Now out of curiosity - do you have access to OpenVMS?
>

No. Which is why I wrote:

>  - ensure that GTK master and gtk-3-24 build on it
> >  - open merge requests for every needed fix, if any
> >  - add a GitLab CI runner, so that we can test every commit and merge
> request on that platform, and ensure we don't regress
>

These are the *minimum* requirements for any support to exist. We'd also
need somebody knowledgeable with the OpenVMS platform to keep things
working when the build changes.

I assume OpenVMS still uses X11, so there's no need for a separate
windowing system, but of course every platform has its own quirks, so
everything that GTK depends upon will need to work on OpenVMS.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Igor Korot via gtk-list]

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 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.
>>
>> What is "Discourse"?
>
>
> Announcement of the Discourse instance, sent to this list: 
> https://mail.gnome.org/archives/gtk-list/2019-March/msg0.html
>
> Discourse: https://discourse.gnome.org

Thank you for the link. I will look at them.

>
>>
>> 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.

There was an effort to upgrade GTK+ for OpenVMS, but unfortunately it failed.

Now out of curiosity - do you have access to OpenVMS?

Thank you.

>
>  - ensure that GTK master and gtk-3-24 build on it
>  - open merge requests for every needed fix, if any
>  - add a GitLab CI runner, so that we can test every commit and merge request 
> on that platform, and ensure we don't regress
>
> If you want to support OpenVMS, you'll have to work on it, or pay somebody to 
> work on it.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Emmanuele Bassi via gtk-list]

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 development
> of GTK even reads this list, except me, so you're never going to get more
> than my opinion about it.
>
> What is "Discourse"?
>

Announcement of the Discourse instance, sent to this list:
https://mail.gnome.org/archives/gtk-list/2019-March/msg0.html

Discourse: https://discourse.gnome.org


> How about porting recent GTK version to OpenVMS?
>

If you want to add a new platform to GTK, you will need to:

 - ensure that GTK master and gtk-3-24 build on it
 - open merge requests for every needed fix, if any
 - add a GitLab CI runner, so that we can test every commit and merge
request on that platform, and ensure we don't regress

If you want to support OpenVMS, you'll have to work on it, or pay somebody
to work on it.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Igor Korot via gtk-list]

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 never going to get more than my 
> opinion about it.

What is "Discourse"?
In the past there was a forum about GTK+ where people could come and
ask questions - it is now dead.
And this list is the only place that known to people.

>
> Meta × 2: while I am employed by the GNOME Foundation to work in GTK, this 
> *my* opinion, and should not be construed as anything but my opinion.
>
> On Sun, 10 Mar 2019 at 06:37, Miroslav Rajcic  wrote:
>>
>> 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  (https://blog.wireshark.org/2013/10/switching-to-qt/)
>>
>> - Subsurface by Linus 
>> (https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/)
>>
>> - GCompris educational software 
>> (https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html)
>
>
> VLC, Wireshark, Subsurface, and GCompris switched to Qt mostly because of its 
> support for Android and mobile platforms, something that GTK doesn't support. 
> Well, Subsurface moved to Qt because the original developers thought that 
> asking on Google Plus was the proper way to ask for help with writing GTK 
> applications, and had no objections when somebody else showed up and rewrote 
> their application using Qt.
>
> It's entirely justified to go through the ringer of a full rewrite if you're 
> thinking of expanding somewhere the GUI toolkit you use is not going to be, 
> and it's highly unlikely that an Android backend for GTK will ever 
> materialise—let alone an iOS one—so if you're thinking of targeting Android 
> and iOS, Qt is a perfectly valid choice. I personally would recommend using 
> Xamarin.Forms, and stop writing code in C/C++.
>
> The LXDE case is a bit different: writing desktop environments is kind of 
> what GTK is known for. It seems that LXDE didn't have many contributors, and 
> the few that were there decided to join forces with a Qt-based project in 
> order to increase the contributors base. It's also telling that the Qt port 
> of LXDE is still very much in progress, and the GTK2 code base is still being 
> maintained. If porting to a new major version of a toolkit is a lot of work, 
> porting to a whole new infrastructure is even more work.
>>
>> All these people have valid complaints, so someone should think about it.
>
> Everyone involved in GTK thought about them. We incorporated the feedback we 
> gleaned from the various ranting into a better stability and versioning 
> guarantees; better tooling, like the Inspector; a better build system, to 
> ensure ease of build on Windows and macOS. If the complaint is "it's not 
> written in C++" or "there is no paid support" then there isn't much we can do.
>
>> 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).
>
>
> There is a fundamental misconception at work, here. GTK was never a 
> cross-platform in the same sense as Qt is a cross-platform toolkit. GTK began 
> supporting Windows in the 2.0 release (2002) because GIMP first, and then 
> Evolution, needed to build and run on Windows. GTK is a *portable* toolkit, 
> but its goal has always been writing Linux (and GNOME-adjacent) applications.
>
> Of course it doesn't mean we shouldn't support people writing non-Linux apps 
> with GTK, but they are a smaller target audience.
>
> Plus, you seem to imply that "binary builds for Windows" somehow means 
> "better cross-platform support", which is nonsensical at best. Windows 
> support in GTK has *never* been this good. There are multiple volunteers 
> working on building, testing, and developing GTK on Windows. It would be 
> great to have as many people working on macOS, even though things are moving 
> once again, there.

How about porting recent GTK version to OpenVMS?

Thank you.

>>
>>   "Golden age" in this regards was when Tor Lillqvist was still doing the 
>> Windows builds regularly on each GTK release. GTK was easy to be used on 
>> Windows at that time.
>
> Yes, things are always "easy" when somebody else is paid to do them for you. 
> Doesn't mean they are easy at all.
>
> Given that Tor stopped working on these years ago, and that Windows hasn't 
> stayed still in the meantime, the only reasonable course of action for GTK 
> developers was to offload the build of GTK on Windows to the MSYS2 package 
> management system—mostly like we do on macOS, with brew and macports. Of 
> course, we would have loved it 

Re: The Future?

[Emmanuele Bassi via gtk-list]

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
>
>   https://gitlab.gnome.org/Infrastructure/gtk-web/merge_requests/5
>
> Thanks,
> Kasper
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Kasper Peeters]

> 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
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Andrea Giammarchi via gtk-list]

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
I think the GNOME tablet-like experience is already good.

The cross platform portability doesn't bother me too much, except for
WebKit2GTK which is nowhere in home-brew and less seamless user friendly
through macports, but it works great on Windows through SWL and Xamarin
(just need n auto-start on .bashrc that launches it if `Gtk.init(null)`
fails).

Last, but not least, it's surprising, if not shocking, there are so many
projects around GTK and only 2 full time employees there.

This info alone might scare adoption when you know the alternative has
definitively more horsepower in terms of development.

However, my experience with Qt, specifically with Qml, is that it breaks
somehow with every minor release so it's practically terrible to use. Even
creating a full screen window is cumbersome from a version to another, but
again the only reason I'd choose it is its chromium based web view, even if
it works best only in Xorg, but no Wayland.

Thanks for the team behind Gtk, hope I could help more but I'm full time
employee myself and we're not using Gtk so I couldn't justify more time on
it.

Best Regards




On Mon, Mar 11, 2019 at 9:22 AM Stefan Salewski  wrote:

> 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. Because it is really hard to imagine that someone still
> interested in GTK not even read this list. (OK, for giants like Donald
> E. Knuth one would be not surprised, I once heard that he switched off
> email totally) I have asked google about GTK a few times in the last
> years, what I found was basically: Some blog post about you (I think it
> was that you have no much hope for Vala, I do agree), something about a
> woman from south America who was working for a few weeks on a game
> sponsored by GSOC, and some notes from someone like Carlsen, but I can
> not remember. So I have not yet investigated that Discourse mentioned
> recently on this list, maybe I should do?
>
> GTK has some justification still as it can be used from many
> programming languages easily. I guess you know my GTK3 Nim bindings
>
> https://github.com/StefanSalewski/gintro
>
> It is not perfect yet, and was some work to do. And I think that
> bindings for C++, Python and Rust are fine. Bindings for other
> languages like Ruby, Haskell, D-Lang, Crystal exists basically.
>
> And while most people would prefer Qt GUI creating bindings for other
> languages seems to be really hard, due to C++ classes, templates, MOC
> and all that. Qt may be fine when one is using C++, and someone told me
> that at least Python wrapper is not that bad, and I think I saw some
> basic Crystal bindings recently. But generally creating complete,
> bugfree high level Qt bindings is very very hard or at least very very
> much work. So I have not much hope for excellent Qt support for all the
> interesting new languages which appeared in the recent years.
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Stefan Salewski]

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. Because it is really hard to imagine that someone still
interested in GTK not even read this list. (OK, for giants like Donald
E. Knuth one would be not surprised, I once heard that he switched off
email totally) I have asked google about GTK a few times in the last
years, what I found was basically: Some blog post about you (I think it
was that you have no much hope for Vala, I do agree), something about a
woman from south America who was working for a few weeks on a game
sponsored by GSOC, and some notes from someone like Carlsen, but I can
not remember. So I have not yet investigated that Discourse mentioned
recently on this list, maybe I should do?

GTK has some justification still as it can be used from many
programming languages easily. I guess you know my GTK3 Nim bindings

https://github.com/StefanSalewski/gintro

It is not perfect yet, and was some work to do. And I think that
bindings for C++, Python and Rust are fine. Bindings for other
languages like Ruby, Haskell, D-Lang, Crystal exists basically. 

And while most people would prefer Qt GUI creating bindings for other
languages seems to be really hard, due to C++ classes, templates, MOC
and all that. Qt may be fine when one is using C++, and someone told me
that at least Python wrapper is not that bad, and I think I saw some
basic Crystal bindings recently. But generally creating complete,
bugfree high level Qt bindings is very very hard or at least very very
much work. So I have not much hope for excellent Qt support for all the
interesting new languages which appeared in the recent years.
 

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Michael Torrie via gtk-list]

On 03/09/2019 11:29 PM, Miroslav Rajcic wrote:
> IMO, it seems that GTK does not have a coherent strategy when it comes 
> to toolkit features and a cross-platform usage (i.e. lowering the effort 
> needed to develop for all major OSes). Nowadays it is mostly focused on 
> adding shiny things as support for shaders, animated transitions, GL 
> rendering.

Have you seen Qt lately?

Remember that GTK is a massive undertaking, carried by a relatively few
number of mostly volunteer developers.  GTK does have coherent
strategies and goals, but maybe they aren't quite in line with 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 would complain that it's lagging behind Qt which is
highly focused on these things now, and has been since Qt 4 days.

Qt is a commercial system, increasingly focused on mobile space, as well
as maintaining the traditional cross-platform GUI widget framework.
>From what I gather from your post, you likely aren't going to be happy
with the way Qt is going anymore than you appear to be with GTK.  Qt's
future and strategy is clearly declarative, responsive GUI layout (like
HTML and CSS), and heavy use of Javascript glue to animate it and bind
it all together, OpenGL (or Vulkan) for rendering, with your preferred
programming language only needed to do the back-end heavy lifting and
OS-specific interaction.  On the plus side, language bindings become
incredibly thin and easy, consisting mainly of a wrapper around the
QObject class (that's all that's required for QtQuick).

Anyway, it's not a zero sum game.  Qt being chosen by some does not
diminish GTK, or vice versa.  Nor should GTK simply follow Qt.  From
what Mr. Bassi has said, it sounds like GTK 4 will bring some impressive
features and capabilities.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Daniel Kasak via gtk-list]

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 foolproof).
> >
> > That's definitely not true; on Windows there's vcpkg and on macOS
> > there is Homebrew; both let you install reasonably up-to-date versions
> > of GTK3 with a single command line.
>
> For Windows, there is also Msys2 ( https://www.msys2.org/ ). It may be
> more handy for porting applications from Linux to Windows. This is what
> I intend to use to build the next versions of Paperwork (
> https://openpaper.work ) for Windows.
>
>
I've also had extreme difficulty in the past with deploying on Windows. Not
being a ( proficient ) C developer, and not having experience with building
on Windows didn't help. I've toyed with broadway ( including writing an
authentication layer, app launcher and transparent proxy ) for giving
Windows users a relatively painless way of accessing apps, though was
discouraged from this by statements of broadway being experimental and
probably not making it through the gtk-4 work. More recently this may have
changed ( there were a bunch of commits to broadway stuff for gtk-4 ),
though from a user perspective there are still some bits missing. I've
recently ( last year or so ) switched to deploying with Flatpak, and this
has worked astonishingly well. In particular, Alexander Larsson's work:
 - https://blogs.gnome.org/alexl/2018/09/17/flatpak-on-windows/
 - https://github.com/flatpak/flatpak/tree/wip/WSL
  ... has given us a very easy path for at least bringing up our apps on
Windows. You still need an X Server ( I use MobaXterm, though I assume we
could build and package an X server too? ). The only thing that hasn't
worked out-of-the-box for us has been maximising windows. This is a bit
nasty, but with some hacks to save + restore window geometry, it's not a
deal-breaker. Keep in mind we haven't done a production deployment yet (
luckily all clients recently have been fine with running Linux ), but I've
done a reasonable amount ( many hours ) of testing and only found this 1
issue.

I would suggest people who need windows binaries check out the Flatpak
angle.

Dan
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Jerome Flesch]

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 on macOS
there is Homebrew; both let you install reasonably up-to-date versions
of GTK3 with a single command line.


For Windows, there is also Msys2 ( https://www.msys2.org/ ). It may be 
more handy for porting applications from Linux to Windows. This is what 
I intend to use to build the next versions of Paperwork ( 
https://openpaper.work ) for Windows.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Sergei Steshenko via gtk-list]

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 level functions), and then you can write in "C".


And using LLVM other forms of language integration is possible.

--Sergei.

On 3/9/19 6:43 PM, Paul Davis wrote:



On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list 
mailto:gtk-list@gnome.org>> 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 complete rewrite, so applications 
(which are the real "users" of a toolkit) generally do not move. 
Developers may start new projects using Qt having previously used 
GTK, but who counts this? How would we judge if it is significant?


3. What makes them move to Qt? Why can't Gtk have that respective
feature?


Qt has as many issues as GTK once you start using it for complex, 
deep applications. Different issues, to be sure, but no GUI toolkit 
gives you a free ride.


Qt is also developed using a different licensing/income generation 
model than GTK, which changes quite a lot.


Qt mostly has distinct advantages over GTK, and to be honest if I was 
starting cross-platform development now (22 years after I actually 
did), I'd probably pick Qt for all the obvious reasons. But it's 
fairly pointless to ask "how can GTK be more like Qt?" when there's 
more or less no chance or pathway for that to happen. As it is, I 
don't do mobile so GTK's issues there don't affect me. I also have 
75k lines of code that would have to be almost completely rewritten 
to use Qt, with no noticeable benefit for our users and only marginal 
benefits for our developers.


Speaking of "why can't?", why can't I write a C application using Qt  
? :))



___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Sergei Steshenko via gtk-list]

'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 6:43 PM, Paul Davis wrote:



On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list 
mailto:gtk-list@gnome.org>> 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 complete rewrite, so applications (which are 
the real "users" of a toolkit) generally do not move. Developers may 
start new projects using Qt having previously used GTK, but who counts 
this? How would we judge if it is significant?


3. What makes them move to Qt? Why can't Gtk have that respective
feature?


Qt has as many issues as GTK once you start using it for complex, deep 
applications. Different issues, to be sure, but no GUI toolkit gives 
you a free ride.


Qt is also developed using a different licensing/income generation 
model than GTK, which changes quite a lot.


Qt mostly has distinct advantages over GTK, and to be honest if I was 
starting cross-platform development now (22 years after I actually 
did), I'd probably pick Qt for all the obvious reasons. But it's 
fairly pointless to ask "how can GTK be more like Qt?" when there's 
more or less no chance or pathway for that to happen. As it is, I 
don't do mobile so GTK's issues there don't affect me. I also have 75k 
lines of code that would have to be almost completely rewritten to use 
Qt, with no noticeable benefit for our users and only marginal 
benefits for our developers.


Speaking of "why can't?", why can't I write a C application using Qt  
? :))



___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Kasper Peeters]

> 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?

[Emmanuele Bassi via gtk-list]

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.
>

Care to file an issue:

  https://gitlab.gnome.org/Infrastructure/gtk-web

to update the wording?

We're in the process of updating the website because it's basically the
same as it was when we released GTK 3 (and it wasn't much different before
that either).

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Kasper Peeters]

> 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 install reasonably up-to-date versions
of GTK3 with a single command line. What's difficult, however, is to
find information on this, and on how to use these. I maintain a large,
fully cross-platform GTK3 app (cadabra) and once we had vcpkg and
Homebrew figured out, we haven't had any GTK-related issues anymore.

So I personally think that what drives people away from GTK (or put more
friendly: what makes people less likely to choose GTK than QT or
something else), is that the information on GTK's web site is not
sufficiently newcomer-friendly. Good documentation is almost as critical
as good code, and while the GTK code is excellent, it lacks on the
documentation front. Not for the API documentation, that one's fine.
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. 

Cheers,
Kasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: The Future?

[Emmanuele Bassi via gtk-list]

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 Foundation to work in GTK, this
*my* opinion, and should not be construed as anything but my opinion.

On Sun, 10 Mar 2019 at 06:37, Miroslav Rajcic 
wrote:

> 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  (https://blog.wireshark.org/2013/10/switching-to-qt/)
>
> - Subsurface by Linus (
> https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/)
> - GCompris educational software (
> https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html)
>

VLC, Wireshark, Subsurface, and GCompris switched to Qt mostly because of
its support for Android and mobile platforms, something that GTK doesn't
support. Well, Subsurface moved to Qt because the original developers
thought that asking on Google Plus was the proper way to ask for help with
writing GTK applications, and had no objections when somebody else showed
up and rewrote their application using Qt.

It's entirely justified to go through the ringer of a full rewrite if
you're thinking of expanding somewhere the GUI toolkit you use is not going
to be, and it's highly unlikely that an Android backend for GTK will ever
materialise—let alone an iOS one—so if you're thinking of targeting Android
and iOS, Qt is a perfectly valid choice. I personally would recommend using
Xamarin.Forms, and stop writing code in C/C++.

The LXDE case is a bit different: writing desktop environments is kind of
what GTK is known for. It seems that LXDE didn't have many contributors,
and the few that were there decided to join forces with a Qt-based project
in order to increase the contributors base. It's also telling that the Qt
port of LXDE is still very much in progress, and the GTK2 code base is
still being maintained. If porting to a new major version of a toolkit is a
lot of work, porting to a whole new infrastructure is even more work.

> All these people have valid complaints, so someone should think about it.
>
Everyone involved in GTK thought about them. We incorporated the feedback
we gleaned from the various ranting into a better stability and versioning
guarantees; better tooling, like the Inspector; a better build system, to
ensure ease of build on Windows and macOS. If the complaint is "it's not
written in C++" or "there is no paid support" then there isn't much we can
do.

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).
>

There is a fundamental misconception at work, here. GTK was never a
cross-platform in the same sense as Qt is a cross-platform toolkit. GTK
began supporting Windows in the 2.0 release (2002) because GIMP first, and
then Evolution, needed to build and run on Windows. GTK is a *portable*
toolkit, but its goal has always been writing Linux (and GNOME-adjacent)
applications.

Of course it doesn't mean we shouldn't support people writing non-Linux
apps with GTK, but they are a smaller target audience.

Plus, you seem to imply that "binary builds for Windows" somehow means
"better cross-platform support", which is nonsensical at best. Windows
support in GTK has *never* been this good. There are multiple volunteers
working on building, testing, and developing GTK on Windows. It would be
great to have as many people working on macOS, even though things are
moving once again, there.

>   "Golden age" in this regards was when Tor Lillqvist was still doing the
> Windows builds regularly on each GTK release. GTK was easy to be used on
> Windows at that time.
>
Yes, things are always "easy" when somebody else is paid to do them for
you. Doesn't mean they are easy at all.

Given that Tor stopped working on these years ago, and that Windows hasn't
stayed still in the meantime, the only reasonable course of action for GTK
developers was to offload the build of GTK on Windows to the MSYS2 package
management system—mostly like we do on macOS, with brew and macports. Of
course, we would have loved it if somebody had showed up and did the work;
somebody did, from time to time, and we even gave access to a Windows build
machine hosted in the GNOME infrastructure, but keeping things building is
hard—I do that for GNOME, and it's not fun—and people simply tire of it.

The move to Meson for GTK4 (and possibly to GTK3, as a secondary build
system) should make building GTK and many of its dependencies easier to
deal with. Ideally, we'd like for people to be able to clone just GTK and
be ready to go; of course, that's 

Re: The Future?

[Miroslav Rajcic]

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 (https://blog.wireshark.org/2013/10/switching-to-qt/)

- Subsurface by Linus 
(https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/)


- LXDE desktop 
(https://www.zdnet.com/article/lxde-waves-goodbye-to-gtk-in-merge-with-razor-qt/)


- GCompris educational software 
(https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html)


All these people have valid complaints, so someone should think about it.

Same as Paul, if I would start cross platform now (I started in 2003), 
Qt would be a no-brainer choice.


My personal issues with GTK in comparison to Qt:

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).


  "Golden age" in this regards was when Tor Lillqvist was still doing 
the Windows builds regularly on each GTK release.GTK was easy to be used 
on Windows at that time.


2. QT has more complete stack, for example integrating audio/video 
playing module (Phonon). gstreamer as an alternative for such module in 
GTK suffers from "build your own binaries" (i.e. issue #1) and a more 
complex interface.


3. for me, this one is huge: QT has much better rich text editor widget 
(QTextEdit), supporting tables, all types of bulleted lists etc.. GTK's 
default widget GtkTextView (nor GtkSourceView) is not nearly close to 
this (no tables, no bullets, no htmL export). For advanced editor you 
are supposed to embed WebKitGTK, but you must first suffer through issue 
#1 and use complex JScript solutions to implement your rich text editor 
features (formatting actions, text change notifications).


4. API stability: jumps from GTK2 to GTK3 were painful, many APIs were 
changed, what it looks like from here, without the strong need, but just 
to make everything better organized or similar, without thinking of 
library users. I have an app that must support GTK2 (even using hildon 
interfaces on old platforms like Maemo) and GTK3 in the same code base, 
so it is now littered with many #ifdef layers


5. Many other parts are unsolved or hard to implement in GTK (drag and 
drop integration using types other than the basic ones, for example)


6. Useful features deprecated, an example is native print preview, that 
worked in 2.16 if i remember correctly and was broken forever in next 
releases (at that time I did not want to port preview  to a new 
mechanism, so i had to remove that feature in my program)


IMO, it seems that GTK does not have a coherent strategy when it comes 
to toolkit features and a cross-platform usage (i.e. lowering the effort 
needed to develop for all major OSes). Nowadays it is mostly focused on 
adding shiny things as support for shaders, animated transitions, GL 
rendering.


Hard-to-implement things like an advanced text editor do not seem to be 
an a table.


This was meant as an constructive critics, it seems strange that this 
topic got just one answer so far.


Regards,

  Miroslav

On 9.3.2019. 17:43, Paul Davis wrote:



On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list 
mailto:gtk-list@gnome.org>> 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 complete rewrite, so applications (which are 
the real "users" of a toolkit) generally do not move. Developers may 
start new projects using Qt having previously used GTK, but who counts 
this? How would we judge if it is significant?


3. What makes them move to Qt? Why can't Gtk have that respective
feature?


Qt has as many issues as GTK once you start using it for complex, deep 
applications. Different issues, to be sure, but no GUI toolkit gives 
you a free ride.


Qt is also developed using a different licensing/income generation 
model than GTK, which changes quite a lot.


Qt mostly has distinct advantages over GTK, and to be honest if I was 
starting cross-platform development now (22 years after I actually 
did), I'd probably pick Qt for all the obvious reasons. But it's 
fairly pointless to ask "how can GTK be more like Qt?" when there's 
more or less no chance or pathway for that to happen. As it is, I 
don't do mobile so GTK's issues there don't affect me. I also have 75k 
lines of code that would have to be almost completely rewritten to use 
Qt, with no noticeable benefit for our users and only marginal 
benefits for our developers.


Speaking of "why can't?", why can't I write a C application using Qt  
? :))



___
gtk-list mailing list
gtk-list@gnome.org

Re: The Future?

[Paul Davis]

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 complete rewrite, so applications (which are the
real "users" of a toolkit) generally do not move. Developers may start new
projects using Qt having previously used GTK, but who counts this? How
would we judge if it is significant?


> 3. What makes them move to Qt? Why can't Gtk have that respective feature?
>

Qt has as many issues as GTK once you start using it for complex, deep
applications. Different issues, to be sure, but no GUI toolkit gives you a
free ride.

Qt is also developed using a different licensing/income generation model
than GTK, which changes quite a lot.

Qt mostly has distinct advantages over GTK, and to be honest if I was
starting cross-platform development now (22 years after I actually did),
I'd probably pick Qt for all the obvious reasons. But it's fairly pointless
to ask "how can GTK be more like Qt?" when there's more or less no chance
or pathway for that to happen. As it is, I don't do mobile so GTK's issues
there don't affect me. I also have 75k lines of code that would have to be
almost completely rewritten to use Qt, with no noticeable benefit for our
users and only marginal benefits for our developers.

Speaking of "why can't?", why can't I write a C application using Qt  ? :))
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

The Future?

[J.Arun Mani via gtk-list]

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 feature?

Im a die-hard Gtk fan, such that I didn't even check whats unique with Qt over 
Gtk ;)
And at last, I have a $50 as BAT in Brave browser, is there anyway I can fund 
it to Gtk?

Thank You
J. Arun Mani___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK_MODULES removal and the future of existing modules

[Matthias Clasen]

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 removed[3] on
> GTK+ master.
>
> It appears that this change could mean the end for Plotinus and other
> modules like it. I would be interested to learn:
>
> 1. What is the rationale behind the removal of module loading?
>
> 2. What will be the first stable release of GTK+ that does not support
>modules anymore? Is this GTK+ 4.0+ only, or will support also be
>dropped in a 3.0 series release?
>
> 3. What, if any, alternatives are available/planned for software
>like Plotinus that needs to inspect the widget hierarchy of running
>applications in order to work?
>
> Any insight is appreciated!
>
>
This may not be a popular opinion, but my view is that it is harmful to the
eco system
overall if useful features are hidden away in 3rd party modules instead of
being properly
integrated in the toolkit.

Has the example you mention ever been suggested as a feature addition to
GTK+ ?
Was it rejected ? Or why was it implemented as a 3rd party module ?

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK_MODULES removal and the future of existing modules

[Emmanuele Bassi]

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 is kind of why we don't want people to write this kind of
modules any more. ;-)

Accessing the hierarchy from outside of the application is a great way
to lead to crashes. See also why we removed theme engines.

From our perspective, the only way to know about menus and actions
should be through the GAction API, and the mechanisms that we already
have in place to export the menus on the session bus.

> Of course, I don't expect LibreOffice to move to GTK4 in the short or
> even medium term. The major cross-platform applications like Firefox,
> LibreOffice, GIMP, and Inkscape have been very reluctant in their
> adoption of even GTK3, and likely don't fancy another bumpy upgrade
> anytime soon. Still, eventually they might switch, and it makes sense
> to anticipate that.

If LibreOffice and Firefox will ever move to GTK4, we're going to
strongly suggest they expose their menus on the session bus, either
through the GMenu API directly, or by implementing the same DBus API
exposed by GTK.

Ciao,
 Emmanuele.

> On Sun, 2018-02-25 at 09:54 +, Emmanuele Bassi wrote:
>> Hi;
>>
>> On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann > mann.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 removed[3]
>> > on
>> > GTK+ master.
>> >
>> > It appears that this change could mean the end for Plotinus and
>> > other
>> > modules like it. I would be interested to learn:
>> >
>> > 1. What is the rationale behind the removal of module loading?
>> >
>>
>> The module code was fairly ancient, and was hand rolling things for
>> which we have better API down the stack, like GIO extension points,
>> which support things like priorities and prerequisites.
>> > 2. What will be the first stable release of GTK+ that does not
>> > support
>> >modules anymore? Is this GTK+ 4.0+ only, or will support also be
>> >dropped in a 3.0 series release?
>> >
>>
>> The GTK 3.x series is frozen, so it won’t be touched. This change is
>> for 4.x only.
>>
>> > 3. What, if any, alternatives are available/planned for software
>> >like Plotinus that needs to inspect the widget hierarchy of
>> > running
>> >applications in order to work?
>> >
>>
>> We could be amenable to add an extension point for this, if you
>> present a case for it, and explain what kind of requirements you need
>> from the toolkit; granting blanket access to the internals of the
>> toolkit is not something we’d be happy to provide, but if you have a
>> specific domain it should be possible to accommodate your extension.
>>
>> Alternatively, we could ensure that all our menus and actions are
>> introspectable from the outside, and give you a proper API for
>> writing Plotinus in GTK 4.0. We’d probably prefer that.
>>
>> Ciao,
>>  Emmanuele.
>>
>> > Any insight is appreciated!
>> >
>> > Warm regards
>> > Philipp
>> >
>> >
>> > [1]: https://github.com/p-e-w/plotinus
>> > [2]: https://github.com/p-e-w/plotinus/issues/35
>> > [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196
>> > b910
>> > dce40e1617
>> >
>> > ___
>> > gtk-devel-list mailing list
>> > gtk-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK_MODULES removal and the future of existing modules

[Philipp Emanuel Weidmann]

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" manner. A good example is
LibreOffice: It doesn't use GtkApplication, nor does it have
GActionMaps, or GMenuModels from which actions can be extracted. There
is only a GtkMenuBar widget, which I'm guessing is constructed from
some backend-agnostic model inside the LibreOffice GUI stack.

Plotinus currently tries the obvious things first, looking for
application menus and their models, and falls back to raw widgets if it
doesn't find any. It is this fallback feature that allows Plotinus to
work with software like LibreOffice, and it is software like
LibreOffice where Plotinus is the most useful, since it has hundreds of
menu items.

Of course, I don't expect LibreOffice to move to GTK4 in the short or
even medium term. The major cross-platform applications like Firefox,
LibreOffice, GIMP, and Inkscape have been very reluctant in their
adoption of even GTK3, and likely don't fancy another bumpy upgrade
anytime soon. Still, eventually they might switch, and it makes sense
to anticipate that.

For Plotinus to continue supporting "semi-GTK" applications,
introspection APIs would need to cover the case where there is nothing
but a GtkWindow and a bunch of widgets. The existing D-Bus APIs, for
example, all seem to require at least a GApplication. I don't know
enough about GTK internals to say which alternatives might be feasible.
You mention GIO extension points, a feature I wasn't aware of until
now. How could such an extension point look for Plotinus' use case?
What information would it provide? And would it work with software that
doesn't use GApplication?

Thanks & best regards
Philipp




On Sun, 2018-02-25 at 09:54 +, Emmanuele Bassi wrote:
> Hi;
> 
> On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann  mann.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 removed[3]
> > on
> > GTK+ master.
> > 
> > It appears that this change could mean the end for Plotinus and
> > other
> > modules like it. I would be interested to learn:
> > 
> > 1. What is the rationale behind the removal of module loading?
> > 
> 
> The module code was fairly ancient, and was hand rolling things for
> which we have better API down the stack, like GIO extension points,
> which support things like priorities and prerequisites.
> > 2. What will be the first stable release of GTK+ that does not
> > support
> >modules anymore? Is this GTK+ 4.0+ only, or will support also be
> >dropped in a 3.0 series release?
> > 
> 
> The GTK 3.x series is frozen, so it won’t be touched. This change is
> for 4.x only.
> 
> > 3. What, if any, alternatives are available/planned for software
> >like Plotinus that needs to inspect the widget hierarchy of
> > running
> >applications in order to work?
> > 
> 
> We could be amenable to add an extension point for this, if you
> present a case for it, and explain what kind of requirements you need
> from the toolkit; granting blanket access to the internals of the
> toolkit is not something we’d be happy to provide, but if you have a
> specific domain it should be possible to accommodate your extension.
> 
> Alternatively, we could ensure that all our menus and actions are
> introspectable from the outside, and give you a proper API for
> writing Plotinus in GTK 4.0. We’d probably prefer that.
> 
> Ciao,
>  Emmanuele.
> 
> > Any insight is appreciated!
> > 
> > Warm regards
> > Philipp
> > 
> > 
> > [1]: https://github.com/p-e-w/plotinus
> > [2]: https://github.com/p-e-w/plotinus/issues/35
> > [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196
> > b910
> > dce40e1617
> > 
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
> -- 
> https://www.bassi.io
> [@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK_MODULES removal and the future of existing modules

[Emmanuele Bassi]

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 removed[3] on
> GTK+ master.
>
> It appears that this change could mean the end for Plotinus and other
> modules like it. I would be interested to learn:
>
> 1. What is the rationale behind the removal of module loading?
>

The module code was fairly ancient, and was hand rolling things for which
we have better API down the stack, like GIO extension points, which support
things like priorities and prerequisites.

>
> 2. What will be the first stable release of GTK+ that does not support
>modules anymore? Is this GTK+ 4.0+ only, or will support also be
>dropped in a 3.0 series release?
>

The GTK 3.x series is frozen, so it won’t be touched. This change is for
4.x only.


> 3. What, if any, alternatives are available/planned for software
>like Plotinus that needs to inspect the widget hierarchy of running
>applications in order to work?
>

We could be amenable to add an extension point for this, if you present a
case for it, and explain what kind of requirements you need from the
toolkit; granting blanket access to the internals of the toolkit is not
something we’d be happy to provide, but if you have a specific domain it
should be possible to accommodate your extension.

Alternatively, we could ensure that all our menus and actions are
introspectable from the outside, and give you a proper API for writing
Plotinus in GTK 4.0. We’d probably prefer that.

Ciao,
 Emmanuele.

Any insight is appreciated!
>
> Warm regards
> Philipp
>
>
> [1]: https://github.com/p-e-w/plotinus
> [2]: https://github.com/p-e-w/plotinus/issues/35
> [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196b910
> dce40e1617
> 
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK_MODULES removal and the future of existing modules

[Philipp Emanuel Weidmann]

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
modules like it. I would be interested to learn:

1. What is the rationale behind the removal of module loading?

2. What will be the first stable release of GTK+ that does not support
   modules anymore? Is this GTK+ 4.0+ only, or will support also be
   dropped in a 3.0 series release?

3. What, if any, alternatives are available/planned for software
   like Plotinus that needs to inspect the widget hierarchy of running
   applications in order to work?

Any insight is appreciated!

Warm regards
Philipp


[1]: https://github.com/p-e-w/plotinus
[2]: https://github.com/p-e-w/plotinus/issues/35
[3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196b910
dce40e1617

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Past and future evolution of Gtk+

[Michael Torrie]

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.

Hardly.  People run a full Gnome (or Mate) desktop all the time with
lots of GTK apps running.  Similar for KDE and Qt apps.

You can't measure memory usage like that.  What Linux reports as the
memory used includes mapped files like shared libraries.  This isn't
real memory use in the sense you are thinking.  I can assure you that
ten hello world programs do not consume 300 MB of real memeory in total.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Michael Torrie]

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 consider a lunch break checking
> it out.

Like Gtk, Qt can also work directly with an XML interface definition
file.  In Gtk, you can use the GtkBuilder class to parse a glade UI file
(which is XML), and generate the in-memory objects for that UI, and
interact with it just as if you had created it manually with gtk_*_new()
calls.

Likewise, Qt has something similar.  The equivalent to Glade is called
Qt Designer (often /usr/bin/designer or /usr/bin/designer-qt5).  It
creates .ui files that are XML similar to how Glade does it.  Qt has a
component called uic which translates the XML files into C++ code. But
you can do it dynamically at runtime, similar to GtkBuilder.  The class
is called QuiLoader.

Mind you Qt is a competitor for Gtk+ only if you don't want to code in C.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Igor Korot]

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.
>>
>> NP.
>> After 7 years working with the library, submitting patches to it and
>> doing development with it I guess I'm "overqualified" to work with it. ;-)
>>
>> So, does the position requires wx knowledge?
>
> What position? I'm confused.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Carsten Mattner]

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 guess I'm "overqualified" to work with it. ;-)
>
> So, does the position requires wx knowledge?

What position? I'm confused.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Carsten Mattner]

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 has no such
regression. That means on current hardware memory overhead
becomes more interesting to optimize than the already fast
enough interactive responsiveness.

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.

I mean I expect a major overhead when using QML since it is
a mini browser engine of sorts, but I don't expect more than 5MB
or 10MB base GUI toolkit overhead, even on 64-bit.

I don't know how much GTK and Qt use on Windows or macOS, but I
do remember that macOS applications occupy IME large amounts of
memory. Windows used to be in the space as X11 when I last ran it
years ago.

I guess what I'm trying to ask is where the resident memory goes
in a GTK or Qt Hello World.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Igor Korot]

On Mon, Sep 18, 2017 at 10:53 AM, Carsten Mattner
<carstenmatt...@gmail.com> 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 guess I'm "overqualified" to work with it. ;-)

So, does the position requires wx knowledge?

Thx.

>
> On 9/18/17, Igor Korot <ikoro...@gmail.com> wrote:
>> On Mon, Sep 18, 2017 at 9:39 AM, Carsten Mattner
>> <carstenmatt...@gmail.com> wrote:
>>> On 9/18/17, Ian Chapman <ichap...@videotron.ca> wrote:
>>>> This is not a troll, only a trawler as in fishing boat. I found the
>>>> discourse on “traditional file chooser” quite interesting and
>>>> informative. I'm using glade 3.18.3 and I'm able to do useful work so
>>>> possibly I'm off 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 working software will fail or simply fail to
>>>> compile on the newer distribution?
>>>
>>> That's how I interpret it. Case in point Raleigh theme which was never,
>>> from what I can tell, intended to be a replacement for the Gtk2 Raleigh
>>> theme. It didn't look right and now it just looks completely broken.
>>> If something is supposed to be removed, there's no need to make 3.x
>>> seem like it supports it and remove it in 4.x, when the version in 3.x
>>> isn't supported and working by sheer luck. This is what I read from the
>>> info I can gather and not meant to be an attack. I'm just trying to
>>> stitch
>>> together a picture.
>>>
>>>> Point 2
>>>>
>>>> Lots of acronyms were mentioned. Qt was one and it's in the LMDE
>>>> repositories. Wiki has a long list of GUIs in
>>>> “https://en.wikipedia.org/wiki/List_of_widget_toolkits” but only a few
>>>> could be of interest. In any case there would be a learning curve to use
>>>> any them and maybe no glade which greatly simplifies Gtk for me. Is
>>>> there an evaluation on these alternative GUIs?
>>>
>>> With all due respect and apologies to the list admins, allow me to
>>> answer this here although it's kinda advertising for "competitors".
>>>
>>> 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 consider a lunch break checking
>>> it out.
>>> If you're writing engineering software that doesn't have requirement
>>> that mandate Qt or Gtk, then FLTK or IUP have been used successfully
>>> in that domain.
>>>
>>> Qt has Haskell bindings (Qtah).
>>> wxWidgets has Gtk2, Gtk3, Qt5 backends and bindings pretty much
>>> everywhere, but there's no GUI builder I know of.
>>
>> wxWidgets does have GUI builders - wxGlade, wxFormBuilder, wxCrafter to
>> name a few.
>> It also works on both MS Windows and OSX without any issues.
>>
>> If you requirements are to have a "native look and feel" of the software
>> then wxWidgets is the way to go.
>>
>> The license is free for both O/S and commercial applications.
>>
>> It has bindings for all popular languages - Python, Perl, Ruby.
>>
>> On Linux GTK is the most developed and most mature port.
>> wxQt is relatively new and wxX11 (so called Universal) is not actively
>> developed. wxMotiff is really outdated and will be removed in future
>> versions.
>>
>> Thank you.
>>
>>> FLTK has a GUI builder and the Haskell bindings also generate
>>> Haskell code when using the GUI builder. Just in case you had
>>> interest in a different language.
>>> IUP is plain C and has been used in many brazilian industrial
>>> applications. Check the screenshots section.
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Carsten Mattner]

Thanks Igor for the wxWidgets clarification.

On 9/18/17, Igor Korot <ikoro...@gmail.com> wrote:
> On Mon, Sep 18, 2017 at 9:39 AM, Carsten Mattner
> <carstenmatt...@gmail.com> wrote:
>> On 9/18/17, Ian Chapman <ichap...@videotron.ca> wrote:
>>> This is not a troll, only a trawler as in fishing boat. I found the
>>> discourse on “traditional file chooser” quite interesting and
>>> informative. I'm using glade 3.18.3 and I'm able to do useful work so
>>> possibly I'm off 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 working software will fail or simply fail to
>>> compile on the newer distribution?
>>
>> That's how I interpret it. Case in point Raleigh theme which was never,
>> from what I can tell, intended to be a replacement for the Gtk2 Raleigh
>> theme. It didn't look right and now it just looks completely broken.
>> If something is supposed to be removed, there's no need to make 3.x
>> seem like it supports it and remove it in 4.x, when the version in 3.x
>> isn't supported and working by sheer luck. This is what I read from the
>> info I can gather and not meant to be an attack. I'm just trying to
>> stitch
>> together a picture.
>>
>>> Point 2
>>>
>>> Lots of acronyms were mentioned. Qt was one and it's in the LMDE
>>> repositories. Wiki has a long list of GUIs in
>>> “https://en.wikipedia.org/wiki/List_of_widget_toolkits” but only a few
>>> could be of interest. In any case there would be a learning curve to use
>>> any them and maybe no glade which greatly simplifies Gtk for me. Is
>>> there an evaluation on these alternative GUIs?
>>
>> With all due respect and apologies to the list admins, allow me to
>> answer this here although it's kinda advertising for "competitors".
>>
>> 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 consider a lunch break checking
>> it out.
>> If you're writing engineering software that doesn't have requirement
>> that mandate Qt or Gtk, then FLTK or IUP have been used successfully
>> in that domain.
>>
>> Qt has Haskell bindings (Qtah).
>> wxWidgets has Gtk2, Gtk3, Qt5 backends and bindings pretty much
>> everywhere, but there's no GUI builder I know of.
>
> wxWidgets does have GUI builders - wxGlade, wxFormBuilder, wxCrafter to
> name a few.
> It also works on both MS Windows and OSX without any issues.
>
> If you requirements are to have a "native look and feel" of the software
> then wxWidgets is the way to go.
>
> The license is free for both O/S and commercial applications.
>
> It has bindings for all popular languages - Python, Perl, Ruby.
>
> On Linux GTK is the most developed and most mature port.
> wxQt is relatively new and wxX11 (so called Universal) is not actively
> developed. wxMotiff is really outdated and will be removed in future
> versions.
>
> Thank you.
>
>> FLTK has a GUI builder and the Haskell bindings also generate
>> Haskell code when using the GUI builder. Just in case you had
>> interest in a different language.
>> IUP is plain C and has been used in many brazilian industrial
>> applications. Check the screenshots section.
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Carsten Mattner]

On 9/18/17, Ian Chapman <ichap...@videotron.ca> wrote:
> This is not a troll, only a trawler as in fishing boat. I found the
> discourse on “traditional file chooser” quite interesting and
> informative. I'm using glade 3.18.3 and I'm able to do useful work so
> possibly I'm off 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 working software will fail or simply fail to
> compile on the newer distribution?

That's how I interpret it. Case in point Raleigh theme which was never,
from what I can tell, intended to be a replacement for the Gtk2 Raleigh
theme. It didn't look right and now it just looks completely broken.
If something is supposed to be removed, there's no need to make 3.x
seem like it supports it and remove it in 4.x, when the version in 3.x
isn't supported and working by sheer luck. This is what I read from the
info I can gather and not meant to be an attack. I'm just trying to stitch
together a picture.

> Point 2
>
> Lots of acronyms were mentioned. Qt was one and it's in the LMDE
> repositories. Wiki has a long list of GUIs in
> “https://en.wikipedia.org/wiki/List_of_widget_toolkits” but only a few
> could be of interest. In any case there would be a learning curve to use
> any them and maybe no glade which greatly simplifies Gtk for me. Is
> there an evaluation on these alternative GUIs?

With all due respect and apologies to the list admins, allow me to
answer this here although it's kinda advertising for "competitors".

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 consider a lunch break checking
it out.
If you're writing engineering software that doesn't have requirement
that mandate Qt or Gtk, then FLTK or IUP have been used successfully
in that domain.

Qt has Haskell bindings (Qtah).
wxWidgets has Gtk2, Gtk3, Qt5 backends and bindings pretty much
everywhere, but there's no GUI builder I know of.
FLTK has a GUI builder and the Haskell bindings also generate
Haskell code when using the GUI builder. Just in case you had
interest in a different language.
IUP is plain C and has been used in many brazilian industrial
applications. Check the screenshots section.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+

[Ian Chapman]

This is not a troll, only a trawler as in fishing boat. I found the 
discourse on “traditional file chooser” quite interesting and 
informative. I'm using glade 3.18.3 and I'm able to do useful work so 
possibly I'm off 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 working software will fail or simply fail to 
compile on the newer distribution?


Point 2

Lots of acronyms were mentioned. Qt was one and it's in the LMDE 
repositories. Wiki has a long list of GUIs in 
“https://en.wikipedia.org/wiki/List_of_widget_toolkits” but only a few 
could be of interest. In any case there would be a learning curve to use 
any them and maybe no glade which greatly simplifies Gtk for me. Is 
there an evaluation on these alternative GUIs?


Regards Ian.


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

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

[Paul Davis]

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 make GTK+ more oriented
toward people and projects with different development priorities.
4) GTK+ was not "taken over" by GNOME developers, it is just that nobody
else stepped up do any of what was clearly necessary

Arguably, there is no other such community of interest. As an example ...
I've been using GTK+ for more than 20 years. For 18 years, the Ardour
project has used GTK+ (2). Our main conclusion after all this time is that
we actually never really had any interest or need for a GUI toolkit
centered on "desktop" applications (aka "productivity tools"), and that we
ended up with GTK+ mostly as a result of my naievete about GUI programming
(not that GTK+ was a bad choice, it just wasn't really what we needed then
or need now). We have little interest in tracking the ongoing development
of GTK+, not because we think that the developers are doing a bad job or
are working on the wrong things, but because this sort of toolkit just
isn't remotely what we want.

I suspect that we are not alone. In the general "creative" application
area, most developers (both proprietary and open source) have tended to
move towards much less structured toolkits, often based on GL for portable
drawing. I suspect that there are quite a lot of developers who made the
same "mistake" that I did back in the late 1990s regarding the type of
functionality I really needed (the mistake was mostly to be beguiled by
widgets, and to ignore the poor fit of MVC programming into the general
design).

As you note, the "GNOME"-centric ness of GTK+ has come up over and over
again for the last 10 years or so, and in that time, nobody has stepped up
to do anything close to what you suggest. While I've been using GTK+, whole
new toolkits such as JUCE have emerged, and even older ones like FLTK have
continued to do their job as well as ever.



On Sun, Sep 17, 2017 at 6:43 AM, Nicolas George  wrote:

> 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 trend that is very typical of the evolution of Gtk+.
>
> In the beginning of the 2000's, Gtk+ was arguably the best toolkit
> available: Libre, of course, best Unicode support, best ergonomics, best
> set of supported languages, best API, etc. In the more recent years, on
> the other hand, we have seen a growing dissatisfaction from a certain
> category of users, about both the ergonomics and the API design.
>
> A friend of mine, historian, likes to say "a false idea is a true fact":
> "people are dissatisfied" is a fact, even if one disagrees with their
> reasons for being dissatisfied.
>
> Some of the complaints are just silly or otherwise unfounded, there is
> little doubt about that. But on the other hand, some of them are founded
> and valid. Amongst them, some are a matter of taste, priorities and use
> style while some may be universally valid points. Somebody who aims to
> enhance Gtk+ needs to heed the valid complaints. And in order to know
> which one is what, all complaints need to be read with an open mind.
>
> Therefore, requesting features or expressing critics in a constructive
> way is good for Gtk+ and perfectly acceptable on its mailing-lists, it
> is not a troll. It becomes "troll bait" because some people do not read
> them with an open mind and reply in non-constructive ways, sometimes
> bordering on insulting. Of course, when polite requests are met with
> impolite replies, the ambiance eventually deteriorates on both sides,
> and the critics become less polite. All sides should make conscious
> efforts to avoid it.
>
> As I said, some critics are a matter of taste and use style. I think
> they should still be heeded: a toolkit like Gtk+ should strive to cater
> for all users and all use styles; it is possible to make a GUI more
> usable for certain users without making it less usable for others.
> Furthermore, general principles about usability often have to give way
> to other considerations. For example, if somebody is forced to work a
> lot with applications developed with a mediocre toolkit, they will want
> their few Gtk+ applications to behave as much as possible the same way:
> even if it is not the "best" way, it is still more convenient for them,
> and Gtk+ should propose it as an option.
>
> Of course, implementing options and alternate behaviours costs time and
> efforts, and testing the various combinations even more so. The work of
> the Gtk+ team is given to the community gratis, nobody has any right 

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

[Nicolas George]

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 trend that is very typical of the evolution of Gtk+.

In the beginning of the 2000's, Gtk+ was arguably the best toolkit
available: Libre, of course, best Unicode support, best ergonomics, best
set of supported languages, best API, etc. In the more recent years, on
the other hand, we have seen a growing dissatisfaction from a certain
category of users, about both the ergonomics and the API design.

A friend of mine, historian, likes to say "a false idea is a true fact":
"people are dissatisfied" is a fact, even if one disagrees with their
reasons for being dissatisfied.

Some of the complaints are just silly or otherwise unfounded, there is
little doubt about that. But on the other hand, some of them are founded
and valid. Amongst them, some are a matter of taste, priorities and use
style while some may be universally valid points. Somebody who aims to
enhance Gtk+ needs to heed the valid complaints. And in order to know
which one is what, all complaints need to be read with an open mind.

Therefore, requesting features or expressing critics in a constructive
way is good for Gtk+ and perfectly acceptable on its mailing-lists, it
is not a troll. It becomes "troll bait" because some people do not read
them with an open mind and reply in non-constructive ways, sometimes
bordering on insulting. Of course, when polite requests are met with
impolite replies, the ambiance eventually deteriorates on both sides,
and the critics become less polite. All sides should make conscious
efforts to avoid it.

As I said, some critics are a matter of taste and use style. I think
they should still be heeded: a toolkit like Gtk+ should strive to cater
for all users and all use styles; it is possible to make a GUI more
usable for certain users without making it less usable for others.
Furthermore, general principles about usability often have to give way
to other considerations. For example, if somebody is forced to work a
lot with applications developed with a mediocre toolkit, they will want
their few Gtk+ applications to behave as much as possible the same way:
even if it is not the "best" way, it is still more convenient for them,
and Gtk+ should propose it as an option.

Of course, implementing options and alternate behaviours costs time and
efforts, and testing the various combinations even more so. The work of
the Gtk+ team is given to the community gratis, nobody has any right to
demand anything about it: "sorry, we do not have time to implement it"
is always a valid answer in a Libre software project, but it should be
followed by "but if you implement it well and maintain it, we will
accept it gratefully".


According to many discussions here and elsewhere, it would seem that the
drop in ergonomics observed by a certain category of users came with the
release of Gtk+ 3. I think it is a mistake. I remember that the
behaviour of the file chooser evolved in a direction that I do not like
with the releases of Gtk+ 2. Also, even though I like Cairo very much
and I think it is a very good thing that it can be use so easily with
Gtk+, I am not sure I approve the use of Cairo for the core of the
drawing, and I am sure I disapprove the dropping of the ugly low-level
primitives.

I think the bend of the evolution happened around 2005, and I observe a
shift in the most frequent names in git log at that time. I think it
matches the time where the development of Gtk+ was taken over by GNOME
developers. I do not know how nor why this take over happened, and I do
not think it is relevant to the discussion. But the net outcome is that
progressively around 2005, Gtk+ stopped to be the GIMP toolkit and
became the GNOME toolkit.

With that in mind, I think the development and release of Gtk+ 3 is not
the cause but the consequence of the evolution: the new generation of
developers needed a major break to be able to implement the changes they
wanted.

I think that the nowadays Gtk+ developers should make their priorities
more explicit: do you want to make a toolkit that is designed to be used
everywhere or a tookit that serves primarily the needs of GNOME? But if
they do not say it explicitly, they let their actions speak for them.


One of the core aspects of the problem is that Gtk+ is the only decent
toolkit that have an API in plain C. If I am mistaken, please let me
know. Application developers who do not like C++ have no choice about
the toolkit they use.

Another of the core aspects of the problem is that the end users, who
benefit from good ergonomics and suffer when it is bad, are not the ones
who choose the toolkit.

For both these reasons, choosing another toolkit is not an option.

Therefore, if the Gtk+ developers continue to be deaf 

Application development for MS Windows now and in the future

[Joakim Majander]

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 they use in Windows.

Is there something I should be worried about? I guess there is no way to run my 
software in 10 S without upgrading to 10 Pro? Currently I only have Windows 7 
and 8 PC's, but several of my clients use 10 without issues. I don't know, if 
anybody has tried 10 S.

Best Regards,
Joakim
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Cong Monkey]

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 will the gitlab system ready for use?

Tks,
Cong
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

about the future deprecation of style properties

[cedlemo]

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 the roadmap I can see that it is in progress for Gtk 3.20. What will 
be the alternatives for the users?


cedlemo


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gnome in the future?

[narcisse doudieu siewe]

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 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.___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

gnome in the future?

[narcisse doudieu siewe]

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 to understand
is libraries are very well organised. With it you can make things
very complicated possible (this are the problems with Qt) but while c 
is good particularly for networking, it is heavy to program with it.
The low level has to be in c but it is important to have a binding
with an oriented object language like python (which is very easy to use)___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gnome in the future?

[Matthias Clasen]

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.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: future of development for the desktop

[Chris Vine]

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 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 ?

If there is a difference, and we are in the realm of guesswork, then I
would suspect the different theming engines as a more likely culprit.
I don't think that GDK has changed significantly - as far as I am aware
GTK+3 and later versions of GTK+2 both use cairo and cairo-pango.

I would be surprised if GTK+3 used significantly more heap allocation
than later versions of GTK+2.  Note also that glib memory slices are a
pretty efficient small object allocator.  It is a long time since
malloc() was used for anything other than large block allocations.  Be
careful or you will end up reinventing the wheel.

Chris
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Enrico Weigelt]

* 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 (heap) allocations,
lookups, etc, etc.

hmm, what could we possibly do about it ?

Perhaps support efficient static allocations (.data segment), combined
with a DSL (and an, maybe even platform/target specific compiler) for
expressing the UI structures - something like Glade's XML files, but
meant for compiling instead of dynamic loading.

Just some examples.

Menus: (picked the example from the gtk tutorial (*1))

menu id=main_menu static=true readonly=true
submenu title=/_File
item title=/_File/_New hotkey=controlN handler=print_hello /
item title=/File/_Open hotkey=controlO handler=print_hello /
item title=/File/_Save hotkey=controlS handler=print_hello 
id=save readonly=false/
item title=/File/Save _As id=main_menu_save_as readonly=false/
separator /
item title=/File/Quit hotkey=controlQ handler=gtk_main_quit /
/submenu
submenu title=/_Options /
item title=/Options/Test /
/submenu
submenu title=/_Help align=right
item title=/_Help/About /
/submenu
/menu

This notation has some interesting aspects:

* the id attribute of the menu tells the menu compiler how the menu variable
  (or macro) should be named. the compiler might also create several helper
  inline functions macros or macros for operating on that menu (at least
  for initialization and destruction)
* the entries for save and save-as also have id's, which just means they 
should
  be accessible from the code as variables (or macros) and provide helper
  macros/functions
* the static=true tells the menu compiler to generate some static struct 
(in .data)
* the menu's id will be used for the generated variable name
* the readonly=true tells it that the we never want to change anything here,
  so it can decide to put that even into .cdata
* the item title's are just the gettext keys for the visual text, *not* the
  path as used in GtkItemFactoryItem (the hierachy information is already
  encoded in the XML structure)
* the hotkeys could be even translated into some (perhaps even platform
  specific) input event code (so we dont need any mapping at runtime)
* handler functions are expected to be already (prototype-) defined

In the end, the compiler will generate some .h and .c file holding all the code
for that menu and it's items.

Our application might now initialize the menu (if there's some initialization
needed at all) by calling GTK_MENU_main_menu_init(). It can enable/disable the
save entry via GTK_MENU_ITEM_main_menu_save_enable(b). (- b is a boolean flag).


By this approach we could also describe all the individual widgets,
windows, etc, by our own DSL and let the compiler handle the actual
code generation. Initial versions would just translate to the current
object types (hmm, shall we call that classes ? ;-o), later versions
would use specialized ones, where it also can directly generate
internal structures.

This approach, IMHO, has several advantages:

a) we can do more RAD (maybe not that far as with Glade's dynamic
   loading) and make the whole application code easier to read/write
b) do performance/size optimizations behind the scenes, without
   having to touch individual applications (once they're ported to
   that new approach, of course ;-)).


Maybe we shoud review a bunch of smaller and larger gtk applications
and destill out some requirements catalog for that.


What do you think about that idea ?


cu

[1] http://www.gtk.org/tutorial1.2/gtk_tut-13.html
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Paul Davis]

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 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 be a good first step.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Jasper St. Pierre]

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 dynamic than its older versions.
 Maybe that's the problem: too many dynamic (heap) allocations,
 lookups, etc, etc.

Are you sure that's the cause of a slowdown? Did you make observations
and measure data?

 hmm, what could we possibly do about it ?

 Perhaps support efficient static allocations (.data segment), combined
 with a DSL (and an, maybe even platform/target specific compiler) for
 expressing the UI structures - something like Glade's XML files, but
 meant for compiling instead of dynamic loading.

 Just some examples.

 Menus: (picked the example from the gtk tutorial (*1))

 menu id=main_menu static=true readonly=true
    submenu title=/_File
        item title=/_File/_New hotkey=controlN handler=print_hello /
        item title=/File/_Open hotkey=controlO handler=print_hello /
        item title=/File/_Save hotkey=controlS handler=print_hello 
 id=save readonly=false/
        item title=/File/Save _As id=main_menu_save_as readonly=false/
        separator /
        item title=/File/Quit hotkey=controlQ handler=gtk_main_quit /
    /submenu
    submenu title=/_Options /
        item title=/Options/Test /
    /submenu
    submenu title=/_Help align=right
        item title=/_Help/About /
    /submenu
 /menu

 This notation has some interesting aspects:

    * the id attribute of the menu tells the menu compiler how the menu 
 variable
      (or macro) should be named. the compiler might also create several helper
      inline functions macros or macros for operating on that menu (at least
      for initialization and destruction)
    * the entries for save and save-as also have id's, which just means they 
 should
      be accessible from the code as variables (or macros) and provide helper
      macros/functions
    * the static=true tells the menu compiler to generate some static struct 
 (in .data)
    * the menu's id will be used for the generated variable name
    * the readonly=true tells it that the we never want to change anything 
 here,
      so it can decide to put that even into .cdata
    * the item title's are just the gettext keys for the visual text, *not* the
      path as used in GtkItemFactoryItem (the hierachy information is already
      encoded in the XML structure)
    * the hotkeys could be even translated into some (perhaps even platform
      specific) input event code (so we dont need any mapping at runtime)
    * handler functions are expected to be already (prototype-) defined

 In the end, the compiler will generate some .h and .c file holding all the 
 code
 for that menu and it's items.

 Our application might now initialize the menu (if there's some initialization
 needed at all) by calling GTK_MENU_main_menu_init(). It can enable/disable the
 save entry via GTK_MENU_ITEM_main_menu_save_enable(b). (- b is a boolean 
 flag).


 By this approach we could also describe all the individual widgets,
 windows, etc, by our own DSL and let the compiler handle the actual
 code generation. Initial versions would just translate to the current
 object types (hmm, shall we call that classes ? ;-o), later versions
 would use specialized ones, where it also can directly generate
 internal structures.

 This approach, IMHO, has several advantages:

 a) we can do more RAD (maybe not that far as with Glade's dynamic
   loading) and make the whole application code easier to read/write
 b) do performance/size optimizations behind the scenes, without
   having to touch individual applications (once they're ported to
   that new approach, of course ;-)).


 Maybe we shoud review a bunch of smaller and larger gtk applications
 and destill out some requirements catalog for that.


 What do you think about that idea ?


 cu

 [1] http://www.gtk.org/tutorial1.2/gtk_tut-13.html
 --
 --
  Enrico Weigelt, metux IT service -- http://www.metux.de/

  phone:  +49 36207 519931  email: weig...@metux.de
  mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
 --
  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
 --
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Enrico Weigelt]

* 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 be a good first step.

Sure. But, unfortunately, it's not trivial to set up some useful
test cases without actually implementing my suggested approach
in several applications first.

So, before writing any code, I'll first try to thing through
several scenarios and analyze what could be done and design
a model. When that's done, maybe I'll hire a bunch of students
for the actual coding.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Paul Davis]

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, etc.
   hmm, what could we possibly do about it ?
 
 measuring it would be a good first step.

 Sure. But, unfortunately, it's not trivial to set up some useful
 test cases without actually implementing my suggested approach
 in several applications first.


you made a fairly strong claim: that too many dynamic (heap) allocations
are involved in slowing down GTK3, either w.r.t. GTK2 and/or w.r.t. other
toolkits.

that seems like a fairly easy thing to test.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

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

[Marshall Lake]

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 don't do C++.  I only use C.  Can 
I use Qt with C ?


Are there any toolkits besides GTK which can be used with C ?

--
Marshall Lake -- ml...@mlake.net -- http://www.mlake.net
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

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

[Sergei Steshenko]

- 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.*.* 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 don't do C++.  I only use C.  
 Can 
 I use Qt with C ?
 
 Are there any toolkits besides GTK which can be used with C ?
 
 -- 
 Marshall Lake -- ml...@mlake.net -- http://www.mlake.net


You can write wrappers in C around C++ - unless what you need to do equates 
to making an instance of C++ template. But you'll need to understand some basic 
things about C++ - constructor, destructor, placement new.

Regarding the latter - start from http://en.wikipedia.org/wiki/Placement_new .

If you implement C wrappers, you'll have an additional function call overhead.

I am no promoter of C++, but gtk+ is ridiculous with its reinvented object 
model.

...

I suggest to read this: 
http://www.linuxquestions.org/questions/programming-9/why-c-is-still-out-there-946286/
 recent thread. Hopefully you will understand why a C toolkit ultimately 
can/should be slower than an equivalent C++ one.

...

I am no C++ programmer, I code mostly in Perl/C/GNU Octave, but I'm trying to 
objectively see in what C++ is better than C, and I still consider C++ to be 
a very convoluted language. But, alas, feature-wise it wins over C.

Regards,
  Sergei.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

future of development for the desktop

[Gour]

Hello!

I must admit that after researching which toolkit to use for
multi-platform desktop project (Nov  last year) to be done in D, we
strongly considered wxWidgets due to possibly better look of apps on
non-Linux platforms.

However, after reading the articles like:

http://arstechnica.com/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 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 of other platforms install (as long as it's available),
Virtualbox or something and run native Linux app that way.

What do you think?


Sincerely,
Gour

--
Everyone is forced to act helplessly according to the qualities 
he has acquired from the modes of material nature; therefore no 
one can refrain from doing something, not even for a moment.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Dov Grobgeld]

There is nothing in the article that sais that you cannot use another
toolchain to compile programs for Windows 8, like gcc, but I'm skeptical
whether that will still be possible. I'm used to compiling my free gtk+
software for windows XP, and Windows7 with a cross compiler under Linux.
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? Further
are there proprietory header files and libraries that you cannot use with
gcc? Whether gtk+ (and Qt just the same) will look native is a minor
issue, the question is if is possible to run it at all?

Regards,
Dov


On Fri, May 25, 2012 at 6:53 PM, Gour g...@atmarama.net wrote:

 Hello!

 I must admit that after researching which toolkit to use for
 multi-platform desktop project (Nov  last year) to be done in D, we
 strongly considered wxWidgets due to possibly better look of apps on
 non-Linux platforms.

 However, after reading the articles like:


 http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

 

 http://www.reddit.com/r/programming/comments/u3pqj/microsoft_pu/space/backup/cdisk-sverige/dosc/users/dorit/Gammal
 Disk/Tysk 
 ostkaka.doclling_free_development_tools_for/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 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 of other platforms install (as long as it's available),
 Virtualbox or something and run native Linux app that way.

 What do you think?


 Sincerely,
 Gour

 --
 Everyone is forced to act helplessly according to the qualities
 he has acquired from the modes of material nature; therefore no
 one can refrain from doing something, not even for a moment.

 http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Gour]

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? 

Well, the first article says: Developers won't be able to stick a
Metro-style application that they wrote themselves onto their website
and let people download it. Every application will have to go through
the Windows store, and will be subject to Microsoft's approval.

Of course, this is for Metro apps, but, still, it does not smell well,
or, let's say, it might be good for Linux. ;)


Sincerely,
Gour


-- 
Even the intelligent are bewildered in determining what is action 
and what is inaction. Now I shall explain to you what action is, 
knowing which you shall be liberated from all misfortune.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Gour]

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.

QML is mainly used for mobile applications where touch input, fluid
animations (60 FPS) and user experience are crucial.


Sincerely,
Gour


-- 
A person is considered still further advanced when he regards honest 
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Sergei Steshenko]

- 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 ( 
  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.
 
 QML is mainly used for mobile applications where touch input, fluid
 animations (60 FPS) and user experience are crucial.
 
 
 Sincerely,
 Gour
 

I didn't read the whole QML documentation, but I don't think that QML can not 
be used without animations and that it cannot be used with traditional input 
from mouse and keyboard.

I.e. my understanding of QML is that it's JavaScript-like language Qt binding 
with additional capabilities like GUI creation from description and the 
features you've mentioned.

...

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.

Regards,
  Sergei.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Gour]

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 cannot believe that gtk2 is 2x slower than Qt...It does not
make sense to me.


Sincerely,
Gour

-- 
From anger, complete delusion arises, and from delusion 
bewilderment of memory. When memory is bewildered, 
intelligence is lost, and when intelligence is lost 
one falls down again into the material pool.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Jasper St. Pierre]

Do you have any benchmarks results to back up the slower claim?

As for MSVC, I don't know. I don't think why we should reject patches
if someone has MSVC 11 Professional, and I don't think we should rip
support for MSVC 2010.

On Fri, May 25, 2012 at 12:49 PM, Sergei Steshenko sergst...@yahoo.com 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 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.

 QML is mainly used for mobile applications where touch input, fluid
 animations (60 FPS) and user experience are crucial.


 Sincerely,
 Gour


 I didn't read the whole QML documentation, but I don't think that QML can not 
 be used without animations and that it cannot be used with traditional input 
 from mouse and keyboard.

 I.e. my understanding of QML is that it's JavaScript-like language Qt binding 
 with additional capabilities like GUI creation from description and the 
 features you've mentioned.

 ...

 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.

 Regards,
   Sergei.

 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Sergei Steshenko]

- 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 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 cannot believe that gtk2 is 2x slower than Qt...It does not
 make sense to me.
 
 
 Sincerely,
 Gour
 

Will you search this list archives yourself or need a link from me ?

Regards,
  Sergei.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Sergei Steshenko]

 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 my a little bit earlier reply for details.

Regards,
  Sergei.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Gour]

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
speed.


Sincerely,
Gour



-- 
A person who has given up all desires for sense gratification, 
who lives free from desires, who has given up all sense of 
proprietorship and is devoid of false ego — he alone can 
attain real peace.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Jasper St. Pierre]

Ah, OK, you're basing the results on GTK+ 3.0. There were a few bugs
in GTK+ 3.0 (that were fixed in subsequent releases), and a lot of
widgets didn't really like the width-for-height allocation model,
tempting the layout to do double the work. A lot of widgets have been
fixed, and Company has also put some time into making GtkTreeView
faster. I'm not sure where he is with that.

On Fri, May 25, 2012 at 1:05 PM, Sergei Steshenko sergst...@yahoo.com wrote:






 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 my a little bit earlier reply for details.

 Regards,
   Sergei.

 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future of development for the desktop

[Sergei Steshenko]

- 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
 
 Ah, OK, you're basing the results on GTK+ 3.0. There were a few bugs
 in GTK+ 3.0 (that were fixed in subsequent releases), and a lot of
 widgets didn't really like the width-for-height allocation model,
 tempting the layout to do double the work. A lot of widgets have been
 fixed, and Company has also put some time into making GtkTreeView
 faster. I'm not sure where he is with that.
 

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 really want to hear from gtk+ gods - I've asked the question about gtk+ 
over Qt advantages, but have never seen an answer.

Regards,
  Sergei.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Enrico Weigelt]

* 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
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Enrico Weigelt]

* 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 apps. rather than having to
 create a web UI from scratch.

drop that idea at all. completely different paradigm with very
different semantics.

may you're looking for XUL ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Andre Osku Schmidt]

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 clipboard




___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Andre Osku Schmidt]

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 drawback:
 
 - there is no cross-browser way to copy text to systems clipboard

i mean, through javascript, that is...
and yeah, not that big drawback in general, but was for me yesterday...


___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[frederico schardong]

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 practice conventional desktop apps don't translate directly to the
 web very well, even with things like ajax.  Hence you're unlikely to
 ever see a version of GTK that targets a web browser.

 A far better solution is to write apps in a modular, flexible way, with
 a clear delineation between front end and back end.  That way you can
 easily move your app between platforms, UI tool kits, and even to the
 web by writing a web UI that accesses your backend code via an exposed
 service.
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-list




-- 
Thanks,
Frederico Schardong,
SOLIS - Open source solutions
www.solis.coop.br
Linux registered user #500582
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Michael Torrie]

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 how you do it) export a backend API
over SOAP or XMLRPC.  Then your frontend, written in whatever language
is appropriate (such as python or php) communicates with this backend.
Just one possible architecture.  There are many ways you could do this.

I actually end up writing backend stuff in python and django, and then
use xmlrpc to allow a GTK frontend app to communicate with it.  That way
my app can be a web-based app, written in an appropriate language (like
python), and then I can provide desktop frontends for when the web is
not convenient or appropriate as a front end.

Regardless of how you do the back end, web front-ends are always going
to be a mix of some server language (the language that dynamically
generates the html pages) and will definitely require Javascript (ajax)
and CSS skill.  There's no real getting around that, at least if you
want to use a web browser as a client.

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

future GTK+ rendering to browser

[shakil anwar]

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 scratch.

Maybe could be done by parsing existing Glade files or intercepting
events (I am no expert) ?

Thanks James
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Alejandro Forero Cuervo]

 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 scratch.
 
 Maybe could be done by parsing existing Glade files or intercepting
 events (I am no expert) ?

Gtkwebd may not be exactly what you're thinking, but it's probably
similar:

  http://wiki.freaks-unidos.net/gtkwebd

Alejo.
http://azul.freaks-unidos.net/
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: future GTK+ rendering to browser

[Michael Torrie]

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 to
ever see a version of GTK that targets a web browser.

A far better solution is to write apps in a modular, flexible way, with
a clear delineation between front end and back end.  That way you can
easily move your app between platforms, UI tool kits, and even to the
web by writing a web UI that accesses your backend code via an exposed
service.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

future GTK+ rendering to browser

[a lister]

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 scratch.

Maybe could be done by parsing existing Glade files or intercepting
events (I am no expert) ?

Thanks James
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

gtk canvas future

[zentara]

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 c++ style of foo,
as a general rule for me.

Thanks,
zentara
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Future GTK+ projects and 1.18 new features page

[Javier Jardón]

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.
I've started this page: [3], but I'd like move it to [4] if you agree
and complete it together.

Best Regards,

[1] http://live.gnome.org/JavierJardon/GTKFuture
[2] http://live.gnome.org/GTK+
[3] http://live.gnome.org/JavierJardon/TwoPointEighteen
[4] http://live.gnome.org/GTK+/TwoPointEighteen
-- 
Javier Jardón Cabezas
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Current status of GtkPlug/GtkSocket and plans for the future

[Alexandre Franke]

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 much is it used? I took a quick look on Google code search and
couldn't really find many applications using it.

2 - Could it somehow replace Bonobo? If the answer is no, I would
appreciate if someone could make it clear what GtkPlug/GtkSocket lacks
that Bonobo provides.

3 - I understand that at the time it was written, DBus was maybe not
there yet, but now, wouldn't it be a good idea to follow the trend and
port it to DBus and get rid of XEmbed to gain portability by removing
the dependancy towards the X Window system?

4 - An in-process approach for components could prove very efficient.
Instead of trying to do IPC (via Corba, DBus, XEmbed, etc), what about
simple calls to a shared library?

5 - I got the impression that GtkPlug/GtkSocket is intended for
embedding components between two threads of the same application
(written by the same developper), not between two different
applications that know very few about each other. Is that correct?

6 - What about interoperability with: OLE (microsoft), KParts (KDE),
UNO (OpenOffice.org)?

I guess that most of the answers to these questions will be you're on
the wrong track or it's not that easy but as a newbie on this
topic, I'd be very interested to have explanations on why things can't
be done or what I didn't understand (or find enough information on).

Thanks for your time and patience.

-- 
Alexandre Franke
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

[Vallone, Anthony]

I am using GtkPlug/GtkSocket on a large space system program.  It turned
out to be incredibly useful to us.  We have a docked window at the top
of the screen that displays a summary of system status.  This docked
window has four GtkSockets that are plugged by four other applications.
Doing it this way made it easy for us to decrease coupling between the
docked window and the other applications that generate the summary
information because the docked window doesn't need to know about any of
the information that is controlled by the other applications.

-Anthony Vallone

-Original Message-
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 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 much is it used? I took a quick look on Google code search and
couldn't really find many applications using it.

2 - Could it somehow replace Bonobo? If the answer is no, I would
appreciate if someone could make it clear what GtkPlug/GtkSocket lacks
that Bonobo provides.

3 - I understand that at the time it was written, DBus was maybe not
there yet, but now, wouldn't it be a good idea to follow the trend and
port it to DBus and get rid of XEmbed to gain portability by removing
the dependancy towards the X Window system?

4 - An in-process approach for components could prove very efficient.
Instead of trying to do IPC (via Corba, DBus, XEmbed, etc), what about
simple calls to a shared library?

5 - I got the impression that GtkPlug/GtkSocket is intended for
embedding components between two threads of the same application
(written by the same developper), not between two different
applications that know very few about each other. Is that correct?

6 - What about interoperability with: OLE (microsoft), KParts (KDE),
UNO (OpenOffice.org)?

I guess that most of the answers to these questions will be you're on
the wrong track or it's not that easy but as a newbie on this
topic, I'd be very interested to have explanations on why things can't
be done or what I didn't understand (or find enough information on).

Thanks for your time and patience.

-- 
Alexandre Franke
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

[Lukasz]

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 saves them in my app,
to have predefined settings by himself. Then, when printing, he just
selects one of them from toolbar in my app and does the printing without
actually showing printing dialog.

Is that possible or should I implement my own printing dialog ? 


--
Piekne piersi bez skalpela? To mozliwe!
http://link.interia.pl/f1dd8

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Padding for future expansion

[Micah Carrick]

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 - http://www.gtkforums.com

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Future of GtkTooltips

[Christof Petig]

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 time into that topic besides studying the
current design and thinking about improvements (which I mostly posted to
the list). Of course I'm still interested in a solution (even if I did
not design/code it myself ;-) )
Back to my current remote_cvs-monotone sync project
   Christof
PS: To summarize from memory: My idea was to design it hierarchically:
Once you are about to display a tooltip traverse the widget tree (at
given mouse position) and display the bottommost tooltip available.
(E.g. a container is asked for a tooltip at position x,y: ask the child
at that position for a tooltip (recursively via a callback (so that each
widget has a chance of returning a different tooltip based on relative
mouse position)), if nothing comes back use the containers tooltip).
IIRC groups (design proposed by Owen) mostly serve to display a tooltip
upon different related widgets (e.g. adiacent buttons in a toolbar)
without delay.


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[muppet]

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 provides anti-flicker capabilities.
So it would be interesting to map where the canvas is still used. I'd
assume gnome-games and nautilus for example.
I use GnomeCanvas for interactive structured graphics --- a view where 
the user directly manipulates shapes and objects that represent things 
in a document that aren't text cells.  Think of flowcharts or graphs or 
things of that nature.  Having canvas items which are basically drawing 
elements with events is really handy, relieving the application 
programmer of responsibility for tedious things like hit testing.

Also keep in mind that many apps of this nature are small-audience, 
special use, in-house things.

--
The door is locked.  I tried to open it, but the lock is harder to pick 
than a broken nose.
  -- Sensei, on 'I, Ninja'

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Future of GtkTooltips

[Christian Neumair]

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 for powerful tooltips, might be overhead
- Or use at least PangoMarkup or PangoLayout

Location:
- Model an optional function similar to GtkMenuPositionFunc

Internals:
All attempts to work around internal exposure MUST fail. A clean
reorganization would include redesigning the tooltip-widget relation.
To be honest, I'm not sure whether it is useful to group tooltips
together in GtkTooltips at all. Is this used? Aren't tooltips usually
describing widget's functions independently from other widgets? Are
people using multi-functional widget groups with multiple GtkTooltips
assigned that are enabled/disabled when needed?
Wouldn't it be more simple to create one GtkTooltip (which would be a
new type) per widget, passing a text layout and an optional position
function to the tooltip and assign it somehow to the widget, maybe
through a property? If people want multi-functional widgets, wouldn't it
be simpler to optionally associate a widget state with a tooltip?

It would be great to get some application author feedback, I'm really
eager to redesign tooltips for GTK+ 2.8 :), this task has been
outstanding for a long time.

-- 
Christian Neumair [EMAIL PROTECTED]

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Future of GtkTooltips

[Damon Chaplin]

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
 
 Proposed resultions:
 
 Flexibility:
 - Use either GtkTextBuffer for powerful tooltips, might be overhead
 - Or use at least PangoMarkup or PangoLayout
 
 Location:
 - Model an optional function similar to GtkMenuPositionFunc

I think you should track mouse movement in the core GTK+ event handling
code, and setup the idle handler function there. Then when the idle
handler fires you can find out which widget the mouse is in and call a
new function like gtk_widget_show_tooltip() on it. (This hopefully means
it can be used for NO_WINDOW widgets as well as widgets with windows,
unlike the present code.)

The default gtk_widget_show_tooltip() class function would do basically
the same as now, but subclasses could override it so they could change
the position or text of the tooltip as appropriate. (But you'd provide
helper functions for doing the basic tooltip stuff.)

I'd use the code event handling code to check when to hide tips as well,
as that could be tricky.

I don't think the GtkTooltips thing is much use. Though I don't know the
code too well.

Damon


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Future of Canvas on GTK+ (and probably GNOME)

[Fabrício Barros Cabral]

Hi all,

I was thinking develop a program using canvas, but some facts come in my
mind:

1) I've read in live.gnome.org[0] libgnomecanvas is deprecated;

2) Cairo now is a dependency of GTK+ (HEAD).

I've seen here about several problems around libgnomecanvas, and you
suggests to people use others alternatives, like FooCanvas (which is
inside Gnumeric). But FooCanvas has IMHO, some problems, like the
license (it's GPL and not LGPL as GTK+) and there isn't an anti-aliased
support.

So, I'm bit confuse: should I develop my own (LGPL) canvas library? Use
DiaCanvas[1] instead of it? Or wait 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
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

future windows port availability

[Bernhard . Rumpler]

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) not used by as many
developers as for Linux/Unix.

Are there any official statements on the availability
of the windows port? Not just for the next release but 
also in the long run.

I really appreciate the work of Tor and Hans and all
others working on the windows port, but if the port's 
future is not yet clear and it's completeness depends 
on the amount of free time of just one or two 
developers, that's an argument not to use gtk (at least 
for applications to be used mainly under windows).

Bernhard
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_paint_string future

[Matej Knopp]

Da St, 2002-06-05 at 22:18, Daniel Elstner napsal:
 Am Mit, 2002-06-05 um 21.21 schrieb Matej Knopp:
  
  I'm writing an application and have chosen Gtk+ 2.0 for the gui. During
  the programming I came to a very significant problem. The main window
  consists of a pane with GtkTextView and GtkTreeView. The text view is
  fine but the tree view almost made me abanon Gtk. It has 12 columns
  (text) and after it's filled working with the app turns to be a pain.
  Some experimentation showed the reason: GtkCellRendererText (and Pango).
  Resizing the window, moving the pane or resizing columns was so delayed
  that the app was absolutely unusable for production. I like pango and
  the way it works but computing unicode layout and painting it so many
  times was a too big deal even for duron 850. So I decided let unicode be
  a wrote my own simple text renderer that converts unicode to 8 bit local
  enc. and draws it with gtk_paint_string. It works suprisingly well.
 
 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.  Did you realize that most people on this world speak languages
 which cannot be represented in an 8bit encoding?

Yes, I did. But the app is very specific and I doubt anyone out of my
country would find any use for it. It's not a problem to add a feature
that would allow you to switch to unicode but this is not the point.
Forcing me to use unicode (removing gtk_paint_string) would almost equal
to forcing me to change toolkit because The application would be
unusable for the people here who need it no matter how many languages it
could render.


  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-di, antialiasing,
  etc. but I'd give all these for fast text output.
 
 It would be much better to ask how you can make the Pango version
 faster.  I suspect it *might* a problem on your side, a Duron 850 is not
 slow enough to render your app unusable.

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...).

 --Daniel

-matej.


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_paint_string future

[Matej Knopp]

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 using
  Unicode.
 
 If the performance is unacceptable, then the performance is unacceptable.
 If reducing the target user base is the only way the programmer can get
 his or her app to work to their standard, then that is their decision. If
 this is an open source project, you are free to improve it if you want.

You got the point. Nobody would use program with such a slow feedback if
there were more acceptable solutions. And adding support for unicode is
a matter of several lines to allow switching the cell renderers. Anyone
who could afford it could use unicode. For the others (who are the
primary target) 8-bits are enough.

 Either the library has to be sped up, or if it is a problem with the
 person writing the code, then the documentation needs to improve. Don't
 shoot the messenger. This is valuable feedback.

I can't affect the performance of the CellRenderer. The Gtk+ demos are
faster, but the difference is that my table is bigger (covers almost the
whole screen) and also more dense (12 columns).

 My $0.02,
 Chris
 
 


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_paint_string future

[Soeren Sandmann]

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...).

Actually, a variant of the only draw uncovered areas optimization
has been in CVS HEAD for a while. You could try that version (it is
source and binary compatible), but if the current TreeView is really
_unusable_, then I suspect something else might be the real reason.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

gtk_paint_string future

[Matej Knopp]

Hi,

I'm writing an application and have chosen Gtk+ 2.0 for the gui. During
the programming I came to a very significant problem. The main window
consists of a pane with GtkTextView and GtkTreeView. The text view is
fine but the tree view almost made me abanon Gtk. It has 12 columns
(text) and after it's filled working with the app turns to be a pain.
Some experimentation showed the reason: GtkCellRendererText (and Pango).
Resizing the window, moving the pane or resizing columns was so delayed
that the app was absolutely unusable for production. I like pango and
the way it works but computing unicode layout and painting it so many
times was a too big deal even for duron 850. So I decided let unicode be
a wrote my own simple text renderer that converts unicode to 8 bit local
enc. and draws it with gtk_paint_string. It works suprisingly well.

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-di, antialiasing,
etc. but I'd give all these for fast text output.

I've also some comments on GtkTreeView. I think there are some further
possible optimizations. I'm not a Gtk+ hacker nor completely understand
GtkTreeView details. What I know is that it does complete repaint on
widget resizing and column resizing. The scrolling is OK since it's
(AFAIK) hw-hw blit. 
Now about widget resizing. I know this bit of work but it should be
possible to copy the part of widget before resizing (I'm not quite sure
about this...) and just update the rest. This would be cool in my case
when the View is in a pane.
The column resizing repaints the whole widget too. IMHO in most cases
the part to the left of resized column could stay unchanged, the resized
column has to be redrawn and the part to the right could be just copied
(moved). (HW-HW are most probably accelerated and this should be faster
then computing the layout and drawing it.

That's all, no more whinning :)

Cheers,
-matej


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_paint_string future

[Daniel Elstner]

Am Mit, 2002-06-05 um 21.21 schrieb Matej Knopp:
 
 I'm writing an application and have chosen Gtk+ 2.0 for the gui. During
 the programming I came to a very significant problem. The main window
 consists of a pane with GtkTextView and GtkTreeView. The text view is
 fine but the tree view almost made me abanon Gtk. It has 12 columns
 (text) and after it's filled working with the app turns to be a pain.
 Some experimentation showed the reason: GtkCellRendererText (and Pango).
 Resizing the window, moving the pane or resizing columns was so delayed
 that the app was absolutely unusable for production. I like pango and
 the way it works but computing unicode layout and painting it so many
 times was a too big deal even for duron 850. So I decided let unicode be
 a wrote my own simple text renderer that converts unicode to 8 bit local
 enc. and draws it with gtk_paint_string. It works suprisingly well.

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.  Did you realize that most people on this world speak languages
which 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-di, antialiasing,
 etc. but I'd give all these for fast text output.

It would be much better to ask how you can make the Pango version
faster.  I suspect it *might* a problem on your side, a Duron 850 is not
slow enough to render your app unusable.

--Daniel

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_paint_string future

[Chris Nystrom]

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, then the performance is unacceptable.
If reducing the target user base is the only way the programmer can get
his or her app to work to their standard, then that is their decision. If
this is an open source project, you are free to improve it if you want.

Either the library has to be sped up, or if it is a problem with the
person writing the code, then the documentation needs to improve. Don't
shoot the messenger. This is valuable feedback.

My $0.02,
Chris


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Future of GTK

[Havoc Pennington]

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 "emulating" toolkit (meaning it
draws its own widgets that may look like native widgets given the
right theme, but it doesn't use native widgets). AFAIK wxWindows is a
"wrapper" toolkit (meaning it uses native widgets underneath).  A
"wrapper" toolkit is going to be less flexible/powerful than a native
toolkit like GTK, in general. This is why Java moved away from that
(AWT) and Swing has a more GTK-like approach. But of course a wrapper
toolkit has more native LF. On the other hand, GTK _is_ the native
LF on at least one platform, unlike Swing.

  How easy/feasible is it to bind various languages to C++?

For language bindings the issue isn't C vs. C++. The issue is that GTK
has an object system designed to facilitate language bindings. You
could write such an object system in C or in C++ (in fact Microsoft
has done so as part of their .NET framework). The "object system" that
C++ has by default though isn't very good for this, you need a more
powerful object system on top.

And of course pretty much all large C++ systems have a more powerful
object system on top - QObject in Qt for example. Though QObject is
not designed to address the language binding issue.

Havoc

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list