GNOME Bugzilla – Bug 171940
Add a time machine to GTK+
Last modified: 2018-02-11 00:33:46 UTC
Please describe the problem: Having a time machine in the toolkit would be nice for multiple reasons. We could go back and fix tree models, and redo DND. Also, it would make all bugs trivially reproducable... Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
This will break ABI, but that's probably okay.
And we could finally spell "creat" with an "e".
Also, we could go forward in time, fetch the code for GTK+ 4.0 and we'll have an ultra-modern toolkit in no-time at all!
Note: this bug breaks eclipse.
Please make the API for the time machine publically accessible so that apps (and WMs using gtk+ such as Metacity) can make use of it too.
gtk_back_to_the_future () ?
This is something that should be done with multiple desktop environment's input in the process and is probably more appropriate for fdo rather than gtk. I don't want to have to have both (hypothetical) GTimeMachine and timemaKhine on my systems.
any progress on this, Matthias?
Would be good if this could be looked at for the hackfest...
We gave it a try. Some of us wrote a time machine and were testing it, but they disappeared. We're waiting a few years for them to get back (or is that forward?) to the hackfest.
Okay this bug is NEEDINFO for quite some time now. Can we close this one? -.-
Its only been NEEDINFO for some time if you don't have GtkTimemachine installed. For those of us with it installed, its only been NEEDINFO for about 2 and a half seconds. So, that said, I think it should remain open.
Oh, I actually did have a timemachine back then. I actually even used it to see that it'd be NEEDINFO in the future (that was right now back then)! Apparently, I can see now that it's not NEEDINFO in the (next) future anymore, so I'll just leave it as it is.
Note: Introspection should be supported as well so that it can be bound for Python or JavaScript easily.
What scientific breakthrough has obsoleted the time machine? Is it something to do with string theory?
If we decide to rewrite this before the time travellers with the initial code dump come back, we should consider looking into using faster-than-light neutrinos.
As discussed at the summit, Ryan's new GDateTime stuff is accurate to historical data accumulated in the 1600s. It might take a little bit longer, but we're finally making progress!
I'm pretty sure we get this for free on systemd with the OnCalendar= specifier in unit files.
Ah, but wouldn't it require integrating a web-compliant just-in-time (so to speak) "time compression" engine to add time at the end of the day? Since GtkHTML is essentially dead (even "Evolution" itself has switched to WebKit now...) and Mozilla/Firefox did not want to handle it in Gecko/XULrunner (see https://bugzilla.mozilla.org/show_bug.cgi?id=60455), we might have to integrate WebKit into GTK+. It should be trivial. We just have to be careful about WebKit's JavaScriptCore, from a security standpoint: it could be a vector for some heisenbugs. We don't want to accidentally hack too much time, or we could end up in the goddamned Viking Age. Anyway, integrating the Web should make us all future-proof, at least.
Just realized how badly we need this for GNOME Calendar (bug #775531)... Not sure if systemd's "OnCalendar=" specifier would be useful once we put it "on GNOME Calendar"...
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
I strongly encourage you to file a bug against the Universe product on the Reality bug tracker, about the directionality of the arrow of time. Additionally, you may want to check with the maintainers of the Universe if they can add a configuration toggle for the Novikov self-consistency principle, in case we do end up back in time, otherwise we won't be able to fix any mistake.