How to get a "traditional" file-chooser

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How to get a "traditional" file-chooser

Clemens Eisserer
Hi,

Until recently I tried to avoid GTK3 applications, because the GTK3's
file chooser is driving me crazy.
However, as more and more applications of my desktop environment are
ported to GTK3, I wonder ... is there any way, to get a more
traditional file chooser for GTK3 applications which resembles what
GTK2 or QT offer?

Thank you in advance, Clemens
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Daniel Kasak-4
Of course there is. Use GTK2 or QT apps. I suggest Redhat 5. That shit
is old school.

On Fri, Sep 15, 2017 at 4:22 AM, Clemens Eisserer <[hidden email]> wrote:

> Hi,
>
> Until recently I tried to avoid GTK3 applications, because the GTK3's
> file chooser is driving me crazy.
> However, as more and more applications of my desktop environment are
> ported to GTK3, I wonder ... is there any way, to get a more
> traditional file chooser for GTK3 applications which resembles what
> GTK2 or QT offer?
>
> Thank you in advance, Clemens
> _______________________________________________
> gtk-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Paul Davis
Now that was surely helpful.

On Thu, Sep 14, 2017 at 6:48 PM, Daniel Kasak <[hidden email]> wrote:
Of course there is. Use GTK2 or QT apps. I suggest Redhat 5. That shit
is old school.

On Fri, Sep 15, 2017 at 4:22 AM, Clemens Eisserer <[hidden email]> wrote:
> Hi,
>
> Until recently I tried to avoid GTK3 applications, because the GTK3's
> file chooser is driving me crazy.
> However, as more and more applications of my desktop environment are
> ported to GTK3, I wonder ... is there any way, to get a more
> traditional file chooser for GTK3 applications which resembles what
> GTK2 or QT offer?
>
> Thank you in advance, Clemens
> _______________________________________________
> gtk-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Daniel Kasak-4
Come on. It's troll bait. He comes to a gtk+ list, declaring his
preference upfront to not use gtk3 because the "file chooser is
driving me crazy". In what why is the file chooser driving him crazy?
Unknown - other than it not looking like GTK2 or qt ( unknown version
) file chooser. Just wondering: what apps use a file chooser anyway?
He didn't mention that either. There's gedit and glade ( I'm guessing
he's not using glade ). He does mention that "more and more
applications of my desktop are ( being ) ported to GTK3". I'm again
wondering which applications. If you're on Gnome or Cinnamon or
whatever, you get *all* GTK3 apps, not a mix  Doesn't add up to me.
Anyway, would you like to tease more information out of Clemens
regarding what parts of the file chooser is driving him crazy? In the
meantime, I stand by my recommendation. If someone passionately hates
parts of a gui toolkit, they should use apps written in a different
toolkit. If, on the other hand, they have a serious intention to use
gtk3, then constructive observations / suggestions / feature requests
would have been included, and things like "drive me crazy" and "I
tried to avoid GTK3 applications" would not. Quick comparison ... I
don't use QT apps when I have a choice either ... I prefer GTK apps. I
like GTK's default theme better, and I also develop GTK apps. I like
some consistency on my desktop, so once there's a critical mass of
apps using 1 toolkit, I try to have all apps using that toolkit.
That's personal choice. However, note that I don't rock up to QT
mailing lists declaring "Hey there donkeys ... I've tried really hard
not to use QT because I think the calendar widget looks like arse. How
about you make it more like GTK3?".

On Fri, Sep 15, 2017 at 9:43 AM, Paul Davis <[hidden email]> wrote:

> Now that was surely helpful.
>
> On Thu, Sep 14, 2017 at 6:48 PM, Daniel Kasak <[hidden email]>
> wrote:
>>
>> Of course there is. Use GTK2 or QT apps. I suggest Redhat 5. That shit
>> is old school.
>>
>> On Fri, Sep 15, 2017 at 4:22 AM, Clemens Eisserer <[hidden email]>
>> wrote:
>> > Hi,
>> >
>> > Until recently I tried to avoid GTK3 applications, because the GTK3's
>> > file chooser is driving me crazy.
>> > However, as more and more applications of my desktop environment are
>> > ported to GTK3, I wonder ... is there any way, to get a more
>> > traditional file chooser for GTK3 applications which resembles what
>> > GTK2 or QT offer?
>> >
>> > Thank you in advance, Clemens
>> > _______________________________________________
>> > gtk-list mailing list
>> > [hidden email]
>> > https://mail.gnome.org/mailman/listinfo/gtk-list
>> _______________________________________________
>> gtk-list mailing list
>> [hidden email]
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Clemens Eisserer
Hi,

> Come on. It's troll bait.
Actually it is not.

> Just wondering: what apps use a file chooser anyway?
Evince, Firefox, Gimp (still GTK2), Eclipse, Geany (still GTK2), ...

> He comes to a gtk+ list, declaring his
> preference upfront to not use gtk3 because the "file chooser is
> driving me crazy". In what why is the file chooser driving him crazy?
> Unknown - other than it not looking like GTK2 or qt ( unknown version
> ) file chooser.

I actually sat down and compared GTK2 and GTK3 regarding the file-chooser.
The one and only thing that really bothers me is GTK3 starting a
search immediatly when I start typing a file-name, where I only would
like it to jump to the file/folder that starts with the letters I just
typed.
Is there any know to turn that instant-search feature off and return
to the more traditional "select on type" mode?

Regards, Clemens

(beside I frequently hit a bug where file-icons sometimes only appear
after forcing a redraw (scrolling, selecting a file).
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Dub
Reply | Threaded
Open this post in threaded view
|

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

Dub
You have access to the low level apis of the OS just use those to initiate the file picker.

On Sep 15, 2017 15:29, "Clemens Eisserer" <[hidden email]> wrote:
Hi,

> Come on. It's troll bait.
Actually it is not.

> Just wondering: what apps use a file chooser anyway?
Evince, Firefox, Gimp (still GTK2), Eclipse, Geany (still GTK2), ...

> He comes to a gtk+ list, declaring his
> preference upfront to not use gtk3 because the "file chooser is
> driving me crazy". In what why is the file chooser driving him crazy?
> Unknown - other than it not looking like GTK2 or qt ( unknown version
> ) file chooser.

I actually sat down and compared GTK2 and GTK3 regarding the file-chooser.
The one and only thing that really bothers me is GTK3 starting a
search immediatly when I start typing a file-name, where I only would
like it to jump to the file/folder that starts with the letters I just
typed.
Is there any know to turn that instant-search feature off and return
to the more traditional "select on type" mode?

Regards, Clemens

(beside I frequently hit a bug where file-icons sometimes only appear
after forcing a redraw (scrolling, selecting a file).
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Michael Torrie
In reply to this post by Daniel Kasak-4
On 09/14/2017 10:56 PM, Daniel Kasak wrote:
> Come on. It's troll bait.

No I don't think so either.  Responses like yours to issues like this
are really unhelpful to everyone.

> He comes to a gtk+ list, declaring his
> preference upfront to not use gtk3 because the "file chooser is
> driving me crazy". In what why is the file chooser driving him crazy?
> Unknown - other than it not looking like GTK2 or qt ( unknown version
> ) file chooser.

> Just wondering: what apps use a file chooser anyway?

This propensity of people to say, implied if not literally, you're
stupid for wanting some feature you used to have is something that I am
seeing more and more in the community surrounding GTK and Gnome. It's
very disheartening.

> He didn't mention that either.

Well, his app uses the file chooser. What more do you want?  Why would
he have to mention what other apps use file choosers? That you would
expect him to justify his use of a file chooser is bizarre.

> He does mention that "more and more
> applications of my desktop are ( being ) ported to GTK3". I'm again
> wondering which applications. If you're on Gnome or Cinnamon or
> whatever, you get *all* GTK3 apps, not a mix  Doesn't add up to me.

Huh? What are you talking about?  There are loads of apps that people
have written in GTK2 over the years. I'm quite sure you don't know of
many of them because they aren't part of distributions or desktop
environments.  I have one myself that you've never seen.

Any app that's written in GTK2, of which I'm sure there are quite a few
out in the world, many of which are specialized programs, are being
ported to GTK3, or in need of a port to GTK3 as the GTK2 framework is
unmaintained. Hence he's also porting his app to GTK3.  You should
applaud his desire to bring his app to the supported framework.

Instead of saying he's an idiot for wanting to use a file chooser, let
alone a GTK2-style one, maybe you should just ask politely about it,
rather than speak past him with "Anyway, would you like to tease more
information out of Clemens regarding what parts of the file chooser is
driving him crazy?"

Besides that you're recommendation to just use Qt if he doesn't like
GTK3 is certainly valid for new applications, but he's already invested
significant time in his GTK2 app, so the logical way forward is to port
to GTK3.

> However, note that I don't rock up to QT
> mailing lists declaring "Hey there donkeys ... I've tried really hard
> not to use QT because I think the calendar widget looks like arse. How
> about you make it more like GTK3?".

You're way off base there, bordering on trolling yourself.  He has done
none of those things, except to say that the GTK2 file chooser worked
very well for his purposes and he likes its features, which were removed
in GTK3. And wonders if we can get the GTK2 file chooser back. The
reference to Qt is incidental, in that Qt's file chooser is similar to
GTK2's file chooser (actually on my machine it's identical because it
*is* the GTK2 file chooser when using the GTK integration in Qt). Guess
he struck a nerve, which seems to happen from time time when a
programmer asks about a feature that has been removed or significantly
altered in GTK3 and Gnome 3.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Chris Moller-3
There are some major apps like gimp that use gtk2 and I doubt they'll ever switch to gtk3--gtk3 widgets tend to be a lot bigger than gtk2 widgets, making control-intensive dialogues bigger, taking away space from whatever you're trying to do. 

I've written a bunch of apps over the last few years using gtk3, but I'm switching back to gtk2.  The widget-size issue is one reason, but in addition I find CSS to be a ridiculously clumsy mechanism for setting widget characteristics--gtk_widget_modify_bg () was a lot more straight-forward than lots of arm-waving with "style providers" and all the rest of it.

Chris Moller

On 09/15/17 14:50, Michael Torrie wrote:
On 09/14/2017 10:56 PM, Daniel Kasak wrote:
Come on. It's troll bait. 



_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
LRN
Reply | Threaded
Open this post in threaded view
|

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

LRN
In reply to this post by Clemens Eisserer
On 9/15/2017 9:28 PM, Clemens Eisserer wrote:
> I actually sat down and compared GTK2 and GTK3 regarding the file-chooser.
> The one and only thing that really bothers me is GTK3 starting a
> search immediatly when I start typing a file-name, where I only would
> like it to jump to the file/folder that starts with the letters I just
> typed.
> Is there any know to turn that instant-search feature off and return
> to the more traditional "select on type" mode?
>

This was discussed a few months ago (June of this year):

ebassi: LRN: find-as-you-type is gone, and no: it won't come back
ebassi: As long as we have search embedded into the file chooser
ebassi: Having two search methods, with conflicting semantics, and the same
trigger ("start typing") is not going to work
ebassi: Improving the search so that it returns local results first, maybe with
a sort order that favours exact starting matches could be considered
ebassi: Full-Text Search for file contents is also in progress for Nautilus, so
we should do the same on the file selector
LRN: what about
type-to-search-and-find-local-files-first-then-press-*something*-to-go-to-file?
LRN: that would be slightly more complicated than type-to-go-to-file, but it
would be a matter of habit, i guess
mclasen: I should take a few days off and revisit the file chooser... but given
the outcome of my last attempt, I'm dreading it
ebassi: "start typing then press Tab then press Enter"?
ebassi: The file chooser is a small application in and of itself :-/
csoriano: as crazy as it sounds...I pondered that maybe gtkfilechooser and
nautilus should use the same base
csoriano: views, search, cache...
csoriano: they are doing basically the same
LRN: right now this works as "type-to-search", then ctrl+alt+o on the file you
need to open its location
csoriano: LRN: are you fine with the search in nautilus for type-ahead use?
LRN: csoriano, no, but i'm not going to piss against the wind. ALso, it's not
like i'm using Nautilus a lot...
LRN: Or maybe i don't understand the question (what is "type-ahead use",
specifically?)
mclasen: csoriano: the search engine code is more or less copy-paste already, no ?
LRN: As for the Ctrl+Alt+O, it works, but not quite as i want - it opens the
location, but doesn't move the cursor to the file
csoriano: mclasen: kinda
csoriano: mclasen still you miss all the search filter we implemented
LRN: so if the file was, for example, in ~/, which has lots of files, i'm right
where i started
grawity: I don't mind the search much, but if I had to list specific
disadvantages: 1) the first result is often unpredictable � in type-ahead,
pressing 'h' would give you the first item named "H�", while in search you get
whatever random item happens to *contain* 'h', so you can't quickly jump around
with letter + Enter anymore
grawity: in fact the entire result order appears semi-random
ebassi: grawity: That's just a sorting problem
grawity: that's imho why people tend to complain about it � they're used to
rapidly navigating like "m Enter h Down Down Enter o Enter"
ebassi: And, "find as you type" was also a misnomer; it's an Easter Egg on par
to Tab completion
ebassi: It's for navigating, not for finding
ebassi: But, again: it shares the same interaction as the search, so one of
them has to go, unless you want to make a mess
LRN: well, use a different sorting for search results, and maybe also separate
local and non-local results more clearly...and maybe add a shortcut for "go to
file"...that could work...i guess
LRN: i'd have to re-adjust anyway, as i'm accustomed to alt+type
ebassi: I think the search designs did call for separate sections for the results
ebassi: It's just that it's hard to do with a treeview, so we were waiting for
ListBox
ebassi: But ListBox is not fast enough to scale to list `/usr` so we haven't
made the switch
grawity: yeah I suppose if I could choose to have the results sorted by name
(and prefix match first, substring match second)


--
O< ascii ribbon - stop html email! - http://arc.pasp.de/

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list

0x8DADE9276759BA74.asc (3K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Clemens Eisserer
Hi,

Thanks for the pointer :/

> ebassi: LRN: find-as-you-type is gone, and no: it won't come back
> ebassi: As long as we have search embedded into the file chooser
> ebassi: Having two search methods, with conflicting semantics, and the same
> trigger ("start typing") is not going to work

I know I'll risk beeing called a troll again ... very gnome-style
project leaders ;)

Regards
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Emmanuele Bassi
On 15 September 2017 at 21:13, Clemens Eisserer <[hidden email]> wrote:

> Hi,
>
> Thanks for the pointer :/
>
>> ebassi: LRN: find-as-you-type is gone, and no: it won't come back
>> ebassi: As long as we have search embedded into the file chooser
>> ebassi: Having two search methods, with conflicting semantics, and the same
>> trigger ("start typing") is not going to work
>
> I know I'll risk beeing called a troll again ... very gnome-style
> project leaders ;)

Yes, that's a flame statement — one you could have entirely avoided
making, but *you* decided to, so it's entirely on you.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Emmanuele Bassi
In reply to this post by Chris Moller-3
On 15 September 2017 at 20:33, Chris Moller <[hidden email]> wrote:
> There are some major apps like gimp that use gtk2 and I doubt they'll ever
> switch to gtk3

Gimp is in the process of switching to GTK+ 3, now that the work on
changing the internals has reached a nearly complete state.

> gtk3 widgets tend to be a lot bigger than gtk2 widgets,
> making control-intensive dialogues bigger, taking away space from whatever
> you're trying to do.

You still have to option to use more compact themes.

> I've written a bunch of apps over the last few years using gtk3, but I'm
> switching back to gtk2.  The widget-size issue is one reason, but in
> addition I find CSS to be a ridiculously clumsy mechanism for setting widget
> characteristics--gtk_widget_modify_bg () was a lot more straight-forward
> than lots of arm-waving with "style providers" and all the rest of it.

If you think a fully specified language that can modify the appearance
of your UI is "clumsy" compared to a function that changed a color
then I don't know what to say — except that your UI must be so simple
that simply changing colors is enough for you.

Additionally, modify_bg() has never done anything about sizing, and
changing sizes of GTK widgets programmatically has always been a good
way to create terrible UIs that neither scale up nor down.

But, hey: if you feel more comfortable using GTK+ 2 you can still do
that. It's never going to get any new feature, and it's never going to
change in appearance or functionality. If you're targeting platforms
that don't change, GTK+ 2 is precisely what you should use.

Ciao,
 Emmanuele.

> On 09/15/17 14:50, Michael Torrie wrote:
>
> On 09/14/2017 10:56 PM, Daniel Kasak wrote:
>
> Come on. It's troll bait.
>
>
>
>
> _______________________________________________
> gtk-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-list
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Stefan Salewski-2
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Chris Moller-3
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Carsten Mattner
On Sat, Sep 16, 2017 at 1:43 PM, Chris Moller <[hidden email]> wrote:

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

If you fail to bend GTK to your will and Qt also doesn't fit, I think FLTK
is used in the domain you describe. Not sure about Fox but FLTK is
used for applications like that. In case you start looking for alternatives.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Carsten Mattner
In reply to this post by Stefan Salewski-2
On Sat, Sep 16, 2017 at 10:06 AM, Stefan Salewski <[hidden email]> 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

This is a common theme in gtk.git unfortunately and I don't understand
why. Some features are deprecated and released in a broken state
instead of removing them. Take the Raleigh CSS theme in gtk.git for
example. In some 3.x release it stopped working altogether and is now
a ghost of the early 3.x version. It's basically broken because
deprecated although still installed. It's the equivalent of a VLC
plugin that crashes but is still bundled by default.

I've since learned how to modify Adwaita and derive a personal theme,
but if Raleigh had continued to look like the one in Gtk2, I wouldn't
have needed to learn SASS and Gtk3 styling basics, which isn't a
useful skill for me because I don't write Gtk3 applications and only
learned it to fix personal annoyances/gripes of default Gtk3 styles.

Another issue with silent/hidden deprecation is that there are drawing
bugs with Gtk3 that never surface when you use Gtk3 in GNOME3 with the
GNOME3 compositor but fail to properly/smoothly draw under everything
else, including XFCE, Sway and compton. This is a result of
architectural changes to have a better drawing system, but if the
toolkit still supports use outside GNOME3 but doesn't work as smoothly
and this isn't advertised, then it's unfortunately another case of
silent deprecation. I don't mind if Gtk3 is supposed to work properly
only with GNOME3, but that must be documented so that application
writers and users are aware of it. Meanwhile, the less advanced
toolkits just keep on working, albeit with less features. Though, if
you can live with Qt, then you get similar features and arguably more
rendering backends, without compositor bugs mentioned.

I have hope the GNOME devs will fix the bugs, but from conversations
in bugzilla it is evident that there aren't any developers who don't
use Windows or GNOME3 as the development environment.

PS: There are bugzilla tickets for the regressions I describe.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Carsten Mattner
In reply to this post by Carsten Mattner
On Sat, Sep 16, 2017 at 2:27 PM, Carsten Mattner
<[hidden email]> wrote:

> On Sat, Sep 16, 2017 at 1:43 PM, Chris Moller <[hidden email]> wrote:
>
>> 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.
>
> If you fail to bend GTK to your will and Qt also doesn't fit, I think FLTK
> is used in the domain you describe. Not sure about Fox but FLTK is
> used for applications like that. In case you start looking for alternatives.

I've sent you other options to consider, but if anyone at some point considers
the use of more declarative toolkit, I can recommend spending an afternoon
going through the Red (Rebol descendant) examples. It doesn't target
X11 or Wayland yet, and is in its infancy, but it goes to show how a radically
different language can make building graphical applications a much more
productive experience.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

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

Nicolas George-3
In reply to this post by Daniel Kasak-4
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 to the requests of
a certain category of dissatisfied users about ergonomics, the principle
of Libre software leaves only one option:

Fork!

Take the current Gtk+ tree, fix the ergonomics issues, publish it and
lobby applications to use it, or at least to be compatible with it.

If the fork only changes high-level user-facing behaviours, like the
layout and reaction of the file chooser, then it can have the same API,
ABI and SONAME, and installing the alternate version in /usr/local/lib
would be enough to "fix" all applications on the system.

Personally, the feature I dislike the most in Gtk+ 3 is the disabling of
the window manager's decorations on application windows. I, as a user,
chose the window manager that I like and configured it to give windows
decorations with the appearance and behaviour that is most efficient for
me. Any application that deviates from that is an annoyance. Some time
ago I gave a cursory glance at the code to find the few lines in Gtk+
responsible for that, but I was not able to find them and had no time to
experiment more. If somebody could tell me where they are, I think that
today I would install a "fixed" version on my system, and very quickly
publish it on GitHub. If not, I will eventually get to it, probably next
time an application that I use a lot moves to Gtk+ 3 and starts using
that misfeature.

Tweaking the behaviour of the file chooser can work that way too, and if
I were to maintain a shallow fork of Gtk+, I would be happy to accept
it. The same goes for other examples of behaviour fixes.

As a side note, I have an awesome name for a de-GNOMEized version of
Gtk+. If I publish a version without WM decorations disabling and
possibly other fixes, I will use it. If somebody wants to do that before
I have time to get to it, I would be happy to share it.


Now, this is the Gtk+ mailing-list, hosted by the GNOME project. If
people want to discuss the ergonomics of the file chooser in a
constructive and polite way, I think it is the place to do so, but I
have no authority about it.

On the other hand, here is not the place to discuss a possible fork of
Gtk+, and I urge people to not continue this aspect of the discussion
here. On the other hand, if a discussion about it appears somewhere
else, I would appreciate to be personally notified.

Regards,

--
  Nicolas George

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 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 to the requests of
a certain category of dissatisfied users about ergonomics, the principle
of Libre software leaves only one option:

Fork!

Take the current Gtk+ tree, fix the ergonomics issues, publish it and
lobby applications to use it, or at least to be compatible with it.

If the fork only changes high-level user-facing behaviours, like the
layout and reaction of the file chooser, then it can have the same API,
ABI and SONAME, and installing the alternate version in /usr/local/lib
would be enough to "fix" all applications on the system.

Personally, the feature I dislike the most in Gtk+ 3 is the disabling of
the window manager's decorations on application windows. I, as a user,
chose the window manager that I like and configured it to give windows
decorations with the appearance and behaviour that is most efficient for
me. Any application that deviates from that is an annoyance. Some time
ago I gave a cursory glance at the code to find the few lines in Gtk+
responsible for that, but I was not able to find them and had no time to
experiment more. If somebody could tell me where they are, I think that
today I would install a "fixed" version on my system, and very quickly
publish it on GitHub. If not, I will eventually get to it, probably next
time an application that I use a lot moves to Gtk+ 3 and starts using
that misfeature.

Tweaking the behaviour of the file chooser can work that way too, and if
I were to maintain a shallow fork of Gtk+, I would be happy to accept
it. The same goes for other examples of behaviour fixes.

As a side note, I have an awesome name for a de-GNOMEized version of
Gtk+. If I publish a version without WM decorations disabling and
possibly other fixes, I will use it. If somebody wants to do that before
I have time to get to it, I would be happy to share it.


Now, this is the Gtk+ mailing-list, hosted by the GNOME project. If
people want to discuss the ergonomics of the file chooser in a
constructive and polite way, I think it is the place to do so, but I
have no authority about it.

On the other hand, here is not the place to discuss a possible fork of
Gtk+, and I urge people to not continue this aspect of the discussion
here. On the other hand, if a discussion about it appears somewhere
else, I would appreciate to be personally notified.

Regards,

--
  Nicolas George

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list



_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: Past and future evolution of Gtk+

Ian Chapman
In reply to this post by Daniel Kasak-4

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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
12