Re: How to get a "traditional" file-chooser

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the support, Stefan, but let me clarify a little...

I'm not a "beginner."  I wrote my first line of C sometime in the early 80s.  I wrote my first line of code of any kind (in APL) in the early 70s, with lots of IBM 370 and x86 assembler in the interim.  I'm not sure how long I've been using GTK--15 years?  Something like that.

My point in my original post was that a toolkit should, above all, be useful, preferably in as wide a range of uses as possible.  And, by that measure, GTK2 was a great deal more useful, at least in certain environments, than GTK3.  Not every app needs the stylistic consistency offered by a fairly complex CSS paradigm.  The code I write is primarily in aid of technical visualisation involving cairographics in a drawing area, OpenGL, and so on, and usually involves a complex UI containing lots and lots of spinbutton widgets and similar controls.  Screen space is a premium, a pretty UI is not, and there some things that, so far as I've been able to discover, you just can't do with the GTK3 CSS mechanism that are trivial to do under GTK2.

Since its inception, it's been a *ix paradigm that system capabilities should be as close to orthogonal as possible, every capability doing one thing and doing that one thing very well.  In saying "modify_bg() has never done anything about sizing," Mr Bassi is implicitly denying that paradigm and asserting that his tool-of-choice, CSS, is superior because of its non-orthogonality, that a single capability is lacking that can't control colour, size, font, etc, etc all at the same time.

There was never anything wrong with adding CSS capability to GTK, but in my opinion it was a mistake to deprecate and/or remove the detailed control provided by modify_bg() and the rest of that family.  Replacing detailed controls with CSS, in many applications, increased complexity and reduced functionality, both in aid of a programming objective neither useful nor desired in a wide range of apps.  Not a good way to go.

By the way, Stefan, your English is fine.

On 09/16/17 06:06, Stefan Salewski wrote:
On Fri, 2017-09-15 at 22:41 +0100, Emmanuele Bassi wrote:
Additionally, modify_bg() has never done anything about
sizing,
Sometimes you seems to try very hard to misunderstand people?

My English is not good, but I really think Chris Moller was refering
only to the fact that modify_bg() was deprecated in GTK3 and does not
work properly often when people try to use it. Changing colors is what
beginners like to do. And they generally expect that only one simple
function call is necessary to do it. With Google you can find many
questions of people asking why modify_bg() or modify_fg() does not work
as expected. Finding an example for a properly working solution for
GTK3 is possible, but not as easy as it should be.

To avoid getting such complains for the Nim bindings, I decide to give
an example in the mini tutorial for the label widget:

https://github.com/StefanSalewski/gintro

I hope that is correct, it is based on a C version someone posted at
stackoverflow.

I know that modifying colors is not that easy in GTK3, as backgrounds
can be gradients for example. And using arbitrary colors generally look
not good for all themes. For me that is OK. But is there really no way
to allow a one function() call option for kids and beginners? Well,
should we really care about kids and beginners at all? As they will not
be able to contribute something valuable -- only stupid questions. But
the fact is, that most users start as kids or beginners with GUI
toolkits or programming languages -- and some of them years later may
do valuable contributions.



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

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux