On Fri, 9 Mar 2018 13:38:36 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> a volunteer is not going to do something they dislike. certainly not > readily. users have to convince the volunteer to do it. not the other > way around (that volunteers need to be slaves to users and do work > for them even if the volunteer disagrees and dislikes it). volunteers > don't get paid... they do things because they desire and want to. > it's the user's job to convince them... or for the user to stand up > and do it themselves. :) Yes and no. Being a volunteer does not mean you just show up and do what ever you want to do. I do not think anyone who thinks along those lines has ever volunteered in person. In my area we do things like beach cleanup, hurricane and disaster recovery. You do no get to just show up and do what ever. You do get assigned things to do as a volunteer. When it comes to FOSS this gets lost. People think its my time, my volunteering, I am going to do what ever I want with my time. That is true within reason. But that also says they only care about themselves, not the project, or what ever they are volunteering for. Which if they do not care about users, that also shows they do not care about the entity, organization, or project over all. If users must always convince others, that will not work, and tends to not work for projects who go down that path. Just as devs/volunteers must be motivated to fulfill a users wishes and desires. A user has to be motivated to step up. They have to want to, and that can start with wanting to work with given developers. If they see those developers/volunteers are just self serving. They likely will not want to work with them. I see that to often. People with skill, but others avoid them and the distro. Then they use that to drive off others saying others are having that effect. Not realizing its them... Thus despite running others off, project still suffers. I am also very much for PAID volunteers. Maybe not full time or part time, but some bounty to help with motivation on things they want no part of or not interested in doing otherwise. > > e doesn't follow the "unix philosophy". quoting it doesn't work. i > believe in efficiency. if it's something that can be controlled by > the same group and thus can get attention and get fixed along with it > and it needs to be integrated (desktop icons require this as does > efficiency) then it should be part of the same process most likely. Maybe it should, E runs mostly on *nix. Most of the world is *nix based now, short of Microsoft. You also end up making someones focus to wide vs narrow. Splitting ones time also as a result. As things grow it becomes to much for any one. I think its better for development, as things can evolve on their own and not be bound to constraints from other things. > e has never been a "unix philosophy thing" for as long as it has > existed. this is not a new thing. it's been the "have 1 process do as > much of your day to day desktop as can be done/is sensible" and fm is > sensible. it's not fundamentally that the shelf or e's menus or > wallpaper handling etc. - if you want the unix philosophy then all of > those move out to processes too. if you like that then kde is > probably good for you. :) gnome used to be until gnome 3... :) What E is today ans has been does not mean it has to be that way tomorrow. Even Apple realized their old OS and ways were garbage, and tossed them for older stuff. Look at the result.... And what has happened since gnome? Less GTK3 dev, and more GTK2 dev and desktops. Gnome did not help itself nor GTK. It just helped XFCE, Mint, and others. That should be a learning lesson there. > > I just do not like any one thing taking out other stuff. The more > > things can be limited and only effect themselves, the better IMHO. > > that is why e has crash recovery... :) but everything being separate > comes with a cost. it's not cheap to have lots of processes. > especially for things you run all the time, like a filemanager (for > the normal icons on desktop). You would not need the crash recovery as such. In the past window managers would crash and other stuff keep chugging along. Also that is IF you can restart E in time. That is not always the case. The thing is I do need the filemanager running all the time. Icons on the desktop could be rendered otherwise. Like what Plasma has done as an example. That is not related to the file manager. Having the file manager running always just for desktop icons seems like a bit much. > like arrows pointing in over a directory indicating you are going to > drop the file into the directory? I guess not sure. There are for arrows, one in each corner, and they like point in as part of their animation. Horrible description sorry! I cannot easily replicate that animation. If I drag a file over a folder nothing happens. Just noticed I cannot drag a file into a folder or anything. I am not sure how to trigger that animation, but seems like its some drag and drop. Though I think its happened on regular files not just folders. > if it's that - how does it get stuck. it's objects in the canvas in > the window.. they are drawn in the window.. so they can't remain if > the window goes. there is no canvas to draw them anymore... You would think so, next time it happens I will take a screenshot and you will see the animation remains. Its odd and annoying. >so this doesn't make sense. unless its the desktop files - that >window is the whole fulls screen canvas of the compositor... and i >can't make the arrows stay around at all... if drop is done they go >away. if dnd moves somewhere else they go away. I never full screen most anything that is rare. This tends to happen for me on accident. I accidentally click on something or drag something and boom, stuck animation. Likely why I cannot replicate. I just know I have seen it more than most other EFM issues. > it's about the only annoyance i find as its just a fast way of nuking > a file rather than right-click .. navigate to delete, then say > "yes"in the dialog or hit del key and say "yes" in dialog. drag and > drop into a trashcan is faster and simpler and... it's undoable (if > done right). The drag into a trashcan/recycle bin to delete is faster. Though I cannot drag and drop into folders now... I thought you were more wanting the extra step of not actually deleting something, but moving it to a intermediary location in case you did not want to delete. I always took trashcan on windows is oops I deleted that, let me get it back from the trashcan. I kind of like that as a fail safe. Though on KDE seems I had to go clean out those trash folders at times. Then does nothing for you at cli, so.... > > Along the same lines, I cannot select multiple files/folders/icons > > on the desktop. Though maybe related to main menu being left click. > > You > > of course you can. shift and ctrl + click. you cant "rubber-band" > select and that's because this conflicts with the main menu which > activates on mouse down and uses the same click+drag+release style of > use (as well as click+release then another click+release). Yes the "rubber-band" I missed, but figured it was due to main menu. I use the other method, shift + ctrl, selecting the files. Just takes a bit more time. I do not do it that often so some what moot. -- William L. Thomson Jr.
pgpzkh6VVdZav.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
