GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2024-02-26T15:01:40Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10844Implement Ctrl-n, Ctrl-o and Ctrl-[0-9] shortcuts into the Welcome dialog2024-02-26T15:01:40ZJehanImplement Ctrl-n, Ctrl-o and Ctrl-[0-9] shortcuts into the Welcome dialog**Operating System:** all
### Description of the feature
Some future nice enhancement to the Welcome dialog would be that it could understand (like on canvas):
* Ctrl-o to open an image and close the welcome dialog; canceling the open...**Operating System:** all
### Description of the feature
Some future nice enhancement to the Welcome dialog would be that it could understand (like on canvas):
* Ctrl-o to open an image and close the welcome dialog; canceling the open would get back the welcome dialog (as though we clicked the open button);
* Ctrl-n to create a new image; canceling would also get back the welcome dialog;
* Ctrl-1 to Ctrl-0 would open one of the last 10 images and close the welcome dialog.
### Use cases
These shortcuts are very useful for people using keyboard a lot (like me!). On the other hand, the welcome dialog is also very useful because it's visual. But when the welcome dialog is opened, we can't just ctrl-1 to open the last image for instance. I have to either reach my pointer device or hit Esc first. I'd like to have the best of both world: both the visual aspect of the welcome dialog and the same well known shortcuts as we have on-canvas.
Anyway it's not urgent. Just a reminder report for future work. :-)Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/7976built-in dual-screen mode2024-02-27T10:46:14ZKrakowski Ruchbuilt-in dual-screen mode**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10
### Description of the feature
A built-in two-screen mode would help GIMP stand out among existing software. This way of working helps...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10
### Description of the feature
A built-in two-screen mode would help GIMP stand out among existing software. This way of working helps concentrate on the image, while all the layers and tools remain close at hand the entire time.
In this basic scope it would be fairly easy to implement - tools, layers and other tabs just need to be docked in the same window on the second screen (in the screenshot they're actually two separate windows). This dual-screen option could be available for example in the "Windows" menu in GIMP.
(For the record, the screenshot shows the latest version of GIMP with no add-ons installed. However I had to play with it quite a bit to get this result. The "Save Window Positions Now" feature needs to be fixed - it works fine for the Toolbox window, but Layers show up elsewhere whenever I start GIMP. Besides, ideally all those dialogs would be in the same window, placed right next to the main GIMP window. A "full-screen" button in the right-hand window might be a good idea, too.)
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
### Use cases
Users with two or more monitors.
<!-- If not obvious, explain the use cases or problems to solve. -->
![screen](/uploads/2168e03a647f0e1735fc031e73d1e8e4/screen.jpg)Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/7952Add toolbox ability to ellipsize if it would make the window outgrow the display2022-07-04T10:10:51ZAless4ndro13Add toolbox ability to ellipsize if it would make the window outgrow the display### Environment/Versions
- GIMP version: 2.10.30
- Package: pacman
- Operating System: Manjaro Linux x86_64 5.10.102-1-MANJARO
### Description of the bug
GIMP's window results all streched up beyond screen's resolution. Fullscreen do...### Environment/Versions
- GIMP version: 2.10.30
- Package: pacman
- Operating System: Manjaro Linux x86_64 5.10.102-1-MANJARO
### Description of the bug
GIMP's window results all streched up beyond screen's resolution. Fullscreen doesn't work either and it won't make the window fit. Trying to resize the window is useless, making even more damage since it streches out even further. This bug doesn't bring up any crash, it seems I can click on tools and interact with the program.
_Window when starting application_
![Istantanea_2022-03-08_15-48-50](/uploads/84bfb8adc1cc67f9ef6c76bc361ef5c5/Istantanea_2022-03-08_15-48-50.png)
_window after trying to move or resize_
![2](/uploads/4c39ed26f1a7316036ae005e2a0fed13/2.png)
### Reproduction
I don't know what I did to cause this bug to happen. I never changed sensible settings in the .config folder...
The only change I made was to make the tools bar more like Photoshop, with all the tools in one row only.
Reproduction steps:
Unkown.
Expected result:
A working window with proper resolution.
Actual result:
Broken window, making it impossibile to work with GIMP.
### Additional informationFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/7868When setting impossible physical size (for resolution), change the resolution...2024-02-24T12:27:58ZNameless WandererWhen setting impossible physical size (for resolution), change the resolution, not the requested sizeHello everyone,
When I needed to create a cover for my book, I set the canvas width to 10.4325 inches, but Gimp automatically resizes it to 10.433 inches. I discussed this issue here: https://www.gimp-forum.net/Thread-Gimp-Automatically...Hello everyone,
When I needed to create a cover for my book, I set the canvas width to 10.4325 inches, but Gimp automatically resizes it to 10.433 inches. I discussed this issue here: https://www.gimp-forum.net/Thread-Gimp-Automatically-Resizes
The helpful users of the Gimp forum told me it was likely a matter of presumably arithmetic rounding, the issue seeming to have something to do with Gimp being a raster / bitmap editor. As a non-technical user, I had too much difficulty understanding why I couldn't really just set the canvas size to what I needed it to be, I did infer Gimp has difficulties with so many decimal points in the canvas size.
This in effect disallowed me to use Gimp to create a cover for my Amazon KDP publication. Photoshop did not have this issue, and so it seems to me Gimp is missing out on succeeding in a competitively important facet. I greatly want Gimp to prevail, as I sympathize deeply with the Open Source mentality, and Gimp simply being a wonderful product (I donated :-]).
I can only imagine how difficult it is to program code, especially for a sophisticated project such as Gimp. However, seeing the great skill of its developer community and the complexity already attained, I believe this issue should definitely be able to be resolved, so that covers can be designed with Gimp. In the forum thread mentioned above, some advice was given, but from a non-technical user end point of view, it was simply too difficult to employ Gimp for my purpose. I hope that my request will contribute to the improvement of Gimp.
Kindly,
AviiFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/7749Wheel/Rotation paint dynamics feature is enabled to the tablets without this ...2022-01-22T13:44:40ZAmerico GobboWheel/Rotation paint dynamics feature is enabled to the tablets without this feature### Environment/Versions
- GIMP version: 2.10.28
- Package: Flatpak Linux Fedora 35 GNOME X11
### Description of the bug
When we are using a tablet without the Wheel/Rotation feature Gimp is using improperly this function on the paint ...### Environment/Versions
- GIMP version: 2.10.28
- Package: Flatpak Linux Fedora 35 GNOME X11
### Description of the bug
When we are using a tablet without the Wheel/Rotation feature Gimp is using improperly this function on the paint dynamics matrix.
All outputs of paint dynamics from Opacity to Jitter have an output when the Wheel/Rotation is enabled on the matrix.
Apparently are excluded Size and Aspect ratio.
### Reproduction
Is the bug reproducible? Always
Reproduction steps for one of the outputs, in this case, I exemplify only the Opacity:
0. use a tablet without the feature wheel/rotation ;);
1. create a new paint dynamics;
2. Open the dynamics matrix and enable only wheel/rotation(pressure);
3. Use the parametric brush '2. Hardness 100' and verify if the opacity and black colour K are equal to 100%;
4. Using the default linear curve we don't have output but with y=1 or a curve (0.5, 1) we have an output, a grey.
Expected result: IMO when we don't have the device on the tablet, the option on paint dynamics must be disabled.Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/7654[RFC] Add support for GdkDevicePad2023-07-31T03:27:51ZLuca Bacciluca.bacci@outlook.com[RFC] Add support for GdkDevicePadI propose to add a dedicated dialog for graphic tablet pad devices used to setup button / strip controls. See https://blogs.gnome.org/carlosg/2016/08/24/wayland-%E2%99%A1-drawing-tablets/comment-page-1/ for informations.
Reference docum...I propose to add a dedicated dialog for graphic tablet pad devices used to setup button / strip controls. See https://blogs.gnome.org/carlosg/2016/08/24/wayland-%E2%99%A1-drawing-tablets/comment-page-1/ for informations.
Reference documentation:
* https://developer-old.gnome.org/gdk3/3.24/GdkDevicePad.html
* https://developer-old.gnome.org/gdk3/3.24/gdk3-Event-Structures.html#GdkEventPadButton
* https://developer-old.gnome.org/gdk3/3.24/gdk3-Event-Structures.html#GdkEventPadAxis
* https://docs.gtk.org/gtk3/class.PadController.htmlFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/6747Make easier display all tools in the toolbar (e.g. with a toolbox context menu)2024-02-25T14:20:42ZGo1denMake easier display all tools in the toolbar (e.g. with a toolbox context menu)**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
I would like to be able to see all of the toolbar icons at once, rather than having 20 dropdowns for similar tools...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
I would like to be able to see all of the toolbar icons at once, rather than having 20 dropdowns for similar tools and having to remember which tools belong to which groups.
### Use cases
There's all this empty space in the toolbar anyway, so why not make it easier to see all the available tools?Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/4416Titlebar-less view for Linux2023-08-20T23:36:26ZBjörn DaaseTitlebar-less view for LinuxOperating System: Linux
# Description of the feature
Just as Mozilla did in Firefox, it would be really good to have an option to integrate the title bar into the top bar, in order to save some vertical space (which is even more impor...Operating System: Linux
# Description of the feature
Just as Mozilla did in Firefox, it would be really good to have an option to integrate the title bar into the top bar, in order to save some vertical space (which is even more important if you work on a non-FHD laptop such older Thinkpads).
I would like to especially see it in GNOME (1. because that is what I use and 2. because GIMP is under the GNOME umbrella), but maybe it could be made into a more portable solution that has options for all DEs with top bars (be it Mac, Gnome, Xfce...). Like Mozilla did, it could even start to roll out when just some DEs are supported, with the warning that it may not work on all systems.Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/2516Difficult drag'n drop for dockables [master]2022-01-30T15:27:35ZJehanDifficult drag'n drop for dockables [master]GIMP version: master
Operating System: probably all (Linux for sure)
# Description of the bug
GIMP 2.10 is also not that good on this topic too, but since code changed quite a lot since then, if we could only deal for master, it's ok....GIMP version: master
Operating System: probably all (Linux for sure)
# Description of the bug
GIMP 2.10 is also not that good on this topic too, but since code changed quite a lot since then, if we could only deal for master, it's ok.
The problem: it's hard to drop a dock over another dock. You have to be either on the dock tab area or on some specific part of the GUI (between widgets or whatnot).
It's not a bug per-se, neither a new feature, just an improvement.
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. drag a dockable
2. drop it onto another dockable
Result: the drag start but the drop often fails. It actually depends on where you drop it. For instance dropping on the list of layers of the "Layers" dock fails. But if you drop it on the buttons or dropdown list above the layer list, it works.
Note that dropping on the tabs always works, so this is not the problem. It would be nice to be able to just drop anywhere over another dockable and have the dropped dockable getting attached, whatever widget is below.Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/1274Creating new Dynamics is buried behind multiple clicks2021-10-30T18:50:08ZBugzillaCreating new Dynamics is buried behind multiple clicks## Submitted by Matthew Stein
**[Link to original bug (#792187)](https://bugzilla.gnome.org/show_bug.cgi?id=792187)**
## Description
Dynamics are a really cool feature. Still learning to use them, but I'd used GIMP for image editing...## Submitted by Matthew Stein
**[Link to original bug (#792187)](https://bugzilla.gnome.org/show_bug.cgi?id=792187)**
## Description
Dynamics are a really cool feature. Still learning to use them, but I'd used GIMP for image editing probably a decade without investigating them. I didn't even realize I could create my own until I searched for a tutorial on them finally! What if clicking the editor button on the default map of "Dynamics off" automatically created a new user created Dynamic? Better yet, what if the default Dynamics were editable? We could have it fork the default Dynamic to something like Default (edited). That way the original default Dynamic stays unchanged, but the ability to alter them is much more discoverable.
Build was 2.8.18 but I also downloaded the dev version to confirm it hadn't been changed.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/1157Healing tool automatic sampling2021-05-31T02:04:42ZBugzillaHealing tool automatic sampling## Submitted by josephbupe
**[Link to original bug (#785345)](https://bugzilla.gnome.org/show_bug.cgi?id=785345)**
## Description
Dear developers,
Photoshop has a tool called "Spot Healing Brush" for retouching images. Unlike the H...## Submitted by josephbupe
**[Link to original bug (#785345)](https://bugzilla.gnome.org/show_bug.cgi?id=785345)**
## Description
Dear developers,
Photoshop has a tool called "Spot Healing Brush" for retouching images. Unlike the Healing Brush, the Spot Healing Brush doesn’t require specifying a sample spot; instead, with the single click, the tool automatically samples from around the target spot and simultaneously applies the sampled texture.
It would be nice to implement the same technique in GIMP to simplify the workflow.
Regards.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/1124Aspect ratio in window title2018-05-29T22:06:14ZBugzillaAspect ratio in window title## Submitted by cso..@..mai.hu
**[Link to original bug (#783921)](https://bugzilla.gnome.org/show_bug.cgi?id=783921)**
## Description
It would be nice to see the aspect ratio of the current image in the window title bar. Now I can s...## Submitted by cso..@..mai.hu
**[Link to original bug (#783921)](https://bugzilla.gnome.org/show_bug.cgi?id=783921)**
## Description
It would be nice to see the aspect ratio of the current image in the window title bar. Now I can see the dimensions there like 640x480 but the ratio like 4:3 is not visible.
In order to display this value, there should be a list of frequently used ratio names:
3:2
4:3
16:9
16:10
21:9
...
If the width/height ratio equals one of these values then it should be displayed in the window title bar. Otherwise the pixel numbers should be written.
[tiger] (imported)-3.0 (RGB colour, 1 layer) 640x480 (ratio: 4:3) - GIMP
[tiger] (imported)-3.0 (RGB colour, 1 layer) 640x481 (ratio: 640:481) - GIMP
Unfortunately the fraction simplification is not enough because in some cases people use not the simplest form. For example, 16:10 and 21:9 are used instead of 8:5 and 7:3, respectively. Therefore, the definition of the list is needed.
Note: the https://en.wikipedia.org/wiki/Aspect_ratio_(image) page lists many commonly used aspect ratios.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/1113Scaling canvas size - transforms text layers to image layers2024-03-10T19:52:36ZBugzillaScaling canvas size - transforms text layers to image layers## Submitted by Jo
**[Link to original bug (#783697)](https://bugzilla.gnome.org/show_bug.cgi?id=783697)**
## Description
Scaling canvas size - transforms text layers to image layers
Version: 2.8.22
### See also
* [Bug 750066]...## Submitted by Jo
**[Link to original bug (#783697)](https://bugzilla.gnome.org/show_bug.cgi?id=783697)**
## Description
Scaling canvas size - transforms text layers to image layers
Version: 2.8.22
### See also
* [Bug 750066](https://bugzilla.gnome.org/show_bug.cgi?id=750066)
* [Bug 125144](https://bugzilla.gnome.org/show_bug.cgi?id=125144)Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/1009"Keyboard shortcuts" dialog does not show all actions2024-02-27T00:01:34ZBugzilla"Keyboard shortcuts" dialog does not show all actions## Submitted by Jehan `@Jehan`
**[Link to original bug (#774890)](https://bugzilla.gnome.org/show_bug.cgi?id=774890)**
## Description
So I noticed that the "Keyboard shortcuts" dialog does not list all available actions. This is bec...## Submitted by Jehan `@Jehan`
**[Link to original bug (#774890)](https://bugzilla.gnome.org/show_bug.cgi?id=774890)**
## Description
So I noticed that the "Keyboard shortcuts" dialog does not list all available actions. This is because we only display action groups from the GimpUIManager "`<Image>`". Various groups, like "palettes-*" actions for instance were not available.
I have just fixed this for the action search, which had the same problem. But I wonder if for some weird reason, this was intended for the shortcuts dialog?
If you tell me this was not intended, I will just fix this. It's easy.
P.S.: these actions are still available and shortcuts settable by editing menurc. They are only absent from the GUI.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/937show remaining grid part by arbitrary canvas sizes - outside the canvas2018-05-29T22:09:52ZBugzillashow remaining grid part by arbitrary canvas sizes - outside the canvas## Submitted by Jo
**[Link to original bug (#769032)](https://bugzilla.gnome.org/show_bug.cgi?id=769032)**
## Description
sometimes a grid overlaps not perfectly on canvas, because of arbitrary measures, therefore a part of the grid...## Submitted by Jo
**[Link to original bug (#769032)](https://bugzilla.gnome.org/show_bug.cgi?id=769032)**
## Description
sometimes a grid overlaps not perfectly on canvas, because of arbitrary measures, therefore a part of the grid is cut on the x or y or both axes.
I would suggest to visualize the remaining grid parts outside the canvas.
Or we get a grid size in percent, in that case this report would become obsolete to some degree.
Version: 2.8.16
### See also
* [Bug 773280](https://bugzilla.gnome.org/show_bug.cgi?id=773280)Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/850MyPaint brush popup out of screen2024-02-27T10:35:45ZBugzillaMyPaint brush popup out of screen## Submitted by Jehan `@Jehan`
**[Link to original bug (#761998)](https://bugzilla.gnome.org/show_bug.cgi?id=761998)**
## Description
The popup of the MyPaint brush is too big and the top is out of the screen, preventing one from ge...## Submitted by Jehan `@Jehan`
**[Link to original bug (#761998)](https://bugzilla.gnome.org/show_bug.cgi?id=761998)**
## Description
The popup of the MyPaint brush is too big and the top is out of the screen, preventing one from getting top brushes.
See screenshot.
We should make sure the popup is constrained inside the current screen, in particular since we anyway have a scrollbar.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/816Make the drop targets more discoverable2024-02-27T11:22:58ZBugzillaMake the drop targets more discoverable## Submitted by Jehan `@Jehan`
**[Link to original bug (#759814)](https://bugzilla.gnome.org/show_bug.cgi?id=759814)**
## Description
When dragging an image into GIMP, we have several drop targets, and 2 in particular:
- the canvas...## Submitted by Jehan `@Jehan`
**[Link to original bug (#759814)](https://bugzilla.gnome.org/show_bug.cgi?id=759814)**
## Description
When dragging an image into GIMP, we have several drop targets, and 2 in particular:
- the canvas: opens a new image if none are opened, otherwise as a layer in the currently focused image;
- the toolbox: always opens as a new image.
The canvas target is quite discoverable because it is big, the "center" of the GIMP UI, hence a logical try. But I find the drop in the toolbox in particular to be quite hidden. I always have questions of how to open new images by dnd reliably.
Isn't it possible to highlight the main drop targets when a drag is in progress, with big overlay texts "Open New Images" over the toolbox and "Open as Layers" over the canvas?
Version: git master
### See also
* [Bug 760763](https://bugzilla.gnome.org/show_bug.cgi?id=760763)Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/643Splash screen should use the splash image's alpha channel as window shape2022-02-20T22:22:10ZBugzillaSplash screen should use the splash image's alpha channel as window shape## Submitted by Jo
**[Link to original bug (#742904)](https://bugzilla.gnome.org/show_bug.cgi?id=742904)**
## Description
i like to create from time to time my own, custom splash screens with a small snapshot of my milestones and sa...## Submitted by Jo
**[Link to original bug (#742904)](https://bugzilla.gnome.org/show_bug.cgi?id=742904)**
## Description
i like to create from time to time my own, custom splash screens with a small snapshot of my milestones and saw that the splash screen accepts no alpha, although the splash screen image ends with the extension *.png, effectively i saved my image as an png, who should support alpha.
Version: 2.8.14Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/405Filters not working on layer groups2024-02-27T20:14:21ZBugzillaFilters not working on layer groups## Submitted by GrafxUser
**[Link to original bug (#676768)](https://bugzilla.gnome.org/show_bug.cgi?id=676768)**
## Description
How to reproduce:
1. group some non-empty layers in a layer group
2. select the layer group
3. goto to ...## Submitted by GrafxUser
**[Link to original bug (#676768)](https://bugzilla.gnome.org/show_bug.cgi?id=676768)**
## Description
How to reproduce:
1. group some non-empty layers in a layer group
2. select the layer group
3. goto to 'Filters' menu and select one filter
This should happen:
If filters are able to work on layer groups, they should behave like on a single layer: open the filters dialog, after user confirmation apply the filter.
If filters are not able to work on layer groups, disable these particular menu items until they work.
This happens:
The filter dialog appears, the preview works on the composed layer group, but after user confirmation the following error message is shown: 'Calling error for procedure '`<the filter procedure>`' Item 'Layer Group' (3) cannot be modified because it is a group item'.
In case of the 'Distorts/Curve Bend' filter: GIMP shows the messages:
'Plug-In "curve-bend.exe"
(C:\Program Files\GIMP 2\lib\gimp\2.0\plug-ins\curve-bend.exe). tried writing to a group layer 3 (killing).Plug-In 'Curve Bend' left image undo in inconsistent state, closing open undo groups.' -> the filter leaves a temporary layer group in the image, which is of no use.
It's confusing to the user to see that the filters work in a preview, but refuse working after confirmation.
It happens always.
It's similar with Tools/GEGL ops: The enabled menu item makes the user believe this would work. Clicking on the item doesn't show up the GEGL dialog or anything else -> disable this menu item as long as it doesn't work.
Version: 2.8.0Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/380Switching to and from single window mode messes up toolbox2019-07-14T00:21:35ZBugzillaSwitching to and from single window mode messes up toolbox## Submitted by max..@..il.com
**[Link to original bug (#661422)](https://bugzilla.gnome.org/show_bug.cgi?id=661422)**
## Description
Created attachment 198746
Window ordering to reproduce the bug
Switching to and from single windo...## Submitted by max..@..il.com
**[Link to original bug (#661422)](https://bugzilla.gnome.org/show_bug.cgi?id=661422)**
## Description
Created attachment 198746
Window ordering to reproduce the bug
Switching to and from single window mode messes up toolbox as it gets merged with the detached dialogues window.
How to reproduce:
1. create a layout like this, from the left: main window -- toolbox -- detached dialogues window
2. switch to single window mode, you end up with a window with the 'you can drop dockable dialogues here' area on the left, then the image area and merged contents of your other windows on the right (with the toolbox on the right)
3. switching back to multi-window mode doesn't restore the previous setup
Expected result:
1. most importantly, the toolbox and the other detached dialogues are not merged together (either after step 2 or 3)
2. in single-window mode the toolbox appears on the left with the detached dialogues on the right
Additional info:
It works just fine if the windows are ordered like this before switching to the single-window mode: toolbox -- main window -- detached dialogues window
**Attachment 198746**, "Window ordering to reproduce the bug":
![setup-to-reproduce-the-bug](/uploads/7d410d578600f484aff23ff57088f412/setup-to-reproduce-the-bug.png)
Version: 2.7.3Future