IgnorantGuru / spacefm

SpaceFM File Manager
http://ignorantguru.github.com/spacefm/
GNU General Public License v3.0
486 stars 72 forks source link

[desktop] Movable desktop icons #256

Closed ghost closed 10 years ago

ghost commented 11 years ago

In Parted Magic I have Rox Filer managing the desktop icons. The only reason I like it better than SpaceFM is that you can position the icons on the desktop by simply dragging them where you want them. It even has a snap to grid, so they can easily be aligned perfectly. The icons and the fonts look nice too.

Why it's not good for Parted Magic:

I have to run rox filer for the desktop wallpaper. For what ever reason transparency doesn't work right with conky, so I have to set the desktop wallpaper with feh too. It's a weird hack, but it works. It also makes it extremely complicated for users to change the desktop wallpaper.

Users can't add icons to the desktop by adding them to /root/Desktop. That means no right click to create a new file or folder on the desktop. The only way to add icons is to open Rox Filer, cd to /usr/share/applications/ and drag the desktop file to the desktop. Then it must be renamed because the .desktop extension is still attached to the name.

The desktop handling in SpaceFM is good, I would like to able to put the icons where I want them and in the order I want them in. This is just a wish. SpaceFM is great either way. :)

kanyck commented 11 years ago

Also, is it possible to make SpaceFM to draw icons only on a specific desktop, or have transparent background, or both? My reason is I use different wallpapers to differentiate compiz desktops (and find it very convenient) but it comes at cost of yielding desktop icons. It would be nice to have both...

jpfleury commented 11 years ago

is it possible to make SpaceFM to draw icons only on a specific desktop

It may be related to bug #40.

IgnorantGuru commented 11 years ago

@kanyck: One topic per issue please - you're welcome to open a new issue. At present, the desktop manager currently in spacefm is fairly simple, so more complex uses are bound to be unsupported. It's mainly intended to provide a lightweight, basic DM without any additional software being needed. But it's fine to point out the deficiencies you encounter - just don't spam other requests and issues please or it becomes unmanageable.

@PatrickVerner : There have been a few other requests elsewhere for movable icons, which I agree would be preferable. That will likely involve a redesign of how the desktop is currently coded, as I don't think the exo code is designed with that in mind at all - it's handled more like a list. What will be done with the desktop manager is still undecided. But requests and ideas are always welcome - they're good to review when any future work is considered, just don't hold your breath. :)

IgnorantGuru commented 11 years ago

Renamed this issue to '[desktop] Moveable desktop icons'

kanyck commented 11 years ago

@IgnorantGuru: Sorry I put it in the wrong place. My reason was that both topics are (probably) related to some DM redesign thus may be kept together. Will open a separate issue.

IgnorantGuru commented 11 years ago

jfyi, next branch (see BUILD NEXT in README - will be in 0.8.7 release) now includes a new desktop menu which allows for adding New|Desktop Application, among other additions.

Please help test next: new desktop manager menu with full design mode, link indicators on desktop items, new Devices menu, file properities now shows link target and allows you to edit the file date, KDE mime apps handling, improved handling of multiple workspaces. Should be nothing dangerous here just possible GUI glitches to be addressed - thanks.

Also, re the transparency and conky, please see the Conky notes on the wiki for possible configuration changes for use with spacefm. However, there was also a report that conky transparency doesn't work well with spacefm-GTK3 - likely something that needs to be addressed in conky.

Not trying to get you to use spacefm desktop - just letting you and other know the options that are available.

ghost commented 11 years ago

Okay, I have updated SpaceFM in the newest Parted Magic test version. It was easy enough to disable rox-filer and use SpaceFM instead. I compiled it for gtk2 and gtk3 and I couldn't make anything not work no matter how hard I tried. Everything looked good. No issues at all. Pretty much what I've always seen from this project. If there is an issue that you suspect, I'll try it. Let me know.

Conky works just fine in SpaceFM, I've never had an issue with PCManFM either. The only thing I noticed is it takes about 5 seconds for the transparency to work in SpaceFM and PCManFM. The background under conky is black for 5 seconds. If I keep my feh hack in place transparency works immediately. Transparency with conky doesn't work at all with rox-filer. Another thing that is annoying is rox-filer doesn't support start-up notification. So when a user clicks on firefox or another app that takes a long time to start, they have no idea it's working in the background and click on it again. Now that I think about it with rox-filer the names are not localized either. :(

I don't plan to hold my breath, but if you want to to work on the code to make them movable, I'll donate $100 for your effort. If bribing works, I'll donate as much as I can afford if you fork lxde-panel too. :D

SPACE DESKTOP!

IgnorantGuru commented 11 years ago

Hi Patrick, Glad your testing was boring. :) Didn't mean to push you into it - it was just a general plea, but appreciated! No known issues at this point but I had to marry some of the desktop code to the file browser code which required project-wide changes, so a little extra testing in next is helpful to keep master reasonably stable.

I can see you have a vision - I too have a lot of ideas for Space Desktop. We shall see. The dev process of SpaceFM is somewhat enigmatic and unpredictable even to me, but does follow a general strategy. eg I'm less likely to make piecemeal changes when later changes might just replace all that code anyway - part of using my time efficiently. And I'll keep the bounty in mind - might be the push I can use at a critical moment. In general I find one of the perks of free software dev is that I rarely commit to (promise) what I may or may not do. No bosses or obligations - something has to make up for the poor pay. ;)

As always I appreciate the feedback and encourage you and everyone to use whatever works best for them in each component. So I can keep the spacefm homepage accurate, does this mean SpaceFM is no longer the default fm in your upcoming Parted Magic? It's been awhile since I've tried the Rox desktop, but I'm assuming if Rox is doing the desktop then that becomes the default fm as well by necessity? I'll check out their snap-to-grid at some point - I think the Rox software is good, I use their terminal.

ghost commented 11 years ago

SpaceFM is our default FM and will be for the foreseeable future. I would rather just use SpaceFM for both. It's nice having a desktop system that's more integrated.

IgnorantGuru commented 11 years ago

Patrick, thanks for the clarification.

BwackNinja looked over the prospect of movable icons for me and his assessment makes it look more promising:

Movable icons sounds like an interesting problem. I guess it would have to be done by pixel rather than by grid square because of the variable height of the filenames. Handling changes in screen resolution would be something I’d want to do right, but I would probably defer it until everything else was working correctly. From a quick look at the code, the change wouldn’t be too hard, but I think you’d be better equipped to solve the issue. To get movable icons, you just need to modify the layout_items function in desktop-window.c to load the previous position of an icon if in movable icons mode, and save it when you drag and drop an icon. Adding new icons can be done by just finding the first place where they wouldn’t intersect with an existing icon. The sorting functions would also need to reset the icon positions. I was expecting this to be a harder problem, but the because the desktop code draws all the icons itself, the codebase looks like its already well equipped for this change.
ghost commented 11 years ago

Like I said before, SpaceFM is really great either way. I get a lot of compliments on how nice the file manager in Parted Magic is.

precutcolours commented 11 years ago

The move code should not be hard. On drag, ROX just drops new coords into an XML file. It's a very trivial XML format. PCManFM also lets desktop icons move.

For all the users I face who organize by desktop icons, I must employ ROX desktop or PCManFM. SpaceFM 0.8.7 release with miscellany desktop tweaks left me disappointed not to find movable desktop icons.

The only problem with ROX is Unix purism. "Save to Desktop" is a very common Windows/Mac metaphor everyone can grasp. The ROX attitude isn't helpful. ROX refuses to track $XDG_DESKTOP_DIR so I guess it's even violating FreeDesktop.org specs. ROX could offer a simple checkbox choice. Come to think of it, so could SpaceFM. Both programs lack a user choice. They just force different ones. SpaceFM shows icons from $XDG_DESKTOP_DIR and ROX doesn't. Neither program gives a checkbox for the user.

I even toyed with bash-scripting inotifywait $XDG_DESKTOP_DIR for either ROX or iDesk. Maybe the simplest thing is to fork ROX just to handle $XDG_DESKTOP_DIR. Movable icons are terribly important to end users. They associate a desktop icon with a file save. I feel their pain in a way. I guess it makes sense.

All of SpaceFM's "design mode" stuff is fine for geeks, but movable icons are what regular people want. Even I myself scarecely ever use "design mode" in any apps. The new right-click SpaceFM desktop menu is don't-care to us in that we set up our own pipe menus through the WM system. We in other words don't even want to see any SpaceFM right-click desktop menus. Actually we would be fine with them under a sort of inversion - with SpaceFM attaching to Openbox right-click menu, not overriding it completely.

Thanks for listening! Still love SpaceFM for all the issues. Naturally every app will reflect author interests and usage to some degree.

precutcolours commented 11 years ago

Movability is sometimes more than just a user skill issue. SpaceFM plops its first desktop icon underneath the draw area of (for instance) Cairo Dock. Our tests with SpaceFM forced us to move trays and docks just for fixed-position SpaceFM icons. So here's a "design mode" idea: a simple constraint box for the area in which SpaceFM draws desktop icons! The app should not assume that the whole screen is available. Borders are common places for trays and docks.

Thanks!

IgnorantGuru commented 11 years ago

So here's a "design mode" idea: a simple constraint box for the area in which SpaceFM draws desktop icons!

I definitely agree on this - I've encountered some problems here too. Am planning to add a customizable empty border width or start location for icons.

ROX refuses to track $XDG_DESKTOP_DIR so I guess it's even violating FreeDesktop.org specs. ROX could offer a simple checkbox choice. Come to think of it, so could SpaceFM. Both programs lack a user choice.

You're talking about a checkbox which would determine where the user's Desktop is found, ~/Desktop vs $XDG_DESKTOP_DIR? I would think that would be redundant, since they can set $XDG_DESKTOP_DIR. This isn't something 99% of users will do - more something someone setting up a distro would do, so it seems an unlikely candidate for a GUI option. If you would like to discuss that further please open a separate issue for it. You can see the code SpaceFM currently uses to find the Desktop dir here - in short glib provides a standards-compliant method for this.

Also, Design Mode is definitely not for geeks only, merely for those who like to customize things and add automation. Even if you change a shortcut key or icon you're using Design Mode.

For general discussion on the desktop and where it might go, consider a forum thread, or drop a link here to any discussion on PM's forum, etc. I try to keep each issue on this tracker focused on one specific actionable issue, otherwise it becomes unreasonable to maintain. On this issue the OT discussion seems inevitable, but if you want specific requests answered and tracked and given independent attention, splitting them is recommended. I definitely don't track every forum discussion involving SpaceFM, but I don't mind participating elsewhere if you bring a post to my attention. Clearly the desktop design can use some discussion, and I plan to review Rox DM and steal their best ideas. ;)

precutcolours commented 11 years ago

You're talking about a checkbox which would determine where the user's Desktop is found

Er, no - study ROX to see. It does not auto-draw icons inside $XDG_DESKTOP_DIR or any other path. One must create desktop icons by hand, ROX won't help, since it's Unix purist meaning there is no "desktop" just a filesystem and everything on the ROX "desktop" is a link.

The movable icons plug was all I wanted to state, sorry to wander. Focus on movability first and constraint box second.

IgnorantGuru commented 11 years ago

If anyone would like to preview the new behavior and give any early feedback (before the paint dries), movable icons have been introduced in the desktop branch. To build this branch, follow the BUILD NEXT instructions in README, substituting 'desktop' for 'next' in those commands.

Currently, a new 'Arrange Icons|Custom option has been added to the desktop menu, making files draggable and pastable on and to the desktop. Note that when you exit spacefm, icon positions are currently lost - saving and loading of positions is not yet coded. And there's still some work to be done in this branch, as some other additional features are being introduced, but the basic behavior of the movability is done.

The desktop is still implemented as a list of icons folded into columns. If Arrange Icons is set to Custom, you can reorder the list and it tolerates blank spaces. Thus if you drag a group of icons, their geometric relationship to one another may be lost - it's easiest to work with columns of icons at a time. Yet this approach has a few advantages: you can drop a selection on or near an icon to insert it into the list (rather than having to move icons out of the way first), you can select icons from various areas and drag them to a new location as a group, etc.

I don't recommend doing any serious testing until this is merged into the next branch (as it will just need to be retested again after some of the coming changes), but if you notice anything amiss feel free to add a comment here. At present, I'm not aware of any problems with the moving icons.

jpfleury commented 11 years ago

I'm testing the desktop branch. Very good work. I don't have any problems so far. I like a lot the possibility to drop an icon to insert it into the list (it's an advantage over xfdesktop).

Maybe one little drawback: when we try to insert an icon into the list before or after a folder, we don't have any visual cue to help us distinguish between a file being moved into a folder and an icon being inserted into the list. The difference between these two actions is just about a few millimeters in the screen, so we might move a file in a folder while we only wanted to insert it into the list.

IgnorantGuru commented 11 years ago

Maybe one little drawback: when we try to insert an icon into the list before or after a folder, we don't have any visual cue to help us distinguish between a file being moved into a folder and an icon being inserted into the list.

Thanks for testing. My plan on that issue is to use a different icon when drag-hovering on a folder vs just above it. You need to hit the space between them, or if the icon above the folder is not a folder, you can drop on the lower 20% of its box and it will be inserted after it. How difficult this is depends somewhat on icon and text sizes.

IgnorantGuru commented 11 years ago

when we try to insert an icon into the list before or after a folder, we don't have any visual cue to help us distinguish between a file being moved into a folder and an icon being inserted into the list

Although there is still no visual clue (lack of stock gtk icons for this), I have changed it so when you drop onto the icon text lines, it drops onto the desktop rather than into the folder (when in Custom sort mode only). This seems to make it much easier to drop between icons as desired. To drop into a folder you must drop directly onto the folder icon, not the icon text.

a1b4fd3 also adds an automatic drag action for the desktop. If you hover or drop over a folder icon which represents a directory on another device from the source files, the action changes to copy.

IgnorantGuru commented 11 years ago

Jfyi, this forum thread is a good place for general discussion of the desktop changes underway beyond movability.

IgnorantGuru commented 11 years ago

Movable icon positions are now saved, and the desktop branch has been merged into next. Please see this post for info on other changes.