starred/ScreenToGif
1
0
Fork 0
mirror of https://github.com/NickeManarin/ScreenToGif.git synced 2026-04-25 23:25:52 +03:00
Code Issues 1.1k Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #838] [Feature Request] Retain output and filename among presets #659

New issue
Closed
opened 2026-02-26 09:32:13 +03:00 by kerem · 10 comments
kerem commented 2026-02-26 09:32:13 +03:00
Owner
Copy link

Originally created by @tony on GitHub (Apr 21, 2021).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/838

Originally assigned to: @NickeManarin on GitHub.

Hi! Thank you again for the application @NickeManarin! This is a tiny one, but wanted to document it for posterity in case anyone else would like it.

(Not sure if this is my own personal habit or the expectation of the common user!)

My intuition expects to "Save as" with the same file name and destination folder in different file types/presets.

In 2.27 and at least 2.28.1, switching the dialog resets / uses the file name for that file type/preset rather than keeping the filename consistent.

I feel surprised when file name changes simply from switching the output types.

For instance:

image

Switching the "file type" wouldn't reset the filename or the destination folder.

Current behavior

Step 1

image

Step 2: Switch filetype / preset

image

current behavior

Below: I would expect the "File" to be the same with the exception of the .mp4 file extension

image

desired behavior

image

Originally created by @tony on GitHub (Apr 21, 2021). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/838 Originally assigned to: @NickeManarin on GitHub. Hi! Thank you again for the application @NickeManarin! This is a tiny one, but wanted to document it for posterity in case anyone else would like it. (Not sure if this is my own personal habit or the expectation of the common user!) My intuition expects to "Save as" with the same file name and destination folder in different file types/presets. In 2.27 and at least 2.28.1, switching the dialog resets / uses the file name for that file type/preset rather than keeping the filename consistent. I feel surprised when file name changes simply from switching the output types. For instance: ![image](https://user-images.githubusercontent.com/26336/115610726-df579400-a2ae-11eb-81b9-c151549185e6.png) Switching the "file type" wouldn't reset the filename or the destination folder. ## Current behavior ### Step 1 ![image](https://user-images.githubusercontent.com/26336/115610066-f9dd3d80-a2ad-11eb-9f1f-a4ed0f48a480.png) ### Step 2: Switch filetype / preset ![image](https://user-images.githubusercontent.com/26336/115611154-5bea7280-a2af-11eb-934f-245d190dba08.png) #### current behavior Below: I would expect the "File" to be the same with the exception of the `.mp4` file extension ![image](https://user-images.githubusercontent.com/26336/115610178-2002dd80-a2ae-11eb-9cf1-ec2fde2884ee.png) #### desired behavior ![image](https://user-images.githubusercontent.com/26336/115610324-52143f80-a2ae-11eb-930f-e43ead71dadb.png)
kerem 2026-02-26 09:32:13 +03:00
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@NickeManarin commented on GitHub (Apr 22, 2021):

The file name and folder are stored in each preset, I could create an option to persist the filename to all presets.

<!-- gh-comment-id:824441280 --> @NickeManarin commented on GitHub (Apr 22, 2021): The file name and folder are stored in each preset, I could create an option to persist the filename to all presets.
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@tony commented on GitHub (Apr 22, 2021):

@NickeManarin I think that would make sense

The file name and the file destination/folder, right? (Hopefully!)

We can leave this issue open to see if anyone agrees / disagrees, as well. So far I think I'm the only one who mentioned it.

<!-- gh-comment-id:824470141 --> @tony commented on GitHub (Apr 22, 2021): @NickeManarin I think that would make sense The file name and the file destination/folder, right? (Hopefully!) We can leave this issue open to see if anyone agrees / disagrees, as well. So far I think I'm the only one who mentioned it.
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@byzod commented on GitHub (Apr 26, 2021):

This is bothering me too

I need a "Set Working Directory" option

btw what I need is remember filename/path for each type of saving mode (gif/webp/etc), but all preset of one mode share the same filename/path

<!-- gh-comment-id:826699662 --> @byzod commented on GitHub (Apr 26, 2021): This is bothering me too I need a "Set Working Directory" option btw what I need is remember filename/path for each type of saving mode (gif/webp/etc), but all preset of one mode share the same filename/path
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@NickeManarin commented on GitHub (Jun 25, 2021):

Idea:

Create two/three options (Options > Application) to persist output path and filename to all presets.

  • Persist the output path to other presets.
    • Persist the filename to other presets.
    • Persist only to presets of the same file type.

When the output path or filename of a preset changes, the other presets will receive the same data.

(Not sure if 'persist' is the right word for that)

<!-- gh-comment-id:868152507 --> @NickeManarin commented on GitHub (Jun 25, 2021): Idea: Create two/three options (Options > Application) to persist output path and filename to all presets. - [ ] Persist the output path to other presets. - [ ] Persist the filename to other presets. - [x] Persist only to presets of the same file type. When the output path or filename of a preset changes, the other presets will receive the same data. (Not sure if 'persist' is the right word for that)
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@byzod commented on GitHub (Jun 25, 2021):

Idea fragments I can think of

  • Automatically optional suffix like filename_gifski_present1.gif
  • Add a default working directory, all modes use its own path but add an option use default directory
  • Same working directory, all modes use subfolders by default but can be changed by user. For example all gifs in wd/gifs and apng in wd/apng. User can change it to whatever/apng2 and stg will remember it until user click reset to default folder button
<!-- gh-comment-id:868157711 --> @byzod commented on GitHub (Jun 25, 2021): Idea fragments I can think of * Automatically optional suffix like `filename_gifski_present1.gif` * Add a default working directory, all modes use its own path but add an option `use default directory` * Same working directory, all modes use subfolders by default but can be changed by user. For example all gifs in `wd/gifs` and apng in `wd/apng`. User can change it to `whatever/apng2` and stg will remember it until user click `reset to default folder` button
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@NickeManarin commented on GitHub (Jun 26, 2021):

The second idea can be implemented in another time, but by opening another issue ticket.

The first and third ideas I didn't properly understand.
Looks like it wouldn't be easy to present that functionality for the user.
(Think that this app needs to easy to understand as possible)

<!-- gh-comment-id:869062521 --> @NickeManarin commented on GitHub (Jun 26, 2021): The second idea can be implemented in another time, but by opening another issue ticket. The first and third ideas I didn't properly understand. Looks like it wouldn't be easy to present that functionality for the user. (Think that this app needs to easy to understand as possible)
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@tony commented on GitHub (Jun 26, 2021):

Thank you for looking into this @NickeManarin !

(Purely a UX bikeshed) Another angle of why the current output/filename handling is odd for me:

Since it's the same recording project, why would filenames and outputs be different between presets?

Right now - if we save with an output/filename in a project, switching presets may give the previous project's filename, which I think can be confusing to users.

People pick filenames based on the project, usually, I assume.

<!-- gh-comment-id:869065882 --> @tony commented on GitHub (Jun 26, 2021): Thank you for looking into this @NickeManarin ! (Purely a UX bikeshed) Another angle of why the current output/filename handling is odd for me: Since it's the same recording project, why would filenames and outputs be different between presets? Right now - if we save with an output/filename in a project, switching presets may give the previous project's filename, which I think can be confusing to users. People pick filenames based on the project, usually, I assume.
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@NickeManarin commented on GitHub (Jul 3, 2021):

I added some options to control this behavior.

image

<!-- gh-comment-id:873480520 --> @NickeManarin commented on GitHub (Jul 3, 2021): I added some options to control this behavior. ![image](https://user-images.githubusercontent.com/14798947/124368438-7b9b0100-dc37-11eb-88b2-6591458a4917.png)
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@NickeManarin commented on GitHub (Jul 3, 2021):

@tony Ahh, yes. The behavior that you are referring to is something that want to implement.
I'm reworking the editor from scratch, changing the UX (one of the things that I want to change is that).

The editor will work on top of projects, so to edit something, the app will create a project based on the type of file, locations, etc.

<!-- gh-comment-id:873480772 --> @NickeManarin commented on GitHub (Jul 3, 2021): @tony Ahh, yes. The behavior that you are referring to is something that want to implement. I'm reworking the editor from scratch, changing the UX (one of the things that I want to change is that). The editor will work on top of projects, so to edit something, the app will create a project based on the type of file, locations, etc.
kerem commented 2026-02-26 09:32:13 +03:00
Author
Owner
Copy link

@tony commented on GitHub (Jul 4, 2021):

@NickeManarin I'm excited to try these new settings out!

@tony Ahh, yes. The behavior that you are referring to is something that want to implement.
I'm reworking the editor from scratch, changing the UX (one of the things that I want to change is that).

Look forward to seeing this! The UX you have already is excellent! Wondering what the rework will look like.

<!-- gh-comment-id:873502185 --> @tony commented on GitHub (Jul 4, 2021): @NickeManarin I'm excited to try these new settings out! > @tony Ahh, yes. The behavior that you are referring to is something that want to implement. > I'm reworking the editor from scratch, changing the UX (one of the things that I want to change is that). Look forward to seeing this! The UX you have already is excellent! Wondering what the rework will look like.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dev
v2.40
2.43.1
2.43
2.42.1
2.42
2.41.5
2.41.4
2.41.3
2.41.2
2.41.1
2.41
2.40.1
2.40
2.39
2.38.1
2.38
2.37.2
2.37.1
2.37
2.36
2.35.4
2.35.3
2.35.2
2.35.1
2.35
2.34.1
2.34
2.33.1
2.33
2.32.1
2.32
2.31
2.30.1
2.30
2.29.1
2.29
2.28.2
2.28.1
2.28
2.27.3
2.27.2
2.27.1
2.27
2.26.1
2.26
2.25
2.24.2
2.24.1
2.24
2.23.2
2.23.1
2.23
2.22.1
2.22
2.21.2
2.21.1
2.21
2.20.4
2.20.3
2.20.2
2.20.1
2.20
2.19.3
2.19.2
2.19.1
2.19
2.18
2.17.1
2.17
2.16
2.15.2
2.15.1
2.15
2.14.1
2.14
2.13.3
2.13.2
2.13.1
2.13
2.12.1
2.12
2.11
2.10
2.9
2.8.1
2.8
2.7.3
2.7.2
2.7.1
2.7
2.6
2.5
2.4
2.3.2
2.3.1
2.3
2.2
2.1
Labels
Clear labels   
copy cats

   
duplicated

   
future feature

   
pull-request

Mirrored from GitHub Pull Request

  
⬜ Accepted

   
⬜ Completed

   
⬜ Help Wanted 💪

   
⬜ In Progress

   
⬜ Missing Details

   
⬜ Pending

   
⬜ Waiting For Answer ⏳

   
🆕 feature preview

   
🔷 Bug 🐛

   
🔷 Out Of Scope

   
🔷 Out Of Scope

   
🔷 Question

   
🔷Enhancement

   
🔷Enhancement

   
🔷Invalid / External

   
🔷Knowledge Base

   
🔷Won't Fix

   
🕑 High

   
🕑 High

   
🕑 High

   
🕕 Medium

   
🕙 Low

   
🕛 Critical
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ScreenToGif#659
No description provided.