GTK+ No More - It's Just GTK As Developers Prepare For This Year's GTK 4.0

[pal666]

In reality, GIMP was the first application so they paid it homage that should long since be dismissed.

in reality gimp was the application from which gtk was ripped out to be used by other apps

[pal666]

So can autoconnect signal handlers to class methods in c++ or is gtk just useless?

c++ bindings are called gtkmm, you shouldn't use plain gtk in c++ project

[DMJC]

c++ bindings are called gtkmm, you shouldn't use plain gtk in c++ project

Of course you'd use gtkmm to write c++ code. But the original question remains. Have they got auto-connecting signal handlers in C++/GTKMM. Or is Glade + GTKMM still a giant waste of time?

[FastCode]

I've never seen this before. Are you using and old theme or some custom CSS?

using latest gnome, it's consistently broken on windows, ubuntu, arch, debian since 2010. no css, no extensions, no modifications, not even an environment variable.

This simply doesn't happen. Unless you're calling gtk_tree_view_scroll_to_cell(), the only thing that can affect the horizontal scroll position is user interaction.

I am not, and I can prove it.

CSS

CSS for a CellRenderer that's not rendering?

Nice

Thanks

Any large software project has issues. Even some small projects like ... um ... can I think of one ... oh yeah ... yours Pretending your own issues are gtk's fault is pretty lame. I lurk in various gtk mailing lists and I've never seen you ask questions about any of these 'issues'. Maybe drop the attitude and reach out for help and you'll get some things solved?

sloccount reports only 3500ksloc. I'm sorry I only have 2 hands(both have carpal tunnel) and can't write a larger codebase to grab your attention with.
And I've asked on IRC before, maybe around version3.6 time which puts it around 2012?. You GNOME people are all holier than thou.



Videos available at http://bd2.ir/gtk/
I very much like to see you dispute this. then I'll livestream it.

[dkasak]

Videos available at http://bd2.ir/gtk/

<yawn>

Yeah so you have code bugs I guess It works for me:

http://tesla.duckdns.org/downloads/2019-02-15_01-00-21.flv

No problems with rows getting automatically selected or whatever. No problems with some mystery fat column at the end.

You GNOME people are all holier than thou.

Oh boo hoo! I'm just a dev using gtk. I use the Enlightenment desktop. As I mentioned before, if you went to the mailing list and described your problem, but left out the symptoms of personality disorders, maybe someone could help you.

[FastCode]

at 00:15, you see how it expands, well, for me it expands and the scroll follows it. I have no events, and only add columns, I'm sure there is no magic in my code either but here we are...
btw, that's a nice program, Is it available for download/purchase?

[justmy2cents]

AFAIK GtkTreeView and the entire GtkCellRenderer system has been negatively viewed for quite a while. However, rendering widgets in GTK3 was exponential (?) time (or maybe something else, I just know it was far above linear), meaning cell renderers were the only way to efficiently render the amount of widgets that would be in a GtkTreeView.

With GTK4, not only has the entire rendering system changed (everything has moved from Cairo painting to the GtkSnapshot hardware-accelerated scene graph), but drawing widget children is now O(n), meaning cell renderers have no place and can be removed .

that is not even remotely true. you had control over efficient drawing if you knew how. problem of gtk4 is that it removes the most of it. gtk4 is a steaming pile of shit in every aspect for a developer who was capable in internals before. in fact it is easy to see where performance will be worse than it was.

cairo drawing was the least of the performance problem and they didn't address the elephant in the room even the least. major problem in performance is terrible css implementation which only gets worse with every layer you encounter. second drawback is measuring. unless you think that you solve billions worth of debt by buying cheaper pencils

the claim about exponential drawing time comes from people who don't know what they talk about. it just means that they never used past 10% of what they should when designing widgets.

not to mention that every widget is now container is implemented in the worst way possible. it just doesn't get any worse

look at the design of snapshot and new containers and you can already see flaws of it.

gtk4 beside no real improvement is also one steaming pile of unnecessary api breaks.

as developer using gtk, i would go so far and say that they should really rename gtk4 to gnome toolkit.

[re:fi.64]

that is not even remotely true. you had control over efficient drawing if you knew how. problem of gtk4 is that it removes the most of it. gtk4 is a steaming pile of shit in every aspect for a developer who was capable in internals before. in fact it is easy to see where performance will be worse than it was.

cairo drawing was the least of the performance problem and they didn't address the elephant in the room even the least. major problem in performance is terrible css implementation which only gets worse with every layer you encounter. second drawback is measuring. unless you think that you solve billions worth of debt by buying cheaper pencils

the claim about exponential drawing time comes from people who don't know what they talk about. it just means that they never used past 10% of what they should when designing widgets.

not to mention that every widget is now container is implemented in the worst way possible. it just doesn't get any worse

look at the design of snapshot and new containers and you can already see flaws of it.

gtk4 beside no real improvement is also one steaming pile of unnecessary api breaks.

as developer using gtk, i would go so far and say that they should really rename gtk4 to gnome toolkit.

- No, drawing was exponential, as was pointed out by several GTK developers on IRC several times. I'd like to see your source, rather.
- GTK4 brings a scene graph (bye, Clutter) and hardware-accelerated rendering, making room for things such as blur and smoother animations.
- What's wrong with snapshots? Having immutable drawing primitives is something other graphics libraries have done successfully.
- Cairo was still pretty slow, which is why Firefox had switched to Skia before doing WebRender.

[justmy2cents]

- No, drawing was exponential, as was pointed out by several GTK developers on IRC several times. I'd like to see your source, rather.
- GTK4 brings a scene graph (bye, Clutter) and hardware-accelerated rendering, making room for things such as blur and smoother animations.
- What's wrong with snapshots? Having immutable drawing primitives is something other graphics libraries have done successfully.
- Cairo was still pretty slow, which is why Firefox had switched to Skia before doing WebRender.

here is just one funny catch about gtk developers. i asked quite a few questions and never really got any response worth much. i always realized that when i went deep in the code for myself.

clutter? clutter was atrocity from day 1 made by one person who never could fit anything into proper solution. gtk provides everything already to have much better scenegraph without the need for 99% of the clutter crap.

here is a catch with hw accelerated rendering. you can't make one that will work for all and the new one wouldn't step on the toes of the developer who really wants to optimize the specific draw parts. it can be done, but it needs reinvention of pretty much everything. and the way snapshots are done is just bad. and the snapshot design is pretty much listbox bad and that tells a lot. listbox is one of the worst widgets in history of all toolkits because writter had no clue what he was doing

here is result of my tests.really heavy gtk layout took 17% of cpu. after rewriting the css paths (which is atrocity), introduced proper locking, rewrote pretty much all widgets listbox, box, and every widget used there usage dropped to 1.7%. and if i disabled css usage was 0.9%. basically, they are breaking the api for improvement in 0.9% and not touching the 16.1%. here is your elephant in the room. this is what i meant previously with "you don't solve debt of billion by buying cheaper pencils". and when you consider that nonsensical solution also breaks all the api for pretty much no reason... yes, gtk4 is catastrophe. if you thought 3 broke a lot... go figure, 4 breaks insanely more. here is just one of those insane decisions... they went and renamed GdkWindow to GtkSurface, just that pretty much breaks almost every custom widget in existence.

the new concept "every widget is a container" is clear case of how things should not be done. you don't stuck developers with half closed and badly implemented half feature. and if you want to know how bad it is, feel free to run gnome logs and keep scrolling in order to spawn new items which watching memory and cpu. at 3000 items, just trying to scroll impacts performance. but, that was the case of poor listbox implementation. well, go figure. exact same bad design is now part of the every widget

take css for example. it is so bad it can't be described. the fact that piece of code reached mainline says paid maintainership really doesn't work. why it is bad? saying not optimized is not correct, the way it is developed is like strapping few tons of metal behind f1. but, that is not even the worst part. it is memory hog... yes, but that again is not the worst part. what is terrible is the fact that it is exposed so badly i never had a chance of seeing worse product from children who were learning. you try figuring how something is done? well, pretty much everything is private and as such public toolkit exposes almost nothing.

just the fact you compare firefox and gtk tells you're not speaking from experience. the two are incomparably different and cairo does quite a few things that are not needed by browser. so, if they removed those they got much more suitable render. off course.

as far as your wish to see it. yes, you most definitely will in quite a short time. i am nearing the end of my proof of concept why gtk4 sucks and should've never been. problem is that in order to show things in complete picture this is not work of few days, but rather work of one year or so and i have to be finished before gtk4 is out or all was in vain.

here is the catch about most developers
- they don't want to rewrite their software every 2 years
- there is no change good enough to warrant more than small api breaks. if you think differently you probably shouldn't work on public api as you're not cutting it

i developed with gtk all the way from before 1. 4 is the time when i split

the reason why i am doing that is quite simple. it needs to be done or any developer like me will be hurt badly. gtk4 breaks everything for all the wrong reasons. gtk3 will have limited maintenance by the wrong people. the biggest problem being that even if they wanted to continue with 3... they can't. gnome taking over gtk was pretty much one of the worst things that happened to the project.

making room for things such as blur and smoother animations.

you obviously never looked at source if you claim that. smoother animations? reason why animations are not smooth is simple. all the animations are not really using gtk. instead they are hacked around it. i could point you to exact lines of code where that happens and it happens A LOT. my poc is exactly that showing how widgets can have butter smooth animations without impacting performance at all. you either animate in sync with screen or you failed. but, for that you don't need to reinvent anything. gtk already has it in 3. the biggest problem here being complete lack of proper locking method which not only impacts performance, it also makes it almost impossible for custom widgets to inject something into proper pipeline.

blur and effects are easy to implement without the need to break api. off course, if first decision from developer is to reinvent everything and not look up the source of the problem you get nonsensical claims. one simple solution would be layered cairo surface. it would be backwards compatible and at the same time everyone would benefit from new feature. i can name at least 10 ways of achieving that without breaking api.

[drankinatty]

From an app development standpoint gtk app development went off the rails when the orderly and easily themed Gtk+2.0 with it simple gtkrc config was inexplicably cast off like a pair of worn-out shoes, in favor of what would be the next great Gtk+3.0 toolkit to make things easier on developers. Such was not the case. The tens or hundreds of hours invested to get an application looking just write under the new tools promptly broke when the next Gtk+3 minor release bump landed. Toolbar spacing and icon-sizes were thrown to the wind leaving toolbars that easily held 29 icons with Gtk+2 with no additional effort now only contain 16 icons with another 13 crammed into an overflow off the right side to the toolbar -- completely unusable. And the answer from the gnome-devel list was to "find another theme", only to have that theme break totally with the next Gtk3 minor version release. The countless hours wasted, the collection of so called "recommended themes" done for minor version -1 are no longer compatible after the latest minor version bump, and it got worse with every minor version bump. A majority of the available theses on `gnome look` are so broken and out of date being build got 2 or 3 minor versions ago. Nothing works. It is a complete moving target. Where we had 1000s of quality Gtk+2 themes that worked really well with all applications, the css styleized Gtk+3 breakages me we have virtually no theses that work for all apps, and if someone spent the enormous amount of time to fix the breakages from version-last, they are guaranteed to have to do it all over again on the next minor version bump. This has gone on for a decade. It is time for it to stop. Within a year of gnome2, there were 1000s of quality theme created and all worked well. There is a silent durth of any themes that even looks good and doesn't have icons spilling into overflow menues. Either Get a final theme API set in stone or go back to a gtkrc model -- where at least there are 1000s of readily available themes and then provide the fine-grain control of box and widget positioning and themeing that gtk2+ provided.