Re: The Future?

2019-03-13 Thread 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?

2019-03-13 Thread 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?

2019-03-13 Thread 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?

2019-03-13 Thread 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?

2019-03-13 Thread 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?

2019-03-13 Thread 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?

2019-03-11 Thread 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?

2019-03-11 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-10 Thread 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?

2019-03-09 Thread 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?

2019-03-09 Thread 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


Re: gtk_paint_string future

2002-06-06 Thread 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

2002-06-06 Thread 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

2002-06-06 Thread 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



Re: gtk_paint_string future

2002-06-05 Thread 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

2002-06-05 Thread 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