This is wildly incorrect and an unfortunate misrepresentation of the past history of Budgie Desktop and my position. Budgie Desktop has never implemented free floating, drag & drop icons. Budgie Desktop used Nautilus’ desktop icons implementation until Nautilus ripped it out. Other distributors of Budgie Desktop went with alternatives such as Nemo or DesktopFolders, whereas for some time Solus (which developed Budgie Desktop back in the day) held back Nautilus to the version of Nautilus which did not remove the desktop icons implementation.
In late 2020, I began work on Budgie Desktop View, which has the goal of providing some form of desktop icons implementation to effectively replace the view Nautilus had, just not at feature parity. This was basically so you could have some form of desktop icons, with a first-party solution, and Nautilus on Solus could finally be updated. Nautilus is a file manager, with a bunch of functions that are IMO out-of-scope for a desktop view. See https://github.com/BuddiesOfBudgie/budgie-desktop-view#scope
I released Budgie Desktop View in November of 2020, release post you can see at https://buddiesofbudgie.org/blog/budgie-desktop-view-first-development-release
At no point did Budgie Desktop ever become “desktop-iconless”. It had no first-party solution until I implemented it. Before that it was piggybacking off Nautilus.
Budgie Desktop View does not support arbitrary positions because it makes use of GtkFlowbox with an orientation that renders items vertically down all the rows on one column before shifting to the next column (in other words, items flow), to keep rendering simple. Using a Flowbox meant calculations of columns and rows based on item size and screen resolution (which could change throughout the runtime of the app as the end user changes display resolution, or based on primary monitor) was able to be kept relatively simple, whereas the use of a GtkGrid or some other canvas solution would have been substantially more complex, as I would need to implement logic for moving elements when grid columns and rows no longer exist (due to screen resolution changes, e.g. primary monitor changes to one that is smaller) and prevent collision during that process, determining when to drop elements off the grid entirely, options for enabling / disabling shifts on file deletions, and so on. Nothing to do with “being against this”.
I have had a consistent position for years. For example this Solus forum post from November 2020. At this point, it is not something I want to do in the context of GTK3 , Budgie Desktop View in its current implementation is effectively feature complete for its current scope and implementation, and it hasn’t really been worth diving in to rewriting it entirely in another toolkit since there was and is substantially higher priority items. It is obviously completely possible to implement with a Grid but it was a matter of path of least resistance then (and I didn’t want to pull a GNOME and just drop all desktop icons support and leave it up to extension development, even though you assert the claim that I made it “desktop-iconless” somehow) and now it just doesn’t make sense to actively pursue a rewrite until other higher priority items are out of the way.
I have no idea what you are referring to with regard to “pinning”.
