Greasemonkey: 백업/복원 추가

글쎄, Firefox와 그 문제. 그래서 저는 이것을 구현하고 있었습니다(물론 '가져오기' 기능도 포함). 거의 다 끝났지만, 쇼 스토퍼가 있습니다. browser toolbox 를 열고 "팝업 자동 닫기 안 함"을 선택한 경우에만 작동합니다. 가져오기는 <input type="file"> (유일한 방법)를 통해 수행되지만 찾아보기 창에 포커스가 있으면 일반적으로 팝업이 닫히므로 창이 파괴되고 기능이 실행되지 않습니다. 관련 버그:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

일할 수 있는 환경이 너무 불편합니다.

또한 #2612에 적용됩니다. 동시에 해결할 수 있는 것이 이 문제입니다.

@Sxderp 팝업 닫기가

할 수 있어요. 그것은 많은 코드를 옮기는 것을 포함합니다. 나는 그것을 다른 시간에 조사할 것이다.

가져오기/내보내기 작업을 완료했습니다. 테스트가 없고 오류 처리가 거의 없습니다. 하지만 작동합니다. 그러나 단순화를 위해 가져오기가 전체 데이터베이스를 덮어쓰도록 만들었습니다. 물론 확인 프롬프트와 함께.

이상적으로는 사용자가 가져오기를 교체하거나 병합하도록 선택할 수 있다고 생각합니다. 스타일러스는 병합만 하며 이는 IME도 좋지 않습니다. 작동할 수 있는 기본값과 함께 사용자 선택이 가장 좋은 것 같습니다.

물론, 하지만 우리는 많은 조건문에 부딪힙니다. 병합의 _정확한_ 특성에 대한 일종의 흐름도를 보고 싶습니다.

대부분 갈등의 측면에서. 콘텐츠 덮어쓰기, 키/값 덮어쓰기(예, 내보내기도 함), 모든 항목에 대한 프롬프트(나쁜 사용자 경험처럼 보임) 등?

내 말은: 파일의 모든 스크립트를 가져오고(해당 상태로 완전히 덮어씁니다), 파일에 없는 스크립트는 건드리거나 삭제하지 마십시오.

오. 훨씬 간단합니다. 예, 좋은 것 같습니다.

그래서 세 가지 다른 가져오기 방법을 구현했습니다.

1. 병합 설치된 스크립트를 만지지 마십시오. 현재 존재하지 않는 스크립트[1]만 데이터베이스에 추가됩니다.
2. 바꾸다. 현재 스크립트를 모두 제거하고 가져온 스크립트로 교체하십시오.
3. 덮어쓰기 병합과 비슷하지만 충돌이 발견되면[1] 가져오는 스크립트가 우선합니다.

제출하기 전에 다른 PR을 기다리고 있습니다.

[1] 스크립트의 id 고유성을 결정합니다.

이것은 어떻습니까?

1. 업데이트. 이미 존재하는 스크립트만 가져오기(덮어쓰기)합니다.

이것은 1을 보완합니다. 병합

1. 덮어쓰기 병합과 비슷하지만 충돌이 발견되면[1] 가져오는 스크립트가 우선합니다.

@Sxderp "Like merge"에는 "현재 존재하지 않는 스크립트만" 제약 조건이 포함되어 있지 않습니다...
(이 제약 조건은 여기에서 의미가 없습니다.) 즉, 덮어쓰기 = 모든 스크립트 가져오기, 충돌하는 스크립트는 아카이브로 덮어씁니다...

다음 중 VM, TM 또는 기타에서 제공하는(업데이트/병합/등) 옵션은 무엇입니까?

1. 업데이트. 이미 존재하는 스크립트만 가져오기(덮어쓰기)합니다.

물론 가능해야 합니다.

즉, 덮어쓰기 = 모든 스크립트 가져오기, 충돌하는 스크립트는 아카이브로 덮어씁니다...

옳은.

다음 중 VM, TM 또는 기타에서 제공하는(업데이트/병합/등) 옵션은 무엇입니까?

확실하지 않습니다. 그러나 이것은 나의 또 다른 걱정거리를 불러일으켰다. 아카이브와의 호환성. 이러한 애드온이 전체 데이터베이스 내보내기(스크립트 + 데이터)를 지원한다고 가정하면 이상적으로 가져오기는 서로 호환되어야 합니다.

업데이트. 이미 존재하는 스크립트만 가져오기(덮어쓰기)합니다.

지금 생각해보면(약 3분 정도) 걱정거리가 있습니다. 관련 데이터(get/setValue)는 어떻습니까? 현재 저장된 데이터를 유지해야 합니까? 가져온 데이터가 우선해야 합니까? 일종의 병합? 그런 다음 이 옵션/상태를 사용자에게 명확하게 나타냅니다. 이것은 실제로 처음 보는 것보다 조금 더 까다롭습니다.

몇 가지 빠른 확인을 수행했지만 이것은 100% 철저하지는 않지만 일반적인 개요와 구현과 관련하여 변경해야 할 사항을 제공합니다.

VM과 TM은 모두 zip 파일로 내보냅니다. zip 파일 내에서 각 스크립트에 대한 .user.js 파일을 찾을 수 있습니다. 그러나 저장/구현 관련 세부 정보를 내보내는 경우 둘 다 약간 다릅니다. VM은 모든 스크립트처럼 보이는 구현 관련 세부 정보 및 스크립트 데이터를 violentmonkey 단일 파일로 래핑합니다. TM은 이것을 좀 더 합리적으로 수행합니다. 각 스크립트에 대한 구현 관련 세부 정보는 .options.js 파일로 내보내지고 스크립트 데이터는 .storage.json 내보내집니다.

나는 TM을 따르기 위해 구현을 다시 작업할 것이라고 생각합니다. 일반적으로 구현 세부 사항을 데이터와 분리하므로 더 나은 표준이라고 생각합니다.

'가져오기 방법'(위의 내 게시물에 설명됨):

TM은 '각 스크립트 선택' 인터페이스를 제공합니다. 아카이브를 가져올 때 각 특정 스크립트를 가져올지 여부를 선택합니다. 체크하면 해당 스크립트의 모든 데이터를 덮어씁니다.

VM은 위에서 설명한 '덮어쓰기'만 제공하는 것 같습니다. 그러나 연결된 스크립트 데이터를 가져오지 않는 옵션이 있습니다(모든 스크립트에 대해 전역). UI 관점에서 GM에서 해당 옵션을 구현하는 것은 어려울 것이라고 생각합니다. 그러나 데이터베이스 내보내기/가져오기에 TM 접근 방식을 취하면 사용자는 아카이브를 열고 .storage.json 파일을 제거할 수 있습니다.

테스트하려는 사람이 있으면 이전에 논의한 .zip 기능을 포함하도록 sxderp:import-export-database-merge 분기를 업데이트했습니다. @Eselce가 제안한 update 옵션을 구현하지 않았습니다. 아직 세부 사항이 확실하지 않기 때문입니다.

@Sxderp 이 기능을 개발해주셔서 감사합니다. 패키지를 빌드하고 Firefox 개발자 에디션에 설치했습니다(서명되지 않은 확장 설치를 활성화하기 위해). 해당 브라우저 버전으로 기존 프로필을 업그레이드하고 기존 GreaseMonkey 설치를 덮어쓰고 문제 없이 내 데이터베이스를 내보냈습니다.

이 GreaseMonkey가 설치된 새 Firefox 프로필을 가져오면 문제가 발생했습니다. 꽤 큰 하나의 특정 사용자 스크립트(user.js 및 gm_details.js 모두 약 230K임)가 가져오기 문제를 일으키는 것 같습니다. 데이터베이스를 교체한 후 GM이 작동을 멈춥니다. GM 아이콘을 클릭하면 빈 드롭다운(약 10x10 정사각형)이 열립니다.

특정 사용자 스크립트를 공개적으로 공유하지 않는 것이 좋습니다. 이 트릭을 사용하여 귀하의 이메일 주소를 찾았으며 그 방법으로 메시지를 보내드리겠습니다.

편집: GM이 중단된 후 작동하게 하는 유일한 방법은 확장을 제거하고 Firefox를 다시 시작한 다음 다시 추가하는 것입니다.

GMExport_20180 2 17_164139.zip ???

불만 없이 3.4MB zip 파일에서 (부분적으로) 큰 스크립트 전체(> 20)를 가져왔습니다. 자세한 검사는 없지만...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() 는 0에서 시작합니다... ; 누락...

IIRC, getMonth()는 0에서 시작합니다... ; 없어진...

찢다

나는 한동안 이 지점에서 일하지 않았다. 나는 오늘을 가지고 master에 rebase하고 많은 정리를 할 것입니다.

나는 master에 내 브랜치를 다시 기반으로 하고 더 나은 가독성을 제공한다고 생각하는 레이아웃에 몇 가지 중요한 변경을 가했습니다.
@ArmEagle 업데이트된 지점에서 보내주신 파일을 가져올 수 있었습니다. 그래도 문제가 있는 경우 알려주시면 자세히 살펴보겠습니다.

7fe8bfe94efbadb1da1a6491aaf424fc8275f09 의 변경 사항과 병합되었습니다. 내가 본 몇 가지 문제를 추적/토론하기 위해 다시 엽니다.

내가 본 몇 가지 문제를 추적/토론하기 위해 다시 엽니다.

어떤 문제가 있었나요?

일회성 빠른 테스트였습니다. 확실하지 않습니다. 설치해야 할 스크립트의 일부가 나열되지 않았습니다. 하지만 나는 그것을 반복하고주의 깊게 추적하고 결과를 기록하고 싶습니다. 가능한 경우가 많습니다.

나는 마침내 이것을 조금 조사했다.

.user.js 및 "세부 정보"만 백업합니다. 우연히 필요한 콘텐츠를 포함하지만 리소스를 놓치는 경우가 있습니다(Blob을 {} 로 직렬화하는 JSON). AFAICT 비어 있거나 깨진 얼룩이 있는 .setKnownResources() 이므로 작동하지 않습니다.

모든 스크립트에 자체 폴더가 있고 해당 폴더에 기본 .user.js , 각 @require 및 @resource 대한 파일이 포함되어 있고 나머지는 구문 분석된/ 사용자 지정 세부 정보 및 저장된 값. 크로스 플랫폼 호환성을 포기할 정도로 이것이 훨씬 더 나을 수 있다고 생각합니다.

전적으로 동의 한. 문서를 "웹 페이지로" 저장하는 것처럼 htm -document와 종속성이 있는 동일한(기본) 이름의 폴더를 생성합니다...

실수로 필요한 콘텐츠를 포함하는 일이 발생합니다 ...

우연이 아니었습니다. 발생했을 수 있는 모든 로컬 변경 사항에 대해 의도적으로 포함합니다. 리소스를 '구현 세부 정보'로 간주하고 따라서 '세부 정보'로 내보냅니다. TM은 리소스를 내보내지도 않습니다 / 필요합니다.

하지만 리소스를 놓치고 있습니다(Blob을 {}로 직렬화하는 JSON). AFAICT는 비어 있거나 깨진 얼룩이 있는 .setKnownResources() 이므로 작동하지 않습니다.

얼룩이 멋지게 문자열화되는지 알아내는 TODO가 있습니다. 이 기능은 PR을 제출하기 전에 기술적으로 병합되었습니다.

당분간 Blob 문제는 #2937로 해결됩니다.

백업 아카이브에 더 많은 파일을 생성하는 것이 모든 이점을 제공할 것이라고 생각하지 않습니다. 리소스 및 요구 사항 및 기타 사항을 별도의 파일로 보관하는 것은 추출할 때 보기 좋게_ 보일 수 있지만 이렇게 하면 간단한 덤프가 아닌 많은 작은 것들을 처리하기 때문에 코드가 더 복잡해질 수 있습니다.

이것은 4.4의 "큰 기능"이므로 이 기능을 곧 완료/개선하기를 바랍니다.

두 번째 생각, 이것은 기능적입니다. 추적하고 싶은 몇 가지 개선 사항이 있지만 이러한 대상 변경 사항에 대한 각각의 문제는 관리하기가 더 쉬울 것입니다.