Greasemonkey: Tambahkan cadangan/pulihkan

Nah, Firefox dan masalahnya. Jadi, saya menerapkan ini (dan tentu saja fungsi 'impor'). Saya hampir selesai dengan itu, tetapi ada penghenti pertunjukan. Ini hanya berfungsi ketika Anda membuka browser toolbox dan memilih "jangan tutup otomatis popup". Impor dilakukan melalui <input type="file"> (yang merupakan satu-satunya cara), namun, pada fokus jendela jelajah, sembulan biasanya ditutup, sehingga jendela dihancurkan dan tidak ada fungsi yang dijalankan. Bug yang relevan:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

Sangat menyebalkan memiliki lingkungan setengah-setengah untuk bekerja.

Juga, berlaku untuk #2612. Yang dapat diatasi pada saat yang sama adalah masalah ini.

@Sxderp Jika penutupan popup menjadi masalah, cara normal untuk menyelesaikan/menyelesaikannya adalah dengan hanya membuka tab atau jendela (menunjuk ke halaman HTML di dalam ekstensi) di mana Anda melakukan apa pun yang perlu Anda lakukan. Tab/jendela seperti itu tidak ditutup secara otomatis dan menampilkan lingkungan yang sama dengan sembulan. Meskipun itu mungkin tidak sebersih memiliki semuanya di dalam popup browser, itu harus berfungsi.

Aku bisa melakukan itu. Ini akan melibatkan memindahkan banyak kode. Saya akan memeriksanya lain kali.

Saya telah menyelesaikan impor / ekspor barang. Tidak ada tes, dan sangat sedikit penanganan kesalahan. Tapi itu berhasil. Padahal, untuk kesederhanaan saya membuatnya sehingga impor akan menimpa seluruh database. Dengan konfirmasi prompt tentu saja.

Saya pikir idealnya pengguna dapat memilih untuk mengganti atau menggabungkan impor. Stylus hanya bergabung, yang juga merupakan IME yang buruk. Pilihan pengguna, dengan default yang mungkin berfungsi, tampaknya yang terbaik.

Tentu, tetapi kemudian kami mengalami banyak persyaratan. Saya ingin melihat semacam diagram alir tentang sifat _exact_ penggabungan.

Sebagian besar dalam hal konflik. Timpa konten, timpa kunci/nilai (ya itu juga diekspor), Prompt untuk semuanya (yang sepertinya pengalaman pengguna yang buruk), dll?

Maksud saya hanya: impor setiap skrip dalam file (dan timpa sepenuhnya ke status itu), tetapi jangan sentuh/hapus skrip yang tidak ada dalam file.

Oh. Itu jauh lebih sederhana. Ya, itu terdengar bagus.

Jadi saya telah menerapkan tiga metode impor yang berbeda.

1. Menggabungkan. Jangan sentuh skrip yang diinstal. Hanya skrip yang saat ini tidak ada[1] yang akan ditambahkan ke database.
2. Mengganti. Copot semua skrip saat ini dan ganti dengan yang diimpor.
3. Timpa. Suka menggabungkan tetapi jika konflik ditemukan[1] maka skrip yang diimpor didahulukan.

Menunggu PR lain sebelum mengirimkan.

[1] Saya menentukan keunikan dengan id skrip.

Bagaimana dengan ini?

1. Memperbarui. Hanya impor (timpa) skrip yang sudah ada.

Ini melengkapi 1. Gabung

1. Timpa. Suka menggabungkan tetapi jika konflik ditemukan[1] maka skrip yang diimpor didahulukan.

@Sxderp Saya kira, "Seperti penggabungan" tidak termasuk batasan "Hanya skrip yang saat ini tidak ada"...
(batasan ini tidak masuk akal di sini) Artinya, Timpa = Impor semua skrip, skrip yang bertentangan ditimpa oleh arsip...

Manakah dari opsi ini (perbarui/gabungkan/dll.) yang ditawarkan oleh VM, TM, atau lainnya?

1. Memperbarui. Hanya impor (timpa) skrip yang sudah ada.

Tentu, itu harus bisa dilakukan.

Artinya, Timpa = Impor semua skrip, skrip yang bertentangan akan ditimpa oleh arsip...

Benar.

Manakah dari opsi ini (perbarui/gabungkan/dll.) yang ditawarkan oleh VM, TM, atau lainnya?

Sebenarnya tidak yakin. Tapi ini memunculkan kekhawatiran saya yang lain. Kompatibilitas dengan arsip. Dengan asumsi add-on tersebut mendukung ekspor basis data penuh (skrip + data), maka idealnya impor harus kompatibel satu sama lain.

Memperbarui. Hanya impor (timpa) skrip yang sudah ada.

Sekarang saya memikirkan hal ini (semuanya seperti 3 menit), saya memiliki kekhawatiran. Bagaimana dengan data terkait (get/setValue)? Haruskah data yang saat ini disimpan tetap ada? Haruskah data yang diimpor didahulukan? Beberapa jenis penggabungan? Dan kemudian dengan jelas mewakili opsi/status ini kepada pengguna. Ini sebenarnya sedikit lebih rumit daripada pandangan pertama.

Melakukan beberapa pemeriksaan cepat, ini tidak 100% menyeluruh tetapi memberikan gambaran umum, serta apa yang mungkin harus saya ubah sehubungan dengan implementasi saya.

VM dan TM keduanya mengekspor ke file zip. Di dalam file zip Anda dapat menemukan file .user.js untuk setiap skrip Anda. Namun, untuk mengekspor detail spesifik penyimpanan/implementasi, keduanya melakukannya sedikit berbeda. VM membungkus detail spesifik implementasi dan data skrip, untuk apa yang tampak seperti semua skrip, ke dalam satu file, violentmonkey . TM melakukan ini sedikit lebih waras. Detail spesifik implementasi, untuk setiap skrip, diekspor ke file .options.js , sedangkan data skrip diekspor ke .storage.json .

Saya pikir saya akan mengerjakan ulang implementasi saya untuk mengikuti TM. Secara umum saya pikir ini adalah standar yang lebih baik karena memisahkan detail implementasi dari data.

Adapun 'metode impor' (dijelaskan dalam posting saya di atas):

TM menyediakan antarmuka 'pilih setiap skrip'. Saat Anda mengimpor arsip, Anda memilih apakah Anda ingin mengimpor setiap skrip tertentu. Jika Anda memeriksanya maka itu akan menimpa semua data untuk skrip itu.

VM sepertinya hanya menawarkan apa yang saya jelaskan di atas sebagai 'Timpa'. Namun, ada opsi untuk TIDAK mengimpor data skrip terkait (global untuk semua skrip). Dari perspektif UI, saya pikir menerapkan opsi itu di GM akan sulit. Namun, jika kita mengambil pendekatan TM untuk mengekspor / mengimpor database, maka pengguna cukup membuka arsip dan menghapus file .storage.json .

Jika ada yang ingin menguji, saya telah memperbarui cabang saya, sxderp:import-export-database-merge , untuk menyertakan fungsionalitas .zip saya diskusikan sebelumnya. Saya tidak mengimplementasikan opsi update yang disarankan @Eselce karena saya masih tidak yakin tentang

@Sxderp Terima kasih telah mengembangkan fitur ini. Saya telah membuat paket dan menginstalnya di Firefox Developer Edition (untuk mengaktifkan pemasangan ekstensi yang tidak ditandatangani). Saya memutakhirkan profil yang ada dengan versi browser itu, menimpa instalasi GreaseMonkey yang ada dan mengekspor database saya tanpa masalah.

Mengimpor profil Firefox baru dengan GreaseMonkey yang diinstal ini menyebabkan masalah. Tampaknya satu skrip pengguna tertentu yang cukup besar (user.js dan gm_details.js sekitar 230K menyebabkan masalah impor. Setelah mengganti database, GM berhenti bekerja. Mengklik ikon GM membuka dropdown kosong (sekitar 10x10 persegi).

Saya lebih suka tidak membagikan skrip pengguna tertentu secara publik. Dengan menggunakan trik ini, saya telah menemukan alamat email Anda dan saya akan mengirimi Anda pesan seperti itu.

Sunting: Satu-satunya cara untuk membuat GM berfungsi setelah rusak adalah dengan menghapus ekstensi, memulai ulang Firefox, dan menambahkannya lagi.

GMexport_20180 2 17_164139.zip ???

Mengimpor sejumlah besar (sebagian) skrip besar (> 20) dari file zip 3,4 MB tanpa keluhan. Tidak ada pemeriksaan rinci meskipun ...

  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() dimulai dari 0... ; hilang...

IIRC, getMonth() dimulai dari 0... ; hilang...

MENINGGAL DUNIA

Saya sudah lama tidak bekerja di cabang ini. Aku akan mengambil hari ini dan rebase pada master dan melakukan banyak pembersihan.

Saya telah mengubah basis cabang saya pada master dan membuat beberapa perubahan signifikan pada tata letak yang menurut saya menawarkan keterbacaan yang lebih baik.
@ArmEagle Di cabang saya yang diperbarui, saya dapat mengimpor file yang Anda kirim. Jika Anda masih mengalami masalah, beri tahu saya dan saya akan memeriksanya lebih lanjut.

Digabungkan dengan perubahan pada 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09 . Membuka kembali untuk melacak/mendiskusikan beberapa masalah yang pernah saya lihat.

Membuka kembali untuk melacak/mendiskusikan beberapa masalah yang pernah saya lihat.

Apa masalahnya?

Adalah tes cepat satu kali, saya tidak yakin, sejumlah skrip yang saya harapkan untuk diinstal tidak terdaftar. Tapi saya ingin mengulanginya dan melacak dengan hati-hati dan menuliskan hasilnya. Ada banyak kemungkinan kasus.

Saya akhirnya melihat ini sedikit.

Itu hanya mencadangkan .user.js , dan "detail". Yang kebetulan secara tidak sengaja menyertakan konten yang diperlukan, tetapi melewatkan sumber daya (JSON membuat serial gumpalan ke {} ). AFAICT itu akan .setKnownResources() dengan gumpalan kosong/rusak, dan dengan demikian gagal bekerja.

Tampaknya lebih baik jika setiap skrip memiliki foldernya sendiri, folder itu berisi file untuk .user.js , untuk masing-masing @require dan @resource , dan kemudian mungkin sisanya diurai/ detail kustom, dan nilai tersimpan. Saya pikir ini bahkan mungkin cukup baik sehingga saya akan mengorbankan kompatibilitas lintas platform apa pun.

Sangat setuju. Sama seperti menyimpan dokumen "sebagai halaman web", yang akan membuat htm -document plus folder dengan nama (dasar) yang sama dengan dependensi...

Yang kebetulan secara tidak sengaja menyertakan konten yang dibutuhkan ...

Bukan karena kebetulan. Termasuk dengan sengaja, untuk setiap perubahan lokal yang mungkin terjadi. Saya akan menganggap sumber daya/kebutuhan sebagai 'detail implementasi', dan karenanya diekspor sebagai "detail". TM bahkan tidak mengekspor sumber daya/membutuhkan.

tetapi melewatkan sumber daya (JSON membuat serial blob ke {}). AFAICT akan .setKnownResources() dengan gumpalan kosong/rusak, dan dengan demikian gagal berfungsi.

Ada TODO untuk mencari tahu apakah gumpalan merangkai dengan baik. Fitur ini secara teknis digabungkan sebelum saya mengajukan PR untuk itu.

Untuk saat ini, masalah Blob akan diselesaikan dengan #2937.

Adapun untuk membuat lebih banyak file di arsip cadangan, saya tidak berpikir itu akan memberikan semua manfaat. Sementara pengarsipan sumber daya dan kebutuhan dan apa pun yang keluar ke dalam file terpisah mungkin _terlihat_ bagus saat diekstraksi, melakukan hal ini kemungkinan akan membuat kode lebih kompleks karena Anda berurusan dengan banyak hal kecil daripada dump sederhana.

Ini adalah "fitur besar" untuk 4.4 jadi saya sangat berharap untuk menyelesaikan/meningkatkan ini segera.

Pikiran kedua, ini fungsional. Ada beberapa peningkatan yang ingin saya lacak, tetapi setiap masalah untuk perubahan yang ditargetkan itu akan lebih mudah dikelola.