Closed fossfreedom closed 6 years ago
Hello @fossfreedom, glad for your comment and the intention to use this project for Ubuntu Budgie. You ask me about concerns, and yes I have some:
My biggest concern is about compatibility. I did this project mainly focused for Elementary OS, but I tried not to use specific Pantheon libraries to allow the use in other distributions. But, to be honest, I didn't test it very well outside Elementary OS, only a few times in Ubuntu. Have you tried deeply in Budgie?. What GTK version is currently being used in Budgie?
Wayland is one of my biggest concerns in the future. I'm not an expert (this was my first, and unique, project with GTK), but it seems Wayland will be a problem for desktopfolder (for the absolute position at the desktop of panels). Is Budige using wayland already? What are the plans to use it?
Hdpi. Desktopfolder use currently using fixed size icons, I'm afraid icons in hdpi desktop will be very small, there is an issue about that. But well, this is something that can be more or less fixed.
Maintenance. To be honest, the project is currently in low maintenance. I don't have too much free time to maintain it, and currently, there is nobody helping me. I'm afraid about the amount of job I need to adapt desktop folder to Budgie / Ubuntu / Gnome and the future maintenance.
On the other hand, it is very exciting the idea to be on the official channel of a distribution like Budgie. So, if I can help, I will try to do my best.
The version of GTK we would be targeting is GTK+3.24 for Debian and Ubuntu - I understand there will be no more version bumps before GTK+4
Budgie does not use Wayland - as I understand - no immediate plans to move in that direction.
From an initial QA testing point of view desktopfolder works nicely with budgie-desktop. We haven't looked at potential integration issues yet - for example how to dynamically start and stop desktop folder via a budgie settings (think gnome-control-center but for budgie) checkbox.
HiDPI is a definite must have - but I'm surprised the normal resolution scaling to 200% does not work with desktopfolder - we will need to confirm.
More than happy to help with smallish maintenance issues - e.g. resolving new vala version compilation issues.
But yes - uploading to Debian and Ubuntu will expose your project to several fold increases of users. This could be both a blessing and a hindrance - more eyes means more potential help... but also much more potential triaging. Again the latter is something I definitely can help with through to adding any debugging etc to try to narrow stuff down. Hint: add a github template so that when users create new issues you could invite them to help diagnosing and help with actual pull-requests.
I'm going to have a much closer look over the next few days at potential code compilation and other integration issues (if any) - would it be ok to discuss this with you if I find anything I cannot figure out myself via this issue?
Sure, you are free to contact me via this issue, email or whatever.
Ok - I had a quick 30 minute look last night. I made the following notes
The overall package name you have "com.github.spheras.desktopfolder" is very odd. I'm intending to package it as "desktopfolder"
The upstream name of the binary is very odd “com.github.spheras.desktopfolder” - think it should just be “desktopfolder” --> If you are happy I'll update the meson.build
A minor tweak to the popup when you right-click the desktop to hide a GTK Separator that is at the top of the popup on its own. I'll have a look at this.
I was mulling over whether there is need to support the ~/Templates folder to enable you to right-click and create Template documents. But that is obviously still available via Nautilus itself.
Drag-drop from the desktop into a desktop-folder is a nice bonus to implement. But not really a must have IMHO.
In addition a must have is to hide the first “folder” on the desktop that is created. Don’t believe that should happen on first startup for budgie. Would need to be a gsetting setting that we can then override. If you are content - I'll have a look at this.
The source contains a debian folder - this will not work for Debian and Ubuntu builds since the package is specific to elementary. Suggest needs deleting/moving to another branch
The release tarball is not signed by you.
Some source files say “GPL+2 or later” - some say “GPL+3” and the overall project LICENSE is GPL+3". Inconsistent and is a no-go for Debian
If you don't mind I will continue looking more closely. Cheers.
quick response to your notes:
re tarballs
This wiki explains how to create tarball signatures - https://wiki.debian.org/Creating%20signed%20GitHub%20releases
As to why - so you as project owner can be absolutely sure that anyone claiming to use your published source has not tampared with it in anyway. Its good practice - its not mandatory though but strongly recommended.
re License - let me know which way you want to go with this - I will do a PR. Do you want me to plough through the .vala sources and ensure you have a "GPL+2 (or later)" statement or a "GPL+3" statement. I will adjust your LICENSE file depending upon which license you want to publish with.
I will do PR's for the rest - or raise separate issues to track.
Quick question with regards to deprecated code.
Are you still targeting trusty/xenial? N.B. your travis-ci is set to run for trusty. The deprecated code I'm looking at is making sure all code is compatible with GTK+3.22 and later. This means it would not be backward compatable with trusty/xenial unless we add compile time GTK checks around offending code.
Kind of messy - but needed if you want to be backward compatible.
re tarballs
This wiki explains how to create tarball signatures - https://wiki.debian.org/Creating%20signed%20GitHub%20releases
As to why - so you as project owner can be absolutely sure that anyone claiming to use your published source has not tampared with it in anyway. Its good practice - its not mandatory though but strongly recommended.
re License - let me know which way you want to go with this - I will do a PR. Do you want me to plough through the .vala sources and ensure you have a "GPL+2 (or later)" statement or a "GPL+3" statement. I will adjust your LICENSE file depending upon which license you want to publish with.
I will do PR's for the rest - or raise separate issues to track.
GPL+3 is the correct license
Quick question with regards to deprecated code.
Are you still targeting trusty/xenial? N.B. your travis-ci is set to run for trusty. The deprecated code I'm looking at is making sure all code is compatible with GTK+3.22 and later. This means it would not be backward compatable with trusty/xenial unless we add compile time GTK checks around offending code.
Kind of messy - but needed if you want to be backward compatible.
mmm As far as I know, travis is set to ubuntu bionic. Anyway, the travis configuration is set to elementary Juno scripts. They really maintain the scripts to test the application against elementary. So, I'm not sure exactly what are they doing behind the scene. You can see more about the requirements to publish in the elementary app center, here (my concern is I want to continue publishing there): https://github.com/elementary/houston/wiki/Before-You-Publish https://medium.com/elementaryos/developer-tips-updating-your-apps-for-juno-453c07a5b3a7
With the recent upgrade to Elementary Juno the idea was to freeze the Loki version (GTK+3.18), upgrade to GTK+3.22 for Juno with no backward compatibility for Loki and only maintain the application for Juno in the future. Therefore, my idea was not to be backward compatible. I will try to review the code during these days to avoid deprecated functions.
@fossfreedom, regarding this:
Drag-drop from the desktop into a desktop-folder is a nice bonus to implement. But not really a must have IMHO.
you can do it, but only with one file at a time. Press ctrl key, and then drag a file from a desktop. Once you start dragging you can release the ctrl key (ctrl key is for copying, without it you move). Drop the file onto a panel. I know it is a bit difficult to understand you must start with the ctrl key pressed, but that is what we have by the moment.
One last request - assuming of course that you are interested - suggest add a donation's link to the README !
@spheras - when you are happy to proceed, I will begin the Debian/Ubuntu upload process when you create the next release tarball. thx for all your help and expertise. Much appreciated.
you're welcome. Do you need a release? I see there are some minor issues pending yet, I will try to solve them asap.
As soon as you make a release I can begin the upload process which can take from a few days to several weeks or months...
After that the next version should be relatively quick to upload.
So I do think the current git master is in good shape.
The UB team will be working with you on a few ideas in the interim whilst the upload process is occurring. We would gratefully request you consider those and if possible include them in a subsequent release
Time frames ... hoping the Debian upload will occur sometime in December ... the next release in January/Feb. Thereafter bug fixes until final release in April.
On Thu, 8 Nov 2018, 07:05 José Amuedo Salmerón notifications@github.com<mailto:notifications@github.com wrote:
you're welcome. Do you need a release? I see there are some minor issues pending yet, I will try to solve them asap.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/spheras/desktopfolder/issues/119#issuecomment-436894125, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8zkGO5QCU5X9CbAfFhBioYcIgYF3-Pks5us9fSgaJpZM4YCC9d.
Thanks for signing the upload - just a quick thing - can you please change the release description from "Ubuntu Budgie" to "budgie-desktop" - changes will work on all budgie-desktop distro's. thx
I'm looking for your public key to check the package against on https://keyserver.pgp.com - did you upload your key to a public key server? It may be a bit slow to replicate ... so I'll check again in a few hours time.
No, I didn't upload. Ok, now is published.
Hi I just realised that I cannot grab the source .tar.gz with a differently named .asc that are downloaded in completely different folders - a debian/watch file just doesn't like this!
enclosed is the way I do signed releases. If you extract the tarball into your root of the project and run ./mkrelease.sh it will sign and create the tarball at the same time. You can then attach both the tarball and the corresponding gpg file at the same time. Its just a very quick way of doing signed releases.
Obviously in the mkrelease.sh you need to change the signing key with yours - and each release you need to bump the version :)
Please can you remake and attach the tarball + signed file? thanks in advance.
Ok, I did. Just for curiosity, I don't understand what was bad. I followed the instructions given in the debian wiki, Did I something bad?, Now there are 2 tarballs in the release, the automatic done by github and the one I just uploaded... that seems strange. What was wrong exactly with the old one?
The pictures and the words in the wiki do not match. The pictures are correct ... The file should be named v1.0.10.tar.gz.asc but the words said desktopfolder-1.0.10.tar.gz.asc
As I mentioned... The script method is very simple and guarantees a matching tarball and signature. I have tried the manual method in the wiki in the past and it us too easy to accidentally get a mismatched pair of files.
Cheers ... I will try again tonight with the revised files.
BTW desktopfolder already has a new translation from the wonderful country of Brazil.
On Fri, 9 Nov 2018, 07:16 José Amuedo Salmerón notifications@github.com<mailto:notifications@github.com wrote:
Ok, I did. Just for curiosity, I don't understand what was bad. I followed the instructions given in the debian wiki, Did I something bad?, Now there are 2 tarballs in the release, the automatic done by github and the one I just uploaded... that seems strange. What was wrong exactly with the old one?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/spheras/desktopfolder/issues/119#issuecomment-437271605, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8zkLjGgbBZowO0rE2Yk9Wj5CsX_6hqks5utSvAgaJpZM4YCC9d.
I have sent v1.0.10 to debian for evaluation now. Just a matter of waiting now and responding.
Ok, Thanks @fossfreedom. (curiosity) In what consists that evaluation? Automatic or manual? If I'm not wrong the evaluation is just to deploy the deb in their repository, isn't it?
Bit of both
https://github.com/UbuntuBudgie/desktopfolder/tree/debian/debian
They will be evaluating the above package meets the current Debian standards. They look at the code to see things like copyright has been correctly captured in the debian package copyright file. They look to see if the source itself meets checks such as what is run by check-all-the-things They check lintian passes for the QA checks.
On Sat, 10 Nov 2018, 22:10 José Amuedo Salmerón notifications@github.com<mailto:notifications@github.com wrote:
Ok, Thanks @fossfreedomhttps://github.com/fossfreedom. (curiosity) In what consists that evaluation? Automatic or manual? If I'm not wrong the evaluation is just to deploy the deb in their repository, isn't it?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/spheras/desktopfolder/issues/119#issuecomment-437625376, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8zkPFsLkqx-7JyC-B3RlguCLzv-K-5ks5ut07cgaJpZM4YCC9d.
@spheras Good news!
v1.0.10 of desktopfolder has now been accepted into Debian and it will now be the version in Debian Buster next week when it transitions from unstable. It will make its way into Ubuntu 19.04 overnight.
Great! :tada: Thank you very much @fossfreedom for the effort!!
Do you think it is time to close a new release? Which functionality do you think is pending for that?
I think what you have already is an excellent time for release!
From my UB hat on, three "must have" issues I would like to pitch for your consideration that our users have requested for a future release or a future + 1 release
When I get some time I would like to ask you for some help with the outstanding PR - hopefully will get back to that in a week or two.
On Tue, 15 Jan 2019 at 08:51, José Amuedo Salmerón notifications@github.com<mailto:notifications@github.com> wrote:
Do you think it is time to close a new release? Which functionality do you think is pending for that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/spheras/desktopfolder/issues/119#issuecomment-454312687, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8zkBs59E9iCGx71oen7l0BbFYJzbI-ks5vDZaDgaJpZM4YCC9d.
I think the best is to add those features if possible in the new release. Let's study them:
Yeah - sorry - was on the phone at the time when I wrote the above.
We also discussed this with Unity #229 which has a vertical dock - and budgie itself can have left and right panels. Can you have additional panels in Elementary? Certainly you should be able to switch Elementary's version of plank to the left hand side.
At the moment with desktopfolder - if you have "app-arrange" mode the grab-hand and auto copy happens. From Grid and Free, whilst the grab-hand appears the drag and drop mode doesnt work until you press the shift key.
Ok:
Hi there,
Ubuntu Budgie have been evaluating this capability as a possible replacement for the extant Nautilus desktop icons capability (v3.26) when the Nautilus version is bumped to v3.32 for 19.04. Assuming the version of Nautilus is bumped in 19.04, an educated guess is that Ubuntu itself will default to the gnome-shell extension that has been developed to support desktop icons for the gnome-shell desktop. Ubuntu Budgie which uses the budgie-desktop would then be left without a desktop-icon solution which is why we have been looking at an off-the-shelf solution such as this project.
I am just seeking your advice - do you have any concerns about this? The alternative approach would be a brand new native budgie-desktop capability written from scratch.
The packaging approach would be to make the existing Debian package fully up-to Debian standards (if it isn't already) and then submit this to Debian for their consideration.
If Debian are content to include it in their repository it will then sync with Ubuntu automatically.
I would be the maintainer of the package in both Debian and Ubuntu - I would primarily sync the same release version as you publish - possibly include any stability type patches that may be released between versions.
Bug reports raised by either Ubuntu or Debian I would try to triage and possibly direct users to your project here. thanks in anticipation