Re: Gtk+4.0

[philip . chimento]

On Sun, Jul 10, 2016 at 3:51 PM John Tall  wrote:

> On Sat, Jul 9, 2016 at 9:06 PM,  wrote:
> > I'm expecting this will become less and less of a problem as apps move
> to Flatpak as a means of distribution.
>
> As far as I know Flatpak only targets GNU/Linux, and at the moment
> only targets a handful of distros. I make software for not only
> GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries
> including GTK+. I don't know yet if or how these changes will impact
> me, all I know is that the way things are right now works just fine
> for me.
>

Let me state categorically:

Nothing in this proposal forces anyone to use Flatpak.

Though I am excited about Flatpak if that wasn't obvious by now, I myself
also make software for other platforms than Linux and contribute quite a
lot of my time towards keeping GTK and other libraries buildable on Mac OS
X.

I really don't want to turn this thread into a discussion of the merits of
Flatpak. What I did (more explanation here [1]) was try to answer a
question, essentially "What if some app developer does ?"
that I would previously, before Flatpak existed, have answered "Well, don't
do that then." Instead, I can now say "I hope fewer people will do  because of Flatpak."


> I'm worried that we're breaking things that already work for lots of
> us in order to fix inconveniences that some people have. I don't want
> to drastically change the way I make and distribute software just
> because one of the many libraries that I use has decided to do things
> differently. If things need to change then do whatever is necessary
> but please, let the old stuff also continue to work.
>

If you track the long-term supported releases of GTK with your software,
then you shouldn't need to change anything in the way you make and
distribute it.

Regards,
Philip C

[1] https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg9.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[John Tall]

On Sat, Jul 9, 2016 at 9:06 PM,  wrote:
> I'm expecting this will become less and less of a problem as apps move to 
> Flatpak as a means of distribution.

As far as I know Flatpak only targets GNU/Linux, and at the moment
only targets a handful of distros. I make software for not only
GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries
including GTK+. I don't know yet if or how these changes will impact
me, all I know is that the way things are right now works just fine
for me.

I'm worried that we're breaking things that already work for lots of
us in order to fix inconveniences that some people have. I don't want
to drastically change the way I make and distribute software just
because one of the many libraries that I use has decided to do things
differently. If things need to change then do whatever is necessary
but please, let the old stuff also continue to work.

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

Re: Gtk+4.0

[Jasper St. Pierre]

On Sun, Jul 10, 2016 at 1:28 PM,  wrote:

> On Sat, Jul 9, 2016 at 1:14 PM Peter Weber 
> wrote:
>
>> Hi!
>>
>> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote:
>>
>> > I'm expecting this will become less and less of a problem as apps move
>> > to Flatpak as a means of distribution.
>>
>> Uhuuu. I'm sorry, but this is bad.
>>
>> This mixes two completely different problems together, packaging and a
>> toolkit. So enforcing Flatpak on distributions, developers and users
>> should solve a problem with Gtk+?
>>
>
> No, nothing about any of this proposal forces people to use Flatpak.
>
> The problem Emilio mentioned was,
>
> > some third party apps pick a dependency on the vte for GTK+ 4.2 but
> don't update it for GTK+ 4.4, as then distros would need to ship an
> increasing number of versions that are unlikely to get any support upstream.
>
> In my opinion, the expectation is that app developers who sign on to the
> unstable series will see it through until the next long-term stable
> release, and not abandon development while still targeting an unstable
> release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2,
> VTE-for-GTK-4.4, etc. because apps are all stuck at different versions.
>
> Of course, nothing is stopping developers from doing that anyway. The same
> way nothing is stopping me right now from putting this line in my app's
> configure.ac:
> PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20])
> However, if I did that then any distros trying to package it would quite
> rightly complain.
>
> I'm saying that if an app developer feels the need to do that, then they
> will be better off targeting a Flatpak runtime.
>
> Having said all this, I'm thinking about sketching out a proposal that
> doubles down on Flatpak like Jasper was suggesting. Paradoxically I think
> it might seem more palatable to more people... more updates later.
>

I intended my proposal as an strawman explanation that I thought was
obviously silly. It wasn't a serious proposal, and I don't think it's the
correct direction for the project to move in.


> Regards,
> Philip C
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>


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

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 1:14 PM Peter Weber  wrote:

> Hi!
>
> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote:
>
> > I'm expecting this will become less and less of a problem as apps move
> > to Flatpak as a means of distribution.
>
> Uhuuu. I'm sorry, but this is bad.
>
> This mixes two completely different problems together, packaging and a
> toolkit. So enforcing Flatpak on distributions, developers and users
> should solve a problem with Gtk+?
>

No, nothing about any of this proposal forces people to use Flatpak.

The problem Emilio mentioned was,

> some third party apps pick a dependency on the vte for GTK+ 4.2 but don't
update it for GTK+ 4.4, as then distros would need to ship an increasing
number of versions that are unlikely to get any support upstream.

In my opinion, the expectation is that app developers who sign on to the
unstable series will see it through until the next long-term stable
release, and not abandon development while still targeting an unstable
release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2,
VTE-for-GTK-4.4, etc. because apps are all stuck at different versions.

Of course, nothing is stopping developers from doing that anyway. The same
way nothing is stopping me right now from putting this line in my app's
configure.ac:
PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20])
However, if I did that then any distros trying to package it would quite
rightly complain.

I'm saying that if an app developer feels the need to do that, then they
will be better off targeting a Flatpak runtime.

Having said all this, I'm thinking about sketching out a proposal that
doubles down on Flatpak like Jasper was suggesting. Paradoxically I think
it might seem more palatable to more people... more updates later.

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

Re: Nim GTK3 editor

[Stefan Salewski]

On Sun, 2016-07-10 at 15:54 +0200, Stefan Salewski wrote:
> Maybe another one, but less important: I am using GSettings -- for
> testing if the editor would work fine on a  fresh install, I would
> like
> to reset all modifications done by my program.

OK, that was not too difficult.

http://unix.stackexchange.com/questions/8922/where-does-gsettings-store-its-files

deleting

/home/stefan/.config/dconf/user

does the trick, which this new message

(ned:2316): Gdk-CRITICAL **: gdk_rgba_parse: assertion 'spec != NULL' failed

proves. So my fear was justified, before shipping a GTK app one has to
test with virgin GSettings

Seems that my app tries to access colors which are not already set by
user in GSettings.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Nim GTK3 editor

[Stefan Salewski]

Yesterday I pushed my Nim editor to github, see

http://ssalewski.de/tmp/NEd.png

https://github.com/ngtk3/NEd

http://forum.nim-lang.org/t/2198

Lets try an easy question: I am using the font chooser button, which
has default text (none) and later shows the name of the last opened
file. For my use in the header bar, I would like to change that label,
maybe to "Open" permanently. No chance?

Maybe another one, but less important: I am using GSettings -- for
testing if the editor would work fine on a  fresh install, I would like
to reset all modifications done by my program. No idea after googling
for a few minutes -- when I create a new user and log in into that
account I should get a clean environment I guess? 

The development up to this early stage was easy and fast, and indeed I
was surprised how fine GtkSourceView works. OK, most of it, that idle
scroll -- would be very hard without gedit sources...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list